SQL Server注入漏洞可能造成什么損失呢？
　　輕：查看數據庫名、SQL Server連接名、得到表的字段與記錄等。
　　重：備份數據庫、下載數據庫、在計算機內添加管理員等。

“查看數據庫名、SQL Server連接名、得到表的字段與記錄”之類的攻擊，對于存在注入漏洞的網頁一般都可實現。但若是使用Web管理網站，Web的密碼又沒加密，這樣事態就變嚴重了。另外對于SELECT語句，如果沒有控制好LockType（應設置為adLockReadOnly），也是很嚴重的。

對于ASP＋SQL Server如何徹底防范注入漏洞：
　　一、對進入sql語句的數字先進行類型轉換
　　二、對進入sql語句的字符，將單引號("'")替換為兩個單引號("''")或其它

僅此兩點即可，也許有人會問，那么文中第8頁所說：

對sql = "……where id=" & request.QueryString("id")
　　用**.asp?id=char(50)，char會起到函數的作用

或者where xtype=char(85)（見文中第8頁），char也會起到函數的作用。

但對于sql = "……where key='" & request.QueryString("key") & "'"
　　用**.asp?key=char(50)，這里的char(50)是不起作用的，為什么呢？
　　套入sql一看，語句是這樣的：
　　sql = "……where key='char(50)'"
　　char(50)位于"'"內，變成了字符（串），所以就起不到函數的作用了。

養成好的習慣，制定統一的規范
　　上面的方法確實解決了注入漏洞問題，但并不表示其它地方可以馬虎了，為什么要馬虎了，為什么要讓自己的網頁千瘡百孔，讓幾句代碼去獨擋一面呢？如果不養成好的習慣，團體之間如果不制定統一的規范，今天這個問題解決了，明天那個問題還會出現。

１、使用RecordSet記錄集之前必須判斷RecordSet的BOF或EOF屬性。
　　２、對于SELECT語句，除了不得已的情況，LockType必須設置為adLockReadOnly。
　　３、放入數據庫中的密碼應該使用良好的加密算法進行加密，同時也禁止密碼以明文的形式存在于頁面文件中。
　　４、在Web條件下，在非本機調試的情況下，不得使用sa連接數據庫。
　　５、對于需要用戶權限的平臺，必須將用戶名和密碼載入session，然后在需要的頁面進行判斷，不得使用if session("loginOK")<>"" then之類的語句來判斷用戶是否是合法用戶。
　　……
　　必要時，可以禁止IIS返回詳細的出錯信息，可以禁止public對sysobjects表的SELECT權限。
　　……

安全不是一方面的，僅靠幾個規范幾個好的習慣并不能保證能造就出安全的空間，1個False與99個True進行“與”運算，結果還是False，從中可以看出，哪怕只有一點錯誤，都可能導致結果全盤被否定。Web安全，除了注入漏洞，還有FTP設置錯誤、Web服務設置錯誤、后臺程序漏洞這些最最基本的都可能導致服務器整個被人控制，所以處處都要三思啊。

最近又看到很多關于 SQL 注入的帖子，都是使用替換 select、delete、update 等字符串的方法來防注入的。

再說明一下，這種是錯誤的防注入方法，原因如下：

1. 可能替換不全，不是所有的關鍵字都列入其中了的。
2. 本身這種替換就有漏洞，比如 aandnd 本身沒有問題，把其中的 and 替換掉后，反而冒出一個 and 出來。
3. 這種替換方式還破壞了文字的原義，我曾經在某個網站上注冊了 candy 這個用戶名，后來該系統卻告訴我沒有這個用戶，后來才知道 candy 中的 and 被去掉了。

正確的防注入方法是：

• 對數字類型進入 sql 前強制轉換為數字。
• 對文本類型進入 sql 前替換單引號為雙引號。
• 對日期類型進入 sql 前強制轉換成日期，并替換單引號為雙引號。

這是從注入的原理來防的。