2）実際の検査におけるZAPの設定と手順

前編の1)で「Standerd Mode」の状態で「クイックスタート」による検査を行ったが、これはあくまでもZAPの動作を確認するための手順で、実際の検査ではもう少し細かい指定をして検査を行う。
以下に実際の検査時の手順を説明する。

・ブラウザのプロキシを設定し、ブラウザで検査対象のページにアクセスする

前編の事前準備のところで解説した手順で、ZAPのプロキシ設定の調整（調整不要ならデフォルトで）と、ブラウザへのプロキシ設定を行う。

その状態で、検査対象とするサイトにアクセスすると、ZAP画面下部の「履歴」タブや左の「サイト」のところにアクセスしたサイトやURLが表示される。

・モードの変更
前編では「Standerd Mode」で検査を行ったが、実際の検査ではZAPの左上のmode設定を「Protected Mode」にして、意図しないページへの検査（攻撃）が走らないようにしながら検査を行う。

セミナーでは教わらなかったか私が聞き洩らしたか、で各モードの詳細が不明だったので調べたところ

・Safe Mode - 危険な処理が一切できないモード
・Protected Mode - スコープ内のURLにのみ危険な処理が行えるモード
・Standard Mode - 全URLに危険な処理が行えるモード

という感じのようでした。
「スコープ」というのは、コンテキストの一段上の概念で、コンテキストの設定画面で「In Scope」にチェックが入っているとそのコンテキストがスコープ内として扱われるようです。
コンテキスト設定画面の「In Scope」にはデフォルトでチェックが入っているので、本記事の手順では「コンテキストに入れていればスコープ内」になります。スコープについては他にも便利な使い方があったりするようなのですが、セミナーでは「スコープ」という概念の説明は、（多分）まだ出てきていないか省略されているため、本記事でも割愛します。

「Standerd Mode」の時に、ZAPを通してアクセスしたサイトをZAP上で右クリックすると、下図のように「攻撃」の各メニューが有効になっている。



この状態で検査を行うと、各URLに何の歯止めもなく攻撃できてしまうモードになっているため、誤操作や誤設定により意図しないページにまで検査を行ってしまう可能性がある。

それを防止するため、ZAPの左上のmode設定を「Protected Mode」にすることにより、「コンテキスト」に指定したページしか検査を行わないという設定を行う。

まず、ZAP左上のモードを「Protected Mode」にすると、コンテキストメニューの「攻撃」の各メニューはほとんどが無効とされてしまい、そのままでは検査（攻撃）をおこなうことができなくなる。



検査対象サイト/ページを指定するには、「サイト」もしくは「履歴」タブ内の検査対象にしたいサイトかページを右クリックし、コンテキストメニューより「include in Context」の「1」を選択。（この「1」はコンテキストの名称で、次に出てくるコンテキストの設定画面でちゃんとした名前に変更できる）



上で「1」を選択すると下図のウィンドウが開く。



ここで、「Include in Context」の「URL regexs」に「\Q」～「\E」の形の正規表現で、指定したURLが表示される。正規表現の「\Q」は「\E」までの正規表現メタ文字をエスケープするため、URLの「.」などが余計な意味を持たない。

「Include in Context」の「URL regexs」にURLを指定すると、ZAPの「サイト」タブのその正規表現にマッチするURLを持つページだけに二重丸「◎」のようなマークが付く。



この二重丸「◎」のようなマークが付いているページはコンテキストメニューの「攻撃」が有効になり、検査対象のページとなる。

ここで、本記事の手順を手元で確認中に気付いたのですが、Protected Modeの場合、対象となるページをコンテキストに入れるだけではなく、サイトのルートもコンテキストに入れないとうまく検査が走らないという挙動があるようです。（セミナーでも、単体のページだとうまく検査が動かず、急遽ルートからの検査に切り替えていたような気がします）

例えば、Protected Modeにした後で「http://127.0.0.1/test/test.php」だけを指定してコンテキストに入れて、このページに「◎」が付いている状態で自動検査を行おうとしても、一見、右クリックメニューで「攻撃」が有効になっているように見えて、実際に「Active Scan single URL」を選択しても検査が走らず、何もせずに止まってしまいます。
モードを「Standard Mode」に戻すか、「http://127.0.0.1/」をコンテキストに入れると、右クリック-「攻撃」-「Active Scan single URL」が動作するようです。
ただ、「◎」が付いていて、コンテキストメニューでも攻撃可能になっているのに、実際には攻撃が走らない、というのは直感に反するので、この挙動が正しいのか自分の設定ミスなのか、後日確認します。
ひとまず上記手順で検査が動かない場合、「サイトのルート」もコンテキストに入れる、という手順を追加して確認してみてください。

※2014/11/8追記
この現象について、私がいろいろZAP関連で参照させていただいているYuki（@yukisov）様のブログで検証がされていました。
Yuki様の調査によるとやはりバグっぽいようで、近いうちに出るZAP 2.4では修正されるようです。ありがとうございます。
OWASP ZAP 2.3 の Protected mode で Active Scan した時の問題について
(Web Application Security Memo)

・手動検査

OWASP ZAPを部分的に使って、手動検査を行うことも可能で、ここではその手順を解説する。

ブレークポイント

