リフレクションのセキュリティに関する考慮事項

2025-06-22

リフレクションは、型とメンバーに関する情報を取得し、メンバーにアクセスする機能を提供します (つまり、メソッドとコンストラクターを呼び出す、プロパティ値を取得および設定する、イベントハンドラーを追加および削除する、など)。リフレクションを使用して型とメンバーに関する情報を取得することは制限されません。すべてのコードでリフレクションを使用して、次のタスクを実行できます。

型とメンバーを列挙し、そのメタデータを調べます。
アセンブリとモジュールを列挙して調べます。

これに対し、リフレクションを使用してメンバーにアクセスする場合は、制限が適用されます。 .NET Framework 4 以降では、セキュリティクリティカルなメンバーにアクセスするためにリフレクションを使用できるのは信頼できるコードだけです。さらに、リフレクションを使用して、コンパイル済みコードに直接アクセスできない非パブリックメンバーにアクセスできるのは、信頼されたコードだけです。最後に、リフレクションを使用してセーフクリティカルなメンバーにアクセスするコードは、コンパイル済みコードと同様に、セーフクリティカルメンバーが要求するアクセス許可を持っている必要があります。

必要なアクセス許可に従って、コードはリフレクションを使用して次の種類のアクセスを実行できます。

セキュリティクリティカルではないパブリックメンバーにアクセスします。
コンパイル済みコードからアクセスできる非パブリックメンバーにアクセスします (それらのメンバーがセキュリティクリティカルでない場合)。このような非パブリックメンバーの例を次に示します。
- 呼び出し元コードの基底クラスの保護されたメンバー。 (リフレクションでは、これはファミリレベルのアクセスと呼ばれます)。
- internal 呼び出し元のコードのアセンブリ内のメンバー (Visual Basic のメンバーFriend )。 (リフレクションでは、これはアセンブリレベルのアクセスと呼ばれます)。
- 呼び出し元のコードを含むクラスの他のインスタンスのプライベートメンバー。

たとえば、セキュリティで保護されたアプリケーションドメインで実行されるコードは、アプリケーションドメインが追加のアクセス許可を付与しない限り、この一覧で説明されているアクセスに制限されます。

.NET Framework 2.0 Service Pack 1 以降では、通常アクセスできないメンバーにアクセスしようとすると、ターゲットオブジェクトの許可セットに対する要求と、ReflectionPermissionFlag.MemberAccess フラグを持つReflectionPermissionが生成されます。完全信頼で実行されているコード (コマンドラインから起動されるアプリケーション内のコードなど) は、常にこれらのアクセス許可を満たすことができます。 (これは、この記事で後述するように、セキュリティクリティカルなメンバーへのアクセスに関する制限事項に従います)。

必要に応じて、サンドボックスアプリケーションドメインは、この記事で後述する「通常アクセスできないメンバーへのアクセス」セクションで説明するように、ReflectionPermissionFlag.MemberAccess フラグを使用してReflectionPermissionを付与できます。

Security-Critical メンバーへのアクセス

メンバーが SecurityCriticalAttributeを持っている場合、 SecurityCriticalAttributeを持つ型に属している場合、またはセキュリティクリティカルなアセンブリ内にある場合、メンバーはセキュリティクリティカルです。 .NET Framework 4 以降、セキュリティクリティカルなメンバーにアクセスするための規則は次のとおりです。

透過的なコードでは、コードが完全に信頼されている場合でも、リフレクションを使用してセキュリティクリティカルなメンバーにアクセスすることはできません。 MethodAccessException、FieldAccessException、またはTypeAccessExceptionがスローされます。
部分信頼で実行されているコードは透過的として扱われます。

これらの規則は、セキュリティクリティカルなメンバーがコンパイル済みコードによって直接アクセスされるか、リフレクションを使用してアクセスされるかに関係なく同じです。

コマンドラインから実行されるアプリケーションコードは、完全信頼で実行されます。透過的としてマークされていない限り、リフレクションを使用してセキュリティクリティカルなメンバーにアクセスできます。部分信頼 (たとえば、サンドボックスアプリケーションドメイン内) で同じコードを実行すると、アセンブリの信頼レベルによって、セキュリティクリティカルなコードにアクセスできるかどうかが決まります。アセンブリに厳密な名前があり、グローバルアセンブリキャッシュにインストールされている場合、アセンブリは信頼できるアセンブリであり、セキュリティクリティカルなメンバーを呼び出すことができます。信頼されていない場合は、透過的としてマークされていなくても透過的になり、セキュリティクリティカルなメンバーにアクセスできません。

反射と透明度

.NET Framework 4 以降、共通言語ランタイムは、アセンブリの信頼レベルやアプリケーションドメインの信頼レベルなど、いくつかの要因から型またはメンバーの透過性レベルを決定します。リフレクションには、 IsSecurityCritical、 IsSecuritySafeCritical、および IsSecurityTransparent のプロパティが用意されており、型の透過性レベルを検出できます。次の表に、これらのプロパティの有効な組み合わせを示します。

