通过HTTP Headers 进行SQL注入

zhouxingxing 发布于 2012/04/12 13:01
阅读 4K+
收藏 17

关于作者

Yasser Aboukir是一位国家级的工程师,信息安全顾问,以及it学院的研究员。他是摩洛哥网络安全挑战的创始人,摩洛哥OWASP的成员。目前致力于网站应用程序,渗透性测试方法和安全管理标准的主题。

在脆弱性评估或渗透率测试,识别输入向量到目标应用程序是一个很原始。有时,当处理Web应用测试时,关于SQL注入缺陷发掘的验证程序局限于GET和POST的变量作为独一无二的输入向量。其他的HTTP Headers又怎么样呢?他们不是潜在的输入向量为了SQL注入攻击?如何测试所有的HTTP参数和如何扫描漏洞,以便于避免留下没有发现的漏洞在应用中。

在网络应用扫描输入参数的安全覆盖率

一份比较结果是在60款商业开源黑盒Web应用的漏洞进行扫描,被发表在标题为: « The Scanning Legion: Web Application Scanners Accuracy Assessment & Feature Comparison ». 这个基准,在2011年由安全研究员Shay Chen实现,专注于测试商业和开源工具可以检测安全漏洞在广泛的URLls。

我们在下面的表中的得出的结论,输入参数的覆盖度的支持通过通过测试Web应用扫描器。这些输入基本是:

  • TP Query String Parameters (GET): 输入参数通过URL发送。
  • HTTP Body Parameters (POST): 输入参数通过HTTP body发送。
  • HTTP Cookie Parameters: 输入参数通过HTTP cookie发送。
  • HTTP Headers:使用HTTP头请求的应用。

这个图表明显的展示出 75% Web应用扫描器不能发现HTTP Headers 参数的相关缺陷,此外70%这些扫描器也不能检查HTTP Cookies 缺陷。这些比率正确的展示扫描器扫描输入向量的能力,不是简单的解释它,相比于合理的GET和POST分数,一些自动化测试工具可能导致不满意的结果当我们处理HTTP Headers作为SQL注入输入向量。

事实上,HTTP Headers 和Cookies不应该被低估,因此,这两个向量应该考虑在测试计划。当漏洞扫描器不支持这些特性,我们应该考虑手工测试这些参数。

潜在的HTTP Header SQL注入 

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变量,我们将在下一个例子中看到基于SQL注入的Cookie。

X-Forwarded-For

X-Forwarded-For 是用来识别通过HTTP代理负载均衡方式连接到Web服务器的客户端最原始的IP地址的HTTP请求头字段。我们将看到一个关于以表单提交的缺陷的例子。

 

$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 header X_FORWARDED_FOR找回,被preg_match控制去证实是否这个参数至少有一个IP地址,事实上,环境变量HTTP header 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查询例子:

 

GET /index.php HTTP/1.1  

Host: [host]  

User-Agent: aaa' or 1/* 

 

Referer

Referer是另一个HTTP Headers 容易被SQL注入攻击一旦应用把它存储到数据库而没有处理它,它是一个可选的头字段允许客户端去指定,为了服务器的利益,这个文档的地址或者其中元素的地址来自请求中的URL。这允许服务器生成文档,兴趣,记录等等的反向链接列表,它允许坏链接来跟踪维护。

例子:

 

GET /index.php HTTP/1.1  

Host: [host]  

User-Agent: aaa' or 1/*  

Referer: http://www.yaboukir.com 

 

攻击者的角度?

众所周知,注入缺陷排名第一在 OWASP 10大Web应用严重风险。攻击者越来越多的去查找注入点来完整的存取你的数据库。不论注入变量的类型是什么,是否是一个GET, POST, Cookie 或者 其他 HTTP headers;对于入侵者最重要的是最少有一个注入点让他们开始入侵工作。

基于SQL注入的手工测试Cookie

在这一部分,我们将介绍 一些检查HTTP Cookie变量的方法

