2.3 SQL注入攻擊前奏

在上節中，我們已經對SQL注入攻擊的目的及原理有所了解。在本節中，將向大家詳細介紹SQL注入攻擊的分類、注入點的掃描及注入類型判斷等，這也是攻擊者在實施SQL注入攻擊前必須進行的準備工作。

2.3.1 網站平臺決定攻擊方式

大部分網站都是采用Web動態網頁結合后臺數據庫架設而成的。網頁從用戶的請求中得到某些參數，然后構成SQL語句請求發給數據庫，再將從數據庫中得到的結果返回給網頁，從而完成網頁所執行的功能。

在許多Web網站系統中，由于網站程序中的變量處理不當，或者對用戶提交的數據過濾不足，很可能產生一種被為SQL注入（SQL Injection）的漏洞。惡意攻擊者可以利用用戶可提交或可修改的數據，構造特殊的SQL語句，將SQL語句插入到系統實際執行的SQL語句中，從而任意獲取數據庫中的某些重要信息，如管理員用戶名和密碼等；基至可以利用SQL注入漏洞控制整個網站服務器。

簡單說來，SQL注入漏洞就是由于用戶可構造執行特殊SQL語句的漏洞；所謂的SQL注入攻擊就是用戶利用SQL注入漏洞非法獲取數據庫信息或者入侵網站服務器的一種黑客攻擊手段。

根據網站所使用的Web腳本語言不同，SQL注入攻擊可以分為ASP注入、PHP、JSP、ASPX注入等多種方式。ASP注入與PHP及其他語言的注入原理是一樣的，但是由于Web語言環境不同，因此實際注入時所使用的語句也不盡相同。

同時，SQL注入攻擊并不僅局限在SQL Server數據庫中，后臺使用Access、MySQL、Oracle、Sybase等數據庫的網站等都可能存在注入漏洞，遭受SQL注入攻擊。

根據目前網絡上的具體情況而言，大部分網站主要是采用“ASP+SQL Server （Access）”或者“PHP+MySQL”結構來架設的，因此本書也重點對這兩種注入方式分別進行敘述。

2.3.2 攻擊前的準備工作

攻擊者在實施SQL注入攻擊前，首先會進行一些準備工作，同樣，我們要對自己的網站進行SQL注入漏洞的檢測，也需要進行相同的準備。

1．取消友好HTTP錯誤信息

在進行SQL注入攻擊時，要利用到從服務器返回的各種出錯信息，但是在瀏覽器中默認設置是不顯示詳細錯誤返回信息的，不論服務器返回什么錯誤，我們都只能看到“HTTP 500服務器錯誤”（圖22）。因此，每次進行SQL注入攻擊測試前，首先要對IE瀏覽器進行一下設置：

打開IE瀏覽器，單擊菜單【工具】→【Internet選項】命令，打開“Internet選項”，選擇“高級”選項卡，在“設置”列表框中找到“瀏覽組”，將其下的“顯示友好HTTP錯誤信息”前面的鉤去掉（圖23）。

2．準備猜解用的工具

與任何攻擊手段相似，在進行每一次入侵前，都要經過檢測漏洞，入侵攻擊，種植木馬后門長期控制等這幾個步驟。同樣，進行SQL注入攻擊也不例外。在這幾個入侵步驟中，黑客往往會使用一些特殊的工具，以大大提高入侵的效率和成功率。在進行SQL注入攻擊測試前，需要準備如下攻擊工具。

1）SQL注入漏洞掃描與猜解工具

ASP環境的注入掃描器主要有“WIS+WED”、NBSI2（圖24）、HDSI、pangolin_bin等。

PHP環境的注入攻擊工具主要有“二娃”和CASI（圖25）。

這些工具，大部分都是采SQL注入漏洞掃描與攻擊于一體的綜合利用工具，可以幫助攻擊迅速完成SQL注入點尋找與數據庫密碼破解、系統攻擊等過程。

