一、引言
大家好！今天我們要聊的話題是——HTTP請求走私（HTTP Request Smuggling）。這是一個相對較新的Web攻擊技術，它利用了前端伺服器和後端伺服器之間的通訊漏洞，來實現惡意操作。接下來，我們將詳細探討什麼是HTTP請求走私、它的工作原理以及如何防禦這種攻擊。
二、HTTP基礎知識
在深入探討HTTP請求走私之前，我們先來了解一些HTTP的基礎知識。HTTP（HyperText Transfer Protocol）是Web應用的基礎協議，它定義了客戶端與伺服器之間的數據傳輸格式。
1. HTTP的工作原理
HTTP是一個請求-響應協議，客戶端（通常是瀏覽器）向伺服器傳送請求，伺服器處理請求並返回響應。每個HTTP請求和響應都包含三個部分：
請求/響應行：描述請求的型別（如GET、POST）或響應的狀態（如200 OK）。
頭部（Headers）：包含請求或響應的後設資料（如Content-Type、Content-Length）。
主體（Body）：包含實際的資料（如表單資料、檔案內容）。
一個典型的HTTP請求如下：
GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 Accept: text/html
而伺服器的響應可能是這樣：
HTTP/1.1 200 OK Content-Type: text/html Content-Length: 1234 <html> <body> <h1>Hello, World!</h1> </body> </html>
2. 前端伺服器與後端伺服器
在實際應用中，Web架構通常由前端伺服器（如Nginx、Apache）和後端伺服器（如Tomcat、Node.js）組成。前端伺服器負責處理客戶端請求，並將請求轉發給後端伺服器進行處理。但這種架構引入了一些新的攻擊面：HTTP請求走私。
三、HTTP請求走私詳解
HTTP請求走私利用前端和後端伺服器之間解析HTTP請求的差異。攻擊者可以提交一個由兩個或多個請求合併而成的一個請求，使得伺服器在解析請求時產生混淆，進而執行未授權的操作。
1. HTTP請求走私的原理
HTTP請求走私利用了HTTP請求中頭部解析的不一致性，特別是對Content-Length和Transfer-Encoding頭部的處理。不同的伺服器對這些頭部的解析方式可能不同，從而導致解析結果的差異。
Content-Length與Transfer-Encoding
在HTTP/1.1中，Content-Length和Transfer-Encoding是兩個用來描述請求主體長度的頭部：
Content-Length：指定請求主體的位元組數。
Transfer-Encoding：指定請求主體的傳輸編碼方式，常見值是
chunked，表示分塊傳輸。
解析方式的不一致性
前端和後端伺服器對這些頭部的解析方式可能不同，導致解析結果不一致。例如：
前端伺服器可能優先處理
Transfer-Encoding，忽略Content-Length。後端伺服器可能優先處理
Content-Length，忽略Transfer-Encoding。
這種不一致性造成了HTTP請求走私攻擊。
示例一：基本請求走私
假設有一個前端伺服器A和一個後端伺服器B，攻擊者傳送如下請求：
POST / HTTP/1.1 Host: victim.com Content-Length: 13 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 Host: victim.com
前端伺服器A解析到
Transfer-Encoding: chunked，認為請求主體是分塊傳輸的，但在讀取第一個塊（0表示結束）後認為請求結束。後端伺服器B則根據
Content-Length: 13繼續讀取剩餘資料，將GET /admin HTTP/1.1作為一個新請求進行處理。
這樣，攻擊者就成功將自己的請求走私到伺服器B。
2. HTTP請求走私的其他可能方式
CL.TE與TE.CL
CL.TE（Content-Length + Transfer-Encoding）：前端伺服器使用
Content-Length，而後端伺服器使用Transfer-Encoding。這種情況下，前端伺服器會根據Content-Length處理請求，而後端伺服器會根據Transfer-Encoding繼續處理剩餘的資料，導致請求走私。TE.CL（Transfer-Encoding + Content-Length）：前端伺服器使用
Transfer-Encoding，而後端伺服器使用Content-Length。前端伺服器會根據Transfer-Encoding處理請求，後端伺服器會根據Content-Length讀取額外資料，導致請求走私。
HTTP/1.1與HTTP/2
HTTP/1.1與HTTP/2之間的轉換：有些前端伺服器可能將HTTP/2請求轉換為HTTP/1.1請求再轉發給後端伺服器，或反之。在這種轉換過程中，如果解析不一致，也可能導致請求走私。
四、防禦措施
統一解析策略：確保前端和後端伺服器對HTTP請求的解析策略一致。特別是對於
Content-Length和Transfer-Encoding頭部的處理保持一致。禁用不必要的頭部：如果應用不需要使用分塊傳輸，建議禁用
Transfer-Encoding: chunked頭。
防禦示例
以下是一些具體的防禦配置示例：
示例一：Nginx配置
在Nginx中，可以透過以下配置禁用分塊傳輸：
http {
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
proxy_set_header Transfer-Encoding "";
proxy_set_header Content-Length $proxy_add_header;
}
}
}
示例二：Apache配置
在Apache中，可以透過以下配置確保解析一致性：
<VirtualHost *:80> ServerName example.com # 禁用分塊傳輸 RequestHeader unset Transfer-Encoding ProxyPass / http://backend/ ProxyPassReverse / http://backend/ </VirtualHost>
結語
希望這篇文章能幫你更好地理解HTTP請求走私攻擊及其防禦方法。如果你有任何問題，歡迎在評論區討論！
