Missing Check against Null

プログラムは、null を戻すことがある関数の戻り値を確認しないため、NULL ポインタを間接参照する場合があります。

ソフトウェアシステムに対する重大な攻撃は、ほぼすべて、プログラマにとって想定外の事態から始まります。実際に攻撃を受けた後にはプログラマの仮定は脆弱で根拠薄弱に思われます。しかし、攻撃以前は多くのプログラマがその仮定を情熱的に弁護するものです。

コードの中に簡単に見つかる 2 つの疑わしい仮定は、「この関数コールは決して失敗しない」、および「この関数コールが失敗するかどうかは重要ではない」です。プログラマが関数の戻り値を無視しているのであれば、それはいずれかの仮定に基づいて作業していると暗黙のうちに認めていることを意味します。
例 1: 次のコードは、Item プロパティによって戻される文字列が null かどうかを、メンバー関数 Equals() をコールする前にチェックしないので、null Dereference の原因になる可能性があります。

string itemName = request.Item(ITEM_NAME);
	if (itemName.Equals(IMPORTANT_ITEM)) {
		...
	}
	...

このコーディングエラーに対しては通常、次のような弁解がなされます。

「これこれの理由で、リクエストされた値が常に存在することはわかっています。値が存在しなければプログラムは目的の動作を実行できないので、エラーをプログラマが処理しても、null 値を間接参照してプログラムが異常終了するのにまかせても同じことです。」

しかし攻撃者は、特に例外に関しては、プログラム内にある想定外のパスを巧妙に見つけ出します。

プログラムは、null を返すことがある関数の戻り値を確認しないため、NULL ポインタを間接参照する場合があります。

ソフトウェアシステムに対する重大な攻撃は、ほぼすべて、プログラマにとって想定外の事態から始まります。実際に攻撃を受けた後にはプログラマの仮定は脆弱で根拠薄弱に思われます。しかし、攻撃以前は多くのプログラマがその仮定を情熱的に弁護するものです。

コードの中に簡単に見つかる 2 つの疑わしい仮定は、「この関数コールは決して失敗しない」、および「この関数コールが失敗するかどうかは重要ではない」です。プログラマが関数の戻り値を無視しているのであれば、それはいずれかの仮定に基づいて作業していると暗黙のうちに認めていることを意味します。
例 1: 次のコードでは、malloc() で戻されたポインタを使用する前に、メモリの割り当てが正しく行われたかチェックしていません。

    buf = (char*) malloc(req_size);
    strncpy(buf, xfer, req_size);

このコーディングエラーに対しては通常、次のような弁解がなされます。

「記述したプログラムでメモリ不足になったら、プログラムの実行に失敗するだろう。エラー処理をするか、NULL ポインタへの間接参照を試行して単にプログラムをセグメンテーション違反で異常終了させるかは、さほど重要な問題ではない。」

この主張では、次の重要な 3 つの問題点を考慮していません。

- アプリケーションのタイプとサイズによっては、他の場所で使用中のメモリを解放してプログラムの実行を継続できる可能性もあります。

- 必要な場合にプログラムが安全な終了を実行するのは不可能です。プログラムが自動操作を実行すると、システムは不整合な状態になる可能性があります。

- プログラマは、診断データを記録する機会を失います。malloc() のコールが失敗に終わった理由が、req_size の超過によるものか、許容範囲外の同時処理によるものか定かではありません。時間の経過とともに蓄積された Memory Leak によるものかも不明です。エラー処理を怠ると、原因を究明する術はありません。