2）Web木馬后門

ASP木馬后門：冰狐浪子、海陽頂端木馬、ASP站長助手（圖26）、藍屏木馬等，用于注入攻擊后控制ASP環境的網站服務器。

PHP木馬后門：PHPSpy、黑客之家PHP木馬等，用于注入攻擊后控制PHP環境的網站服務器。

3）注入輔助工具

ASC碼逆轉換工具、C2C注入格式轉換器、SQL注入字符轉換工具（圖27）等，主要用于在注入檢測過程中轉換注入語句編碼，突破過濾防護限制。

2.3.3 尋找攻擊入口

對一個網站要實施SQL注入攻擊檢測，當然首先要找到存在SQL注入漏洞的地方，也就是所謂的尋找注入點。可能的SQL注入點一般存在于登錄頁面、查找頁面、添加頁面及信息條目瀏覽頁面等，用戶可提交修改數據的地方，比如常見的登錄用戶名和密碼輸入框或者信息條目ID顯示頁面等。

1．手工檢測SQL注入點

最常用的SQL注入點判斷方法，是在網站中尋找如下形式的網頁鏈接：

            http://www.＊＊＊＊＊.com/＊＊＊.asp? id=xx  （ASP注入）

或者

            http://www.＊＊＊＊＊.com/＊＊＊.php? id=xx  （PHP注入）

其中的“xx”可能是數字，也有可能是字符串，分別被稱為整數類型數據和字符型數據。

如果判斷某個網頁鏈接是否存在SQL注入漏洞呢？通常有兩種檢測方法。

1）“加引號”法

第一種檢測SQL注入漏洞是否存在的方法是“加引號”法。

對于整數類型數據，可以直接在瀏覽器地址欄中的網址鏈接后加上一個單引號，構造如：

            http://www.＊＊＊＊＊.com/＊＊＊.asp? id=11'
            http://www.＊＊＊＊＊.com/＊＊＊.php? id=11'

之類的鏈接。如果瀏覽器返回如下類似信息（圖28）：

            Microsoft OLE DB Provider for ODBC Drivers 錯誤 '80040e14'
            [Microsoft][ODBC SQL Server Driver][SQL Server]字符串 '8' ' 之前
            有未閉合的引號。
            /web/ChannelContent.asp，行 45

在返回的信息中，有詳細的數據庫SQL語句操作執行錯誤信息，并出現類似的提示信息的話，則往往表明存在SQL注入漏洞。

同樣，如果是字符型數據，我們也可以在后加上一個單引號，如果返回與上面類似的出錯提示，那么也說明存在SQL注入漏洞。另外對于字符型數據來說，單引號的添加可以靈活些，可把單引號加入到字符串中去，構造形如“http://www.*****.com/***.php? id=puma' xy”之類的鏈接請求。

為了便于讀者對“加引號法”有一個更直觀的了解，這里特意找了一個存在SQL注入的ASP網址“http://love.**.tj.cn/bbs/openarticlenew.asp? ID=11695”，分別截取了正常顯示與添加單引號后的錯誤返回圖示，見圖29和圖30。

對于PHP網站返回的SQL注入漏洞錯誤提示略有不同，注入點檢測后的返回信息往往是一些SQL出錯的信息提示（圖31），通過這些信息，往往可以分析是否存在SQL注入漏洞。

2）經典的“1=1和1=2”法

加引號法雖然很直接，但是由于SQL注入攻擊的普及，所以很多程序員已經在網頁程序將引號過濾掉。很多時候檢測提交包含引號的鏈接時，會提示非法字符，或者不返回任何信息。但這并不等于不存在SQL注入漏洞，這時候黑客往往會使用經典的“1=1和1=2”法進行檢測。

首先提交網址鏈接http://www.*****.com/***.asp? id=xx and 1=1。

一般應該運行正常，而且與“http://www.*****.com/***.asp? id=xx”運行顯示頁面相同。

