保證應用程序的安全應當從編寫第一行代碼的時候開始做起,原因很簡單,隨著應用規模的發展,修補安全漏洞所需的代價也隨之快速增長。根據IBM的系統科學協會(Systems Sciences Institute)的研究,如果等到軟件部署之后再來修補缺陷,其代價相當于開發期間檢測和消除缺陷的15倍。
為了用最小的代價保障應用程序的安全,在代碼本身的安全性、抗御攻擊的能力等方面,開發者應當擔負更多的責任。然而,要從開發的最初階段保障程序的安全性,必須具有相應的技能和工具,而真正掌握這些技能和工具的開發者并不是很多。雖然學寫安全的代碼是一個復雜的過程,最好在大學、內部培訓會、行業會議上完成,但只要掌握了下面五種常見的ASP.NET應用安全缺陷以及推薦的修正方案,就能夠領先一步,將不可或缺的安全因素融入到應用的出生之時。
一、不能盲目相信用戶輸入
在Web應用開發中,開發者最大的失誤往往是無條件地信任用戶輸入,假定用戶(即使是惡意用戶)總是受到瀏覽器的限制,總是通過瀏覽器和服務器交互,從而打開了攻擊Web應用的大門。實際上,黑客們攻擊和操作Web網站的工具很多,根本不必局限于瀏覽器,從最低級的字符模式的原始界面(例如telnet),到CGI腳本掃描器、Web代理、Web應用掃描器,惡意用戶可能采用的攻擊模式和手段很多。
因此,只有嚴密地驗證用戶輸入的合法性,才能有效地抵抗黑客的攻擊。應用程序可以用多種方法(甚至是驗證范圍重疊的方法)執行驗證,例如,在認可用戶輸入之前執行驗證,確保用戶輸入只包含合法的字符,而且所有輸入域的內容長度都沒有超過范圍(以防范可能出現的緩沖區溢出攻擊),在此基礎上再執行其他驗證,確保用戶輸入的數據不僅合法,而且合理。必要時不僅可以采取強制性的長度限制策略,而且還可以對輸入內容按照明確定義的特征集執行驗證。下面幾點建議將幫助你正確驗證用戶輸入數據:
?、?始終對所有的用戶輸入執行驗證,且驗證必須在一個可靠的平臺上進行,應當在應用的多個層上進行。
?、?除了輸入、輸出功能必需的數據之外,不要允許其他任何內容。
?、?設立“信任代碼基地”,允許數據進入信任環境之前執行徹底的驗證。
⑷ 登錄數據之前先檢查數據類型。
?、?詳盡地定義每一種數據格式,例如緩沖區長度、整數類型等。
?、?嚴格定義合法的用戶請求,拒絕所有其他請求。
?、?測試數據是否滿足合法的條件,而不是測試不合法的條件。這是因為數據不合法的情況很多,難以詳盡列舉。
二、五種常見的ASP.NET安全缺陷
下面給出了五個例子,闡述如何按照上述建議增強應用程序的安全性。這些例子示范了代碼中可能出現的缺陷,以及它們帶來的安全風險、如何改寫最少的代碼來有效地降低攻擊風險。
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、 篡改參數之二
◎ 避免驗證操作的漏洞
然而,僅僅為每個輸入域引入驗證器還不能防范所有通過修改參數實施的攻擊。在執行數值范圍檢查之時,還要指定正確的數據類型。
也就是說,在使用ASP.NET的范圍檢查控件時,應當根據輸入域要求的數據類型指定適當的Type屬性,因為Type的默認值是String。