OWASP ZAPの右ペインの上部に「→」（全リクエストにブレークポイントセット）というアイコンがあり、このボタンを押下すると、ブラウザから発行されるPOSTやGETをZAPで中継する際に一時的に差し止めて、リクエストを改変してから発行することができる。

「Standard Mode」の場合、「→」（全リクエストにブレークポイントセット）を押下しただけで全てのリクエストにブレークポイントが設定されるが、「Protected Mode」の場合、ブレークポイントが有効になるのはコンテキスト内のURLに対してのみの模様。

ブレークが入るURLの場合、POSTやGETなどで当該URLに遷移する際、ZAPが反応してリクエストを差し止めてくれる。右上ペインの「ブレーク」タブが自動的に有効になり、上にリクエストヘッダ、下にリクエストボディが表示された状態になる。



パラメータやリクエストヘッダの内容を改変し、「サブミットして次のリクエストかレスポンスへ移動」「サブミットして次のブレークポイントへ移動」のどちらかのボタンを押下すると、改変したリクエストがサーバーに投げられ、レスポンスが戻ってくる。



サーバから戻ってきたレスポンスは、ZAPの右上の「レスポンス」タブで内容が見られるし、ブラウザにも表示される。
この手順でリクエストをいろいろ改変し、脆弱性を探すことができる。

Fuzzer

ブレークポイントを使ってパラメータを一つ一つ改変するのを手作業でやるのがつらい時がある。
OWASP ZAPには、ファジングを行う機能もあり、その機能を使って様々なパラメータを楽に試すことができる。（ファジングに使うパラメータリストを自前で作成することもできる。）

Fuzzerの設定を調整

「ツール」-「オプション」-「Fuzzer」で「並列スキャンスレッド数」を設定することができる。並列スレッド数を増やすと、ファジングを行うスレッドが増え、検査の進捗が早くなるが、サーバ及びクライアント側の負荷が高くなる。

また、この画面の「Add Custom fuzz File：」「ファイルを選択してください」というボタンを押下し、任意のテキストファイル（1行に1パラメータを記述したテキストファイル）を、自前のファジング用パラメータリストとしてZAPに設定することができる。



ここでFuzzerの動作を確認するため、試しに

fuzz1
fuzz2
fuzz3

という3行だけのテキストファイルを作って、「fuzztest.txt」という名前でデスクトップ等に保存し、これをZAPのカスタムファザーに設定してみる。（このファイルの一行が、1パラメータになる予定）

上図Options画面の「Add Custom fuzz File：」「ファイルを選択してください」というボタンを押下し、「fuzztest.txt」を指定する。（このファイルをZAPが格納するディレクトリの書き込み権限がないとエラーになることがある。その場合はエラーダイアログに表示されるディレクトリを作成し書き込み権限を追加してください）

ZAPの画面下部の履歴タブからファジングを行いたいリクエストを選択し、画面上部右の「リクエスト」タブを開き、ファジングを行いたい箇所をドラッグで選択してから右クリック-「Fuzz..」を選択。



「Fuzz」という子ウィンドウが開くので、「Fuzzカテゴリー：」のプルダウンを「Custom Fuzzers」にセットし、Fuzzリストにさきほど読み込ませたファイルが出てきていたら、それを選択。



「Fuzz」ボタンを押下すると、ZAPメインウィンドウの「Fuzzer」タブがアクティブになり、読み込ませたファイルに記載したパラメータが、ドラッグした箇所に設定されて次々とリクエストされる。



後は、レスポンスを見て回って脆弱性を示すようなレスポンスがないかチェックする。

結果一覧で、「Status」がHTTPステータスコード、「RTT(ms)」がレスポンス時間、「size」がレスポンスサイズ、「Fuzz」欄にリクエストしたパラメータが表示されるので、
特定のパラメータの時だけ
・HTTPステータスがおかしい
・他のパラメータの時と比べてレスポンスに時間がかかっている
・他のパラメータの時と比べてレスポンスサイズが大きい/小さい
などの変化を一覧で表示してくれるので、大変便利である。

また、「State」に「Refrected」とあると、リクエストしたパラメータが変更なく反射されたということを表すので、XSSの判定などに便利である。

・ZAPのアップデート
ZAPの「ヘルプ」-「アップデートのチェック」で、「Manege Add-ons」というウィンドウが開き、すでにZAPにインストールされているアドオンのアップデートがある場合には「Installed」タブに「Update」という印がついているので、右のチェックボックスをクリックして「Update Selected」ボタンでアップデートすることができる。



「MarketPlace」タブのほうでアドオンを追加することもでき、ここでstatusが「Release」になっている項目は、リリースレベルであると確認されたものなので追加しても安全とされる。

Betaレベルのアドオンでもベータ版であることを分かった上で追加することもでき、たとえば「SQLMap」がBetaレベルのアドオンとしてリストにあるので、追加してみると、スキャンポリシーのインジェクションカテゴリに「Advanced SQL Injection」という設定項目が増える。
（SQLMapは強力なツールなので、利用には気をつけたほうがよいようです。私は機能追加のテストとしてのみ入れ、ポリシーの項目が増えるのを確認した後アンインストールしました。）

---

参考資料

Translations / OWASPドキュメント翻訳
https://www.owasp.org/index.php/Japan#Completed
OWASP ZAP マニュアル Ver.2.1.0版 がある（日本語マニュアル）

