本当は怖い文字コードの話：第2回 UTF-7によるクロスサイトスクリプティング攻撃［後編］｜gihyo.jp … 技術評論社（情報元のブックマーク数）

ってことで、ちょっとだけフォローしてみたｗ

文字エンコーディングの指定がないと時度的にIEが内容をみて自動応答してくれることを悪用したクロスサイトスクリプティング。

一時期文字化けをしまくっていた頃にできた、親切機能
あの頃日本人はIEが文字化けする！文字化けする！って文句ばっかり言っていたのに、今度は脆弱性だ！脆弱性だ！って、手のひらを変えたように言いやがる！お前らのNON ASCII言語のせいだぞ！という声が聞こえて着そう・・・

見ての通り，HTTPレスポンスヘッダ，HTMLのmeta要素内のいずれにも文字エンコーディングの指定がありません。

IEを使ってこのようなHTMLを開いた場合，IEにおいて文字エンコーディングの自動選択が有効になっていると，+ADw- のような特徴的な文字列からコンテンツがUTF-7であると自動で解釈され，スクリプトが動作します。

あるいは，IEの文字エンコーディングの自動選択が無効であったとしても，攻撃者がUTF-7で書かれた罠ページを用意し，そこからiframe経由で攻撃対象のページを読み込んだ場合には，iframe内は親ページの文字エンコーディングを引き継ぐため，攻撃対象のページもUTF-7であると解釈され，やはりスクリプトが動作します。

第2回 UTF-7によるクロスサイトスクリプティング攻撃［後編］：本当は怖い文字コードの話｜gihyo.jp … 技術評論社

このあたりは、事前にテンプレートなり作っておいてプログラマが触らないほうがよさそうですね。

文字エンコーディング名を出力する際には，大文字と小文字の差異は同一視されますが，ハイフンの有無などのちょっとした誤記であってもIEは正しく文字エンコーディング名を認識できなくなるので，注意が必要です。

第2回 UTF-7によるクロスサイトスクリプティング攻撃［後編］：本当は怖い文字コードの話｜gihyo.jp … 技術評論社

よくあるのが、Blogなどで「Blogのタイトル＋Blog名とかでTITLEを出すアプリ」で、順番がTITLE−＞METAになっているとこの問題は発生します。要注意です。

IEが正しく解釈できる文字エンコーディング名を出力している場合でも，HTTPレスポンスヘッダではなくmeta要素内で出力しており，さらにそのmeta要素より前方に攻撃者が任意の文字列を出力できる場合には，IEがコンテンツをUTF-7と解釈してスクリプトが動作することになります。

第2回 UTF-7によるクロスサイトスクリプティング攻撃［後編］：本当は怖い文字コードの話｜gihyo.jp … 技術評論社