Webアプリケーション脆弱性診断本『Webセキュリティ担当者のための脆弱性診断スタートガイド 上野宣が教える情報漏えいを防ぐ技術』を発売予定

本 私

2016年8月2日に3年ぶりに書籍を出します。テーマは「Webアプリケーション脆弱性診断」です。
弊社（株式会社トライコーダ）では脆弱性診断を学ぶための講座をいくつか提供していたり、リーダーを務めるOWASP Japanの脆弱性診断士スキルマッププロジェクトでのガイドライン作りなどによって、診断会社各社の診断手法やノウハウなどを蓄積することができました。本書はそれを一冊にまとめた本となっています。

Webセキュリティ担当者のための脆弱性診断スタートガイド 上野宣が教える情報漏えいを防ぐ技術
Webセキュリティ担当者のための脆弱性診断スタートガイド 上野宣が教える情報漏えいを防ぐ技術
  • 発売元: 翔泳社
  • 価格: ï¿¥ 3,456
  • 発売日: 2016/08/02

posted with Socialtunes at 2016/07/13

脆弱性診断はセキュリティ会社が実施することが多いのが現状のようです。それは脆弱性診断という技術が特殊なために熟練のセキュリティ専門家でないと実施できないという誤解からかもしれません。
実際はそうではありません。手法を知り、方法を学ぶことで誰にでもできるようになる技術です。さらにはシステムの仕様を知っている開発者が脆弱性診断を行うことで、システムのことを知らないセキュリティ専門家が行うよりもうまく行える可能性すらあるのです。

本書ではWebアプリケーションの脆弱性診断を行うために必要な基礎知識、診断に必要なツール、そして脆弱性を効率的に発見するための診断手法、報告書の書き方などを学ぶことができます。
また、レビューアーにはOWASP JapanなどのWGでご一緒させて頂いている 小河 哲之さん（Burp Suite Japan User Group）、亀田 勇歩さん（SCSK株式会社）、国分 裕さん、洲崎 俊さん、西村 宗晃さん（株式会社リクルートテクノロジーズ）、山崎 圭吾さん（株式会社ラック）にお願いさせて頂きました。

目次

1.脆弱性診断とは
この章では脆弱性診断とは何かということを学んで行きます。WebサイトやWebアプリケーションの脆弱性とはどういったもので、それを発見するための手法である脆弱性診断とはどういったものかを学びましょう。

2.診断に必要なHTTPの基本
この章ではWebの主要なプロトコルであるHTTPの基本について学んで行きます。Webアプリケーションの脆弱性診断を行うためには、Webの主要な通信プロトコルであるHTTPの理解を欠かすことができません。
HTTPというプロトコルの仕組みや、通信でやりとりするメッセージの構造などを学びましょう。

3.Webアプリケーションの脆弱性
この章ではWebアプリケーションの脆弱性について学んで行きます。Webアプリケーションへの攻撃がどういうもので、どういった種類のものがあるのかを学びましょう。

  • Webアプリケーションへの攻撃とは
  • インジェクション - Webアプリケーションの脆弱性
  • 認証 - Webアプリケーションの脆弱性
  • 認可制御の不備・欠落 - Webアプリケーションの脆弱性
  • セッション管理の不備 - Webアプリケーションの脆弱性
  • 情報漏えい - Webアプリケーションの脆弱性
  • その他 - Webアプリケーションの脆弱性

4.脆弱性診断の流れ
この章ではWebアプリケーション脆弱性診断の流れについて学んで行きます。まず診断会社が提供しているような診断業務全体の流れを学びます。そして診断実施前の準備には何が必要かを知り、脆弱性診断はどのように行うかという実施手順を学びましょう。

  • 診断業務の流れ
  • 診断実施前の準備
  • 脆弱性診断の実施手順

5.実習環境とその準備
この章では本書の実習に必要な診断ツール、Webブラウザ、実習環境のセットアップについて説明していきます。

  • 診断ツールのセットアップ
  • 診断のためのWebブラウザのセットアップ
  • 実習環境のセットアップ
  • 実際の診断の際の注意事項

