五種常見的ASP.NET安全缺陷

< DOCTYPE html PUBLIC -WCDTD XHTML TransitionalEN httpwwwworgTRxhtmlDTDxhtml-transitionaldtd>

五種常見的ASP.NET安全缺陷 　保證應用程式的安全應當從編寫第一行代碼的時候開始做起，原因很簡單，随着應用規模的發展，修補安全漏洞所需的代價也随之快速增長。根據IBM的系統科學協會（Systems Sciences Institute）的研究，如果等到軟體部署之後再來修補缺陷，其代價相當于開發期間檢測和消除缺陷的15倍。

　　為了用最小的代價保障應用程式的安全，在代碼本身的安全性、抗禦攻擊的能力等方面，開發者應當擔負更多的責任。然而，要從開發的最初階段保障程式的安全性，必須具有相應的技能和工具，而真正掌握這些技能和工具的開發者并不是很多。雖然學寫安全的代碼是一個複雜的過程，最好在大學、内部教育訓練會、行業會議上完成，但隻要掌握了下面五種常見的ASP.NET應用安全缺陷以及推薦的修正方案，就能夠領先一步，将不可或缺的安全因素融入到應用的出生之時。

　　一、不能盲目相信使用者輸入

　　在Web應用開發中，開發者最大的失誤往往是無條件地信任使用者輸入，假定使用者（即使是惡意使用者）總是受到浏覽器的限制，總是通過浏覽器和伺服器互動，進而打開了攻擊Web應用的大門。實際上，黑客們攻擊和操作Web網站的工具很多，根本不必局限于浏覽器，從最低級的字元模式的原始界面（例如telnet），到CGI腳本掃描器、Web代理、Web應用掃描器，惡意使用者可能采用的攻擊模式和手段很多。

　　是以，隻有嚴密地驗證使用者輸入的合法性，才能有效地抵抗黑客的攻擊。應用程式可以用多種方法（甚至是驗證範圍重疊的方法）執行驗證，例如，在認可使用者輸入之前執行驗證，確定使用者輸入隻包含合法的字元，而且所有輸入域的内容長度都沒有超過範圍（以防範可能出現的緩沖區溢出攻擊），在此基礎上再執行其他驗證，確定使用者輸入的資料不僅合法，而且合理。必要時不僅可以采取強制性的長度限制政策，而且還可以對輸入内容按照明确定義的特征集執行驗證。下面幾點建議将幫助你正确驗證使用者輸入資料：

　　⑴ 始終對所有的使用者輸入執行驗證，且驗證必須在一個可靠的平台上進行，應當在應用的多個層上進行。

　　⑵ 除了輸入、輸出功能必需的資料之外，不要允許其他任何内容。

　　⑶ 設立“信任代碼基地”，允許資料進入信任環境之前執行徹底的驗證。

　　⑷ 登入資料之前先檢查資料類型。

　　⑸ 詳盡地定義每一種資料格式，例如緩沖區長度、整數類型等。

　　⑹ 嚴格定義合法的使用者請求，拒絕所有其他請求。

　　⑺ 測試資料是否滿足合法的條件，而不是測試不合法的條件。這是因為資料不合法的情況很多，難以詳盡列舉。

　　二、五種常見的ASP.NET安全缺陷

　　下面給出了五個例子，闡述如何按照上述建議增強應用程式的安全性。這些例子示範了代碼中可能出現的缺陷，以及它們帶來的安全風險、如何改寫最少的代碼來有效地降低攻擊風險。

　　2.1 篡改參數

　　◎ 使用ASP.NET域驗證器

　　盲目信任使用者輸入是保障Web應用安全的第一敵人。使用者輸入的主要來源是HTML表單中送出的參數，如果不能嚴格地驗證這些參數的合法性，就有可能危及伺服器的安全。

　　下面的C#代碼查詢後端SQL Server資料庫，假設user和password變量的值直接取自使用者輸入：

SqlDataAdapter my_query = new SqlDataAdapter(

"SELECT * FROM accounts WHERE acc_user='" + user + "' AND acc_password='" + password, the_connection);  

