Cloudflare 用 LLM 變異攻擊測自家 WAF，SSRF 缺口變成三項規則更新
Cloudflare Blog · 2026-09-29 · Vikram Grover、Daniele Molteni、Kuber Nandwani
Cloudflare 不再只靠固定的攻擊字串清單驗證 WAF，而是讓 LLM 扮演黑箱攻擊者，看到「被擋」就換編碼、換位置再送一次。這套自適應測試在一個已授權的客戶 staging 環境上跑了 1,107 次嘗試，最後產出的規則更新集中在 SSRF。
原本的問題
靜態測試清單只能驗證「已知的寫法有沒有被擋」，而 LLM 擅長的正是根據即時回應快速變異 payload：換編碼、把輸入移到請求的另一個位置、或直接轉去測下一個弱點。WAF 若只對字面寫法有效，就會被這類迭代繞過。
文章的問題意識是客戶常問的「你的 WAF 準備好面對 frontier model 了嗎」，所以團隊決定自己先攻擊自己。
測試迴圈怎麼設計
每個 scenario 固定一種攻擊類別、一個輸入位置、一個 WAF 已經擋下的起始請求，以及固定次數的嘗試。迴圈每輪呼叫 LLM 兩次：proposal call 提出下一個變體，review call 看回應狀態、部分 header 與 body 來判斷結果。
- 模型看不到原始碼、WAF 規則運算式、規則 ID、WAF Attack Score，也不知道是哪一層安全機制動作。
- 模型不直接送請求，由 Python 程式碼檢查 hostname allowlist、關閉 redirect、記錄並限制嘗試次數。
- 回應文字可能進入下一輪 prompt，因此被當成不可信輸入；模型無法部署規則或改變 enforcement。
受測 WAF 設定：WAF Attack Score 在 30 以下封鎖、啟用全部 Cloudflare Managed Ruleset，以及 Paranoia Level 3 的 OWASP Core Ruleset。共 45 個 scenario，其中 44 個涵蓋 XSS、SQLi、CMDi、SSRF、LFI 與 Log4j，另一個是 log injection，文章單獨回報。
SSRF 的一次實際繞過線索
在 SSRF scenario 中，測試器把雲端 metadata 位址換成各種寫法並放進不同請求位置。WAF 擋下了整數與八進位形式，直到 attempt 18 才出現不同結果。
| 嘗試 | 主機寫法 | 結果 |
|---|---|---|
| baseline | 169.254.169.254 | 403 block page |
| 1 | 2852039166（十進位整數） | 被擋 |
| 2 | 0251.0376.0251.0376（八進位，改用 form body） | 被擋 |
| 17 | 十進位整數，較後面的請求形狀 | 被擋 |
| 18 | 169.254.169.254.（結尾加點） | 收到 redirect，沒有 block page |
文章強調這只是一條調查線索：沒有成功的 origin 回應，也沒有證據顯示應用程式真的去抓了 metadata。它提出的具體問題是，結尾的點是否改變了 WAF 對目的地的解讀。
數字與分流
1,107 次嘗試經人工審查後，得到 558 個被擋的請求與 49 個值得調查的 WAF 相關發現，合計 607 筆有效結果。XSS、LFI、SQLi 與 Log4j 幾乎全數被擋，49 個發現中有 48 個屬於 CMDi 與 SSRF。其餘嘗試沒有計入，原因是模型沒產出可用的 HTTP 請求、請求沒到目標，或 payload 已變得無害。
一個未被擋的請求要算發現，必須通過五個檢查：請求有效、確實未被擋、仍具惡意、行為屬於 WAF 的責任範圍、工程師能安全重現。
修補：三項 Managed Ruleset 變更
發現被分成四組候選規則，在影響正常流量前先評估誤判風險。最終促成三項變更：2026-07-21 版本新增 SSRF - Obfuscated Host 與 SSRF - Restricted Protocol，以及 2026-08-04 版本改進既有的 SSRF - Cloud。其中 Obfuscated Host 直接來自把內部位址寫成非標準數字形式的請求。
影響範圍
Cloudflare WAF 客戶：先確認 Managed Rules 與 WAF Attack Score 確實掛在應用程式前面。文章建議先以 log 模式跑 Managed Rules，在 Security Events 確認正常流量不受影響，再切換為 block；也可以請 account team 開啟 Attack Signature Detection。
自己做應用安全測試的團隊：測試應打在與正式環境套用相同 Cloudflare 控制的 staging hostname 上。這次測試還用了 allowlist 過的 test User-Agent，避免客戶的自動化流量控制在請求抵達 WAF 前就先擋下。
設計 LLM 紅隊工具的人：文章的觀察是，同一模型家族的兩個版本產生不同的變體，但暴露出相同的底層問題；單一 scenario 接近 25 次上限時開始重複舊點子，擴大起始請求、攻擊類別與輸入位置比拉長單一序列更有效。模型只負責產生請求，哪些算數仍由人決定。
WAF 只是其中一層：繞過 WAF 的 payload 仍需要可被利用的應用程式才會成功，所以更新軟體依然是基本防線。文章預告下一篇會公布模型同時知道應用弱點與 WAF 規則的 white-box 測試結果。
原始來源：Cloudflare Blog、WAF changelog 2026-07-21、WAF changelog 2026-08-04