知識星球在漏洞評估和滲透測試中，確定標的應用程式的輸入向量是第一步。這篇文章解釋了別人是如何透過HTTP頭部對你的資料庫進行SQL註入攻擊的，以及討論下選擇哪種漏洞掃描器測試SQL註入。
在漏洞評估和滲透測試中，確定標的應用程式的輸入向量是第一步。有時，當做web應用程式測試時，SQL註入漏洞的測試用例通常侷限於特殊的輸入向量GET和POST變數。那麼對於其他的HTTP頭部引數呢？難道他們不是潛在的SQL註入攻擊輸入向量嗎？我們如何測試這些HTTP引數呢，以及使用什麼樣的漏洞掃描器查找出這些應用的漏洞呢？
web應用掃描器裡輸入引數的改寫範圍
透過對60個商業和開源的黑盒web應用程式漏洞掃描器的比較，發表了這樣一篇文章：“掃描軍團：掃描精度評估&功能比較”。這個主要用於測試商業和開源軟體的urls漏洞的標準，已經被安全研究人員Shay Chen在2011年釋出了。
對於測試web應用程式的掃描器支援輸入引數改寫的情況，我們已經總結在下麵的圖表中了。這些主要的輸入是：
-
HTTP 查詢字元引數（GET）：輸入引數透過URL傳送
-
HTTP 正文引數（POST）：輸入引數透過HTTP正文傳送
-
HTTP Cookie引數：輸入引數透過HTTP cookie傳送
-
HTTP Headers：HTTP提交應用程式使用的頭
這個圖表中明顯的顯示出，有75%的web應用程式掃描器不能發現HTTP Headers引數的相關漏洞。此外，這些掃描器中的70%，也錯誤的檢查了HTTP Cookies漏洞。這些比例完全說明瞭這些掃描器在掃描輸入向量方面的能力，而不只是簡單的解釋。對GET和POST的評分是比較合理的，一些自動化測試工具可能導致，在處理HTTP essay-headers作為一個SQL註入輸入向量時，出現不令人滿意的結果。
實際上，HTTP Headers和Cookie沒有得到重視。因此，這兩個向量應該在測試用例中被考慮到。還有，當我們使用的漏洞掃描器不支援這些特徵時，我們應該考慮手工測試這些引數。
潛在的HTTP頭SQL註入
HTTP頭欄位
HTTP頭欄位是超文字傳輸協議（HTTP）中請求和響應的部分資訊，它們定義了HTTP傳輸的操作引數。
例如: 請求的 HTTP
GET / HTTP/1.1
Connection: Keep-Alive
Keep-Alive: 300
Accept:*/*
Host: host
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16 ( .NET CLR 3.5.30729; .NET4.0E)
Cookie: guest_id=v1%3A1328019064; pid=v1%3A1328839311134
當我們把會話標識儲存在資料庫時，首先應該把HTTP Cookies作為首要潛在的HTTP變數進行測試。在後面我們將會看到一個使用Cookie進行SQL註入的實體。也有其他和應用相關的HTTP頭資訊。
X-Forwarded-For
X-Forwarded-For是HTTP頭的一個欄位。它被認為是客戶端透過HTTP代理或者負載均衡器連線到web服務端獲取源ip地址的一個標準。
我們來看一個基於表單提交漏洞的例子。
$req = mysql_query(“SELECT user,password FROM admins WHERE user=’”.sanitize($_POST[‘user’]).”‘ AND password=’”.md5($_POST[‘password’]).”‘ AND ip_adr=’”.ip_adr().”‘”);
sanitize() 方法控制著登入變數的正確性。
function sanitize($param){ if (is_numeric($param)) { return $param; } else { return mysql_real_escape_string($param); } }
讓我們檢查下變數ip，它透過ip_addr()方法來得到輸出的值。
function ip_adr() { if
(isset($_SERVER[‘HTTP_X_FORWARDED_FOR’])) { $ip_adr = $_SERVER[‘HTTP_X_FORWARDED_FOR’]; } else { $ip_adr = $_SERVER[“REMOTE_ADDR”]; } if (preg_match(“#^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}#”,$ip_addr)) { return $ip_adr; } else { return $_SERVER[“REMOTE_ADDR”]; } }
顯然，ip地址透過HTTP頭X_FORWARDED_FOR 得到傳回值。之後，透過preg_match方法來驗證是否至少存在一個合法的ip地址。事實上，在使用SQL查詢前HTTP_X_FORWARDED_FOR 環境變數沒有充分的過濾，這也就導致了在SQL查詢時，可以透過這個欄位註入任意SQL程式碼。
這個頭欄位可以像下麵這樣簡單地修改:
GET /index.php HTTP/1.1
Host: [host]
X_FORWARDED_FOR :127.0.0.1′ or 1=1#
這樣的修改將會導致繞過安全認證。
User-agent
使用者代理（user agent）是記錄軟體程式的客戶端資訊的HTTP頭欄位，他可以用來統計標的和違規協議。在HTTP頭中應該包含它，這個欄位的第一個空格前面是軟體的產品名稱，後面有一個可選的斜槓和版本號。
並不是所有的應用程式都會被獲取到user-agent資訊，但是有些應用程式利用它儲存一些資訊（如：購物車）。在這種情況下，我們就有必要研究下user-agent頭存在的問題了。
HTTP查詢實體：
GET /index.php HTTP/1.1
Host: [host]
User-Agent: aaa’ or 1/*
Referer
Referer是另外一個當應用程式沒有過濾儲存到資料庫時，容易發生SQL註入的HTTP頭。它是一個允許客戶端指定的可選頭部欄位，透過它我們可以獲取到提交請求URI的伺服器情況。它允許伺服器產生一系列的回退連結檔案，像感興趣的內容，日誌等。它也允許跟蹤那些壞連結以便維護。
例如：
GET /index.php HTTP/1.1
Host: [host]
User-Agent: aaa’ or 1/*
Referer: http://www.yaboukir.com
攻擊者目的?
眾所周知，註入漏洞位列OWASP十大web應用安全風險之首。攻擊者越來越多的尋找你的資料庫讀寫許可權，無論這個註入點是向量輸入型別，GET，POST，Cookie或者其他的HTTP頭；對於攻擊者重要的是，找到至少一個能夠讓他們深入利用的註入點。
手動測試Cookie漏洞
在這部分，我們將介紹下檢查HTTP Cookie變數的幾種方法。
使用瀏覽器外掛
Cookie Manager+ 允許檢視，編輯和建立新的cookies，它也提供顯示cookies的一些額外資訊，支援同時修改多個cookies，而且我們可以備份/恢復這些cookies。
安裝之後，在工具選單中選擇Cookies Manager+，選擇一個和標的應用有關的Cookie 變數。
我們來編輯下language_id這個變數，為了判斷是否存在SQL註入漏洞，我們在欄位後面新增個“’”。
language_id內容如下：
然後掃清頁面，或者點選這個應用程式內部的其他連結，提交編輯後的HTTP cookie請求，傳回結果出現一個SQL錯誤:
這個資料庫錯誤提醒我們存在一個易產生SQL註入的漏洞。
Cookies Manager+ 優勢是他非常易用，我們可以直接對cookie操作並且儲存之前修改的cookie。
下麵我們將嘗試使用另一個Firefox外掛，來檢測標的的列數。
Tamper Data:
Tamper Data 是火狐下的一個非常強大的外掛，它可以顯示和修改HTTP/HTTPS頭，以及POST引數。
安裝之後，在工具欄選單選擇Tamper Data，點選按鈕Start Tamper開始修改HTTP請求。
當標的應用程式傳送任何請求時，Tamper Data都會彈出一個對話方塊詢問我們是否想要幹預當前HTTP請求。
點選Tamper後，將彈出一個Tamper詳細視窗:
我們按上圖顯示的那樣：新增order by 4到HTTP cookie變數。從應用程式傳回的響應是正常的。
我們繼續增加: order by 5. 這次註入的響應如下:
所以，我們能夠推斷出列數為4。
現在，為了在更多查詢裡註入，我們嘗試找出受影響的列。因此，我們需要把下麵的查詢新增到HTTP cookie變數language_id裡:
-1+UNION+ALL+SELECT+1,2,3,4
這個手段可能需要利用到一些高階的SQL註入技術。
使用自動化滲透測試掃描工具
以Sqlmap為例
Sqlmap 是一個流行的開源的自動化滲透測試工具。這個程式可以測試和利用SQL註入缺陷，並且可以接管資料庫服務。
Sqlmap 支援HTTP cookie功能，所以它可以透過兩種方式使用:
-
當web應用程式需要時，基於cookies的安全驗證。
-
頭值中SQL註入的檢測和利用。
Sqlmap預設測試所有的GET引數和POST引數。當-level引數值設定為2或者更大時，它將測試HTTP Cookie 頭值。當這個值設定為3或者更大時，測試也包含HTTP User_Agent和HTTP Referer頭值。你也可以將你想用sqlmap測試的引數，用逗號分隔開進行測試，這樣就會繞過對-level的依賴。
|
Tested HTTP parameter |
Level in sqlmap |
|
GET |
1 (Default) |
|
POST |
1 (Default) |
|
HTTP Cookie |
2 ? |
|
HTTP User-Agent |
3 ? |
|
HTTP Referer |
3 ? |
例如，測試GET引數id和HTTP User-agent，只需提供-p id,user-agent引數。
下麵這個例子演示了DVWA (Damn Vulnerable Web Application)的HTTP cookie中名為security的測試。
./sqlmap.py -u ‘http://127.0.0.1/vulnerabilities/sqli/?id=1&Submit;=Submit#’
–cookie=’PHPSESSID=0e4jfbrgd8190ig3uba7rvsip1; security=low’
–string=’First name’ –dbs –level 3 -p PHPSESSID
-string標誌比較註入時有效頁面和無效頁面。另一方面，-dbs標示用來列舉資料庫管理系統。最後，-p標示用來表示強制測試PHPSESSID變數。
測試SQL註入的工具：透過精度選擇還是向量改寫率選擇?
為了回答這個問題，我們使用了sectoolmarket.com網站提供的標準測試結果，我們先假設候選的掃描程式的測試精度和向量改寫率有相同的重要性。我們將GET。POST，HTTP Cookie和HTTP Headers作為應該被支援的輸入向量。當所有的引數都被支援時，這個掃描器的改寫範圍的比率為100%（4/4）。
我們建議使用下麵的算術方程式，也就是說對於漏洞掃描器的得分求一個平均值。
然後從得到的檢測準確率的百分比中，我們列出前14名的掃描器：
|
Rank |
Vulnerability Scanner |
Vendor |
Detection Rate |
Input Vector Coverage |
Average Score |
|
1 |
Arachni |
Tasos Laskos |
100.00% |
100% |
100.00% |
|
2 |
Sqlmap |
sqlmap developers |
97.06% |
100% |
98,53% |
|
3 |
IBM AppScan |
IBM Security Sys Division |
93.38% |
100% |
96,69% |
|
4 |
Acunetix WVS |
Acunetix |
89.71% |
100% |
94,85% |
|
5 |
NTOSpider |
NT OBJECTives |
85.29% |
100% |
92,64% |
|
6 |
Nessus |
Tenable Network Security |
82.35% |
100% |
91,17% |
|
7 |
WebInspect |
HP Apps Security Center |
75.74% |
100% |
87,87% |
|
8 |
Burp Suite Pro |
PortSwigger |
72.06% |
100% |
86,03% |
|
9 |
Cenzic Pro |
Cenzic |
63.24% |
100% |
81,62% |
|
10 |
SkipFish |
Michal Zalewski – Google |
50.74% |
100% |
75,37% |
|
11 |
Wapiti |
OWASP |
100.00% |
50% |
75.00% |
|
12 |
Netsparker |
Mavituna Security |
98.00% |
50% |
74.00% |
|
13 |
Paros Pro |
MileSCAN Technologies |
93.38% |
50% |
71,69% |
|
14 |
ZAP |
OWASP |
77,21% |
50% |
63,60% |
我們可以透過對掃描器的掃描漏洞的精度和向量改寫率取到的平均值，做出下麵一個圖表。
接下來做啥?
對於開發者
開發者應當把cookies和其他儲存的HTTP頭像表單輸入一樣對待，能透過常規的驗證。
對於測試者
HTTP頭的操作請求資訊（尤其是REFERE和USER-AGENT）對於確認應用程式是否存在SQL註入漏洞或者其他缺陷（XSS）是非常重要的，最好的方法是在使用應用程式時定義和描述好每一種操作情況。這些資料可能被儲存，提取和處理，像cookie,HTTP-essay-headers（像HTTP_USER_AGENT）,form-variables（顯示和隱藏），Ajax- ，JQusery-，XML-requests.
Yasser Aboukir 是INFOSEC機構的一個安全研究員. InfoSec Institute 是個提供CEH 認證和CCNA training訓練的機構.
參考文獻
[1] Penetration Testing with Improved Input Vector Identification, William G.J. Halfond, Shauvik Roy Choudhary, and Alessandro Orso College of Computing Georgia Institute of Technology
[2] Security Tools Benchmarking – A blog dedicated to aiding pen-testers in choosing tools that make a difference. By Shay-Chen http://sectooladdict.blogspot.com/2011/08/commercial-web-application-scanner.html
[3] https://en.wikipedia.org/wiki/X-Forwarded-For
[4] http://www.techbrunch.fr/securite/blind-sql-injection-essay-header-http/
[5] http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#user-agent
[6] http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z14
[7] https://addons.mozilla.org/en-US/firefox/addon/cookies-manager-plus/
[8] https://addons.mozilla.org/en-US/firefox/addon/tamper-data/
[9] http://sqlmap.sourceforge.net/doc/README.html
[10] http://msdn.microsoft.com/en-us/library/ms161953.aspx
英文出處：DatabaseTube
譯文出處：開源中國-繆斯的情人
譯文連結：http://www.oschina.net/translate/sql-injection-through-http-essay-headers