幫助程序員解脫困境的十條技巧

2019-11-17 05:37:29

字體：大中小

供稿：網(wǎng)友

　　安全專家 Michael Howard 和 Keith Brown 提出了十條技巧來(lái)幫助您解脫困境。

安全問(wèn)題涉及許多方面。安全風(fēng)險(xiǎn)可能來(lái)自任何地方。您可能編寫(xiě)了無(wú)效的錯(cuò)誤處理代碼，或者在賦予權(quán)限時(shí)過(guò)于慷慨。您可能忘記了在您的服務(wù)器上正在運(yùn)行什么服務(wù)。您可能接受了所有用戶輸入。如此等等。為使您在保護(hù)自己的計(jì)算機(jī)、網(wǎng)絡(luò)和代碼方面有個(gè)良好開(kāi)端，這里展示了十條技巧，遵循這些技巧可以獲得一個(gè)更安全的網(wǎng)絡(luò)策略。

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

即使不閱讀余下的內(nèi)容，也要記住一點(diǎn)，“不要信任用戶輸入”。假如您總是假設(shè)數(shù)據(jù)是有效的并且沒(méi)有惡意，那么問(wèn)題就來(lái)了。大多數(shù)安全薄弱環(huán)節(jié)都與攻擊者向服務(wù)器提供惡意編寫(xiě)的數(shù)據(jù)有關(guān)。
信任輸入的正確性可能會(huì)導(dǎo)致緩沖區(qū)溢出、跨站點(diǎn)腳本攻擊、SQL 插入代碼攻擊等等。
讓我們具體討論一下這些潛在攻擊方式。

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

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

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

問(wèn)題在哪里？事實(shí)上，假如 cBuffSrc 和 cbBuffSrc 來(lái)自可信賴的源（例如不信任數(shù)據(jù)并因此而驗(yàn)證數(shù)據(jù)的有效性和大小的代碼），則這段代碼沒(méi)有任何問(wèn)題。然而，假如數(shù)據(jù)來(lái)自不可信賴的源，也未得到驗(yàn)證，那么攻擊者（不可信賴源）很輕易就可以使cBuffSrc 比 cBuffDest 大，同時(shí)也將 cbBuffSrc 設(shè)定為比 cBuffDest 大。當(dāng) memcpy將數(shù)據(jù)復(fù)制到 cBuffDest 中時(shí)，來(lái)自 DoSomething 的返回地址就會(huì)被更改，因?yàn)閏BuffDest 在函數(shù)的堆棧框架上與返回地址相鄰，此時(shí)攻擊者即可通過(guò)代碼執(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ū)溢出的正確編寫(xiě)的函數(shù)的三個(gè)特性。首先，它要求調(diào)用者提供緩沖區(qū)的長(zhǎng)度。當(dāng)然，您不能盲目相信這個(gè)值！接下來(lái)，在一個(gè)調(diào)試版本中，代碼將探測(cè)緩沖區(qū)是否真的足夠大，以便能夠存放源緩沖區(qū)。假如不能，則可能觸發(fā)一個(gè)訪問(wèn)沖突并把代碼載入調(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: SaferString Handling in C（英文）中找到它們。

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

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

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

有多少人曾經(jīng)見(jiàn)過(guò)類似的代碼？但令人驚奇的是它有問(wèn)題！通常，用戶會(huì)使用類似如下的 URL 訪問(wèn)這段代碼： http://eXPlorationair.com/welcome.ASPx?name=Michael[m

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

您將得到一個(gè)網(wǎng)頁(yè)，上面顯示一個(gè)對(duì)話框，顯示“您好！”。您可能會(huì)說(shuō)，“那又怎樣？”想像一下，攻擊者可以誘導(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)
{
// 好！字符串沒(méi)問(wèn)題
}
else
{
// 不好！字符串無(wú)效
}

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

HTML 或腳本不可能蒙混過(guò)此正則表達(dá)式！不要使用正則表達(dá)式尋找無(wú)效字符并在發(fā)現(xiàn)這種無(wú)效字符后拒絕請(qǐng)求，因?yàn)檩p易出現(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)問(wèn)題的字符串。

4. 不要請(qǐng)求 sa 權(quán)限

我們要討論的最后一種輸入信任攻擊是 SQL 插入代碼。許多開(kāi)發(fā)人員編寫(xiě)這樣的代碼，即獲取輸入并使用該輸入來(lái)建立 SQL 查詢，進(jìn)而與后臺(tái)數(shù)據(jù)存儲(chǔ)（如 Microsoft SQL Server 或 Oracle）進(jìn)行通信。

請(qǐng)看以下代碼片段：