再提交“http://www.*****.com/***.asp? id=xx and 1=2”，頁面運行異常。

如果滿足上面的顯示，那么就說明當前頁面中存在SQL注入漏洞，反之則可能不能注入。此方法對PHP站點同樣適用。

例如，某PHP站點鏈接地址為“http://www.he**.com.cn/superbaby/galleryint roduced.php? ID=5404”，正常頁面中顯示數據庫中相應的“寶寶姓名”、“所在城市”等信息及圖片（圖32）。

采用上面的方法，先在鏈接地址后添加“and 1=1”，提交鏈接地址為：

            http://www.he＊＊.com.cn/superbaby/galleryintroduced.php? ID=54
            04 and 1=1

返回顯示與正常狀態相同（圖33）。

再在鏈接地址后添加“and 1=2”，提交鏈接地址為：

            http://www.he＊＊.com.cn/superbaby/galleryintroduced.php? ID=54
            04 and 1=2

返回的頁面中（圖34），沒有任何信息，說明該網頁鏈接存在著PHP注入漏洞。

2．快速掃描出網站的安全威脅

除了可以使用上述介紹的方法手工檢測某個網站中存在的SQL注入漏洞外，還有更為簡便的方法，那就是直接使用一些漏洞掃描工具對整個網站進行掃描。這些安全檢測工具，一旦落入攻擊者的手中，就將成為攻擊的罪惡利器。

1）WIS掃描法

“WIS+WED”是一個SQL注入組合工具包，其中的WIS是一個命令行的SQL注入漏洞掃描工具，使用格式為（圖35）：

            wis  ＜Web Page＞

以掃描“http://net110.**.net/”網站中存在的SQL注入漏洞的網站為例，在命令行下輸入命令：

            WIS http://net110.＊＊.net/

命令執行后，會將存在SQL注入漏洞的網址鏈接以紅色顯示（圖36）。

2）使用NBSI掃描

NBSI可以在圖形界面下對網站進行注入漏洞掃描。運行程序后，單擊工具欄上的“網站掃描”按鈕，然后在網站地址中輸入要掃描的網站鏈接地址，再選擇掃描的方式。如果是第一次掃描的話，可以選擇“快速掃描”，如果使用該方式沒有掃描到漏洞時，再使用“全面掃描”項。最后單擊【掃描】按鈕，即可在下面的列表中看到可能存在SQL注入的鏈接地址（圖37）。

請注意，在掃描結果列表中將會顯示注入漏洞存在的可能性，其中標記為“可能性：較高”的注入成功的機率較大些。

上面介紹的兩種掃描工具都是運行于ASP網站下的，對于使用PHP語言的網站，一般沒有直接進行掃描的工具，還是手工檢測比較可靠些。

2.3.4 區分SQL注入點的類型

根據注入時提交的變量參數類型，SQL注入點有不同的分類，不同的注入點，其注入時需要注意的事項也有所不同。按提交參數類型，SQL注入點主要分為下面3種。

1．數字型注入點

形如“http://******? ID=50 ”，這類注入的參數是“數字”，因此稱為“數字型”注入點。

此類注入點提交的SQL語句，其原形大致為：

            Select ＊ from 表名 where 字段=50

當我們提交注入參數為“http://******? ID=50 And [查詢條件]”時，向數據庫提交的完整SQL語句為：

            Select ＊ from 表名 where 字段=50 And [查詢條件]

2．字符型注入點

形如“http://******? Class=日期” 這類注入的參數是“字符”，因此稱為“字符型”注入點。

此類注入點提交的SQL語句，其原形大致為：

            Select ＊ from 表名 where 字段=’日期’

當我們提交注入參數為“http://******? Class=日期And [查詢條件]”時，向數據庫提交的完整SQL語句為：

            Select ＊ from 表名 where 字段=’日期’ and [查詢條件]

3．搜索型注入點

