Black Hat USA 2025 | HTTP/1.1 Must Die! The Desync Endgame
三句話摘要
James Kettle 在 Black Hat 揭露 HTTP/1.1 請求走私（Desync）攻擊已進入「終局」——偵測工具被正規表達式封鎖、漏洞本身從未修復，兩個全新攻擊類別波及數千萬網站，並呼籲業界全面遷移至 HTTP/2。 --- HTTP/1.1 的請求邊界缺陷從未真正修復，只要繼續在後端使用 H1，新的 Desync 攻擊就永遠不會停止——切換到 HTTP/2 upstream 是唯一根治之道。 1. 偵測被封鎖，漏洞仍存在
重點整理
重點- 1
1. 偵測被封鎖，漏洞仍存在
- 2
過去六年間，業界用正規表達式攔截含 `Transfer-Encoding` 的探測請求，有效封鎖了所有主流掃描工具，但 Desync 本身的根本原因——HTTP/1.1 請求邊界模糊——從未在伺服器層真正修復，形成一個「表面安全、實則危險」的終局狀態。
- 3
2. 微小的方法論錯誤反而能挖出更嚴重的漏洞
- 4
Cloudflare 的案例中，研究者因「忘記加 cache buster」這個操作失誤，意外觸發了 Cloudflare 內部 H2→H1→H2 轉換流程中的 Desync，使攻擊者可持久性劫持使用 Cloudflare 的 2,400 萬個網站，說明在 Desync 終局中「正確做法」反而找不到漏洞。
- 5
3. ZCL Desync + Double Desync 開創新攻擊類別
- 6
傳統上 Zero Content-Length Desync 被認為不可行（後端會因等待 body 而 deadlock）。研究者發現利用 IIS 的 `/con` 裝置路徑可讓伺服器提前回應，破解 deadlock；再搭配 Double Desync（攻擊者的第二個請求作為武器化中介）即可對受害者執行完整帳號劫持。
- 7
4. Expect header 是新的攻擊面
- 8
`Expect: 100-continue` 在 proxy 層引入有狀態處理，導致大量邊緣案例：memory leak、洩露內部 header、ZCL Desync 及 Response Queue Poisoning，波及 T-Mobile、GitLab、Netlify、Akamai 等平台，根本原因均源於 HTTP/1.1 的協定設計缺陷。
- 9
--
實用技巧與重點
乾貨- 數字與獎金
- Cloudflare Desync 影響：2,400 萬個網站
- T-Mobile Expect Desync 單一預生產伺服器：$12,000
- GitLab 附件伺服器 Response Queue Poisoning（27,000 請求後取得他人私密漏洞報告）：$7,000
- Akamai CDN Desync（透過各廠商分別回報）：團隊總計超過 $200,000；Kettle 本人向 Akamai 直報：$9,000
- 本次研究累計獎金：超過 $350,000
- Akamai 從收到報告到完全修復：65 天
- GitLab 的 Response Queue Poisoning 需發送至少 27,000 個請求才成功
- 工具與平台
- HTTP Request Smuggler v3（開源 Burp Suite 擴充套件，相容 Pro / DAST / Community Edition）
- Turbo Intruder（Kettle 自製 HTTP 客戶端，Expect header 會直接將其崩潰）
- Portswigger Web Security Academy（新增 ZCL Double Desync 免費練習 Lab）
- 參考資源：http1mustdie.com
- 不支援 H2 Upstream 的主要 CDN
- Nginx、Akamai、CloudFront、Fastly（截至報告時）
- 攻擊技術名稱
- CL.0 Desync（Content-Length 為零）
- Zero Content-Length (ZCL) Desync
- Double Desync（兩階段鏈式攻擊）
- Response Queue Poisoning
- H2.TE Desync / H2.CL Desync
- Hidden-Visible / Visible-Hidden 解析差異
- Early Response Gadget（IIS `/con` 裝置路徑技巧）
- 漏洞觸發條件
- IIS + 特殊 Windows 裝置路徑（`/con`、`/aux` 等）→ 提前回應，解除 body deadlock
- `Expect: 100-continue` → 讓 proxy 忘記尚未收到 body，觸發 ZCL Desync
- Akamai Desync 完全在 Akamai 內部基礎設施中發生
- 修復建議
- 後端啟用 HTTP/2 Upstream（前端→後端連線）
- 定期使用 HTTP Request Smuggler v3 掃描
- AWS ALB：修改兩個 Load Balancer 設定即可解決 IIS 解析差異
- --
結論
結論“HTTP/1.1 的請求邊界缺陷從未真正修復，只要繼續在後端使用 H1，新的 Desync 攻擊就永遠不會停止——切換到 HTTP/2 upstream 是唯一根治之道。”
完整解析
詳細HTTP/1.1 自誕生以來便有一個結構性缺陷：協定本身沒有單一可靠的方式界定兩個請求之間的邊界。James Kettle 自 2019 年起持續研究這個問題，並在 PayPal 登入頁面等高知名度目標上展示了 Desync 攻擊的威力。理論上的解法早已明確——前後端之間改用 HTTP/2 upstream，即可消除長度歧義——但六年後的今天，業界的實際反應卻是在邊緣用正規表達式攔截含特定 header 的探測請求。這讓偵測工具集體失效，卻讓漏洞本身原封不動地留在伺服器裡，形成 Kettle 所稱的「Desync 終局」：表面上一切看起來安全，但只要稍微調整方法論，就會發現觸目驚心的問題。
Cloudflare 案例完美詮釋了終局的荒謬性。研究者 Vans 在測試時因為「忘記加 cache buster」這個操作失誤，竟意外觸發了 Cloudflare 內部將請求從 H2 轉 H1 再轉回 H2 的流程中的 Desync，使任何測試 Cloudflare 網站的人（只要不加 cache buster）都能持久劫持使用 Cloudflare 的 2,400 萬個網站。Kettle 試圖複製攻擊時「修正了錯誤」，反而讓攻擊失效——正確的做法讓他什麼都找不到，錯誤的做法卻差點釀成史上最大規模的 CDN 劫持事件。
為了突破正規表達式的封鎖，Kettle 釋出了 HTTP Request Smuggler v3，核心思路是改用 Host header 的變形（加前綴空格、插入重複且格式錯誤的 Host）作為偵測探針，完全迴避了現有 WAF 規則的攔截。同一工具也引導研究者發現了 ZCL（Zero Content-Length）Desync 這個過去被認為「理論上不可行」的新攻擊類別。傳統上，當前端不看 Content-Length 時，後端會因無限等待 body 而 deadlock。Kettle 發現 Windows IIS 對 `/con` 等裝置路徑會提前回應、不等 body，這個存在超過十年的 Windows 小知識成了打破 deadlock 的關鍵。搭配 Double Desync——用第一個請求觸發 ZCL，再用第二個請求作為中介武器化——即可在不依賴受害者自身請求內容的情況下，對第三方用戶執行完整的 JavaScript 注入與帳號劫持，每秒需發送數百個請求以克服 race condition。
最後一個攻擊類別來自 Expect header。這個古老的 HTTP header 原本設計用來讓客戶端在伺服器不支援時提前中止上傳，卻因為在 proxy 層引入了有狀態的兩段式處理流程，在大量伺服器中觸發了記憶體洩漏、內部 header 暴露、ZCL Desync 及 Response Queue Poisoning。T-Mobile 的預生產環境、GitLab 的附件伺服器（內含其他研究者送交的私密漏洞報告）、Netlify 整個 CDN 以及 Akamai 的基礎設施全數受到波及。尤其 Akamai 的案例中，研究合作夥伴透過各家廠商的漏洞回報計畫累計獲得超過 20 萬美元，而 Akamai 從收到回報到完全修復耗時 65 天，凸顯了 CDN 層漏洞的修復複雜度。
Kettle 的結論明確：所有這些漏洞雖然是實作層面的 bug，但根本原因是 HTTP/1.1 的協定設計——前後端之間的請求隔離從根本上就是破碎的，且無法在不破壞舊版客戶端的前提下透過前端正規化來安全修復。唯一的出路是在前後端之間啟用 HTTP/2 upstream；目前 Nginx、Akamai、CloudFront、Fastly 均尚未支援此選項，使大量網站暫時無路可退。在等待 H2 普及的過渡期，定期以 HTTP Request Smuggler v3 掃描並持續修改工具以對抗新一波正規表達式封鎖，是現階段最可行的防禦策略。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
