system.text.stringbuilder query = new system.text.stringbuilder("select * from users where login = '").append(txtlogin.text).append("' and password='").append(txtpassword.text).append("'");

select * from users where login = '' or '1'='1' andpassword = '' or '1'='1'

　　⑸ 服務器執行查詢或存儲過程，將用戶輸入的身份信息和服務器中保存的身份信息進行對比。

　　⑹ 由于sql命令實際上已被注入式攻擊修改，已經不能真正驗證用戶身份，所以系統會錯誤地授權給攻擊者。

　　如果攻擊者知道應用會將表單中輸入的內容直接用于驗證身份的查詢，他就會嘗試輸入某些特殊的sql字符串篡改查詢改變其原來的功能，欺騙系統授予訪問權限。

　　系統環境不同，攻擊者可能造成的損害也不同，這主要由應用訪問數據庫的安全權限決定。如果用戶的帳戶具有管理員或其他比較高級的權限，攻擊者就可能對數據庫的表執行各種他想要做的操作，包括添加、刪除或更新數據，甚至可能直接刪除表。

　　二、如何防范

　　好在要防止asp.net應用被sql注入式攻擊闖入并不是一件特別困難的事情，只要在利用表單輸入的內容構造sql命令之前，把所有輸入內容過濾一番就可以了。過濾輸入內容可以按多種方式進行。

　　⑴ 對于動態構造sql查詢的場合，可以使用下面的技術：

　　第一：替換單引號，即把所有單獨出現的單引號改成兩個單引號，防止攻擊者修改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 =''”之類的查詢，因為這類查詢的后半部分已經被注釋掉，不再有效，攻擊者只要知道一個合法的用戶登錄名稱，根本不需要知道用戶的密碼就可以順利獲得訪問權限。

　　第三：對于用來執行查詢的數據庫帳戶，限制其權限。用不同的用戶帳戶執行查詢、插入、更新、刪除操作。由于隔離了不同帳戶可執行的操作，因而也就防止了原本用于執行select命令的地方卻被用于執行insert、update或delete命令。

　　⑵ 用存儲過程來執行所有的查詢。sql參數的傳遞方式將防止攻擊者利用單引號和連字符實施攻擊。此外，它還使得數據庫權限可以限制到只允許特定的存儲過程執行，所有的用戶輸入必須遵從被調用的存儲過程的安全上下文，這樣就很難再發生注入式攻擊了。

　　⑶ 限制表單或查詢字符串輸入的長度。如果用戶的登錄名字最多只有10個字符，那么不要認可表單中輸入的10個以上的字符，這將大大增加攻擊者在sql命令中插入有害代碼的難度。

　　⑷ 檢查用戶輸入的合法性，確信輸入的內容只包含合法的數據。數據檢查應當在客戶端和服務器端都執行——之所以要執行服務器端驗證，是為了彌補客戶端驗證機制脆弱的安全性。

　　在客戶端，攻擊者完全有可能獲得網頁的源代碼，修改驗證合法性的腳本（或者直接刪除腳本），然后將非法內容通過修改后的表單提交給服務器。因此，要保證驗證操作確實已經執行，唯一的辦法就是在服務器端也執行驗證。

　　你可以使用許多內建的驗證對象，例如regularexpressionvalidator，它們能夠自動生成驗證用的客戶端腳本，當然你也可以插入服務器端的方法調用。如果找不到現成的驗證對象，你可以通過customvalidator自己創建一個。

　　⑸ 將用戶登錄名稱、密碼等數據加密保存。加密用戶輸入的數據，然后再將它與數據庫中保存的數據比較，這相當于對用戶輸入的數據進行了“消毒”處理，用戶輸入的數據不再對數據庫有任何特殊的意義，從而也就防止了攻擊者注入sql命令。system.web.security.formsauthentication類有一個hashpasswordforstoringinconfigfile，非常適合于對輸入數據進行消毒處理。

　　⑹ 檢查提取數據的查詢所返回的記錄數量。如果程序只要求返回一個記錄，但實際返回的記錄卻超過一行，那就當作出錯處理。