HTTP Response Splitting（分割回應攻擊）是一種透過在 HTTP 標頭注入 CR/LF（\r\n） 特殊字元，迫使伺服器產生兩個獨立回應的攻擊手法。一旦成功，攻擊者可完全掌控第二個回應的內容，進而觸發 Cache Poisoning、XSS 或 Session Hijacking 等連鎖危害。
攻擊原理：CR/LF 注入如何切割回應
HTTP 協定以 \r\n 作為標頭欄位的分隔符號，以 \r\n\r\n 標示標頭結束。當應用程式將使用者輸入直接嵌入 HTTP 回應標頭（如 Location 或 Set-Cookie），且未過濾這兩個控制字元時，攻擊者可注入偽造的標頭欄位，甚至插入完整的第二個 HTTP 回應。伺服器依然回傳單一 TCP 回應，但瀏覽器或代理伺服器會將其解析成兩個獨立回應，第二個回應的內容完全由攻擊者決定。
GET /redirect?url=http://example.com%0d%0a%0d%0a<script>alert(1)</script>
# 伺服器輸出（被切割為兩個回應）：
HTTP/1.1 302 Found
Location: http://example.com
<script>alert(1)</script>連鎖攻擊：從分割回應到 Cache Poisoning 與 XSS
split-response attack 的威力在於它能作為多種攻擊的跳板。Cache Poisoning 方面，當共享代理伺服器（如 CDN、Squid）快取了被污染的第二個回應，所有後續使用者請求相同資源時都會收到惡意內容。XSS 方面，攻擊者在偽造回應中注入 JavaScript，即可繞過同源政策的保護。Session Hijacking 則透過在偽造的 Set-Cookie 標頭中覆寫受害者的 Session Cookie 來實現。三種攻擊路徑可同時存在，危害範圍極廣。
💡 重點整理
- 根本原因：使用者輸入未經過濾直接寫入 HTTP 回應標頭。
- 防禦核心：對所有寫入標頭的使用者輸入執行 CR（%0d）與 LF（%0a）字元的嚴格過濾或編碼。
- 框架防護：現代框架（如 Spring、Express）多已內建標頭驗證，應優先使用框架提供的重導向 API。
- 縱深防禦：搭配 CSP 標頭與 HttpOnly Cookie 可有效限制連鎖攻擊的實際危害。
HTTP Response Splitting 看似古老，卻仍潛藏於自行拼接標頭的舊式程式碼中。永遠不要信任使用者輸入，在標頭寫入前完成驗證，是杜絕此類攻擊的唯一根本解法。