网络上很多同行都发文讨论过各种绕WAF的技巧,也有很多文章分享自研WAF的思路。
作为传统行业的甲方安全工程师,我试着写一写自己在WAF选型测试时的大体思路。
一方面,是对自己完成一个项目的总结,另一方面,也算是提供一个不同的视角看看WAF,希望对乙方朋友今后设计、优化WAF产品有一点点帮助。
0X01 测试思路
- 环境搭建
- 服务器:使用DVWA搭建一套包含各类漏洞的网站,并开启access日志以供分析。DVWA搭建过程不细说。
- WAF:反向代理部署,将DVWA服务器做反向代理后映射出VS IP。测试时所有payload发送至VS IP,经WAF处理后交给DVWA服务器。
- 测试方法:客户端构造payload提交给VS IP,服务器查看access日志。如被有效识别并过滤,access日志应没有相关内容。
0X02 OWASP TOP10 常规防御
- SQLi
- get型注入:http://10.44.100.18/dvwa/vulnerabilities/sqli/?id=22&Submit=Submit# 的参数id可以注入,构造payload提交即可。
- post型注入:DVWA登录过程用burpsuite抓包,即可构造post型注入。
- XSS
- 反射型XSS和存储型XSS在DVWA中都有,构造payload即可。
- CSRF、command injection、Brute Foce、File upload等等方式,DVWA都有了,不细说。
- 漏掉的是SSRF、反序列化、structs、心脏滴血,这些攻击在当前版本的DVWA中是没有设计的,需要单独考虑。
0X03 绕过技术的防御
除了最常见攻击手法的防御以外,WAF还应该具备识别变形的Payload的能力。
目前国内外商业WAF可以识别99%以上的常规攻击手段,区别主要就体现在对各类编码后的变形Payload的分析能力上。
这里面又区分成了两大类思路。
思路一:
WAF抓取到HTTP包后,做多重解码,将每重解码的结果提取正则,与特征库进行匹配。各家能解码的层数会有区别。F5的ASM可以支持最多5层并且允许用户手工设定层数。其他家虽不可指定解码层数,但都具备相应能力。
思路二:
考虑到正则匹配容易误报漏报,有厂家放弃了这种分析模式,转而做语义分析。长亭科技的SqlChop就是如此,详情可阅读:SQLChop - 一个新型 SQL 注入检测引擎
在测试中,需要手工对payload做编码变形。详细说来:
SQLi变形
- urlencode编码:别小看这种常见的绕过方法,有厂家的WAF还真检测不出来。
- unicode编码
- 关键字大小写替换:这个比较常规了,基本是没有检测不到的。
- 关键字转为十六进制
- 关键字用反引号引起来
- 关键字用/#! #/注释引起来
- 关键字用/##/注释截断:select转为sel/**/ect
- 关键字用%00截断
- 提交的HTTP包中,将x-originating-IP 改为127.0.0.1
- 提交的HTTP包中,将X-remote-addr 改为127.0.0.1
- SQLMAP的各类TAMPER,挨个试一试吧
XSS变形
XSS变形最多,WAF漏报也是最严重的。谁让HTML可利用的标签那么多呢。
这一块的测试,有赖于测试者平时收集各类XSS payload 的量。我仅列出一部分常见的以供参考:
文件包含绕过
|
|
文件上传绕过
文件上传绕过主要考虑几个方面:
- 123.php.123
- 123.asp;.gif
- as.php%00.gif
- 文件开头添加GIF89a
- burpsuite抓包修改Content-Type: image/jpeg
###0X03 扫描器防御能力
WAF应具备根据数据包特征识别扫描器的能力,并加以阻止。常见的扫描器,如WVS、SQLMAP、Netsparker、havij、Appscan都应该拿来实际测试WAF的反应。
需要说明的一点是,WAF不仅要拦截扫描器发来的数据包,还应在日志中注明,攻击者使用何种扫描器。这对运维人员分析日志很有帮助。
例如,实际测试中,Imperva对SQLMAP和Netsparker都可以准确识别。而F5的ASM则可以准确识别WVS和SQLMAP。FortiWeb则不具备这个能力。
剩下几个章节,将讨论以下内容:
- Webshell通信拦截测试
- 其余几个小功能点测试
- 设备自身安全测试
- 自学习模式测试
- WAF测试工具
- WAF 管理维护功能测试
未完待续