核心要點
CRLF‑Powered Desync 攻擊將原本被視為低風險的 HTTP 標頭注入，升級為 請求走私（request smuggling）。攻擊者藉由注入 CRLF（Carriage Return Line Feed） 換行字元，使單一請求被切割成兩段，觸發 回應佇列污染（Response Queue Poisoning），最終竊取 HTTPOnly Cookie、劫持帳號，甚至產生自我擴散的 Desync 蠕蟲。
背景與技術細節
PortSwigger 與 TurtleSec 的研究指出，此手法主要利用 Nginx 等開源反向代理伺服器的常見設定錯誤。當代理伺服器在解碼請求時未正確處理 CRLF，攻擊者即可在 HTTP 標頭中插入 \r\n，將原本的請求分割為：
-
合法請求：被前端伺服器正常處理。
-
惡意請求：在同一 TCP 連線的後續資料中，形成偽造的第二筆請求。
這兩筆請求在後端的回應佇列中錯位，導致不同使用者的回應被錯誤送達，從而取得其他使用者的 Cookie、驗證權杖等敏感資訊。研究團隊證實，僅需在受害者的 瀏覽器 內執行簡單的 JavaScript fetch 或透過普通網頁瀏覽，即可觸發此攻擊，無需直接連入內部網路，成功繞過 IP 與連線鎖定等防護機制。
可能影響與實測案例
研究人員在多個真實環境中重現此攻擊，包括：
- CDN 服務：利用 CDN 前端的緩存層作為入口，將惡意請求傳遞至後端伺服器。
- 電信 平台：透過手機瀏覽器發動攻擊，竊取用戶的認證 Cookie。
- 支付服務 平台：成功取得 HTTPOnly Cookie，導致帳號被接管。
上述案例顯示，即使目標系統已啟用 HTTPOnly（只能由伺服器端存取的 Cookie）保護，仍可因回應佇列錯位而被前端腳本間接取得。
未來展望與防護建議
-
加強代理伺服器的 CRLF 處理：確保 Nginx、Apache 等反向代理在解析標頭時，嚴格過濾或拒絕包含 CRLF 的輸入。
-
啟用請求長度檢查：對於
Content-Length與Transfer-Encoding兩者同時出現的情況，採取明確的拒絕策略，以防止解析差異。 -
監控回應佇列異常：部署 WAF（Web Application Firewall）或行為分析系統，偵測回應順序不一致的情形。
-
定期安全測試：將 HTTP 標頭注入 與 請求走私 列入滲透測試範圍，確保新版本程式碼不會重現相同漏洞。
CRLF‑Powered Desync 攻擊提醒業界，單一漏洞的組合 可能產生遠高於預期的危害。唯有在設計階段即考慮協議解析的完整性，並持續追蹤實務攻擊手法，才能在日益複雜的資安環境中保持防禦的前瞻性。