中新網安安全實驗室｜HTTP請求走私漏洞及靶場復現
2019年8月，hackerone提交了關于PayPal HTTP請求走私+存儲性XSS （鏈接：https://hackerone.com/reports/510152） 攻擊可以直接對PayPal登陸頁面進行控制，并且能獲取所有用戶密碼，危害極大。這是什么漏洞，我們今天來揭開它的面紗：HTTP請求走私(HTTP Request Smuggling) 
圖片來源： https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn 我們先了解下今年black hat上共享的Paypal漏洞實例（引用：https://i.blackhat.com/eu-19/Wednesday/eu-19-Kettle-HTTP-Desync-Attacks-Request-Smuggling-Reborn.pdf ）代碼如下：由于PayPal登錄頁面有一個CSP規則腳本-SRC，阻止了這個重定向后來，作者登錄頁面在動態生成的iframe中將c.payal.com上的子頁面加載了。此子頁面未使用CSP，還使用了由作者的JS文件！可以控制iframe頁面，但是由于同源策略，無法讀取父頁面的數據。然后，在paypal.com/us/gifts上發現了一個不使用CSP的頁面，并且還導入了污染JS文件。通過使用自己的JS將c.paypal.com iframe重定向到該URL（并第三次觸發自己的JS導入），他終于可以訪問父級并從使用Safari或IE PayPal登錄的每個人那里竊取純文本的PayPal密碼。看著是挺繞的，但是慢慢想一下很簡單，PayPal主站是有同源策略，旁站存在HTTP請求走私直接加載自己的JS，PayPal.com/us/gifts可以繞過主站可以加載自己的JS，然后成功竊取每個登陸PayPal賬號密碼。好，我們來了解下什么是HTTP走私。首先我們要了解下HTTP簡介和概念。
HTTP請求走私是一種干擾網站處理從一個或多個用戶接收的HTTP請求序列的方式的技術，它可以繞過安全控制，未經授權訪問敏感數據并且直接危害其他應用程序用戶。
我們知道HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用于從萬維網（WWW:World Wide Web）服務器傳輸超文本到本地瀏覽器的傳送協議，HTTP是一個基于TCP/IP通信協議來傳遞數據。
自HTTP/1.1開始，支持通過單個基礎TCP或者SSL/TLS套接字發送多個HTTP請求，該協議將HTTP請求背靠背放置，服務器解析標頭以計算出每個結束的位置及下個開始位置。1. Persistent Connection（持久連接）HTTP運行在TCP連接之上，存在TCP三次握手，慢啟動等特點，為了盡可能提高HTTP的性能，引用了長連接的概念，目的解決HTTP傳輸，多次建立連接信息的情況，通過Connection: keep-alive 頭部來實現，服務器和客戶端使用它告訴對方在發送完數據之后不斷開TCP連接，那么問題來了，我們該如何判斷信息是否傳輸完成呢。為了解決這個問題，于是引入下面的請求頭Content-length。2. Content-length（實體長度）Content-Length實體標頭字段發送給接收方的實體的大?。ㄒ?/span>OCTET的十進制數為單位）通過判斷Content-lenget長度相等，服務器便知道這個時候可以斷開連接，如果Content-length和實體的實際長度短會造成內容截斷，如果比實際內容長，會為缺少的內容進行自動填充，看似完美了，但是服務器為了計算信息內容，將所有內容緩存下載，并沒有解決web應用優化。3. Transfer-Encoding: chunked（分塊編碼）為了解決Web優化，引入一個新的請求頭Transfer-Encoding: chunked 也就是分塊編碼，加入請求頭后，報文會使用分塊的形式進行傳輸，不在需要緩存所有實例內容，只需要緩存分塊即可，分塊要求，每塊必須包含16進制的長度和數據，長度值獨立占據一行，不包括CRLF（\r\n），也不包括結尾的CRLF，當分塊的長度為0，且沒有數據，連接結束大多數網站為了提高瀏覽速度，用戶體驗，減少服務器負擔，使用CDN加速服務，原理就是在源站前面加入具有緩存功能的反向代理，當用戶請求靜態資源，可以直接到代理服務器中獲取，不在從源站服務器獲取，反向代理與后端源站服務器之間，會重用TCP鏈接，因為不同的用戶請求將通過代理服務器與源站服務器連接，代理服務器與后端的源站服務器的IP是相對固定。但是由于兩者服務器的實現方法不同，如果用戶提供模糊的請求可能代理服務器認為是一個HTTP請求，然后轉發給后端源站服務器，源站服務器經過解析處理后，只認為其中一部分請求，剩下的另外一部分就是走私請求，形成這個原因，是由于HTTP規范提供了兩種不同方式來指定請求的結束位置，它們是Content-Length標頭和Transfer-Encoding標頭。
我這里用的是https://portswigger.net演示環境，工具:burp suite，首先關閉Update content-length。
(1) CL.TE漏洞CT-TE: 前端使用Content-length,后端使用Transfer-Encoding前端服務器使用Content-Length頭，而后端服務器使用Transfer-Encoding頭。https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te前端服務器處理Content-Length標頭，并確定請求正文的長度為9個字節，直到的結尾test該請求被轉發到后端服務器。后端服務器處理Transfer-Encoding標頭，因此將消息正文視為使用分塊編碼。它處理第一個塊，該塊被聲明為零長度，因此被視為終止請求。接下來的字節test保留未處理，后端服務器會將其視為序列中下一個請求的開始。(2) TE.CL漏洞前端服務器使用Transfer-Encoding頭，而后端服務器使用Content-Length頭。https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-te-cl，當我們直接訪問/admin直接顯示403，無法訪問。該怎么辦呢，如果我們使用下面請求是不是就繞過了呢？ 
是的，但是提示必須host是localhost才能訪問，那我們直接加入HOST: localhost 可見加入HOST:localhost 發送請求，直接進入管理頁面。
因為前端服務器處理Transfer-Encoding標頭，使用分塊編碼。一直讀到為0，認為讀取完畢，此時這個請求對代理服務器來說是一個完整的請求，然后轉發給后端服務器，后端服務器對Content-Length標頭進行處理，當它讀完71后認為請求結束，后面的數據就認為另一個請求，也就是成功執行。文件字節數為十六進制數：113轉換為十進制數：71
TE-TE行為很容易理解，當前端服務器和后端服務器都支持Transfer-Encoding標頭，我們可以通過某種方式混淆標頭來誘導其中一臺服務器不對其進行處理?？梢哉f還是CL-TE TE-CL。 https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-te-cl使用下面數據包進行發送：
1．不要重復使用后端連接，HTTP走私依賴多個后端多路復用，后端服務器將走私數據包與合法數據包一起處理，產生危害行為。如果每個請求單獨聯系發送，惡意的走私請求不在有效。
2．使用HTTP / 2進行后端連接，因為此協議禁止使用分塊傳輸編碼。3．前端服務器和后端服務器確保使用完全相同的Web服務器軟件，以便它們就請求之間的界限達成一致。https://portswigger.net/research/http-desync-attacks-request-smuggling-rebornhttps://portswigger.net/web-security/request-smuggling
|
![{8K1270%2W{(7)MU]P)K6BL.png](http://www.wynianfo.com//content/uploadfile/blogimg/20200330/1585562013659940.png "1585562013659940.png")
