Windows Presentation Foundation のセキュリティ方針 - プラットフォームセキュリティ

[アーティクル]
09/17/2008

更新 : 2007 年 11 月

Windows Presentation Foundation (WPF) にはさまざまなセキュリティサービスが用意されていますが、基になるプラットフォーム (オペレーティングシステム、CLR、および Internet Explorer) のセキュリティ機能も活用されています。WPF では、これらの層の組み合わせにより、強力な多重防御のセキュリティモデルが実現されています。このセキュリティモデルは、次の図に示すように、単一点障害の排除を目指しています。

WPF セキュリティの図

ここからは、これら各層の機能について、WPF 関連の機能に絞って説明します。

このトピックには次のセクションが含まれています。

オペレーティングシステムのセキュリティ
共通言語ランタイムのセキュリティ
Microsoft Internet Explorer のセキュリティ
関連トピック

オペレーティングシステムのセキュリティ

WPF では、Windows XP SP2 以降のオペレーティングシステムが必要です。Windows XP SP2 のコアには、WPF で構築されたものを含むすべての Windows アプリケーションのセキュリティの基盤となるいくつかのセキュリティ機能が用意されています。Windows Vista では、WPF のセキュリティ機能が組み込まれ、さらに拡張されています。ここでは、WPF にとって重要なこれらの一連のセキュリティ機能と、WPF がそれらのセキュリティ機能との統合によってさらに進んだ多重防御を実現しているしくみについて説明します。

Microsoft Windows XP Service Pack 2 (SP2)

Windows XP SP2 では、Windows の全般的な見直しと強化に加えて、ここで取り上げる次の 3 つの重要な機能が追加されています。

/GS コンパイル
Microsoft Windows Update.

/GS コンパイル

Windows XP SP2 では、バッファオーバーランへの対策として、WPF のすべての依存関係 (CLR など) を含む多くのコアシステムライブラリが再コンパイルされています。これは、C/C++ コマンドラインコンパイラで /GS パラメータを使用することによって行われます。バッファオーバーランに対しては積極的な防止策が必要ですが、不注意から、または意図的にバッファオーバーランによってもたらされる潜在的な脆弱性に対する多重防御の 1 つとして、/GS コンパイルが利用されています。

これまでバッファオーバーランは、数多くの深刻なセキュリティ攻撃の原因となってきました。バッファオーバーランは、攻撃者がコードの脆弱性を利用して、バッファの境界を越えて書き込まれる悪質なコードを挿入することによって引き起こされます。その後、攻撃者は、自分のコードが実行されるように関数のリターンアドレスを上書きすることによって、コードを実行しているプロセスを乗っ取ることができます。それによって実行される悪質なコードでは、乗っ取ったプロセスと同じ特権で任意のコードを実行できます。

大まかに言うと、/GS コンパイラフラグは、ローカルの文字列バッファを持つ関数のリターンアドレスを保護するための特殊なセキュリティ Cookie を挿入することにより、バッファオーバーランを防止します。関数が戻ると、そのセキュリティ Cookie が前の値と比較されます。値が変更されていた場合は、バッファオーバーランが発生している可能性があるため、エラーによってプロセスが停止されます。こうしてプロセスを停止することで、潜在的に悪質なコードの実行を防ぐことができます。詳細については、「/GS (バッファのセキュリティチェック)」を参照してください。

WPF は、WPF アプリケーションにさらなる防御層を追加するために、/GS フラグを使用してコンパイルされます。

Microsoft Windows Update の強化

Windows XP SP2 では Microsoft Windows Update も強化されており、更新のダウンロードとインストールのプロセスが簡単になっています。これらの変更により、システムを (特にセキュリティ更新プログラムに関して) 最新の状態に維持しやすくなるため、WPF ユーザーのセキュリティが大幅に強化されます。

Windows Vista

Windows Vista の WPF ユーザーは、"最小特権ユーザーアクセス"、コード整合性チェック、特権の分離など、オペレーティングシステムのさらなるセキュリティ強化の恩恵を受けることができます。

ユーザーアカウント制御 (UAC)

現在、多くの Windows ユーザーが管理者特権を使用してアプリケーションを実行しています。これは、インストール、実行、またはその両方で管理者特権を必要とするアプリケーションが多いためです。たとえば、既定のアプリケーション設定をレジストリに書き込むには管理者特権が必要です。

