クリックジャッキング対策の迂回方法を試してみた

クリックジャッキング対策で推奨されるのはX-FRAME-OPTIONSの使用ですが、他にもJavaScriptによる対策があったりします。
しかし、IPAの資料を見ると、どうやらJavaScriptによる対策は迂回方法があるようです。どんな迂回方法があるのか興味がわいたので、試してみました。なお、クリックジャッキング攻撃とは何か？は、徳丸さんのブログなどを見るとよいと思います。

ここでは、下記のJavaScriptによるクリックジャッキング対策を迂回する方法の検証結果を紹介します。

<script>
	if(window.top !== window.self){
		window.top.location = window.self.location;
	}
</script>

上記の対策コードは、JavaScriptの実行かwindow.top.locationの書き換えを無効にすれば迂回できそうです。
探すといくつか迂回方法の情報が見つかります。今回試した迂回方法は下記2つです。

  1. iframe要素のsandbox属性を利用した迂回
  2. ステータスコード204を利用した迂回

検証方法

まず、JavaScriptによる対策を実施したやられサイトと攻撃者が用意した罠サイトを用意します。
次に、罠サイトの設定を変更し、罠サイトからiframeでやられサイトを表示します（下図はイメージ）。


罠サイトの設定は、下記3パターンです。

  1. 特に設定なし
  2. 迂回方法1を実施
  3. 迂回方法2を実施

検証結果

パターン1[特に設定なし]
  • やられサイトに記述したJavaScriptが実行され、強制的にwindow.topにやられサイトが表示される

JavaScriptの対策が有効なため、罠サイトにやられサイトを表示することができませんでした。

パターン2[迂回方法1を実施]
  • やられサイトに記述したJavaScriptが実行されず、罠サイトにiframeでやられサイトを表示することができる
  • やられサイトに記述したJavaScriptは実行されるが、強制的にwindow.topにやられサイトを表示することはできない

多くのブラウザで上記の結果になりました。
迂回するためのコードは下記の通りです。これを罠サイトに記述します。

//やられサイトに記述したJavaScriptが実行されず、罠サイトにiframeでやられサイトを表示することができる
<iframe id="target" sandbox="allow-forms" src="やられサイトのURL"></iframe>
//やられサイトに記述したJavaScriptは実行されるが、強制的にwindow.topにやられサイトを表示することはできない
<iframe id="target" sandbox="allow-forms allow-scripts" src="やられサイトのURL"></iframe>

下記が検証したブラウザおよび結果の一覧です。

ブラウザ バージョン 迂回成功
IE 9
10		 ×
○
Firefox*1 20.0
20.0(Android)		 ○
○
Chrome 26.0.1410.43 m
18.0.1025469(Android)		 ○
○
Opera 12.15
Mobile 12.1(Android)		 ×
×
Safari 5.1.7
6.1.3(iOS)		 ○
○

iframe要素のsandbox属性をサポートするブラウザにおいて有効な迂回方法です。sandbox属性はiframeで読み込むコンテンツに対して様々な制限を課すことができ、例えば、JavaScriptやフォームのsubmitを無効にしたり、window.topの書き換えを禁止したりすることが可能です。また、allow-xxxで制限を緩めることも可能です。

クリックジャッキング攻撃は、クリックだけで設定変更できるページにおいて、利用者を視覚的に騙してsubmitボタンまで押させる攻撃です。そのため攻撃者は、攻撃の邪魔になる制限は排除し、JavaScriptによる対策は無効化するようにsandbox属性値を設定すると思われます。sandbox属性について詳しくはW3Cの情報を確認するのがよいと思います。が、カラフル過ぎて読む気が...

なお、下記のような対策を実施しており、かつJavaScriptを有効にしないと（クリック操作だけでは）フォームのsubmitができないサイトでは、JavaScriptによる対策は迂回されないと思われますが、素直にX-FRAME-OPTIONSを使ったほうがよいですよね。

<script>
	if(window.top !== window.self){
		document.body.innerHTML="hoge";
	}
</script>
パターン3[迂回方法2を実施]
  • やられサイトに記述したJavaScriptは実行されるが、強制的にwindow.topにやられサイトを表示することはできない

デスクトップ向けのChromeのみ、上記の結果になりました。他のブラウザは、強制的にwindow.topにやられサイトが表示されました。
迂回するためのコードは下記の通りです。これを罠サイトに記述します。

<script>
    var prevent_bust = 0;  
    window.onbeforeunload = function(){ prevent_bust++ };  
    setInterval(function(){  
      if (prevent_bust > 0) {  
        prevent_bust -= 2;
        window.top.location = './204.php';
      }
    }, 1);
</script>

204.phpのコードは下記の通りです。

