[SECURITY] XSS Filter Improvements in IE8 RC1 の日本語訳
やぁ、みんな，元気？長谷川陽介です。今日はIE8 RC1のXSSフィルタの改善点をこっそり教えちゃうよ。
いつもは攻撃側でひらがなの名前でやってるんだけど，きょうは防御側ということで，名乗りも漢字に変えたんだ。だってさ，Microsoft SWIのDavid Rossさんから翻訳許可もらったのにひらがなとか失礼じゃないか。
では始めよう。
- //blogs.technet.com/swi/archive/2009/01/30/xss-filter-improvements-in-ie8-rc1.aspx">XSS Filter Improvements in IE8 RC1:http://blogs.technet.com/swi/archive/2009/01/30/xss-filter-improvements-in-ie8-rc1.aspx
月曜日にIE8 RC1がリリースされました。XSSフィルター機能の興味深い点および修正を示します。
システムロケールに依存するかたちで、いくつかのバイトシーケンスがフィルタをバイパスできました。
いくつかのロケールにおいて特定のバイトシーケンスを含むURLは、Beta 2 のフィルタ実装を回避できていました。例えば、中国語ロケールでは以下の書式のURLはフィルタをバイパスします。
http://www.fabrikam.com?x=%A0<script>alert();</script>
フィルタはURLを正規表現エンジンに通すより前にURLエンコードをパースします。0xA0バイトに続く0x3Cバイト(「<」)の存在は、MultiByteToWideChar の失敗を引き起こすことがあります。これは、0xA0 0x3Cというバイト列が中国語および他のロケールで正しいマルチバイト文字ではないからです。この状態では、引き続き大文字小文字を区別しない正規表現マッチングの失敗が発生します。しかしさらに悪いことに、正規表現のコードのあとの部分では、0xA0 0x3C の並びは単一のマルチバイト文字と解釈されます。「<」文字は入力から実質的に消えているので、発見ロジックはXSSを見落とします。
IE8 RC1 では、正規表現コードにて全ての入力をデフォルトコードページ(マルチバイトのときもあります)の文字としてではなく、個々のバイト列であると見なすように修正されました。
Yosuke Hasegawa (訳注：ヽ(´ー｀)ノ ) と 80sec の両名が IE8 Beta2 でこのバグを発見しました。
HTTP レスポンスに含まれるNULLが、フィルタリングがHTTPレスポンスデータのデータを欠落させる原因となっていました。
関連するバッファクラスを修正しました。
PHP stripslashesを含んでいる攻撃シナリオからの保護の追加
PHP の stripslashes 関数は入力からバックスラッシュを取り払います(また、二重のバックスラッシュを単一のバックスラッシュに置き換えます)。一般的に、PHPデベロッパは文字列を出力する前に stripslases を呼び出します。この場合、出力がサーバー側でのXSSを可能にするならば、IE8 XSSフィルターにも関わらず、まだXSSを引き起こすことができます。
これは、XSS Filter Architectural Overview で論じたように、プラットフォーム固有の作為的な影響の一例です。
このデコードの処理は、柔軟であり、また様々なWebプラットフォームでの固有の影響を受けることもあります。必要に応じて、フィルタは同じ入力データに対する異なる解釈に基づくシグネイチャを追加的に生成します(下記参照)。例えば、不正な形式のURLエンコード文字は異なるWebプラットフォームでは異なった扱いを受けるかも知れないため、フィルタは適切なシグネイチャを構築できなければなりません。
この記述は、新しい動作をうまく表現しています。現在フィルタは、入力に対する異なる解釈について必要に応じて、シグネイチャを追加的に生成します。この新しいシグネイチャは、PHP の stripslashes 関数の動作に合わせるために設計されています。
現在、PHPの "magic quotes" 機能は廃止される予定です。PHPのコードで stripslashes を使用しているのが magic quotes の動作に由来するのであれば、 今後 Web 上では stripslashes の使用頻度が下がると思われます。しかし、我々はまだこの問題が広く存在し、少なくとも今の時点ではIE8 RC1 にて問題を軽減する意味があるため、この機能を呼び出すようにしています。
Ronald van den Heetkamp がこの問題を確認しました。
サーバが未だにUTF-8の冗長表現をサポートしていることによる攻撃シナリオに対する防御の追加
上述の PHP Stripslashes の変更と同様に、非最小形式のUTF-8が入力値に検知された場合に、追加のシグネイチャを生成し処理します。
非最小形式のUTF-8がRFC3629で禁止されて長い期間が経ちますが、残念ながらまだ多くのWebサーバプラットフォームでこれを受け入れてるようですので、我々がこの攻撃ベクトルを示しておくことは意味があるようです。
Amit Klein がこの問題を確認するヒントとなるフィードバックを提供しました。
FORM および ISINDEX 要素のインジェクションの攻撃シナリオからの保護の追加
我々は一般的なHTMLインジェクションをブロックしませんが、スクリプトのインジェクションに類似した攻撃のシナリオを可能にする、これら2つの要素に対する例外を定めました。
Gareth Heyes が ISINDEX 要素による問題を指摘しました。
OBJECT タグの CODETYPE 属性を TYPE 属性と同様に扱うようにしました
OBJECT タグの CODETYPE 属性は TYPE 属性と同様の機能をもっています。IE8 RC1では両方の属性を同一に扱うようにしました。
Gareth Heyes がこの問題を指摘しました。
