"まず、Googleの404 Not Foundのページはこの例のように、リクエストされたURLのパス名を画面に表示するようになっている。ここで、そのパス名にHTMLのタグを構成する文字「<」「>」が含まれている場合、Googleは、これをきちんと「&lt;」「&gt;」にエスケープして出力するよう正しく実装していた。ところが、このページは当時、ページの文字エンコーディングを強制する指定をしていなかった。つまり、

Content-Type: text/html; charset=エンコーディング名

といった指定をHTTP応答のヘッダないし、HTMLの「<meta http-equiv="Content-Type" content="...」に記述することをしていなかった。Internet Explorerでは、ページのエンコーディングが指定されていない場合、データがUTF-7っぽい内容であれば自動的にUTF-7として表示する機能が働くため、UTF-7エンコードされたXSS攻撃文字列をURLに含めてGoogle.comの404 Not Foundページを表示させる攻撃がしかけられると、罠にかかった被害者のInternet Explorer上でJavaScriptコードが実行されてしまう。

Googleはこの指摘に対し、当該ページに「<meta http-equiv="content-type" content="text/html;charset=us-ascii">」を埋め込んでエンコーディングを明示するようにすることで、この問題を解決したようだ。

このような文字エンコーディングの曖昧さによって発現するXSS脆弱性の問題については、2000年の時点で既にCERT Advisory CA-2000-02で次のように勧告されていた。

web pages should explicitly set a character set to an appropriate value in all dynamically generated pages.
（Webページは全ての動的に生成されるページにおいて文字エンコーディングを適切な値に明示的にセットするべきである。 ）

2000年にリリースされたApache 1.3.12でも、404 Not Foundなどのエラーページで「charset=iso-8859-1」を明示する変更が加えられており、当時日本では、これによって文字化けが発生する不具合が生じたため、別の意味で話題となっていた。当時の様子は「Apache 1.3.12 文字化け問題」に見ることができる。

幸い日本では、日本語を使用する都合から文字エンコーディングを常に指定する習慣が元々根付いているため、この問題の影響を受けるところは多くないかもしれないが、念のため、エンコーディング指定のないページがないか確認しよう。

この問題はUTF-7固有の問題ではない。たとえばISO-2022-JPでも同様のことが起こり得る。ユーザが意図してメニューから文字エンコーディングを変更すると、それによってXSS攻撃が発動することがある。訪れたサイトで文字化けが起きているからといって、不用意にエンコーディングを変更してはいけない。「文字エンコーディングを変更してください」などと要求するページに騙されないよう注意が必要だ。"