Flashの解析はそこまで深くできる訳ではないのですが、オープンリダイレクタ見つけられるくらいの解析はできるようになったので、手順のメモをここに書いておきます。

1. Flashデコンパイラのインストール

Flashの解析に必要なFlashデコンパイラ JPEXS Free Flash Decompilerを下記よりダウンロードしてインストール
http://www.free-decompiler.com/flash/
（要JRE 1.7以上）

※デスクトップのショートカット、もしくはインストールフォルダのffdec.exeを起動して
>Error: Could not create the Java Virtual Machine.
とか出て起動しない場合、インストールフォルダのffdec.batから起動すると起動できる

※Flashのswfを解析することができるデコンパイラは他にもあるが（flareとか）、筆者があまり使ったことがないので省略。

2.検査対象swfを入手してJPEXS Free Flash Decompilerにドラッグドロップ

swfが解析され、script/の下に抽出されたActionScriptがソースごとに表示される

3.FlashVarsを利用している箇所の処理を見る

adobeの公式ヘルプページ
http://helpx.adobe.com/jp/flash/kb/228618.html

ここに書いてあるサンプルコード

<param name="movie" value="myFlashMovie.swf" />
<param name=FlashVars value="myVariable=Hello%20World&mySecondVariable=Goodbye" />

こういうタグをHTML上に書くことで、Flash側へHTMLから値を渡すことができるのだけれど（FlashVarsのvalueがflashに渡されるパラメータ）、このFlashVarsの扱いがswf内でうまくなされていなくて、脆弱性の原因になるケースがある。（外部から任意の値が渡されることを全く考慮していないで重要な処理をしているケースが多い）

外部から値を受け取るswfの場合、解析したswfのActionScriptのどこかに

var temp:String = loaderInfo.parameters["<FlashVars変数名>"];

のような形でHTMLで指定したパラメータの値がActionScript内で利用されている箇所があるはずなので、デコンパイラで抽出したソース上でパラメータ名を検索して見つけ出す。※loaderInfo.parametersを参照する書き方はこれ以外にもあるが、要はFlashVarsの変数名で検索してどう使われるか追っかければ良い。

（JPEXS Free Flash Decompilerの場合、検索はTools->TextSearch。ctrl + fで出てくる検索メニューは別物なので注意）

Flashは、HTML上のタグだけではなく、GETパラメータとして渡された値もFlashVarsとして受け取ってしまうため、swfにパラメータをつけてコールする形にすれば任意のFlashVarsを渡してFlashを動作させることができてしまう。

そのため、例えば、外部から渡された値がノーチェックで

navigateToURL(new URLRequest(<FlashVars由来の値>));

こんな感じで使われていたら、navigateToURLは指定したURLに遷移する関数なので、そこに外部から任意のURLを指定することができるため、オープンリダイレクタ脆弱性を見つけたことになる。

上の例でいくと

http://..../myFlashMovie.swf?<FlashVars変数名>=http://evilsite.test.attack.xx

みたいな形でコールすれば、navigateToURL関数に怪しいURL（http://evilsite.test.attack.xx）を渡して遷移させることができてしまう。

---

その他、オープンリダイレクタ以外のいろいろな攻撃方法・見るべきポイントについてはmala氏の下記の記事に情報が載っている。

Flash Based XSSについて その2 解析と発見と修正方法（金利0無利息キャッシング – キャッシングできます）
http://subtech.g.hatena.ne.jp/mala/20130604/1370328780

Flashからjsを呼び出すために使う ExtarnalInterface.call() 関数の脆弱性に関してはMasato Kinugawa氏の下記スライドもすごく参考になる。

見つけた脆弱性について(cybozu.com Security Challenge)
http://www.slideshare.net/masatokinugawa/cybozu-security-challenge

EC-CUBEで脆弱性を見つけたり、mixiの脆弱性報告制度で成果を挙げたりしたせいか、「どうやって脆弱性を見つけてるんですか？」という質問をされることが時折あり、一応手順は説明するのですが、いつも口頭で細かくは説明できなくて申し訳ないので、自分のやり方をまとめてこのブログにアップしておきます。

標準的な脆弱性検査のやり方しか説明していないので、脆弱性検査のやり方を既に把握している人が読んでも得るものは少ないのではないかと思います。今回は脆弱性検査に興味があるが何をどうしたらいいか分からないような初心者向けコンテンツです。

●ウェブサイトの手動脆弱性検査の基本

