アンマネージ コード
更新 : 2007 年 11 月
一部のライブラリ コードは、アンマネージ コードを呼び出す必要があります (たとえば、Win32 などのネイティブ コード API)。これは、マネージ コード用のセキュリティの境界の外部に出ることなので、注意が必要です。コードがセキュリティに中立的な場合、コードとそのコードを呼び出すコードは、アンマネージ コードのアクセス許可 (UnmanagedCode フラグを指定した SecurityPermission) を持つ必要があります。
しかし、呼び出し元がこのような強力なアクセス許可を持つことが不適切な場合もあります。このようなケースでは、信頼されるコードが、「ラッパー コードの保護」で説明したマネージ ラッパーまたはライブラリ コードのように、仲介役になってしまう可能性があります。基になるアンマネージ コードの機能が総合的に安全な場合は、それを直接公開できます。それ以外の場合は、最初に適切なアクセス許可のチェック (demand) が必要です。
コードがアンマネージ コードを呼び出すとき、呼び出し元にアンマネージ コードへのアクセス許可を与えたくない場合は、その権限をアサートする必要があります。アサーションは、フレーム内でのスタック ウォークをブロックします。このプロセスで、セキュリティ ホールを作らないように注意が必要です。通常、これは、呼び出し元の適切なアクセス許可を要求し、アンマネージ コードを使用して、アクセス許可で認められていることだけを実行し、それ以上のことは実行しないことを意味します。日付関数の時刻の取得など、いくつかのケースでは、セキュリティ チェックを一切行わずにアンマネージ コードを呼び出し元に直接公開することがあります。どのようなケースでも、アサートを行うコードはセキュリティ対策を実施することが必要です。
ネイティブ コードへのコード パスを提供するどのようなマネージ コードも、悪意のあるコードのターゲットになる可能性がります。このため、安全に使用できるアンマネージ コードやその使用方法を決めるには、十分な注意が必要です。一般に、どのアンマネージ コードも、部分的な信頼の呼び出し元に直接公開するべきではありません。部分的な信頼のコードから呼び出せるアンマネージ コードをライブラリで使用することの安全性を評価するには、主に次の 2 つの点について考慮する必要があります。
機能。呼び出し元が危険性のある操作を実行できない機能がアンマネージ API によって提供されているかどうかを考慮します。コード アクセス セキュリティはアクセス許可を使用してリソースへのアクセスを強制するため、API がファイル、ユーザー インターフェイス、またはスレッドを使用するかどうか、あるいは、保護されている情報を公開するかどうかを考慮します。API がこれを行うときは、それをラップするマネージ コードが、実行前に必要なアクセス許可を要求する必要があります。また、アクセス許可で保護されていない場合は、メモリへのアクセスを厳密なタイプ セーフに制限する必要があります。
パラメータのチェック。一般的な攻撃は、公開されているアンマネージ コードの API メソッドに予期しないパラメータを渡し、仕様とは異なる動作をさせようと試みます。範囲外のインデックス値やオフセット値を使用するバッファ オーバーラン攻撃は、この種の攻撃の 1 例で、パラメータの基のコードのバグを攻略します。このため、アンマネージ コード API が部分的な信頼の呼び出し元に対して安全に機能している場合でも (必要な demand の後)、マネージ コードもパラメータの正当性を二重にチェックし、悪意のあるコードが、マネージ コードのラッパー レイヤを使用して予期しない呼び出しを行うのを不可能にすることが必要です。