作者: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,感觉太惨淡了。如果读者觉得我的文章有帮助,就希望能在公众号"点赞、在看、分享","点赞"和"在看"似乎也能增加一些曝光量。要不然文章就只能关注的人才能看得到。


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