Article Learn

自动化web安全测试

Post by 妇愁者纞萌 at 2016-10-25 14:23:52

注:本文为“小米安全中心”原创,转载请联系“小米安全中心”

上期回顾:中、小企业如何自建免费的云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进行本地保存,捕获完成后再进行测试

经实验后发现第一种方案并不合适。1是它会影响抓包时测试机的资源占用,2是边抓取边测试会影响web应用的使用。所以这里还是建议使用第二种方案。

接下来简单说一下fiddler的插件开发,我是一名测试人员,并不擅长开发,开发技术只是协助测试的一种手段。自动化测试讲究的也是效率,所以建议不要在开发插件上花费太多的精力,尽可能最大话的利用工具已有的功能,比如对request进行测试时,为提高效率,我们可以过滤一些不需要测试的request,fiddler有对request的过滤功能:                       

那么过滤不需要测试的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的处理流程仅供参考:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1


依照上边的流程写完工具后,基本能够达到日常测试工作的需要了。当然还需要很多的改进,比如对json数据提交的request的解析,伪静态的判断等等还没有加入到工具中。但好处是常规漏洞已经不再需要手工的重放请求,且工具很容易上手,无安全知识的人同样可以使用。日后的工作量就在维护规则,增加漏洞规则上了。

我的原则管他黑猫还是白猫,能抓到耗子就是好猫。工具不在于表面上功能有多完善,重要的是灵活,易用,测试人员需要的是高效,准确,能挖到漏洞才是硬道理。

注:本文为“小米安全中心”原创,转载请联系“小米安全中心”

—   联系我们   —

新浪微博

公众号