• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 94, comments - 250, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

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

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

            #include "strsafe.h"

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

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

              我們覺得,缺乏統(tǒng)一性是導(dǎo)致現(xiàn)有許多 C 語言字符串處理函數(shù)容易產(chǎn)生安全漏洞的根本原因,而 strsafe 系列函數(shù)所帶來的高度統(tǒng)一性恰恰是解決此問題的一劑良藥。然而,strsafe 也不是萬能藥。單純依靠 strsafe 系列函數(shù)并不能保證代碼的安全性和堅固性——你還必須開動你的大腦才行——然而這樣對解決問題還是大有幫助的!
            下面給出一段采用經(jīng)典 C 語言運(yùn)行時間函數(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 中保存的是目標(biāo)緩沖區(qū)內(nèi)剩余空間的長度,而不是目標(biāo)緩沖區(qū)的總長度)。于是,“內(nèi)存溢出” 問題將會快找上門來。然而,象這樣的代碼片段早已泛濫成災(zāi)了。如果改用 strsafe 系列函數(shù),那么以上代碼應(yīng)該變成:

            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;
            }						
              這段代碼不但檢查了每一個返回值,還保證了適時傳入同一目標(biāo)緩沖區(qū)的總長度。你還可以采用 Ex 版本的 strsafe 系列函數(shù)來實現(xiàn)更加高級的功能,比如:
            • 獲取目標(biāo)緩沖區(qū)的當(dāng)前指針。
            • 獲取目標(biāo)緩沖區(qū)的剩余空間長度。
            • 以某個特定字符填充空閑緩沖區(qū)。
            • 一旦字符串處理函數(shù)失敗,就把用特定值填充字符串。
            • 一旦字符串處理函數(shù)失敗,就把目標(biāo)緩沖區(qū)設(shè)成 NULL 。

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

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

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

            DWORD dwFlags = STRSAFE_NULL_ON_FAILURE | STRSAFE_FILL_BYTE(0xFE);

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

            Feedback

            # re: Strsafe.h:更安全的C語言字符串處理函數(shù)  回復(fù)  更多評論   

            2009-06-23 08:38 by ufo
            (web server軟件)UFO不會出現(xiàn)一個字節(jié)的內(nèi)存泄漏和一個線程的不能回收,使用UFO做Web Server的好處是網(wǎng)站能做得很穩(wěn)定,永遠(yuǎn)也不會自己down掉;UFO在托管機(jī)房丟包率很高、遭受Hacker攻擊、互聯(lián)網(wǎng) 骨干網(wǎng)被黑等惡劣的環(huán)境條件下仍然能很好地運(yùn)行;UFO在對付Hacker方面(防Hacker弄down和Hacker抓取不該訪問的資源)也有足夠措施。
            另外,UFO幾乎不會進(jìn)行垃圾回收,消耗CPU很少,在普通的PC Server上用UFO運(yùn)行網(wǎng)站,平時CPU占用率<0.1%,最多時也不會超 過5%。您知道,JVM的垃圾回收會導(dǎo)致大量的運(yùn)算,消耗很多CPU,從而導(dǎo)致Server的負(fù)載能力和響應(yīng)速度下降。UFO在對象管理方面采 用了很好的機(jī)制和算法,做得很出色。用UFO運(yùn)行網(wǎng)站,可以一直保證高負(fù)載能力,快速的響應(yīng)速度和低CPU消耗。發(fā)布網(wǎng)址:www.gm365.com

            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            久久精品免费一区二区三区| 性做久久久久久久久| 国产精品久久久久久久久软件| 欧美精品九九99久久在观看| 无码国内精品久久人妻| 国产亚洲精午夜久久久久久| 久久婷婷五月综合色奶水99啪| 久久精品国产99国产电影网| 日本久久久久久久久久| 99久久人妻无码精品系列蜜桃| 国产伊人久久| 国产精品福利一区二区久久| 久久只这里是精品66| 亚洲综合精品香蕉久久网97 | 日本一区精品久久久久影院| 色天使久久综合网天天| 精品精品国产自在久久高清| 伊人久久大香线蕉综合Av| 久久久久免费视频| 国产成人精品久久一区二区三区av | 国产精品青草久久久久福利99| 亚洲精品无码久久千人斩| 久久精品国产亚洲7777| 精品国产91久久久久久久 | 久久久久国产精品三级网| 嫩草伊人久久精品少妇AV| 亚洲国产精品狼友中文久久久| 国产福利电影一区二区三区久久久久成人精品综合 | 久久综合狠狠综合久久综合88| 久久久久国产亚洲AV麻豆| 日韩亚洲欧美久久久www综合网| 久久亚洲AV成人无码国产| 亚洲精品乱码久久久久久蜜桃不卡| 久久人人爽人人爽人人片AV麻烦| 青青青青久久精品国产h久久精品五福影院1421 | 国产精品久久久久久久 | 久久最新免费视频| 亚洲日韩欧美一区久久久久我| 少妇久久久久久被弄到高潮 | 亚洲国产成人久久精品影视| 精品久久一区二区三区|