6.自動診断ツールによる脆弱性診断の実施
この章では自動診断ツールを使った脆弱性診断の実施手順をはじめとして、自動診断ツールとして使用するOWASP ZAPの基本操作、脆弱性診断の実施方法などを説明していきます。

  • 自動診断ツールを使った脆弱性診断の実施手順
  • OWASP ZAPの基本操作
  • OWASP ZAPに診断対象を記録
  • OWASP ZAPで診断を実行

7.手動診断補助ツールによる脆弱性診断の実施
この章では手動診断補助ツールを使った脆弱性診断の実施手順を初めとして、脆弱性診断に使用する基準、診断リストの作成方法、手動診断補助ツールとして使用するBurp Suiteの基本操作、各種ツールの使い方、脆弱性診断の実施方法などを説明していきます。

  • 手動診断補助ツールを使った脆弱性診断の実施手順
  • Webアプリケーション脆弱性診断手法: 脆弱性診断士スキルマッププロジェクトの基準
  • Burp Suiteの基本操作: 手動診断のためのBurp Suite基本操作
  • 診断リストの作成: テストケースのシートを作成する手順
  • Burp Suiteの各種ツールの使い方
  • Burp Suiteを使った脆弱性診断
  • より多くの脆弱性を発見するためのヒント集: より多くの脆弱性を発見するための手動診断のコツ

8.診断報告書の作成
この章では脆弱性診断を実施した結果をまとめた診断報告書の作成について、報告書に記載すべき事項や個別の脆弱性の報告方法、リスク評価の付け方などを説明していきます。

  • 診断報告書の記載事項
  • 総合評価と個別の脆弱性の報告
  • リスク評価

9.関係法令とガイドライン
この章では脆弱性診断に関連する法律、診断時のルールや診断結果の取り扱い、セキュリティに関する基準やガイドラインについて説明していきます。

  • 脆弱性診断に関連する法律、ルール、基準など

付録: 実習環境のセットアップ（Oracle VM VirtualBox）

Webアプリケーション脆弱性診断講座

本書を使ったトレーニングであれば筆者が教える弊社のこちらがお勧めです。

Aterm MR03LNが海外でもSIMフリーになった

私

モバイルルーターとしては最強と言われるほど申し分ない機能を持つ Aterm MR03LN は、当初SIMフリー機だと噂されていましたが、国内ONLYのDoCoMoのMVNOのSIMにしか対応していませんでした。

海外によく行く私としては、海外で使えないとモバイルルーターとしての意味がなく、買ってしばらくしてタンスの肥やしに。（買った理由は、クレードルを使うことで有線LANのネットワークが組めるからでした。出張時のサイバー演習のトレーニングに1回使ったっきり。）

そしてこの8月に期待していたファームウェア2系が公開されて、いろいろあって（ファームウェア2.0の公開停止とか）ようやくAPNの設定が自由にできるように！これは期待！ということで、ファームウェアを 2.0 にした MR03LN を今回の台湾出張（ハッカー系カンファレンスの HITCON に参加するため）

結果、松山空港で買った中華電信のプリペイドSIMを挿し、APN設定を行ったところ無事に動作を確認しました。安定性、速度ともにまったく問題ありません。（台湾ではLTEは今年開始しましたが、プリペイドSIMではLTE未対応らしい）

2.0は不具合があって心配していましたが、台湾滞在中の8月19日に2.1が公開されアップデートを行いましたので、これでいろいろ一安心。

このルーターは何と言っても、テザリング使用時はBluetoothで24時間、Wi-Fiで12時間というバッテリーの持ちが海外出張時に非常に便利です。
周波数的には多くの国に対応しているので、モバイルルーター最強伝説と言われていた Aterm MR03LN が個人的にも本当に最強になったかも。

NEC Aterm MR03LN【OCN モバイル ONE マイクロSIM付きセット】クレドール付属 LTE対応 SIMフリーモバイルルーター 月額900円(税抜)~
NEC Aterm MR03LN【OCN モバイル ONE マイクロSIM付きセット】クレドール付属 LTE対応 SIMフリーモバイルルーター 月額900円(税抜)~

posted with Socialtunes

Facebookの写真は公開範囲を限定していても誰でも見ることができる

security

そう、URLさえわかればね。
セキュリティの講義のネタでよく話してるんですけど、以外と知られていないようなので。

公開範囲は 自分のみ

