什么是HTTP請求夾帶(smuggling)攻擊
HTTP請求走私是一種干擾網站處理從一個或多個用戶接收的HTTP請求序列的方式的技術。
請求夾帶漏洞危害，允許攻擊者繞過安全控制，獲取對敏感數據的未授權訪問，並直接危及其他應用程序用戶。
HTTP請求夾帶攻擊是怎么發生的？
今天的Web應用程序經常在用戶和最終應用程序邏輯之間使用HTTP服務器鏈。
用戶將請求發送到前端服務器（有時稱為負載平衡器或反向代理），此服務器將請求轉發給一個或多個后端服務器。
在現代基於雲的應用程序中，這種類型的體系結構越來越常見，並且在某些情況下是不可避免的。
當前端服務器將HTTP請求轉發到后端服務器時，它通常通過相同的后端網絡連接發送多個請求，因為這樣做效率更高，性能更高。
協議非常簡單：HTTP請求一個接一個地發送，接收服務器解析HTTP請求標頭以確定一個請求結束的位置和下一個請求的開始：
在這種情況下，前端和后端系統就請求之間的界限達成一致至關重要。否則，攻擊者可能會發送一個模糊的請求，前端和后端系統會對其進行不同的解釋：
在這里，攻擊者將后端服務器的部分前端請求解釋為下一個請求的開始。它有效地預先附加到下一個請求，因此可能會干擾應用程序處理請求的方式。這是一次請求夾帶攻擊，它可能會造成嚴重的后果。
如何構造 HTTP 請求夾帶漏洞
HTTP請求夾帶漏洞出現的原因是因為HTTP規范提供了兩種不同的方式來指定請求的結束位置：Content-Length標頭和Transfer-Encoding標頭。
Content-Length標頭很簡單，它以字節為單位指定消息體的長度。 例如：
POST /search HTTP/1.1 Host: normal-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 11 q=smuggling
Transfer-Encoding標頭可用於指定消息體使用分塊編碼。
這意味着報文包含一個或多個數據塊。 每個塊包含以字節為單位的塊大小（以十六進制表示），后跟換行符，后跟塊內容。 消息以大小為零的塊結束。 例如：
POST /search HTTP/1.1 Host: normal-website.com Content-Type: application/x-www-form-urlencoded Transfer-Encoding: chunked b q=smuggling 0
由於HTTP規范提供了兩種不同的方法來指定HTTP消息的長度，因此單個消息可以同時使用這兩種方法，這樣它們就會相互沖突。
HTTP規范試圖通過聲明防止此問題，如果Content-Length和Transfer-Encoding標頭都存在，則應忽略Content-Length標頭。這可能足以避免在只有一台服務器正在運行時出現歧義，但在兩台或多台服務器鏈接在一起時則不行。
在這種情況下，出現問題有兩個原因：
1.某些服務器不支持請求中的Transfer-Encoding標頭。
2.如果標頭以某種方式進行模糊處理，則可能會導致某些支持Transfer-Encoding標頭的服務器不處理它。
如果前端服務器和后端服務器與（可能模糊的）Transfer-Encoding標頭的行為不同，那么他們可能不同意連續請求之間的邊界，從而導致請求夾帶漏洞。
如何執行HTTP請求夾帶攻擊
請求夾帶攻擊涉及將Content-Length頭和Transfer-Encoding頭放入單個HTTP請求並對其進行操作，以便前端和后端服務器以不同方式處理請求。完成此操作的確切方式取決於兩台服務器的行為：
CL.TE：前端服務器使用Content-Length頭，后端服務器使用Transfer-Encoding頭。
TE.CL：前端服務器使用Transfer-Encoding標頭，后端服務器使用Content-Length標頭。
TE.TE：前端和后端服務器都支持Transfer-Encoding標頭，但是可以通過以某種方式模糊標頭來誘導其中一個服務器不處理它
CL.TE漏洞
這里前端服務器使用Content-Length頭，后端服務器使用Transfer-Encoding頭。我們可以執行簡單的HTTP請求夾帶攻擊，如下所示：
POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 13 Transfer-Encoding: chunked 0 SMUGGLED
前端服務器處理Content-Length頭並確定請求主體長度為13個字節，直到SMUGGLED結束。此請求將轉發到后端服務器。
后端服務器處理Transfer-Encoding標頭，因此將消息體視為使用分塊編碼。
它處理第一個塊，它被稱為零長度，因此被視為終止請求。以下字節SMUGGLED未經處理，后端服務器將這些字節視為序列中下一個請求的開始。
TE.CL漏洞
這里，前端服務器使用Transfer-Encoding標頭，后端服務器使用Content-Length標頭。我們可以執行簡單的HTTP請求夾帶攻擊，如下所示：
POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 3 Transfer-Encoding: chunked 8 SMUGGLED 0
注意:
要使用Burp Repeater發送此請求，您首先需要轉到Repeater菜單，並確保未選中“Update Content-Length”選項。
您需要在最后的0之后包含尾隨序列\r\n\r\n
前端服務器處理Transfer-Encoding標頭，因此將消息體視為使用分塊編碼。它處理第一個塊，長度為8個字節，直到SMUGGLED之后的行的開頭。它處理第二個塊，它被稱為零長度，因此被視為終止請求。此請求將轉發到后端服務器。
后端服務器處理Content-Length標頭並確定請求主體長度為3個字節，直到8之后的行的開頭。以SMUGGLED開頭的以下字節未經處理，后端服務器將這些視為序列中下一個請求的開頭。
TE.TE行為：混淆TE頭、
這里，前端和后端服務器都支持Transfer-Encoding標頭，但是可以通過以某種方式模糊標頭來誘導其中一個服務器不處理它。
有可能無休止地混淆Transfer-Encoding標頭。例如：
Transfer-Encoding: xchunked Transfer-Encoding : chunked Transfer-Encoding: chunked Transfer-Encoding: x Transfer-Encoding:[tab]chunked [space]Transfer-Encoding: chunked X: X[\n]Transfer-Encoding: chunked Transfer-Encoding : chunked
這些技術中的每一種都涉及到與HTTP規范的細微偏離。實現協議規范的實際代碼很少以絕對精度遵守它，並且不同的實現通常容忍規范的不同變化。要發現TE.TE漏洞，有必要找到Transfer-Encoding標頭的一些變體，以便只有一個前端或后端服務器處理它，而另一個服務器忽略它。
根據是否可以誘導不處理混淆的Transfer-Encoding標頭的前端服務器或后端服務器，攻擊的其余部分將采用與CL.TE或TE.CL漏洞相同的形式已經描述過。
如何防止HTTP請求夾帶漏洞
在前端服務器通過同一網絡連接將多個請求轉發到后端服務器的情況下會出現HTTP請求走私漏洞，並且用於后端連接的協議存在兩個服務器不同意關於兩者之間邊界的風險要求。防止HTTP請求走私漏洞的一些通用方法如下：
禁用后端連接的重用，以便通過單獨的網絡連接發送每個后端請求。
使用HTTP / 2進行后端連接，因為此協議可防止請求之間的邊界模糊不清。
為前端和后端服務器使用完全相同的Web服務器軟件，以便他們就請求之間的界限達成一致。
在某些情況下，可以通過使前端服務器規范化模糊請求或使后端服務器拒絕模糊請求並關閉網絡連接來避免漏洞。然而，這些方法可能比上面確定的通用緩解更容易出錯。
web-security 練習
要解決實驗問題，請將請求走私到后端服務器，以便后端服務器處理的下一個請求似乎使用GPOST方法。
https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te
https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl
https://portswigger.net/web-security/request-smuggling/lab-ofuscating-te-header
參考
https://portswigger.net/web-security/request-smuggling