前言

做项目时，遇到了一个形式上，但是存在自定义的waf拦截，本篇简单的讲下我的绕过思路。

XSS发现

这个xss的发现很简单，就直接加上">就能直接看出来是存在XSS的了

绕过思路

后续的正常思路就直接输入"><img src=1 onerror=alert(1)>，然后G掉

所以能够意识到是存在waf拦截的，我们上面输入的XSS语句太明显了，被检测出来了，所以需要考虑怎么绕过。
在XSS的绕过中，我一般是倾向先慢慢删，把payload删到不拦截为止，所以我直接删完了
通过尝试发现<img就直接被拦截，所以尝试更换使用<image>可以，然后就正常的向后构造，直到构造到这里<image src=| onerror=alert(1)//>又G了

通过把alert删除后发现能够正常访问

所以我们需要考虑怎么把alert绕过去

函数替换

首先第一思路肯定是用confirm或者prompt替换，然后发现全都过滤了

编码绕过

一般编码绕过我都只尝试Unicode编码，将prompt编码为pr\u006fmpt，结果还是被拦住了

混淆绕过

在一般的waf拦截中，大多都是采用的正则的方式进行匹配，一般不会是只要某个字符出现就拦截，所以我们在绕过waf的时候可以考虑混淆

比如这个代码

this[`al`+/ert/.source](1)

制作一个alert函数来进行弹窗，这种构造在面对正则的匹配时一般是能绕过去的，所以当我输入这个payload时很明显的发现自动的给我们的payload改动了一些，导致弹窗失败

后续尝试这种构造也是存在上面的这个问题，我们输入的payload会被改动，在最后会有个=

window['a'+'l'+'e'+'r'+'t'](123)

所以这条路就只能宣告暂时无法走通了

反思

目前大致尝试了多种方法，均无法利用，所以后续能够考虑的比较有效的思路就只有两种了

1. 模糊测试，FUZZ看看有没有什么特殊字符能够拼接然后绕过

2. 对上面的混淆绕过重新考虑利用方式

由于我使用的是热点，在简单的FUZZ后，发现效率很慢，所以转变思路在混淆绕过上面了。
跟具我多次的尝试，发现当我们输入的paylaod中带有如下等符号时，会自动的在最后给我们加上一个=或者是直接删除掉我们的特殊符合等，导致我们的payload失效

' " ` /

所以后续的考虑点就变成了，不用任何特殊符合的混淆，且网站对编码进行了严格的检测，所以还不能使用编码来混淆。
所以使用top对象，转30进制，构造paylaod为:

top[8680439..toString(30)](document.cookie)

最后成功弹窗

最后

这个waf属于自研的，比较简单，在日常遇到的waf中，通用的思路还是在上面的方法走不通后，还是倾向于去FUZZ特殊字符比如这种: