一、什么是sql注入式攻擊
所謂sql注入式攻擊，就是攻擊者把sql命令插入到web表單的輸入域或頁面請求的查詢字符串，欺騙服務器執(zhí)行惡意的sql命令。在某些表單中，用戶輸入的內容直接用來構造（或者影響）動態(tài)sql命令，或作為存儲過程的輸入?yún)?shù)，這類表單特別容易受到sql注入式攻擊。常見的sql注入式攻擊過程類如：
⑴ 某個asp.net web應用有一個登錄頁面，這個登錄頁面控制著用戶是否有權訪問應用，它要求用戶輸入一個名稱和密碼。
⑵ 登錄頁面中輸入的內容將直接用來構造動態(tài)的sql命令，或者直接用作存儲過程的參數(shù)。下面是asp.net應用構造查詢的一個例子：
system.text.stringbuilder
query = new system.text.stringbuilder(
"select * from users where login = ’")
.append(txtlogin.text)
.append("’ and password=’")
.append(txtpassword.text).append("’");
⑶ 攻擊者在用戶名字和密碼輸入框中輸入"’或’1’=’1"之類的內容。
⑷ 用戶輸入的內容提交給服務器之后，服務器運行上面的asp.net代碼構造出查詢用戶的sql命令，但由于攻擊者輸入的內容非常特殊，所以最后得到的sql命令變成：
select * from users where
login = ’’ or ’1’=’1’ and
password = ’’ or ’1’=’1’
⑸ 服務器執(zhí)行查詢或存儲過程，將用戶輸入的身份信息和服務器中保存的身份信息進行對比。
⑹ 由于sql命令實際上已被注入式攻擊修改，已經不能真正驗證用戶身份，所以系統(tǒng)會錯誤地授權給攻擊者。
如果攻擊者知道應用會將表單中輸入的內容直接用于驗證身份的查詢，他就會嘗試輸入某些特殊的sql字符串篡改查詢改變其原來的功能，欺騙系統(tǒng)授予訪問權限。
系統(tǒng)環(huán)境不同，攻擊者可能造成的損害也不同，這主要由應用訪問數(shù)據(jù)庫的安全權限決定。如果用戶的帳戶具有管理員或其他比較高級的權限，攻擊者就可能對數(shù)據(jù)庫的表執(zhí)行各種他想要做的操作，包括添加、刪除或更新數(shù)據(jù)，甚至可能直接刪除表。
二、如何防范
好在要防止asp.net應用被sql注入式攻擊闖入并不是一件特別困難的事情，只要在利用表單輸入的內容構造sql命令之前，把所有輸入內容過濾一番就可以了。過濾輸入內容可以按多種方式進行⑴ 對于動態(tài)構造sql查詢的場合，可以使用下面的技術：
第一：替換單引號，即把所有單獨出現(xiàn)的單引號改成兩個單引號，防止攻擊者修改sql命令的含義。再來看前面的例子，“select * from users where login = ’’’ or ’’1’’=’’1’ and password = ’’’ or ’’1’’=’’1’”顯然會得到與“select * from users where login = ’’ or ’1’=’1’ and password = ’’ or ’1’=’1’”不同的結果。
第二：刪除用戶輸入內容中的所有連字符，防止攻擊者構造出類如“select * from users where login = ’mas’ -- and password =’’”之類的查詢，因為這類查詢的后半部分已經被注釋掉，不再有效，攻擊者只要知道一個合法的用戶登錄名稱，根本不需要知道用戶的密碼就可以順利獲得訪問權限。
第三：對于用來執(zhí)行查詢的數(shù)據(jù)庫帳戶，限制其權限。用不同的用戶帳戶執(zhí)行查詢、插入、更新、刪除操作。由于隔離了不同帳戶可執(zhí)行的操作，因而也就防止了原本用于執(zhí)行select命令的地方卻被用于執(zhí)行insert、update或delete命令。
⑵ 用存儲過程來執(zhí)行所有的查詢。sql參數(shù)的傳遞方式將防止攻擊者利用單引號和連字符實施攻擊。此外，它還使得數(shù)據(jù)庫權限可以限制到只允許特定的存儲過程執(zhí)行，所有的用戶輸入必須遵從被調用的存儲過程的安全上下文，這樣就很難再發(fā)生注入式攻擊了。
⑶ 限制表單或查詢字符串輸入的長度。如果用戶的登錄名字最多只有10個字符，那么不要認可表單中輸入的10個以上的字符，這將大大增加攻擊者在sql命令中插入有害代碼的難度。
⑷ 檢查用戶輸入的合法性，確信輸入的內容只包含合法的數(shù)據(jù)。數(shù)據(jù)檢查應當在客戶端和服務器端都執(zhí)行——之所以要執(zhí)行服務器端驗證，是為了彌補客戶端驗證機制脆弱的安全性。
在客戶端，攻擊者完全有可能獲得網頁的源代碼，修改驗證合法性的腳本（或者直接刪除腳本），然后將非法內容通過修改后的表單提交給服務器。因此，要保證驗證操作確實已經執(zhí)行，的辦法就是在服務器端也執(zhí)行驗證。
你可以使用許多內建的驗證對象，例如regularexpressionvalidator，它們能夠自動生成驗證用的客戶端腳本，當然你也可以插入服務器端的方法調用。如果找不到現(xiàn)成的驗證對象，你可以通過customvalidator自己創(chuàng)建一個。
⑸ 將用戶登錄名稱、密碼等數(shù)據(jù)加密保存。加密用戶輸入的數(shù)據(jù)，然后再將它與數(shù)據(jù)庫中保存的數(shù)據(jù)比較，這相當于對用戶輸入的數(shù)據(jù)進行了“消毒”處理，用戶輸入的數(shù)據(jù)不再對數(shù)據(jù)庫有任何特殊的意義，從而也就防止了攻擊者注入sql命令。system.web.security.formsauthentication類有一個hashpasswordforstoringinconfigfile，非常適合于對輸入數(shù)據(jù)進行消毒處理。
⑹ 檢查提取數(shù)據(jù)的查詢所返回的記錄數(shù)量。如果程序只要求返回一個記錄，但實際返回的記錄卻超過一行，那就當作出錯處理。
所謂sql注入式攻擊，就是攻擊者把sql命令插入到web表單的輸入域或頁面請求的查詢字符串，欺騙服務器執(zhí)行惡意的sql命令。在某些表單中，用戶輸入的內容直接用來構造（或者影響）動態(tài)sql命令，或作為存儲過程的輸入?yún)?shù)，這類表單特別容易受到sql注入式攻擊。常見的sql注入式攻擊過程類如：
⑴ 某個asp.net web應用有一個登錄頁面，這個登錄頁面控制著用戶是否有權訪問應用，它要求用戶輸入一個名稱和密碼。
⑵ 登錄頁面中輸入的內容將直接用來構造動態(tài)的sql命令，或者直接用作存儲過程的參數(shù)。下面是asp.net應用構造查詢的一個例子：
system.text.stringbuilder
query = new system.text.stringbuilder(
"select * from users where login = ’")
.append(txtlogin.text)
.append("’ and password=’")
.append(txtpassword.text).append("’");
⑶ 攻擊者在用戶名字和密碼輸入框中輸入"’或’1’=’1"之類的內容。
⑷ 用戶輸入的內容提交給服務器之后，服務器運行上面的asp.net代碼構造出查詢用戶的sql命令，但由于攻擊者輸入的內容非常特殊，所以最后得到的sql命令變成：
select * from users where
login = ’’ or ’1’=’1’ and
password = ’’ or ’1’=’1’
⑸ 服務器執(zhí)行查詢或存儲過程，將用戶輸入的身份信息和服務器中保存的身份信息進行對比。
⑹ 由于sql命令實際上已被注入式攻擊修改，已經不能真正驗證用戶身份，所以系統(tǒng)會錯誤地授權給攻擊者。
如果攻擊者知道應用會將表單中輸入的內容直接用于驗證身份的查詢，他就會嘗試輸入某些特殊的sql字符串篡改查詢改變其原來的功能，欺騙系統(tǒng)授予訪問權限。
系統(tǒng)環(huán)境不同，攻擊者可能造成的損害也不同，這主要由應用訪問數(shù)據(jù)庫的安全權限決定。如果用戶的帳戶具有管理員或其他比較高級的權限，攻擊者就可能對數(shù)據(jù)庫的表執(zhí)行各種他想要做的操作，包括添加、刪除或更新數(shù)據(jù)，甚至可能直接刪除表。
二、如何防范
好在要防止asp.net應用被sql注入式攻擊闖入并不是一件特別困難的事情，只要在利用表單輸入的內容構造sql命令之前，把所有輸入內容過濾一番就可以了。過濾輸入內容可以按多種方式進行⑴ 對于動態(tài)構造sql查詢的場合，可以使用下面的技術：
第一：替換單引號，即把所有單獨出現(xiàn)的單引號改成兩個單引號，防止攻擊者修改sql命令的含義。再來看前面的例子，“select * from users where login = ’’’ or ’’1’’=’’1’ and password = ’’’ or ’’1’’=’’1’”顯然會得到與“select * from users where login = ’’ or ’1’=’1’ and password = ’’ or ’1’=’1’”不同的結果。
第二：刪除用戶輸入內容中的所有連字符，防止攻擊者構造出類如“select * from users where login = ’mas’ -- and password =’’”之類的查詢，因為這類查詢的后半部分已經被注釋掉，不再有效，攻擊者只要知道一個合法的用戶登錄名稱，根本不需要知道用戶的密碼就可以順利獲得訪問權限。
第三：對于用來執(zhí)行查詢的數(shù)據(jù)庫帳戶，限制其權限。用不同的用戶帳戶執(zhí)行查詢、插入、更新、刪除操作。由于隔離了不同帳戶可執(zhí)行的操作，因而也就防止了原本用于執(zhí)行select命令的地方卻被用于執(zhí)行insert、update或delete命令。
⑵ 用存儲過程來執(zhí)行所有的查詢。sql參數(shù)的傳遞方式將防止攻擊者利用單引號和連字符實施攻擊。此外，它還使得數(shù)據(jù)庫權限可以限制到只允許特定的存儲過程執(zhí)行，所有的用戶輸入必須遵從被調用的存儲過程的安全上下文，這樣就很難再發(fā)生注入式攻擊了。
⑶ 限制表單或查詢字符串輸入的長度。如果用戶的登錄名字最多只有10個字符，那么不要認可表單中輸入的10個以上的字符，這將大大增加攻擊者在sql命令中插入有害代碼的難度。
⑷ 檢查用戶輸入的合法性，確信輸入的內容只包含合法的數(shù)據(jù)。數(shù)據(jù)檢查應當在客戶端和服務器端都執(zhí)行——之所以要執(zhí)行服務器端驗證，是為了彌補客戶端驗證機制脆弱的安全性。
在客戶端，攻擊者完全有可能獲得網頁的源代碼，修改驗證合法性的腳本（或者直接刪除腳本），然后將非法內容通過修改后的表單提交給服務器。因此，要保證驗證操作確實已經執(zhí)行，的辦法就是在服務器端也執(zhí)行驗證。
你可以使用許多內建的驗證對象，例如regularexpressionvalidator，它們能夠自動生成驗證用的客戶端腳本，當然你也可以插入服務器端的方法調用。如果找不到現(xiàn)成的驗證對象，你可以通過customvalidator自己創(chuàng)建一個。
⑸ 將用戶登錄名稱、密碼等數(shù)據(jù)加密保存。加密用戶輸入的數(shù)據(jù)，然后再將它與數(shù)據(jù)庫中保存的數(shù)據(jù)比較，這相當于對用戶輸入的數(shù)據(jù)進行了“消毒”處理，用戶輸入的數(shù)據(jù)不再對數(shù)據(jù)庫有任何特殊的意義，從而也就防止了攻擊者注入sql命令。system.web.security.formsauthentication類有一個hashpasswordforstoringinconfigfile，非常適合于對輸入數(shù)據(jù)進行消毒處理。
⑹ 檢查提取數(shù)據(jù)的查詢所返回的記錄數(shù)量。如果程序只要求返回一個記錄，但實際返回的記錄卻超過一行，那就當作出錯處理。