HTTP Request Smuggling / HTTP Desync Attack
What is
Uthibitisho huu hutokea wakati desyncronization kati ya front-end proxies na back-end server inaruhusu mshambuliaji kutuma HTTP request ambayo itatafsiriwa kama ombile moja na front-end proxies (load balance/reverse-proxy) na kama ombi 2 na back-end server. Hii inaruhusu mtumiaji kubadilisha ombi linalofuata linalofika kwa server ya back-end baada ya lake.
Theory
Ikiwa ujumbe unapokelewa ukiwa na uwanja wa kichwa cha Transfer-Encoding na uwanja wa kichwa cha Content-Length, wa mwisho LAZIMA upuuziliwe mbali.
Content-Length
Kichwa cha Content-Length kinadhihirisha ukubwa wa mwili wa kitu, kwa bytes, kilichotumwa kwa mpokeaji.
Transfer-Encoding: chunked
Kichwa cha Transfer-Encoding kinabainisha aina ya usimbuaji inayotumika kwa usalama kuhamasisha mwili wa payload kwa mtumiaji. Chunked inamaanisha kwamba data kubwa inatumwa kwa mfululizo wa vipande.
Reality
Front-End (load-balance / Reverse Proxy) inasindika content-length au transfer-encoding kichwa na Back-end server inasindika nyingine ikisababisha desyncronization kati ya mifumo 2. Hii inaweza kuwa hatari sana kwani mshambuliaji ataweza kutuma ombi moja kwa reverse proxy ambayo itatafsiriwa na back-end server kama maombi 2 tofauti. Hatari ya mbinu hii inatokana na ukweli kwamba back-end server itaelewa ombile la 2 lililoingizwa kana kwamba lilitoka kwa mteja anayefuata na ombile halisi la mteja huyo litakuwa sehemu ya ombile lililoingizwa.
Particularities
Kumbuka kwamba katika HTTP herufi mpya inaundwa na bytes 2:
Content-Length: Kichwa hiki kinatumia nambari ya desimali kuonyesha idadi ya bytes za mwili wa ombi. Mwili unatarajiwa kumalizika katika herufi ya mwisho, herufi mpya haitahitajika mwishoni mwa ombi.
Transfer-Encoding: Kichwa hiki kinatumia katika mwili nambari ya hexadecimal kuonyesha idadi ya bytes za kipande kinachofuata. Kipande lazima kimalizike na herufi mpya lakini herufi hii mpya haitahesabiwa na kiashiria cha urefu. Mbinu hii ya uhamasishaji lazima ikamilike na kipande cha ukubwa 0 kinachofuatwa na herufi 2 mpya:
0Connection: Kulingana na uzoefu wangu, inapendekezwa kutumia
Connection: keep-alivekwenye ombi la kwanza la HTTP Request Smuggling.
Basic Examples
Wakati wa kujaribu kutumia hii na Burp Suite zima Update Content-Length na Normalize HTTP/1 line endings katika repeater kwa sababu baadhi ya vifaa vinatumia herufi mpya, kurudi kwa gari na maudhui yasiyo sahihi ya urefu.
HTTP request smuggling attacks are crafted by sending ambiguous requests that exploit discrepancies in how front-end and back-end servers interpret the Content-Length (CL) and Transfer-Encoding (TE) headers. These attacks can manifest in different forms, primarily as CL.TE, TE.CL, and TE.TE. Each type represents a unique combination of how the front-end and back-end servers prioritize these headers. The vulnerabilities arise from the servers processing the same request in different ways, leading to unexpected and potentially malicious outcomes.
Basic Examples of Vulnerability Types
CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
Front-End (CL): Inasindika ombi kulingana na kichwa cha
Content-Length.Back-End (TE): Inasindika ombi kulingana na kichwa cha
Transfer-Encoding.Attack Scenario:
Mshambuliaji anatumia ombi ambapo thamani ya kichwa cha
Content-Lengthhaifanani na urefu halisi wa maudhui.Server ya front-end inapeleka ombi lote kwa back-end, kulingana na thamani ya
Content-Length.Server ya back-end inasindika ombi kama kipande kutokana na kichwa cha
Transfer-Encoding: chunked, ikitafsiri data iliyobaki kama ombi tofauti, linalofuata.Example:
TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
Front-End (TE): Inasindika ombi kulingana na kichwa cha
Transfer-Encoding.Back-End (CL): Inasindika ombi kulingana na kichwa cha
Content-Length.Attack Scenario:
Mshambuliaji anatumia ombi la kipande ambapo ukubwa wa kipande (
7b) na urefu halisi wa maudhui (Content-Length: 4) havifanani.Server ya front-end, ikiheshimu
Transfer-Encoding, inapeleka ombi lote kwa back-end.Server ya back-end, ikiheshimu
Content-Length, inasindika tu sehemu ya awali ya ombi (7bbytes), ikiacha iliyobaki kama sehemu ya ombi linalofuata lisilotarajiwa.Example:
TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
Servers: Zote zinasaidia
Transfer-Encoding, lakini moja inaweza kudanganywa kuipuuza kupitia obfuscation.Attack Scenario:
Mshambuliaji anatumia ombi lenye kichwa cha
Transfer-Encodingkilichofichwa.Kulingana na server ipi (front-end au back-end) inashindwa kutambua obfuscation, udhaifu wa CL.TE au TE.CL unaweza kutumika.
Sehemu isiyosindikwa ya ombi, kama inavyoonekana na moja ya servers, inakuwa sehemu ya ombi linalofuata, ikisababisha smuggling.
Example:
CL.CL Scenario (Content-Length used by both Front-End and Back-End):
Servers zote zinashughulikia ombi kulingana na kichwa cha
Content-Lengthpekee.Hali hii kwa kawaida haipelekei smuggling, kwani kuna ulinganifu katika jinsi servers zote zinavyotafsiri urefu wa ombi.
Example:
CL != 0 Scenario:
Inarejelea hali ambapo kichwa cha
Content-Lengthkinapatikana na kina thamani isiyo sifuri, ikionyesha kwamba mwili wa ombi una maudhui.Ni muhimu katika kuelewa na kuunda mashambulizi ya smuggling, kwani inaathiri jinsi servers zinavyotambua mwisho wa ombi.
Example:
Breaking the web server
Mbinu hii pia ni muhimu katika hali ambapo inawezekana kuvunja server ya wavuti wakati wa kusoma data ya awali ya HTTP lakini bila kufunga muunganisho. Kwa njia hii, mwili wa ombi la HTTP utaonekana kama ombile linalofuata la HTTP.
Kwa mfano, kama ilivyoelezwa katika hiki andiko, Katika Werkzeug ilikuwa inawezekana kutuma baadhi ya Unicode herufi na itafanya server kuvunja. Hata hivyo, ikiwa muunganisho wa HTTP ulianzishwa na kichwa Connection: keep-alive, mwili wa ombi hautasomwa na muunganisho utaendelea kuwa wazi, hivyo mwili wa ombi utaonekana kama ombile linalofuata la HTTP.
Forcing via hop-by-hop headers
Kwa kutumia vibaya vichwa vya hop-by-hop unaweza kuonyesha proxy kufuta kichwa cha Content-Length au Transfer-Encoding ili smuggling ya HTTP iwezekane kutumika.
For more information about hop-by-hop headers visit:
hop-by-hop headersFinding HTTP Request Smuggling
Kutambua udhaifu wa HTTP request smuggling mara nyingi kunaweza kufanywa kwa kutumia mbinu za wakati, ambazo zinategemea kuangalia ni muda gani inachukua kwa seva kujibu maombi yaliyobadilishwa. Mbinu hizi ni muhimu hasa kwa kugundua udhaifu wa CL.TE na TE.CL. Mbali na mbinu hizi, kuna mikakati na zana nyingine ambazo zinaweza kutumika kutafuta udhaifu kama huo:
Finding CL.TE Vulnerabilities Using Timing Techniques
Method:
Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
Example:
Observation:
Seva ya mbele inashughulikia ombi kulingana na
Content-Lengthna kukata ujumbe mapema.Seva ya nyuma, ikitarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haitafika, na kusababisha kuchelewesha.
Indicators:
Timeout au ucheleweshaji mrefu katika majibu.
Kupokea kosa la 400 Bad Request kutoka kwa seva ya nyuma, wakati mwingine na maelezo ya kina ya seva.
Finding TE.CL Vulnerabilities Using Timing Techniques
Method:
Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
Example:
Observation:
Seva ya mbele inashughulikia ombi kulingana na
Transfer-Encodingna inapeleka ujumbe mzima.Seva ya nyuma, ikitarajia ujumbe kulingana na
Content-Length, inasubiri data zaidi ambayo haitafika, na kusababisha kuchelewesha.
Other Methods to Find Vulnerabilities
Differential Response Analysis:
Tuma toleo lililobadilishwa kidogo la ombi na uangalie ikiwa majibu ya seva yanatofautiana kwa njia isiyotarajiwa, ikionyesha tofauti ya uchambuzi.
Using Automated Tools:
Zana kama Burp Suite's 'HTTP Request Smuggler' extension zinaweza kujaribu kiotomatiki udhaifu hawa kwa kutuma aina mbalimbali za maombi yasiyo na uwazi na kuchambua majibu.
Content-Length Variance Tests:
Tuma maombi yenye thamani tofauti za
Content-Lengthambazo hazilingani na urefu halisi wa maudhui na uangalie jinsi seva inavyoshughulikia tofauti hizo.Transfer-Encoding Variance Tests:
Tuma maombi yenye vichwa vya
Transfer-Encodingvilivyofichwa au visivyo sahihi na uangalie jinsi seva za mbele na za nyuma zinavyoshughulikia mabadiliko kama hayo.
HTTP Request Smuggling Vulnerability Testing
Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuthibitisha ikiwa maombi ya mteja yanaweza kubadilishwa. Njia rahisi ni kujaribu kuharibu maombi yako, kwa mfano, kufanya ombi kwa / kuleta jibu la 404. Mifano ya CL.TE na TE.CL zilizozungumziwa hapo awali katika Basic Examples zinaonyesha jinsi ya kuharibu ombi la mteja ili kuleta jibu la 404, licha ya mteja kutaka kufikia rasilimali tofauti.
Key Considerations
Wakati wa kujaribu udhaifu wa request smuggling kwa kuingilia maombi mengine, kumbuka:
Distinct Network Connections: Maombi ya "shambulio" na "ya kawaida" yanapaswa kutumwa kupitia muunganisho tofauti wa mtandao. Kutumia muunganisho mmoja kwa yote mawili hakuthibitishi uwepo wa udhaifu.
Consistent URL and Parameters: Jaribu kutumia URLs na majina ya vigezo sawa kwa maombi yote mawili. Programu za kisasa mara nyingi hupeleka maombi kwa seva maalum za nyuma kulingana na URL na vigezo. Kulinganisha haya kunaongeza uwezekano kwamba maombi yote mawili yanashughulikiwa na seva moja, ambayo ni sharti la shambulio lililofanikiwa.
Timing and Racing Conditions: Ombi la "kawaida", lililokusudiwa kugundua kuingilia kutoka kwa ombi la "shambulio", linashindana na maombi mengine ya programu yanayoendelea. Kwa hivyo, tuma ombi la "kawaida" mara moja baada ya ombi la "shambulio". Programu zenye shughuli nyingi zinaweza kuhitaji majaribio kadhaa kwa uthibitisho wa udhaifu.
Load Balancing Challenges: Seva za mbele zinazofanya kazi kama wasambazaji wa mzigo zinaweza kugawa maombi kati ya mifumo mbalimbali ya nyuma. Ikiwa maombi ya "shambulio" na "ya kawaida" yanakutana kwenye mifumo tofauti, shambulio halitafanikiwa. Kipengele hiki cha usambazaji wa mzigo kinaweza kuhitaji majaribio kadhaa kuthibitisha udhaifu.
Unintended User Impact: Ikiwa shambulio lako kwa bahati mbaya linaathiri ombi la mtumiaji mwingine (sio ombi la "kawaida" ulilotuma kwa ajili ya kugundua), hii inaonyesha kuwa shambulio lako limeathiri mtumiaji mwingine wa programu. Kujaribu mara kwa mara kunaweza kuharibu watumiaji wengine, hivyo inahitajika kuwa na mbinu ya tahadhari.
Abusing HTTP Request Smuggling
Circumventing Front-End Security via HTTP Request Smuggling
Wakati mwingine, proxies za mbele zinaweka hatua za usalama, zikichunguza maombi yanayoingia. Hata hivyo, hatua hizi zinaweza kupuuziliwa mbali kwa kutumia HTTP Request Smuggling, kuruhusu ufikiaji usioidhinishwa kwa maeneo yaliyopigwa marufuku. Kwa mfano, kufikia /admin kunaweza kuwa marufuku nje, huku proxy ya mbele ikizuia juhudi kama hizo. Hata hivyo, proxy hii inaweza kupuuzilia mbali kuangalia maombi yaliyojumuishwa ndani ya ombi la HTTP lililosafirishwa, ikiacha pengo la kupita marufuku haya.
Fikiria mifano ifuatayo inayoonyesha jinsi HTTP Request Smuggling inaweza kutumika kupita hatua za usalama za mbele, hasa ikilenga njia ya /admin ambayo kwa kawaida inalindwa na proxy ya mbele:
CL.TE Example
Katika shambulio la CL.TE, kichwa cha Content-Length kinatumika kwa ombi la awali, wakati ombi lililoingizwa linatumia kichwa cha Transfer-Encoding: chunked. Proxy ya mbele inashughulikia ombi la awali la POST lakini inashindwa kukagua ombi lililoingizwa la GET /admin, ikiruhusu ufikiaji usioidhinishwa wa njia ya /admin.
TE.CL Mfano
Kinyume chake, katika shambulio la TE.CL, ombi la awali la POST linatumia Transfer-Encoding: chunked, na ombi lililoingizwa linasindika kulingana na kichwa cha Content-Length. Kama ilivyo katika shambulio la CL.TE, proxy ya mbele inapuuzilia mbali ombi la GET /admin lililosafirishwa, bila kukusudia ikitoa ufikiaji kwa njia iliyo na vizuizi ya /admin.
Kufichua uandishi wa ombi la mbele
Programu mara nyingi hutumia seva ya mbele kubadilisha maombi yanayoingia kabla ya kuyapeleka kwa seva ya nyuma. Marekebisho ya kawaida yanajumuisha kuongeza vichwa, kama vile X-Forwarded-For: <IP ya mteja>, ili kupeleka IP ya mteja kwa seva ya nyuma. Kuelewa marekebisho haya kunaweza kuwa muhimu, kwani kunaweza kufichua njia za kuzidi ulinzi au kufichua taarifa au maeneo yaliyofichwa.
Ili kuchunguza jinsi proxy inavyobadilisha ombi, pata parameter ya POST ambayo seva ya nyuma inarudisha katika jibu. Kisha, tengeneza ombi, ukitumia parameter hii mwisho, kama ifuatavyo:
Katika muundo huu, vipengele vya ombi vinavyofuata vinaongezwa baada ya search=, ambayo ni parameter inayojitokeza katika jibu. Hii itafichua vichwa vya ombi la baadaye.
Ni muhimu kulinganisha kichwa cha Content-Length cha ombi lililo ndani na urefu halisi wa maudhui. Kuanzia na thamani ndogo na kuongezeka taratibu ni bora, kwani thamani ya chini sana itakata data iliyojitokeza, wakati thamani ya juu sana inaweza kusababisha ombi kufeli.
Tekniki hii pia inatumika katika muktadha wa udhaifu wa TE.CL, lakini ombi linapaswa kumalizika na search=\r\n0. Bila kujali wahusika wa newline, thamani zitajumuishwa kwenye parameter ya utafutaji.
Njia hii hasa inatumika kuelewa mabadiliko ya ombi yaliyofanywa na proxy ya mbele, kimsingi ikifanya uchunguzi wa kujiongoza.
Kukamata ombi za watumiaji wengine
Ni rahisi kukamata ombi za mtumiaji anayefuata kwa kuongeza ombi maalum kama thamani ya parameter wakati wa operesheni ya POST. Hapa kuna jinsi hii inaweza kufanywa:
Kwa kuongeza ombi lifuatalo kama thamani ya parameter, unaweza kuhifadhi ombi la mteja anayefuata:
Katika hali hii, parameta ya maoni inakusudia 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, mbinu hii ina mipaka. Kwa ujumla, inakamata data tu hadi kwenye kipimo cha parameta kilichotumika katika ombi lililosafirishwa. Kwa uwasilishaji wa fomu iliyohifadhiwa kwenye URL, kipimo hiki ni herufi &. Hii ina maana kwamba maudhui yaliyokamatwa kutoka kwa ombi la mtumiaji waathirika yatakoma kwenye & ya kwanza, ambayo inaweza hata kuwa sehemu ya mfuatano wa swali.
Zaidi ya hayo, inafaa kutaja kwamba mbinu hii pia inapatikana na udhaifu wa TE.CL. Katika hali kama hizo, ombi linapaswa kumalizika na search=\r\n0. Bila kujali wahusika wa mstari mpya, thamani zitajumuishwa kwenye parameta ya utafutaji.
Kutumia HTTP request smuggling kutekeleza XSS iliyorejelewa
HTTP Request Smuggling inaweza kutumika kutekeleza kurasa za wavuti zilizo hatarini kwa Reflected XSS, ikitoa faida kubwa:
Maingiliano na watumiaji wa lengo hayahitajiki.
Inaruhusu matumizi ya XSS katika sehemu za ombi ambazo kwa kawaida hazipatikani, kama vichwa vya ombi la HTTP.
Katika hali ambapo tovuti inakabiliwa na Reflected XSS kupitia kichwa cha User-Agent, mzigo ufuatao unaonyesha jinsi ya kutumia udhaifu huu:
This payload is structured to exploit the vulnerability by:
Kuanzisha ombi la
POST, ambalo linaonekana kuwa la kawaida, lenye kichwa chaTransfer-Encoding: chunkedkuashiria mwanzo wa smuggling.Kufuatia na
0, ikionyesha mwisho wa ujumbe wa chunked.Kisha, ombi la smuggling
GETlinaanzishwa, ambapo kichwa chaUser-Agentkinatolewa na script,<script>alert(1)</script>, ikichochea XSS wakati seva inashughulikia ombi hili linalofuata.
Kwa kubadilisha User-Agent kupitia smuggling, payload inakwepa vikwazo vya kawaida vya ombi, hivyo ikitumia udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.
HTTP/0.9
Ikiwa maudhui ya mtumiaji yanarejelewa katika jibu lenye Content-type kama text/plain, kuzuia utekelezaji wa XSS. Ikiwa seva inasaidia HTTP/0.9 inaweza kuwa inawezekana kupita hii!
Toleo la HTTP/0.9 lilikuwa kabla ya 1.0 na linatumia tu GET verbs na halijibu na headers, bali tu mwili.
Katika hii andiko, hii ilitumiwa vibaya na smuggling ya ombi na nukta ya hatari ambayo itajibu na maudhui ya mtumiaji ili kusmuggle ombi na HTTP/0.9. Kigezo ambacho kitarejelewa katika jibu kilikuwa na jibu bandia la HTTP/1.1 (pamoja na headers na mwili) hivyo jibu litakuwa na msimbo wa JS unaoweza kutekelezwa kwa Content-Type ya text/html.
Exploiting On-site Redirects with HTTP Request Smuggling
Mifumo mara nyingi hupeleka kutoka URL moja hadi nyingine kwa kutumia jina la mwenyeji kutoka kichwa cha Host katika URL ya kupeleka. Hii ni ya kawaida na seva za wavuti kama Apache na IIS. Kwa mfano, kuomba folda bila slash ya mwisho kunasababisha kupelekwa kuhusisha slash:
Matokeo katika:
Ingawa inaonekana haina madhara, tabia hii inaweza kudhibitiwa kwa kutumia HTTP request smuggling ili kuwahamisha watumiaji kwenye tovuti ya nje. Kwa mfano:
Hii ombi lililosafirishwa linaweza kusababisha ombi la mtumiaji linalofuatia kushughulikiwa kuhamasishwa kwa tovuti inayodhibitiwa na mshambuliaji:
Matokeo katika:
Katika hali hii, ombi la mtumiaji la faili la JavaScript linachukuliwa. Mshambuliaji anaweza kuathiri mtumiaji kwa kutoa JavaScript mbaya kama jibu.
Kutumia Upoisonaji wa Kivinjari cha Mtandao kupitia HTTP Request Smuggling
Upoisonaji wa kivinjari cha mtandao unaweza kutekelezwa ikiwa sehemu yoyote ya miundombinu ya mbele inahifadhi maudhui, kawaida ili kuboresha utendaji. Kwa kubadilisha jibu la seva, inawezekana kuponya kivinjari.
Awali, tuliona jinsi majibu ya seva yanaweza kubadilishwa ili kurudisha kosa la 404 (rejelea Mifano ya Msingi). Vivyo hivyo, inawezekana kumdanganya seva kutoa maudhui ya /index.html kama jibu la ombi la /static/include.js. Kwa hivyo, maudhui ya /static/include.js yanabadilishwa katika kivinjari na yale ya /index.html, na kufanya /static/include.js isiweze kupatikana kwa watumiaji, ambayo inaweza kusababisha Denial of Service (DoS).
Teknolojia hii inakuwa na nguvu hasa ikiwa kuna udhaifu wa Open Redirect ulio gundulika au ikiwa kuna mwelekeo wa ndani kwa mwelekeo wazi. Udhaifu kama huu unaweza kutumiwa kubadilisha maudhui yaliyohifadhiwa ya /static/include.js na script chini ya udhibiti wa mshambuliaji, kwa msingi inaruhusu shambulio la Cross-Site Scripting (XSS) dhidi ya wateja wote wanaotafuta /static/include.js iliyosasishwa.
Hapa kuna mfano wa kutumia upoisonaji wa kivinjari pamoja na mwelekeo wa ndani kwa mwelekeo wazi. Lengo ni kubadilisha maudhui ya kivinjari ya /static/include.js ili kutoa msimbo wa JavaScript unaodhibitiwa na mshambuliaji:
Note the embedded request targeting /post/next?postId=3. This request will be redirected to /post?postId=4, utilizing the Host header value to determine the domain. By altering the Host header, the attacker can redirect the request to their domain (on-site redirect to open redirect).
After successful socket poisoning, a GET request for /static/include.js should be initiated. This request will be contaminated by the prior on-site redirect to open redirect request and fetch the content of the script controlled by the attacker.
Subsequently, any request for /static/include.js will serve the cached content of the attacker's script, effectively launching a broad XSS attack.
Using HTTP request smuggling to perform web cache deception
What is the difference between web cache poisoning and web cache deception?
In web cache poisoning, the attacker causes the application to store some malicious content in the cache, and this content is served from the cache to other application users.
In web cache deception, the attacker causes the application to store some sensitive content belonging to another user in the cache, and the attacker then retrieves this content from the cache.
Mshambuliaji anaunda ombi lililofichwa ambalo linapata maudhui nyeti ya mtumiaji. Fikiria mfano ufuatao:
Ikiwa ombi hili lililofichwa linachafua kipengee cha cache kilichokusudiwa kwa maudhui ya statiki (mfano, /someimage.png), data nyeti za mwathirika kutoka /private/messages zinaweza kuhifadhiwa chini ya kipengee cha cache cha maudhui ya statiki. Kwa hivyo, mshambuliaji anaweza kupata data hizi nyeti zilizohifadhiwa.
Kutumia TRACE kupitia HTTP Request Smuggling
Katika chapisho hili inapendekezwa kwamba ikiwa seva ina njia ya TRACE iliyoanzishwa inaweza kuwa inawezekana kuitumia vibaya na HTTP Request Smuggling. Hii ni kwa sababu njia hii itarejesha kichwa chochote kilichotumwa kwa seva kama sehemu ya mwili wa jibu. Kwa mfano:
Nitapeleka jibu kama:
Mfano wa jinsi ya kutumia tabia hii ungekuwa kuficha kwanza ombi la HEAD. Ombi hili litajibiwa kwa vichwa vya ombi la GET (Content-Type miongoni mwao). Na kuficha moja kwa moja baada ya HEAD ombi la TRACE, ambalo litakuwa linarejelea 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 kuonyesha data isiyo na mipaka katika jibu.
Jibu hili litatumwa kwa ombi linalofuata kupitia muunganisho, hivyo hili linaweza kutumika katika faili ya JS iliyohifadhiwa kwa mfano kuingiza msimbo wa JS usio na mipaka.
Kutumia TRACE kupitia HTTP Response Splitting
Endelea kufuata hii chapisho inapendekezwa njia nyingine ya kutumia mbinu ya TRACE. Kama ilivyotajwa, kuficha ombi la HEAD na ombi la TRACE inawezekana kudhibiti baadhi ya data inayorejelewa katika jibu la ombi la HEAD. Urefu wa mwili wa ombi la HEAD kimsingi unatajwa katika kichwa cha Content-Length na unaundwa na jibu la ombi la TRACE.
Hivyo, wazo jipya lingekuwa kwamba, kwa kujua Content-Length hii na data iliyotolewa katika jibu la TRACE, inawezekana kufanya jibu la TRACE liwe na jibu halali la HTTP baada ya byte ya mwisho ya Content-Length, ikiruhusu mshambuliaji kudhibiti kabisa ombi kwa jibu linalofuata (ambalo linaweza kutumika kufanya uharibifu wa cache).
Mfano:
Itazalisha majibu haya (zingatia jinsi jibu la HEAD lina Content-Length ikifanya jibu la TRACE kuwa sehemu ya mwili wa HEAD na mara tu Content-Length ya HEAD inapoisha, jibu halali la HTTP linapaswa kuingizwa):
Kuandaa HTTP Request Smuggling na HTTP Response Desynchronisation
Je, umepata udhaifu wa HTTP Request Smuggling na hujui jinsi ya kuutumia. Jaribu njia hizi nyingine za kutumia:
HTTP Response Smuggling / DesyncMbinu Nyingine za HTTP Request Smuggling
Browser HTTP Request Smuggling (Upande wa Mteja)
Request Smuggling katika HTTP/2 Downgrades
Turbo intruder scripts
CL.TE
Kutoka https://hipotermia.pw/bb/http-desync-idor
TE.CL
Kutoka: https://hipotermia.pw/bb/http-desync-account-takeover
Tools
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Chombo hiki ni Fuzzer ya HTTP inayotumia sarufi ambayo ni muhimu katika kutafuta tofauti za ajabu za kuhamasisha maombi.
References
Last updated
