Strsafe.h:更安全的C語言字串處理函數

來源:互聯網
上載者:User
原文出處:Strsafe.h: Safer String Handling in C

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

#include "strsafe.h"

還等什麼呢!
再強調一次,對 strsafe 函數庫的引用是可選的。
為了實現 strsafe 系列函數的目標,你的代碼必須滿足下列條件:

  • 始終以 NULL 字元結束字串。
  • 始終檢測目標緩衝區的長度。
  • 始終用 HRESULT 語句產生統一的傳回值。
  • 兼顧 32 位與 64 位元兩種運行環境。
  • 具有靈活性。

  我們覺得,缺乏統一性是導致現有許多 C 語言字串處理函數容易產生安全性漏洞的根本原因,而 strsafe 系列函數所帶來的高度統一性恰恰是解決此問題的一劑良藥。然而,strsafe 也不是萬能藥。單純依靠 strsafe 系列函數並不能保證代碼的安全性和堅固性——你還必須開動你的大腦才行——然而這樣對解決問題還是大有協助的!
下面給出一段採用經典 C 語言已耗用時間函數的代碼:

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 函數的調用中也沒有正確地使用 cchPath (因為MAX_PATH 中儲存的是目標緩衝區內剩餘空間的長度,而不是目標緩衝區的總長度)。於是,“記憶體溢出” 問題將會快找上門來。然而,象這樣的程式碼片段早已泛濫成災了。如果改用 strsafe 系列函數,那麼以上代碼應該變成:

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;}

  這段代碼不但檢查了每一個傳回值,還保證了適時傳入同一目標緩衝區的總長度。你還可以採用 Ex 版本的 strsafe 系列函數來實現更加進階的功能,比如:

  • 擷取目標緩衝區的當前指標。
  • 擷取目標緩衝區的剩餘空間長度。
  • 以某個特定輸入鍵台空閑緩衝區。
  • 一旦字串處理函數失敗,就把用特定值填充字串。
  • 一旦字串處理函數失敗,就把目標緩衝區設成 NULL 。

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

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

在測試中,調用 Ex 版本的 strsafe 系列函數的程式會在調用失敗時把緩衝區設為 NULL ,並以 0xFE 作為填充位元組,代碼如下:

DWORD dwFlags = STRSAFE_NULL_ON_FAILURE | STRSAFE_FILL_BYTE(0xFE);

  其中設定填充位元組的代碼耗時較多。事實上,如果這裡僅僅把緩衝區設定為 NULL 的話,則採用 Ex 版本的 strsafe 系列函數的代碼將會與採用普通的 strsafe 系列函數的代碼耗時相同。
  由此可見,以上三種方案的效能差異極小。我相信你也不會經常在一個程式中數百萬次地反覆執行包含大量字串處理函數的代碼吧!
還有一點值得引起注意:當你引用 strsafe 系列函數時,原有的 C 語言字串處理函數都將被自動進行 #undef 處理。這也沒問題,因為調試過程中的出錯資訊將會告訴你哪些函數已經被相應的 strsafe 系列函數取代了。好了,請放心地使用 strsafe.h 吧!更多相關資訊請參閱 《Using the Strsafe.h Functions》。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.