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，非常適合於對輸入資料進行消毒處理。