萬盛學電腦網 >> 應用技巧 >> Web開發中常見的安全缺陷及解決辦法
Web開發中常見的安全缺陷及解決辦法
一、不能盲目相信用戶輸入
二、五種常見的ASP.NET安全缺陷
2.1 篡改參數
2.2 篡改參數之二
2.3 信息洩漏
2.4 SQL注入式攻擊
2.5 跨站腳本執行
三、使用自動安全測試工具
正文：
保證應用程序的安全應當從編寫第一行代碼的時候開始做起，原因很簡單，隨著應用規模的發展，修補安全漏洞所需的代價也隨之快速增長。根據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。
■ 風險分析
由於沒有指定Type屬性值，上面的代碼將假定輸入值的類型是String，因此RangeValidator驗證器只能確保字符串由0-9之間的字符開始，“0abcd”也會被認可。
■ 解決方案
要確保輸入值確實是整數，正確的辦法是將Type屬性指定為Integer：
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" %>
標簽文字
■ 風險分析
攻擊者可以用JavaScript代碼構造一個惡意的查詢，點擊鏈接時JavaScript就會運行。舉例來說，腳本可以通過下面的用戶輸入來嵌入：
■ 解決方案
在一個雙層的安全體系中，對HTML頁面中出現的外發用戶數據執行輸入驗證和HTML編碼，確保浏覽器只把用戶輸入數據當成純粹的文本，而不是其他具有特殊含義的內容，例如HTML代碼、JavaScript腳本。
對於本例，只要加入一個HtmlEncode調用即可：
Label1.Text=Server.HtmlEncod
- 上一頁:典型DoS攻擊原理及抵御措施
- 下一頁:網絡攻擊概述
應用技巧排行
電腦基礎推薦
相關文章
copyright © 萬盛學電腦網 all rights reserved