自动化web安全测试

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

上期回顾：中、小企业如何自建免费的云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/

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

源链接

Hacking more

...