†まず、前提として以下のような状態が成立しているとします。上記の状態の続きから、以下のような攻撃が始まります。自分が意図したメッセージを「あるWebサイト」へ強制送信させること。その際に、「攻撃者のサイト→あるWebサイト」へとサイトを横断(クロス)させる必要があるので、クロスサイト○○という風に呼んでいます。上記の図でいえば「攻撃者のサイト」を作る手法のことです。自前でサイトを用意するのもアリなんですが、みんなが普通にアクセスする掲示板などを「攻撃者のサイト」に変えてしまうのが一般的なやり方です。掲示板に「こんにちは」と書きこむと当然、掲示板には「こんにちは」と表示されます(ん?何を当たり前の事言っているんだ?)ところが、<script>悪意のあるjavascriptの命令</script>のように書きこむと、あるユーザが掲示板を表示した時に<script>タグ命令が実行されて、悪意の命令がユーザのWebブラウザ上で起動されてしまう、という原理です。の)訪問者からの入力内容をそのまま表示するWebサイトにおいて、悪意のあるコードを入力する(URLリンク、HTMLタグ、JavaScript等を入力する)ことで、他の訪問者がそのWebサイトを表示した際にその訪問者を操ろうとするのが、このXSSの手法です。操って何をさせるかは様々です(後述のXSRFも、その1つ)。自前の不正サイトからウィルスをダウンロードさせたりもします。昨今の掲示板ならば、上記の悪意のある命令を書いても、書いた内容がそのまま表示されるだけな筈です(命令は実行されない)。その際に掲示板のソースを表示すると(InternetExplorerだと[右クリック]-[ソースの表示])、大抵の場合は該当個所は以下のように表示されているでしょう。&lt;script&gt;悪意のあるjavascriptの命令&lt;/script&gt;つまり「<」が「&lt;」に、「>」が「&gt;」という文字へエスケープされています。このようにXSSに対する代表的な対策は、Webサイト側で危険な入力文字(<>&など)をエスケープすることになります。上の図の(1)~(4)のイメージです。対策は、ユーザ側は図の(1)の状態を作らない事。銀行サイトから「ログアウト」すればセッション情報は消えます。万が一XSRFのサイトを踏んでも、ログイン画面が表示されるだけでしょう。ログインしっぱなしは良くないということです。Webサイト側の対策は、まず、XSS対策を行い、図の(3)のサーバにならないようにする図の(4)で入力値を受け付けるときには、セッション情報のみで認証しない。銀行のサイトだと振込み前に再度パスワード入力させたりしますし、オンラインショッピングでも購買直前の画面に入れたランダム値を入力値に加えたり、なんらか工夫している筈です。前述のXSS、XSRFとは毛色が変わりますが、こんな感じです。ユーザは、無害なサイトに個人情報を入力して送信ボタンを押したつもりが、実は透明な有害なサイト上での操作していた(有害なサイトに情報を奪われた)という事になってしまう。対策としては、Webサーバ側(図で言うと「無害なサイト」側)で以下を行う*3HTTPレスポンスに、X-FRAME-OPTIONSを設定する。"DENY"HTTPレスポンスに、X-Content-Security-Policyを設定して、スクリプトや画像ファイルの読み込み元を限定する。*.null-i.net"ただ、ここからは調査不足なんですが、HTTPレスポンスでの制限なので、古いWebブラウザがどこまで対応しているのかは疑問ですね。少なくとも後者のX-Content-Security-Policyについては2013年3月現在でFireFoxのみが対応とのこと。Sheets)と混同するのでXSSと呼ぶ。使用して作成しています。使用しています(このサイトについて)。