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

保證應用程序的安全應當從編寫第一行代碼的時候開始作起，緣由很簡單，隨着應用規模的發展，修補安全漏洞所需的代價也隨之快速增加。根據IBM的系統科學協會（Systems Sciences Institute）的研究，若是等到軟件部署以後再來修補缺陷，其代價至關於開發期間檢測和消除缺陷的15倍。

　　爲了用最小的代價保障應用程序的安全，在代碼自己的安全性、抗禦攻擊的能力等方面，開發者應當擔負更多的責任。然而，要從開發的最初階段保障程序的安全性，必須具備相應的技能和工具，而真正掌握這些技能和工具的開發者並非不少。雖然學寫安全的代碼是一個複雜的過程，最好在大學、內部培訓會、行業會議上完成，但只要掌握了下面五種常見的asp.net應用安全缺陷以及推薦的修正方案，就可以領先一步，將不可或缺的安全因素融入到應用的出生之時。

　　1、不能盲目相信用戶輸入

　　在Web應用開發中，開發者最大的失誤每每是無條件地信任用戶輸入，假定用戶（即便是惡意用戶）老是受到瀏覽器的限制，老是經過瀏覽器和服務器交互，從而打開了攻擊Web應用的大門。實際上，黑客們攻擊和操做Web網站的工具不少，根本沒必要侷限於瀏覽器，從最低級的字符模式的原始界面（例如telnet），到CGI腳本掃描器、Web代理、Web應用掃描器，惡意用戶可能採用的攻擊模式和手段不少。

　　所以，只有嚴密地驗證用戶輸入的合法性，纔能有效地抵抗黑客的攻擊。應用程序能夠用多種方法（甚至是驗證範圍重疊的方法）執行驗證，例如，在承認用戶輸入以前執行驗證，確保用戶輸入只包含合法的字符，並且全部輸入域的內容長度都沒有超過範圍（以防範可能出現的緩衝區溢出攻擊），在此基礎上再執行其餘驗證，確保用戶輸入的數據不只合法，並且合理。必要時不只能夠採起強制性的長度限制策略，並且還能夠對輸入內容按照明肯定義的特徵集執行驗證。下面幾點建議將幫助你正確驗證用戶輸入數據：

　　⑴ 始終對全部的用戶輸入執行驗證，且驗證必須在一個可靠的平臺上進行，應當在應用的多個層上進行。

　　⑵ 除了輸入、輸出功能必需的數據以外，不要容許其餘任何內容。

　　⑶ 設立「信任代碼基地」，容許數據進入信任環境以前執行完全的驗證。

　　⑷ 登陸數據以前先檢查數據類型。

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

　　⑹ 嚴格定義合法的用戶請求，拒絕全部其餘請求。

　　⑺ 測試數據是否知足合法的條件，而不是測試不合法的條件。這是由於數據不合法的狀況不少，難以詳盡列舉。

　　2、五種常見的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：

<!-- 要求輸入值必須是1-9之間的數字 --> <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 acc_password=@pass", 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編碼版本，即「<」和「>」。

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

　　因爲客戶需求不斷變化，一些單位平均每三個月就要部署新的應用，同時因爲人員流動，因此對開發者快速開發健壯的、高質量的代碼寄予很高的指望。雖然對全部開發者進行代碼安全技術的培訓是十分必要的，但不能否認，自動檢測代碼安全漏洞的工具也有助於快速開發安全的應用程序。

　　到目前爲止，開發者經常使用的工具只能涵蓋功能測試的特定方面，例如性能測試，BUG/故障點偵查。人工檢查代碼有着許多與生俱來的侷限，並且要求開發者具備豐富的代碼安全經驗，因此對於編寫高質量的應用來講，面向應用程序安全及其在惡意環境下行爲的工具也是十分關鍵的。

　　要迅速提升應用的質量和安全性，最有效的辦法是給開發者提供一個自動測試應用的工具。若是在單元測試期間，工具可以檢測出應用的安全缺陷，並將修補建議嵌入到代碼之中，開發者就能當即找出代碼中存在的錯誤，不只方便了現有錯誤的修改，並且也有助於避免未來再犯一樣的錯誤，不斷地提升代碼抗禦攻擊的能力。

　　結束語：Web服務應用正在爆炸式增加，愈來愈多的應用被推出到防火牆以外，安全性脆弱的Web應用面臨的風險也只會有增無減。同時，爲了在緊迫的時限以前快速完成應用開發，開發者面臨的壓力也愈來愈大。注重編寫代碼時的安全問題，同時投入必要的資源，這樣才能爲將來的Web服務應用作好準備，同時確保當前應用的高質量。只有從應用的出生之日開始就採起正確的措施來確保其安全性，才能構造出高質量、安全的應用。