zaproxy Google Code プロジェクト
https://code.google.com/p/zaproxy/
downloadsのところにUserGuideがある

（参考）別の方のOWASP ZAP ハンズオンセミナーマニュアル
OWASP ZAPのススメ （亀田 勇歩氏）
http://sssslide.com/speakerdeck.com/ykame/owasp-zapfalsesusume

ZAPをぶん回せ（境 稔氏、亀田 勇歩氏）
http://www.slideshare.net/minorsakai/130821-owasp-zed-attack-proxy

8月から毎月一度開催されている「セキュリティ診断（自分でしたら）いかんのか？（OWASP ZAPなら）ええんやで(^ ^)」という、OWASP ZAPハンズオンセミナーに第一回から第三回まで参加し、講師の方に全体的な内容のまとめ＆ブログ掲載の許可をいただいたので、これまで私がセミナーで学んだ内容を全部まとめてみます。
時系列に沿ったまとめではなく、セミナーの内容を頭から自習できるような一本の記事に再構成しました。

ブログ記事へのまとめ・編集による間違いやミスの混入の責任は私にあります。 また、一部、セミナーの時にとったメモを見ながら不明点を手元で確かめて書いている箇所があります。

リンク
セミナーの案内ページ（セキュリティ診断手法コミュニティページ）
セキュリティ診断 勉強会
http://security-testing.doorkeeper.jp/
このページにこれまでのセミナーの案内ページへのリンクがあります。

第二回ハンズオンセミナー 資料(Slideshare)
http://www.slideshare.net/nilfigo/sec-test-zap00220140925-40667816

第三回ハンズオンセミナー 資料(Slideshare)
http://www.slideshare.net/nilfigo/sec-test-zap00320141024-40802525

・セミナーの事前準備
ハンズオンセミナーなので、OWASP ZAPが動く環境が必要です。
自習用に環境の整え方を記載しておきます。

準備1: OWASP ZAPインストール
各環境用（win,mac,linux版がある）のOWASP ZAPをこのサイト からダウンロードしてインストール。（要JRE）
本記事ではWindows版ZAPバージョン2.3.1に基づいて解説します。

準備2:ブラウザのプロキシ設定
OWASP ZAPをローカルプロキシとして設定する。

OWASP ZAPは起動するとデフォルトで8080ポートでプロキシとして動作し始めるが、8080ポートは他サービスで利用されている可能性が高いポートなので、他とぶつかる場合は「ツール」-「オプション」の「ローカル・プロキシ」でポートを変更する。



ここで、ホスト名のほうも変更できるが、これはhostsなどでローカルホスト名が変わっている場合などに設定を行う。

そして、利用するブラウザのプロキシ設定を、OWASP ZAPのローカルプロキシのポートに設定する。 （http, https 両方を同じポートに設定する必要がある。）

Firefoxの場合は「ツール」-「オプション」-「詳細」-「接続設定」で下図のように設定する。


講師の松本さんによると、FirefoxであればFoxyProxyというプラグインが、Fiddlerや、ZAP、通常接続などを手軽に切り替えられるのでお勧めとのこと。

プロキシ設定に成功していれば、ブラウザで任意のサイトにアクセスすることで、OWASP ZAPの「サイト」や「履歴」のところにサイトやアクセスログが記録される。

準備3:検査可能なサイトの用意

セミナーでは講師の方が自分のパソコンに「Mutillidae II」という、OWASPで配布している 「やられ役サイト」を立ち上げて、セミナー参加者が一斉にそのアドレスに攻撃（検査）を仕掛ける、という形式だった。

本記事で自習する場合、手順確認用に、何か検査可能な（=壊れても大量アクセスしても他人に迷惑をかけないような）任意のローカルWEBアプリを準備する必要がある。（リモートにあるWEBアプリでは、検査により途中のネットワークに負荷がかかってしまう恐れがあるのでローカルネットワーク内が望ましい）

「Mutillidae II」はWindowsのXAMPP環境でセットアップしてみた限りでは、「Mutillidae II」のZIPアーカイブを解凍して出てきたディレクトリをXAMPPのhtdocs下に置いて、MySQL+Apache有効化してアクセスしただけで使えるようになるので、それを利用してもよい。（本セミナーでは目下「Mutillidae II」に依存した手順は出てきていないので、自分の管理下にある検査可能なサイトがある場合はそのサイトで代用しても良い）

「Mutillidae II」ダウンロードサイトはこちら。
http://sourceforge.net/projects/mutillidae/

※「Mutillidae」って正しくは何て読むのだろう？ と思って調べたところ「ミューティリダエ」というのが正しい読み方っぽいです。
発音→http://ja.forvo.com/word/mutillidae/
（私は「ムッチリダエ」で定着してしまったのでこの綴りを書くときは必ず「ムッチリダエ」と内心で読んでいますが）

---

以下はセミナーの内容です。

・OWASP ZAP って何？
OWASP（The Open Web Application Security Project）が開発および管理しているセキュリティ診断ツール。オープンソースで、世界中のセキュリティエンジニアが開発に加わっている。