　　從表面上看，這幾行代碼毫無問題，實際上卻可能引來SQL注入式攻擊。攻擊者隻要在user輸入域中輸入“OR 1=1”，就可以順利登入系統，或者隻要在查詢之後加上适當的調用，就可以執行任意Shell指令：

'; EXEC master..xp_cmdshell(Oshell command here')--  

　　■ 風險分析

　　在編寫這幾行代碼時，開發者無意之中作出了這樣的假定：使用者的輸入内容隻包含“正常的”資料----合乎人們通常習慣的使用者名字、密碼，但不會包含引号之類的特殊字元，這正是SQL注入式攻擊能夠得逞的根本原因。黑客們可以借助一些具有特殊含義的字元改變查詢的本意，進而調用任意函數或過程。

　　■ 解決方案

　　域驗證器是一種讓ASP.NET開發者對域的值實施限制的機制，例如，限制使用者輸入的域值必須比對特定的表達式。

　　要防止上述攻擊行為得逞，第一種辦法是禁止引号之類的特殊字元輸入，第二種辦法更嚴格，即限定輸入域的内容必須屬于某個合法字元的集合，例如“[a-zA-Z0-9]*”。

　　2.2 篡改參數之二

　　◎ 避免驗證操作的漏洞

　　然而，僅僅為每個輸入域引入驗證器還不能防範所有通過修改參數實施的攻擊。在執行數值範圍檢查之時，還要指定正确的資料類型。

　　也就是說，在使用ASP.NET的範圍檢查控件時，應當根據輸入域要求的資料類型指定适當的Type屬性，因為Type的預設值是String。

<!-- 要求輸入值必須是1-9之間的數字 -->

<asp:RangeValidator ... MinimumValue="1" MaximumValue="9" .../>  

　　由于沒有指定Type屬性值，上面的代碼将假定輸入值的類型是String，是以RangeValidator驗證器隻能確定字元串由0-9之間的字元開始，“0abcd”也會被認可。

　　要確定輸入值确實是整數，正确的辦法是将Type屬性指定為Integer：

<asp:RangeValidator ... MinimumValue="1"

MaximumValue="9" Type="Integer"  

　　2.3 資訊洩漏

　　◎ 讓隐藏域更加安全

　　在ASP.NET應用中，幾乎所有HTML頁面的__VIEWSTATE隐藏域中都可以找到有關應用的資訊。由于__VIEWSTATE是BASE 64編碼的，是以常常被忽略，但黑客可以友善地解碼BASE 64資料，用不着花什麼力氣就可以得到__VIEWSTATE提供的詳細資料。

　　預設情況下，__VIEWSTATE資料将包含：

　　⑴ 來自頁面控件的動态資料。

　　⑵ 開發者在ViewState中顯式儲存的資料。

　　⑶ 上述資料的密碼簽字。

　　設定EnableViewStatMAC="true"，啟用__VIEWSTATE資料加密功能。然後，将machineKey驗證類型設定成3DES，要求ASP.NET用Triple DES對稱加密算法加密ViewState資料。

　　2.4 SQL注入式攻擊

　　◎ 使用SQL參數API

　　正如前文“篡改參數”部分描述的，攻擊者可以在輸入域中插入特殊字元，改變SQL查詢的本意，欺騙資料庫伺服器執行惡意的查詢。

　　惡意查詢有可能擷取後端資料庫儲存的任何資訊，例如客戶信用卡号碼的清單。

　　除了前面介紹的辦法----用程式代碼確定輸入内容隻包含有效字元，另一種更加健壯的辦法是使用SQL參數API（例如ADO.NET提供的API），讓程式設計環境的底層API（而不是程式員）來構造查詢。

　　使用這些API時，開發者或者提供一個查詢模闆，或者提供一個存儲過程，然後指定一系列的參數值，由底層API将參數值嵌入到查詢模闆，然後将構造出來的查詢送出給伺服器查詢。這種辦法的好處是確定參數能夠正确地嵌入，例如，系統将對引号進行轉義處理，從根本上杜絕SQL注入式攻擊的發生。同時，在表單中引号仍是一個允許輸入的有效字元，這也是使用底層API的一個優點。

　　按照這種思路修改前文“篡改參數”部分的例子，結果如下：

