灌注-編程篇》中，我們講了對于程序員而言，如何編碼以防范代碼存在SQL灌注縫隙，那么，對于職員來說，如何測試SQL灌注縫隙是不是存在呢？
起首，我們將SQL灌注攻擊能分為以下三品類型：
Inband：數(shù)據(jù)經(jīng)由SQL代碼灌注的通道取出，這是最直接的一種攻擊，通過SQL灌注獲取的信息直接反映到應(yīng)用程序的Web頁面上；
Out-of-band：數(shù)據(jù)通過不同于SQL代碼灌注的方式獲患上（譬如通過郵件等）
推理：這種攻擊是說并無真正的數(shù)據(jù)傳輸，但攻擊者可以通過發(fā)送特定的哀求，重組返回的結(jié)果從而獲患上一些信息。
豈論是哪種SQL灌注，攻擊者都需要構(gòu)造一個語法正確的SQL查詢，如果應(yīng)用程序?qū)σ粋€不正確的查詢返回了一個錯誤消息，那么就和容易重新構(gòu)造初始的查詢語句的思維規(guī)律，進(jìn)而也就能更易的舉行灌注；如果應(yīng)用程序隱藏了錯誤信息，那么攻擊者就必需對查詢思維規(guī)律舉行逆向工程，即我們所謂的“盲SQL灌注”
黑盒測試及示例： 這個測試的第一步是理解我們的應(yīng)用程序在什么時辰需要訪問數(shù)據(jù)庫，典型的需要訪問數(shù)據(jù)庫的時機(jī)是： 認(rèn)證表單：輸入用戶名和暗碼以查抄是不是有權(quán)限
搜刮引擎：提交處理字符串以從數(shù)據(jù)庫中獲取響應(yīng)的記載
電子商務(wù)站點(diǎn)：獲取某類商品的價格等信息
作為測試職員，我們需要列對所有輸入域的值可能用于查詢的字段做一個表單，包括那一些POST哀求的隱含字段，然后截取查詢語句并孕育發(fā)生錯誤信息。第一個測試往往是用一個單引號“‘”或是分號“；”，前者在SQL中是字符串終結(jié)符，如果應(yīng)用程序沒有過濾，則會孕育發(fā)生一條錯誤信息；后者在SQL中是一條SQL語句的終結(jié)符，同樣如果沒有過濾，也會孕育發(fā)生錯誤信息。在Microsoft SQL Server中，返回的錯誤信息一般是這樣：
同樣可用于測試的另有“--”以及SQL中的一些諸如“AND”的關(guān)鍵字，通常很常見的一種測試是在要求輸入為數(shù)碼的輸入框中輸入字符串，會返回如下的錯誤信息：
類似上邊這樣的墮落返回信息能讓我們知道很多數(shù)據(jù)庫的信息，通常不會返回那么多信息，會返回諸如“500 Server Error”的信息，那就需要“盲SQL灌注”了。注重，我們需要對所有可能存在SQL灌注縫隙的輸入域舉行測試，并且在每個測嘗試使用例時只變化一個域的值，從而才氣找到真正存在縫隙的輸入域。
下面我們看一下標(biāo)準(zhǔn)的SQL灌注測試是怎樣的。
我們以下面的SQL查詢?yōu)槔?
如果我們在頁面上輸入以下的用戶名和暗碼：
那么整個查詢語句就變?yōu)椋?
假定參數(shù)值是通過GET方法傳遞到辦事器的，且域名為www.example.com，那么我們的訪問哀求就是：
對上邊的SQL語句作簡單分析后我們就知道由于該語句永遠(yuǎn)為真，所以肯定會返回一些數(shù)據(jù)，在這種環(huán)境下現(xiàn)實(shí)上并未驗(yàn)證用戶名和暗碼，并且在某些系統(tǒng)中，用戶表的第一行記載是辦理員，那這樣造成的后果則更為嚴(yán)重。
別的一個查詢的例子如下：
在這個例子中，存在兩個需要別人解答的題目，一個是括號的用法，另有一個是MD5哈希函數(shù)的用法。對于第一個需要別人解答的題目，我們可以很容易找到缺掉的右括號解決，對于第二個需要別人解答的題目，我們可以想辦法使第二個條件掉效。我們在查詢語句的最后加上一個注解符以表示后面的都是注解，常見的注解肇始符是/*（在Oracle中是--），也就是說，我們用如下的用戶名和暗碼：
那么整條SQL語句就變?yōu)椋?
我們的URL哀求就變?yōu)椋?
http://www.example.com/index.
php?username=1'%20or% 20'1'%20=%20'1'))/*&password=foo Union查詢SQL灌注測試
另有一種測試是利用Union的，利用Union可以毗連查詢，從而從其他表中獲患上信息，假定我們就象下的查詢：
然后我們設(shè)置id的值為：
那么整體的查詢就變?yōu)椋?
顯然這樣就能獲患上所有信用卡用戶的信息。
盲SQL灌注測試
在上邊我們提到過盲SQL灌注，即blind SQL injection，它象征著對于某個操作我們患上不到不論什么信息，通常這是由于程序員已編寫了特定的墮落返回頁面，從而隱藏了數(shù)據(jù)庫結(jié)構(gòu)的信息。
利用推理方法，有時候辰我們可以或許恢復(fù)特定字段的值。這種方法通常采用一組對辦事器的布爾查詢，依據(jù)返回的結(jié)果來推斷結(jié)果的寄義。仍然延續(xù)上邊的www.example.com，有一個參數(shù)名為id，那么我們輸入以下url哀求：
顯然由于語法錯誤，我們會獲患上一個預(yù)先界說好的墮落頁面，假定辦事器上的查詢語句為SELECT field1, field2, field3 FROM Users WHERE Id='$Id'，假定我們想要獲患上用戶名字段的值，那么通過一些函數(shù)，我們就能夠逐字符的讀取用戶名的值。在這里我們使用以下的函數(shù)：
我們界說id為：
那么最終的SQL查詢語句為：
那么，如果在數(shù)據(jù)庫中有效戶名的第一個字符的ASCII碼為97的話，那么我們就能獲患上一個真值，那么我們就接續(xù)尋找該用戶名的下一個字符；如果沒有的話，那么我們就遞增猜測第一個字符的ASCII碼為98的用戶名，這樣反復(fù)下去就能判斷出正當(dāng)?shù)挠脩裘?
那么，什么時辰我們可以竣事推理呢，我們假定id的值為：
此中N是我們到目前為止已分析的字符數(shù)目，那么整體的sql查詢?yōu)椋?
這個查詢的返回值若是真，那我們就已完成了推理并且我們已獲患上了想要的數(shù)值，如果為假，則表示我們還要接續(xù)分析。
這種盲SQL灌注會要求我們輸入大量的sql嘗試，有一些自己主動化的東西可以或許幫我們實(shí)現(xiàn)，SqlDumper就是這樣的一種東西，對MySQL數(shù)據(jù)庫舉行GET訪問哀求。
存儲過程灌注
在上一篇《如何防范SQL灌注—編程篇》中，我們提到使用存儲過程是可以或許防范SQL灌注的，但同時也要注重，存儲過程如果使用不恰當(dāng)，使用存儲過程的動態(tài)查詢事實(shí)上也會造成一定的SQL灌注縫隙。
以下面的SQL存儲過程為例：
用戶的輸入如下：
后面則顯而易見，用戶的所有暗碼都被更改且獲患上了報(bào)表信息。