管理者特権を使用して実行するということは、管理者特権を付与されたプロセスでアプリケーションが実行されるということです。これは、セキュリティ上問題になります。管理者特権で実行されているプロセスが悪質なコードによって乗っ取られると、それらの特権は、重要なシステムリソースへのアクセス権を含め、そのコードに自動的に継承されるからです。

このセキュリティの脅威を防止するために、必要最小限の特権でアプリケーションを実行するという方法があります。これは最小特権の原則と呼ばれ、Windows Vista オペレーティングシステムのコア機能の 1 つになっています。この機能はユーザーアカウント制御 (UAC) と呼ばれ、Windows Vista では主に次の 2 つの形で使用されています。

ほとんどのアプリケーションは、既定では UAC 特権で実行されます。これは、ユーザーが管理者であっても変わりません。管理者特権を必要とするアプリケーションのみが管理者特権で実行されます。管理者特権で実行するアプリケーションは、アプリケーションマニフェストかセキュリティポリシーのエントリで明示的に指定されている必要があります。
仮想化のような互換性ソリューションが提供されます。たとえば、多くのアプリケーションは、C:\Program Files のような制限された場所への書き込みを行おうとします。UAC で実行されるアプリケーションには、管理者特権がなくても書き込みを行うことができるユーザーごとの場所が別に用意されます。UAC で実行されるアプリケーションでは、UAC によって C:\Program Files が仮想化されるため、実際にはユーザーごとの別の場所に書き込まれていても、アプリケーションからは C:\Program Files に書き込まれているように見えます。この種の互換性操作により、Windows Vista では、従来は UAC で実行できなかった多くのアプリケーションを実行できるようになっています。

コード整合性チェック

Windows Vista には、読み込み時や実行時に悪質なコードがシステムファイルやカーネルに挿入されるのを防ぐための詳細なコード整合性チェックが組み込まれています。これは、単なるシステムファイルの保護にとどまりません。

ブラウザによってホストされるアプリケーションの制限された権限のプロセス

ブラウザによってホストされる WPF アプリケーションは、インターネットゾーンのサンドボックスで実行されます。WPF と Microsoft Internet Explorer の統合により、この保護は追加のサポートによって拡張されます。

Internet Explorer 6 Service Pack 2 と Internet Explorer 7 for XP

WPF では、さらなる保護のために、XAML ブラウザアプリケーション (XBAP) のプロセス特権を制限することによってオペレーティングシステムのセキュリティを活用しています。ブラウザによってホストされる WPF アプリケーションが起動する前に、プロセストークンから不要な特権を削除するホストプロセスがオペレーティングシステムによって作成されます。たとえば、ユーザーのコンピュータのシャットダウン、ドライバの読み込み、コンピュータ上のすべてのファイルの読み取りアクセスなどの特権が削除されます。

Internet Explorer 7 for Vista

Windows Internet Explorer 7 では、WPF アプリケーションは保護モードで実行されます。具体的には、XAML ブラウザアプリケーション (XBAP) は中レベルの整合性で実行されます。

多重防御層

一般に XAML ブラウザアプリケーション (XBAP) はインターネットゾーンアクセス許可セットによってサンドボックス化されるため、これらの特権を削除しても XAML ブラウザアプリケーション (XBAP) の互換性が損なわれることはありません。代わりに、追加の多重防御層が作成されます。つまり、サンドボックス化されたアプリケーションが他の層を悪用してプロセスを乗っ取ることができたとしても、そのプロセスには限られた特権しかありません。

「Using a Least-Privileged User Account」を参照してください。

共通言語ランタイムのセキュリティ

共通言語ランタイム (CLR) には、検証と検査、コードアクセスセキュリティ (CAS)、セキュリティクリティカルな方法など、重要なセキュリティの利点がいくつかあります。

検証と検査

CLR では、アセンブリの分離と整合性を実現するために検証のプロセスが使用されています。CLR の検証では、アセンブリの移植可能な実行可能 (PE: Portable Executable) ファイル形式について、アセンブリの外部を指すアドレスがないかどうかを検証することによって、アセンブリの分離が確認されます。そのほか、アセンブリ内に埋め込まれているメタデータの整合性も検証されます。

CLR のセキュリティでは、タイプセーフの保証、一般的なセキュリティの問題 (バッファオーバーランなど) の防止、およびサブプロセスの分離によるサンドボックス化の実現のために、検査の概念が使用されています。

