IE8 Security Part IV: The XSS Filter

更新日: 2008 年 7 月 2 日


本記事は、Internet Explorer 開発チーム ブログ (英語) の翻訳記事です。本記事に含まれる情報は、Internet Explorer 開発チームブログ (英語) が作成された時点の内容であり、製品の仕様や動作内容を保証するものではありません。本記事に含まれる情報の利用については、使用条件をご参照ください。また、本記事掲載時点で、Internet Explorer 開発チーム ブログ (英語) の内容が変更されている場合があります。最新情報については、Internet Explorer 開発チームブログ (英語) をご参照ください。

翻訳元 : IE8 Security Part IV: The XSS Filter (英語)



こんにちは、SWI (英語) チームでソフトウェア エンジニアをしている David Ross です。今回 Internet Explorer チームとの共同作業の成果を紹介できることを誇りに思います。

今回は reflected / "Type-1" Cross-Site Scripting (XSS) (英語) に関する脆弱性に対抗し Internet Explorer 8 内からの攻撃実行をより困難にする Internet Explorer の新機能について説明します。Type-1 XSS に関する欠陥は、脆弱性についての報告の中でも増加しつつあり、実際に悪用される事例も増加しています。

よく知られた Web サイトで XSS に関する欠陥が報告される事例も急激に増加しつつあり、MITRE の報告(英語) では脆弱性についての報告の中で XSS に関するものが最も多いとしています。最近では XSSed.com (英語) のように何万もの XSS に関する脆弱性を収集し、Web で公開を始めたサイトもあります。

XSS に関する脆弱性を利用すると攻撃者はユーザーとユーザーが信頼している Web サイトや Web アプリケーションとの関係を悪用できるようになります。Cross Site Scripting を利用すると以下のような攻撃が可能になります。

ž   アカウントの乗っ取りにつながる セッション Cookie の盗用を含む、Cookie の盗用

ž  Web サイト、もしくは Web アプリケーションへのキー入力の監視

ž   ユーザーになりすまして Web サイトへの操作 (例えば Windows Live Mail 上の XSS 攻撃では、利用者になりすまして、Web メールを読んだり、転送したり、カレンダーに予約を設定することができるかも知れません)

Web サイトや Web アプリケーションの XSS に関する脆弱性を緩和するための多くのツールが開発者向けに存在していますが、こうしたツールは一般的なユーザーが Web ブラウズする際に XSS 攻撃を予防するというニーズには対応していません。

XSS Filter - 動作原理

XSS Filter はブラウザー内のすべての要求、応答通信に対し透過的に動作する Internet Explorer 8 のコンポーネントです。この機能はクロスサイトの要求通信に XSS と考えらえる内容を見つけ、その内容がサーバーからの応答通信にも含まれていた場合、これを XSS 攻撃であると認識し、無力化します。ブロックの可否はユーザーには提示されず、自動的に悪意のあるスクリプトはブロックされます。XSS Filter 機能が攻撃を検出した場合、下記のようなメッセージが表示されます。

上記のページは内容が変更され、XSS による攻撃は阻止されました。

このケース場合、XSS フィルタは この URL で Cross Site Scripting による攻撃を意図していると認識しました。このページへの応答通信に問題となるスクリプトが含まれていたため、攻撃だと認識され無効化されました。このようにフィルタは要求通信を変更せず、応答通信をブロックすることで効力を発揮します。

フィルタが適正に動作する必要がある幾つかの興味深いシナリオが想定できます。

例としては、

ž  Web アプリケーションの共用フレームワークに特化した攻撃に対しても有効に動作する必要があります。
例 - リクエストに含まれる特定の文字が、サーバーからのレスポンスの際に意図的に抜かれていたり、変更されていても攻撃を検出できるか

ž   フィルタリングの実行に用いられるコードを逆手に取った新たな攻撃を生み出してはならない
例えば、フィルタがスクリプトの閉じタグである</SCRIPT> を無効化することを考慮して、閉じタグ以降にさらに信頼できないスクリプトを記述する可能性もあります。

これらに加え、「XSS-Focused Attack Surface Reduction (英語) 」で説明していない XSS アタックの方向性 (英語) にも対処する必要があります。

互換性を維持することはとても重要なことです。もしこの機能を動作させることで既存の「Web ページが壊れる」のであれば、デフォルトで有効化することはできないということを念頭にこの機能は開発されました。互換性を維持できなければ、ユーザーはこの機能を無効化して Internet Explorer 8 を利用することになるため、結果的に何もメリットを生み出さないことになります。我々は可能な限り大多数のユーザーの利益となる機能を適用したいと考えています。

Internet Explorer の互換性ログを記録すれば、Microsoft Application Compatibility Toolkit (英語) を用いて、XSS Filter の動作をすべて確認することができます。

Web 開発者はこの機能を無効化したいと考えるかもしれません。この場合、HTTP ヘッダーで X-XSS-Protection: 0 を設定すれば無効化できます。

最終的に、我々はサイトの互換性を損なうような設計のフィルタを選択しないという現実的なアプローチを採りました。そのため、XSS Filter は一般的な XSS 攻撃を防御することはできますが、すべての XSS 攻撃に対する万能薬とはなりえません。これは ASP.Net Request Validation (英語) でも採用された現実的なアプローチではありますが、ASP.net の場合に比べるとより能動的に動作します。

サイトの互換性とパフォーマンスにわずかばかりの影響は発生しますが XSS Filter が Type-1 XSS 攻撃の手法としてしばしば見られる 「><script>... 」 を用いた手法を効果的にブロックできることは本質的な前進であると考えます。さらに他の reflected XSS 攻撃についてもブロックできるよう開発を進めることによって XSS Filter はさらに効果的になります。

注意事項はさておき、XSSed.com (英語) のようなサイトで公開されている何万もの Type-1 XSS に関する脆弱性を Internet Explorer 8 が阻止できることを誇りに思います (Type 1 XSS と同様に警告している IFRAME SEO Poisoning (英語) 攻撃はいうに及びません) 。

フィルタの動作原理、その歴史、その限界と開発の過程で得られた教訓については、今後改めて私のブログ (英語) で発表します。

David Ross
Security Software Engineer

 

ページのトップへページのトップへ