• [アーティクル]

Internet Explorer 8 のセキュリティ : 総合的な保護

更新日: 2008 年 7 月 2 日

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

翻訳元 : IE8 Security Part V: Comprehensive Protection (英語)


こんにちは Internet Explorer セキュリティ プログラム マネージャー Eric Lawrence です。先週の火曜日に Dean はブラウザーをより信頼性の高いものにする (英語) ための方針を説明しました。今回、我々が Internet Explorer 8 のセキュリティ機能を開発した際に行った価値のある投資の概要を共有できることに感動しています。この投稿の長さからご推察いただけると思いますが、Internet Explorer 8 は多岐に渡るセキュリティ関連の成果が含まれています。エンドユーザーは、Internet Explorer 8 にアップグレードするだけで安全性の向上という利益が得られます。ドメインの管理者はグループ ポリシーと IEAK を使い、ネットワークによりセキュアな設定をすることができます。Web 開発者は顧客と Web アプリケーションを保護する手助けとなる幾つかの新機能を利用できるようになります。

Internet Explorer 8 を設計するにあたって、我々セキュリティ チームは、現実によく行われている攻撃と、その傾向から考えられる攻撃者達が次に注目する可能性のある攻撃の手法に着目しました。セキュリティに関する新機能を構築するのと同時に、アクティビティや Web スライスといった強力な新機能が新しい攻撃の対象とならないように努力しました。計画の段階でおもな脅威を三つのカテゴリーに分類しました。Web アプリケーションの脆弱性、ブラウザーとそのアドオンの脆弱性、ソーシャル エンジニアリングの脅威。それぞれの脅威に応じた対抗策を提供することで、不当な行為に対する縦深陣による防御方法を開発しました。

Web アプリケーションの保護

クロス サイト スクリプティングからの保護

この数年間でクロスサイト スクリプティング (XSS) による攻撃はバッファー オーバーフローを用いるものを上回る最も一般的(英語) なソフトウェアの脆弱性を利用した攻撃手法となりました。Web アプリケーションの脆弱性を悪用した XSS 攻撃は Cookie やデータの盗聴、ページの改ざん、認証情報の盗用、もしくはさらなる外部攻撃の踏み台として利用することを目的としています。

Internet Explorer 8 は「reflection」と呼ばれる XSS 攻撃をブロックすることで XSS 攻撃の脅威を緩和します。Internet Explorer 8 の XSS フィルター機能は、注入されたスクリプトを取り除き、その実行を阻止するヒューステリック型の緩和機能です。この防御機能については以下のDavid の投稿をご確認ください : IE8 Security Part IV - The XSS Filter

XSS フィルターはこのような不当行為に対して有効な対抗策を提供しますが、現時点ではInternet Explorer 8 でしか利用できません。Web 開発者がさらなる防御手段を用意し、Web サイトから XSS に関する脆弱性を取り除く必要があります。サーバー サイドで XSS を防ぐのはブラウザーでそれを実行するよりはるかに簡単です。端的には「ユーザーの入力を信用しないでくださいするな (英語)」ということになります。大部分の Web プラットフォーム テクノロジーは複数の除去 (サニタイズ) 技術を提供しています - ASP.NET  環境を利用しているのであれば、Microsoft Anti-Cross Site Scripting Library (英語) の利用をご検討ください。

さらに XSS による Cookie の盗用を防ぐため、重要な Cookie (特に認証に利用されるものなど) については HttpOnly属性 (英語) の付与によって保護すべきです。

より安全なマッシュアップ

XSS フィルターによって、サーバー間ナビゲートを悪用した反射型の XSS 攻撃の危険性は軽減されますが、Web 2.0 の世界においては、Web アプリケーションによるクライアントでのマッシュアップ技術 の利用は増加しつつあります。ほとんどのマッシュアップはサードパーティのスクリプトをマッシュアップするページに単純な SCRIPT SRC タグ (英語) によって直接挿入する安全でない方法で構築されています。これらのスクリプトはサードパーティにDOM への無制限アクセスが許可されていたり、Cookie に HttpOnly の設定がないことが多いのです。