マネージアプリケーションは Microsoft Intermediate Language (MSIL) にコンパイルされます。マネージアプリケーションのメソッドが実行されると、MSIL が Just-In-Time (JIT) コンパイルによってネイティブコードにコンパイルされます。JIT コンパイルに含まれる検査のプロセスでは、安全性と信頼性に関する数多くの規則が適用されて、コードに次のような問題がないかが確認されます。

型のコントラクトに違反している。
バッファオーバーランを引き起こす。
メモリに対して過度のアクセスがある。

検査の規則に従っていないマネージコードは、信頼されたコードと見なされない限り、実行を許可されません。

検査可能なコードのこの利点は、WPF が .NET Framework に基づいて構築されている大きな理由の 1 つです。検査可能なコードが使用されている範囲では、潜在的な脆弱性が悪用される可能性が大幅に減少します。

コードアクセスセキュリティ

クライアントコンピュータでは、ファイルシステム、レジストリ、印刷サービス、ユーザーインターフェイス、リフレクション、環境変数など、マネージアプリケーションがアクセスできるさまざまなリソースが公開されています。マネージアプリケーションでクライアントコンピュータのリソースにアクセスするには、そのための .NET Frameworkコードアクセスセキュリティ (CAS) アクセス許可が必要です。CAS のアクセス許可は、CodeAccessPermission のサブクラスです。CAS では、マネージアプリケーションがアクセスできる各リソースにつき 1 つのサブクラスが実装されます。

マネージアプリケーションが実行を開始するときに CAS によって付与されるアクセス許可のセットを、アクセス許可セットと呼びます。アクセス許可セットは、アプリケーションが提供する証拠によって決定されます。WPF アプリケーションの場合、提供される証拠はアプリケーションが起動された場所 (ゾーン) です。CAS では、次のゾーンが識別されます。

マイコンピュータ。クライアントコンピュータから起動されたアプリケーション (完全信頼)。
ローカルイントラネット。イントラネットから起動されたアプリケーション (部分信頼)。
インターネット.インターネットから起動されたアプリケーション (最小限の信頼)。
信頼済みサイト。ユーザーによって信頼済みとして識別されたアプリケーション (最小限の信頼)。
信頼されないサイト。ユーザーによって信頼できないとして識別されたアプリケーション (信頼されていない)。

CAS には、これらの各ゾーンに対してそれぞれ定義済みのアクセス許可セットが用意されています。これらのアクセス許可セットには、それぞれに関連付けられた信頼レベルに対応するアクセス許可が含まれています。以下に例を示します。

FullTrust。マイコンピュータ ゾーンから起動されたアプリケーションのアクセス許可セット。すべてのアクセス許可が付与されます。
LocalIntranet。ローカルイントラネット ゾーンから起動されたアプリケーションのアクセス許可セット。クライアントコンピュータのリソースへの適度なアクセスを提供するアクセス許可のサブセットが付与されます。これには、分離ストレージ、無制限の UI アクセス、無制限のファイルダイアログ、制限されたリフレクション、環境変数への制限されたアクセスが含まれます。レジストリのような重要なリソースへのアクセス許可は提供されません。
インターネット.インターネットゾーンや信頼済みサイト ゾーンから起動されたアプリケーションのアクセス許可セット。クライアントコンピュータのリソースへの制限されたアクセスを提供するアクセス許可のサブセットが付与されます。これには、分離ストレージ、ファイルオープンのみ、および制限された UI が含まれます。このアクセス許可セットでは、基本的に、アプリケーションはクライアントコンピュータから分離されます。

CAS では、信頼されないサイト ゾーンから起動されたと識別されたアプリケーションに対してはアクセス許可が一切付与されません。したがって、それらのアプリケーションの定義済みアクセス許可セットは存在しません。

次の図は、ゾーン、アクセス許可セット、アクセス許可、およびリソースの関係を示しています。

CAS アクセス許可セット

インターネットゾーンのセキュリティサンドボックスの制限は、XBAP が WPF などのシステムライブラリからインポートするコードにも同じように適用されます。これにより、WPF を含め、すべてのコードが制限されることになります。しかし、インターネットゾーンのセキュリティサンドボックスで有効になるアクセス許可だけでは、XBAP を実行するために必要な機能を実行することはできません。

