解密協(xié)議層的攻擊——HTTP請(qǐng)求走私

最近一直在研究一些比較有意思的攻擊方法與思路，在查閱本地文檔的時(shí)候(沒錯(cuò)，本地，我經(jīng)常會(huì)將一些有意思的文章但是沒時(shí)間看就會(huì)被我保存pdf到本地），一篇2019年Black hat的議題——HTTP請(qǐng)求走私，進(jìn)入我的視野，同時(shí)我也查閱到在2020 Blackhat中該攻擊手法再次被分析。我對(duì)此產(chǎn)生濃厚學(xué)習(xí)興趣，于是便有了這篇文章。

HTTP請(qǐng)求走私是一種HTTP協(xié)議的攻擊利用方法，該攻擊產(chǎn)生的原因在于HTTP代理鏈中HTTP Server的實(shí)現(xiàn)中存在不一致的問題。

• 2004年，@Amit Klein提出HTTP Response Splitting技術(shù)，為HTTP Smuggling攻擊雛形；

• 2005年，第一次被@Watchfire所提出， 并對(duì)其進(jìn)行了詳細(xì)介紹；

• 2016年，DEFCON 24上，@regilero在他的議題——Hiding?Wookiees in HTTP中在對(duì)前面報(bào)告進(jìn)行豐富與擴(kuò)充；

• 2019年，Blackhat USA上，PortSwigger的@James Kettle在其議題——HTTP DESYNC ATTACKS SMASHING INTO THE CELL NEXT DOOR中對(duì)當(dāng)前網(wǎng)絡(luò)環(huán)境進(jìn)行了分析，同時(shí)在其利用上加入chunked技術(shù)，對(duì)現(xiàn)有攻擊面進(jìn)行了拓展；

• 2020年，Blackhat USA上，@Amit Klein在其議題——HTTP Request Smuggling in 2020中最新變種手法進(jìn)行分析，同時(shí)對(duì)各類環(huán)境場(chǎng)景下進(jìn)行了分析。

HTTP協(xié)議請(qǐng)求走私并不像其他web攻擊手法那么直觀，而是在更加復(fù)雜的網(wǎng)絡(luò)環(huán)境中，因不同服務(wù)器基于不同的RFC標(biāo)準(zhǔn)實(shí)現(xiàn)的針對(duì)HTTP協(xié)議包的不同處理方式而產(chǎn)生的一種安全風(fēng)險(xiǎn)。

在對(duì)其漏洞進(jìn)行分析前，首先需要了解目前被廣泛使用的HTTP 1.1協(xié)議特性——Keep-Alive、Pipeline技術(shù)。

簡(jiǎn)單來說，在HTTP 1.0及其以前版本的協(xié)議中，在每次進(jìn)行交互的時(shí)候，C/S兩端都需要進(jìn)行TCP的三次握手鏈接。而如今的web頁面大部分主要還是由大量靜態(tài)資源所組成。如果依然按照HTTP 1.0及其以前版本的協(xié)議設(shè)計(jì)，會(huì)導(dǎo)致服務(wù)器大量的負(fù)載被浪費(fèi)。于是在HTTP 1.1中，增加了Keep-Alive、Pipeline技術(shù)。

根據(jù)RFC7230規(guī)范中section-6.3可以得知，HTTP 1.1中默認(rèn)使用persistent connections方式。其實(shí)現(xiàn)手法是在HTTP通信包中加入Connection: Keep-Alive標(biāo)識(shí)：在一次HTTP通信后不會(huì)關(guān)閉TCP連接，而在后續(xù)相同目標(biāo)服務(wù)器請(qǐng)求中復(fù)用該空閑的TCP通道，避免了由于新建TCP連接產(chǎn)生的時(shí)延和服務(wù)器資源消耗，提升用戶資源訪問速度。

而在Keep-Alive中后續(xù)又有了Pipeline機(jī)制,這樣客戶端就可以像流水線一樣不用等待某個(gè)包的響應(yīng)而持續(xù)的向服務(wù)器發(fā)包。而服務(wù)器也會(huì)遵循先進(jìn)先出原則對(duì)客戶端請(qǐng)求進(jìn)行響應(yīng)。

如圖，我們可以看到相比于no pipelining模式，pipelining模式下服務(wù)器在響應(yīng)時(shí)間上有了很大的提升。

現(xiàn)如今，為了提高用戶瀏覽速度、加強(qiáng)服務(wù)穩(wěn)定性、提升使用體驗(yàn)以及減輕網(wǎng)絡(luò)負(fù)擔(dān)。大部分廠商都會(huì)使用CDN加速服務(wù)或負(fù)載均衡LB等部署業(yè)務(wù)。當(dāng)用戶訪問服務(wù)器靜態(tài)資源時(shí)，將直接從CDN上獲取詳情，當(dāng)存在真正服務(wù)器交互時(shí)，才會(huì)與后端服務(wù)器產(chǎn)生交互。如圖所示：

但是，該模式中reverse proxy部分將長(zhǎng)期與back-end部分通信，一般情況下這部分連接會(huì)重用TCP通道。通俗來說，用戶流量來自四面八方，user端到reverse proxy端通信會(huì)建立多條TCP通道，而rever proxy與back-end端通信ip固定，這兩者重用TCP連接通道來通信便順理成章了。

在這種場(chǎng)景下，當(dāng)不同服務(wù)器實(shí)現(xiàn)時(shí)參考的RFC標(biāo)準(zhǔn)不同時(shí)，我們向reverse proxy發(fā)送一個(gè)比較模糊的HTTP請(qǐng)求時(shí)，因?yàn)閞everse proxy與back-end基于不同標(biāo)準(zhǔn)進(jìn)行解析，可能產(chǎn)生reverse proxy認(rèn)為該HTTP請(qǐng)求合法，并轉(zhuǎn)發(fā)到back-end，而back-end只認(rèn)為部分HTTP請(qǐng)求合法，剩下的多余請(qǐng)求，便就算是夾帶走私的HTTP請(qǐng)求了。當(dāng)該部分對(duì)正常用戶的請(qǐng)求造成了影響之后，就實(shí)現(xiàn)了HTTP走私攻擊。如圖所示：深色為正常請(qǐng)求，橙色為走私請(qǐng)求，綠色為正常用戶請(qǐng)求。一起發(fā)包情況下，走私的請(qǐng)求內(nèi)容被拼接到正常請(qǐng)求中。

分塊傳輸編碼（Chunked transfer encoding）是超文本傳輸協(xié)議（HTTP）中的一種數(shù)據(jù)傳輸機(jī)制，允許HTTP的數(shù)據(jù)可以分成多個(gè)部分。

如下圖所示，為jdcloud.com未進(jìn)行數(shù)據(jù)包進(jìn)行chunked。

當(dāng)對(duì)jdcloud.com進(jìn)行分塊時(shí)，如下圖所示。

注：后續(xù)文章中所提到CL=Content-Length，TE=Transfer-Encoding，如需使用burpsuite進(jìn)行數(shù)據(jù)包調(diào)試時(shí)，需去除Repeater中Update Content-Length選項(xiàng)。

主要指在GET中設(shè)置Content-Length長(zhǎng)度，使用body發(fā)送數(shù)據(jù)。當(dāng)然這里也不僅僅限制與GET請(qǐng)求中，只是GET的理解比較典型，所以我們用在做例子。

在RFC7230 Content-Length部分提到：

For example, a Content-Length header field is normally sent in a POST request even when the value is 0 (indicating an empty payload body). A user agent SHOULD NOT send a Content-Length header field when the request message does not contain a payload body and the method semantics do not anticipate such a body.

在最新的RFC7231 4.3.1 GET中也僅僅提了一句：

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

?

從官方規(guī)范文檔可以了解到：RFC規(guī)范并未嚴(yán)格的規(guī)范Server端處理方式，對(duì)該類請(qǐng)求的規(guī)范也適當(dāng)進(jìn)行了放松，但是也是部分情況。由于這些中間件沒有一個(gè)嚴(yán)格的標(biāo)準(zhǔn)依據(jù)，所以也會(huì)產(chǎn)生解析差異導(dǎo)致HTTP Smuggling攻擊。