<?php
header("HTTP/1.0 204 No Content");
?>

下記が検証したブラウザおよび結果の一覧です。

ブラウザ バージョン 迂回成功
IE 9
10		 ×
×
Firefox 20.0
20.0(Android)		 ×
×
Chrome 26.0.1410.43 m
18.0.1025469(Android)		 ○
×
Opera 12.15
Mobile 12.1(Android)		 ×
×
Safari 5.1.7
6.1.3(iOS)		 ×
×

かなりアドホックな迂回方法です。RFC2616によると、HTTPステータスコード204はレスポンスにメッセージボディを含めてはならず、ユーザエージェントのdocument viewを変更すべきではないそうです。つまり、ブラウザは画面の更新をしない（はず）。上記の迂回コードは、やられサイト側のwindow.top.locationの書き換えが発生した直後に、window.top.locationを204のステータスコードを返すURLに変更し、あわよくばやられサイト側のwindow.top.locationの書き換えを無効化しようとしています。が、成功したのはデスクトップ向けのChromeだけでした。しかも、Chromeにおいても100%の成功率ではありませんでした。やられサイトの情報がブラウザ上に中途半端に表示される場合もあり、成功可否にはインターネット回線やPCの処理速度など様々な要素が絡んでいそうだと感じました。

まとめ

いろいろと書きましたが、クリックジャッキング攻撃は、JavaScriptによる対策は迂回される可能性があるため、X-FRAME-OPTIONSを使って対策した方がよいというお話です。 ちなみにX-FRAME-OPTIONSは、metaタグによる指定では有効にならないので注意です。指定方法は、IPAの『クリックジャッキング』に関するレポートなどを参照するとよいと思います。

ツッコミ等ありましたら指摘ください。Twitterも同じIDです。

*1:window.topの書き換え制限は実装されていない模様

巷で話題のCSRF攻撃は、ウェブアプリが対策すべきか

最近、CSRFによる掲示板への犯行予告の話が話題になっていますが、その中で「ウェブサイトが対策を怠ったため起きた」「ウェブアプリの脆弱性だ」のような記事やツイートをみかけました。

私は当該ウェブアプリの性質を鑑みると、ウェブアプリの脆弱性とは言い切れず、必ずしもウェブアプリ側で対策しなければならないものではないと考えているため、上記の記事やツイートを見て、違和感を覚えました。他の方々はどのような意見を持っているのか聞いてみたいと思い、普段書かない日記を書くことにしました*1。

そもそもCSRFについて認識がずれていると、意見がかみあわない可能性があるため、まずはCSRFとはナンゾヤというところから整理したいと思います。

CSRF とは何かの整理

CSRFの用語について

CSRFとは、クロスサイト・リクエスト・フォージェリの略です。他のサイトを経由したリクエスト偽装的な意味合いでしょうか。 読み方はシーサーフって読む人もいれば、シーエスアールエフと読む人もいます。私は後者です。

CSRFという単語は、2つの捉え方があります。 一つは攻撃手法で、もう一つが脆弱性の名称です。 ここでは区別するために、攻撃手法を「CSRF攻撃」、脆弱性の名称を「CSRFの脆弱性」と呼びます。

CSRFはどのような脆弱性か

えっと、簡単にCSRFの脆弱性を説明すると、

K氏）おまえがやったんだろ！
X氏）いいえ、私はやってません！
K氏）ここに証拠がある！！x月x日xx時に何してた！？
X氏）...たしか変なリンクをクリックしました
＿人人人人人人人人＿
＞ CSRFの脆弱性 ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^￣


こんな感じでしょうか。

もう少しまじめに説明すると、CSRFの脆弱性とは利用者に攻撃者が用意したリクエストを送信させ、利用者が意図しない処理を実行させてしまう脆弱性のことです。ウェブアプリにおいて、利用者が意図したリクエストであるかどうかを識別する仕組みがないために起きてしまうものです。

出典：IPAのAppGoatを使った講義の補助資料

なお、CSRFの脆弱性はログイン前提の脆弱性か？という定義に関する問題がありますが、この日記で決着がつく問題ではないため*2、この日記内では「対象のウェブアプリが認証やそれに近い行為により利用者を識別している状態のときに、その利用者に攻撃者が用意したリクエストを送信させ、利用者が意図しない処理を実行させてしまう」ものをCSRFの脆弱性と定義させていただきます*3。

