XAML セキュリティの考慮事項
この記事では、XAML および .NET XAML Services API を使用する場合のアプリケーションのセキュリティに関するベスト プラクティスについて説明します。
アプリケーションで信頼されていない XAML
最も一般的な意味では、信頼されていない XAML とは、アプリケーションによって明示的にインクルードまたは生成されなかった XAML ソースのことです。
信頼された署名付きアセンブリに resx
型のリソースとしてコンパイルまたは格納された XAML は、本質的に信頼できません。 XAML は、アセンブリ全体を信頼するのと同程度に信頼できます。 ほとんどの場合、必要なのは、ストリームまたは他の I/O から読み込む XAML ソースである、Loose XAML の信頼の側面だけです。 Loose XAML は、展開とパッケージ化インフラストラクチャを備えた、アプリケーション モデルの特定のコンポーネントまたは機能ではありません。 ただし、アセンブリにより Loose 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 リーダーおよびライターの信頼されているコンポーネントと信頼されていないコンポーネントの間で、コンテキストを安全に共有できます。 ただし、これを行う場合でも、そのようなリーダーとライターを別の 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 の型システムが拡張可能であり、XAML 自体の拡張性およびその使用可能な代替の型マッピング戦略と、既定の CLR でバッキングされた実装および既定の XAML スキーマ コンテキストを一致させるためです。 詳細については、XamlType および XamlMember のいくつかのプロパティに関する具体的な注意事項を参照してください。
関連項目
.NET Desktop feedback