• 構(gòu)造數(shù)據(jù)包

1GET?/?HTTP/1.1\r\n
2Host:?example.com\r\n
3Content-Length:?44\r\n
4
5GET?/secret?HTTP/1.1\r\n
6Host:?example.com\r\n
7\r\n

<左右滑動(dòng)以查看完整代碼>

由于GET請(qǐng)求，服務(wù)器將不對(duì)Content-Length進(jìn)行處理，同時(shí)因?yàn)镻ipeline的存在，后端服務(wù)器會(huì)將該數(shù)據(jù)包視為兩個(gè)GET請(qǐng)求。分別為：

請(qǐng)求——1

1GET?/?HTTP/1.1\r\n
2Host:?example.com\r\n

<左右滑動(dòng)以查看完整代碼>

請(qǐng)求——2

1GET?/secret?HTTP/1.1\r\n
2Host:?example.com\r\n

<左右滑動(dòng)以查看完整代碼>

這就導(dǎo)致了請(qǐng)求走私。

在RFC7230的第3.3.3節(jié)中的第四條中，規(guī)定當(dāng)服務(wù)器收到的請(qǐng)求中包含兩個(gè)Content-Length，而且兩者的值不同時(shí)，需要返回400錯(cuò)誤。

If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and the recipient MUST treat it as an unrecoverable error. If this is a request message, the server MUST respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy, the proxy MUST close the connection to the server, discard the received response, and send a 502 (Bad Fielding & Reschke Standards Track [Page 32] RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 Gateway) response to the client. If this is a response message received by a user agent, the user agent MUST close the connection to the server and discard the received response.

但是某些服務(wù)器并沒遵循規(guī)范進(jìn)行實(shí)現(xiàn)，當(dāng)服務(wù)器未遵循該規(guī)范時(shí)，前后服務(wù)器都不會(huì)響應(yīng)400?？赡茉斐纱矸?wù)器使用第一個(gè)Content-Length獲取長(zhǎng)度，而后端按照第二個(gè)Content-Length獲取長(zhǎng)度。

• 構(gòu)造數(shù)據(jù)包

1POST?/?HTTP/1.1\r\n
2Host:?example.com\r\n
3Content-Length:?8\r\n
4Content-Length:?7\r\n
5
612345\r\n
7a

<左右滑動(dòng)以查看完整代碼>

這個(gè)時(shí)候，當(dāng)后端服務(wù)器接受到數(shù)據(jù)包時(shí)，Content-Length長(zhǎng)度為7。實(shí)際上接受到的body為12345\r\n，而我們前面所提到的，代理服務(wù)器會(huì)與后端服務(wù)器重用TCP通道，這個(gè)時(shí)候a就會(huì)拼接到下一個(gè)請(qǐng)求。這個(gè)時(shí)候如果存在一個(gè)用戶發(fā)起GET請(qǐng)求。則該用戶GET請(qǐng)求實(shí)際為：

1aGET?/?HTTP/1.1\r\n
2Host:?example.com\r\n

<左右滑動(dòng)以查看完整代碼>

同時(shí)該用戶也會(huì)收到一個(gè)類似aGET request method not found的報(bào)錯(cuò)響應(yīng)，其實(shí)這樣就已經(jīng)實(shí)現(xiàn)了一次HTTP協(xié)議走私攻擊，對(duì)正常用戶造成了影響，而且后續(xù)可以擴(kuò)展成類似于CSRF的攻擊方式。

但是兩個(gè)Content-Length這種請(qǐng)求包還是太過于理想化了，一般的服務(wù)器都不會(huì)接受這種存在兩個(gè)請(qǐng)求頭的請(qǐng)求包，但是在RFC2616的第4.4節(jié)中，規(guī)定：

The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence):

If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.