開発者がより安全なマッシュアップを行う手助けをするため、Internet Explorer 8 には HTML 5 のクロス ドキュメント メッセージング機能 をサポートしました。この機能は DOM を分離したまま、IFRAME 間の通信をより安全に行うことができます。また異なるドメイン間でデータを安全に共有することができる XDomainRequest (英語) も導入しました。

Cross Document Messaging と XDomain Request の導入は安全なマッシュアップのために役立ちますが、重大な脅威は依然として存在します。どちらの方法を利用しても、サードパーティのフレーム、もしくはサーバーからのストリング データにスクリプトを含めることは可能です。もし利用者がやみくもにそのストリングを DOM に挿入した場合、スクリプト インジェクション攻撃が成立する可能性があります。という訳で、スクリプト インジェクション攻撃の可能性を軽減するドメイン間通信に関する二つの新技術を紹介できることを幸せに思います。

より安全なマッシュアップ : HTML のサニタイズ

Internet Explorer 8 は toStaticHTML と呼ばれる Windows オブジェクトを制御する新しいメソッドが搭載されています。HTML のストリングがこの機能に渡されると、潜在的に実行される可能性のあるスクリプトの部分はそのストリングを返す前に除去されます。内部的処理としては、以前に紹介した サーバー サイドで実行される Microsoft Anti-Cross Site Scripting Library (英語) と同じ技術を元にしています。

例えば、toStaticHTML を利用することで、postMessage によって受信した HTML を、スクリプトを実行することなく、基本的な HTML 構文のみを解釈できます。

