IEBlog : IE8 Security Part IV: The XSS Filter

IEBlog : IE8 Security Part IV: The XSS Filter について、記事を書いた David Ross さんに翻訳許可をもらいましたので、訳してみました。誤訳や指摘がありましたらガンガン突っ込みをお願いいたします(他の記事も時間をとって訳していこうと思います)。当然ながら、これは私が私的に訳したものであり、Microsoftによる公式な翻訳/見解ではありません。
(訳注追加) 「reflected / Type-1 XSS」というのは、攻撃コードが被害者からのリクエスト自身に含まれるタイプのXSSで、サーバ側のアプリケーションでユーザからのリクエストに含まれる攻撃コードを「反射的」に返すような種類のXSSです。典型的には「"><script>...」のような語を検索したときに

<input type="text" value=""><script>...">

のような応答を返すXSSなどです。type-1 ではないXSSとしては、例えば Web メールのように攻撃者は事前にSMTPを通じて攻撃コードをWebアプリケーションに送り込み、被害者は通常通りWebメールを開いたとき(リクエストに攻撃を含んでいない)にXSSが発動するような例があります。
日本ではあまりこういった種類分けは流行っていないですし、私も好きでないですが、今回の説明においては type-1 XSS がどういったものかを理解しておくほうが分かりやすいと思いましたので一応書いておきます。


IE8 Security Part IV: The XSS Filter

みなさん、こんにちは。私は SWI チームのセキュリティソフトウェアエンジニアである David Ross です。
今日、私は SWI チームが Internet Explorer チームと行っている共同作業のいくつかを見せるためにIEブログにゲストとして投稿できることを誇りに思っています。
今日、我々は IE8 からreflected / Type-1と呼ばれる種類のXSSによる攻略をより困難にするIE8の新機能について、いくらかの詳細を公表します。Type-1 XSS は、近年の脆弱性報告のうちの増加部分を占めており、「趣味と実益」のためにますます攻略されています。
知名度の高いWebサイトでのXSSの報告数は、昨今急増しています。MITREは、XSSがもっとも脆弱性の報告の種類として多いと報じています。また最近では、XSSed.com のようなサイトが、Web上の何万もの Type-1 XSS を集めて公表し始めていました。
XSS脆弱性は、WebサイトやWebアプリケーションとユーザの間の信頼関係を攻撃者にコントロール可能にします。XSSは以下のような攻撃を可能にします。

  • Cookie情報の盗用。アカウントのハイジャックにつながるセッションCookieの盗用を含みます。
  • 犠牲となるWebサイト/アプリケーションに対するキーストロークのモニタリング。
  • 被害者に代わり、ターゲットとなるWebサイトへの操作を実行。例えば、Windows Live MailへのXSSであれば、攻撃者はメールを読み、転送し、新しい予定をカレンダーに設定できます。

多くの開発者向けの優れたツールが、Webサイト/アプリケーションでXSSを軽減させるために存在していますが、これらのツールは平均的なユーザがWebを閲覧しているときのXSSの発動を予防するには至りません。

XSS Filter - それがどのように働くか

XSS Filter はブラウザを経由する全てのリクエスト/レスポンスに対して働く IE8 のコンポーネントとして機能します。フィルタがXSSのように見えるクロスサイトのリクエストを検出したら、サーバからのレスポンスにてその内容が再び現れている場合、攻撃を検知して無力化します。ユーザには、答えられないような質問は提示されません - IEは単純に悪意のあるスクリプトの実行をブロックします。
この新しい XSS Filter により、Type-1 XSS に遭遇した IE8 beta 2 のユーザは、以下のような通知を目にします。

ページは変更され、XSS攻撃はブロックされました。

このケースでは、XSS Filter はURL中のXSS攻撃を検出しました。フィルタは、該当するスクリプトがレスポンスのページにて再現されて返されたので、攻撃を無力化しました。このように、サーバへの本来のリクエストを変更することや、レスポンス全体のブロックをすることなくフィルタは働きます。

想像できるように、フィルタが適切に扱うべき、興味深く微妙なシナリオがいくつかあります。いくつかの例を示します。

  • たとえ攻撃が共通のWebアプリケーションフレームワークに人為的に影響するよう調整されているとしても、フィルタは働かないといけません。例えば、リクエストに含まれる正しい文字がレスポンスでの出現時に欠落または変換していても、攻撃が検出できるでしょうか。
  • フィルタリングの実行において、我々のコードが、本来は存在しない新しい攻撃のシナリオを生み出してはいけません。例えば、フィルタがやむ終えず SCRIPT の閉じタグを削除する場合を考えてください。その場合、ページ中の信頼できない内容がスクリプトとして実行されるかも知れません。

そしてもちろん、これら全てに加えて、他の「XSS-Focused Attack Surface Reduction」対策により、ここで記述しなかった他のXSS攻撃ベクターに対抗する必要があります。

互換性は重要です。フィルタ機能は、もしこの機能が「Webを壊す」ことになるなら、デフォルトで有効にはできないという思いで開発されました。そうでなければ、人々は機能を無効にし、メリットを全く生み出さないでしょう。我々は本当に、できるだけたくさんのユーザに大きな価値を提供したいと思っています。

Internet Explorer のアプリケーション互換ログを有効にすると、Microsoft Application Compatibility Toolkit を使って、全ての XSS Filter の活動を見ることができます。

Webデベロッパーは、コンテンツにおいてフィルタを無効にしたいと思うかもしれません。その場合、HTTPヘッダにて

X-XSS-Protection: 0
と設定してください。

結局、我々は最も現実的なアプローチを採りました。我々は、フィルタがサイトの互換性を損なうような方法での作りを選びませんでした。
そのため、XSS Filter は最も一般的なXSS攻撃に対しては防御できますが、決してXSSに対する万能薬ではありません。これは、ASP.Netの Request Validation で採られた現実的なアプローチと同様ですが、ASP.Net の機能以上に、より積極的に働きます。

サイトの互換性とパフォーマンスへの影響を無視できると考えるなら、フィルタがType-1 XSS攻撃においてもっとも頻繁に見かける「><script>...」パターンを効果的にブロックすることは、本質的な前進です。XSS Filterが行うように、さらに押し進めて Refrected XSS の他の共通的な部分を可能な限りブロックすることは、よりすばらしいことです。

警告はともかく、XSSed.comのようなサイトで公にされた何万もの Type-1 XSS 脆弱性について、IE8 での動作がストップされるのを見るのは、とてもすばらしいことです。(我々が同様に保護する、IFRAME SEO Poisoning攻撃は言うまでもなく!)

フィルタがどのように働くのかより詳しい説明、その歴史、制限、そして開発プロセスを通じて得た教訓について、今後数週間のうちに私のブログで説明します。

David Ross
Security Software Engineer
Published Wednesday, July 02, 2008 9:03 AM by ieblog
Filed under: Security