WPF セキュリティ戦略 - プラットフォーム セキュリティ

Windows Presentation Foundation (WPF) はさまざまなセキュリティ サービスを提供しますが、オペレーティング システム、CLR、Internet Explorer など、基になるプラットフォームのセキュリティ機能も利用します。 これらのレイヤーは、次の図に示すように、単一障害点を回避しようとする強力な多層防御セキュリティ モデルを WPF に提供するために組み合わされています。

このトピックの残りの部分では、WPF に関連するこれらの各レイヤーの機能について具体的に説明します。

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

Windows のコアには、WPF で構築されたものを含め、すべての Windows アプリケーションのセキュリティ基盤を形成するいくつかのセキュリティ機能が用意されています。 このトピックでは、WPF にとって重要なこれらのセキュリティ機能の幅と、WPF を統合して多層防御を提供する方法について説明します。

Microsoft Windows XP Service Pack 2 (SP2)

Windows の一般的なレビューと強化に加えて、このトピックで説明する Windows XP SP2 の 3 つの主要な機能があります。

• /GS コンパイル

• Microsoft Windows Update。

/GS コンパイル

Windows XP SP2 は、CLR などのすべての WPF 依存関係を含む多くのコア システム ライブラリを再コンパイルして保護を提供し、バッファー オーバーランを軽減します。 これは、C/C++ コマンド ライン コンパイラで /GS パラメーターを使用することで実現されます。 バッファー オーバーランは明示的に回避する必要がありますが、/GS コンパイルでは、意図せずまたは悪意を持って作成された潜在的な脆弱性に対する多層防御の例が提供されます。

これまで、バッファー オーバーランは、影響の大きいセキュリティの悪用の多くの原因でした。 バッファー オーバーランは、攻撃者がコードの脆弱性を利用して、バッファーの境界を超えて書き込む悪意のあるコードを挿入できる場合に発生します。 これにより、攻撃者は、関数のリターン アドレスを上書きして攻撃者のコードの実行を引き起こすことによって、コードが実行されているプロセスをハイジャックできます。 その結果、ハイジャックされたプロセスと同じ特権で任意のコードを実行する悪意のあるコードが生成されます。

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

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

Windows Vista

Windows Vista の WPF ユーザーは、"Least-Privilege ユーザー アクセス"、コード整合性チェック、特権の分離など、オペレーティング システムの追加のセキュリティ強化の恩恵を受けます。

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

現在、Windows ユーザーは管理者特権で実行する傾向があります。多くのアプリケーションでは、インストールまたは実行、またはその両方が必要です。 レジストリに既定のアプリケーション設定を書き込むことが 1 つの例です。

管理者特権を使用して実行するということは、管理者特権が付与されたプロセスからアプリケーションが実行されることを意味します。 このセキュリティへの影響は、管理者特権で実行されているプロセスをハイジャックする悪意のあるコードが、重要なシステム リソースへのアクセスを含め、それらの特権を自動的に継承することです。

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

• ユーザーが管理者であっても、UAC 特権を持つほとんどのアプリケーションを既定で実行する。管理者特権を必要とするアプリケーションのみが管理者特権で実行されます。 管理特権を使用して実行するには、アプリケーション マニフェストまたはセキュリティ ポリシーのエントリとして、アプリケーションを明示的にマークする必要があります。

• 仮想化などの互換性ソリューションを提供するため。 たとえば、多くのアプリケーションは、C:\Program Files などの制限された場所に書き込もうとします。 UAC で実行されているアプリケーションの場合、書き込み先の管理者特権を必要としないユーザーごとの別の場所が存在します。 UAC で実行されているアプリケーションの場合、UAC は C:\Program Files を仮想化して、書き込んでいると思われるアプリケーションが実際に代替のユーザーごとの場所に書き込まれるようにします。 この種の互換性作業により、オペレーティング システムは、UAC で以前に実行できなかった多くのアプリケーションを実行できます。

コード整合性チェック

Windows Vista には、より深いコード整合性チェックが組み込まれており、悪意のあるコードがシステム ファイルに挿入されたり、読み込み/実行時にカーネルに挿入されたりするのを防ぐことができます。 これは、システム ファイルの保護を超えています。

Browser-Hosted アプリケーションの制限付き権利プロセス

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

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

「Least-Privileged ユーザー アカウントの使用」を参照してください。

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

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

有効性確認と検証

アセンブリの分離と整合性を提供するために、CLR は検証のプロセスを使用します。 CLR 検証では、アセンブリの外部を指すアドレスのポータブル実行可能 (PE) ファイル形式を検証することで、アセンブリが確実に分離されます。 CLR 検証では、アセンブリ内に埋め込まれているメタデータの整合性も検証されます。