void DoQuery(string Id)
{
SqlConnection sql=new SqlConnection(@"data source=localhost;" + "user id=sa;password=password;");
sql.Open();
sqlstring= "SELECT hasshipped" + " FROM shipping WHERE id='" + Id + "'";
SqlCommand cmd = new SqlCommand(sqlstring,sql);
...
}

這段代碼有三個(gè)嚴(yán)重缺陷。首先，它是以系統(tǒng)治理員帳戶 sa 建立從 Web 服務(wù)到SQL Server的連接的。不久您就會(huì)看到這樣做的缺陷所在。第二點(diǎn)，注重使用“password”作為 sa帳戶密碼的聰明做法！但真正值得關(guān)注的是構(gòu)造 SQL 語(yǔ)句的字符串連接。假如用戶為 ID 輸入 1001，您會(huì)得到如下 SQL 語(yǔ)句，它是完全有效的。

SELECT hasshipped FROM shipping WHERE id = '1001'

但攻擊者比這要有創(chuàng)意得多。他們會(huì)為 ID 輸入一個(gè)“'1001' DROP table shipping --”，它將執(zhí)行如下查詢：

SELECT hasshipped FROM shipping WHERE id = '1001' DROP table shipping -- ';

它更改了查詢的工作方式。這段代碼不僅會(huì)嘗試判定是否裝運(yùn)了某些貨物，它還會(huì)繼續(xù) drop（刪除）shipping 表！操作符 -- 是 SQL 中的注釋操作符，它使攻擊者能夠更輕易地構(gòu)造一系列有效但危險(xiǎn)的 SQL 語(yǔ)句！

這時(shí)您也許會(huì)覺(jué)得希奇，怎么任何一個(gè)用戶都能刪除 SQL Server 數(shù)據(jù)庫(kù)中的表呢。當(dāng)然，您是對(duì)的，只有治理員才能做這樣的工作。但這里您是作為 sa 連接到數(shù)據(jù)庫(kù)的，而 sa 能在 SQL Server 數(shù)據(jù)庫(kù)上做他想做的任何事。永遠(yuǎn)不要在任何應(yīng)用程序中以 sa連接 SQL Server；正確的做法是，假如合適，使用 Windows 集成的身份驗(yàn)證，或者以一個(gè)預(yù)先定義的具有適當(dāng)權(quán)限的帳戶連接。

修復(fù) SQL 插入代碼問(wèn)題很輕易。使用 SQL 存儲(chǔ)過(guò)程及參數(shù)，下面的代碼展示了創(chuàng)建這種查詢的方法 - 以及如何使用正則表達(dá)式來(lái)確認(rèn)輸入有效，因?yàn)槲覀兊慕灰滓?guī)定貨運(yùn)ID 只能是 4 到 10 位數(shù)字：

Regex r = new Regex(@"^/d{4,10}$");
if (!r.Match(Id).Success)
throw new Exception("無(wú)效 ID");

SqlConnection sqlConn= new SqlConnection(strConn);

string str="sp_HasShipped";
SqlCommand cmd = new SqlCommand(str,sqlConn);
cmd.CommandType = CommandType.StoredPRocedure;
cmd.Parameters.Add("@ID",Id);

緩沖區(qū)溢出、跨站點(diǎn)腳本和 SQL 插入代碼攻擊都是信任輸入問(wèn)題的示例。所有這些攻擊都能通過(guò)一種機(jī)制來(lái)減輕危害，即認(rèn)為所有輸入都是有害的，除非獲得證實(shí)。

5. 注重加密代碼！

下面我們來(lái)看些會(huì)讓我們吃驚的東西。我發(fā)現(xiàn)我們檢查的安全代碼中百分之三十以上都存在安全漏洞。最常見(jiàn)的漏洞可能就是自己的加密代碼，這些代碼很可能不堪一擊。永遠(yuǎn)不要?jiǎng)?chuàng)建自己的加密代碼，那是徒勞的。不要認(rèn)為僅僅因?yàn)槟凶约旱募用芩惴ㄆ渌司蜔o(wú)法破解。攻擊者能使用調(diào)試器，他們也有時(shí)間和知識(shí)來(lái)確認(rèn)系統(tǒng)如何工作 - 通常在幾小時(shí)內(nèi)就會(huì)破解它們。您應(yīng)該使用 Win32? 的CryptoAPI，system.Security.Cryptography 命名空間提供了大量?jī)?yōu)秀且經(jīng)過(guò)測(cè)試的加密算法。

6. 減少自己被攻擊的可能性

假如沒(méi)有百分之九十以上的用戶要求，則不應(yīng)默認(rèn)安裝某一功能。Internet Information Services (IIS) 6.0 遵循了這一安裝建

上一篇：大中小車?yán)浀膯?wèn)題

下一篇：從當(dāng)前的瀏覽器取得當(dāng)前URL