界: API Abuse

API 就像是呼叫者與被呼叫者之間簽訂的規定。最常見的 API 濫用形式是由呼叫者這一當事方未能遵守此規定所造成的。例如，如果程式在呼叫 chroot() 後無法呼叫 chdir()，即違反規範如何以安全方式變更使用中根目錄的規定。程式庫濫用的另一個好例子是期待被呼叫者向呼叫者傳回值得信賴的 DNS 資訊。在這種情況下，呼叫者是透過對其行為做出某些假設 (傳回值可用於驗證目的) 來濫用被呼叫者 API。另一方也可能違反呼叫者與被呼叫者間的規定。例如，如果編碼器衍生出子類別 SecureRandom 並傳回一個非隨機值，則違反了規定。

Often Misused: File System

Abstract

將長度不適當的輸出緩衝區傳送給 Path Manipulation 函數會導致 Buffer overflow。

Explanation

Windows 提供了許多的公用程式函數來操作包含著檔案名稱的緩衝區。在大多數情況下，結果會回傳在做為輸入傳送的緩衝區中。(通常會適當的修改檔案名稱。)大多數函數至少需要 MAX_PATH 位元組長度的緩衝區，但是你應該檢查每一個函數的文件資料。如果緩衝區不夠大，無法儲存操作的結果，就會發生 Buffer overflow。

範例 1：


char *createOutputDirectory(char *name) {
	char outputDirectoryName[128];
	if (getCurrentDirectory(128, outputDirectoryName) == 0) {
		return null;
	}
	if (!PathAppend(outputDirectoryName, "output")) {
		return null;
	}
	if (!PathAppend(outputDirectoryName, name)) {
		return null;
	}
	if (SHCreateDirectoryEx(NULL, outputDirectoryName, NULL)
        != ERROR_SUCCESS) {
		return null;
	}
	return StrDup(outputDirectoryName);
}

在此範例中，函數在目前目錄中建立了名為「output\<name>」的目錄，並且回傳該名稱的堆積分配副本。對於大多數的目前目錄值和名稱參數，此函數都能夠正常執行。但是如果 name 參數特別長，第二個 PathAppend() 呼叫就可能會溢出 outputDirectoryName 緩衝區，因為這個緩衝區比 MAX_PATH 位元組小。

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560

[2] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation

[3] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow

[4] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4

[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection

[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection

[16] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I

[17] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I

[18] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I

[19] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I

[20] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I

[21] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I

[22] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I

desc.semantic.cpp.often_misused_file_system.windows

Abstract

由 umask() 引數指定的 mask 總是容易與 chmod() 引數混淆。

Explanation

umask() 線上手冊以錯誤陳述式開頭：

「umask sets the umask to mask & 0777」

儘管這種行為最好遵從 chmod() 的用法，即使用者提供的引數指定某些位元在指定的檔案上啟用，但事實上 umask() 的行為恰恰相反： umask() 將 umask 設為 ~mask & 0777。

umask() 線上手冊接下來描述了對於 umask() 的正確使用方式：

「open() 使用 umask 來為新建立的檔案設定初始化檔案權限。特別是，umask 的權限關閉了傳送給 open(2) 的 mode 引數 (例如，一般的 umask 預設值 022 會讓新建立的檔案擁有 0666 & ~022 = 0644 = rw-r--r-- 權限，而在一般情況下，應將 mode 指定為 0666)。」