记一次绕过国内安全厂商某亭WAF

据了解,某亭的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。

如果有疑问,或者哪里有不对的地方,留言就行。

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180109G0C8LY00?refer=cp_1026

扫码关注云+社区