摘要：涉及安全問題時(shí)，有很多情況都會(huì)導(dǎo)致出現(xiàn)麻煩。您可能信任所有在您的網(wǎng)絡(luò)上運(yùn)行的代碼，賦予所有用戶訪問重要文件的權(quán)限，并且從不費(fèi)神檢查您機(jī)器上的代碼是否已經(jīng)改變。您也可能沒有安裝防病毒軟件，沒有給您自己的代碼建立安全機(jī)制，并賦予太多帳戶以太多的權(quán)限。您甚至可能非常大意地使用大量內(nèi)置函數(shù)從而允許惡意侵入，并且可能任憑服務(wù)器端口開著而沒有任何監(jiān)控措施。顯然，我們還可以舉出更多的例子。哪些是真正重要的問題（即，為了避免危及您的數(shù)據(jù)和系統(tǒng)，應(yīng)立即予以關(guān)注的最危險(xiǎn)的錯(cuò)誤）？安全專家 Michael Howard 和 Keith Brown 提出了十條技巧來幫助您解脫困境。
　　安全問題涉及許多方面。安全風(fēng)險(xiǎn)可能來自任何地方。您可能編寫了無效的錯(cuò)誤處理代碼，或者在賦予權(quán)限時(shí)過于慷慨。您可能忘記了在您的服務(wù)器上正在運(yùn)行什么服務(wù)。您可能接受了所有用戶輸入。如此等等。為使您在保護(hù)自己的計(jì)算機(jī)、網(wǎng)絡(luò)和代碼方面有個(gè)良好開端，這里展示了十條技巧，遵循這些技巧可以獲得一個(gè)更安全的網(wǎng)絡(luò)策略。

　　1. 信任用戶的輸入會(huì)將自己置于險(xiǎn)境

　　即使不閱讀余下的內(nèi)容，也要記住一點(diǎn)，“不要信任用戶輸入”。如果您總是假設(shè)數(shù)據(jù)是有效的并且沒有惡意，那么問題就來了。大多數(shù)安全薄弱環(huán)節(jié)都與攻擊者向服務(wù)器提供惡意編寫的數(shù)據(jù)有關(guān)。

　　信任輸入的正確性可能會(huì)導(dǎo)致緩沖區(qū)溢出、跨站點(diǎn)腳本攻擊、SQL 插入代碼攻擊等等。

　　讓我們?cè)敿?xì)討論一下這些潛在攻擊方式。

　　2. 防止緩沖區(qū)溢出

　　當(dāng)攻擊者提供的數(shù)據(jù)長度大于應(yīng)用程序的預(yù)期時(shí)，便會(huì)發(fā)生緩沖區(qū)溢出，此時(shí)數(shù)據(jù)會(huì)溢出到內(nèi)部存儲(chǔ)器空間。緩沖區(qū)溢出主要是一個(gè) C/C++ 問題。它們是種威脅，但通常很容易修補(bǔ)。我們只看到過兩個(gè)不明顯且難以修復(fù)的緩沖區(qū)溢出。開發(fā)人員沒有預(yù)料到外部提供的數(shù)據(jù)會(huì)比內(nèi)部緩沖區(qū)大。溢出導(dǎo)致了內(nèi)存中其他數(shù)據(jù)結(jié)構(gòu)的破壞，這種破壞通常會(huì)被攻擊者利用，以運(yùn)行惡意代碼。數(shù)組索引錯(cuò)誤也會(huì)造成緩沖區(qū)下溢和超限，但這種情況沒那么普遍。

　　請(qǐng)看以下 C++ 代碼片段：
void DoSomething(char *cBuffSrc, DWORD cbBuffSrc) {
char cBuffDest[32];
memcpy(cBuffDest,cBuffSrc,cbBuffSrc);
}

　　問題在哪里？事實(shí)上，如果 cBuffSrc 和 cbBuffSrc 來自可信賴的源（例如不信任數(shù)據(jù)并因此而驗(yàn)證數(shù)據(jù)的有效性和大小的代碼），則這段代碼沒有任何問題。然而，如果數(shù)據(jù)來自不可信賴的源，也未得到驗(yàn)證，那么攻擊者（不可信賴源）很容易就可以使 cBuffSrc 比 cBuffDest 大，同時(shí)也將 cbBuffSrc 設(shè)定為比 cBuffDest 大。當(dāng) memcpy 將數(shù)據(jù)復(fù)制到 cBuffDest 中時(shí)，來自 DoSomething 的返回地址就會(huì)被更改，因?yàn)?cBuffDest 在函數(shù)的堆�？蚣苌吓c返回地址相鄰，此時(shí)攻擊者即可通過代碼執(zhí)行一些惡意操作。

