飛揚天下

作者：Michael Howard
原文出處：Strsafe.h: Safer String Handling in C

　　在微軟公司舉行的Microsoft Windows Security Push 活動期間，一批測試者、程序管理經(jīng)理和普通程序員共同決定要為 C 語言量身定制一套具有較高安全性的字符串處理函數(shù)，并且希望這些函數(shù)能被 Windows 程序員和微軟公司內(nèi)部的程序員所采用。
簡單說來，現(xiàn)有的 C 語言運行時函數(shù)實在難以在當今充斥著惡意攻擊企圖的大環(huán)境下立足。這些函數(shù)要么在返回值和參數(shù)上缺乏一致性，要么隱含著所謂的“截斷誤差”(truncation errors) 錯誤，要么無法提供足夠強大的功能。坦言之，調(diào)用這些函數(shù)的代碼太容易產(chǎn)生“內(nèi)存溢出”問題了。
　　我們發(fā)現(xiàn)，面向 C++ 程序員的類足以應付各種安全處理字符串的編程需要；他們能夠選擇 MFC 的Cstring 類、ATL 的CComBSTR 類 或者STL 的string 類，等等。然而，經(jīng)典的 C 語言程序仍然普遍地存在，何況許多人正在把 C++ 當作 “改良的 C 語言” 來用，卻把豐富的 C++ 類束之高閣。
　　其實只需要添加一行代碼，你就能在 C 語言代碼中調(diào)用安全性良好的 strsafe 系列函數(shù)了，詳細請參閱：
《Using the Strsafe.h Functions》
這些新函數(shù)包含在一個頭文件和一個函數(shù)庫(可選)中，而后兩者能在新版的 Platform SDK 中找到。對，就這么簡單：

#include "strsafe.h"

還等什么呢！
再強調(diào)一次，對 strsafe 函數(shù)庫的引用是可選的。
為了實現(xiàn) strsafe 系列函數(shù)的目標，你的代碼必須滿足下列條件：

• 始終以 NULL 字符結(jié)束字符串。
• 始終檢測目標緩沖區(qū)的長度。
• 始終用 HRESULT 語句產(chǎn)生統(tǒng)一的返回值。
• 兼顧 32 位與 64 位兩種運行環(huán)境。
• 具有靈活性。

　　我們覺得，缺乏統(tǒng)一性是導致現(xiàn)有許多 C 語言字符串處理函數(shù)容易產(chǎn)生安全漏洞的根本原因，而 strsafe 系列函數(shù)所帶來的高度統(tǒng)一性恰恰是解決此問題的一劑良藥。然而，strsafe 也不是萬能藥。單純依靠 strsafe 系列函數(shù)并不能保證代碼的安全性和堅固性——你還必須開動你的大腦才行——然而這樣對解決問題還是大有幫助的！
下面給出一段采用經(jīng)典 C 語言運行時間函數(shù)的代碼：

void UnsafeFunc(LPTSTR szPath,DWORD cchPath) {
	TCHAR szCWD[MAX_PATH];

	GetCurrentDirectory(ARRAYSIZE(szCWD), szCWD);
	strncpy(szPath, szCWD, cchPath);
	strncat(szPath, TEXT("\\"), cchPath);
	strncat(szPath, TEXT("desktop.ini"),cchPath);
}

　　以上代碼中的 bug 隨處可見 —— 它沒有檢查任何一個返回值，而且在對 strncat 函數(shù)的調(diào)用中也沒有正確地使用 cchPath (因為MAX_PATH 中保存的是目標緩沖區(qū)內(nèi)剩余空間的長度，而不是目標緩沖區(qū)的總長度)。于是，“內(nèi)存溢出” 問題將會快找上門來。然而，象這樣的代碼片段早已泛濫成災了。如果改用 strsafe 系列函數(shù)，那么以上代碼應該變成：

bool SaferFunc(LPTSTR szPath,DWORD cchPath) {
	TCHAR szCWD[MAX_PATH];

	if (GetCurrentDirectory(ARRAYSIZE(szCWD), szCWD) &&
			SUCCEEDED(StringCchCopy(szPath, cchPath, szCWD)) &&
			SUCCEEDED(StringCchCat(szPath, cchPath, TEXT("\\"))) &&
			SUCCEEDED(StringCchCat(szPath, cchPath, TEXT("desktop.ini")))) {

			return true;
	}

	return false;
}						

• 獲取目標緩沖區(qū)的當前指針。
• 獲取目標緩沖區(qū)的剩余空間長度。
• 以某個特定字符填充空閑緩沖區(qū)。
• 一旦字符串處理函數(shù)失敗，就把用特定值填充字符串。
• 一旦字符串處理函數(shù)失敗，就把目標緩沖區(qū)設成 NULL 。

　　如此改進后的代碼性能又如何呢？告訴你一個好消息：它與原先的代碼在性能上幾乎沒有差別。我曾在自己的 1.8 GHz 電腦上測試過混用經(jīng)典 C 語言中各種字符串連接函數(shù)的代碼、混用 strsafe 系列中各種字符串連接函數(shù)的代碼和混用 Ex 版本 strsafe 系列中各種字符串連接函數(shù)的代碼。它們各自獨立運行一百萬次(沒錯，就是 10,000,000 次)所消耗的時間分別為：

• 經(jīng)典 C 語言 —— 7.3 秒
• Strsafe 系列—— 8.3 秒
• Strsafe 系列 (Ex 版) —— 11.1 秒

在測試中，調(diào)用 Ex 版本的 strsafe 系列函數(shù)的程序會在調(diào)用失敗時把緩沖區(qū)設為 NULL ，并以 0xFE 作為填充字節(jié)，代碼如下：

DWORD dwFlags = STRSAFE_NULL_ON_FAILURE | STRSAFE_FILL_BYTE(0xFE);

　　其中設置填充字節(jié)的代碼耗時較多。事實上，如果這里僅僅把緩沖區(qū)設置為 NULL 的話，則采用 Ex 版本的 strsafe 系列函數(shù)的代碼將會與采用普通的 strsafe 系列函數(shù)的代碼耗時相同。
　　由此可見，以上三種方案的性能差異極小。我相信你也不會經(jīng)常在一個程序中數(shù)百萬次地反復執(zhí)行包含大量字符串處理函數(shù)的代碼吧！
還有一點值得引起注意：當你引用 strsafe 系列函數(shù)時，原有的 C 語言字符串處理函數(shù)都將被自動進行 #undef 處理。這也沒問題，因為調(diào)試過程中的出錯信息將會告訴你哪些函數(shù)已經(jīng)被相應的 strsafe 系列函數(shù)取代了。好了，請放心地使用 strsafe.h 吧！更多相關(guān)信息請參閱 《Using the Strsafe.h Functions》。