Developers Summit 2012で「趣味と実益の脆弱性発見」を聞いてきた

IE8までのセキュリティ設定には「拡張子ではなく、内容によってファイルを開く」があり、デフォルトで有効(msdn.microsoft.com) になっています。このためサーバー側で適切なMIMEを設定していても、コンテンツの中身によってはHTMLと解釈されXSSが発生する可能性があり、セキュリティ上のリスクとなっていることは古くから知られた事象です。

• なお、最新のIE9ではtext/plainなコンテンツをMIMEスニッフィングしなくなっています(blogs.msdn.com) 。

ユーザーの防御策はこの設定を「無効にする」に変更すること、サーバー側（サイト運営者）の対策は動的コンテンツのレスポンスヘッダに X-Content-Type-Options: nosniff を付けることですね。

• IE8 Security Part V: Comprehensive Protection(blogs.msdn.com)
• X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに!(d.hatena.ne.jp)

IE7まではレスポンスヘッダで指定した文字コードより、script要素のcharset属性に指定した方を優先する仕様により情報漏えいが起こりうるというもの。

HTMLで文字符号化方法が複数の方法で指定されている場合の優先順位はHTML4.01の仕様で定められており 、The charset attribute set on an element that designates an external resource. はもっとも優先順位が低いのですが、IE7以下ではHTTPヘッダよりも優先されてしまうようなのです。わけがわからないよ。

• 手元の環境で試してみたところ、Windows XP + IE7ではXSSが再現したのですが、Wondows 7 + IE8の互換モードでは発動しませんでした。本物のIE7以下でないとダメなのでしょうか。

Firefoxでは、古くからE4X(developer.mozilla.org) を実装しており、一見ただのHTMLやXML断片に見える次のような文字列がJavaScriptとしても認識されます。

<p>{foo(<em>test</em>)}</p>

このため {foo( と )} のように、対象サイトの複数箇所に文字列を挿入することが可能な場合、罠ページにscript要素を書いて対象コンテンツのHTML文字列をJavaScriptとして読み取ることでデータの抜き取りが可能となっていました[1]。その対策として、Firefox 3.5からは先のコードのように文字列がXMLリテラルしかない場合はJavaScriptとして扱わないようになったようです。

一方、Web Workersでは、importScripts()メソッド を使うことで別ドメインのスクリプトが実行可能ですが、この機能を使ったときはXMLリテラルのみの場合でもJavaScriptが動作するようになっていたため（Firefox3.6.6まで）、両者の技術を組み合わせることで外部サイトのデータを取得することが可能だった、というもののようです。

• Bug 568148 – Combining "importScripts" of WebWorker with E4X causes information disclosure(bugzilla.mozilla.org)
• PoC(openmya.hacker.jp)