webメールサービスのリンク確認画面にあった反射型XSS

数年前、EUC-JPなwebメールサービスでたまたま反射型のXSSを見つけたのでIPAに届けていました。

f:id:ooooooo_q:20170717180431p:plain

当時eメールからのリンクをクリックしたときの動作を調べていたのですが、その際に変な挙動に突き当たりました。適当なリンクを自分自身に送信した後、画面内に表示されたリンクをクリックすると外部リンクであることの確認画面に飛ばされます。そこまではいいのですが、なぜかリンクが途中で切れていました。

webメールの安全性は結構重要でして、webサービスではパスワードリセットする際にはメールで確認しているケースが多いため*1、ここに脆弱性があると他のサービスにも影響を受ける可能性が高まります。というわけで、よくよく調べてみると、確認画面のクエリパラメータに載っているurl=の文字の一部が画面側には出ていません。

このあたり記憶が曖昧なのですが xss に繋がりそうな文字種があると画面に表示する際には消されていたり、WAFでブロックされたような表示になっていた覚えがあります。詳細については念のため省略しますが、パラメータに細工をすることで対策された部分を乗り越えることができました。

f:id:ooooooo_q:20170717173623p:plain

chromeでは反射型XSSはフィルタリングによってブロックされるので単純には実行できませんでしたが、デフォルトでは組み込まれていないFireFoxでは実行できました。

f:id:ooooooo_q:20170717173852p:plain

ユーザが悪意のあるリンクをクリックするのを防ぐためのセキュリティ対策と思われますが、実装に脆弱性があるケースでした。*2

IPAを通じて届け出たのですが思いの外対応が早く、最初のメール送信から受理と通知までに3日ほど、修正までに一週間ほどでした。*3どこまで影響があるか調べるよりも先に届け出るのを優先したため、実際にどこまで影響があるのかを確認していなかったのですが、おそらくメールの読み取りなどはできたのではないでしょうか。

この手の反射型のXSSに対する対策としては、基本的にフレームワークに使われているエスケープ関数を使えば大抵の場合問題ありません。使っていない場合はフレームワークを入れるかライブラリを探すか、徳丸本を読みましょう。*4

*1:将来は分かりませんが少なくとも見つけた当時は

*2:このリンククリック時に確認画面が出るかどうかは、送信元のメールアドレスによって違いがあるようでした

*3:当時本体の会社は脆弱性報告制度がありましたが、japanの方にはありません。現在もHackerOneではスコープ外です。https://hackerone.com/yahoo

*4:今回はおそらくサーバ側で何か特殊な処理をしていたのが原因のように見えたので、フレームワークなどで防げたのかは怪しいですが。