二、五種常見的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開發者對域的值實施限制的機制,例如,限制用戶輸入的域值必須匹配特定的表達式。
要防止上述攻擊行為得逞,第一種辦法是禁止引號之類的特殊字符輸入,第二種辦法更嚴格,即限定輸入域的內容必須屬於某個合法字符的集合,例如「*」。
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" %>
<aspabel id="Label1" runat="server">
標籤文字
</aspabel>
<form method="post" runat="server" ID="Form1">
請在此處輸入反饋信息<br>
<asp:Textbox ID="feedback" runat="server"/><br>
<asp:Button id="cmdSubmit" runat="server"
Text="提交!" >
</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編碼版本,即「<」和「>」。