ブラウザでウェブページを見る際、発生する通信はHTTPプロトコルの「HTTPリクエスト」と「HTTPレスポンス」の二種類のメッセージで成り立っています。

ウェブサーバにブラウザから要求（リクエスト）を出し、ウェブサーバから戻ってきた応答（レスポンス）をブラウザが解釈してウェブページを表示する、というのが、ブラウザでサイトを見た際に裏側で行われている処理です。

あるウェブアプリの脆弱性検査を行いたい場合で、ブラックボックステスト方式で検査を行う場合には、この「HTTPリクエスト」のいろいろな箇所にいろいろな値を入れてみて（手順A）、ウェブサーバから戻ってきた「HTTPレスポンス」の反応を解釈して、脆弱性を見つける（手順B）というのが基本の手順になります。（他、ソースコードを開示してもらい、解析して脆弱性を見つけ出す等のホワイトボックステスト的なやり方もありますがここでは解説しません）

この(A)(B)の手順は、ブラウザ単体でやろうとしても十全にはできないので、ブラウザ-WEBサーバ間の通信内容を見たり、一旦止めて修正してから送信できたりするローカルプロキシソフトを使うのが一般的です。

私が使っているローカルプロキシソフトはFiddlerというソフトですが、Burp Suiteというソフトを使っている人も多いようです。

Fiddlerの使い方は下記サイトが詳しいです。

・実はFiddlerがすごすぎたので、機能まとめ紹介 - digital matter
・Webセキュリティの小部屋 > Fiddler の簡単な使い方
・Webセキュリティの小部屋 > Fiddler でリクエストパラメーターを改ざんする方法

Fiddler起動させておくと、ブラウザの設定が自動的に変わり、ブラウザからの通信がFiddlerを経由しての通信になります。

Fiddlerの機能で、ブラウザから送信されたリクエストを、いったんサーバーに実際に投げる前に一時停止して、編集できるようにするモードがあるので、そのモードにして、ブラウザから送信されるリクエストをいじくってからサーバーに投げます。そうして、いじくったリクエストに対するレスポンスに反応が出るか出ないか、異常な反応か正常な反応か、などを見ます。

●具体例

以下は私のローカルPC上のWEBサーバのページ（XAMPPトップページ）にアクセスした場合のFiddlerの画面キャプチャです。

検査対象のサイトに対して、Fiddlerを起動してブラウザからアクセスをすると、Fiddlerの左のウィンドウにアクセス結果（URL、結果ステータス等）が、右の上ペインに「HTTPリクエスト」、右の下ペインに「HTTPレスポンス」が表示されます。

（Inspectorsタブを選択し、リクエスト・レスポンス両方とも「Raw」を選択するようにしてください。本手順を確認するときは、インターネットの任意のサイトへの通信を覗く形で手元で確認できますが、外部のサイトを覗いて確認するときは、SSL利用のサイトだと通信を覗くのに設定を加えないといけないので、非SSLのサイトにアクセスして確認してください。また、注意事項ですが、公開サーバーへの攻撃とみなされる可能性がありますので、検査の許可をもらっていないサイトや自分が管理していないサイトへの通信は改変等はせず覗くだけにしましょう。）



Fiddlerには、ブラウザからサイトにリクエストを投げる際に、いったんリクエストがFiddlerで差し止められ、Fiddler上でリクエストを編集することができるようになるモードがあります。

分かりづらいのですが、Fiddlerのステータスバーの左から三番目の区切りの箇所

を一度クリックすると こんな表示になり、この状態にすると、ブラウザからのリクエストをいったんFiddlerが差し止めるモードになります。

ここで、ブラウザからウェブサイトにアクセスすると、Fiddlerが通信を差し止めるので、ブラウザはレスポンス待ちの状態で止まります。
Fiddlerの画面を見ると、右上のリクエストを表示する欄でウェブサーバに投げるリクエストが表示されているので、内容を改変し、「Run to Completion」のボタンを押下すると、改変されたリクエストがウェブサーバに投げられ、そのレスポンスがFiddlerの右下のレスポンスを表示する欄に表示されつつ、ブラウザにもレスポンスが表示されます。

ここで、検査の際にどういう風に考えて値を改変していくかを簡単にやってみます。

ここで、「example.com」というサイトに対するGETリクエストを改変する場合を考えてみます。

例えば、GETリクエストの内容がこうだったとして、

GET http://example.com/?q=a HTTP/1.1
Host: example.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Referer: http://example.com/ref
Cookie: uid=12345
Connection: keep-alive

