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

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

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

僅此兩點(diǎn)即可，也許有人會(huì)問，那么文中第8頁所說：

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

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

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

養(yǎng)成好的習(xí)慣，制定統(tǒng)一的規(guī)范
　　上面的方法確實(shí)解決了注入漏洞問題，但并不表示其它地方可以馬虎了，為什么要馬虎了，為什么要讓自己的網(wǎng)頁千瘡百孔，讓幾句代碼去獨(dú)擋一面呢？如果不養(yǎng)成好的習(xí)慣，團(tuán)體之間如果不制定統(tǒng)一的規(guī)范，今天這個(gè)問題解決了，明天那個(gè)問題還會(huì)出現(xiàn)。

１、使用RecordSet記錄集之前必須判斷RecordSet的BOF或EOF屬性。
　?。?、對于SELECT語句，除了不得已的情況，LockType必須設(shè)置為adLockReadOnly。
　?。场⒎湃霐?shù)據(jù)庫中的密碼應(yīng)該使用良好的加密算法進(jìn)行加密，同時(shí)也禁止密碼以明文的形式存在于頁面文件中。
　?。?、在Web條件下，在非本機(jī)調(diào)試的情況下，不得使用sa連接數(shù)據(jù)庫。
　?。怠τ谛枰脩魴?quán)限的平臺(tái)，必須將用戶名和密碼載入session，然后在需要的頁面進(jìn)行判斷，不得使用if session("loginOK")<>"" then之類的語句來判斷用戶是否是合法用戶。
　　……
　　必要時(shí)，可以禁止IIS返回詳細(xì)的出錯(cuò)信息，可以禁止public對sysobjects表的SELECT權(quán)限。
　　……

安全不是一方面的，僅靠幾個(gè)規(guī)范幾個(gè)好的習(xí)慣并不能保證能造就出安全的空間，1個(gè)False與99個(gè)True進(jìn)行“與”運(yùn)算，結(jié)果還是False，從中可以看出，哪怕只有一點(diǎn)錯(cuò)誤，都可能導(dǎo)致結(jié)果全盤被否定。Web安全，除了注入漏洞，還有FTP設(shè)置錯(cuò)誤、Web服務(wù)設(shè)置錯(cuò)誤、后臺(tái)程序漏洞這些最最基本的都可能導(dǎo)致服務(wù)器整個(gè)被人控制，所以處處都要三思啊。

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

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

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

正確的防注入方法是：

• 對數(shù)字類型進(jìn)入 sql 前強(qiáng)制轉(zhuǎn)換為數(shù)字。
• 對文本類型進(jìn)入 sql 前替換單引號(hào)為雙引號(hào)。
• 對日期類型進(jìn)入 sql 前強(qiáng)制轉(zhuǎn)換成日期，并替換單引號(hào)為雙引號(hào)。

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