この定義ですと、例えば下記のような事象が発生するとCSRFの脆弱性が存在すると判断できる、と私は考えています。

  • ショッピングサイトAは、誰からの注文かを識別し、かつ購入する意図があるのかを確認する必要がある。しかし、ショッピングサイトAにログイン済みの利用者が罠サイトを閲覧しただけで、ショッピングサイトに商品購入リクエストを送信してしまい、ショッピングサイトのウェブアプリが商品購入処理が実行されてしまった。
  • ローカルPCで動作するアプリBは、ブラウザ上から各種操作をするアプリであり、暗黙的にローカルPCの利用者のみが使用することを前提としていた。しかし、利用者が罠サイトを閲覧しただけで、アプリBにリクエストを送信してしまい、攻撃者が指定した操作が実行されてしまった。

前者は、認証により利用者を識別している状態です。後者はそれに近い行為により利用者を識別している状態です。 CSRFの脆弱性の定義として、前者は異論ないでしょうが、後者はありそうですね。

しかし、このような広めの脆弱性の定義であっても、巷で話題のCSRF攻撃はウェブアプリの脆弱性ではないと考えています。

次に、話題になっているCSRF攻撃がどのようなものかの認識を合わせたいと思います。

巷で話題になっているCSRF攻撃とは？

声明では、横浜市のホームページに小学校の襲撃予告を書き込んだとして、７月に明治大学の男子学生（１９）が逮捕された事件への関与を詳述し、その方法として、遠隔操作ウイルスは使用せず「クロスサイト・リクエスト・フォージェリ（ＣＳＲＦ）を仕掛けた」と明かしている。

【なりすましウイルス】「閲覧させＰＣ操作」 犯行メールに書き込み 横浜の小学校襲撃予告 - MSN産経ニュース

巷で話題になっているのは、上記の事件のことだと認識しています。
ヨミウリ・オンラインの記事では「市民からの提案」のフォームに問題があったと記載があります（ヨミウリ・オンラインは直リンク禁止らしいのでリンクは載せません）。
上記が事実ならば、CSRF攻撃によって、罠のリンクもしくは罠サイトを閲覧した利用者が、利用者の意図とは無関係に犯行予告をフォームに投稿したことになります。

ここでのポイントは、

  • 攻撃者がしかけたCSRF攻撃により、利用者のPCからフォームに犯行予告を投稿させた
  • 当該フォームは、(市民からであれば)誰からの意見も受け付けるようフォームであり、利用者を識別するような機能は存在しなかった

でしょうか。

ウェブアプリ側で対策すべきか

さて、ここからが本題です。
巷で話題になっているCSRF攻撃は、ウェブアプリ側で対策すべきでしょうか。

当該フォームは、誰でも意見を投稿できるフォームです。
フォームには公表を希望しない場合のチェックボックスもありますし、「投稿要旨、回答内容等から特定の個人が識別されてしまう恐れがある場合等は公表しません」という記載もありますので、投稿者を識別する機能がなくとも、ウェブアプリの機能上問題ないと思われます。ではなぜ、誰が投稿してもいいはずなのに、CSRF攻撃により他人のPCから犯行予告が投稿できてしまうことが当該ウェブアプリの脆弱性であるかのように（一部で）言われているのでしょうか。

それは、投稿したPCに割り当てられたIPアドレス情報のみで犯人にされてしまう可能性があり、実際に犯人ではないと思われる方が逮捕されている事例が出てきたからだと考えます。たしかにそれは問題ですが、当該ウェブアプリにセキュリティ上の問題があったと言えるでしょうか。

投稿したPCの持ち主が確実に犯人だとは言い切れません。ISPや投稿したPCを保有する組織の協力を得れば、IPアドレスやアクセスした時間から投稿したPCは特定できるかもしれませんが、それだけでは利用者は特定できません。盗んだ自動車で窃盗者が事故を起こしたら自動車の持ち主が逮捕される世の中では困ります。

当該ウェブアプリは投稿した利用者を識別する機能が必要ないのにも関わらず、IPアドレスベースで投稿した利用者であるとされ逮捕されてしまう可能性があることを理由に、ウェブアプリ側で修正すべき問題（脆弱性）であるということになってしまいます。これは逮捕に至るまでの捜査方法の問題ではないでしょうか。*4


以上のような状況を鑑みると、私はウェブアプリの脆弱性とは言い切れず、ウェブアプリ側で対策”すべき”とは言えないと考えています。
ただし、利用者の立場を考えると、逮捕されるかもしれないと怯えながらウェブサイトを閲覧するような状況は好ましくないため、CSRF攻撃への対策をすることは利用者に親切な対応だと思います。

*1:いざ書き始めるとなかなかうまくまとめることができず途中で挫折し、公開までに数日かかってしまいました

*2:CSRFの定義について - Togetter

*3:あえてここでは脆弱性の対象を広くするような定義にしています

*4:この日記ではウェブアプリの性質を考慮して、ウェブアプリの脆弱性かどうかを判断したほうがよいという主旨のことをいいたい訳で、警察を批判したい訳ではありません