型の安全性を確保し、一般的なセキュリティの問題 (バッファー オーバーランなど) を防ぎ、サブプロセス分離によるサンドボックス化を有効にするために、CLR セキュリティでは検証の概念が使用されます。

マネージド アプリケーションは、Microsoft Intermediate Language (MSIL) にコンパイルされます。 マネージド アプリケーション内のメソッドが実行されると、その MSIL は Just-In-Time (JIT) コンパイルによってネイティブ コードにコンパイルされます。 JIT コンパイルには、コードで次のことが行われないように、多くの安全性と堅牢性の規則を適用する検証プロセスが含まれています。

• 型コントラクトに違反する

• バッファー オーバーランの導入

• メモリに無秩序にアクセスします。

検証規則に準拠していないマネージド コードは、信頼できるコードと見なされない限り実行できません。

検証可能なコードの利点は、WPF が .NET Framework 上に構築される主な理由です。 検証可能なコードが使用される限り、考えられる脆弱性を悪用する可能性が大幅に低下します。

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

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

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

• マイ コンピューター。 クライアント コンピューターから起動されたアプリケーション (完全に信頼済み)。

• ローカル イントラネット。 イントラネットから起動されたアプリケーション。 （ある程度信頼されています）

• インターネット。 インターネットから起動されたアプリケーション。 (最小信頼)。

• 信頼済みサイト。 ユーザーが信頼済みとして識別するアプリケーション。 (最小信頼)。

• 信頼されていないサイト。 ユーザーが信頼されていないと識別するアプリケーション。 (信頼されていません)。

これらのゾーンごとに、CAS には、それぞれに関連付けられている信頼レベルに一致するアクセス許可を含む定義済みのアクセス許可セットが用意されています。 これらには次のものが含まれます。

• FullTrust。 マイ コンピューター ゾーンから起動されたアプリケーションの場合。 すべての利用可能な権限が付与されています。

• LocalIntranet。 ローカル イントラネット ゾーンから起動されたアプリケーションの場合。 アクセス許可のサブセットは、分離ストレージ、無制限の UI アクセス、無制限のファイル ダイアログ、制限付きリフレクション、環境変数への制限付きアクセスなど、クライアント コンピューターのリソースへの中程度のアクセスを提供するために付与されます。 レジストリなどの重要なリソースのアクセス許可は提供されません。

• インターネット。 インターネットまたは信頼済みサイト ゾーンから起動されたアプリケーションの場合。 アクセス許可のサブセットは、分離ストレージ、ファイルオープンのみ、制限付き UI など、クライアント マシンのリソースへの制限付きアクセスを提供するために付与されます。 基本的に、このアクセス許可セットは、クライアント コンピューターからアプリケーションを分離します。

信頼されていないサイト ゾーンから識別されたアプリケーションには、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();

Dim fp As 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();

Dim fp As 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 に含まれており、Visual Studio と統合される包括的な配置テクノロジです (詳細については、「 ClickOnce のセキュリティと配置 」を参照してください)。 スタンドアロン WPF アプリケーションは ClickOnce を使用して配置できますが、ブラウザーでホストされるアプリケーションは ClickOnce と共に配置する必要があります。

ClickOnce を使用して配置されたアプリケーションには、コード アクセス セキュリティ (CAS) 経由で追加のセキュリティレイヤーが付与されます。基本的に、ClickOnce 配置アプリケーションは、必要なアクセス許可を要求します。 アプリケーションの展開元ゾーンのアクセス許可のセットを超えない場合にのみ、これらのアクセス許可が付与されます。 必要なアクセス許可のみにアクセス許可のセットを減らすことで、起動ゾーンのアクセス許可セットによって提供されるアクセス許可セットよりも少ない場合でも、アプリケーションがアクセスできるリソースの数は最小限に抑えられます。 その結果、アプリケーションがハイジャックされた場合、クライアント コンピューターに損傷を与える可能性が減少します。

Security-Critical 手法

アクセス許可を使用して XBAP アプリケーションのインターネット ゾーン サンドボックスを有効にする WPF コードは、可能な限り高度なセキュリティ監査と制御を保持する必要があります。 この要件を容易にするために、.NET Framework では、特権を昇格させるコードを管理するための新しいサポートが提供されます。 具体的には、CLR を使用すると、特権を昇格するコードを識別し、 SecurityCriticalAttributeでマークすることができます。 SecurityCriticalAttribute でマークされていないコードは、この手法を使用して 透過的 になります。 逆に、 SecurityCriticalAttribute でマークされていないマネージド コードは、特権を昇格できません。

