php网站若何测试技巧_技能分享从甲方的角度谈谈WAF测试方法

作者：lewisec_com

稿费：300RMB（不服你也来投稿啊！
）

投稿办法：发送邮件至linwei#360.cn，或上岸网页版在线投稿

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

0X04 扫描器防御能力

WAF应具备根据数据包特色识别扫描器的能力，并加以阻挡。
常见的扫描器，如WVS、SQLMAP、Netsparker、havij、Appscan都该当拿来实际测试WAF的反响。

须要解释的一点是，WAF不仅要拦截扫描器发来的数据包，还应在日志中注明，攻击者利用何种扫描器。
这对运维职员剖析日志很有帮助。

例如，实际测试中，Imperva对SQLMAP和Netsparker都可以准确识别。
而F5的ASM则可以准确识别WVS和SQLMAP。
FortiWeb则不具备这个能力。

0X05 Webshell防御

webshell拦截

文件上传防御难免鸭蛋虽密也有缝，普通的webshell上传后，攻击者一定要通过与webshell通信，开展后续渗透。
WAF必须有能力识别通信内容，并及时阻断。
很多webshell的通信内容是经由base64编码的，WAF必须具备解码后准确剖析的能力。

测试方法很大略，在做事器上放好测试的webshell，客户端通过WAF后访问webshell，实行主要的操作，如：dir、ls、net user等系统命令；连接操作数据库；上传下载文件等。

这项测试须要网络大量常用webshell，用于覆盖常见webshell的识别。
Github上有一个项目网络了各种格式的webshell，妈妈再也不担心我找不到shell啦。

Github webshell collect

一句话拦截

如果做事器安装有杀毒软件，常见webshell是可以被查杀的。
大马能拦住，小马当然也不能放过。
一句话木马可是杀软无力识别的。

防御一句话，实在防御的是菜刀以及各种版本的菜刀与一句话的通信。

这里要重点说两款工具：

cknife：[项目地址]，这把刀可以自定义各种通信办法和php实行函数用于绕过waf检测。
实际测试下来，的确很多家waf的默认策略对自定义模式拦截无力。

antSword：[项目地址]，修正版的菜刀，也很好用。

0X06 暴力破解及其他杂项

暴力破解

WAF必须具备识别工具自动爆破密码的能力，实在判断的事理不难，剖析要求某个文件的某几个参数的频率即可。
用BurpSuite测一测就知道。
在WAF上须要手工配置防爆破的策略，指明要求的URI、用户须要输入的参数名、访问阈值条件。

F5 ASM在判断暴力破解行为时，会判断会话有效性，造成这里有个bug，利用burpsuite爆密码时ASM根本拦不住。
开了售前ticket查了半天，联系研发才闹明白是判断机制设计所致，自然也就无法修正了。

机器访问

为了防止薅羊毛，WAF必须具备能力，根据用户自定义的URI、参数名、源IP/目的IP、目的URL等条件，拦截超出正常频率的机器访问行为。

这项测试非常磨练设备的自定义程度，而Imperva在自定义策略的灵巧性上，遥遥领先其他友商，无愧于Gartner第一象限的位置。
自定义程度越高，策略越灵巧，防御效果越好，对甲方工程师的技能哀求也就越高。
很多传统行业的甲方工程师由于不熟习攻防，对HTTP没研究那么深，自定义策略反而成了事情的包袱。
在和Imperva工程师互换时多次看到其他同行发来的邮件，讯问某某场景下实现某功能，该当如何配置。
我以为如果不懂HTTP，WAF干脆就不要玩了，纯粹是给自己找包袱。
从白帽子的角度来说，目标网站有WAF不可怕，渗透还是要坚持的，万一对方不懂HTTP呢。

指定参数拦截

在post表单中，安全基线哀求代码必须判断用户输入内容是否合理。
比如，手机号一项，必须提交13/15/17/18开头的11位纯数字。
如果编码时实现该需求，一行正则匹配就搞定。
但是你不能担保每个程序猿都是勤奋的。
以是，用WAF帮助站点实现该需求是必备功能哀求。

WAF必须具备识别制订URI的指定参数，提交的数据格式。
这一项也是将各厂家区分开的主要指标。

命令注入

WAF还必须具备识别命令注入攻击的能力，这一项DVWA是供应了测试功能的。
之以是重点拿出来说，是由于Imperva、F5 ASM在这里都存在明显的疏漏。
常见系统命令，这两家的WAF都不能在默认策略下准确识别。
这一点我很奇怪，明明特色库里是有这一类特色的，可为何检出率如此低？