URLさえわかれば表示することが可能です。下記はそのURLです。
https://scontent-a.xx.fbcdn.net/hphotos-xpa1/t31.0-8/10363467_10203851587031224_5439857412795849561_o.jpg
そういう仕様っていうだけなんですけどね。URLは予測することが困難そうですし、あんまり悪用方法は思いつきません。以前のmixiもそういう仕様だったような気がする。
仲間内に限定公開とかしていて、その仲間の誰かが裏切って、あいつこんな写真公開してるぜ。とかぐらいだろうけど、それだったらURLを直リンクじゃなくてもいいですしね。

今夜つける HTTPレスポンスヘッダー （セキュリティ編）

security

Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。
囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。

X-Frame-Options

ブラウザが frame または iframe で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。

X-Frame-Options: SAMEORIGIN

  • DENY フレーム内にページを表示することを禁止（同じサイト内であっても禁止です）
  • SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可（他のサイトに禁止したい場合は主にこれを使用します）
  • ALLOW-FROM origin_uri 指定された生成元のみページを表示することを許可（特定のサイトのみに許可したい場合はこれを使用します）

X-Frame-Options レスポンスヘッダ - HTTP | MDN

X-Content-Type-Options

script または stylesheet で読み込むファイルの MIME タイプが正しい（許可された）ものと一致しない限りファイルを読み込みません。非HTMLをHTMLと見なすなど、コンテンツ内容の誤判定を利用した XSS などの攻撃を防ぐために用いられます。

X-Content-Type-Options: nosniff

機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
MIME タイプのセキュリティ リスクの軽減 (Windows)

X-XSS-Protection

ブラウザの XSSフィルターの機能を有効にし、XSS攻撃を防ぐために用いられます。

X-XSS-Protection: 1; mode=block

  • 0 XSSフィルターを無効
  • 1 XSSフィルターを有効（IE,Chromeの場合は 1; mode=block が使える）

2008/7/2 - IE8 Security Part IV: The XSS Filter
IE8 XSS Filterの仕様が微妙に変更されていた。 - 葉っぱ日記

Content-Security-Policy

外部のリソースを信頼できる生成元以外から読み込めないように制限することができます。XSSやデータインジェクション攻撃を検出して軽減することがあります。（ただし、設定によっては外部リソースを読み込めないようにすることによって、現在動作しているスクリプトが動かなくなる可能性があります。）
以前は、"X-Content-Security-Policy" というヘッダーフィールド名を使っていました。

Content-Security-Policy: default-src 'self'

  • default-src 'self' 同じオリジン（同じURLスキーム、ホスト、ポート番号）からはすべてのコンテンツを読み込むようにしたい場合
  • default-src 'self' *.example.com 指定したドメインとすべてのサブドメインからのコンテンツを許可したい場合

CSP (Content Security Policy) - Security MDN

X-Permitted-Cross-Domain-Policies

「crossdomain.xml 」（Flash コンテンツから別ドメインにあるファイルを読み込む際に必要になる設定を記述したポリシーファイル）をサイトのドキュメントルートに置くことができない場合などに、同様の効果を発揮することができます。

X-Permitted-Cross-Domain-Policies: master-only

  • master-only マスターポリシーファイル（ /crossdomain.xml）のみが許可される

Flash Player 9および10におけるポリシーファイル関連の変更点 | デベロッパーセンター

Strict-Transport-Security

指定されたサイトが常に HTTPS プロトコルを使ってアクセスするようにブラウザに指示します。HTTPのサイトからHTTPSにリダイレクトするより安全に誘導する方法です。

Strict-Transport-Security: max-age=31536000; includeSubDomains

  • max-age STSを有効にする期間、想定される再訪問の時間より遙かに長い目に設定した方がよい
  • includeSubDomains サブドメインにもルールを適用する。

HTTP Strict Transport Security - The Chromium Projects
HTTP Strict Transport Security - Security | MDN

Access-Control-Allow-Origin など CORS 関連

XMLHttpRequestを使って、他のドメインなどからリソースを取得したいクロスドメイン通信をしたい場合に指定します。使う場合には詳しくはCORS (Cross-Origin Resource Sharing)勧告などを参考にして下さい。

Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-TRICORDER
Access-Control-Max-Age: 1728000