たとえば、次のページを含む XBAP アプリケーションがあったとします。

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

この XBAP を実行するには、基になる WPF コードで、呼び出し元の XBAP では利用できない以下の機能を実行する必要があります。

描画のためのウィンドウハンドル (hWnd) の作成
メッセージのディスパッチ
Tahoma フォントの読み込み

セキュリティの観点から見た場合、サンドボックス化されたアプリケーションから直接これらの操作にアクセスできるようにすることは致命的です。

しかし、WPF では、システム特権を使用することにより、サンドボックス化されたアプリケーションの代わりにこれらの操作が実行され、この状況に対処することができます。すべての WPF 操作は、XBAP のアプリケーションドメインの制限されたインターネットゾーンのセキュリティアクセス許可に対してチェックされますが、WPF には (他のシステムライブラリと同様に)、すべてのアクセス許可を含むアクセス許可セットが付与されています。

したがって、WPF が受け取るシステム特権が、ホストアプリケーションドメインのインターネットゾーンのアクセス許可セットによって制御されないようにする必要があります。

WPF では、アクセス許可の Assert メソッドを使用してこれを実現します。このしくみを次のコードに示します。

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Assert の本質的な役割は、WPF が必要とする無制限のアクセス許可が XBAP のインターネットゾーンのアクセス許可によって制限されないようにすることです。

プラットフォームの観点から見た場合、WPF には Assert を正しく使用する責任があります。Assert が不正に使用されると、悪質なコードによって権限を昇格される可能性があります。したがって、Assert は必要なときにのみ呼び出すようにして、サンドボックスの制限が損なわれないようにすることが大切です。たとえば、サンドボックス化されたコードでは任意のファイルを開くことはできませんが、フォントを使用することはできます。WPF で Assert を呼び出して、サンドボックス化されたアプリケーションに代わって WPF が、目的のフォントが含まれていることがわかっているファイルを読み取れるようにすると、サンドボックス化されたアプリケーションでフォント機能を使用できるようになります。

ClickOnce の配置

ClickOnce は、.NET Framework に含まれる包括的な配置テクノロジで、Microsoft Visual Studio と統合されています (詳細については、「ClickOnce Deployment Overview」を参照してください)。スタンドアロンの WPF アプリケーションは、ClickOnce を使用して配置することができます。ブラウザによってホストされるアプリケーションは、ClickOnce を使用して配置する必要があります。

ClickOnce を使用して配置されたアプリケーションでは、コードアクセスセキュリティ (CAS) の上にさらにセキュリティ層が追加されます。これは、ClickOnce で配置されたアプリケーションは、その性質上、必要なアクセス許可を要求するためです。これらのアプリケーションに対しては、要求されたアクセス許可のみが、配置元のゾーンのアクセス許可セットの範囲内で付与されます。アクセス許可のセットを (起動ゾーンのアクセス許可セットによって提供されるアクセス許可よりも少なくなるとしても) 必要なものみに縮小することによって、アプリケーションがアクセスできるリソースの数を最小限に抑えることができます。その結果、アプリケーションが乗っ取られた場合にクライアントコンピュータが被害を受ける可能性が減少します。

セキュリティクリティカルな方法

アクセス許可を使用して XBAP アプリケーションのインターネットゾーンサンドボックスを有効にする WPF コードに対しては、最大限のセキュリティ監査と制御を適用する必要があります。これを支援するために、.NET Framework には、権限を昇格させるコードを管理するための新たなサポートが用意されています。具体的には、権限を昇格させるコードを識別して、SecurityCriticalAttribute でマークすることができます。この方法を使用すると、SecurityCriticalAttribute でマークされていないすべてのコードは "透明" になります。逆に言えば、SecurityCriticalAttribute でマークされていないマネージコードに対しては権限の昇格が阻止されます。

セキュリティクリティカルな方法を使用すると、権限を昇格させる WPF コードを "セキュリティクリティカルカーネル" にまとめて、その他のコードを透明にすることができます。セキュリティクリティカルコードを分離することにより、WPF のエンジニアリングチームは、標準のセキュリティプラクティスの範囲を超えた追加のセキュリティ分析とソース管理をセキュリティクリティカルカーネルに対して集中させることができます (「Windows Presentation Foundation のセキュリティ方針 - セキュリティエンジニアリング」を参照してください)。

