据了解,某亭的WAF是基于机器学习的,设备也非常贵,在一次偶然测试中碰上了,测试时还不知道,绕过之后才发现系统上了WAF。这也属于一次盲打的过程吧,写这篇文章是为了记录下。
过程大概如下
一,利用二次提交将Self-XSS提升到高危XSS
最开始,系统并没有上WAF之类的安全设备,测试发现系统存在存储型XSS,但是前端访问时时不触发的,通过查看源码发现都转义了,但是重新返回编辑时候,却触发了XSS,整体看起来就是一个Self-XSS。
前端访问
重新进入编辑
但是这个时候,如果我们将此时编辑下的内容(包含Self-XSS Payload)重新进行提交,会发现重新访问前端时,竟然触发了XSS。
二次访问触发
出现这种问题的原因,看文章的小伙伴可以开始你们的想象了
二,从所谓的部署WAF修复漏洞到绕过WAF检测
上面的问题报上去后,第二天跟我说漏洞修复了,让我再检测检测,OK再看看,通过插入些伪标签,诸如的东西,发现其实系统本身并没有修复,然后尝试插入Payload,发现怎么都不能触发,看源码看到Payload时候,讲道理是完全没问题的可以妥妥的触发,但是就是不行。
不断的编码尝试,字符切割等等,最后发现,通过UTF-32的编码,竟然前端输出了之前一样的Payload,而且成功的触发了。
不解,通过跟系统管理员了解到,原来系统上了国内某亭的WAF,通过查看WAF后台的拦截日志信息,原来之前的Payload都被拦截了,而且也都告警了。但是怎么也没找到UTF-32编码后触发漏洞的拦截信息。
到此可以断定,Payload完全的绕过了。
最终的检测Payload如下:
%00%00%00%00%00%3C%00%00%00s%00%00%00v%00%00%00g%00%00%00/%00%00%00o%00%00%00n%00%00%00l%00%00%00o%00%00%00a%00%00%00d%00%00%00=%00%00%00a%00%00%00l%00%00%00e%00%00%00r%00%00%00t%00%00%00(%00%00cookie%00)%00%00%00%3E
出现这个情况,猜测是WAF对于这类的编码规则并没有学习到,自然也就不能识别到这类的攻击Payload。
如果有疑问,或者哪里有不对的地方,留言就行。
领取专属 10元无门槛券
私享最新 技术干货