脆弱性を探すための改変箇所として、パッと見でとりあえず色々試して反応を見たい箇所は
・GETパラメータ「q」の値
・Cookieの「uid」
だと思います。

---

・GETパラメータ「q」の値
は、まず「xxxxxyyyyyzzzzz」みたいな文字列にして、ここに指定した値がページ上にエコーバックされるかされないかを見ます。（文字列は何でも良いのですが、一目でわかるような特殊な文字列であればエコーバック箇所が見つけやすい）

それから、指定した値がエコーバックされる場合は「"」や「'」や「<」「>」などHTML的に特殊な意味を持つ文字を指定してみて、それらの文字がエスケープされて表示されるか否かを見ます（XSS狙い）。

それらの記号がエスケープされないで表示されるなら、ブラウザがHTMLを解釈（パース）する際に、ページのHTMLの構造をウェブサイト運営側が意図しない形で解釈させてスクリプトを動かしたり、ページの一部や全体を偽造したりすることが可能なので、XSS脆弱性の発見に成功したということになります。
（*細かくは記号がエコーバックできてもXSSできないケース等もあると思いますが、ここではざっくり例外を省いて解説しています）

---

・Cookieの「uid」
これはパラメータの名前や値の雰囲気からいって「ユーザーID」を示す値っぽいです。こういう値の場合には、SQL的に特殊な意味を持つ「'」などを指定してみてSQLインジェクション脆弱性がないか探すのも一手ですが、「12345」という値を「12344」のように、同じ形式の別の値にしてみることにより他人になりすませないか見るほうが期待値が高いです。

というのも、「'」のような特殊記号の混入には対策が取られていても、「適切な形式の値である」というチェックを通ったら、実際には他者のIDであっても正しい値として処理を通してしまう、というようなチェック処理の漏れを持つプログラムは割にあるからです。

（しかも、こういう処理漏れは脆弱性スキャナにエラーとして認識されないことが多々あります。ログイン者と違う氏名が表示されても画面遷移的には正常なので、脆弱性スキャナには異常と検知されない可能性が高いです）

---

こんな感じで、当たりをつけつつ、リクエストをいじくって、レスポンスの反応を確認し怪しい挙動があれば絞り込んでいく、みたいな作業を繰り返します。
（もちろん件のGETリクエストには上記以外にもいろいろリクエストをいじくって反応を見てみたい箇所はありますが、大まかな例です）

これが私のやっている脆弱性検査の基本的な手順です。おそらくこれは大抵の脆弱性検査者がやってる手順だと思います。

●検査に有用な知識

上述の作業において、脆弱性の当たりをつけたり、絞り込んでいったりするのに有用なのが、WEBアプリケーションの開発経験と脆弱性の知識です。（これは私の私見です）

WEBアプリケーションの開発経験は、「このあたりはこういう構造になっているのではないか」と内部構造を推測するのに役立ちます。

脆弱性の知識は、どれだけたくさん色々な脆弱性を把握しているかが、検査人としての腕前に直結するのではないかと思います。というのも、知識がないと危険な現象を見ても脆弱性に結びつけることができないからです。

例えば、「XSS」という脆弱性の原理を知らない開発者がもしいたとしたら、ユーザーが入力した「"」や「<」や「>」等がページにそのまま出力されてしまうことの危険性は分からないため、HTML上の特殊文字をそのままエコーバックするようなつくりにしてしまい、XSSを知っているクラッカーに脆弱性を突かれてしまいます。クラッカー側の目線から見ると、「XSS」というものを知っていることによって、「"」や「<」や「>」などの特殊記号がエコーバックされる危険性を想起することができたわけです。

検査人としても同様に、脆弱性の事例を知っていれば知っているほど、ウェブサイトの振る舞いから想起できる脆弱性の数が増えるので、知識は多いほうが良いです。
（私はこの点でまだまだ知識が足りません。勉強しなければ）

脆弱性についての知識は、たぶん無限に必要ですが、基本を抑えるならIPAの公式ドキュメントにある代表的な脆弱性の把握から始めれば良いのではないかと思います。

(IPA) 知っていますか？脆弱性 (ぜいじゃくせい)
http://www.ipa.go.jp/security/vuln/vuln_contents/index.html
(IPA) 安全なウェブサイトの作り方
https://www.ipa.go.jp/security/vuln/websecurity.html

●脆弱性検査の注意点

最後に重要なので再度注意書きを。

注意：脆弱性検査は検査許可をもらっているサイトか、自分の管理しているサイトに対してのみ行いましょう。

