自动化web安全测试

2016-08-24 10,503

注:本文为“小米安全中心”原创,作者: 妇愁者纞萌,转载请联系“小米安全中心”

上期回顾:中、小企业如何自建免费的云WAF

Web安全的测试过程简单的可以理解为“对基础request的改造,来探测服务器的响应”。当改造后的request,使服务器的响应得出了对应的结果,我们就可以初步判定漏洞是否存在。

以SQL注入为例:

如下是一个最常见的post请求

POST

http://*****api/report/bad?stoken=7c0dfa753141c86ab1e44b801c29f54f&channel=chunlei&web=1&app_id=250528&logid=MTQ3MDkwNjQ3M==&clienttype=0HTTP/1.1

Host:*****

Proxy-Connection:keep-alive

Content-Length:141

Accept:*/*

Origin:http://******

X-Requested-With:XMLHttpRequest

User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/51.0.2704.106 Safari/537.36

Content-Type:application/x-www-form-urlencoded; charset=UTF-8

Referer:http://*****/s/1kVGYFrx

Accept-Encoding:gzip, deflate

Accept-Language:zh-CN,zh;q=0.8

Cookie:

 

tpl=report&feture=sharefile&item_id=%5B162086046798865%5D&item_url=http%3A%2F%2Fpan.baidu.com%2Fs%2F1kVGYFrx&item_uk=1259907924&report_type=5

SQL注入的检测过程其实就是替换请求中的参数值为我们的测试规则,如’ and sleep(3) or ‘1’=’1改造后的post请求就是:

POST

http://***/api/report/bad?stoken=7c0dfa753141c86ab1e44b801c29f54f&channel=chunlei&web=1&app_id=250528&logid=MTQ3MDkwuNzU2MzkyMzc4NzM1MzE0Mg==&clienttype=0HTTP/1.1

Host:***

Proxy-Connection:keep-alive

Content-Length:141

Accept:*/*

Origin:http://***

X-Requested-With:XMLHttpRequest

User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/51.0.2704.106 Safari/537.36

Content-Type:application/x-www-form-urlencoded; charset=UTF-8

Referer:http://***/s/1kVGYFrx

Accept-Encoding:gzip, deflate

Accept-Language:zh-CN,zh;q=0.8

Cookie:

 

tpl=report’ and sleep(3) or ‘1’=’1&feture=sharefile&item_id=%5B162086046798865%5D&item_url=http%3A%2F%2F***%2Fs%2F1kVGYFrx&item_uk=1259907924&report_type=5

 

当请求出现延迟,我们则可以初步判定此处有sql注入的可能。这是一个request的探测基础,那么自动化测试的思路就是:

  1. 收集大量的原始request
  2. 对request进行规则的改造
  3. 将改造后的request发送至服务端探测服务的响应

当服务端的响应因规则的改变而变化,响应符合漏洞的特点时,说明规则生效。

有了这样的一个框架,探测一些隐藏较深的漏洞也会很容易,如文件包含、命令注入、XSS等。

无非是修改为这些漏洞的规则后,在对漏洞的特点做服务端响应的判断。

有人可能会问为什么要用request,直接爬取url不是更方便吗?url由于没有请求头cookie,所以很难测试一些需要登陆会话的web产品。

再加上我们往往测试的请求并不简简单单的测试请求的参数,像伪静态的链接、请求头、cookie都可能会成为我们的测试对象,所以测试request最完善。

再加上目前有很多厂商为防止爬取或防止CSRF等都会验证请求的referer或其他请求头,爬取url的方式、日志中提炼url的方式往往已经不能满足测试需求。

Request的获取一般都采用代理抓包的方式。常用的测试工具如burpsuite、Fiddler。个人比较青睐于使用后者,fiddler里有一个customize rules选项,进入FiddlerScript可以让我们自己编写功能。

 

那么问题来了,现在出现两种方案:

  1. 编写插件,直接对request进行测试
  2. 将request进行本地保存,捕获完成后再进行测试

经实验后发现第一种方案并不合适。(脉搏小编认为完全没有问题,你可以抓包写到db或者队列,另外扫描机读取db或队列测试回显嘛)

  1. 是它会影响抓包时测试机的资源占用,
  2. 是边抓取边测试会影响web应用的使用。

所以这里还是建议使用第二种方案。

接下来简单说一下fiddler的插件开发,我是一名测试人员,并不擅长开发,开发技术只是协助测试的一种手段。

自动化测试讲究的也是效率,所以建议不要在开发插件上花费太多的精力,尽可能最大话的利用工具已有的功能,比如对request进行测试时,为提高效率,我们可以过滤一些不需要测试的request,fiddler有对request的过滤功能:

 

fiddle1

 

那么过滤不需要测试的request就可以直接交给fiddler.在FiddlerScript中函数OnExecAction可以让我们自定义命令。好在的是fiddler已经为我们封装好了很多函数,直接调用就可以了。参考代码:

case"save":
varSessions=UI.GetAllSessions();
for(vari=0;i<Sessions.Length;i++)
{
Sessions[i].SaveRequest("存储目录"+i.toString()+"_Request.txt",false);
}
returntrue;

保存后,在fiddler左下角执行save即可保存request到指定目录。

有了原始request那么问题就容易多了,但是对request的处理依然是一段坎坷的路程,比如各种编码问题、特殊请求头的处理问题、解决误报等,这些一般都是在不断调试修改后才能得出结论的。下面给一个request的处理流程仅供参考:

requests

依照上边的流程写完工具后,基本能够达到日常测试工作的需要了。

当然还需要很多的改进,比如对json数据提交的request的解析,伪静态的判断等等还没有加入到工具中。

但好处是常规漏洞已经不再需要手工的重放请求,且工具很容易上手,无安全知识的人同样可以使用。日后的工作量就在维护规则,增加漏洞规则上了。

我的原则管他黑猫还是白猫,能抓到耗子就是好猫。

工具不在于表面上功能有多完善,重要的是灵活,易用,测试人员需要的是高效,准确,能挖到漏洞才是硬道理。

讨论

作者在对request进行排重时,遇到难题,现在很多web产品使用框架,请求的地址都是相同的,只有参数的不同、或参数值的不同。

如何能测试完整,又能高效的完成测试?

你有什么好的方法?

微信公众号:qrcode

小米安全中心:http://sec.xiaomi.com/

【注:本文为“小米安全中心”原创  作者: 妇愁者纞萌    安全脉搏整理发布】

本文作者:小米SRC

本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/51411.html

Tags:
评论  (1)
快来写下你的想法吧!

小米SRC

文章数:39 积分: 56

安全问答社区

安全问答社区

脉搏官方公众号

脉搏公众号