・ハンズオンセミナー開催の理由
講師の松本さんが熱い思いを語っておられました。
セキュリティ会社の人間が自前での検査方法をレクチャーするのは、自分の利益を減らすような行為だが、あまりにも今のWEBアプリのセキュリティの状況が悪すぎるので、診断方法を公開して、開発者が自ら検査を行えるようにセミナーを開くことにした、とのことでした。

---

・セミナー本編
1）「クイックスタート」による検査

まずOWASP ZAPの動きを見るため、一番手軽な「クイックスタート」での検査を行ってみる。
「クイックスタート」での検査では、URL欄に攻撃対象のURLを指定し、ボタンを押すと、自動でリンクをたどってクロールを行い、OWASP ZAPに備わっているさまざまな検査項目を自動で実施してくれる。
これは手軽に検査できるが、微調整ができないので、実際の診断ではあまり使わない。
しかし、クローリング-自動的なスキャン-検出結果出力というZAPの一通りの手順を試すことができるため、ZAPの機能を一通り見ることができる。

「クイックスタート」での検査手順は、

ZAPのウィンドウ左上のプルダウンの値が「Standard Mode」である状態（起動直後のデフォルトではそうなっている）で

↓
クイックスタートタブの「URL」欄に、アタックしてよいURLを指定して「攻撃」ボタン押下

↓
最初にスパイダー検索が走る（ZAPウィンドウ下部の「スパイダー検索」タブが自動的にアクティブになり、クロールの履歴が表示される）
↓
次に、OWASP ZAPに設定されているポリシーにより
・静的スキャン
・動的スキャン
が実施され（「動的スキャン」タブが自動的にアクティブになる）、スキャンが終わると結果が表示される。

ここでのプチテクニックとして、分かりにくいが「動的スキャン」タブのプログレスバーの左隣に、グラフのようなアイコンがあり、これを押下すると、現在の検査の進捗が別ウィンドウで表示される。





カテゴリ別にどのくらい検査が進んでいるかがプログレスバーで表示される。
「status」欄にある再生一時停止ボタンのようなマークをクリックすると、そのジャンルの検査をそこで終えて次のカテゴリの検査に移る。上の画面は「パストラバーサル」の検査を途中でスキップしたときのキャプチャ。

自動検査が終わると、「アラート」タブに切り替わって見つかった脆弱性が表示される。

※ここで、twitterなどの外部サイトへリンクがある場合、勝手にそっちのサイトまでクロールして検査してしまうのではないかと不安になる方もいると思われるが、クイックスタートでURLを指定した場合は、ドメインレベルで違うサイトにまでは検査は行わないようになっており、例えば、URLに「http://127.0.0.1/mutillidae/」を指定した場合、Mutillidaeからリンクが貼られているhttp://www.owasp.org、http://sourceforge.net、http://www.kali.orgなどのページは、クロール結果に出ては来るが「OUT_OF_SCOPE」（スコープ外）として表示される。



前方一致ではなくあくまでドメインレベルで歯止めをかけているだけらしく、探査するディレクトリを制限したくて「http://127.0.0.1/mutillidae/xxx/」を指定しても、上のディレクトリは探査対象に入るようで、「http://127.0.0.1/mutillidae/」や「http://127.0.0.1」は対象になってしまう。

スキャンポリシー

OWASP ZAPは、自動検査の強度(Strength)や閾値（Threshold）を設定することができる。
「メニュー」-「スキャンポリシー」を選択すると、別ウィンドウで、スキャンポリシーの設定画面が開く。ここでの設定値に基づいて、自動検査の強度が決定される。



各カテゴリごとに「Threshold」「Strength」という設定項目がついている。

それぞれ選べる設定値は次のとおり。


「Threshold」を「OFF」にすると、そのカテゴリの検査を行わないようにできる。「LOW」～「HIGH」についてはパラメータの多さなどの調整になるとのこと。

「Strength」については、具体的な意味をセミナーで質問するのを忘れてしまったが、ZAPのヘルプによると「strength (the number of attacks they perform)」と書いてある箇所があるので、攻撃の回数を表す模様。「insane」にするとダメージが大きい模様（insaneってどういう意味だっけ？　と思って辞書引いてみたら「正気でない、狂気の」とあった）。

「Threshold」「Strength」は、OSSの開発のプロセスでバランス調整が行われているのが期待されるので、基本はDefaultで良い。
また、各カテゴリを選択すると、その内部でも細かく検査項目が分かれており、その項目ごとに「Threshold」「Strength」を個別で設定することができ、そうやってカスタマイズしたスキャンポリシーに名前をつけて保存することも可能。

カテゴリ内の設定項目の例）「インジェクション」の設定項目


「Passive」カテゴリだけは「Threshold」の選択項目がなく、OFFにできないが、これはいわゆる「静的スキャン（受動的スキャン）」だからで、通常のアクセスログから分かるような脆弱性（が疑われる箇所）を指摘するものなので、OFFにする必然性がないからと思われる。（静的スキャンはスパイダーによるクロール時に既に行われてしまう模様）

ここで、特定のカテゴリのみDefault、他のカテゴリを全部OFFにすると、例えばディレクトリトラバーサルのみ、SQLインジェクションのみ、という検査を走らせることも可能になる。