これは不正アクセス禁止法に触れるという以外に、検査行為によって対象サイトに実際の被害を発生させかねないからです。

参考：検査行為のおかげで対象サイトに害が発生しえた/害が発生した例
ockeghem(徳丸浩)の日記 2008-11-17 SQLインジェクション検査の危険性
とある診断員とSQLインジェクション

●参考書籍

また、この記事以上に脆弱性検査について学びたい方は
・体系的に学ぶ安全な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 最新の状況に合わせて更新しました

mixiに報告した脆弱性4件のうち、1件が評価されAmazonギフト10万円分頂いたので、その詳細を書いてみます。
mixi脆弱性報告制度とは、公式サイトによると、

本制度は、株式会社ミクシィとその子会社がリリースした、ウェブアプリケーションおよびクライアントアプリケーションの脆弱性を対象とします。

とあるように、株式会社ミクシィさんとその子会社のウェブアプリケーション、クライアントアプリケーションの脆弱性を見つけて報告したら懸賞金がもらえる制度です。
（検査対象の除外条件がいくつかあるので詳しくは公式サイトを参照）

開催期間は2013/09/30 から 2014/03/31 までです。

この制度のすごいところは有名サイト「mixi」の本番環境に対し（ルールで許されてる範囲内で）自由に検査をしてよいという点だと思います。

検査に当たっての禁止事項・制限事項としてルールのページに書いてあるのは

サービスの運営に支障を与えたり、他のユーザが所有するデータにアクセスしない限りにおいて、脆弱性発見のための調査が可能です。

これだけなので、「サービスの運営に支障を与えないように留意しながら」「他のユーザのデータにアクセスしないように留意しながら」であれば、ミクシイの本番環境で検査をすることが可能です。

（そのためサーバーに負荷をかけるような検査や、「' or 1=1--」みたいなのを不用意に発行して全件更新のSQLインジェクションが実行されてしまったりするような検査は避ける必要があります。SQLインジェクション検査の危険性についてよく分からない方はこちらのページが参考になると思います：ockeghem(徳丸浩)の日記「SQLインジェクション検査の危険性」）

---

私が見つけて報告したのは4件で、内容は以下のようなものでした。

・モラッポのオープンリダイレクタ（前々回書いたやつ）
報告日 11月4日
対応完了日 11月14日
報酬なしの連絡 12月5日

・http://adsmixi.net のxss
報告日 10月6日
対応完了日 12月3日
報酬なしの連絡 12月24日

・mixiモール（http://mmall.jp/）のHTTPヘッダインジェクション
報告日 10月14日
対応完了日 12月5日
報酬なしの連絡 12月24日

・mixiアンケート パラメータバグ
報告日 11月25日
対応完了日 12月18日
報酬連絡 12月24日 ￥100,000

これらは全て対応済みで、もう再現できないので説明しても問題ないため、順番に解説します。

---

・モラッポのオープンリダイレクタ

これは前々回のブログ記事で書いたので割愛します。

---

・http://adsmixi.net のxss

mixi内で読み込まれているJavascriptのソースを追っていくと、location.hashの値を加工してnew Image().srcに指定している個所があったので、その箇所にjavascript:alert(1);を指定してみたところ、IE6、IE7でalertが実行されXSSが可能でした（IETesterで検証）。

攻撃成功URLはこんな感じ。

http://adsmixi.net/ad/audiencescience/cookie.html#!host=javascript:alert(1);//

ただし、ドメインがmixi.jpでないため、cookieを読み出せるにしても被害はおそらく極小で、これは望み薄だろうなあ・・・と思っていたら案の定

弊社において検討した結果、直接的な被害の発生は
軽微である、または可能性が低いと判断させていただきました。
従いまして、報酬お支払いの対象外となりますことをご了承ください。

で報酬なしでした。

---

・mixiモールのHTTPヘッダインジェクション

mixiモールで転送アドレスになっているURLがあり、

http://mmall.jp/slink/xxxx

のアドレスにアクセスすると

Location: http://mmall.jp/xxxx

というヘッダが発行され、そのページに転送される箇所がありました。

ここで、転送前アドレスに改行コードの「%0d」を含ませてみたところ、Location:ヘッダ内で改行として出力され、任意のHTTPレスポンスヘッダを発行させることできてしまいました。

つまり、

http://mmall.jp/slink/aaa/%0dSet-Cookie:SESSIONID=AAAAABBBBB12345; Path=/

のようなアドレスにアクセスすると

Location: http://mmall.jp/aaa/
Set-Cookie:SESSIONID=AAAAABBBBB12345; Path=/