Security-Critical 手法を使用すると、特権を セキュリティクリティカルなカーネルに昇格させる WPF コードの編成が可能になり、残りは透過的になります。 セキュリティ クリティカルなコードを分離することで、WPF エンジニアリング チームは、標準的なセキュリティ プラクティス以上のセキュリティ クリティカルなカーネルに対して、追加のセキュリティ分析とソース管理に重点を置きます ( 「WPF セキュリティ戦略 - セキュリティ エンジニアリング」を参照)。

.NET Framework では、開発者が AllowPartiallyTrustedCallersAttribute (APTCA) でマークされ、ユーザーのグローバル アセンブリ キャッシュ (GAC) に展開されるマネージド アセンブリを記述できるようにすることで、信頼されたコードで XBAP インターネット ゾーン サンドボックスを拡張できます。 APTCA を使用してアセンブリをマークすることは、任意のコードがそのアセンブリを呼び出すことができるようにするため、機密性の高いセキュリティ操作です (インターネットからの悪意のあるコードを含む)。 これを行う際には、細心の注意とベストプラクティスを徹底する必要があります。また、ユーザーはそのソフトウェアをインストールする前に信頼することを選択する必要があります。

Microsoft Internet Explorer のセキュリティ

セキュリティの問題を軽減し、セキュリティ構成を簡素化するだけでなく、Microsoft Internet Explorer 6 (SP2) には、XAML ブラウザー アプリケーション (XBAP) のユーザーのセキュリティを強化するセキュリティ強化機能がいくつか含まれています。 これらの機能の推力は、ユーザーが閲覧エクスペリエンスをより詳細に制御できるようにしようとします。

IE6 SP2 より前のユーザーは、次のいずれかの対象になる可能性があります。

• ランダム ポップアップ ウィンドウ。

• 混乱を招くスクリプト リダイレクト。

• 一部の Web サイトでは、多数のセキュリティ ダイアログが表示されます。

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

IE6 SP2 には、ユーザーの開始の概念を中心に、これらの種類の問題を軽減するためのいくつかの機能が含まれています。 IE6 SP2 は、ユーザーがアクション (ユーザー 開始と呼ばれます) の前にリンクまたはページ要素をクリックしたことを検出し、同様のアクションがページ上のスクリプトによってトリガーされる場合とは異なる方法で処理します。 たとえば、IE6 SP2 には、ページがポップアップを作成する前にユーザーがボタンをクリックしたときに検出する Pop-Up ブロッカー が組み込まれています。 これにより、IE6 SP2 は、ユーザーが求めも望んでもいないポップアップを防ぎながら、ほとんどの無害なポップアップを許可できます。 ブロックされたポップアップは新しい 情報バーの下にトラップされ、ユーザーはブロックを手動でオーバーライドしてポップアップを表示できます。

Open/Save セキュリティ プロンプトにも、同じユーザー開始ロジックが適用されます。 ActiveX インストール ダイアログ ボックスは、以前にインストールしたコントロールからのアップグレードを表す場合を除き、常に情報バーの下にトラップされます。 これらの対策は、不要なソフトウェアまたは悪意のあるソフトウェアをインストールすることを嫌がらせするサイトから保護されているため、ユーザーに安全でより制御されたユーザー エクスペリエンスを提供するために組み合わされます。

これらの機能により、IE6 SP2 を使用して WPF アプリケーションをダウンロードしてインストールできる Web サイトを参照するユーザーも保護されます。 特に、IE6 SP2 は、WPF を含む、ビルドに使用されたテクノロジに関係なく、悪意のあるアプリケーションや悪質なアプリケーションをユーザーがインストールする機会を減らす優れたユーザー エクスペリエンスを提供するためです。 WPF は、ClickOnce を使用してこれらの保護を追加し、インターネット経由でのアプリケーションのダウンロードを容易にします。 XAML ブラウザー アプリケーション (XBAP) はインターネット ゾーン セキュリティ サンドボックス内で実行されるため、シームレスに起動できます。 一方、スタンドアロン WPF アプリケーションを実行するには、完全な信頼が必要です。 これらのアプリケーションの場合、ClickOnce は起動プロセス中にセキュリティ ダイアログ ボックスを表示し、アプリケーションの追加のセキュリティ要件の使用を通知します。 ただし、これはユーザーが開始する必要があり、ユーザーが開始したロジックによって管理され、取り消すこともできます。

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

こちらも参照ください

• コード アクセス セキュリティ
• セキュリティ
• WPF 部分信頼セキュリティ
• WPF セキュリティ戦略 - セキュリティ エンジニアリング