近期安全研究人員發現了一項名為 HTTP/2 Bomb 的遠端拒絕服務（DoS）漏洞，該漏洞影響範圍極廣，包括 NGINX、Apache HTTPD、Microsoft IIS、Envoy 以及 Cloudflare 的 Pingora 等主流 Web 伺服器。這項漏洞的核心在於將兩種已知的攻擊技術結合，讓攻擊者能以極低的成本消耗伺服器巨大的記憶體資源。
理解 HTTP/2 Bomb 的技術背景
要理解這個漏洞，首先要認識 HTTP/2 的兩個關鍵機制：HPACK 與流量控制（Flow Control）。
HPACK 是 HTTP/2 專用的標頭壓縮演算法。在 HTTP/1.1 中，標頭是以純文字傳輸，重複性極高且浪費頻寬。HPACK 透過 Huffman 編碼與動態表（Dynamic Table）來減少重複內容，將傳輸量降低約 30%。
流量控制則是 HTTP/2 用來管理資料傳輸速率的機制。伺服器會告訴客戶端目前還能接收多少資料（即 Window Size），如果伺服器將視窗設為零，客戶端就必須停止傳送資料，直到伺服器重新開放視窗。
HTTP/2 Bomb 的攻擊原理
傳統的壓縮炸彈（Compression Bomb）通常是傳送一個極小的壓縮檔，解壓縮後變成巨大的檔案，導致伺服器記憶體耗盡。為了防禦這種攻擊，現代伺服器通常會設定解壓縮後的最大長度限制（Decoded-size limit），一旦超過限制就中斷連線。
然而，HTTP/2 Bomb 採取了完全不同的策略。它不再嘗試讓解壓後的內容變得巨大，而是利用伺服器在管理標頭條目時產生的簿記開銷（Bookkeeping overhead）。
簡單來說，攻擊者傳送大量近乎空的標頭，雖然解壓縮後的實際內容很小，不會觸發伺服器的長度限制，但伺服器為了管理每一個標頭條目，必須在記憶體中配置一定的管理空間。當這種操作重複數千次時，伺服器會分配出大量的記憶體來維護這些空條目。
更致命的是，攻擊者隨後會利用類似 Slowloris 的技巧，將流量控制視窗設為零（Zero-byte flow-control window）。這會讓伺服器認為請求尚未完成，因此無法釋放先前為該連線配置的記憶體。
攻擊影響與實務衝擊
這種攻擊方式具有極高的放大倍率。研究顯示，一名使用 100Mbps 家用網路的攻擊者，可以在數秒內讓受影響的伺服器癱瘓。在針對 Apache HTTPD 和 Envoy 的測試中，單一客戶端在 20 秒內就能強行佔用伺服器約 32GB 的記憶體。
這揭示了一個深層的設計缺陷：目前的 HTTP/2 規範過於關注壓縮比（Amplification Ratio），而忽略了記憶體釋放的時機。如果記憶體能在請求完成後立即釋放，即使有 70 倍的放大率也無大礙；但當客戶端能以極低成本將連線長時間掛起（Pinning），記憶體就會被持續佔用直到崩潰。
建議修復與緩解措施
目前各家廠商的應對進度不一，工程師應根據所使用的伺服器採取以下措施：
NGINX 使用者請升級至 1.29.8 或更高版本，新版本引入了 max_headers 指令（預設 1000 個），用以限制單個請求的標頭數量。若無法立即升級，建議暫時關閉 HTTP/2 功能。
Apache HTTPD 使用者請更新 mod_http2 至 v2.0.41 或更高版本。若無法升級，可將 Protocols 設定為僅支援 http/1.1 以規避風險。
Microsoft IIS、Envoy 與 Cloudflare Pingora 方面，在研究公布之初尚未提供正式補丁，建議密切關注官方更新並監控伺服器記憶體使用異常。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。