英文原文：DatabaseTube，翻譯：開源中國
在漏洞評估和滲透測試中，確定目標應用程序的輸入向量是第一步。這篇文章解釋了別人是如何通過HTTP頭部對你的數據庫進行SQL注入攻擊的，以及討論下選擇哪種漏洞掃描器測試SQL注入。
作者：Yasser Aboukir, InfoSec Institute
在漏洞評估和滲透測試中，確定目標應用程序的輸入向量是第一步。有時，當做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 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-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-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
http://blog.jobbole.com/35764/