ブラウザのパスワード自動入力機能(パスワードマネージャ)とクリックジャッキングを併用して、ユーザに意図せずSNSなどにログインさせる方法がある。
自分はこれはセキュリティ上問題のある動作、ブラウザ側の脆弱性だと思っている。
前提として、セキュアなHTTPSでないサイトについてパスワードマネージャーに対する攻撃は知られていて、HTTPSで設定したパスワードをHTTPでは自動入力しない、という方法がとられている。
もしHTTPでも自動入力を許してしまうと、ブラウザ側の同一生成元ポリシー(SameOriginPolicy/SOP)による対策はDNSインジェクションや偽装WiFiAPなどを利用して簡単に破られるので、簡単なJavascriptで網羅的にパスワードを詐取できる。従って、現存する
全てのパスワードマネージャはSOPとHTTPSで守られていると考えていい。
しかし、
ログインフォームにクリックジャッキング対策が為されていない場合、SOPが守られていても、
ユーザに意図せずパスワードを送信させることが出来る。
パスワードマネージャの自動入力のクリックジャッキング脆弱性自体は、既に2年以上前にBugzillaにポストされていた(mala氏から教えて頂いた)が、セキュリティバグではないと判断されてしまっている。Chromiumにもポストしたが、セキュリティバグでないとリジェクトされてしまった。
しかし自分はこの問題には、ブラウザ側で対策すべき理由があると考えている。攻撃に利用されるクリックジャッキング未対策のウェブサイト側には、積極的に塞ぐ理由が(ごく一部のユーザーからの信頼以外)無く、ユーザが巧妙に仕掛けられた罠iframeを見破ることは事実上不可能だからだ。
この手法それ自体では、
攻撃者が直接的な利益を得られる確率は低い。僅かな利益を得られるシナリオとしては、
・SNSのログインページにログイン後リダイレクト機能があり、同一SNS上に用意した自分のページのログインユーザ閲覧数を稼ぎたい場合。
・攻撃対象ユーザのリアルタイム情報自体に価値がある、標的型攻撃の場合
があるが、露見時のリスクから考えてもっと他に良い方法が有るだろう。
一方、
SNS側には露見した場合も信用の低下以外に被害がない。
ユーザーの個人情報を集積し、広告を流すことで利益を得ているSNS側は、なるべく多くのユーザにログイン状態にいて欲しい。また、クリックジャッキング対策に有効なX-Frame-OptionsヘッダはまだXが付く標準化以前のものであり、必須ヘッダではない。そして、この対策をすることによって、ごく一部のユーザーの信頼の維持以外に直接的な利益が無い。
Evilなウェブサイトがユーザーのログインという同意を、第三者の攻撃に見せかけて捏造することさえ不可能でない。
他方、
被害を受けるユーザーにとっては問題が生じうる。
クリックジャッキングによってログインした場合に、SNSには位置情報など、通常ユーザーの意思で保護されるべきリアルタイムの情報が意図せず伝わってしまう。
SNSが足跡機能やユーザー現在位置などリアルタイム情報を公開する機能を持っていれば、
SNSを通じて第三者が"意図的にログアウトしたい状況下にある"ユーザーの情報を取得できる可能性がある。
そもそも、ログアウトしたはずのサイトにログインしているという事自体、ユーザの意図に反する動作で、安全でない環境にアクセスする際はCookieを削除してこまめにログアウトする、という初等的なセキュリティ対策を無効化してしまう。
また、冤罪事件から分かるように、CSRFやクリックジャッキングによるユーザーの意図しない行動について、刑事捜査の過程で(少なくとも冤罪被害者に利する方向には)考慮されない事が分かった。
ログインフォームにCSRF対策がなされていても、クリックジャッキング脆弱性があればログインを誘導でき、現状XSSは論外としても、ログインユーザに対する
クリックジャッキングやCSRF脆弱性がウェブサイトの何処にも無いと言い切るのは無謀と考えられる。愉快犯がクリックジャッキングを二度成功させ、SNSや掲示板などにログインさせて犯行予告をポストできた場合、冤罪被害者が第三者による悪意あるCSRFやクリックジャッキングであると証明することはとても難しいのではないだろうか?
現在、ユーザーが意図せず情報を送信あるいは公開しうるSNSを2つ確認している。一つはログイン直後に位置情報がSNS側に送信され、もう一つはログイン状態表示と足跡機能によってリアルタイム情報を第三者に公開しうる。
二段階のクリックジャッキングによってログインユーザを騙って犯行予告といった比較的簡単な条件ならもっと有りそうだ。
少なくとも、X-Frame-OptionsヘッダがRFC標準でMUSTになるか、ブラウザのデフォルト動作がDenyになるまでは、クリックジャッキング対策は可能な限りブラウザ側で行うべきだ。
例えば、
XFOヘッダに頼らなくても、以下のような解決法がある。
パスワードマネージャは、iframe.srcとwindow.location(つまりアドレスバーのドメイン)が
異なるオリジンの場合に自動で入力はしない。パスワードを入力する前に、BASIC認証自動化URLの警告と同様に、「異なるサイトexample.comにパスワードが送信される場合があります」などと警告した上、ユーザーの明示的確認を得てから半自動で入力する。
将来的には、iframeを完全に禁止する、より安全な対策が実現するかもしれない。しかし今のところクリックジャッキングは何処にでも存在しえて、ウェブサービス側はともかく、一部のユーザーには脅威になる。ウェブサイトの善意に頼るよりも、ブラウザ側に対策が求められると考えている。
現時点で、この攻撃に対する手軽な対処法は、
拡張機能などでiframeでの外部リンクを禁止すること。例えば、Adblockで次のフィルタを追加する。
##iframe[src*="//"]
サイト自身の機能を利用するためにiframeが必須なサイトがどれだけ有るか考えると、これが一番と思われる。