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 は、バッファー オーバーランを軽減するために、WPF など、CLR の依存関係のすべてを含む多数のコア システム ライブラリを再コンパイルして、保護を行います。 これは、C や C++ のコマンド ライン コンパイラの /GS パラメーターを使用して実現されます。 バッファー オーバーランを明示的に避ける必要はありますが、/GS コンパイルは、故意であるかないかにかかわらずバッファー オーバーランによって生み出される潜在的な脆弱性に対する多重防御の一例となります。

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

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

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

Windows Vista

Windows Vista の WPF ユーザーは、「最小限の特権によるユーザー アクセス」、コードの整合性チェック、および特権の分離など、オペレーティング システムのさらなるセキュリティ機能強化の恩恵を受けられます。

ユーザー アカウント制御 [UAC]

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

管理者特権で実行することの本当の意味は、管理者特権を付与されているプロセスからアプリケーションを実行することです。 これによるセキュリティへの影響は、管理者特権で実行するプロセスを乗っ取る悪意のあるコードが、重要なシステム リソースへのアクセスなど、これらの権限を自動的に継承することです。

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

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

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

コードの整合性チェック

Windows Vista には、読み込み時または実行時に、悪意のあるコードがシステム ファイルやカーネルに挿入されないようにするための、より詳細なコード整合性チェックが組み込まれています。 これは、システム ファイルの保護を超えて動作します。

ブラウザーでホストされるアプリケーションの制限付き権限のプロセス

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

警告

XBAP が動作するには、Internet Explorer や旧バージョンの Firefox などのレガシ ブラウザーが必要です。 これらの古いブラウザーは通常、Windows 10 や Windows 11 ではサポートされていません。 最新のブラウザーでは、セキュリティ リスクがあるため XBAP アプリに必要なテクノロジがサポートされなくなりました。 XBAP を有効にするプラグインはサポートされなくなりました。 詳細については、「ブラウザーでホストされる WPF アプリケーション (XBAP) についてよく寄せられる質問」を参照してください。

XAML ブラウザー アプリケーション (XBAP) は一般に、インターネット ゾーン アクセス許可セットによってセキュリティで保護されるため、互換性の観点から、これらの特権を取り除いても、XAML ブラウザー アプリケーション (XBAP) には害を及ぼしません。 代わりに、追加の多重防御層が作成されます。セキュリティで保護されたアプリケーションが他のレイヤーを利用してプロセスを乗っ取ることができる場合、プロセスの特権は制限されたままとなります。

詳細については、最小特権ユーザー アカウントの使用に関する記事を参照してください。

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

共通言語ランタイム (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 が動作するには、Internet Explorer や旧バージョンの Firefox などのレガシ ブラウザーが必要です。 これらの古いブラウザーは通常、Windows 10 や Windows 11 ではサポートされていません。 最新のブラウザーでは、セキュリティ リスクがあるため XBAP アプリに必要なテクノロジがサポートされなくなりました。 XBAP を有効にするプラグインはサポートされなくなりました。 詳細については、「ブラウザーでホストされる 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 が配置済みのアプリケーションは、必要なアクセス許可を要求します。 これらのアプリケーションが、アプリケーションの配置元ゾーンのアクセス許可セット数を超えていない場合、これらのアプリケーションには必要なアクセス許可のみが付与されます。 アクセス許可セットの数を必要な数のみに減らすことで、起動ゾーンのアクセス許可セットが提供するアクセス許可数を下回る場合でも、アプリケーションがアクセスできるリソースの数が最小限まで削減されます。 その結果、アプリケーションが乗っ取られた場合、クライアント コンピューターの損傷の可能性が低減します。

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

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

警告

XBAP が動作するには、Internet Explorer や旧バージョンの Firefox などのレガシ ブラウザーが必要です。 これらの古いブラウザーは通常、Windows 10 や Windows 11 ではサポートされていません。 最新のブラウザーでは、セキュリティ リスクがあるため XBAP アプリに必要なテクノロジがサポートされなくなりました。 XBAP を有効にするプラグインはサポートされなくなりました。 詳細については、「ブラウザーでホストされる WPF アプリケーション (XBAP) についてよく寄せられる質問」を参照してください。

セキュリティ クリティカルな方法では、WPF コードの組織が、セキュリティ クリティカルなカーネルに特権を昇格させ、残りの部分を透過にすることができます。 セキュリティ クリティカルなコードを分離することにより、WPF のエンジニアリング チームは、標準的なセキュリティ プラクティスを上回る、セキュリティ クリティカルなカーネルでのセキュリティ分析およびソース コントロールに重点を置くことができます (「WPF のセキュリティ方針 - セキュリティ エンジニアリング」を参照してください)。

なお .NET Framework は、開発者が AllowPartiallyTrustedCallersAttribute (APTCA) でマークされ、ユーザーのグローバル アセンブリ キャッシュ (GAC) に配置されたマネージド アセンブリに書き込めるようにすることで、信頼されたコードが XBAP のインターネット ゾーンのサンドボックスに拡張することを許可します。 アセンブリを APTCA でマークすることは、機密性の高いセキュリティ操作です。インターネットからの悪意のあるコードなど、いずれのコードもそのアセンブリを呼び出すことができるためです。 これを実施する際は十分注意し、ベスト プラクティスを使用する必要があります。ソフトウェアをインストールするためには、ユーザーがそのソフトウェアを信頼することを選択する必要があります。

Microsoft Internet Explorer のセキュリティ

セキュリティ上の問題を減らし、セキュリティの構成を簡素化するだけでなく、Microsoft Internet Explorer 6 (SP2) には、XAML browser applications (XBAP) のユーザーのセキュリティを強化するようセキュリティが向上した複数の機能が含まれています。 これらの機能の推進により、ユーザーが閲覧の制御を拡大できるようにしています。

警告

XBAP が動作するには、Internet Explorer や旧バージョンの Firefox などのレガシ ブラウザーが必要です。 これらの古いブラウザーは通常、Windows 10 や Windows 11 ではサポートされていません。 最新のブラウザーでは、セキュリティ リスクがあるため XBAP アプリに必要なテクノロジがサポートされなくなりました。 XBAP を有効にするプラグインはサポートされなくなりました。 詳細については、「ブラウザーでホストされる WPF アプリケーション (XBAP) についてよく寄せられる質問」を参照してください。

IE6 SP2 の前のバージョンでは、ユーザーは次のいずれかの影響を受ける可能性がありました。

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

• スクリプトのリダイレクトの混乱。

• 一部の Web サイトでの多数のセキュリティ ダイアログ。

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

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 のセキュリティ機能が強化されています。

関連項目

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