使用一个浏览器插件

Cookies Manager+

Cookie Manager+ 允许查看,编辑和创建新的cookies.它同样允许展示额外的关于cookies信息,允许一次编辑成倍的cookies,同样支持备份和还原它们。

安装完成以后,在工具菜单中,选择Cookies Manager+,我们选择一个Cookie变量来关联一个目标应用。

我们将编辑language_id,来计算出SQL注入缺陷,我们将加入一个引用在这个字段language_id的内容。

在刷新页面后,或者点击应用中其他网络连接,应用提交这个请求通过HTTP cookie。这个结果触发了一个SQL错误:

这个数据库错误提醒我们一个容易影响的SQL注入缺陷。

使用Cookies Manager+的优势是它用起来非常的简单,直接作用于cookie和保存cookie先前的编辑值。

我们将试着确定列的数目通过其他的火狐插件。

Tamper Data:

Tamper Data是一个功能强大的火狐插件去查看和修改HTTP/HTTPS头和传递的参数。

安装完成之后,在工具菜单中,选择Tamper Data。开始破坏HTTP请求通过点击按钮。

当从目标应用中发射请求,Tamper Data弹出一个对话框然后问时候我们要破坏刚刚发送的正确的HTTP请求。

点击Tamper后,我们得到一个Tamper弹出框。

我们添加:以4排序HTTP cookie变量在下面提供截图,从应用得到的响应是正常的。

此时我们增加这个数字:以5排序 这个响应对于这个注入:

所以我们可以推断这个列的列数是4.

现在,我们将试着去计算出有影响的列以便于注入更多SQL查询。所以,我们将添加下面的查询到language_id HTTP cookie变量。

-1+UNION+ALL+SELECT+1,2,3,4

有时,这个开发可能需要更高级的SQL注入技术。

采用自动化渗透检测扫描器

Sqlmap为例

Sqlmap 是一款开源的流行的渗透测试工具,进行自动化的检测过程和利用一些SQL注入缺陷来接管数据库服务。

Sqlmap 支持HTTP cookie特性,所有它可以有两种用途:

  • 当Web应用需要的时候进行基于cookie的鉴权。
  • 检测和利用SQL注入在这样的头字段的值。、

默认情况下的Sqlmap支持GET参数和POST参数。当level的值被设置为2或者更高,它同时也测试HTTP Cookie header的值。当被设置为3或者更高,它也测试 HTTP User-Agent 和 HTTP Referer header 的SQL注入。它可能手动指定表为你想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。

下面的这个例子是如何测试参数为security的HTTP Cookie

 

./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%。

我们建议下面方程的算法,意味着适应一个平均分数的漏洞扫描器。

在平均获得检查的精度的比例之后,我们得到一份下面的结果前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%

 

我们可以展示一个图表代表着漏洞扫描器通过他们的平均得分,定义了它们的检测精度队友SQL注入缺陷和他们的输入向量的覆盖率。

 

接下来的工作?

对于开发者

Cookies 和其他存储的 HTTP headers应该被当做开发者作为其他来自用户输入,经受同样的验证程序。

对于测试者

操纵HTTP header 请求在页面请求(特别是REFERER 和 USER-AGENT字段)是重要的确定时候应用容易受到SQL注入向量或者甚至其他的XSS,它是一个很好的实践去定义和描绘每一种方式,一个用户操纵的被应用使用的数据,这些数据或许被存储,用来和处理从Cookies, HTTP-headers (像是 HTTP_USER_AGENT ), 来自的数据 (可见的和隐藏的), Ajax-, JQuery-, XML-请求。

参考文献

[1]渗透测试与改进的输入向量识别,William G.J. Halfond, Shauvik Roy Choudhary,和亚历山德罗超卓汇集大学计算佐治亚理工学院。

[2]安全工具基准,一个博客致力于帮助pen-testers在选择工具有影响。通过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

英文原文   OSCHINA原创翻译
加载中
返回顶部
顶部