SQL注入是從正常的WWW端口訪問，而且表面看起來跟一般的Web頁面訪問沒什麼區別，所以目前市面的防火牆都不會對SQL注入發出警報，如果管理員沒查看IIS日誌的習慣，可能被入侵很長時間都不會發覺。但是，SQL注入的手法相當靈活，在注入的時候會碰到很多意外的情況。能不能根據具體情況進行分析，構造巧妙的SQL語句，從而成功獲取想要的數據。
據統計，網站用ASP+Access或SQLServer的佔70%以上，PHP+MySQ佔L20%，其他的不足10%。在本文，以SQL-SERVER＋ASP例說明SQL注入的原理、方法與過程。（PHP注入的文章由NB聯盟的另一位朋友zwell撰寫的有關文章）
SQL注入攻擊的總體思路是：
1、發現SQL注入位置；
2、判斷後臺數據庫類型；
3、確定XP_CMDSHELL可執行情況
4、發現WEB虛擬目錄
5、上傳ASP木馬；
6、得到管理員權限；
防止ASP注入攻擊的分步實施提要
第一步. 使用ASP.NET 請求校驗.
第二步. 使用權用約束輸入.
第三步. 對不安全的輸入進行編碼.
第四步. 對Sql語句使用命令參數方式.
第五步. 驗證ASP.NET的錯誤沒有被返回客戶端.
額外的資源
一、SQL注入漏洞的判斷
一般來說，SQL注入一般存在於形如：HTTP://xxx.xxx.xxx/abc.asp...等帶有參數的ASP動態網頁中，有時一個動態網頁中可能只有一個參數，有時可能有N個參數，有時是整型參數，有時是字符串型參數，不能一概而論。總之只要是帶有參數的動態網頁且此網頁訪問了數據庫，那麼就有可能存在SQL注入。如果ASP程序員沒有安全意識，不進行必要的字符過濾，存在SQL注入的可能性就非常大。
爲了全面瞭解動態網頁回答的信息，首選請調整IE的配置。把IE菜單-工具-Internet選項－高級－顯示友好HTTP錯誤信息前面的勾去掉。
爲了把問題說明清楚，以下以HTTP://xxx.xxx.xxx/abc.asp...爲例進行分析，YY可能是整型，也有可能是字符串。
1、整型參數的判斷
當輸入的參數YY爲整型時，通常abc.asp中SQL語句原貌大致如下：
select * from 表名 where 字段=YY，所以可以用以下步驟測試SQL注入是否存在。
①HTTP://xxx.xxx.xxx/abc.asp...'(附加一個單引號)，此時abc.ASP中的SQL語句變成了
select * from 表名 where 字段=YY'，abc.asp運行異常；
②HTTP://xxx.xxx.xxx/abc.asp... and 1=1, abc.asp運行正常，而且與HTTP://xxx.xxx.xxx/abc.asp...運行結果相同；
③HTTP://xxx.xxx.xxx/abc.asp... and 1=2, abc.asp運行異常；如果以上三步全面滿足，abc.asp中一定存在SQL注入漏洞。
2、字符串型參數的判斷
當輸入的參數YY爲字符串時，通常abc.asp中SQL語句原貌大致如下：
select * from 表名 where 字段='YY'，所以可以用以下步驟測試SQL注入是否存在。
①HTTP://xxx.xxx.xxx/abc.asp...'(附加一個單引號)，此時abc.ASP中的SQL語句變成了
select * from 表名 where 字段=YY'，abc.asp運行異常；
②HTTP://xxx.xxx.xxx/abc.asp... ... 39;1'='1', abc.asp運行正常，而且與HTTP://xxx.xxx.xxx/abc.asp...運行結果相同；
③HTTP://xxx.xxx.xxx/abc.asp... ... 39;1'='2', abc.asp運行異常；如果以上三步全面滿足，abc.asp中一定存在SQL注入漏洞。
3、特殊情況的處理
有時ASP程序員會在程序員過濾掉單引號等字符，以防止SQL注入。此時可以用以下幾種方法試一試。
①大小定混合法：由於VBS並不區分大小寫，而程序員在過濾時通常要麼全部過濾大寫字符串，要麼全部過濾小寫字符串，而大小寫混合往往會被忽視。如用SelecT代替select,SELECT等；
②UNICODE法：在IIS中，以UNICODE字符集實現國際化，我們完全可以IE中輸入的字符串化成UNICODE字符串進行輸入。如+ =%2B，空格=%20 等；URLEncode信息參
③ASCII碼法：可以把輸入的部分或全部字符全部用ASCII碼代替，如U=chr
(85),a=chr(97)等，ASCII信息；
二、區分數據庫服務器類型
一般來說，ACCESS與SQL－SERVER是最常用的數據庫服務器，儘管它們都支持T－SQL標準，但還有不同之處，而且不同的數據庫有不同的攻擊方法，必須要區別對待。
1、 利用數據庫服務器的系統變量進行區分SQL－SERVER有user,db_name()等系統變量，利用這些系統值不僅可以判斷SQL-SERVER，而且還可以得到大量有用信息。如：
① HTTP://xxx.xxx.xxx/abc.asp... and user>0 不僅可以判斷是否是SQL-SERVER，而還可以得到當前連接到數據庫的用戶名
②HTTP://xxx.xxx.xxx/abc.asp... ... db_name()>0 不僅可以判斷是否是SQL-SERVER，而還可以得到當前正在使用的數據庫名；
2、利用系統表
ACCESS的系統表是msysobjects,且在WEB環境下沒有訪問權限，而SQL-SERVER的系統表是sysobjects,在WEB環境下有訪問權限。對於以下兩條語句：
①HTTP://xxx.xxx.xxx/abc.asp... and (select count(*) from sysobjects)>0
②HTTP://xxx.xxx.xxx/abc.asp... and (select count(*) from msysobjects)>0
若數據庫是SQL-SERVE，則第一條，abc.asp一定運行正常，第二條則異常；若是ACCESS則兩條都會異常。
3、 MSSQL三個關鍵系統表
sysdatabases系統表：Microsoft SQL Server 上的每個數據庫在表中佔一行。最初安裝 SQL Server 時，sysdatabases 包含 master、model、msdb、mssqlweb 和tempdb 數據庫的項。該表只存儲在 master 數據庫中。 這個表保存在master數據庫中，這個表中保存的是什麼信息呢？這個非常重要。他是 保存了所有的庫名,以及庫的ID和一些相關信息。
這裏我把對於我們有用的字段名稱和相關說明給大家列出來。name //表示庫的名字。dbid //表示庫的ID，dbid從1到5是系統的。分別是：master、model、msdb、mssqlweb、tempdb 這五個庫。用select * from master.dbo.sysdatabases 就可以查詢出所有的庫名。
好在要防止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，非常適合於對輸入數據進行消毒處理。