document.attachEvent('onmessage',function(e) {

    if (e.domain == 'weather.example.com') {

        spnWeather.innerHTML = window.toStaticHTML(e.data);

    }

}

呼び出し:

window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");

結果:

This is some <b>HTML</b> with embedded script following... !

より安全なマッシュアップ : JSON のサニタイズ

JavaScript Object Notation (JSON (英語)) はマッシュアップされたコンポーネント間の通信でしばしば用いられる、軽量の JavaScript Object の表記方法です。残念なことにマッシュアップの多くは安全でない方法で JSON を利用しています。潜在的にスクリプトが実行されてしまう可能性のある Eval (英語) メソッドを利用して JSON のストリングを JavaScript オブジェクトに復元する手法に依存しているからです。セキュリティを重視する開発者は JSON オブジェクトが実行可能なスクリプトを含んでいないかを確認するため JSON-parser (英語) を利用しますが、この方法はパフォーマンスの低下を招きます。

Internet Explorer 8 は JSON を取り扱う機能として ECMA Script 3.1 プロポーザル (Douglas Crockford 氏の json2.js API (英語) を利用します) を実装します。JSON.stringify メソッドは Script オブジェクトを JSON ストリングに変換し、JSON.parse はストリングを安全に Java Script オブジェクトに変換します。この新しいネイティブな JSON メソッドは、Java Script エンジンそのものと同じコードを利用することによって、他のネイティブでない方式に比べ、劇的なパフォーマンスの改善が得られました。DOM へのインジェクションを狙うストリングが含まれるオブジェクトは、先述のとおり toStaticHTML 機能によって阻止することが可能となります。

下記の例では JSON と HTML のサニタイズの両方を使用しています。

<html>

<head><title>XDR+JSON Test Page</title>

<script>

if (window.XDomainRequest){

      var xdr1 = new XDomainRequest();

      xdr1.onload = function(){

           var objWeather = JSON.parse(xdr1.responseText);

           var oSpan = window.document.getElementById("spnWeather");

           oSpan.innerHTML = window.toStaticHTML("Tonight it will be <b>"

                             + objWeather.Weather.Forecast.Tonight + "</b> in <u>" 

                             + objWeather.Weather.City+ "</u>.");

      };

      xdr1.open("POST", "http://evil.weather.example.com/getweather.aspx");

      xdr1.send("98052");

}

</script></head>

<body><span id="spnWeather"></span></body>

</html>

仮に天気予報のサービスが悪意のある応答をしたとしてもスクリプト インジェクションは防がれます。

HTTP/1.1 200 OK

Content-Type: application/json

XDomainRequestAllowed: 1

{"Weather": {

  "City": "Seattle",

  "Zip": 98052,

  "Forecast": {

    "Today": "Sunny", 

    "Tonight": "<script defer>alert('bang!')</script>Dark",

    "Tomorrow": "Sunny"

  }

}}

MIME 処理の変更

Web サーバーから送信されるファイルにはそれぞれのファイルの性質 (例えば、画像、テキスト、アプリケーションなど) を表す MIME Type (英語) (Content-type とも呼ばれます) が付与されます。互換性を維持するため、Internet Explorer はダウンロードしたファイルの Content-type を特定する MIME Sniffing (英語) 機能が搭載されています。Internet Explorer はいくつかの場合にサーバーから指定されたものとMIME Type が異なっていると報告することがあります。たとえば、Internet Explorer  が HTTP 応答ヘッダーに Content-Type :text/plain と記述されているファイルの中に HTML コンテンツを見つけた場合、Internet Explorer はこのコンテンツを HTML として描画することを決定します。なぜなら、Web 上にあるいくつかのレガシーなサーバー( 例えば、すべてのファイルに test/plain を付与するものなど) のため、MIME-sniffing は互換性を維持するために重要な機能です。

残念なことに MIME-sniffing は信頼のおけないコンテンツを配信するサーバーによってセキュリティ的な問題を引き起こすこともあります。たとえば、匿名ユーザーによって投稿される画像を共有するための Web サービスを考えてみましょう。攻撃者はスクリプトを JPEG ファイルに巧みに偽装してアップロードし、不用心な攻撃対象にこのファイルへのリンクを送ります。この方法でこのユーザーの Cookie を盗用したり、偽のページを作成することができるかも知れません。

この問題に対応するため、Internet Explorer 8 が MIME-Type を判定するためのコードにいくつもの変更を加えました。

MIME 処理 : Upsniff の制限

まず "Upsniff" を制限し、Internet Explorer 8 が image/* の Content-type を付与して送信されたファイルを HTML もしくは Script として処理しないようにします。たとえファイルにスクリプトが含まれていたとしても、サーバーが画像ファイルであると主張するファイルについては、Internet Explorer は埋め込まれているスクリプトを実行しません。この変更により、サーバー側で対応をしなくとも、画像共有サイトを利用した攻撃を抑制できるようになります。この変更が既定の動作になりますが、サーバーが HTML ファイルやスクリプトを image/* として送信することはまずないので、互換性への影響は最小限にとどまります。

MIME 処理 : Sniffing オプトアウト

つぎに Web アプリケーションが MIME Sniffing をオプトアウトできる機能を提供します。Internet Explorer の MIME Sniffing 機能は HTTP 応答ヘッダーに authoritative=true が付与されているコンテンツに対するスニッフィングを行いません。

例えば HTTP 通信で以下のような応答を受信した場合、

HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain; authoritative=true;

<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>

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

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

信頼できないコンテンツをホストしているサイトは authoritative 属性を設定することで、text/plain ファイルが sniffing 機能により他の種類として扱われないよう設定できます。

MIME 処理 : 強制保存

最後に、信頼できない HTML ファイルを扱う必要がある Web アプリケーションのため、信頼できないコンテンツからサイトのセキュリティを守るための助けとなる機能を導入しました。新しく導入された X-Download-Options ヘッダーに noopen を設定した場合、ユーザーがファイルを直接開くことを防ぐことができます。この場合、ユーザーはまずローカルにファイルを保存する必要があります。ローカルに保存されたファイルをあとで開いたとしても、それはサイトのセキュリティには影響を及ぼしませんので、スクリプト インジェクションを防ぐ手助けとなります。

HTTP/1.1 200 OK

Content-Length: 238

Content-Type: text/html

X-Download-Options: noopen

Content-Disposition: attachment; filename=untrustedfile.html

これらの新しい Web アプリケーションの防御機能は、Web アプリケーションをより安全に構築することを可能とします。

ローカル ブラウザー保護

Web アプリケーションへの攻撃が一般化する一方で、攻撃者の興味は一般ユーザーのコンピューターを感染させることにも常に注がれています。Web アプリケーション、個人情報、ローカルリソースを保護するためブラウザーにセキュリティ ポリシーが効果的に適用されるためには、ブラウザーへの攻撃を阻止する必要があります。Internet Explorer 7 はプロテクトモード (英語) 、ActiveX オプトイン (英語) 、ゾーンロックダウン機能 (英語) を搭載してこの分野に多大なる投資を行いました。ブラウザー本体の強化の結果として、攻撃者はより脆弱なブラウザーのアドオンへの攻撃を増加させています。

Internet Explorer 8 では、アドオンのセキュリティの改善と攻撃対象領域の削減を行い、いくつもの新機能を搭載することで、開発者とユーザーのエクスペリエンスを向上させます。

アドオンのセキュリティ

このセキュリティに関するブログ記事は DEP/NX メモリ保護機能についての議論 で始まり、Windows Server 2008 、Windows Vista SP1 、Windows XP SP3 上で動作する Internet Explorer 8 はメモリ保護機能を有効化することになりました。DEP/NX は非実行領域のメモリ上でコードを動作させようとする攻撃を防ぐ助けとなります。DEP/NX 機能は Address Space Layout Randomization (ASLR (英語)) のような別のテクノロジーと連携することで、バッファーオーバーフロー攻撃のようなメモリ関連の脆弱性を利用した攻撃を行うことを困難にします。何よりも、この保護機能は Internet Explorer とそのアドオンの両方に適用されます。この保護機能については、以前の投稿で詳しく確認することができます。IE8 Security Part I: DEP/NX Memory Protection 。

フォローアップの投稿 で Matt Crowley は Internet Explorer 8 の ActiveX 関連の改善点について説明し、従来のバージョンから引き継がれているActive X に関連するセキュリティの機能についてまとめています。Internet Explorer 8 での改善点の鍵となるのは Pre-Site Active X と呼ばれる、コントロールの不正な再利用を阻止するための防御機能です。また Internet Explorer 8 は管理者ではないユーザーが Active X コントロールをインストールすること (英語) をサポートしており、ドメイン管理者が管理者権限を持たないユーザーのActive X コントロールの設定を構成できます。「IE8 セキュリティ パート II: ActiveX の機能向上」を読めば、この改善点についての詳細を確認できます。Active X コントロールの開発者向けには、「ActiveX セキュリティ : 強化点とベスト プラクティス」が最適です。

保護モード

Windows Vista で動作する Internet Explorer 7 に搭載された保護モードは、一見安全なソフトウェアに見える仮面を被ったものを含め、ソフトウェアの脆弱性を狙う悪意のあるコードが自動でインストールされることを防ぎ、Internet Explorer と拡張機能から様々な脅威を削減する手助けとなります。Internet Explorer 8 では、アドオンの開発者が保護モードで動作するブラウザーのインスタンスを容易に制御し、相互運用できるように保護モードの API の一部に改善を行いました。Improved Protected Mode API Whitepaper (英語) にこれらの改善点の詳細が記載されています。

パフォーマンスの向上と互換性の確保のため、Internet Explorer 8 はイントラネット ゾーンの保護モードを既定で無効にしています。Internet Explorer 7 はプロテクト モードを切り替える際に新しいウィンドウを作り、新しいプロセスを駆動する必要があったため、操作性を維持するためにイントラネットゾーンでも既定値で有効になっていました。

Internet Explorer 8 は LCIE 機能により保護モードと非保護モードのタブを同じウィンドウ内で制御することを可能としたため、ユーザーエクスペリエンス的な不快感を取り除きます。もちろん Internet Explorer 8 ではユーザーやドメインの管理者はイントラネットゾーンの保護モードの設定を必要に応じて有効化することができます。

アプリケーション プロトコルの警告

アプリケーション プロトコル ハンドラーはサードパーティ製のアプリケーション (ストリーミング メディア プレイヤーやインターネット電話のアプリケーションなど) が Web ブラウザーや他の Windows プログラムから直接起動することを可能にします。残念ながら、この機能は非常に強力であるため、この機能を対象とした攻撃が多数存在します。これはインターネットから入手した信頼性の低いコンテンツが引き金となるような脆弱性を内包したアプリケーションがプロトコルハンドラーとして登録されることで発生します。

Web ブラウズを信頼できるものにするため、Internet Explorer 8 ではアプリケーション プロトコルが起動する前に警告を表示する予定です。

縦深防御を提供するため、アプリケーション プロトコルを利用する開発者は Best Practices described on MSDN (英語) を確認することをお勧めします。

ファイルのアップロード制御

歴史的に見て、HTML の ファイル アップロード コントロール (input type=file) はかなりの数の公開された脆弱性の温床であり続けました。この問題を解決するため、このコントロールの動作について二つの変更を加えました。

ユーザーの入力するローカルのファイル パスをキーストロークの監視によって盗む攻撃を防ぐため、ファイル パスの編集ボックスを読み取り専用としました。ファイルをアップロードする場合、ファイルの参照ダイアログを利用して、ファイルを指定する必要があります。

さらに「サーバーにファイルをアップロードするときにローカル ディレクトリのパスを加える」の設定について、インターネット ゾーンの既定値を無効に変更しました。この変更により、インターネット上にローカルのファイル システムに関する潜在的に機密性のある情報が流出する危険を防止します。例えば、C:\users\ericlaw\documents\secret\image.png をアップロードする場合、Internet Explorer 8 はファイル名である image.png  のみを送信します。

ソーシャルエンジニアリングの防止

ここ数年、ブラウザーのセキュリティ防御機能が向上するにともなって、Web 上での犯罪はますますソーシャルエンジニアリングへの依存度が増しています。より強化された防壁の突破を試みるのではなく、ユーザーに信用させて正門から侵入しようとする攻撃者が増加しています。

Internet Explorer 8 はサイトや信頼できる認証機関から集めた情報に基づいて、ブラウズするサイトが安全かを判断する手助けになる機能を搭載しました。

アドレスバーの改善

ドメイン強調表示機能 は Internet Explorer 8 beta 1 から搭載された Web アドレス (URL) を簡単により簡単に判断できる手助けとなる機能です。ドメイン名はURL の中でも最も安全性の確認に関連するため、黒字で表示され、サイトの制御に利用されるクエリストリングやパスなどはグレイで表示されます。

Extended Validation SSL 証明書 などの他の技術と組み合わせることで、Internet Explorer 8 の改良されたアドレスバーはユーザーが信頼できるサイトだけに個人情報を送信する手助けとなります。

SmartScreen® Filter

Internet Explorer 7 はユーザーが既知のフィッシング詐欺サイトをブラウズしようとした時に警告するよう設計された動的なセキュリティ機能であるフィッシングフィルター機能 を導入しました。

フィッシング フィルター機能 ( 週に何百万ものフィッシング攻撃を防御しています) の成功に基づいて、Internet Explorer 8 のために SmartScreen Filter を開発しました。SmartScreen Filter はフィッシング詐欺だけではなく、コンピューターを攻撃したり、個人情報を盗もうとする悪意のあるソフトウェア- マルウェアを配布することが知られているサイトへのアクセスもブロックします。SmartScreen は、悪意のあるソフトウェアからより広範囲の保護を提供するため、Windows Defender (英語) や Windows Live OneCare といった他のテクノロジーとも連携します。

以前の投稿で SmartScreen 機能の詳細について確認することができます: Internet Explorer 8 のセキュリティ Part III: SmartScreen Filter

まとめ

セキュリティを確保することは信頼できるWeb ブラウズの中心的な役割であり、Internet Explorer 8 は Web のセキュリティ対策の進化させるために取り組んだ大きな機能改善を含みます。悪者が「タオルを投げて」諦めることは無さそうですが、Internet Explorer チームはユーザーを保護し、Web アプリケーションのセキュリティを強化する新しい方法を提供すべく、一生懸命努力し続けます。

信頼のおけるブラウズのためのプライバシー、信頼性、そしてビジネスプラクティスについての取組については引き続き IEBlog にご注目ください。

Eric Lawrence
Program Manager
Internet Explorer Security

　

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