IPAから「クリックジャッキング」に関するレポート出ました

Webアプリケーションのセキュリティの分野で「新しい攻撃手法」は実はそれほど多くないのですが、比較的新しく対応が求められているものとしてクリックジャッキングがあります。クリックジャッキングは、CSRFと同じように「Webアプリケーションのサーバー側機能」を利用者（被害者）に実行させる手法です。CSRFは、当該機能を実行するHTTPリクエストを送信させる罠を使いますが、クリックジャッキングの方は、iframe等に当該機能を呼び出す画面を表示しておき、利用者（被害者）に実行ボタンを押させる（=クリックジャック）手法です。クリックジャッキングに関しては従来詳しい解説がありませんでしたが、この3月26日にIPAから「クリックジャッキング」に関するレポートが公開されました。
このレポートから、クリックジャッキングのイメージを示す図4を引用します。

サイトAが攻撃対象のサイト、悪意のあるページは罠になります。これらのページはiframe等に入れられ、さらにサイトAはCSSにより透明に設定され、利用者には見えません。この「見えない攻撃対象のページ」をOHPフィルムのように罠ページに重ねたものが上図のイメージです。
このままでは攻撃は成立せず、利用者（被害者）にラジオボタンと「情報更新」ボタンをクリックしてもらう必要があります。巧妙な誘導により、上図の①と②をクリックさせる手法がクリックジャッキングです。利用者は罠サイトの①と②をクリックしているつもりですが、実際にクリックされるのは手前側に配置された（見えない）サイトAのボタンです。これにより、利用者は意図しない画面操作をさせられてしまいます。

さて、クリックジャッキングは新しいと言っても2008年のOWASPでの発表で、専門家には広く知られるようになっていましたが、当時は確実な対策方法がありませんでした。2009年にMicrosoftからX-FRAME-OPTIONSというレスポンスヘッダを用いる方法が提唱されるとともにIE8に実装され、その後主要なブラウザ（Firefox、Google Chrome、Safari、Opera）がX-FRAME-OPTIONSを採用するようになり、確実な対策が取れるようになりました（もっとも、「本家」MicrosoftのIE6とIE7がX-FRAME-OPTIONSに対応していないという問題があります）。以下に、IPAレポートの表1を引用します。

X-FRAME-OPTIONSによるクリックジャッキング対策は、ブラウザ側の対応だけではなく、Webアプリケーション側で適切なX-FRAME-OPTIONSヘッダを送信する必要があります。クリックジャッキングの知名度はまだまだ低く、IPAの「クリックジャッキングに関するレポート」では、この調査結果を載せています。日本人向けに提供されている56のWebサイトを調べた結果、わずか3サイトのみがX-FRAME-OPTIONSヘッダを用いていたという結果です。以下に同レポートから図5を引用します。

IPAは調査対象のサイト名を公開していませんが、例えばtwitterはX-FRAME-OPTIONSを送信している数少ないサイトの一つです。
最近もtwitterで犯行予告をした青年が逮捕されるという事件がありましたが、なりすましで犯行予告されると大変困ります。twitterはCSRFに加えて、クリックジャッキングにも対策しているということです。

ここで、「利用者はボタンをクリックするだけなのに犯行予告までできてしまうの?」という疑問が生じるかもしれませんね。でも、（対策していないと）できてしまうのです。twitterには、サイト側が用意した発言を利用者に求める機能があります。たとえば、このリンクをクリックすると、以下のような表示になります。

このままではツイートまではしない（ツイートしてしまったらCSRF脆弱性です）のですが、利用者が「ツイート」というボタンをクリックすると、上記テキストが、ボタンをクリックした利用者の発言としてツイートされます。クリックジャッキングにより、これを勝手にやられると困ります。
しかし、twitterはX-FRAME-OPTIONSヘッダを送信しているので、上記をiframeに入れて罠を作ろうとすると、下記のような表示になります（IE9の例）。

これにより、なりすまし投稿を防いでいるわけですね。

さて、IPAのクリックジャッキングに関するレポートには、X-FRAME-OPTIONSの詳しい説明の他、CSP(Content Security Policy)や、JavaScriptによる対策方法も示しています。たとえば、CSPでクリックジャッキングを防ぐ例としては以下が紹介されています（Firefox向けの書き方）。

X-Content-Security-Policy: allow 'self'; frame-ancestors *.ipa.go.jp *.meti.go.jp

上記は、このヘッダを送信しているページは、ipa.go.jpとmeti.go.jp（経産省）のサブドメインのiframeにのみ入れることができるという意味です。従って、罠サイトのiframeに入れようとすると、前述のようなエラーになるはずです…
ところが実際には、期待通りには動きません。これはFirefoxの既知の脆弱性のようで、最新版
Firefox19.0.2ではCSPのホスト式にワイルドカードを指定した場合、式の内容に関係なく「全てのホストが対象」となってしまいます。すなわち、前述の例はIPAと経産省だけでなく、世界中のどのホストのiframeにも入れていいよ、という動作になります…これは酷い脆弱性ですが、それほど話題になっていないのは、Content Security Policyがまだ普及していないからだと思います。

ということは分かっていたのですが、Firefox 20βでは修正されているようですし、CSPによる方法は残念ながらクリックジャッキング対策の（当面の）本命ではないので、冊子ではFirefoxの脆弱性については触れていません。なぜ本命でないかは、IPAの冊子をお読みください。

なお、徳丸はIPA非常勤研究員として、同冊子のレビュアーという形で参画していますが、このエントリは個人の見解として書いているものであり、IPAとしての見解ではないことを付記いたします。