UTF-7エンコードされたタグ文字列によるXSS脆弱性に注意
本家に「Cross Site Scripting Discovered in Google」というストーリが掲載された。 これは、Web Application Security Consortiumが主宰するメーリングリストに投稿された記事を伝えるもの。その記事によると、Google.comにXSS(クロスサイトスクリプティング)脆弱性が見つかり、発見者が11月15日にGoogleに連絡したところ、12月1日に修正されたという。この脆弱性の原因と対策は以下の通り。まず、Googleの404 Not Foundのページはこの例のように、リクエストされたURLのパス名を画面に表示するようになっている。ここで、そのパス名にHTMLのタグを構成する文字「<」「>」が含まれている場合、Googleは、これをきちんと「<」「>」にエスケープして出力するよう正しく実装していた。ところが、このページは当時、ページの文字エンコーディングを強制する指定をしていなかった。つまり、
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.2000年にリリースされたApache 1.3.12でも、404 Not Foundなどのエラーページで「charset=iso-8859-1」を明示する変更が加えられており、当時日本では、これによって文字化けが発生する不具合が生じたため、別の意味で話題となっていた。当時の様子は「Apache 1.3.12 文字化け問題」に見ることができる。
(Webページは全ての動的に生成されるページにおいて文字エンコーディングを適切な値に明示的にセットするべきである。 )幸い日本では、日本語を使用する都合から文字エンコーディングを常に指定する習慣が元々根付いているため、この問題の影響を受けるところは多くないかもしれないが、念のため、エンコーディング指定のないページがないか確認しよう。
この問題はUTF-7固有の問題ではない。たとえばISO-2022-JPでも同様のことが起こり得る。ユーザが意図してメニューから文字エンコーディングを変更すると、それによってXSS攻撃が発動することがある。訪れたサイトで文字化けが起きているからといって、不用意にエンコーディングを変更してはいけない。「文字エンコーディングを変更してください」などと要求するページに騙されないよう注意が必要だ。