次の方法で共有


XAML のセキュリティに関する考慮事項

この記事では、XAML および .NET XAML サービス API を使用する場合のアプリケーションのセキュリティに関するベスト プラクティスについて説明します。

アプリケーションの信頼されていない XAML

最も一般的な意味では、信頼されていない XAML は、アプリケーションが明示的に含めたり出力したりしなかった XAML ソースです。

信頼された署名付きアセンブリ内で resx型リソースとしてコンパイルまたは格納される XAML は、本質的に信頼されていません。 アセンブリ全体を信頼する限り、XAML を信頼できます。 ほとんどの場合、ルーズ XAML の信頼の側面のみが関係します。これは、ストリームまたはその他の I/O から読み込む XAML ソースです。 Loose XAML は、デプロイとパッケージ化インフラストラクチャを備えたアプリケーション モデルの特定のコンポーネントまたは機能ではありません。 ただし、アセンブリは、緩やかな XAML の読み込みを伴う動作を実装する場合があります。

信頼されていない XAML の場合は、通常、信頼されていないコードの場合と同じように扱う必要があります。 サンドボックスやその他のメタファーを使用して、信頼されていない XAML が信頼されたコードにアクセスできないようにします。

XAML 機能の性質により、XAML はオブジェクトを構築し、そのプロパティを設定する権限を XAML に与えます。 これらの機能には、型コンバーターへのアクセス、アプリケーション ドメイン内のアセンブリのマッピングとアクセス、マークアップ拡張機能、x:Code ブロックなどを使用する機能も含まれます。

XAML は、言語レベルの機能に加えて、多くのテクノロジで UI 定義に使用されます。 信頼されていない XAML を読み込むと、悪意のあるスプーフィング UI が読み込まれた可能性があります。

閲覧者とライターの間でコンテキストを共有する

XAML リーダーと XAML ライターの .NET XAML サービス アーキテクチャでは、多くの場合、XAML リーダーを XAML ライターまたは共有 XAML スキーマ コンテキストと共有する必要があります。 XAML ノード ループ ロジックを記述する場合、またはカスタムの保存パスを指定する場合は、オブジェクトまたはコンテキストの共有が必要になる場合があります。 信頼されたコードと信頼されていないコードの間で、XAML リーダー インスタンス、既定以外の XAML スキーマ コンテキスト、または XAML リーダー/ライター クラスの設定を共有しないでください。

CLR ベースの型バッキングに対する XAML オブジェクトの書き込みに関連するほとんどのシナリオと操作では、既定の XAML スキーマ コンテキストのみを使用できます。 既定の XAML スキーマ コンテキストには、完全な信頼を損なう可能性のある設定は明示的に含まれません。 そのため、信頼された XAML リーダー/ライター コンポーネントと信頼されていない XAML リーダー/ライター コンポーネントの間でコンテキストを共有しても安全です。 ただし、これを行う場合は、このようなリーダーとライターを個別の AppDomain スコープに保持し、そのうちの 1 つは部分信頼用に具体的に意図/サンドボックス化しておくことをお勧めします。

XAML 名前空間とアセンブリ信頼

XAML がカスタム XAML 名前空間マッピングをアセンブリに解釈する方法に関する基本的な非修飾構文と定義では、アプリケーション ドメインに読み込まれる信頼されたアセンブリと信頼されていないアセンブリは区別されません。 したがって、信頼されていないアセンブリが信頼されたアセンブリの目的の XAML 名前空間マッピングをスプーフィングし、XAML ソースの宣言されたオブジェクトとプロパティ情報をキャプチャすることは技術的に可能です。 この状況を回避するためのセキュリティ要件がある場合は、次のいずれかの手法を使用して、目的の XAML 名前空間マッピングを作成する必要があります。

  • アプリケーションの XAML によって作成されたすべての XAML 名前空間マッピングで、厳密な名前を持つ完全修飾アセンブリ名を使用します。

  • XAML リーダーと XAML オブジェクト ライター用の特定の XamlSchemaContext を構築することによって、アセンブリマッピングを固定の参照アセンブリセットに制限します。 XamlSchemaContext(IEnumerable<Assembly>)を参照してください。

XAML 型マッピングと型システム アクセス

XAML は独自の型システムをサポートしています。これは多くの点で、CLR が基本的な CLR 型システムを実装する方法のピアです。 ただし、型情報に基づいて型に関する信頼の決定を行う型認識の特定の側面については、CLR バッキング型の型情報を延期する必要があります。 これは、XAML 型システムの特定のレポート機能の一部が仮想メソッドとして開いたままになっているため、元の .NET XAML サービスの実装を完全に制御できないためです。 これらの拡張ポイントは、XAML 自体の拡張性と、可能な代替型マッピング戦略と、既定の CLR でサポートされる実装と既定の XAML スキーマ コンテキストに一致するように、XAML 型システムが拡張可能であるために存在します。 詳細については、XamlTypeXamlMemberのいくつかのプロパティに関する具体的な注意事項を参照してください。

関連項目