HTTP 請求走私（HTTP Request Smuggling）是一種通過利用前端代理（如負載均衡器、CDN）和后端服務器在 解析 HTTP 請求時存在不一致性 的漏洞，從而實現 注入惡意請求 的攻擊技術。
一、基本原理
HTTP 請求走私主要依賴兩個請求頭字段的不一致處理：
-
Content-Length：指明請求體的長度。 -
Transfer-Encoding: chunked：指明請求體是分塊傳輸的。
不一致的場景
當前端和后端服務器對這兩個頭的解釋不一致時，攻擊者就能將多個請求“混淆”為一個請求，從而：
-
繞過認證
-
注入惡意請求
-
劫持用戶會話
-
發起緩存投毒
-
進行 XSS / CSRF 攻擊
常見的組合方式：
| 名稱 | 條件 |
|---|---|
| CL.TE | 前端使用 Content-Length，后端使用 Transfer-Encoding |
| TE.CL | 前端使用 Transfer-Encoding，后端使用 Content-Length |
| TE.TE | 前端和后端都支持 Transfer-Encoding，但處理方式不同 |
二、CL.TE 類型攻擊示例
假設你有以下攻擊場景：
-
前端（比如 Nginx）使用
Content-Length解析請求； -
后端（比如 Apache）使用
Transfer-Encoding: chunked解析請求。
攻擊請求如下：
POST / HTTP/1.1
Host: vulnerable.site
Content-Length: 62
Transfer-Encoding: chunked0GET /admin HTTP/1.1
Host: vulnerable.site
解析過程：
前端（Nginx）：
-
只看
Content-Length: 62，把整段請求當作一個完整請求發送到后端。
后端（Apache）：
-
看到
Transfer-Encoding: chunked，開始以分塊方式解析請求。 -
0\r\n\r\n表示請求體結束。 -
后面的
GET /admin HTTP/1.1...被解釋為另一個完整的 HTTP 請求。
→ 后端就會執行這個攻擊者構造的請求 GET /admin，可能會繞過權限控制！
三、防御方式
-
統一前后端解析邏輯
-
確保前后端對 HTTP 請求頭的處理一致。
-
-
禁止混合使用
Content-Length和Transfer-Encoding-
可以在 Web 應用防火墻（WAF）中檢測并拒絕。
-
-
升級服務器
-
新版本的服務器通常修復了相關解析不一致的問題。
-
-
使用 Web Application Firewall（WAF）
-
例如 ModSecurity 可以檢測這種模糊請求。
-
-
啟用 Chunked 請求白名單機制
-
如果應用不需要 chunked 編碼，直接禁用該特性。
-
以下是一個真實的 HTTP 請求走私（HTTP Request Smuggling）攻擊案例，展示了其在現實世界中的危害性。
🧪 案例：利用請求走私劫持用戶會話
安全公司 Outpost24 在一次滲透測試中發現，某 Web 應用存在 TE:CL 類型的請求走私漏洞。通過精心構造的請求，攻擊者成功實現了響應隊列的不同步（Response Queue Desynchronization），從而劫持了其他用戶的會話。Outpost24+1Outpost24+1
攻擊過程：
-
識別漏洞：使用工具檢測到前端服務器使用
Transfer-Encoding解析請求，而后端服務器使用Content-Length，存在解析不一致。 -
構造惡意請求：發送包含兩個請求的單個 HTTP 請求，其中第一個請求設置了特定的頭部，使后端服務器將兩個請求視為一個，從而導致響應隊列不同步。
-
劫持會話：由于響應隊列不同步，攻擊者能夠接收到屬于其他用戶的響應，其中可能包含敏感信息，如訪問令牌。
🔍 案例：Apache Tomcat 中的請求走私漏洞（CVE-2021-33037）
Apache Tomcat 是廣泛使用的 Java Web 服務器。在 2021 年，發現其存在一個請求走私漏洞（CVE-2021-33037），影響版本包括 8.5.0 至 8.5.66、9.0.0.M1 至 9.0.46 和 10.0.0-M1 至 10.0.6。該漏洞源于 Tomcat 在某些情況下未正確解析 HTTP 的 Transfer-Encoding 請求頭，導致在與反向代理一起使用時可能發生請求走私。QualysPortSwigger+1Qualys+1
攻擊者可以利用該漏洞，隱藏惡意請求在正常請求中，繞過安全檢查，執行未授權的操作。該漏洞已在后續版本中修復，建議用戶升級至最新版本。
