WAF bypass总结

previous page next page

1：数据流向：

如下图所示：

描述了从浏览器敲下URL到请求最终发送到web服务器，中间经历了多少设备，哪些地方经过了处理，哪些地方没有经过处理。

经过公网的时候，公网一般都是一些工作在网络层的设备，这些设备基本做路由转发，不会对于数据包进行应用层处理的。在到达目标服务器之前，可能会有一些防护设备，如云waf，又如硬件waf，ips，ids设备，这些设备会对于数据包进行处理，因此在此处针对于一些应用层的防护设备应该有 bypass的姿势，为第一个角度。数据包会发送到终端，终端会有windows和linux之分，同时不同操作系统上也会安装不一样的主机防护，如 safedog，因此针对此类主机防护可能也会有bypass的姿势，为第二个角度。经过主机防护的包会发送到web服务器，web服务器也有很多种，如常见的apache和iis等。因此针对于web服务器也会有bypass的姿势，为第三个角度。web服务器的数据流会被发布在web服务器上的应用程序处理，针对于应用程序同样也会有bypass的姿势，为第四个角度，web程序处理的过程中会与数据库交互，不同的数据库有不同的特性，应此对于不同的数据库同样会有bypass的姿势，为第五个角度。

2：waf以及主机防护bypass

现在市面上各种waf与主机防护，如百度云加速，阿里云盾，加速乐，安全宝，安全狗，云锁，360网站卫士等等，总结补充下：
1）：修改请求的方式，请求的内容一般分为get，post以及cookie的方式，还有自定义LOL,FUCK，post下又会有urlencode以及form-data<二进制？>的提交两种
2）：截断字符的利用
3）：关键字url编码的利用
4）：脏数据的添加，即添加无效数据，有可能超过最大的检测长度，而导致bypass，
5）：fuzz测试，这里我一般会每一种请求方式均fuzz一次，这里fuzz的地方，主要是有可能waf之类的设备处理某些字符不当导致了bypass。
6）：对于waf类的其实找到原始IP直接访问，也是一种bypass的方法。 <尤其适用于云端>

3：webserver端的bypass姿势

webserver常见的iis，apache以及tomcat等等
我见到过的可能可以利用的：
1）：iis在asp程序处理中，对于%处理的不是太好，貌似直接显示空白了
2）：iis在aspx程序处理中对于%u00处理的不是太好，貌似直接显示空白了
3）：iis加asp环境下的复参攻击，在如下连接中有参考：
4）：apache服务器对于畸形请求的解析,此处没有考证，漏洞连接
WooYun: 安全宝SQL注入规则绕过
http://www.80sec.com/%E6%B5%85%E8%B0%88%E7%BB%95%E8%BF%87waf%E7%9A%84%E6%95%B0%E7%A7%8D%E6%96%B9%E6%B3%95.html

4：web程序端bypass姿势

web程序一般运行在webserver上，web程序在获取参数如果选择方式不正确可能造成bypass：
1：asp asp.net中获取参数如果使用的Request['']的形式的话，可以使用畸形的请求，如一个GET请求，同时还发送了post部分的内容
2：之前说到更换提交方式绕过的其实需要此处web程序的支持，如常见的dedecms就会支持get post以及cookie的提交。

5：数据库端的bypass姿势

数据库端的bypass大多是利用了数据库的特性，数据库有mysql,mssql,oracle等等
其实数据到最后在数据库被执行了才算是真正的bypass，因此直接从数据库特性去测试一般是最有效的：
mysql的特性，<见文档>
1）：空白符的利用（之前有人做过空白符的测试）【http://zone.wooyun.org/content/15953】

SQLite3 0A 0D 0C 09 20 
MySQL5 09 0A 0B 0C 0D A0 20 
PosgresSQL 0A 0D 0C 09 20 
Oracle 11g 00 0A 0D 0C 09 20 
MSSQL 01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F,10,11,12,13,14,15,16,17,18,19,1A,1B,1C,1D,1E,1F,20

在数据库中的空白符可能和php或者其他的web程序端的空白符存在差异，这样的差异可能就会导致绕过正则或其他防御的绕过。

2）：利用数据库fuzz测试，如： <[]貌似不行>

select * from dual where id =1[]union[]select[]1,2,3,4 from[]m,

经大量测试发现select[]位置处的fuzz成功？，往往可以bypass大量防御规则。

previous page start next page