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