第一：替換單引號，即把所有單獨出現的單引號改成兩個單引號，防止攻擊者修改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 =""”之類的查詢，因為這類查詢的後半部分已經被註釋掉，不再有效，攻擊者只要知道一個合法的使用者登入名稱，根本不需要知道使用者的密碼就可以順利獲得訪問許可權。
(1)對於動態構造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 =""”之類的查詢，因為這類查詢的後半部分已經被註釋掉，不再有效，攻擊者只要知道一個合法的使用者登入名稱，根本不需要知道使用者的密碼就可以順利獲得訪問許可權。
⑵ 用儲存過程來執行所有的查詢。SQL引數的傳遞方式將防止攻擊者利用單引號和連字元實施攻擊。此外，它還使得資料庫許可權可以限制到只允許特定的儲存過程執行，所有的使用者輸入必須遵從被呼叫的儲存過程的安全上下文，這樣就很難再發生注入式攻擊了。
⑶ 限制表單或查詢字串輸入的長度。如果使用者的登入名字最多隻有10個字元，那麼不要認可表單中輸入的10個以上的字元，這將大大增加攻擊者在SQL命令中插入有害程式碼的難度。
⑷ 檢查使用者輸入的合法性，確信輸入的內容只包含合法的資料。資料檢查應當在客戶端和伺服器端都執行——之所以要執行伺服器端驗證，是為了彌補客戶端驗證機制脆弱的安全性。
在客戶端，攻擊者完全有可能獲得網頁的原始碼，修改驗證合法性的指令碼（或者直接刪除指令碼），然後將非法內容透過修改後的表單提交給伺服器。因此，要保證驗證操作確實已經執行，唯一的辦法就是在伺服器端也執行驗證。你可以使用許多內建的驗證物件，例如RegularExpressionValidator，它們能夠自動生成驗證用的客戶端指令碼，當然你也可以插入伺服器端的方法呼叫。如果找不到現成的驗證物件，你可以透過CustomValidator自己建立一個。
⑸ 將使用者登入名稱、密碼等資料加密儲存。加密使用者輸入的資料，然後再將它與資料庫中儲存的資料比較，這相當於對使用者輸入的資料進行了“消毒”處理，使用者輸入的資料不再對資料庫有任何特殊的意義，從而也就防止了攻擊者注入SQL命令。System.Web.Security.FormsAuthentication類有一個HashPasswordForStoringInConfigFile，非常適合於對輸入資料進行消毒處理。
⑹ 檢查提取資料的查詢所返回的記錄數量。如果程式只要求返回一個記錄，但實際返回的記錄卻超過一行，那就當作出錯處理。
---------------------------------------------------------------------------------------------------------------------------
關鍵是明白原理，其實防範很簡單的，
1.過濾SQL需要的引數中的敏感字元（注意加入忽略大小寫）
3.遮蔽伺服器異常資訊