前言-基礎篇

在了解Bypass Waf之前，我們應該首先了解一些前置知識：

1.Waf是什么

2.Waf的類型

3.Waf的工作原理

1. Waf是什么

Waf全稱為Web Application FireWall（Web應用防火墻）；顧名思義Waf原理與日常使用防火墻相似，但主要注重在Web頁面中存在的對應安全問題。

2.Waf的類型

WAF分為非嵌入型WAF和嵌入型WAF。

非嵌入型是指硬WAF、云WAF、軟WAF之類。

嵌入型是指web容器模塊類型WAF、代碼層WAF。

3.Waf的工作原理

不論是什么類型的Waf，工作的方式幾乎差不多。首先，從用戶體驗上出發，用戶的目的是部署Waf從而解決對應的WEB安全問題；所以對于Waf開發來說，需要了解的就是：哪些位置可能會引發安全漏洞、如何判斷攻擊者利用攻擊觸發了漏洞。

回顧一下TOP 10的安全漏洞，我們可以得到一個結論，Web漏洞產生的位置基本都為：

1.HTTP頭部字段

2.GET、POST提交的內容

3.上傳的文件

所以，我們也可以逆推得到Waf構建及工作的原理大致為：

1.構建各種漏洞利用的攻擊特征庫

2.對漏洞產生位置的內容進行搜集

3.將搜集的內容在特征庫中進行匹配，查看是否存在攻擊特征并作出相應

更詳細的工作流程如下圖所示：

建立特征庫的流程：

判斷惡意攻擊流程：

繞Waf實戰

了解完Waf是怎么攔截對應的流量之后，我們就明白了繞Waf的最終目標是繞過特征庫檢測（即繞過正則匹配）。

那如何繞過正則匹配呢？

主要的方式就兩種：

1. 通過Fuzz腳本構造大量Payload進行嘗試

2. 通過人為手工探測Waf編寫規則。

第一種方式比較暴力，且針對初學者并不是很友好，因為需要很多之前師傅們繞Waf的Payload作為前置知識。

基本思路大致是：對繞過的方法進行搜集構造一些經常繞Waf的字符串，并且利用腳本在漏洞點構造語句+繞Waf字符串+垃圾字符等Payload，通過跑大量Payload的方式爆開可以繞Waf的Payload。

很好，所以我們介紹第二種方法。

相關資料獲取可私信回復“資料”

**前置知識：**由于Waf需要盡量滿足客戶需求，Waf的匹配規則通常會匹配的很詳細進而減少誤報。

以某安全廠商的Waf產品的規則為例：

那我們就可以通過手工一步步探測Waf的過濾規則是什么，從而進行繞過。

【領取文檔】

如何進行手工探測Waf的過濾規則-實戰篇

以下測試均為授權滲透測試：

探測規則1

在頁面發現一處富文本編輯器，并且該內容提交后會顯示在對應頁面上，這里第一個想到的就是XSS了。

先整個最簡單的XSS的Payload試試，抓包看現象：

發現輸入的標簽會被HTML實體化編碼，所以每次構造Payload時需要解HTML實體。

從回包的狀態碼403和Server值可以判斷是被Waf攔截了。

那么這時如果我們想要繞Waf的話，就要去思考它對應的正則匹配的規則可能存在的情況了：

1.匹配script

2.匹配alert

3.匹配<.*?>

4.匹配

注：.?表示非貪婪比配，可以匹配任意字符，直到下一個字符出現為止。例如：<.?>可以匹配<符號開頭、后面可以有任意字符直到匹配到>為止。

大致推出比較有可能的就是這集中情況，那我們就可以進行一一驗證：

script

alert

<(.*?)>

可以發現，攔截的關鍵字為

探測規則2

既然可以構造img標簽，那也拿img的XSS Payload淺測一下：

好了，又被攔了。首先大致能排除的問題，出于穩健的心理淺測一下：

說明構造的Payload里面被攔截的特征為：οnerrοr=alert(123)。

那就再簡單猜測一下對應的Waf規則吧：

1.匹配οnerrοr=

2.匹配alert(.*?)

3.匹配on.?=alert(.?)

4.匹配on.?=.?alert(.*?)

一一驗證：

οnerrοr=

攔了οnerrοr=應該也攔了其他的on事件，簡單嘗試一下：

那on事件幾乎就是無了，得思考思考怎么繞。

alert(.*?)

看來也被攔截了，那只能試試換prompt(123)或alert123

均已失敗告終…所以下面兩個on.?=.?alert(.?)和on.?=alert(.*?)也無需測試都會被Waf攔截。

alert最簡單的繞過方式就是換函數了，但是常用的彈窗函數都被禁用了，貌似已經有點困難了；但是突發奇想：研發是否會不會只過濾了常見的彈窗函數，拿document.location.href=xxx試試：

沒攔截這個函數呀，所以并不是所有函數都被攔了，而是常用的alert()、prompt()、confirm()被攔截了。

所以要么換函數，要么強行繞alert函數（我喜歡硬剛，就沖alert了！）

我發現貌似這樣判斷alert是否被過濾不太嚴謹，應該重新判斷一次：

故試了試如下Payload：

意外發現竟然沒有攔截？所以前面alert(.*?)判斷的匹配規則不對，匹配中的應該為?alert(123)，前面可能有內容才會匹配

xxalert沒有攔截，那說明過濾的應該是特殊符號，這時上波Fuzz爆破一下，發現只有:和是被攔截的，也就是說，不能使用:alert(123)和?alert(123)

探測規則3

先總結一下前面兩波手工探測的成果：
1.過濾了

這樣就可以執行JS代碼了，但是沒什么用…所以還是要想辦法彈窗，但是又必須要繞過:alert(123)等。

靈機一動，Payload就來了！alert()函數是JS BOM的函數，為了調用方便被簡寫成alert()，而正規的調用方法為window.alert()。那這樣Payload就有了：

test

頁面點擊鏈接看現象：

以上漏洞已報送至對應廠商。

總結

以上是生活随笔為你收集整理的【安全漏洞】浅谈Bypass Waf （基础-实战）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。