セキュリティレベル	IsSecurityCritical	IsSecuritySafeCritical	IsSecurityTransparent
危うい	`true`	`false`	`false`
セーフクリティカル	`true`	`true`	`false`
透明	`false`	`false`	`true`

これらのプロパティの使用は、アセンブリとその型のセキュリティ注釈を調べたり、現在の信頼レベルを確認したり、ランタイムの規則を複製したりするよりもはるかに簡単です。たとえば、コマンドラインから実行する場合は同じ型をセキュリティクリティカルにしたり、セキュリティで保護されたアプリケーションドメインで実行する場合はセキュリティ透過的にすることができます。

MethodBase、FieldInfo、TypeBuilder、MethodBuilder、DynamicMethod クラスにも同様のプロパティがあります。 (その他のリフレクションおよびリフレクション出力の抽象化の場合、セキュリティ属性は関連付けられているメソッドに適用されます。たとえば、プロパティの場合は、プロパティアクセサーに適用されます)。

通常アクセスできないメンバーへのアクセス

リフレクションを使用して、共通言語ランタイムのアクセシビリティ規則に従ってアクセスできないメンバーを呼び出すには、次の 2 つのアクセス許可のいずれかをコードに付与する必要があります。

コードがパブリックでないメンバーを呼び出せるようにするには、コードに ReflectionPermissionFlag.MemberAccess フラグを付けてReflectionPermissionを付与する必要があります。

注

既定では、セキュリティポリシーは、インターネットから送信されたコードに対するこのアクセス許可を拒否します。このアクセス許可は、インターネットから生成されたコードに付与しないでください。
呼び出されたメンバーを含むアセンブリの許可セットが呼び出し元のコードを含むアセンブリの許可セットと同じか、またはそのサブセットである限り、コードが非パブリックメンバーを呼び出せるようにするには、呼び出し元のコードを含むアセンブリの許可セットを指定する必要があります。コードには、ReflectionPermissionFlag.RestrictedMemberAccess フラグを使用してReflectionPermissionを付与する必要があります。

たとえば、アプリケーションドメインのインターネットアクセス許可に加えて、ReflectionPermissionFlag.RestrictedMemberAccess フラグを持つReflectionPermissionを付与し、A と B の 2 つのアセンブリを使用してインターネットアプリケーションを実行するとします。

アセンブリ B の許可セットには、A に付与されていない権限が含まれていないため、アセンブリ A はリフレクションを使用してアセンブリ B のプライベートメンバーにアクセスできます。
アセンブリ A は、mscorlib.dllなどの .NET Framework アセンブリのプライベートメンバーにアクセスするためにリフレクションを使用できません。mscorlib.dll は完全に信頼されているため、アセンブリ A に付与されていないアクセス許可を持っています。コードアクセスセキュリティが実行時にスタックをウォークすると、 MemberAccessException がスローされます。

シリアル化

シリアル化の場合、SecurityPermissionAttribute.SerializationFormatter フラグを使用してSecurityPermissionすると、アクセシビリティに関係なく、シリアル化可能な型のメンバーを取得および設定できます。このアクセス許可により、コードはインスタンスのプライベート状態を検出して変更できます。 (適切なアクセス許可が付与されるだけでなく、型はメタデータでシリアル化可能としてマークされている必要があります)。

MethodInfo 型のパラメーター

特に信頼できるコードの場合は、 MethodInfo パラメーターを受け取るパブリックメンバーを記述しないでください。このようなメンバーは、悪意のあるコードに対して脆弱になる可能性があります。たとえば、 MethodInfo パラメーターを受け取る高信頼コードのパブリックメンバーについて考えてみます。パブリックメンバーが、指定されたパラメーターに対して Invoke メソッドを間接的に呼び出しているとします。パブリックメンバーが必要なアクセス許可チェックを実行しない場合、セキュリティシステムは呼び出し元が高信頼であると判断するため、 Invoke メソッドの呼び出しは常に成功します。悪意のあるコードにメソッドを直接呼び出すアクセス許可がない場合でも、パブリックメンバーを呼び出すことによって間接的に行うことができます。

バージョン情報

.NET Framework 4 以降では、透過的なコードではリフレクションを使用してセキュリティクリティカルなメンバーにアクセスすることはできません。
ReflectionPermissionFlag.RestrictedMemberAccess フラグは、.NET Framework 2.0 Service Pack 1 で導入されています。以前のバージョンの .NET Framework では、リフレクションを使用して非パブリックメンバーにアクセスするコードに ReflectionPermissionFlag.MemberAccess フラグが必要です。これは、部分的に信頼されたコードに付与すべきでないアクセス許可です。
.NET Framework 2.0 以降では、リフレクションを使用して非パブリック型とメンバーに関する情報を取得する場合、アクセス許可は必要ありません。以前のバージョンでは、ReflectionPermissionFlag.TypeInformation フラグを使用したReflectionPermissionが必要です。