這是一類特殊的注入類型。這類注入主要是指在進行數據搜索時沒過濾搜索參數，一般在鏈接地址中有“keyword=關鍵字”，有的不顯示明顯的鏈接地址，而是直接通過搜索框表單提交。

此類注入點提交的SQL語句，其原形大致為：

            Select ＊ from 表名 where 字段like ‘%關鍵字%’

當我們提交注入參數為“keyword=' and [查詢條件] and ‘%' =' ，則向數據庫提交的完整SQL語句為：

            Select ＊ from 表名 where字段like ‘%' and [查詢條件] and ‘%' =' %’

2.3.5 判斷目標數據庫類型

目前，網上建站使用的一般是ASP+MS SQL Server/Access或PHP+MySQL這兩種架構。因此，對于PHP網站使用的數據庫為可能是MS SQL、MySQL；對ASP網頁來說，使用的數據庫可能是Access、MS SQL，也可能是MySQL，針對不同的數據庫采用的注入方式法略有差異。

判斷注入漏洞網站數據庫類型，主要是為了決定采取的注入攻擊方式。一般來說，由于SQL Server有一些內置的系統變量，因此在注入時可以利用一些查詢語句直接返回其表名或字段名；但是Access的SQL查詢功能就簡陋得多，無法返回正確信息，因此可構造特殊的語句來進行判斷。

如何判別這兩種數據庫類型呢？

1．過分體貼的錯誤信息

為了方便網站管理者解決各種操作錯誤的問題，網站通常會將各種錯誤信息進行詳細的反饋，顯示在網頁出錯頁面中。這些“體貼”的設計，反而給攻擊者帶來了便利，攻擊者通過注入點的返回信息，可以判斷出網站所使用的數據庫類型。

例如，在返回信息中，看到如“Microsoft OLE DB Provider for SQL Server錯誤 ’80040e14' ”，由此可以看出數據庫采用的是SQL Server；如果返回“Microsoft JET Database Engine錯誤 ’80040e14' ”之類的信息，基本上可以確定采用的是Access數據庫（圖38）。如果提示信息為“Microsoft OLE DB Provider for ODBC Drivers錯誤 ’80040e14' ”的語句，則有可能是Access數據庫，也可能是SQL數據庫。

例如，提示信息為：

            Microsoft OLE DB Provider for ODBC Drivers 錯誤 '80040e14'
            [Microsoft][ODBC SQL Server Driver][SQL Server]字符串 '8' ' 之前
            有未閉合的引號。
            /web/ChannelContent.asp，行45

從上面的錯誤信息“Microsoft OLE DB Provider”，可以看出數據庫采用OLE DB驅動；“[Microsoft][ODBC SQL Server Driver][SQL Server]”，則說明此網站使用的是SQL數據庫（圖39）。如果提示信息為：

            Microsoft OLE DB Provider for ODBC Drivers 錯誤 '80040e14'
            [Microsoft][ODBC Microsoft Access Driver] 字符串的語法錯誤 在查
            詢表達式 ' b_id=175' ' 中。
            /view.asp，行8

說明此網站數據庫采用OLE DB驅動，從“[Microsoft][ODBC Microsoft Access Driver]”看出采用的是Access數據庫。

2．報出數據庫類型

SQL Server有一些系統變量和系統表，如果服務器IIS提示沒關閉，并且SQLServer返回錯誤提示的話，那可以直接從出錯信息獲取判斷數據庫的類型。

1）內置變量報出數據庫類型

其方法是在注入點之后加上“and user＞0”字符，示例如下：

            http://www.＊＊＊.com/jobs.asp? ID=1651 and user＞0

