程序員十大安全技巧

　　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)為所有輸入都是有害的，除非獲得證明。

　　5. 注意加密代碼！

　　下面我們來(lái)看些會(huì)讓我們吃驚的東西。我發(fā)現(xiàn)我們檢查的安全代碼中百分之三十以上都存在安全漏洞。最常見(jiàn)的漏洞可能就是自己的加密代碼，這些代碼很可能不堪一擊。永遠(yuǎn)不要?jiǎng)?chuàng)建自己的加密代碼，那是徒勞的。不要認(rèn)為僅僅因?yàn)槟�有自己的加密算法其他人就無(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 遵循了這一安裝建議，您可以在這個(gè)月發(fā)布的 Wayne Berry 的文章“Innovations in Internet Information Services Let You Tightly Guard Secure Data and Server Processes”中讀到相關(guān)內(nèi)容。這種安裝策略背后的思想是您不會(huì)注意自己并未使用的服務(wù)，如果這些服務(wù)正在運(yùn)行，則可能被其他人利用。如果默認(rèn)安裝某功能，則它應(yīng)在最小授權(quán)原則下運(yùn)行。也就是說(shuō)，除非必要，否則不要允許使用管理員權(quán)限運(yùn)行應(yīng)用程序。最好遵循這一忠告。

　　7. 使用最小授權(quán)原則

　　出于若干原因，操作系統(tǒng)和公共語(yǔ)言運(yùn)行時(shí)有一個(gè)安全策略。很多人以為此安全策略存在的主要原因是防止用戶有意破壞：訪問(wèn)他們無(wú)權(quán)訪問(wèn)的文件、重新配置網(wǎng)絡(luò)以達(dá)到他們的要求以及其他惡劣行為。的確，這種來(lái)自內(nèi)部的攻擊很普遍，也需要防范，但還有另一個(gè)原因需要嚴(yán)守這一安全策略。即在代碼周圍建立起防范壁壘以防止用戶有意或（正如經(jīng)常發(fā)生的）無(wú)意的操作對(duì)網(wǎng)絡(luò)造成嚴(yán)重破壞。例如，通過(guò)電子郵件下載的附件在 Alice 的機(jī)器上執(zhí)行時(shí)被限制為只能訪問(wèn) Alice 可以訪問(wèn)的資源。如果附件中含有特洛伊木馬，那么好的安全策略就是限制它所能產(chǎn)生的破壞。 當(dāng)您設(shè)計(jì)、建立并部署服務(wù)器應(yīng)用程序時(shí)，您不能假設(shè)所有請(qǐng)求都來(lái)自合法用戶。如果一個(gè)壞家伙發(fā)送給您一個(gè)惡意請(qǐng)求（但愿不會(huì)如此）并使您的代碼產(chǎn)生惡劣操作，您會(huì)希望您的應(yīng)用程序擁有所有可能的防護(hù)來(lái)限制損害。因此我們認(rèn)為，您的公司實(shí)施安全策略不僅是因?yàn)樗�不信任您或您的代碼，同時(shí)也是為了保護(hù)不受外界有企圖的代碼的傷害。

　　最小授權(quán)原則認(rèn)為，要在最少的時(shí)間內(nèi)授予代碼所需的最低權(quán)限。也就是說(shuō)，任何時(shí)候都應(yīng)在您的代碼周圍豎起盡可能多的防護(hù)墻。當(dāng)發(fā)生某些不好的事情時(shí) - 就象 Murphy 定律保證的那樣 - 您會(huì)很高興這些防護(hù)墻都處在合適的位置上。因此，這里就使用最小授權(quán)原則運(yùn)行代碼給出了一些具體方法。

　　為您的服務(wù)器代碼選擇一個(gè)安全環(huán)境，僅允許其訪問(wèn)完成其工作所必需的資源。如果您代碼中的某些部分要求很高的權(quán)限，請(qǐng)考慮將這部分代碼分離出來(lái)并單獨(dú)以較高的權(quán)限運(yùn)行。為安全分離這一以不同的操作系統(tǒng)驗(yàn)證信息運(yùn)行的代碼，您最好在一個(gè)單獨(dú)的進(jìn)程（運(yùn)行在具有更高權(quán)限的安全環(huán)境中）中運(yùn)行此代碼。這意味著您將需要進(jìn)程間通訊（如 COM 或 Microsoft .NET 遠(yuǎn)程處理），并且需要設(shè)計(jì)該代碼的接口以使往返行程最小。