浅谈Bypass Waf – 下（实战篇）

文章来源｜MS08067 Web漏洞挖掘班 第3期

本文作者：Hi2x（Web漏洞挖掘班讲师）

以下测试均为授权渗透测试：

探测规则1

在页面发现一处富文本编辑器，并且该内容提交后会显示在对应页面上，这里第一个想到的就是XSS了。

先整个最简单的XSS的Payload试试，抓包看现象：

发现输入的标签会被HTML实体化编码，所以每次构造Payload时需要解HTML实体。

从回包的状态码403和Server值可以判断是被Waf拦截了。

那么这时如果我们想要绕Waf的话，就要去思考它对应的正则匹配的规则可能存在的情况了：

1.匹配script

2.匹配alert

3.匹配<.*?>

4.匹配<script>

5.匹配<script>.*?alert.*?</script>

注：.*?表示非贪婪比配，可以匹配任意字符，直到下一个字符出现为止。例如：<.*?>可以匹配<符号开头、后面可以有任意字符直到匹配到>为止。

大致推出比较有可能的就是这集中情况，那我们就可以进行一一验证：

script

alert

<(.*?)>

<script>

可以发现，拦截的关键字为<script>，则第五种情况无需测试，因为构造的字符串存在<script>,一定会被规则匹配中。
那么该规则过滤了<script>标签，我们就可以思考通过其他标签构造XSS，例如<img>等。

探测规则2

既然可以构造img标签，那也拿img的XSS Payload浅测一下：

好了，又被拦了。首先大致能排除<img src=xxx>的问题，出于稳健的心理浅测一下：

说明构造的Payload里面被拦截的特征为：onerror=alert(123)。

那就再简单猜测一下对应的Waf规则吧：

1.匹配onerror=

2.匹配alert(.*?)

3.匹配on.*?=alert(.*?)

4.匹配on.*?=.*?alert(.*?)

一一验证：

onerror=

拦了onerror=应该也拦了其他的on事件，简单尝试一下：

那on事件几乎就是无了，得思考思考怎么绕。

alert(.*?)

看来也被拦截了，那只能试试换prompt(123)或alert`123`

均已失败告终...所以下面两个on.*?=.*?alert(.*?)和on.*?=alert(.*?)也无需测试都会被Waf拦截。

alert最简单的绕过方式就是换函数了，但是常用的弹窗函数都被禁用了，貌似已经有点困难了；但是突发奇想：研发是否会不会只过滤了常见的弹窗函数，拿document.location.href=xxx试试：

没拦截这个函数呀，所以并不是所有函数都被拦了，而是常用的alert()、prompt()、confirm()被拦截了。

所以要么换函数，要么强行绕alert函数（我喜欢硬刚，就冲alert了！）

我发现貌似这样判断alert是否被过滤不太严谨，应该重新判断一次：

故试了试如下Payload：

意外发现竟然没有拦截？所以前面alert(.*?)判断的匹配规则不对，匹配中的应该为 alert(123)，前面可能有内容才会匹配

xxalert没有拦截，那说明过滤的应该是特殊符号，这时上波Fuzz爆破一下，发现只有:和是被拦截的，也就是说，不能使用:alert(123)和 alert(123)

探测规则3

先总结一下前面两波手工探测的成果：
1.过滤了<script>等标签
2.过滤了onerror事件
3.过滤了:alert(123)及 alert(123)
在这里，第一个规则我们可以使用<img>或者<a>，比较好绕过；第二个规则再加上对<script>标签的限制比较难绕过，但仍然可以尝试使用href=javascript:xxxx伪协议绕过；但如果在第二个规则内构造伪协议，则Payload应该为：<a href=javasciprt:alert(123)>，这样的话会匹配中第三个规则:alert(123)，所以思路应该还是要换函数：

这样就可以执行JS代码了，但是没什么用...所以还是要想办法弹窗，但是又必须要绕过:alert(123)等。

灵机一动，Payload就来了！alert()函数是JS BOM的函数，为了调用方便被简写成alert()，而正规的调用方法为window.alert()。那这样Payload就有了：

<a href=javascript:window.alert(123)>test</a>

页面点击链接看现象：

以上漏洞已报送至对应厂商。

本文作者：Ms08067安全实验室

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/173213.html