WPF のセキュリティ方針 - プラットフォーム セキュリティ
Windows Presentation Foundation (WPF) にはさまざまなセキュリティ サービスが用意されていますが、基になるプラットフォーム (オペレーティング システム、CLR、および Internet Explorer) のセキュリティ機能も活用されています。 WPF では、これらの層の組み合わせにより、強力な多重防御のセキュリティ モデルが実現されています。このセキュリティ モデルは、次の図に示すように、単一点障害の排除を目指しています。
.png "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 browser applications (XBAPs) のプロセス特権を制限することによってオペレーティング システムのセキュリティを活用しています。 ブラウザーによってホストされる WPF アプリケーションが起動する前に、プロセス トークンから不要な特権を削除するホスト プロセスがオペレーティング システムによって作成されます。 たとえば、ユーザーのコンピューターのシャットダウン、ドライバーの読み込み、コンピューター上のすべてのファイルの読み取りアクセスなどの特権が削除されます。
Internet Explorer 7 for Vista
Windows Internet Explorer 7 では、WPF アプリケーションは保護モードで実行されます。 具体的には、XAML browser applications (XBAPs) は中レベルの整合性で実行されます。
多重防御層
一般に XAML browser applications (XBAPs) はインターネット ゾーン アクセス許可セットによってサンドボックス化されるため、これらの特権を削除しても XAML browser applications (XBAPs) の互換性が損なわれることはありません。 代わりに、追加の多重防御層が作成されます。つまり、サンドボックス化されたアプリケーションが他の層を悪用してプロセスを乗っ取ることができたとしても、そのプロセスには限られた特権しかありません。
「Using a Least-Privileged User Account (権限が最小限のユーザー アカウントの使用)」を参照してください。
共通言語ランタイムのセキュリティ
common language runtime (CLR) には、検証と検査、Code Access Security (CAS)、セキュリティ クリティカルな方法など、重要なセキュリティの利点がいくつかあります。
検証と検査
CLR では、アセンブリの分離と整合性を実現するために検証のプロセスが使用されています。 CLR の検証では、アセンブリの移植可能な実行可能 (PE: Portable Executable) ファイル形式について、アセンブリの外部を指すアドレスがないかどうかを検証することによって、アセンブリの分離が確認されます。 CLR の検証では、アセンブリ内に埋め込まれているメタデータの整合性も検証されます。
タイプ セーフの保証、一般的なセキュリティの問題 (バッファー オーバーランなど) の防止、およびサブプロセスの分離によるサンドボックス化の実現のために、 CLR のセキュリティでは、検査の概念が使用されています。
マネージ アプリケーションは Microsoft Intermediate Language (MSIL) にコンパイルされます。 マネージ アプリケーションのメソッドが実行されると、MSIL が Just-In-Time (JIT) コンパイルによってネイティブ コードにコンパイルされます。 JIT コンパイルに含まれる検査のプロセスでは、安全性と信頼性に関する数多くの規則が適用されて、コードに次のような問題がないかが確認されます。
型のコントラクトに違反している。
バッファー オーバーランを引き起こす。
メモリに対して過度のアクセスがある。
検査の規則に従っていないマネージ コードは、信頼されたコードと見なされない限り、実行を許可されません。
検査可能なコードのこの利点は、WPF が .NET Framework に基づいて構築されている大きな理由の 1 つです。 検査可能なコードが使用されている範囲では、潜在的な脆弱性が悪用される可能性が大幅に減少します。
コード アクセス セキュリティ
クライアント コンピューターでは、ファイル システム、レジストリ、印刷サービス、ユーザー インターフェイス、リフレクション、環境変数など、マネージ アプリケーションがアクセスできるさまざまなリソースが公開されています。 マネージ アプリケーションでクライアント コンピューターのリソースにアクセスするには、そのための .NET Framework Code Access Security (CAS) アクセス許可が必要です。 CAS のアクセス許可は、CodeAccessPermission のサブクラスです。CAS では、マネージ アプリケーションがアクセスできる各リソースにつき 1 つのサブクラスが実装されます。
マネージ アプリケーションが実行を開始するときに CAS によって付与されるアクセス許可のセットを、アクセス許可セットと呼びます。アクセス許可セットは、アプリケーションが提供する証拠によって決定されます。 WPF アプリケーションの場合、提供される証拠はアプリケーションが起動された場所 (ゾーン) です。 CAS では、次のゾーンが識別されます。
マイ コンピューター。 クライアント コンピューターから起動されたアプリケーション (完全信頼)。
ローカル イントラネット。 イントラネットから起動されたアプリケーション (部分信頼)。
インターネット。 インターネットから起動されたアプリケーション (最小限の信頼)。
信頼済みサイト。 ユーザーによって信頼済みとして識別されたアプリケーション (最小限の信頼)。
信頼されないサイト。 ユーザーによって信頼できないとして識別されたアプリケーション (信頼されていない)。
CAS には、これらの各ゾーンに対してそれぞれ定義済みのアクセス許可セットが用意されています。これらのアクセス許可セットには、それぞれに関連付けられた信頼レベルに対応するアクセス許可が含まれています。 以下に例を示します。
FullTrust。 マイ コンピューター ゾーンから起動されたアプリケーションのアクセス許可セット。 すべてのアクセス許可が付与されます。
LocalIntranet。 ローカル イントラネット ゾーンから起動されたアプリケーションのアクセス許可セット。 クライアント コンピューターのリソースへの適度なアクセスを提供するアクセス許可のサブセットが付与されます。これには、分離ストレージ、無制限の UI アクセス、無制限のファイル ダイアログ、制限されたリフレクション、環境変数への制限されたアクセスが含まれます。 レジストリのような重要なリソースへのアクセス許可は提供されません。
インターネット。 インターネット ゾーンや信頼済みサイト ゾーンから起動されたアプリケーションのアクセス許可セット。 クライアント コンピューターのリソースへの制限されたアクセスを提供するアクセス許可のサブセットが付与されます。これには、分離ストレージ、ファイル オープンのみ、および制限された UI が含まれます。 このアクセス許可セットでは、基本的に、アプリケーションはクライアント コンピューターから分離されます。
CAS では、信頼されないサイト ゾーンから起動されたと識別されたアプリケーションに対してはアクセス許可が一切付与されません。 したがって、それらのアプリケーションの定義済みアクセス許可セットは存在しません。
次の図は、ゾーン、アクセス許可セット、アクセス許可、およびリソースの関係を示しています。
.png "CAS アクセス許可セット")
インターネット ゾーンのセキュリティ サンドボックスの制限は、XBAP が WPF などのシステム ライブラリからインポートするコードにも同じように適用されます。 これにより、WPF を含め、すべてのコードが制限されることになります。 しかし、インターネット ゾーンのセキュリティ サンドボックスで有効になるアクセス許可だけでは、XBAP を実行するために必要な機能を実行することはできません。
たとえば、次のページを含む XBAP アプリケーションがあったとします。
Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()
' Perform operation that uses the assert
' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()
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 メソッドを使用してこれを実現します。 このしくみを次のコードに示します。
Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()
' Perform operation that uses the assert
' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()
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 の配置の概要」を参照してください)。 スタンドアロンの WPF アプリケーションは、ClickOnce を使用して配置することができます。ブラウザーによってホストされるアプリケーションは、ClickOnce を使用して配置する必要があります。
ClickOnce を使用して配置されたアプリケーションでは、Code Access Security (CAS) の上にさらにセキュリティ層が追加されます。これは、ClickOnce で配置されたアプリケーションは、その性質上、必要なアクセス許可を要求するためです。 これらのアプリケーションに対しては、要求されたアクセス許可のみが、配置元のゾーンのアクセス許可セットの範囲内で付与されます。 アクセス許可のセットを (起動ゾーンのアクセス許可セットによって提供されるアクセス許可よりも少なくなるとしても) 必要なものみに縮小することによって、アプリケーションがアクセスできるリソースの数を最小限に抑えることができます。 その結果、アプリケーションが乗っ取られた場合にクライアント コンピューターが被害を受ける可能性が減少します。
セキュリティ クリティカルな方法
アクセス許可を使用して XBAP アプリケーションのインターネット ゾーン サンドボックスを有効にする WPF コードに対しては、最大限のセキュリティ監査と制御を適用する必要があります。 これを支援するために、.NET Framework には、権限を昇格させるコードを管理するための新たなサポートが用意されています。 具体的には、CLR を使用すると、権限を昇格させるコードを識別して、SecurityCriticalAttribute でマークすることができます。この方法を使用すると、SecurityCriticalAttribute でマークされていないすべてのコードは "透明" になります。 逆に言えば、SecurityCriticalAttribute でマークされていないマネージ コードに対しては権限の昇格が阻止されます。
セキュリティ クリティカルな方法を使用すると、権限を昇格させる WPF コードを "セキュリティ クリティカル カーネル" にまとめて、その他のコードを透明にすることができます。 セキュリティ クリティカル コードを分離することにより、WPF のエンジニアリング チームは、標準のセキュリティ プラクティスの範囲を超えた追加のセキュリティ分析とソース管理をセキュリティ クリティカル カーネルに対して集中させることができます (「WPF のセキュリティ方針 - セキュリティ エンジニアリング」を参照してください)。
.NET Framework では、AllowPartiallyTrustedCallersAttribute (APTCA) でマークされたマネージ アセンブリを作成し、ユーザーのグローバル アセンブリ キャッシュ (GAC) に配置することによって、XBAP のインターネット ゾーン サンドボックスを信頼されたコードで拡張することができます。 アセンブリを APTCA でマークすると、インターネットの悪質なコードを含むあらゆるコードがそのアセンブリを呼び出せるようになるため、セキュリティ上のリスクがきわめて高くなります。 この操作を行う場合は、細心の注意を払い、ベスト プラクティスに従う必要があります。また、そのソフトウェアをインストールするには、ユーザーがそのソフトウェアを信頼することを選択する必要があります。
Microsoft Internet Explorer のセキュリティ
Microsoft Internet Explorer 6 (SP2) では、セキュリティの問題の削減やセキュリティの構成の単純化が実現されているほか、XAML browser applications (XBAPs) のユーザーのセキュリティを強化する機能がいくつか含まれています。 これらの機能は、ユーザーが今まで以上にブラウジング エクスペリエンスを制御できるようにすることを目的としています。
IE6 SP2 以前のユーザーは、次のような問題を抱えていました。
不規則なポップアップ ウィンドウ。
わかりにくいスクリプト リダイレクト。
多数のセキュリティ ダイアログが表示される Web サイト。
中には、インストールuser interface (UI) になりすましたり、Microsoft ActiveX のインストール ダイアログ ボックスを (ユーザーがキャンセルしているにもかかわらず) 繰り返し表示したりして、ユーザーをだまそうとする信頼できない Web サイトもあります。 こうした手法によって、かなりの数のユーザーがだまされてスパイウェア アプリケーションをインストールしてしまっている可能性があります。
IE6 SP2 には、こうした問題を軽減する機能がいくつか含まれています。その中心にあるのは、ユーザー実行の概念です。 IE6 SP2 では、アクションの前にユーザーがリンクやページの要素をクリックした場合に (ユーザー実行) そのことが検出され、同様のアクションがページ上のスクリプトによって呼び出された場合とは別に扱われます。 その一例が IE6 SP2 に組み込まれているポップアップ ブロックです。ポップアップ ブロックでは、ページでポップアップが作成される前にユーザーがボタンをクリックした場合には、そのことが検出されます。 これにより、IE6 SP2 では、害のないポップアップは許可され、ユーザーが要求していない無用なポップアップは阻止されます。 ブロックされたポップアップは、新しい情報バーで処理されます。ここでユーザーは、ブロックを手動で無効にして、ポップアップを表示することができます。
同じユーザー実行のロジックは、[開く]/[保存] のセキュリティの確認にも適用されています。 ActiveX のインストール ダイアログ ボックスは、以前にインストールされたコントロールのアップグレードを表している場合を除き、常に情報バーで処理されます。 こうした方策の組み合わせにより、不要なソフトウェアや悪質なソフトウェアのインストールを迫るサイトからユーザーが保護されるため、より安全で制御されたユーザー エクスペリエンスが実現されます。
これらの機能により、WPF アプリケーションをダウンロードしてインストールできる Web サイトを利用する際に IE6 SP2 を使用するユーザーも保護されます。 これは具体的に言うと、IE6 SP2 の強化されたユーザー エクスペリエンスにより、作成に使用されているテクノロジ (WPF など) に関係なく、悪質なアプリケーションや不正なアプリケーションをユーザーがインストールしてしまう可能性が減少するためです。 WPF では、これらの保護に加えて、インターネットからのアプリケーションのダウンロードに役立つ ClickOnce も使用されています。 XAML browser applications (XBAPs) はインターネット ゾーンのセキュリティ サンドボックス内で実行されるため、シームレスに起動することができます。 一方、スタンドアロンの WPF アプリケーションを実行するには、完全信頼が必要です。 これらのアプリケーションに対しては、起動プロセスの間にClickOnce によってセキュリティ ダイアログ ボックスが表示され、アプリケーションの追加のセキュリティ要件が使用されることが通知されます。 ただし、これはユーザー実行でなければならず、これもまたユーザー実行のロジックによって制御されます。また、キャンセルすることもできます。
Internet Explorer 7 では、セキュリティに対する継続的な取り組みの一貫として、IE6 SP2 のセキュリティ機能が組み込まれ、拡張されています。
参照
概念
WPF のセキュリティ方針 - セキュリティ エンジニアリング
その他の技術情報
保護モードの Internet Explorer の理解と機能