（免責聲明：這幾天有點燒起來了 文長會短一點）

RFC 7541

我們先來看一個正常的 HTTP 封包：

GET / HTTP/2
Host: blog.whale-tw.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
X-Forwarded-For: 127.0.0.1
Cookie: sessionId=whale_sess_7768616c65313230; theme=dark; userLanguage=zh-TW; last_search=how+to+hack+NASA+?

假設今天使用者要瀏覽一個 Blog 網站，只要他是個人類而不是爬蟲，就算 Cookie/User-Agent 等 Header 再大也不過就幾 KB/每 （秒　甚至　分鐘）
ㄟ～但如果打開像是 Facebook/Discord 這樣的社群平台呢？
我們 F12 戳一下：
打開網站不到十秒就有 918 requests xD
當中可能包含許多靜態資源、動態地訊息/狀態抓取等等。

但網站又不可能不去驗證使用者身分就提供那麼多資訊，現代網站也會有許多 Ad Trackers/Loggers 做資料分析，這些全部都會帶上各式各樣的 HTTP Headers 一起請求，這對伺服器的負擔就會大大加重。

因此 HTTP/2 引入了 HPACK (RFC 7541) [1] 壓縮協議。HPACK 不是單純像 gzip 那樣對整個 Payload 壓一次，而是採用了兩張表：

1. Static Table（靜態表）：預先定義了 61 個最常見的 Header（如 :method: GET、:status: 200 等），雙方連線時就已經存在。
2. Dynamic Table（動態表）：在單一 TCP/TLS 連線期間，雙方各自維護一張 FIFO 的記憶體快取表。當 Client 送出一個新的 Header 時，可以指示 Server "請把這個鍵值對存入動態表"。後續請求如果需要重複使用，只要傳送一個微小的整數索引（Index）即可。

而這張 HPACK 動態表有最大容量限制（通常由 SETTINGS_HEADER_TABLE_SIZE 控制，預設 4096 bytes），為了防止 DoS，看似非常正確！對吧對吧？

沒錯！不過其實有時候漏洞不會只從一個角度進入

同學～越界囉

考古

在看到 "表"(table)、"索引"(index) 這樣的關鍵詞時，作為一個漏洞研究員我們一定要去想的漏洞是 OOB (越界讀寫)。
攻擊者可能可以透過輸入大於當前索引最大值/負數等數字來存取記憶體上超出表範圍的其他內容。

沒錯！Hpack 歷史上像是 HAProxy 就出過 OOB 的漏洞：

• CVE-2018-14645: HAProxy HPACK OOB Read [2]
• CVE-2020-11100: HaProxy HPACK OOB Write [3]

另外還有看到蘋果開源的 SwiftNIO[4] 在 HPACK Side 發生過 Interger Underflow （CVE-2022-24667）。

相信應該還有些 Embeding/Edge IoT Devices 上面在 HPack 表或各個 HTTP 封包 Parsing Components 有類似漏洞吧...？

References

• [1] https://www.rfc-editor.org/info/rfc7541/
• [2] https://github.com/advisories/GHSA-gr9c-vx25-2fh5
• [3] https://github.com/advisories/GHSA-3xcv-57q9-hrj2
• [4] https://github.com/apple/swift-nio