.NET Framework では、AllowPartiallyTrustedCallersAttribute (APTCA) でマークされたマネージアセンブリを作成し、ユーザーのグローバルアセンブリキャッシュ (GAC) に配置することによって、XBAP のインターネットゾーンサンドボックスを信頼されたコードで拡張することができます。アセンブリを APTCA でマークすると、インターネットの悪質なコードを含むあらゆるコードがそのアセンブリを呼び出せるようになるため、セキュリティ上のリスクがきわめて高くなります。この操作を行う場合は、細心の注意を払い、ベストプラクティスに従う必要があります。また、そのソフトウェアをインストールするには、ユーザーがそのソフトウェアを信頼することを選択する必要があります。

Microsoft Internet Explorer のセキュリティ

Microsoft Internet Explorer 6 (SP2) では、セキュリティの問題の削減やセキュリティの構成の単純化が実現されているほか、XAML ブラウザアプリケーション (XBAP) のユーザーのセキュリティを強化する機能がいくつか含まれています。これらの機能は、ユーザーが今まで以上にブラウジングエクスペリエンスを制御できるようにすることを目的としています。

IE6 SP2 以前のユーザーは、次のような問題を抱えていました。

不規則なポップアップウィンドウ。
わかりにくいスクリプトリダイレクト。
多数のセキュリティダイアログが表示される Web サイト。

中には、インストールユーザーインターフェイス (UI) になりすましたり、Microsoft ActiveX のインストールダイアログボックスを (ユーザーがキャンセルしているにもかかわらず) 繰り返し表示したりして、ユーザーをだまそうとする信頼できない Web サイトもあります。こうした手法によって、かなりの数のユーザーがだまされてスパイウェアアプリケーションをインストールしてしまっている可能性があります。

IE6 SP2 には、こうした問題を軽減する機能がいくつか含まれています。その中心にあるのは、ユーザー実行の概念です。IE6 SP2 では、アクションの前にユーザーがリンクやページの要素をクリックした場合に (ユーザー実行) そのことが検出され、同様のアクションがページ上のスクリプトによって呼び出された場合とは別に扱われます。その一例が IE6 SP2 に組み込まれているポップアップブロックです。ポップアップブロックでは、ページでポップアップが作成される前にユーザーがボタンをクリックした場合には、そのことが検出されます。これにより、IE6 SP2 では、害のないポップアップは許可され、ユーザーが要求していない無用なポップアップは阻止されます。ブロックされたポップアップは、新しい情報バーで処理されます。ここでユーザーは、ブロックを手動で無効にして、ポップアップを表示することができます。

同じユーザー実行のロジックは、[開く]/[保存] のセキュリティの確認にも適用されています。ActiveX のインストールダイアログボックスは、以前にインストールされたコントロールのアップグレードを表している場合を除き、常に情報バーで処理されます。こうした方策の組み合わせにより、不要なソフトウェアや悪質なソフトウェアのインストールを迫るサイトからユーザーが保護されるため、より安全で制御されたユーザーエクスペリエンスが実現されます。

これらの機能により、WPF アプリケーションをダウンロードしてインストールできる Web サイトを利用する際に IE6 SP2 を使用するユーザーも保護されます。これは、具体的に言うと、IE6 SP2 の強化されたユーザーエクスペリエンスにより、作成に使用されているテクノロジ (WPF など) に関係なく、悪質なソフトウェアや不正なソフトウェアをユーザーがインストールしてしまう可能性が減少するからです。WPF では、これらの保護に加えて、インターネットからのアプリケーションのダウンロードに役立つClickOnce も使用されています。XAML ブラウザアプリケーション (XBAP) はインターネットゾーンのセキュリティサンドボックス内で実行されるため、シームレスに起動することができます。一方、スタンドアロンの WPF アプリケーションを実行するには、完全信頼が必要です。これらのアプリケーションに対しては、起動プロセスの間にClickOnce によってセキュリティダイアログボックスが表示され、アプリケーションの追加のセキュリティ要件が使用されることが通知されます。ただし、これはユーザー実行でなければならず、これもまたユーザー実行のロジックによって制御されます。また、キャンセルすることもできます。

Internet Explorer 7 では、セキュリティに対する継続的な取り組みの一貫として、IE6 SP2 のセキュリティ機能が組み込まれ、拡張されています。