※セミナーで紹介されてはいないのですが、OWASP ZAPのスキャンポリシーの検査項目については、下記 Yuki 氏 のサイトにかなり詳しい説明があったので、参考資料としてリンクしておきます。
OWASP ZAP スキャンポリシーの検査項目一覧(Release版)（Web Application Security Memo）

→OWASP ZAP ハンズオンセミナー 「セキュリティ診断（自分でしたら）いかんのか？（OWASP ZAPなら）ええんやで(^ ^)」第一回～第三回の内容まとめ・後編へ続く

本ブログは以前fc2ブログで運営していたのですが、今後はこちらで記事を書いていきます。
（旧ブログURL：http://securitymemo.blog.fc2.com/ WEB系情報セキュリティ学習メモ）
ブクマの変更等、お手数ですがよろしくお願いいたします。

mixiの脆弱性報告制度の総括記事を書こうと思い、報告した脆弱性の評価が確定するのを待っていたのだが、最後の一件の評価がなかなか戻って来ないため問い合わせたところ、修正方法を含め時間がかかる、との事だった。

そのため、一件評価が未確定のものが残ってはいるが、評価が出るのを待っていたら遅くなりそうなので、先に今回の脆弱性報告制度に参加した感想を書いてしまおうと思う。

報酬

報告した脆弱性：15件
評価された脆弱性：4件
（評価が確定していないものが1件残っている）

いただいた報酬：現時点までの合計 ￥475,000（Amazonギフト）

感想

よかった点
・報酬が高額
・「mixi」という大手企業の色々なサービスを思う存分検査できた点。超楽しかった。ずっと続けたいぐらい。

悪かった点
・参加者への応対
・脆弱性の評価の判断基準の不明瞭さ

mixiさんの制度運用について思うこと

私が以前書いた記事のせいもあって、mixiさんに批判が集まる形になっているが、とりあえず参加者として思うところを少し述べてみようと思う。

私が報酬を頂いた脆弱性を発見したサイトは、mixiアンケート、youbride、YYC、ショッパーズアイだが、サイトの規模に関わらず、mixiさんからは高額な報酬（10～12.5万円のAmazonギフト）をいただくことができた。

特に、「ショッパーズアイ」というサイトはmixi本体と比べるとかなり参加者の少ない小規模なサイトだと思うが、このサイトのXSSであっても、特にケチるようなそぶりもなく、公式ルールの「脆弱性と報酬額の例」のXSSの場合の金額、12.5万円（Amazonギフト）が支払われた。

mixiさんが本当にできる限り報酬をケチりたいなら、「このサイトはユーザー数がmixi本体と比べるとかなり少なく、影響範囲も小さいので、報酬は1万円で」みたいなケチり方もできたと思うし、そのほうが批判の対象にもなりにくく、スマートだったと思う。
でもそれをしなかったので、運営側は必ずしも「何が何でも賞金をケチりたい」というのではなかったように思う。

しかし、超高額報酬が出てしまった際には、賞金支払いをケチっているかのように見える挙動があり、疑念を打ち消すような判断基準の情報開示もなかったので、炎上して叩かれてしまったように見える。

やはり、この手の脆弱性発見コンテストでは「企業側の評価基準の透明化」が絶対的に必要なのだろうと思う。
下手に「自社の基準で」でやってしまうと、どうしても「有益な脆弱性報告をただ取りされた」的なトラブルが起こってしまう気がする。

（サイボウズの脆弱性発見コンテストでは、 脆弱性はCVSS v2 を用いて評価となっていた。例えばこのように客観的な指標を導入するのも手なのではないかと思った）

---

あと、別件で指摘したいのが、「脆弱性に賞金を出す制度」というのは、本来、クラッカーが発見した脆弱性を悪用したりその手のマーケットで販売したりするのを防ぐために企業が脆弱性情報をクラッカーから買い取るという趣旨があるものだが、今回、私の発見した例の脆弱性にしろ、このブログの方の発見した脆弱性にしろ、すごい危険性がある状態を発見し、それを悪用せずに企業に情報を渡したのに、企業側が「悪用しなかった」ということに対する対価を払わなかった（ように見えた）。この点は良くなかったと思う。

危険な脆弱性を発見して報告しても正当な対価がもらえないなら、今後は報告なんかせずに見つけた脆弱性を直接悪用するか、ブラックマーケットに売った方がいいや、となってしまうのでよろしくないと思う。（私は逮捕されたくないので仮に全く利益が得られなくてもIPAとかに報告してしまうと思いますが、一般論として）

既知であろうが同様の脆弱性が他にあろうが、「脆弱性を悪用しなかった」という点に対しての報酬はいくばくか払った方が良かったように思う。

まとめ：「次回に期待」

mixiさんの脆弱性報告制度は、自社および子会社の運営するサイトの本番環境を脆弱性検査希望者に全公開するという「こんなに緩くていいんですか？？」という荒っぽさがあり、たぶん「攻撃なんて毎日腐るほど来ているのだから、脆弱性コンテストに本番環境使っても大丈夫やろ」というノリの豪胆な人がmixiの中にいたのだと思う。

それで、そういうノリでとりあえず開始してみたところ、起こる事態の想定なども甘いままボロが出てしまった、というところがあったのではないかと思う。（例えば対応人員足りなくて評価に時間かかったり）