0X07 设备自身安全

WAF除了要保护目标网站的安全性之外，自身的安全性也不可或缺。
别不信，FortiWeb的5.5.3版本就存在CSRF漏洞。
国产主流的漏洞扫描产品，除了绿盟也都存在CSRF漏洞。

其余，要利用NMAP等各种工具扫描设备开放的端口，看看有没有什么做事存在已知漏洞。

第三，设备登录入口必须支持连续登录失落败X次后拦截登录要求的功能，防止被爆破。

第四，设备web端会利用类似jQuery等库，而第三方库是有各种已知漏洞的，查到CVE后逐个验证下漏洞是否存在。

第五，开个WVS扫一扫页面吧，看看有没有什么明显的漏洞。

0X08 自学习

商业WAF比较自研WAF，最大的上风在于自学习功能。
商业WAF拥有多项专利技能，可以根据web运用的访问行为和流量，自动学习用户正常访问行为特色，据此建立防御策略。
Imperva在这方面技能领先很多，专利也最多。
如果用好了自学习功能，WAF的漏过能够很大程度上的改进。

但是，凡事没有绝对。
WAF的自学习功能最大的困扰是误报。
Web运用的功能非常繁芜，要求办法千奇百怪，机器学习算法再精妙，也不可能百分百还原所有用户正常行为。
一旦误判，大量的误报拦截会让管理员叫苦不迭。

实际测试下来，个人觉得自学习功能更多时候是厂商拿来做宣扬的噱头和控标的一个指标项，但是实际在生产环境中利用它，最好还是慎之又慎，就连厂商工程师都不建议利用，你敢给领导打保票背这个雷吗？

但是自学习功能并非是聋子的耳朵--摆设。
自学习最大的用途实在是剖析用户行为的工具。
用这个功能连续监控一个月之后，哪个URL被访问次数最多，用户的要求方法与行为是什么，可以通过自动报告一览无余。
有了这个报告，后续在做Web运用调优、访客行为剖析、判断误报等方面还是很有用的。

0X09 第三方测试工具

除了上述各种手工测试项目，还可以利用第三方开源工具测试WAF的拦截能力。
这里推举两个工具。

第一：碳基体的测试工具：[项目地址]

这款工具是用perl写的，在t文件夹下已经写好了很多测试脚本，这些脚本可以把攻击payload放在http协议的各个字段提交，用于测试WAF在不同http参数的识别能力。
详细用法不多说了，碳基体写的非常清楚。

这里想说两点：

1. X-Forwared-For是很多WAF会漏过的点。

2. 没有哪家WAF可以百分百拦截所有测试脚本。
换句话说，测出来漏过的地方，须要WAF上手工配置策略，白帽子们也可以在渗透时自由发挥了。

第二：Ironbee项目：[项目地址]

Ironbee是一款开源waf，这个项目是测试拦截率的攻击，也是用perl写的。
同样的，baseline-detection目录下的脚本，也不是默认策略可以百分百识别的。

0X10 管理与掩护

WAF除了要知足低误报低漏报，还必须人性化易管理。
下面的几个功能点，是从管理员角度出发测试的内容。

设备操作日志：WAF的所有管理员操作必须留存日志备查。

管理员权限分割：管理员必须不能删除和操作设备日志，管理与审计权限必须分立。

误报后的快速例外：WAF会涌现超过50%的误报，涌现误报后，设备必须支持快速且简便的例外策略天生。

日志包含完全http的request和response，高亮显示违规内容。

日志可导出：WAF的日志必须支持以标准syslog格式导出，既可以与SIEM联动，也可以让管理员手工剖析。

多种形式的报表展现：包括但不限于自定义源地址、目的地址、攻击手腕、规则、日期韶光等条件的自由组合天生报表。

流量可视化展现：统计每个站点流量、统计指定源的流量、统计点击次数，可视化展现。

0X11 写在末了

写这篇文章的初衷，绝非为某个品牌站台，或者贬损某个品牌。
我在写作的过程中只管即便避免带有个人感情色彩，只管即便保持对品牌的中立性。
任何WAF都是浩瀚开拓职员的辛劳结晶，每家都有自己独到的地方，也难免存在疏漏。
希望通过甲方安全职员的和厂商研发职员的共同努力，把WAF完善的更好更易用。

受限于自己技能能力，测试方法和测试内容难免有遗漏或缺点，希望读者反馈示正，本人博客：www.lewisec.com。