～ ふしぎなおどりで審査員のMPを搾り取って銅メダル ～
null-i.net

クロスサイト○○、クリックジャッキング(2014-10-11)

クロスサイトって何？ †

まず、前提として以下のような状態が成立しているとします。

そして、上記の状態の続きから、以下のような攻撃が始まります。

攻撃者の目的は、ターゲットの「あるユーザ」に対して、
自分が意図したメッセージを「あるWebサイト」へ強制送信させること。
その際に、「攻撃者のサイト→あるWebサイト」へとサイトを横断(クロス)させる必要があるので、
クロスサイト○○という風に呼んでいます。

クロスサイトスクリプティング（Cross Site Scripting：XSS*1） †

上記の図でいえば「攻撃者のサイト」を作る手法のことです。
もちろん自前でサイトを用意するのもアリなんですが、みんなが普通にアクセスする掲示板などを「攻撃者のサイト」に変えてしまうのが一般的なやり方です。

具体的には、
例えば掲示板に「こんにちは」と書きこむと当然、掲示板には「こんにちは」と表示されます（ん？何を当たり前の事言っているんだ？）
ところが、

<script>悪意のあるjavascriptの命令</script>

のように書きこむと、あるユーザが掲示板を表示した時に<script>タグ命令が実行されて、悪意の命令がユーザのWebブラウザ上で起動されてしまう、という原理です。
実際は、掲示板等の脆弱性に合わせながらもう少し複雑な命令を書くのですが、いずれにせよ、
（掲示板や、入力値確認画面等の）訪問者からの入力内容をそのまま表示するWebサイトにおいて、悪意のあるコードを入力する（URLリンク、HTMLタグ、JavaScript等を入力する）ことで、他の訪問者がそのWebサイトを表示した際にその訪問者を操ろうとするのが、このXSSの手法です。
操って何をさせるかは様々です（後述のXSRFも、その１つ）。
例えば自前の不正サイトからウィルスをダウンロードさせたりもします。

しかし昨今の掲示板ならば、上記の悪意のある命令を書いても、書いた内容がそのまま表示されるだけな筈です（命令は実行されない）。
その際に掲示板のソースを表示すると（InternetExplorerだと[右クリック]-[ソースの表示]）、大抵の場合は該当個所は以下のように表示されているでしょう。

<script>悪意のあるjavascriptの命令</script>

つまり「<」が「&lt;」に、「>」が「&gt;」という文字へエスケープされています。
このようにXSSに対する代表的な対策は、Webサイト側で危険な入力文字（<>&など）をエスケープすることになります。

クロスサイトリクエストフォージェリ（Cross Site Request Forgeries：CSRFまたはXSRF） †

上の図の（１）～（４）のイメージです。

対策は、

ユーザ側は図の（１）の状態を作らない事。
例えば銀行サイトから「ログアウト」すればセッション情報は消えます。万が一XSRFのサイトを踏んでも、ログイン画面が表示されるだけでしょう。
ログインしっぱなしは良くないということです｡

Webサイト側の対策は、

• まず、XSS対策を行い、図の（３）のサーバにならないようにする
• 図の（４）で入力値を受け付けるときには、セッション情報のみで認証しない。
  銀行のサイトだと振込み前に再度パスワード入力させたりしますし、オンラインショッピングでも購買直前の画面に入れたランダム値を入力値に加えたり、なんらか工夫している筈です。
• また（４）のHTTPリクエスト内にRefererヘッダという「どこのサイトから来たか」を示す情報があるので、これが自分以外のサイトならば拒否するという手もあります（図の場合は（３）～（４）の流れで「攻撃者のサイト」から来ました、とRefererには書かれる）*2

クリックジャッキング（Click Jacking） †

前述のXSS、XSRFとは毛色が変わりますが、こんな感じです。

ユーザは、無害なサイトに個人情報を入力して送信ボタンを押したつもりが、実は透明な有害なサイト上での操作していた（有害なサイトに情報を奪われた）という事になってしまう。

対策としては、Webサーバ側（図で言うと「無害なサイト」側）で以下を行う*3

• HTTPレスポンスに、X-FRAME-OPTIONSを設定する。
  これで自分のサイトに勝手に透明なサイトを重ねることが不可能になる（frame、iframeタグから呼べなくなる）

httpd.confの例：
Header always append X-FRAME-OPTIONS "DENY"

• HTTPレスポンスに、X-Content-Security-Policyを設定して、スクリプトや画像ファイルの読み込み元を限定する。

httpd.confの例
Header always append X-Content-Security-Policy "allow 'self'; frame-ancestors *.null-i.net"

ただ、ここからは調査不足なんですが、HTTPレスポンスでの制限なので、古いWebブラウザがどこまで対応しているのかは疑問ですね。
少なくとも後者のX-Content-Security-Policyについては2013年3月現在でFireFoxのみが対応とのこと。