這條語句很簡單，但卻是很典型的SQL Server注入原理的體現。我們來看看它的含義：首先，前面的語句是正常的，重點在“and user＞0”, “user”是SQLServer的一個內置變量，它的值是當前連接的用戶名，類型為“nvarchar”。將一個“nvarchar”的值跟“int”的數“0”比較，系統會先試圖將“nvarchar”的值轉成“int”型。然而在轉換的過程中肯定會出錯，因此SQL Server會報出錯提示信息（圖40）：

            Microsoft OLE DB Provider for SQL Server 錯誤 '80040e07'
            將 nvarchar 值 ' ＊＊＊＊' 轉換為數據類型為 int 的列時發生語法錯誤。
            /city/dz/lx/show.asp，行 8

其中的“***”正是變量“user”的值，這樣就拿到了數據庫的用戶名。這里重點不是在于用戶名，而是數據庫的判斷，凡是出現上面的錯誤信息，都可以判斷是SQL數據庫。

用上面的方法可以很方便地測試出數據庫類型是否為SQL，但有時如果用戶是以“sa”登錄，那么提示信息將有所不同，提示信息為：

            將”dbo”轉換成int的列發生錯誤
            這樣的情況下，也可以判斷是采用的SQL數據庫。

反之，如果采用的是Access數據庫的話，那么提示信息則會為：

            Microsoft OLE DB Provider for ODBC Drivers 錯誤 '80040e10'
            [Microsoft][ODBC Microsoft Access Driver] 參數不足，期待是 1。
            /index/info/jobs.asp，行 8

從“參數不足，期待是1”信息，可以肯定這是一個Access數據庫（圖41）。

2）內置數據表報出數據庫類型

在前面介紹經典的“1=1和1=2”法進行注入點檢測時，通常是用于服務器不返回錯誤信息，或者過濾了單引號的情況。如果服務器IIS不允許返回錯誤提示，怎么判斷數據庫類型呢？在這樣的情況下，只能通過數據庫內置的系統數據表來進行判斷。

Access和SQL Server數據庫都有自己的系統表，比如存放數據庫中所有對象的表，Access是在系統表[msysobjects]中，但在Web環境下讀該表會提示“沒有權限”, SQL Server是在表[sysobjects]中，在Web環境下可正常讀取。因此，根據Access和SQLServer數據庫系統表的區別，可以判斷這兩種數據庫類型。

在注入點后提交如下語句：

            http://www.＊＊＊＊com/showdetail.asp? id=49 and (select count(＊)
            from sysobjects)＞0
            http://www.＊＊＊＊.com/showdetail.asp? id=49 and (select count(＊)
             from msysobjects)＞0

如果數據庫是SQL Server，那么第一個網址的頁面與原頁面“http://www.***.com/showdetail.asp? id=49”是大致相同的（圖42）；而第二個網址，由于找不到表“msysobjects”，會提示出錯，提示信息為：

            Microsoft OLE DB Provider for SQL Server 錯誤 '80040e37'
            對象名 ' mssysobjects' 無效。
            /city/dz/lx/show.asp，行 8

就算程序有容錯處理，不會返回錯誤信息，但是頁面也與原頁面完全不同（圖43）。

如果數據庫采用的是Access，那么情況就有所不同：提交第一個網址鏈接的頁面與原頁面完全不同，提示錯誤信息為（見圖44）：

            Microsoft OLE DB Provider for ODBC Drivers 錯誤 '80040e37'
            [Microsoft][ODBC Microsoft Access Driver] Microsoft Jet 數據庫
            引擎找不到輸入表或查詢 ' mssysobjects' 。 確定它是否存在，以及它的名稱的
            拼寫是否正確。
            /index/info/jobs.asp，行 8

由于在Access中不存在“sysobjects”表，因此會提示“找不到輸入表或查詢'sysobjects' ”。在提交第二個網址鏈接，其返回信息根據數據庫設置是否允許讀該系統表，從而導致返回的錯誤信息不同。一般在Access中是不允許讀取該表的，所以與原網址也是完全不同的。

一般來說，大多數情況下，提交第一個網址鏈接就可以得知系統所用的數據庫類型，第二個網址只作為開啟IIS錯誤提示時的驗證。

另外，通過自動化的注入工具，也可以自動進行注入點的判斷。