SqlDataAdapter my_query = new SqlDataAdapter("SELECT * FROM accounts

WHERE acc_user= @user AND ", the_connection);

SqlParameter userParam = my_query.Select_Command.Parameters.Add(

"@user",SqlDb.VarChar,20);

userParam.Value=user;

SqlParameter passwordParam = my_query.Select_Command.Parameters.Add(

"@",SqlDb.VarChar,20);

passwordParam.Value=password;  

　　2.5 跨站腳本執行

　　◎ 對外發的資料進行編碼

　　跨站腳本執行（Cross-site scripting）是指将惡意的使用者輸入嵌入到應答（HTML）頁面。例如，下面的ASP.NET頁面雖然簡單，卻包含着一個重大的安全缺陷：

<%@ Page Language="vb" %>

<asp:Label id="Label1" runat="server">

标簽文字

</asp:Label>

<form method="post" runat="server" ID="Form1">

請在此處輸入回報資訊<br>

<asp:Textbox ID="feedback" runat="server"/><br>

<asp:Button id="cmdSubmit" runat="server"

Text="送出!" OnClick="do_feedback">

</asp:Button>

</form>

<script runat="server">

Sub do_feedback(sender As Object, e As System.EventArgs)

Label1.Text=feedback.Text

End Sub

</script>  

　　攻擊者可以用JavaScript代碼構造一個惡意的查詢，點選連結時JavaScript就會運作。舉例來說，腳本可以通過下面的使用者輸入來嵌入：

<script>alert(document.cookie)

</script>

　　在一個雙層的安全體系中，對HTML頁面中出現的外發使用者資料執行輸入驗證和HTML編碼，確定浏覽器隻把使用者輸入資料當成純粹的文本，而不是其他具有特殊含義的内容，例如HTML代碼、JavaScript腳本。

　　對于本例，隻要加入一個HtmlEncode調用即可：

Label1.Text=Server.HtmlEncode(feedback.Text)  

　　這樣，應答HTML流将包含使用者輸入内容的HTML編碼版本，也就是說，浏覽器不會執行使用者輸入的JavaScript代碼，因為根本不存在HTML的“<SCRIPT>”标記，使用者輸入的“<”和“>”字元已經被替換成HTML編碼版本，即“<”和“>”。

　　三、使用自動安全測試工具

　　由于客戶需求不斷變化，一些機關平均每三個月就要部署新的應用，同時由于人員流動，是以對開發者快速開發健壯的、高品質的代碼寄予很高的期望。雖然對所有開發者進行代碼安全技術的教育訓練是十分必要的，但不可否認，自動檢測代碼安全漏洞的工具也有助于快速開發安全的應用程式。

　　到目前為止，開發者常用的工具隻能涵蓋功能測試的特定方面，例如性能測試，BUG/故障點偵查。人工檢查代碼有着許多與生俱來的局限，而且要求開發者具有豐富的代碼安全經驗，是以對于編寫高品質的應用來說，面向應用程式安全及其在惡意環境下行為的工具也是十分關鍵的。

　　要迅速提高應用的品質和安全性，最有效的辦法是給開發者提供一個自動測試應用的工具。如果在單元測試期間，工具能夠檢測出應用的安全缺陷，并将修補建議嵌入到代碼之中，開發者就能立即找出代碼中存在的錯誤，不僅友善了現有錯誤的修改，而且也有助于避免将來再犯同樣的錯誤，不斷地提高代碼抗禦攻擊的能力。

　　結束語：Web服務應用正在爆炸式增長，越來越多的應用被推出到防火牆之外，安全性脆弱的Web應用面臨的風險也隻會有增無減。同時，為了在緊迫的時限之前快速完成應用開發，開發者面臨的壓力也越來越大。注重編寫代碼時的安全問題，同時投入必要的資源，這樣才能為未來的Web服務應用做好準備，同時確定目前應用的高品質。隻有從應用的出生之日開始就采取正确的措施來確定其安全性，才能構造出高品質、安全的應用。

本文轉自 netcorner 部落格園部落格，原文連結：http://www.cnblogs.com/netcorner/archive/2007/05/21/2912376.html  ，如需轉載請自行聯系原作者