免费人成网站免费看视频,国产免费踩踏调教视频,亚洲中文有码字幕日本,亚洲国产成人久久综合下载

中新網(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) 

1585559883195470.png











圖片來源:

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登錄的JS文件。
1585559918124576.png

由于PayPal登錄頁面有一個CSP規(guī)則腳本-SRC,阻止了這個重定向
1585559947418307.png

后來,作者登錄頁面在動態(tài)生成的iframe中將c.payal.com上的子頁面加載了。此子頁面未使用CSP,還使用了由作者的JS文件!可以控制iframe頁面,但是由于同源策略,無法讀取父頁面的數(shù)據(jù)。

1585559963153504.png

然后,在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密碼。
1585559990931803.png

看著是挺繞的,但是慢慢想一下很簡單,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)頭。

1585560133674508.png
 

五、靶場復(fù)現(xiàn)


我這里用的是https://portswigger.net演示環(huán)境,工具:burp suite,首先關(guān)閉Update content-length。

 
A%))`DWN3P~}YN6E~)NIE87.png
我們來看下常見HTTP走私有三種情況。

(1) CL.TE漏洞

CT-TE: 前端使用Content-length,后端使用Transfer-Encoding
前端服務(wù)器使用Content-Length頭,而后端服務(wù)器使用Transfer-Encoding頭。
環(huán)境演示地址:
https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te
例如:

1585560178504473.png
第一次請求,返回正常頁面:

1585560209945906.png

第二次請求,惡意請求被執(zhí)行:
 
1585560230958451.png

前端服務(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。
環(huán)境演示地址:
https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-te-cl,當(dāng)我們直接訪問/admin直接顯示403,無法訪問。

1585560526822274.png

該怎么辦呢,如果我們使用下面請求是不是就繞過了呢?

1585560549104585.png


是的,但是提示必須
hostlocalhost才能訪問,那我們直接加入HOST: localhost
試一下:
1585560594314076.png

 可見加入HOST:localhost 發(fā)送請求,直接進(jìn)入管理頁面。

最終請求為:
1585560609681506.png


1585560633363279.png


因為前端服務(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í)行。

1585561986301168.png
成功執(zhí)行。
說明:
71是文件字節(jié)數(shù)十六進(jìn)制轉(zhuǎn)換出來的十進(jìn)制數(shù)。

{8K1270%2W{(7)MU]P)K6BL.png

文件字節(jié)數(shù)為十六進(jìn)制數(shù):113轉(zhuǎn)換為十進(jìn)制數(shù):71

 (3)TE.TE行為:混淆TE頭
TE-TE行為很容易理解,當(dāng)前端服務(wù)器和后端服務(wù)器都支持Transfer-Encoding標(biāo)頭,我們可以通過某種方式混淆標(biāo)頭來誘導(dǎo)其中一臺服務(wù)器不對其進(jìn)行處理??梢哉f還是CL-TE TE-CL。
環(huán)境演示地址:
  https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-te-cl使用下面數(shù)據(jù)包進(jìn)行發(fā)送:

1585562029722412.png

當(dāng)我們第一請求直接返回正常頁面 :

1585562046113022.png


 當(dāng)我們第二次發(fā)包,直接執(zhí)行后面的GPOST:

1585562062648750.png

 

六、如何防止HTTP請求走私漏洞

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á)成一致。
 

七、參考文章


HTTP異步攻擊:請求走私重生
https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn
HTTP請求走私
https://portswigger.net/web-security/request-smuggling
 



咸丰县| 施秉县| 威海市| 沈丘县| 钟山县| 新建县| 襄垣县| 改则县| 河南省| 西乌珠穆沁旗| 曲水县| 青冈县| 宁远县| 平陆县|