こういうHTTPレスポンスヘッダが発行され、教科書通りのHTTPヘッダインジェクション、もしくはHTTPレスポンススプリッティング攻撃が可能となっていました。

通常は、この種類の脆弱性があると、セッション固定攻撃によるセッションの乗っ取り等危険度の高い攻撃が成立してしまうものなので、これは結構大きい脆弱性を見つけたか？ と思ったのですが、mixiモールの場合、カートでの購入時などに別途ログインが必要な構造になっていたため検証した限りでは大した攻撃が成立しませんでした。
（攻撃URLを踏んだ他人がカートに入れた商品が見れる程度。攻撃対象者が購入フローに遷移し、ログインするとセッションIDとは別にハッシュ値のような値がcookieに設定されてそれで攻撃側からのセッション覗き見がガードされる。必ず先に発行されるLocationヘッダのせいですぐブラウザが別の画面に遷移してしまうので、偽BODYを作ってのXSSも成功せず、案外成立する攻撃がありませんでした。
HTTPレスポンススプリッティングは、本番環境でやってキャッシュ等で実害があると危険なので検証しませんでした。）

mixiモールと全く同じプログラムを使っていると思われるDeNAショッピングにも同様の問題があったため、IPA経由でDeNAショッピングに連絡し、mixiさんからの対応完了メールより少し先に対応完了のメールが来ました。

本件も、mixiさんからの返事は

直接的な被害の発生は軽微である、または可能性が低いと判断させていただきました。

で報酬なしでした。

潜在的には何か実害があることができそうにも思えたのですが、mixiさん側の検証でも大したことはできなかったのだと思います（HTTPレスポンススプリッティングも含め）。

---

・mixiアンケートのパラメータバグ

これは、脆弱性と言うよりバグに近いもので、mixiアンケート内のあるURLを操作すると、アンケート完了時にランダムにもらえるクーポンが、アンケートに全く回答しない状態でもらえてしまう現象を発見したため、クーポンを不正に取得できる手順を報告したところ、この報告は評価されて100,000円のAmazonギフトをいただきました。


（画面キャプチャあんま撮ってなかったので報告時の画像を加工して掲載）

mixiアンケートで、各アンケートの最初のページが以下のようなURLになっていたのですが、

https://mr.mplace.jp/ctrl/MON1030D.do?ActuonKey=MON1030&enqueteId=XXXXXXXX

このURLのActuonKey=MON1030をActuonKey=MON1020に打ち直すと、アンケートに全く答えていないのにアンケート回答完了画面にいきなり飛びました。

https://mr.mplace.jp/ctrl/MON1030D.do?ActuonKey=MON1020&enqueteId=XXXXXXXX

これだけではアンケートに回答したことにはならないっぽいのですが、一定の確率でアンケート最終画面でクーポンが当たることがあり、何度か試していたら、アンケートに答えていないのに自分のIDにクーポンが加算されてしまいました。

正直、これはテクニカルな意味ではあまり高度なものではなく、他の3件のどれよりも簡単な内容のものだったのですが、この現象には明らかに実害があり、この手口が広まったら大きな損害になりえたという事で評価していただいたのだと思います。
（私が不正に入手したクーポンは500円の価値があるものだったので、そういうクーポンの不正入手方法が広がったり積み重なると・・・という感じで評価されたのだと思われます）

---

というわけで頑張って検査したかいがありました。

評価された一件は見過ごされていたバグを見つけたという感じで、高度な脆弱性検査の知識が必要、というようなのでは全然なかったので、「4件中これが評価されたか」という印象もあるのですが、まあmixiさんからすれば実害ベースでの評価になるのは当たり前で、他の脆弱性では実害があまりなく、これが一番実害があったということでしょう。
とりあえず報酬もらえた＆検査楽しいので結果オーライでした。

脆弱性報告制度は来年3月末までなのでまだまだ探してみます。

良い制度を開催していただいてありがとうございます。＞mixi様

---

追記：ちなみに、賞金を頂くに至った一件は、最初メールが不達だったようで、他の脆弱性報告時には「受領しました」連絡が数日で来たのに、この件だけ一週間ぐらい返信がなかったので、「どうなっていますか？」と確認したらメールが届いていませんと言われメールを再送して、最終的に評価に至りました。

ちゃんとした脆弱性を報告しているのに、mixiさんから受領連絡も何も全く来ないという方は、一度情報が受領されているか確認してみたほうが良いかもしれません。（あきらめていたら賞金もらえないところだった）