一不能盲目相信用戶輸入
在Web應用開發中開發者最大的失誤往往是無條件地信任用戶輸入假定用戶（即使是惡意用戶）總是受到浏覽器的限制總是通過浏覽器和服務器交互從而打開了攻擊Web應用的大門實際上黑客們攻擊和操作Web網站的工具很多根本不必局限於浏覽器從最低級的字符模式的原始界面（例如telnet）到CGI腳本掃描器Web代理Web應用掃描器惡意用戶可能采用的攻擊模式和手段很多
因此只有嚴密地驗證用戶輸入的合法性才能有效地抵抗黑客的攻擊應用程序可以用多種方法（甚至是驗證范圍重疊的方法）執行驗證例如在認可用戶輸入之前執行驗證確保用戶輸入只包含合法的字符而且所有輸入域的內容長度都沒有超過范圍（以防范可能出現的緩沖區溢出攻擊）在此基礎上再執行其他驗證確保用戶輸入的數據不僅合法而且合理必要時不僅可以采取強制性的長度限制策略而且還可以對輸入內容按照明確定義的特征集執行驗證下面幾點建議將幫助你正確驗證用戶輸入數據⑴ 始終對所有的用戶輸入執行驗證且驗證必須在一個可靠的平台上進行應當在應用的多個層上進行
⑵ 除了輸入輸出功能必需的數據之外不要允許其他任何內容
⑶ 設立信任代碼基地允許數據進入信任環境之前執行徹底的驗證
⑷ 登錄數據之前先檢查數據類型
⑸ 詳盡地定義每一種數據格式例如緩沖區長度整數類型等
⑹ 嚴格定義合法的用戶請求拒絕所有其他請求
⑺ 測試
數據是否滿足合法的條件而不是測試不合法的條件這是因為數據不合法的情況很多難以詳盡列舉
二五種常見的ASPNET安全缺陷
下面給出了五個例子闡述如何按照上述建議增強應用程序的安全性這些例子示范了代碼中可能出現的缺陷以及它們帶來的安全風險如何改寫最少的代碼來有效地降低攻擊風險
篡改參數
◎ 使用ASPNET域驗證器
盲目信任用戶輸入是保障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 =就可以順利登錄系統或者只要在查詢之後加上適當的調用就可以執行任意Shell命令
; EXEC masterxp_cmdshell(Oshell command here)
■ 風險分析
在編寫這幾行代碼時開發者無意之中作出了這樣的假定用戶的輸入內容只包含正常的數據——合乎人們通常習慣的用戶名字密碼但不會包含引號之類的特殊字符這正是SQL注入式攻擊能夠得逞的根本原因黑客們可以借助一些具有特殊含義的字符改變查詢的本意進而調用任意函數或過程
■ 解決方案
域驗證器是一種讓ASPNET開發者對域的值實施限制的機制例如
限制用戶輸入的域值必須匹配特定的表達式
要防止上述攻擊行為得逞第一種辦法是禁止引號之類的特殊字符輸入第二種辦法更嚴格即限定輸入域的內容必須屬於某個合法字符的集合例如[azAZ]*
篡改參數之二
◎ 避免驗證操作的漏洞
然而僅僅為每個輸入域引入驗證器還不能防范所有通過修改參數實施的攻擊在執行數值范圍檢查之時還要指定正確的數據類型
也就是說在使用ASPNET的范圍檢查控件時應當根據輸入域要求的數據類型指定適當的Type屬性因為Type的默認值是String
＜! 要求輸入值必須是之間的數字 ＞
＜asp:RangeValidator MinimumValue= MaximumValue= /＞
■ 風險分析
由於沒有指定Type屬性值上面的代碼將假定輸入值的類型是String因此RangeValidator驗證器只能確保字符串由之間的字符開始abcd也會被認可
■ 解決方案
要確保輸入值確實是整數正確的辦法是將Type屬性指定為Integer
＜! 要求輸入值必須是之間的數字 ＞
＜asp:RangeValidator MinimumValue=
MaximumValue= Type=Integer
信息洩漏
◎ 讓隱藏域更加安全
在ASPNET應用中幾乎所有HTML頁面的__VIEWSTATE隱藏域中都可以找到有關應用的信息由於__VIEWSTATE是BASE 編碼的所以常常被忽略但黑客可以方便地解碼BASE 數據用不著花什麼力氣就可以得到__VIEWSTATE提供的詳細資料
■ 風險分析
默認情況下__VIEWSTATE數據將包含
⑴ 來自頁面控件的動態數據
⑵ 開發者在ViewState中顯式保存的數據
⑶ 上述數據的密碼簽字
■ 解決方案
設置EnableViewStatMAC=true啟用__VIEWSTATE數據加密功能然後將machineKey驗證類型設置成DES要求ASPNET用Triple DES對稱加密算法加密ViewState數據
SQL注入式攻擊
◎ 使用SQL參數API
正如前文篡改參數部分描述的攻擊者可以在輸入域中插入特殊字符改變SQL查詢的本意欺騙數據庫服務器執行惡意的查詢
■ 風險分析
惡意查詢有可能獲取後端數據庫保存的任何信息例如客戶信用卡號碼的清單
■ 解決方案
除了前面介紹的辦法——用程序代碼確保輸入內容只包含有效字符另一種更加健壯的辦法是使用SQL參數API（例如ADONET提供的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_querySelect_CommandParametersAdd(
@userSqlDbVarChar);
userParamValue=user;
SqlParameter passwordParam = my_querySelect_CommandParametersAdd(
@SqlDbVarChar);
passwordParamValue=password;
跨站腳本執行
◎ 對外發的數據進行編碼
跨站腳本執行（Crosssite scripting）是指將惡意的用戶輸入嵌入到應答（HTML）頁面例如下面的ASPNET頁面雖然簡單卻包含著一個重大的安全缺陷
＜%@ Page Language=vb %＞
＜asp:Label id=Label runat=server＞
標簽文字
＜/asp:Label＞
＜form method=post runat=server ID=Form＞
請在此處輸入反饋信息＜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 SystemEventArgs)
LabelText=feedbackText
End Sub
＜/script＞
■ 風險分析
攻擊者可以用JavaScript代碼構造一個惡意的查詢點擊鏈接時JavaScript就會運行舉例來說腳本可以通過下面的用戶輸入來嵌入
＜script＞alert(okie)
＜/script＞
■ 解決方案
在一個雙層的安全體系中對HTML頁面中出現的外發用戶數據執行輸入驗證和HTML編碼確保浏覽器只把用戶輸入數據當成純粹的文本而不是其他具有特殊含義的內容例如HTML代碼JavaScript腳本
對於本例只要加入一個HtmlEncode調用即可
LabelText=ServerHtmlEncode(feedbackText)
這樣應答HTML流將包含用戶輸入內容的HTML編碼版本也就是說浏覽器不會執行用戶輸入的JavaScript代碼因為根本不存在HTML的＜SCRIPT＞標記用戶輸入的＜和＞字符已經被替換成HTML編碼版本即＜和＞
三使用自動安全測試工具
由於客戶需求不斷變化一些單位平均每三個月就要部署新的應用同時由於人員流動所以對開發者快速開發健壯的高質量的代碼寄予很高的期望雖然對所有開發者進行代碼安全技術的培訓是十分必要的但不可否認自動檢測代碼安全漏洞的工具也有助於快速開發安全的應用程序
到目前為止開發者常用的工具只能涵蓋功能測試的特定方面例如性能測試BUG/故障點偵查人工檢查代碼有著許多與生俱來的局限而且要求開發者具有豐富的代碼安全經驗所以對於編寫高質量的應用來說面向應用程序安全及其在惡意環境下行為的工具也是十分關鍵的
要迅速提高應用的質量和安全性最有效的辦法是給開發者提供一個自動測試應用的工具如果在單元測試期間工具能夠檢測出應用的安全缺陷並將修補建議嵌入到代碼之中
開發者就能立即找出代碼中存在的錯誤不僅方便了現有錯誤的修改而且也有助於避免將來再犯同樣的錯誤不斷地提高代碼抗御攻擊的能力
結束語Web服務應用正在爆炸式增長越來越多的應用被推出到防火牆之外安全性脆弱的Web應用面臨的風險也只會有增無減同時為了在緊迫的時限之前快速完成應用開發開發者面臨的壓力也越來越大注重編寫代碼時的安全問題同時投入必要的資源這樣才能為未來的Web服務應用做好准備同時確保當前應用的高質量只有從應用的出生之日開始就采取正確的措施來確保其安全性才能構造出高質量安全的應用
From:http://tw.wingwit.com/Article/program/net/201311/13189.html