也就是說，當(dāng)Content-Length與Transfer-Encoding同時(shí)被定義使用時(shí)，可忽略Content-Length。也就是說當(dāng)Transfer-Encoding的加入，兩個(gè)Content-Length并不影響代理服務(wù)器與后端服務(wù)器的響應(yīng)。

這里的情況是指代理服務(wù)器處理Content-Length，后端服務(wù)器會(huì)遵守RFC2616的規(guī)定，處理Transfer-Encoding的情況(這里也就是場(chǎng)景2后邊所提到的情況)。

• 構(gòu)造數(shù)據(jù)包

 1POST?/?HTTP/1.1\r\n
 2Host:?example.com\r\n
 3User-Agent:?Mozilla/5.0?(Macintosh;?Intel?Mac?OS?X?10.14;?rv:56.0)?Gecko/20100101?Firefox/56.0\r\n
 4Accept:?text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
 5Accept-Language:?en-US,en;q=0.5\r\n
 6Connection:?keep-alive\r\n
 7Content-Length:?6\r\n
 8Transfer-Encoding:?chunked\r\n
 9\r\n
100\r\n
11\r\n
12G

<左右滑動(dòng)以查看完整代碼>

• 因前后服務(wù)器規(guī)范不同，解析如下：

請(qǐng)求——1 (代理服務(wù)器的解析）

 1POST?/?HTTP/1.1\r\n
 2Host:?example.com\r\n
 3User-Agent:?Mozilla/5.0?(Macintosh;?Intel?Mac?OS?X?10.14;?rv:56.0)?Gecko/20100101?Firefox/56.0\r\n
 4Accept:?text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
 5Accept-Language:?en-US,en;q=0.5\r\n
 6Connection:?keep-alive\r\n
 7Content-Length:?6\r\n
 8Transfer-Encoding:?chunked\r\n
 9\r\n
100\r\n
11\r\n
12G

<左右滑動(dòng)以查看完整代碼>

請(qǐng)求——2 (代理服務(wù)器的解析）

G

其中G被留在緩存區(qū)中，當(dāng)無其他用戶請(qǐng)求時(shí)候，該數(shù)據(jù)包會(huì)不會(huì)產(chǎn)生解析問題，但TCP重用情況，當(dāng)一個(gè)正常請(qǐng)求過來時(shí)候。將出現(xiàn)如下情況：

1GPOST?/?HTTP/1.1\r\n
2Host:?example.com\r\n
3....

<左右滑動(dòng)以查看完整代碼>

這個(gè)時(shí)候HTTP包，再一次通過TCP通道進(jìn)行走私。

即代理服務(wù)器處理Transfer-Encoding請(qǐng)求，后端服務(wù)器處理Content-Length請(qǐng)求。

• 構(gòu)造數(shù)據(jù)包

 1POST?/?HTTP/1.1\r\n
 2Host:?example.com\r\n
 3User-Agent:?Mozilla/5.0?(Macintosh;?Intel?Mac?OS?X?10.14;?rv:56.0)?Gecko/20100101?Firefox/56.0\r\n
 4Accept:?text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
 5Accept-Language:?en-US,en;q=0.5\r\n
 6Content-Length:?4\r\n
 7Transfer-Encoding:?chunked\r\n
 8\r\n
 912\r\n
10GPOST?/?HTTP/1.1\r\n
11\r\n
120\r\n
13\r\n

<左右滑動(dòng)以查看完整代碼>

由于Transfer-Encoding遇到0\r\n\r\n才結(jié)束解析。此時(shí)后端將解析Content-Length,真正到達(dá)后端數(shù)據(jù)將為：

1POST?/?HTTP/1.1\r\n
2Host:?example.com\r\n
3User-Agent:?Mozilla/5.0?(Macintosh;?Intel?Mac?OS?X?10.14;?rv:56.0)?Gecko/20100101?Firefox/56.0\r\n
4Accept:?text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
5Accept-Language:?en-US,en;q=0.5\r\n
6Content-Length:?4\r\n
7\r\n
812\r\n

<左右滑動(dòng)以查看完整代碼>

同時(shí)將出現(xiàn)第二個(gè)數(shù)據(jù)包：

1GPOST?/?HTTP/1.1\r\n
2\r\n
30\r\n
4\r\n

<左右滑動(dòng)以查看完整代碼>

當(dāng)收到存在兩個(gè)請(qǐng)求頭的請(qǐng)求包時(shí)，前后端服務(wù)器都處理Transfer-Encoding請(qǐng)求頭，這確實(shí)是實(shí)現(xiàn)了RFC的標(biāo)準(zhǔn)。不過前后端服務(wù)器畢竟不是同一種，這就有了一種方法，我們可以對(duì)發(fā)送的請(qǐng)求包中的Transfer-Encoding進(jìn)行某種混淆操作(這里主要指Content-Length)，從而使其中一個(gè)服務(wù)器不處理Transfer-Encoding請(qǐng)求頭。從某種意義上還是CL-TE或者TE-CL。

• 構(gòu)造數(shù)據(jù)包

 1POST?/?HTTP/1.1\r\n
 2Host:?example.com\r\n
 3User-Agent:?Mozilla/5.0?(Macintosh;?Intel?Mac?OS?X?10.14;?rv:56.0)?Gecko/20100101?Firefox/56.0\r\n
 4Accept:?text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
 5Content-length:?4\r\n
 6Transfer-Encoding:?chunked\r\n
 7Transfer-encoding:?cow\r\n
 8\r\n
 95c\r\n
10GPOST?/?HTTP/1.1\r\n
11Content-Type:?application/x-www-form-urlencoded\r\n
12Content-Length:?15\r\n
13\r\n
14x=1\r\n
150\r\n
16\r\n

<左右滑動(dòng)以查看完整代碼>

使用PortSwigger的實(shí)驗(yàn)環(huán)境環(huán)境進(jìn)行實(shí)際攻擊演示。

*靶場(chǎng)鏈接：

https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-cl-te

This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding. There's an admin panel at /admin, but the front-end server blocks access to it.

To solve the lab, smuggle a request to the back-end server that accesses the admin panel and deletes the user carlos.

實(shí)驗(yàn)?zāi)康模涸L問admin頁，并利用認(rèn)證對(duì)carlos用戶進(jìn)行刪除。

• SETP 1、因直接訪問/admin目錄被提示攔截，同時(shí)題目提示CL.TE。這里通過構(gòu)造CL.TE格式數(shù)據(jù)包，嘗試訪問。/admin路由。

• SETP 2、訪問提示管理員界面只允許為本地用戶訪問，嘗試直接訪問localhost,并獲取到刪除用戶路由地址。

• SETP 3、通過構(gòu)造請(qǐng)求訪問即可，最終再次訪問/admin顯示頁面已經(jīng)沒有刪除carlos用戶選項(xiàng)。

*鏈接：

https://portswigger.net/web-security/request-smuggling/exploiting/lab-reveal-front-end-request-rewriting

This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding.

There's an admin panel at /admin, but it's only accessible to people with the IP address 127.0.0.1. The front-end server adds an HTTP header to incoming requests containing their IP address. It's similar to the X-Forwarded-For?header but has a different name.

To solve the lab, smuggle a request to the back-end server that reveals the header that is added by the front-end server. Then smuggle a request to the back-end server that includes the added header, accesses the admin panel, and deletes the user carlos.

實(shí)驗(yàn)?zāi)康耐希贿^這里在前端服務(wù)器做了限制。不支持chunked。同時(shí)前端到后端做了檢查,在headers中自定義了一個(gè)類似于X-Forwarded-For的頭。