ただ、その大雑把さのおかげで私としてはmixiという大手企業が運営する多数のサイト（本番運用中）をブロックや通報を恐れずに検査することができ、普通に脆弱性検査の体験学習として面白かったし、ためになった。

mixiさんの試みは、試み自体としては非常に良い試みだと思ったし、今後どんどんほかの企業も同じような試みをやってほしいと思った。

私としては、あまり国内でやられていない「高額賞金の脆弱性報告制度」という冒険を、本番環境で「えいや」でやってしまったmixiさんの男気は評価されるべきだと思う。

ただちょっと運用面では色々まずかったようにも思うので、次回やるときはそのあたりを改善してほしいと思う。

余談：Amazonギフトについて

今回のmixiの脆弱性報告制度の賞金はAmazonギフトで支払われた。

些末な事ながら、Amazonギフトは１～数万円程度の報酬には向くと思うが、それ以上の高額賞金には全く向かないと思う。
大きな理由としてはAmazonギフトには有効期限があり（一年間 有効期限はギフト券の券種によって一～三年のものがあるようだが、今回mixiさんが賞金の支払いに使ったのは有効期限一年の券種だった）、その間に使い切らないと無効になってしまうからだ。

高額になればなるほど、その一年縛りがきつくなるため、大金もらったのに素直に喜べず、一年以内に使い切るために何を買えばいいのかで悩まないといけないという、ジョジョのどこかのシーンみたいなことになってしまい、大金いただいたことはありがたいのに、一年縛りのせいで悩みが発生してしまう。（頂き物にたいして文句を付けるのは勇気がいるが、たぶん今回mixiさんに高額賞金もらった人はみんなこれで悩んでると思う）
この手のコンテストの賞金は、2～3万円以上の額になる場合は現金で支払った方が良いのではと思った。

---

※5/17追記：
Amazonギフトの有効期限は延長できるという噂を聞いたので、Amazonカスタマーサービスに電話してAmazonギフトの仕様について聞いてみた。
ネット上の情報では申請すれば簡単に期限を延長できるという感じだったが、実際にサポートに聞いてみると、あくまでも特例措置で、必ずしもホイホイやってくれるようなものでもないようだ。
オペレーターの方によると、

・Amazonギフト券の残高がある状態で有効期限を迎えてしまうと残高も無効になる
・ギフト券の有効期限の延長は、お客様の事情をお伺いして、上司の判断を仰ぐ必要がある。通常のサービスではなく特例的な対応のため、申請していただいても確実に延長が約束できるわけではない
・延長が可能だった場合でも原則として一年しか延長できない（それ以上延長できるケースがあるかどうかは不明）

とのことだった。
というわけでやはりAmazonギフトは、原則として有効期限内に使い切らないといけないものであるようだ。

mixi脆弱性報告制度で報告した脆弱性のうち、報告したけど評価対象外になったものをまとめます。

報告したけど評価対象外だった脆弱性

1.ショッパーズアイ コードインジェクション

報告日：2014年3月31日
評価結果連絡：2014年4月8日 弊社において既知の脆弱性であると判断、よって脆弱性報告制度の対象外

※追記：この脆弱性は現在は対応済みです。mixiさんに問い合わせて脆弱性対応済みであることを確認してから記事を公開しました。

※2014.4.16 23:00 本記事の反響がやたら大きくなってしまったのでコメントを追加します。
もともと本エントリはmixiさんの不正な判定を告発するとかそういう意図は全くなく、「超面白かった脆弱性検査の記録」という以上の意味はありませんでした。（あとこんだけ検査したんだぜーという自己PRと）