上記は "http://www.example.com" からのクロスドメイン通信をしたい場合の設定で、当該リソースへの問い合わせには POST, GET, OPTIONS が実行可能なメソッド、カスタムヘッダーとして "X-TRICORDER" を付けたリクエストを送信し、プリフライトのレスポンスをキャッシュしていい時間が 1,728,00 秒だということを表しています。
HTTP access control (CORS) | MDN

X-Download-Options

ユーザーがダウンロードしたファイルを直接"開く"ことを防止したい場合に指定します。

X-Download-Options: noopen

  • noopen IE8以降ではユーザーはファイルを直接開くことができず、ローカルに保存することになります。ダウンロードのダイアログから"開く"がなくなります。

IE8 Security Part V: Comprehensive Protection - IEBlog - Site Home - MSDN Blogs

Set-Cookie

Cookie をセットします。サーバーがクライアントに対して状態管理を始める際などにさまざまな情報を伝えます。

Set-Cookie: name=value; secure; HttpOnly

  • secure HTTPSで通信している場合にのみ Cookie を送信する
  • HttpOnly Cookie ã‚’ JavaScript からアクセスできないようにする
  • path 属性は Cookie を送出するディレクトリを限定する指定ですが、回避する方法がありセキュリティ機構としては期待できません。
  • domain 属性は後方一致になります。明示的に複数ドメインに対して Cookie を送出する場合を除いて、この属性は設定しない方が安全です。

Cache-Control

ディレクティブと呼ばれるコマンドを指定することで、ブラウザのキャッシング動作を指定します。

Cache-Control: no-cache, no-store, must-revalidate

  • no-cache キャッシュサーバーはリソースを格納してはならない。また有効性の再確認なしではキャッシュを使用してはならない
  • no-store キャッシュはリクエスト・レスポンスの一部分をローカルストレージに保存してはならない
  • must-revalidate キャッシュ可能であるが、オリジンサーバーにリソースの再確認を要求する

pragma

HTTP/1.0との後方互換性のためだけに定義されているヘッダーフィールドで、本来はクライアントからのリクエストのみに使用されます。"Cache-Control: no-cache”と併記するとよいでしょう。

pragma: no-cache

  • no-cache クライアントがすべての中間サーバーに対して、キャッシュされた応答を望まないことを要求する

expires

リソースの有効期限の日時を伝えます。キャッシュされることを望まない場合には、Date ヘッダーフィールドの値と同じに設定するか、"-1"と設定します。

expires: -1

HOWTO Internet Explorer でキャッシュを無効にする

content-type

エンティティボディに含まれるオブジェクトのメディアタイプを伝えます。charsetでは文字セットを指定します。正しいメディアタイプの設定と、正しい文字コードを正しい表記で設定しましょう。

content-type: text/html;charset=utf-8

HTTPレスポンスヘッダーの設定の仕方

Apache で追加する場合には、httpd.conf の中で下記のモジュールが有効になっている必要があります。

  • LoadModule headers_module modules/mod_headers.so

常に表示する HTTP レスポンスヘッダーを追加するには、下記のように設定を行います。

Header set HeaderFieldName "value"

Header set X-XSS-Protection "1; mode=block”

タイトルは、拙著『今夜わかるHTTP』からですが、『HTTPの教科書』の方が新しい本です。また、セキュリティ編としてますがたぶん完結です。2に続くか…？
ご意見などお待ちしています。そのうち OWASP Japan の OWASP Night でも紹介するかも。

HTTPの教科書
HTTPの教科書
  • 発売元: 翔泳社
  • 価格: ï¿¥ 2,730
  • 発売日: 2013/05/25

posted with Socialtunes

追記

2013/12/01 "Access-Control-Allow-Origin"などCORS関連、"X-Download-Options"を追記しました。その他説明を微修正。コメント頂いた @hasegawayosuke さん、@kinugawamasato さん、@ockeghem さん、@hirayasu さんありがとうございます。

クレジットカードのセキュリティコードの保存は禁止

security

私も海外でよく使っていたイモトのWi-Fi「GLOBALDATA」のWebサーバーに不正アクセスがあり、調査の結果最大146,701件のクレジットカード情報を含む情報漏えいがあったことが判明しています。