• SETP1、通過頁面search處直接構(gòu)造走私數(shù)據(jù)包，在頁面返回中間服務(wù)器到后端服務(wù)器數(shù)據(jù)包內(nèi)容(走私數(shù)據(jù)包長(zhǎng)度當(dāng)前為200，若實(shí)際場(chǎng)景中顯示不全則可通過增加CL長(zhǎng)度解決)，獲取到X-uNiqsg-Ip頭。同時(shí),這里之所以選擇search處，主要是因?yàn)樵撎幵陧撁娲嬖谳敵觥?/span>

• SETP2、通過偽造同樣請(qǐng)求發(fā)包即可。

*鏈接：

https://portswigger.net/web-security/request-smuggling/exploiting/lab-capture-other-users-requests

This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding.

To solve the lab, smuggle a request to the back-end server that causes the next user's request to be stored in the application. Then retrieve the next user's request and use the victim user's cookies to access their account.

實(shí)驗(yàn)?zāi)康模和ㄟ^寫頁面的方式，獲取下一個(gè)請(qǐng)求數(shù)據(jù)包中cookie數(shù)據(jù)。

• SETP1、發(fā)現(xiàn)post?postId=路由下存在寫頁面操作，通過修改數(shù)據(jù)包。

• SETP2、訪問當(dāng)前頁面查看website處即可獲取到下一個(gè)請(qǐng)求包的數(shù)據(jù)。（這里同樣也可以控制下一個(gè)請(qǐng)求包數(shù)據(jù)在評(píng)論區(qū)，只需將最后一個(gè)評(píng)論參數(shù)comment放至最后即可）

