Missing Check against Null

程式可能會解除參照 Null 指標，因為它不會檢查可能傳回 null 的函數回傳值。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

通常會發現兩個顯而易見的問題假設，分別是「這個函數呼叫不可能會出錯」以及「就算函數呼叫失敗也沒關係」。因此當程式設計師忽略函數的回傳值時，這就暗示著他們已經做了上述的假設。
範例 1： 以下程式碼在呼叫 Equals() 成員函數前，不會檢查 Item 屬性回傳的字串是否為 null，可能會造成 null 解除參照。

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

通常對此編碼錯誤的辯解為：

「我知道要求的值會永遠存在，因為…如果這個值不存在，程式就無法執行想要的運作方式，所以無論是我處理這個錯誤或是只要讓程式停止解除參照 null 值都沒有關係。

但是，攻擊者對於在程式中尋找意料之外的情況十分在行，特別是牽涉到異常的時候。

程式可能會解除參照 Null 指標，因為它不會檢查可能傳回 null 的函數回傳值。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

通常會發現兩個顯而易見的問題假設，分別是「這個函數呼叫不可能會出錯」以及「就算函數呼叫失敗也沒關係」。因此當程式設計師忽略函數的回傳值時，這就暗示著他們已經做了上述的假設。
範例 1： 以下程式碼中，在使用由 malloc() 回傳的指標之前，並不會檢查記憶體是否已成功分配。

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

通常對此編碼錯誤的辯解為：

「如果我的程式耗盡了所有的記憶體的話，它將必定會失敗。當程式試圖忽略一個 Null 指標時，無論是我處理這個錯誤，還是只是簡單讓程式由於程式分段錯誤而自行崩潰都沒什麼關係。」

但是這個藉口忽略了以下三個重要的因素：

- 視應用程式的類型以及大小而定，在釋放記憶體的同時，該記憶體在別處正在被其他程式函數使用，而這不會影響其他程式函數的正常執行。

- 程式無法在需要時執行正常結束。如果程式執行不可部分完成的作業，它會使系統處於不一致狀態。

- 程式設計師失去了記錄診斷資訊的機會。對 malloc() 呼叫的失敗是由於 req_size 太大，或者因為在同一時刻有太多的要求需要被處理？或者是由於建立已久的記憶體洩露所引起的？若不處理此錯誤，我們將永遠不知道答案。