私がこの脆弱性を報告したのは、報告制度の最終日(3/31）間際だったので、最後の駆け込みで大量の報告が上げられていて、mixiさんのマンパワーが単純に足りなかった状況だったのではないかと思います。
また、報告日時が日曜深夜だったので、週末に誰かが（私より先に）同様の脆弱性の報告を上げていたけど、月曜まではmixiさんに認識されていなかった、というようなことだったのかもしれません。（推定ですが）

いずれにせよ、mixiさんは私の他の脆弱性報告では高額な賞金をルール通りきっちり払ってくれてますので、この件だけ出し惜しみするとは思えないため、｢既知｣というのが具体的にどういう状況だったのか分からないながらも、正当な判断だったんだろうなと思っています。

報告内容：
ショッパーズアイのマイページ
https://www.shoppers-eye.jp/mypage/recruit
の「募集中の調査案件」の検索フォームで、「キーワード」欄のエスケープがされておらず、プログラムに任意のコードを差し込めるコードインジェクション脆弱性があり、system関数によりOSコマンドがコールできた。



現象の詳細としては、このキーワード欄でシングルクォート入力時の挙動がおかしく、下記のような挙動が見られた。

'+ → システムエラー
'+' → OK （結果0件）
'+'a → OK かつ 検索画面のキーワードの内容が「a」になる
'+'1'+' → OK かつ 検索画面のキーワードの内容が「1」になる

また、下記のような挙動があることも分かった。

'+sleep(10)+' → 時間がかかった上でシステムエラー
'+sleep(100)+' → かなり時間がかかった上でタイムアウトエラー

当初これはSQLインジェクションだと思っていて、何らかのDBのsleep関数が呼ばれていると思い、色々なデータベースの関数を試して見たが、どうも他に呼べるデータベース系の関数がないので、もしや・・・と思い、下記を試したところ、20秒sleepをしているような挙動があった。

'+system("/bin/sleep 20")+'

これはSQLインジェクションではなくてコードインジェクションということが分かったが、sleepだと決め手に欠けるので、システムに害をもたらさないで、確実にOSコマンドが呼ばれていることを証明するには・・・と考えて下記入力を試したところ、「MailSubject」というタイトルの「1」という内容のメールが指定のメールアドレスに届いた。
そのため確実にsystem関数の実行が行われているということで報告した。

'+system("/bin/echo 1 | /bin/mail -s MailSubject <自分のメールアドレス>")+'

この脆弱性は、mixi脆弱性報告制度の一番高額な例（「リモートから、ウェブサーバー上で、任意のコードが実行可能」）に当てはまるので、かなり緊張しながら結果を待ったが「弊社において既知の脆弱性のため対象外」とのことだった。

2.ショッパーズアイ DOS攻撃を容易にする仕様

報告日：2014年3月31日
評価結果連絡：2014年4月8日 弊社において既知の脆弱性であると判断、よって脆弱性報告制度の対象外

報告内容：
ショッパーズアイの振り込み履歴のページにて

https://www.shoppers-eye.jp/mypage/history?pp=50&year=2014

というURLのyearパラメータをいじって過去の年にすると、ページ上のプルダウンでの選択できる年が増えるが、これに下限が設定されていないため、例えば

https://www.shoppers-eye.jp/mypage/history?pp=50&year=-9999

などのように指定すると、-9999年～2014年までのプルダウンが生成される仕様だった。


ここで、巨大なマイナス値

https://www.shoppers-eye.jp/mypage/history?pp=50&year=-999999999999999999999999999999999999999999999999999

を指定したところ、長くレスポンスを待たされた後、「proxy error」の画面になったので、おそらくサーバ側処理で大量のプルダウンリストが生成されて落ちてしまったと思われたため、DOS攻撃を容易にする仕様として報告したが、やはり「既知の脆弱性と判断」よって「報告制度の対象外」だった。

mixi脆弱性報告制度で報告した脆弱性をまとめてみます。

※以前報告した脆弱性4件の解説はこちらにあります。
（書いたときに脆弱性の詳細をぼかしすぎたので明確な形に書き直しました。）
今回はそれ以後報告した脆弱性についてです。

今回評価された脆弱性報告

1.youbride 認証が不十分なバグ

報告日：2014年3月1日
対応完了連絡：2014年3月18日
評価結果連絡：2014年3月24日 報酬額 ￥125,000（Amazonギフト）

mixiの子会社、株式会社Diverseが運営している「youbride」という婚活支援サイトで、登録した会員情報の変更メニューで、メールアドレス変更画面のパスワード入力欄が、実際には機能していなかった。

メールアドレス欄に、任意の変更先メールアドレスを入れ、パスワード欄に正しいパスワードでなく、「a」とか「1」とか適当な値を入れても、変更先のメールアドレスに、メアド変更用リンクが書いてあるメールが送信される仕様だった。



このページはパスワードによる認証でCSRFを防ぐ仕組みだったが、そのパスワード認証が機能していないため、メアド変更画面へPOSTを行うCSRF攻撃で、youbrideにログイン中のユーザのアカウントから、攻撃者の指定した任意のメアドに、メールアドレス変更確認メールを送信させることが可能となってしまっていた。
その後、入手したメアド変更用URLを何らかの手段で再度そのユーザーに踏ませられれば、その人のメアド（=ログインID）が変更できてしまい、その後攻撃者がパスワード再設定を行うことでアカウントを乗っ取ることが可能だった。（IDが攻撃者のメアドに変わっているから、パスワード再設定用アドレスはそのメアドに送られてくる）

URLをユーザーに踏ませる方法としては、たとえば上述の不正なPOSTを行うページの裏で素早くメール受信処理をしてメールアドレス変更URLに遷移するような攻撃用スクリプトを書く、ソーシャルな手段でメール等で踏ませる、などがあると思うが、報告ではそこまでの実証はせず、可能性を示唆したのみで報告した。

2.YYCの特定のURLでXSS

報告日：2014年3月14日
対応完了連絡：2014年4月7日
評価結果連絡：2014年4月9日 報酬額 ￥125,000（Amazonギフト）

mixiさんから最初にいただいた報奨金（前回のやつ）でwin7マシンとAndroidスマートフォンを購入したので、勉強も兼ねてmixiの開発したAndroidアプリの通信をPC上のFiddlerで覗くということをやってみた。

大半のアプリはSSLで通信をしており、不正な証明書も認めてくれなかったので通信を覗き見ることはできなかった。（Androidアプリの脆弱性検査の手法がよく分からない。今後の課題）

しかし、これも株式会社Diverseがやっている出会い応援サイト「YYC」のアプリが、ある通信だけはHTTPで特定のURLにアクセスを行っていて、そのURLを調べて見たところ、POST値をエコーバックする箇所があったので、試して見たところIEのコンテンツ解釈でHTMLと誤認させてのXSSを仕掛けることが可能だった。

問題のあったURL：
http://yyc.co.jp/api/app/member/boot_app

このページにアクセスすると、下記のようにJSON形式でレスポンスが返ってくるが、「.apikey」というPOST値があると、レスポンスのapikeyの値にそのまま反映される仕様だった。

{"response":{"success":false,"accept_time":"2014-04-14 01:28:15","errors":["error.no_api_key"],"code":"-4","apikey":"<ここに値が反映される>"}}

レスポンスヘッダに「Content-Type: application/json;」が付いているのでIE以外のブラウザではHTMLタグがタグとして解釈されない形だったが、IEはIE6～8でデフォルト設定だとContent-Typeヘッダを無視してコンテンツの内容を解釈するので、下記のようにpathinfoとして「a.html」を付けてIEがHTMLだと誤認するようにし、「.apikey」にscriptタグを投げ込むようなHTMLを書いてIETesterのIE8でPOSTしたところ、スクリプトが有効に動作したので報告した。（IETesterのIE6とIE8で動作を確認した）

<form method=post action="http://yyc.co.jp/api/app/member/boot_app/a.html">
<input type=text name=".apikey" value="yycapp&lt;script&gt;document.write(document.cookie);alert(1);&lt;/script&gt;">
<input type=submit name="submok" value="submit">
</form>

3.ショッパーズアイ メールのテスト送信機能のXSS

報告日：2014年3月26日
対応完了連絡：2014年4月8日
評価結果連絡：2014年4月9日 報酬額 ￥125,000（Amazonギフト）

ミステリーショッパー事業の「ショッパーズアイ」の会員情報変更画面の中に、自分のメールアドレスを変更する画面があり、そこに「テスト送信」というリンクがあり、そこで指定のメールアドレスにテストメールを送信できる仕組みになっている。

テスト送信の画面は、普通の遷移ではパラメータもPOST値も何もない形だったが、いったんテストメールを送信した後に、画面をリロードすると、何故かメールアドレスがGETパラメータとしてURLに付き（そういうLocationヘッダが発行される）、外部からメールアドレスが自由に指定できるようになり、しかもパラメータで渡したメールアドレスが全くエスケープされていなかったので、XSSが可能だった。

問題のあったURL：
http://www.shoppers-eye.jp/mypage/user/testmail

テストメールを一度送信し終わった後にリロードすると下記のようにURLが変化した。

http://www.shoppers-eye.jp/mypage/user/testmail?email=<登録したメールアドレス>&mail_type=pc

これを下記のように変化させてアクセスしたところ、普通に画面上でスクリプトが実行された。

http://www.shoppers-eye.jp/mypage/user/testmail?email=<script>alert(1)</script>&mail_type=pc

---

その他現在確認中のものなど。

※「XXXX」になってる箇所は、確認取れ次第更新していきます。

「報告制度の範囲外」ということで無効になった脆弱性報告（いつの間にか報告制度の対象外になってたやつ）

対応未確認なので公表できない。mixiさんに対応が完了したか確認中。対応済みであれば詳細公開。

• XXXX にてオープンリダイレクタ脆弱性 （報告日：2013年12月8日）
• XXXX にてdataストリームによるXSS脆弱性 （報告日：2013年12月8日）
• XXXX のXXX機能のCSRF （報告日：2014年3月24日）

「既知の脆弱性」ということで無効になった脆弱性報告

問い合わせたら対応済みとの事だったので、次のエントリで詳細書きました。

現在対応待ち

mixiさんに報告して対応連絡がまだ来ていないもの。評価未確定なので報奨金の可能性が残っている。対応未確認なので公表できない。

・XXXX でDOS攻撃を容易にする仕様（システムに大きい負荷を簡単にかけられる仕様） （報告日：2014年1月14日） → いったん対応報告来たけど報告時の説明が悪く漏れがあったので再対応していただいている
・XXXX オープンリダイレクタ脆弱性 （報告日：2014年3月17日）
・XXXX ソーシャルな手順によるXSS（セルフXSS） （報告日：2014年3月30日）


現状こんな感じ。

最近のEC-CUBEの脆弱性で私が発見したやつが結構あるので、ロックオン様が公開しているEC-CUBEの脆弱性リストに発見者とJVN iPediaとIPA注意喚起へのリンクを加筆して一覧表を作ってみました。

基本自分用資料ですが、ロックオン社の脆弱性情報とJVN iPediaとの対応表になっているので、CVE等を調べたいときに使えるかもしれません。

下表の★マークが私の見つけた脆弱性です。
参考：EC-CUBE脆弱性リスト（ロックオン公式）
（2013-05-22より前の脆弱性については私が関わっていないので省略します）

・EC-CUBEプラグインの脆弱性


（プラグインは私はアイネクシオ様のプラグイン調査のページでDL数が多いものを対象に調べています。）

私が見つけたEC-CUBEの脆弱性は影響の大きいものも数件あるので、世間で広く使われている（公式HPによると推定20,000店舗以上で稼働中）EC-CUBEの安全性にかなり貢献できたのではないかと思います。

いずれ時期を見てそれなりの情報を公開しようとは考えておりますので、この記事を読んだ時点でまだ対応されていない脆弱性が残っているEC-CUBEをご利用の場合は、なるべく早めにご対応ください。
（脆弱性のおおまかな情報や修正パッチの解析などにより再現手段が解明され攻撃が発生する可能性もあります）

* 2016/08/12 最新の状況に合わせて更新しました