*鏈接：

https://portswigger.net/web-security/request-smuggling/exploiting/lab-deliver-reflected-xss

This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding.

The application is also vulnerable to reflected XSS?via the User-Agent?header.

To solve the lab, smuggle a request to the back-end server that causes the next user's request to receive a response containing an XSS exploit that executes alert(1).

應(yīng)用場(chǎng)景：當(dāng)業(yè)務(wù)存在反射型XSS時(shí)，可通過緩存投毒的方式在其他用戶頁面寫入臟數(shù)據(jù)。

SETP1、 進(jìn)入任意評(píng)論區(qū)發(fā)現(xiàn)頁面存在userAgent回顯，通過走私協(xié)議修改userAgent即可。

*鏈接：

https://portswigger.net/web-security/request-smuggling/exploiting/lab-perform-web-cache-poisoning

This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding. The front-end server is configured to cache certain responses.

To solve the lab, perform a request smuggling?attack that causes the cache to be poisoned, such that a subsequent request for a JavaScript file receives a redirection to the exploit server. The poisoned cache should alert document.cookie.

應(yīng)用場(chǎng)景：劫持下一用戶請(qǐng)求頁面。（實(shí)際場(chǎng)景中可劫持跳轉(zhuǎn)至釣魚等頁面）

• SETP1、緩存注入修改Host為惡意請(qǐng)求。

從前面的案例我們可以看到HTTP請(qǐng)求走私的危害性，那么如何防御呢？

• 禁用代理服務(wù)器與后端服務(wù)器之間的TCP連接重用。

• 使用HTTP/2協(xié)議。

• 前后端使用相同的服務(wù)器。

但是這些修復(fù)方法又存在一些現(xiàn)實(shí)困難：

• HTTP/2推行過于困難，盡管HTTP/2兼容HTTP/1.1。

• 取消TCP重用將增大服務(wù)器負(fù)載，服務(wù)器資源吃不消。

• 使用相同的服務(wù)器，在一些廠商其實(shí)也很難實(shí)現(xiàn)。其主要原因還是前后端實(shí)現(xiàn)標(biāo)準(zhǔn)不一致的問題。

那么沒有解決方案了嘛？

其實(shí)不然，上云就是個(gè)很好的方案。云主機(jī)、CDN、WAF都統(tǒng)一實(shí)現(xiàn)編碼規(guī)范，可以很好地避免該類問題的產(chǎn)生。

*https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEF%20CON%2024%20-%20Regilero-Hiding-Wookiees-In-Http.pdf

*https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn

*https://regilero.github.io/english/security/2019/10/17/securityapachetrafficserverhttp_smuggling/

*https://paper.seebug.org/1048

*https://tools.ietf.org/html/rfc2616

*http://blog.zeddyu.info/2019/12/05/HTTP-Smuggling/

*https://tools.ietf.org/html/rfc7230

*https://tools.ietf.org/html/rfc7231