4. 不要請求 sa 權限　　

　　我們要討論的最后一種輸入信任攻擊是 SQL 插入代碼。許多開發人員編寫這樣的代碼，即獲取輸入并使用該輸入來建立 SQL 查詢，進而與后臺數據存儲（如 Microsoft? SQL Server? 或 Oracle）進行通信。

　　請看以下代碼片段：


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);
???

　　這段代碼有三個嚴重缺陷。首先，它是以系統管理員帳戶 sa 建立從 Web 服務到 SQL Server 的連接的。不久您就會看到這樣做的缺陷所在。第二點，注意使用“password”作為 sa 帳戶密碼的聰明做法！
但真正值得關注的是構造 SQL 語句的字符串連接。如果用戶為 ID 輸入 1001，您會得到如下 SQL 語句，它是完全有效的。

　　SELECT hasshipped FROM shipping WHERE id = '1001'

　　但攻擊者比這要有創意得多。他們會為 ID 輸入一個“'1001' DROP table shipping --”，它將執行如下查詢：

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

　　它更改了查詢的工作方式。這段代碼不僅會嘗試判斷是否裝運了某些貨物，它還會繼續 drop（刪除）shipping 表！操作符 -- 是 SQL 中的注釋操作符，它使攻擊者能夠更容易地構造一系列有效但危險的 SQL 語句！

　　這時您也許會覺得奇怪，怎么任何一個用戶都能刪除 SQL Server 數據庫中的表呢。當然，您是對的，只有管理員才能做這樣的工作。但這里您是作為 sa 連接到數據庫的，而 sa 能在 SQL Server 數據庫上做他想做的任何事。永遠不要在任何應用程序中以 sa 連接 SQL Server；正確的做法是，如果合適，使用 Windows 集成的身份驗證，或者以一個預先定義的具有適當權限的帳戶連接。

　　修復 SQL 插入代碼問題很容易。使用 SQL 存儲過程及參數，下面的代碼展示了創建這種查詢的方法 - 以及如何使用正則表達式來確認輸入有效，因為我們的交易規定貨運 ID 只能是 4 到 10 位數字：

Regex r = new Regex(@"^d{4,10}$");
if (!r.Match(Id).Success)
throw new Exception("無效 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);

　　緩沖區溢出、跨站點腳本和 SQL 插入代碼攻擊都是信任輸入問題的示例。所有這些攻擊都能通過一種機制來減輕危害，即認為所有輸入都是有害的，除非獲得證明。

　　5. 注意加密代碼！

　　下面我們來看些會讓我們吃驚的東西。我發現我們檢查的安全代碼中百分之三十以上都存在安全漏洞。最常見的漏洞可能就是自己的加密代碼，這些代碼很可能不堪一擊。永遠不要創建自己的加密代碼，那是徒勞的。不要認為僅僅因為您有自己的加密算法其他人就無法破解。攻擊者能使用調試器，他們也有時間和知識來確認系統如何工作 - 通常在幾小時內就會破解它們。您應該使用 Win32? 的 CryptoAPI，System.Security.Cryptography 命名空間提供了大量優秀且經過測試的加密算法。

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

　　如果沒有百分之九十以上的用戶要求，則不應默認安裝某一功能。Internet Information Services (IIS) 6.0 遵循了這一安裝建議，您可以在這個月發布的 Wayne Berry 的文章“Innovations in Internet Information Services Let You Tightly Guard Secure Data and Server Processes”中讀到相關內容。這種安裝策略背后的思想是您不會注意自己并未使用的服務，如果這些服務正在運行，則可能被其他人利用。如果默認安裝某功能，則它應在最小授權原則下運行。也就是說，除非必要，否則不要允許使用管理員權限運行應用程序。最好遵循這一忠告。

　　7. 使用最小授權原則

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

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

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