CRLF-Powered Desync：HTTPOnly Cookie 為何仍可能失守

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-03

iThome 報道指，PortSwigger 與 TurtleSec 研究人員公開名為 CRLF-Powered Desync 的攻擊手法。它把原本常被視為影響有限的 HTTP 標頭注入問題，結合請求走私（request smuggling）技術，令攻擊者有機會取得驗證權杖、竊取 HTTPOnly Cookie，甚至接管帳號。研究團隊已在 CDN、電訊及支付服務平台等實際案例中重現相關情況。

不過，這不代表所有採用 Nginx、CDN 或反向代理的網站都存在同一風險。iThome 指出的關鍵前提，是代理層出現常見但不當的設定，並且其對 CRLF 換行字元的解碼方式，與後端處理 HTTP 請求邊界的方式產生落差。受影響的是這類「前後層理解不同」的部署組合，而非某一款軟件一律有問題。

問題核心：一個請求在不同層被看成兩個

CRLF 是 HTTP 訊息中用來分隔標頭與內容、以及劃分行結構的控制字元。正常情況下，應用程式輸入不應有機會改變這些協議結構；但若反向代理把經編碼的 CRLF 還原，並將其帶進由使用者可影響的 HTTP 標頭欄位，攻擊者便可能令後續組件對同一段資料作出不同解讀。

iThome 報道所述的 CRLF-Powered Desync，正是利用這種解析差異，把看似單一的惡意 HTTP 請求切割成兩部分。代理、CDN 或前端 server 可能仍按一個請求轉送，但後端或連線上的另一端卻將其中部分視為另一個請求。當共用連線上的請求與回應順序因此脫節，便可能出現回應佇列污染（Response Queue Poisoning）：甲使用者送出的請求，有機會收到原應屬於乙使用者的回應。

這類問題的危險之處，在於漏洞不必直接存在於登入頁面或 Cookie 的設定本身。網站即使把敏感 Cookie 標示為 HTTPOnly，只要中間層與後端對請求邊界不一致，攻擊者仍可能透過被錯配的 HTTP 回應取得認證資料。換言之，防護效果取決於整條請求路徑是否一致處理協議資料，而不只是瀏覽器端的一個安全旗標。

HTTPOnly 為何未必足夠

HTTPOnly 的作用，是阻止網頁上的 JavaScript 直接讀取 Cookie。這仍是必要的基礎防護，能減少一般跨站腳本攻擊竊取登入憑證的機會；但它並不保證 Cookie 不會隨 HTTP 請求傳送，也無法修正 server、代理與 CDN 之間的協議解析錯配。

iThome 指出，研究人員展示了可經受害者瀏覽器的 JavaScript fetch，或透過一般網頁瀏覽觸發攻擊的情況。這意味著風險不局限於攻擊者直接連到內部後端的情境：若攻擊鏈成立，瀏覽器可被用作發起請求的一環，並避開某些以來源 IP 或連線綁定為基礎的限制。最終被取得的未必是由前端程式直接讀出的 Cookie，而可能是因為回應錯配而落到錯誤請求一方的認證資訊。

從防守角度看，HTTPOnly、Secure 與適當的 SameSite Cookie 設定仍應保留；它們分別處理不同層面的威脅。然而，CRLF-Powered Desync 提醒團隊，瀏覽器安全屬性不能替代 HTTP 邊界驗證、標頭正規化，以及代理鏈一致性檢查。若把 Cookie 保護當成唯一防線，便容易忽略流量在抵達應用程式前已經歷多層轉送與重寫。

香港網站團隊應優先檢查甚麼

對使用 Nginx、負載平衡器、WAF、CDN 與應用程式伺服器的團隊而言，首要工作是盤點一條外部請求實際會經過哪些層，而不是急於套用單一設定。特別要確認哪些 URL、查詢參數或使用者輸入會被映射到轉送用的 HTTP 標頭、重新導向位置或上游請求；並檢查這些值在任何一層有否被解碼後再拼接使用。

建議檢查重點包括：入口層能否拒絕或安全處理 CR、LF 及其編碼變體；Nginx、CDN、WAF 與後端框架對編碼字元及標頭格式的規則是否一致；反向代理是否會重用通往上游的連線；以及錯誤處理與快取規則會否把異常回應交給不相干的使用者。若組織使用第三方 CDN 或託管式負載平衡服務，亦應向供應商確認其對這類請求解析落差的緩解措施與設定責任界線。

測試時應在獲授權、隔離的環境進行，並由熟悉 HTTP 協議與應用架構的人員審閱流量記錄，避免將生產環境變成驗證場。實務上，修正方向通常是消除使用者可控制資料進入協議控制位置的可能、統一各層的請求正規化規則，並收緊代理對不合規 HTTP 請求的接受程度。這些改動或會令少量非標準客戶端失效，因此需要配合監測與分階段推出，而不是一刀切。