　　彌補(bǔ)的方法就是不要信任用戶的輸入，并且不信任 cBuffSrc 和 cbBuffSrc 中攜帶的任何數(shù)據(jù)：

void DoSomething(char *cBuffSrc, DWORD cbBuffSrc) {
const DWORD cbBuffDest = 32;
char cBuffDest[cbBuffDest];
#ifdef _DEBUG
memset(cBuffDest, 0x33, cbBuffSrc);
#endif
memcpy(cBuffDest, cBuffSrc, min(cbBuffDest, cbBuffSrc));
}

　　此函數(shù)展示了一個(gè)能夠減少緩沖區(qū)溢出的正確編寫的函數(shù)的三個(gè)特性。首先，它要求調(diào)用者提供緩沖區(qū)的長度。當(dāng)然，您不能盲目相信這個(gè)值！接下來，在一個(gè)調(diào)試版本中，代碼將探測(cè)緩沖區(qū)是否真的足夠大，以便能夠存放源緩沖區(qū)。如果不能，則可能觸發(fā)一個(gè)訪問沖突并把代碼載入調(diào)試器。在調(diào)試時(shí)，您會(huì)驚奇地發(fā)現(xiàn)竟有如此多的錯(cuò)誤。最后也是最重要的是，對(duì) memcpy 的調(diào)用是防御性的，它不會(huì)復(fù)制多于目標(biāo)緩沖區(qū)存放能力的數(shù)據(jù)。

　　在 Windows? Security Push at Microsoft（Microsoft Windows? 安全推動(dòng)活動(dòng)）中，我們?yōu)?C 程序員創(chuàng)建了一個(gè)安全字符串處理函數(shù)列表。您可以在 Strsafe.h: Safer String Handling in C（英文）中找到它們。

　　3. 防止跨站點(diǎn)腳本

　　跨站點(diǎn)腳本攻擊是 Web 特有的問題，它能通過單個(gè) Web 頁中的一點(diǎn)隱患危害客戶端的數(shù)據(jù)。想像一下，下面的 ASP.NET 代碼片段會(huì)造成什么后果：

＜script language=c#＞
Response.Write("您好，" + Request.QueryString("name"));
＜/script＞

　　有多少人曾經(jīng)見過類似的代碼？但令人驚訝的是它有問題！通常，用戶會(huì)使用類似如下的 URL 訪問這段代碼： http://explorationair.com/welcome.aspx?name=Michael

　　該 C# 代碼認(rèn)為數(shù)據(jù)始終是有效的，并且只是包含了一個(gè)名稱。但攻擊者會(huì)濫用這段代碼，將腳本和 HTML 代碼作為名稱提供。如果輸入如下的 URL http://northwindtraders.com/welcome.aspx?name=＜script＞alert('您好！'); ＜/script＞

　　您將得到一個(gè)網(wǎng)頁，上面顯示一個(gè)對(duì)話框，顯示“您好！”。您可能會(huì)說，“那又怎樣？”想像一下，攻擊者可以誘導(dǎo)用戶點(diǎn)擊這樣的鏈接，但查詢字符串中卻包含一些真正危險(xiǎn)的腳本和 HTML，由此會(huì)得到用戶的 cookie 并把它發(fā)送到攻擊者擁有的網(wǎng)站；現(xiàn)在攻擊者便獲得了您的私人 cookie 信息，或許會(huì)更糟。

　　要避免這種情況，有兩種方法。第一種是不信任輸入，并嚴(yán)格限制用戶名所包含的內(nèi)容。例如，可以使用正則表達(dá)式檢查該名稱是否只包含一個(gè)普通的字符子集，并且不太大。以下 C# 代碼片段顯示了完成這一步驟的方法：

Regex r = new Regex(@"^[w]{1,40}$");

if (r.Match(strName).Success) {
// 好！字符串沒問題
} else {
// 不好！字符串無效
}

　　這段代碼使用正則表達(dá)式驗(yàn)證一個(gè)字符串僅包含 1 到 40 個(gè)字母或數(shù)字。這是確定一個(gè)值是否正確的唯一安全方法。

　　HTML 或腳本不可能蒙混過此正則表達(dá)式！不要使用正則表達(dá)式尋找無效字符并在發(fā)現(xiàn)這種無效字符后拒絕請(qǐng)求，因?yàn)槿菀壮霈F(xiàn)漏掉的情況。 第二種防范措施是對(duì)所有作為輸出的輸入進(jìn)行 HTML 編碼。這會(huì)減少危險(xiǎn)的 HTML 標(biāo)記，使之變成更安全的轉(zhuǎn)義符。您可以在 ASP.NET 中使用 HttpServerUtility.HtmlEncode，或者在 ASP 中使用 Server.HTMLEncode 轉(zhuǎn)義任何可能出現(xiàn)問題的字符串。