リリースによると漏えいした情報は下記の通りと、この情報が揃えば大半のサイトのオンライン決済で利用できるでしょう。

  1. カード名義人名
  2. カード番号
  3. カード有効期限
  4. セキュリティコード
  5. お申込者住所

この中の「セキュリティコード」ですが、これはVISAやMasterでは「CVV」や「CV2」などと呼ばれている不正使用防止のための番号で、カードの裏面などに記載されているものです。
この「セキュリティコード」はカードに記載された番号を確認することで、カードの実物を持った所有者であることを確かめるセキュリティ対策なので、オンライン決済をしている加盟店のWebサーバーが保存してはいけません。


JCCA 日本クレジットカード協会が定める「新規インターネット加盟店におけるクレジットカード決済に係る本人認証導入による不正使用防止のためのガイドライン」にも「加盟店にてセキュリティコードを保存することは、禁止する。」という一文があります。

セキュリティコードを保存する実装にしているオンライン決済サイトはすぐにでも修正しましょう。また、上記ガイドラインにもある3Dセキュアなどの本人認証を導入すべきでしょう。


それにしても、エクスコムグローバル社は不正アクセスの件を4月23日から把握していて調査しているようですが、発表が5月27日とかなり遅いですね。

私も被害者ですが、ここまでの情報が漏えいするとクレジットカード番号は再発行になるかもしれませんね…。最近各所で漏えい事件の被害者としてヒットしていますが、そのたびにクレジットカード番号を変更とかになると、いろんなサイトの決済情報を変更しなければいけなくて本当にめんどうくさいですね。

Webに関わる人のための『HTTPの教科書』を発売

本 私

ひさびさの単著となる『HTTPの教科書』が2013年5月24日に発売になります。
内容はタイトルの通り、Webに関わる全ての人に捧げるHTTPを学ぶための教科書です。基礎を学びたい初心者の方から、机の上に置いてリファレンス的に使いたい方までを対象としています。

HTTPの教科書
HTTPの教科書
  • 発売元: 翔泳社
  • 価格: ï¿¥ 2,730
  • 発売日: 2013/05/25

posted with Socialtunes at 2013/05/21

HTTP関連の書籍は『今夜わかるHTTP (Network)』というタイトルの本を2004年に出しています。その頃からHTTP/1.1が主流であるというのは、今でも変わりませんがそれを取り巻く環境というのは変わりつつあります。
HTTPを学ぶ上での要点がわかりやすく、そして読みやすくなっております。前作のリニューアルっぽく感じるかと思いますが、9割以上は書き直しや追記しております。
また、レビューアとして、Masato Kinugawaさん、山崎圭吾さん、ネットエージェント株式会社はせがわようすけさんなどもお迎えして、よりよい一冊となっております。

以下は本書の目次になります。
第1章　Web とネットワークの基本を知ろう
1.1 Web はHTTP で見えている
1.2 HTTP はこうして生まれ育った
　1.2.1　Web は知識共用のために考案された
　1.2.2　Web が成長した時代
　1.2.3　進歩しないHTTP
1.3 ネットワークの基本はTCP/IP
　1.3.1　TCP/IP はプロトコル群
　1.3.2　階層で管理するTCP/IP
　1.3.3　TCP/IP の通信の流れ
1.4 HTTPと関係深いプロトコル IP・TCP・DNS
　1.4.1　配送を担当するIP
　1.4.2　信頼性を担当するTCP
1.5 名前解決を担当するDNS
1.6 それぞれとHTTP の関係
1.7 URIとURL
　1.7.1　URI はリソースの識別子
　1.7.2　URI のフォーマット
　
第2章　シンプルなプロトコルHTTP

続きを読む

コマンドラインから画面共有をONにする方法 for OS X Mountain Lion

Mac

システム環境設定からONにすればいいんですけど、なぜかシステム環境設定のロックが外せなくなったので、コマンドラインから各種設定変更を模索してみました。
コマンドラインから画面共有をONにするには、下記のコマンドをターミナルから実行します。

# sudo defaults write /var/db/launchd.db/com.apple.launchd/overrides.plist com.apple.screensharing -dict Disabled -bool false
# sudo launchctl load /System/Library/LaunchDaemons/com.apple.screensharing.plist

ssh とかでもONにできるので、人によっては便利かも。動作は OS X Mountain Lion（10.8.3） で確認しました。