[アーティクル]
10/20/2021

Internet Explorer 8 のセキュリティ Part VI: Beta 2 の更新項目

更新日: 2008 年 9 月 2 日

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

翻訳元 : IE8 Security Part VI: Beta 2 Update (英語)

Internet Explorer 8 Beta 2 が公開されましたので、開発チームが最近行った幾つかのセキュリティに関する小規模な変更についての更新情報を簡単にお伝えします。Internet Explorer 8 の XSS フィルター機能を設計した開発者の素晴らしい記事へのリンクも案内します。

document.domain の制限

document.domain (英語) プロパティは、まずページを提供しているサーバーの完全修飾ドメイン名を返します。このプロパティはフレーム上の異なるホスト名のページから共有できるようにドメインサフィックスを割り当てることができます。例えば、app1.expample.com と app2.example.com で稼動しているふたつのフレームは、それぞれのフレームに共通の example.com を document.domain に設定すれば、お互いに対するスクリプトを記述することができます。フレームがドメインプロパティにトップレベルドメインを設定したり、異なるサフィックスを設定したりすることはできません。例えば、app1.example.com にはドメインプロパティに .com や microsoft.com を設定できません。HTML5 プロポーザルでは、指定されたドメインプロパティへ割り当てが許可されるのかを判定するアルゴリズム (英語) が正式化され、特に割り当てる値が現在の値のサフィックスであることが義務付けられます。

Internet Explorer 7 では下記の呼び出しは成功します。

// document.domain の初期値は app1.example.com

document.domain = "app1.example.com"; // 1. 初期値として設定されるドメインプロパティ

document.domain = "example.com"; // 2. " 曖昧な " ドメイン

document.domain = "app1.example.com"; // 3. " 厳密な " ドメイン

Internet Explorer 8 や他のブラウザーでは、三番目の割り当ての app1.example.com はこの時点の値である example.com のサフィックスでないため、例外が発生します。

簡単にいえば、曖昧な document.domain を指定した場合、再度厳密な指定を行うことはできません 。

異なるドメインからデータを相互交換する必要のある Web アプリケーションは document.domain の調整より、むしろ postMessage() (英語) か XDomainRequest APIs (英語) の利用を検討した方がよいでしょう。

フレーム指定の制限

HTML5 では、あるフレームが他の名前が付けられたフレームやウィンドウを指定するためにWindows.open() (英語) を呼び出す際の targetname パラメーターの使用が許可される状況も規定 (英語) しています。

この規定はウィンドウインジェクションに関する脆弱性の抑止に役立つことを意味します。ウィンドウインジェクション攻撃ではブラウザーフレーム中の悪意のある Web サイトが、信頼できる Web ページのフレームやポップアップを "ハイジャック" しようと企てます。

例えば https://contoso.com が helpPage という名前のポップアップウィンドウを開こうとするシナリオを想定してください。

window.open("helpTopic.htm", "helpPage", "height=200,width=400");

もし http://evil.example.com という別のページがこのウィンドウの乗っ取りを企む場合は、このようになります :

window.open("spoof.htm", "helpPage", "height=200,width=400");

Contoso.com の helpPage ウィンドウに誘導される代わりに、spoof.htm が新しいブラウザーウィンドウで開きます。Internet Explorer 7 と 8 ですべてのウィンドウで常にアドレスバーを表示していることに加え、この新しい制限によって、ウィンドウインジェクションによるなりすましは更に説得力を失います。

MIME 処理 :Sniffing オプトアウト

IE8 Security Part V (英語) で取り上げた Internet Explorer の MIME-Sniffing 機能は信頼できないコンテンツを配信するサーバーのせいでセキュリティの問題を引き起こす可能性があります。そこで特定の HTTP レスポンスに対して MIME-Sniffing 機能を無効にするための、新しい Content-Type 属性 ("authoritative" という名前) をお知らせしていました。

過去二か月にわたり、Content-Type に新しい属性を使用することがサーバー管理者とって頭痛の種になっているという重大な反響を受け取りました。これを受け、このオプションを見直し単独の HTTP レスポンスヘッダーに置き換えました。新しい X-Content-Type-Options レスポンスヘッダーの値に nosniff を設定して送信すると、Internet Explorer が MIME Sniffing 機能で content-type 宣言を回避するのを防止できます。

例えば、以下のような HTTP レスポンスを付与します。

HTTP/1.1 200 OK

Content-Length: 108

Date: Thu, 26 Jun 2008 22:06:28 GMT

Content-Type: text/plain;

X-Content-Type-Options: nosniff

<html>

This page renders as HTML source code (text) in IE8.

</body>

</html>

Internet Explorer 6 と 7 はこのテキストを HTML として解釈します。

Internet Explorer 8 はこのページをプレーンテキストとして描画します。

信頼できない内容をホストしているサイトでは X-Content-Type-Options: nosniff ヘッダーを利用することで text/plain ファイルが他の何かに判定されないよう設定できます。

XSS 攻撃界面の削減 : Internet Explorer 8 標準モードでの CSS Expression 関数の無効化

"ダイナミックプロパティ" として知られる CSS の Expression 関数は高い処理能力を必要とする独自拡張です。 CSS Expression 関数はまた、サーバー側の XSS フィルターを回避するために攻撃者にとっても一般的に利用されます。

Internte Explorer 8 Beta 2 では、CSS Expression 関数は Internet Explorer 8 標準モードにおいてサポートされません。下位互換性を維持するため Internet Explorer 7 互換モードと Quirks モードでは従来通りサポートされます。Internet Explorer 8 の XSS フィルターは XSS アタックの一環として CSS Expression を反映させる試みをブロックできますが、Internet Explorer 8 標準モードでこれらを無効にすることは処理能力の点でも有利になり、Web 標準への準拠も改善され、さらにスクリプトインジェクションに対する攻撃界面の削減にもつながります。

Intetnet Explorer 8 の XSS フィルターの詳細

Internet Explorer 8 の XSS フィルターの設計者である David Ross が Secure Windows Initiative (英語) に XSS フィルターの構造と実装の詳細に関する技術文書を発表しています。XSS フィルターがどうのようにして動作しているかの詳細に興味がある方は、ご一読ください。

お読みいただきありがとうございました。

Eric Lawrence
Program Manager
Internet Explorer Security

ページのトップへ