HTTP Request Smuggling / HTTP Desync Attack
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Hierdie kwesbaarheid gebeur wanneer 'n desynkronisasie tussen front-end proxies en die back-end bediener 'n aanvaller toelaat om 'n HTTP versoek te stuur wat as 'n enkele versoek deur die front-end proxies (laai balanseer / omgekeerde proxy) en as 2 versoeke deur die back-end bediener geïterpreteer sal word. Dit laat 'n gebruiker toe om die volgende versoek wat by die back-end bediener aankom na syne te wysig.
As 'n boodskap ontvang word met beide 'n Transfer-Encoding kopveld en 'n Content-Length kopveld, moet laasgenoemde geïgnoreer word.
Content-Length
Die Content-Length entiteit kopveld dui die grootte van die entiteit-liggaam, in bytes, wat na die ontvanger gestuur word, aan.
Transfer-Encoding: chunked
Die Transfer-Encoding kopveld spesifiseer die vorm van kodering wat gebruik word om die payload liggaam veilig na die gebruiker oor te dra. Chunked beteken dat groot data in 'n reeks stukke gestuur word.
Die Front-End (n laai-balanseer / Omgekeerde Proxy) verwerk die content-length of die transfer-encoding kopveld en die Back-end bediener verwerk die ander een wat 'n desynkronisasie tussen die 2 stelsels veroorsaak. Dit kan baie krities wees aangesien 'n aanvaller in staat sal wees om een versoek na die omgekeerde proxy te stuur wat deur die back-end bediener as 2 verskillende versoeke geïterpreteer sal word. Die gevaar van hierdie tegniek lê in die feit dat die back-end bediener die 2de versoek wat ingesluit is sal interpreteer asof dit van die volgende kliënt gekom het en die werklike versoek van daardie kliënt sal deel wees van die ingeslote versoek.
Onthou dat in HTTP 'n nuwe lyn karakter bestaan uit 2 bytes:
Content-Length: Hierdie kopveld gebruik 'n desimale getal om die aantal van die bytes van die liggaam van die versoek aan te dui. Die liggaam word verwag om in die laaste karakter te eindig, 'n nuwe lyn is nie nodig aan die einde van die versoek.
Transfer-Encoding: Hierdie kopveld gebruik in die liggaam 'n heksadesimale getal om die aantal van die bytes van die volgende stuk aan te dui. Die stuk moet eindig met 'n nuwe lyn maar hierdie nuwe lyn word nie getel deur die lengte-indikator nie. Hierdie oordragmetode moet eindig met 'n stuk van grootte 0 gevolg deur 2 nuwe lyne: 0
Connection: Gebaseer op my ervaring word dit aanbeveel om Connection: keep-alive op die eerste versoek van die versoek Smuggling te gebruik.
Wanneer jy probeer om dit met Burp Suite te benut, deaktiveer Update Content-Length en Normalize HTTP/1 line endings in die herhaler omdat sommige gadgets nuwe lyne, karakters en verkeerd gevormde content-lengths misbruik.
HTTP versoek smuggling aanvalle word geskep deur ambigue versoeke te stuur wat verskille in hoe front-end en back-end bedieners die Content-Length (CL) en Transfer-Encoding (TE) kopvelde interpreteer, benut. Hierdie aanvalle kan in verskillende vorme manifesteer, hoofsaaklik as CL.TE, TE.CL, en TE.TE. Elke tipe verteenwoordig 'n unieke kombinasie van hoe die front-end en back-end bedieners hierdie kopvelde prioriteer. Die kwesbaarhede ontstaan uit die bedieners wat dieselfde versoek op verskillende maniere verwerk, wat lei tot onverwagte en potensieel kwaadwillige uitkomste.
By die vorige tabel moet jy die TE.0 tegniek voeg, soos CL.0 tegniek maar met Transfer Encoding.
Front-End (CL): Verwerk die versoek gebaseer op die Content-Length kopveld.
Back-End (TE): Verwerk die versoek gebaseer op die Transfer-Encoding kopveld.
Aanval Scenario:
Die aanvaller stuur 'n versoek waar die waarde van die Content-Length kopveld nie ooreenstem met die werklike inhoud lengte nie.
Die front-end bediener stuur die hele versoek na die back-end, gebaseer op die Content-Length waarde.
Die back-end bediener verwerk die versoek as chunked weens die Transfer-Encoding: chunked kopveld, wat die oorblywende data as 'n aparte, daaropvolgende versoek interpreteer.
Voorbeeld:
Front-End (TE): Verwerk die versoek gebaseer op die Transfer-Encoding kopveld.
Back-End (CL): Verwerk die versoek gebaseer op die Content-Length kopveld.
Aanval Scenario:
Die aanvaller stuur 'n chunked versoek waar die stuk grootte (7b) en werklike inhoud lengte (Content-Length: 4) nie ooreenstem nie.
Die front-end bediener, wat Transfer-Encoding eerbiedig, stuur die hele versoek na die back-end.
Die back-end bediener, wat Content-Length respekteer, verwerk slegs die aanvanklike deel van die versoek (7b bytes), wat die res as deel van 'n onbedoelde daaropvolgende versoek laat.
Voorbeeld:
Bedieners: Beide ondersteun Transfer-Encoding, maar een kan mislei word om dit te ignoreer via obfuskering.
Aanval Scenario:
Die aanvaller stuur 'n versoek met obfuscated Transfer-Encoding kopvelde.
Afhangende van watter bediener (front-end of back-end) nie die obfuskering herken nie, kan 'n CL.TE of TE.CL kwesbaarheid benut word.
Die onverwerkte deel van die versoek, soos gesien deur een van die bedieners, word deel van 'n daaropvolgende versoek, wat lei tot smuggling.
Voorbeeld:
Beide bedieners verwerk die versoek gebaseer slegs op die Content-Length kopveld.
Hierdie scenario lei tipies nie tot smuggling nie, aangesien daar 'n ooreenstemming is in hoe beide bedieners die versoek lengte interpreteer.
Voorbeeld:
Verwys na scenario's waar die Content-Length kopveld teenwoordig is en 'n waarde anders as nul het, wat aandui dat die versoek liggaam inhoud het. Die back-end ignoreer die Content-Length kopveld (wat as 0 behandel word), maar die front-end parse dit.
Dit is belangrik om te verstaan en smuggling aanvalle te skep, aangesien dit beïnvloed hoe bedieners die einde van 'n versoek bepaal.
Voorbeeld:
Soos die vorige een maar met TE
Tegniek gerapporteer hier
Voorbeeld:
Hierdie tegniek is ook nuttig in scenario's waar dit moontlik is om 'n webbediener te breek terwyl die aanvanklike HTTP-data gelees word maar sonder om die verbinding te sluit. Op hierdie manier sal die liggaam van die HTTP-versoek as die volgende HTTP-versoek beskou word.
Byvoorbeeld, soos verduidelik in hierdie skrywe, was dit in Werkzeug moontlik om 'n paar Unicode karakters te stuur en dit sal die bediener breek. As die HTTP-verbinding egter met die kop Connection: keep-alive geskep is, sal die liggaam van die versoek nie gelees word nie en die verbinding sal steeds oop wees, so die liggaam van die versoek sal as die volgende HTTP-versoek hanteer word.
Deur hop-by-hop koppe te misbruik, kan jy die proxy aandui om die kop Content-Length of Transfer-Encoding te verwyder sodat 'n HTTP-versoek smuggling misbruik kan word.
For meer inligting oor hop-by-hop headers besoek:
hop-by-hop headersDie identifisering van HTTP request smuggling kwesbaarhede kan dikwels bereik word deur tydtegnieke, wat staatmaak op die waarneming van hoe lank dit neem vir die bediener om op gemanipuleerde versoeke te reageer. Hierdie tegnieke is veral nuttig om CL.TE en TE.CL kwesbaarhede te ontdek. Benewens hierdie metodes, is daar ander strategieë en gereedskap wat gebruik kan word om sulke kwesbaarhede te vind:
Metode:
Stuur 'n versoek wat, indien die toepassing kwesbaar is, die agtergrondbediener sal dwing om vir addisionele data te wag.
Voorbeeld:
Waarneming:
Die voorgrondbediener verwerk die versoek gebaseer op Content-Length en sny die boodskap voortydig af.
Die agtergrondbediener, wat 'n chunked boodskap verwag, wag vir die volgende chunk wat nooit aankom nie, wat 'n vertraging veroorsaak.
Aanduiders:
Timeouts of lang vertraging in reaksie.
Ontvang 'n 400 Bad Request fout van die agtergrondbediener, soms met gedetailleerde bediener-inligting.
Metode:
Stuur 'n versoek wat, indien die toepassing kwesbaar is, die agtergrondbediener sal dwing om vir addisionele data te wag.
Voorbeeld:
Waarneming:
Die voorgrondbediener verwerk die versoek gebaseer op Transfer-Encoding en stuur die hele boodskap voort.
Die agtergrondbediener, wat 'n boodskap gebaseer op Content-Length verwag, wag vir addisionele data wat nooit aankom nie, wat 'n vertraging veroorsaak.
Differensiële Responsanalise:
Stuur effens verskillende weergawes van 'n versoek en kyk of die bediener se reaksies op 'n onverwagte manier verskil, wat 'n parsingsverskil aandui.
Gebruik van Geoutomatiseerde Gereedskap:
Gereedskap soos Burp Suite se 'HTTP Request Smuggler' uitbreiding kan outomaties toets vir hierdie kwesbaarhede deur verskillende vorme van ambigue versoeke te stuur en die reaksies te analiseer.
Content-Length Variansie Toetse:
Stuur versoeke met verskillende Content-Length waardes wat nie ooreenstem met die werklike inhoudslengte nie en kyk hoe die bediener sulke wanbalanse hanteer.
Transfer-Encoding Variansie Toetse:
Stuur versoeke met obfuskeerde of misvormde Transfer-Encoding headers en monitor hoe verskillend die voorgrond- en agtergrondbedieners op sulke manipulasies reageer.
Nadat die doeltreffendheid van tydtegnieke bevestig is, is dit noodsaaklik om te verifieer of kliëntversoeke gemanipuleer kan word. 'n Eenvoudige metode is om te probeer om jou versoeke te vergiftig, byvoorbeeld, om 'n versoek na / te maak wat 'n 404 reaksie oplewer. Die CL.TE en TE.CL voorbeelde wat voorheen bespreek is in Basiese Voorbeelde demonstreer hoe om 'n kliënt se versoek te vergiftig om 'n 404 reaksie uit te lok, ten spyte van die kliënt se poging om toegang tot 'n ander hulpbron te verkry.
Belangrike Oorwegings
Wanneer jy toets vir request smuggling kwesbaarhede deur ander versoeke te beïnvloed, hou in gedagte:
Verskillende Netwerkverbindinge: Die "aanval" en "normale" versoeke moet oor verskillende netwerkverbindinge gestuur word. Die gebruik van dieselfde verbinding vir albei valideer nie die kwesbaarheid se teenwoordigheid nie.
Konstante URL en Parameters: Probeer om identiese URL's en parametername vir albei versoeke te gebruik. Moderne toepassings lei dikwels versoeke na spesifieke agtergrondbedieners gebaseer op URL en parameters. Ooreenstemming hiervan verhoog die waarskynlikheid dat albei versoeke deur dieselfde bediener verwerk word, 'n voorvereiste vir 'n suksesvolle aanval.
Tyd en Wedrenstoestande: Die "normale" versoek, wat bedoel is om interferensie van die "aanval" versoek te detecteer, kompeteer teen ander gelyktydige toepassingsversoeke. Stuur dus die "normale" versoek onmiddellik na die "aanval" versoek. Besige toepassings mag verskeie pogings vereis vir beslissende kwesbaarheid bevestiging.
Laai Balansuitdagings: Voorgrondbedieners wat as laai-balansers optree, mag versoeke oor verskillende agtergrondstelsels versprei. As die "aanval" en "normale" versoeke op verskillende stelsels eindig, sal die aanval nie slaag nie. Hierdie laai-balans aspek mag verskeie pogings vereis om 'n kwesbaarheid te bevestig.
Onbedoelde Gebruikerimpak: As jou aanval per ongeluk 'n ander gebruiker se versoek beïnvloed (nie die "normale" versoek wat jy gestuur het vir detectie nie), dui dit aan dat jou aanval 'n ander toepassingsgebruiker beïnvloed het. Voortdurende toetsing kan ander gebruikers ontwrig, wat 'n versigtige benadering vereis.
Soms handhaaf voorgrondproxies sekuriteitsmaatreëls, wat inkomende versoeke ondersoek. Hierdie maatreëls kan egter omseil word deur HTTP Request Smuggling te benut, wat ongeoorloofde toegang tot beperkte eindpunte moontlik maak. Byvoorbeeld, toegang tot /admin mag ekstern verbied wees, met die voorgrondproxy wat aktief sulke pogings blokkeer. Nietemin mag hierdie proxy versuim om ingebedde versoeke binne 'n gesmokkelde HTTP versoek te ondersoek, wat 'n leemte laat om hierdie beperkings te omseil.
Oorweeg die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om voorgrondsekuriteitsbeheer te omseil, spesifiek teiken die /admin pad wat tipies deur die voorgrondproxy beskerm word:
CL.TE Voorbeeld
In die CL.TE-aanval word die Content-Length kop vir die aanvanklike versoek benut, terwyl die daaropvolgende ingebedde versoek die Transfer-Encoding: chunked kop gebruik. Die front-end proxy verwerk die aanvanklike POST versoek, maar slaag nie daarin om die ingebedde GET /admin versoek te inspekteer nie, wat ongeoorloofde toegang tot die /admin pad toelaat.
TE.CL Voorbeeld
Conversely, in the TE.CL-aanval, die aanvanklike POST versoek gebruik Transfer-Encoding: chunked, en die daaropvolgende ingebedde versoek word verwerk op grond van die Content-Length kop. Soos in die CL.TE-aanval, oorsien die front-end proxy die gesmokkelde GET /admin versoek, wat per ongeluk toegang tot die beperkte /admin pad verleen.
Toepassings gebruik dikwels 'n front-end bediener om inkomende versoeke te wysig voordat dit aan die agterkant bediener oorgedra word. 'n Tipiese wysiging behels die toevoeging van koppe, soos X-Forwarded-For: <IP van die kliënt>, om die kliënt se IP aan die agterkant oor te dra. Om hierdie wysigings te verstaan, kan van kardinale belang wees, aangesien dit maniere kan onthul om beskermings te omseil of verborgene inligting of eindpunte te ontdek.
Om te ondersoek hoe 'n proxy 'n versoek verander, vind 'n POST parameter wat die agterkant in die antwoord weergee. Skep dan 'n versoek, met hierdie parameter laaste, soortgelyk aan die volgende:
In hierdie struktuur word daaropvolgende versoekkomponente bygevoeg na search=, wat die parameter is wat in die antwoord weerspieël word. Hierdie weerspieëling sal die koptekste van die daaropvolgende versoek blootstel.
Dit is belangrik om die Content-Length koptekst van die geneste versoek te belyn met die werklike inhoudslengte. Dit is raadsaam om met 'n klein waarde te begin en geleidelik te verhoog, aangesien 'n te lae waarde die weerspieëlde data sal afsnip, terwyl 'n te hoë waarde die versoek kan laat misluk.
Hierdie tegniek is ook toepaslik in die konteks van 'n TE.CL kwesbaarheid, maar die versoek moet eindig met search=\r\n0. Ongeag die nuwe reël karakters, sal die waardes by die soekparameter gevoeg word.
Hierdie metode dien hoofsaaklik om die versoekwysigings wat deur die voorpunt-proxy gemaak is, te verstaan, en voer in wese 'n selfgerigte ondersoek uit.
Dit is haalbaar om die versoeke van die volgende gebruiker te vang deur 'n spesifieke versoek as die waarde van 'n parameter tydens 'n POST-operasie by te voeg. Hier is hoe dit gedoen kan word:
Deur die volgende versoek as die waarde van 'n parameter by te voeg, kan jy die daaropvolgende kliënt se versoek stoor:
In hierdie scenario is die comment parameter bedoel om die inhoud binne 'n pos se kommentaarafdeling op 'n publiek toeganklike bladsy te stoor. Gevolglik sal die inhoud van die daaropvolgende versoek as 'n kommentaar verskyn.
Hierdie tegniek het egter beperkings. Oor die algemeen vang dit data slegs tot by die parameter-afskeid wat in die gesmugde versoek gebruik word. Vir URL-gecodeerde vormindienings is hierdie afskeid die & karakter. Dit beteken dat die gevangenis inhoud van die slagoffer gebruiker se versoek by die eerste & sal stop, wat selfs deel van die vrae string kan wees.
Boonop is dit die moeite werd om op te let dat hierdie benadering ook lewensvatbaar is met 'n TE.CL kwesbaarheid. In sulke gevalle moet die versoek eindig met search=\r\n0. Ongeag van nuwe reël karakters, sal die waardes by die soekparameter gevoeg word.
HTTP Request Smuggling kan benut word om webblaaie wat kwesbaar is vir Weerspieëlde XSS te ontgin, wat beduidende voordele bied:
Interaksie met die teiken gebruikers is nie nodig nie.
Dit stel die ontginning van XSS in dele van die versoek wat normaalweg ontoeganklik is, soos HTTP versoek koptekste, moontlik.
In scenario's waar 'n webwerf kwesbaar is vir Weerspieëlde XSS deur die User-Agent koptekst, demonstreer die volgende payload hoe om hierdie kwesbaarheid te ontgin:
Hierdie payload is gestruktureer om die kwesbaarheid te benut deur:
'n POST versoek te begin, blykbaar tipies, met 'n Transfer-Encoding: chunked kop om die begin van smuggling aan te dui.
Volg met 'n 0, wat die einde van die chunked boodskapliggaam aandui.
Dan word 'n gesmugde GET versoek bekendgestel, waar die User-Agent kop met 'n skrip, <script>alert(1)</script>, ingespuit word, wat die XSS aktiveer wanneer die bediener hierdie daaropvolgende versoek verwerk.
Deur die User-Agent deur smuggling te manipuleer, omseil die payload normale versoekbeperkings, en benut dus die Reflected XSS kwesbaarheid op 'n nie-standaard maar effektiewe manier.
In die geval dat die gebruikersinhoud in 'n antwoord met 'n Content-type soos text/plain weerspieël word, wat die uitvoering van die XSS voorkom. As die bediener HTTP/0.9 ondersteun, mag dit moontlik wees om dit te omseil!
Die weergawe HTTP/0.9 was voorheen die 1.0 en gebruik slegs GET werkwoorde en antwoord nie met koppe nie, net die liggaam.
In hierdie skrywe, is dit misbruik met 'n versoek smuggling en 'n kwesbare eindpunt wat met die invoer van die gebruiker sal antwoordgee om 'n versoek met HTTP/0.9 te smuggle. Die parameter wat in die antwoord weerspieël sal word, het 'n valse HTTP/1.1 antwoord (met koppe en liggaam) bevat sodat die antwoord geldige uitvoerbare JS-kode met 'n Content-Type van text/html sal bevat.
Toepassings lei dikwels van een URL na 'n ander deur die hostname van die Host kop in die omleidings-URL te gebruik. Dit is algemeen met webbedieners soos Apache en IIS. Byvoorbeeld, om 'n gids sonder 'n agterste schuif aan te vra, lei tot 'n omleiding om die schuif in te sluit:
Resultate in:
Hoewel dit op die oog af onskadelik lyk, kan hierdie gedrag gemanipuleer word met behulp van HTTP request smuggling om gebruikers na 'n eksterne webwerf te herlei. Byvoorbeeld:
Hierdie gesmugde versoek kan veroorsaak dat die volgende verwerkte gebruikersversoek na 'n aanvaller-beheerde webwerf omgerig word:
Resultate in:
In hierdie scenario word 'n gebruiker se versoek vir 'n JavaScript-lêer gekaap. Die aanvaller kan moontlik die gebruiker kompromitteer deur kwaadwillige JavaScript in antwoord te dien.
Web cache poisoning kan uitgevoer word as enige komponent van die front-end infrastruktuur inhoud kas om prestasie te verbeter. Deur die bediener se antwoord te manipuleer, is dit moontlik om die cache te vergiftig.
Voorheen het ons gesien hoe bediener-antwoorde verander kan word om 'n 404-fout te retourneer (verwys na Basic Examples). Op soortgelyke wyse is dit haalbaar om die bediener te mislei om /index.html-inhoud te lewer in antwoord op 'n versoek vir /static/include.js. Gevolglik word die inhoud van /static/include.js in die kas vervang met dié van /index.html, wat /static/include.js ontoeganklik maak vir gebruikers, wat moontlik kan lei tot 'n Denial of Service (DoS).
Hierdie tegniek word veral kragtig as 'n Open Redirect-kwesbaarheid ontdek word of as daar 'n op-site omleiding na 'n oop omleiding is. Sulke kwesbaarhede kan benut word om die gekaste inhoud van /static/include.js te vervang met 'n skrip onder die aanvaller se beheer, wat essensieel 'n wye Cross-Site Scripting (XSS) aanval teen alle kliënte wat die opgedateerde /static/include.js versoek, moontlik maak.
Hieronder is 'n illustrasie van die benutting van cache poisoning gekombineer met 'n op-site omleiding na oop omleiding. Die doel is om die kasinhoud van /static/include.js te verander om JavaScript-kode te dien wat deur die aanvaller beheer word:
Let wel die ingebedde versoek wat op /post/next?postId=3 teiken. Hierdie versoek sal herlei word na /post?postId=4, wat die Host header waarde gebruik om die domein te bepaal. Deur die Host header te verander, kan die aanvaller die versoek na hul domein herlei (on-site redirect to open redirect).
Na suksesvolle socket poisoning, moet 'n GET request vir /static/include.js geïnisieer word. Hierdie versoek sal besmet wees deur die vorige on-site redirect to open redirect versoek en die inhoud van die skrip wat deur die aanvaller beheer word, opvra.
Daarna sal enige versoek vir /static/include.js die gekapte inhoud van die aanvaller se skrip dien, wat effektief 'n breë XSS-aanval ontketen.
Wat is die verskil tussen web cache poisoning en web cache misleiding?
In web cache poisoning veroorsaak die aanvaller dat die toepassing 'n paar kwaadwillige inhoud in die cache stoor, en hierdie inhoud word vanaf die cache aan ander toepassingsgebruikers bedien.
In web cache deception veroorsaak die aanvaller dat die toepassing 'n paar sensitiewe inhoud wat aan 'n ander gebruiker behoort in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.
Die aanvaller vervaardig 'n gesmokkelde versoek wat sensitiewe gebruiker-spesifieke inhoud opvra. Oorweeg die volgende voorbeeld:
As hierdie gesmokkelde versoek 'n kasinskrywing vir statiese inhoud (bv. /someimage.png) besoedel, mag die slagoffer se sensitiewe data van /private/messages onder die kasinskrywing van die statiese inhoud gebuffer wees. Gevolglik kan die aanvaller moontlik hierdie gebufferde sensitiewe data terugkry.
In hierdie pos word voorgestel dat as die bediener die metode TRACE geaktiveer het, dit moontlik kan wees om dit te misbruik met 'n HTTP Request Smuggling. Dit is omdat hierdie metode enige kop wat na die bediener gestuur word, as deel van die liggaam van die antwoord sal reflekteer. Byvoorbeeld:
Sal 'n antwoord stuur soos:
'n Voorbeeld van hoe om hierdie gedrag te misbruik, sou wees om eers 'n HEAD-versoek te smuggle. Hierdie versoek sal geantwoord word met slegs die koppe van 'n GET-versoek (Content-Type onder hulle). En smuggle dadelik na die HEAD 'n TRACE-versoek, wat die gestuurde data sal reflekteer.
Aangesien die HEAD-antwoord 'n Content-Length-kop sal bevat, sal die antwoord van die TRACE-versoek as die liggaam van die HEAD-antwoord behandel word, wat dus arbitrêre data in die antwoord reflekteer.
Hierdie antwoord sal na die volgende versoek oor die verbinding gestuur word, so dit kan gebruik word in 'n gebufferde JS-lêer om byvoorbeeld arbitrêre JS-kode in te voeg.
Dit word aanbeveel om hierdie pos te volg, wat 'n ander manier voorstel om die TRACE-metode te misbruik. Soos opgemerk, is dit moontlik om 'n HEAD-versoek en 'n TRACE-versoek te smuggle om sommige reflekteerde data in die antwoord op die HEAD-versoek te beheer. Die lengte van die liggaam van die HEAD-versoek word basies in die Content-Length-kop aangedui en word gevorm deur die antwoord op die TRACE-versoek.
Daarom sou die nuwe idee wees dat, met kennis van hierdie Content-Length en die data gegee in die TRACE-antwoord, dit moontlik is om die TRACE-antwoord 'n geldige HTTP-antwoord te laat bevat na die laaste byte van die Content-Length, wat 'n aanvaller in staat stel om die versoek na die volgende antwoord heeltemal te beheer (wat gebruik kan word om 'n cache poisoning uit te voer).
Voorbeeld:
Sal hierdie antwoorde genereer (let op hoe die HEAD-antwoord 'n Content-Length het wat die TRACE-antwoord deel van die HEAD-liggaam maak en sodra die HEAD Content-Length eindig, word 'n geldige HTTP-antwoord gesmuggle):
Het jy 'n HTTP Versoek Smuggling kwesbaarheid gevind en weet jy nie hoe om dit te benut nie. Probeer hierdie ander metode van benutting:
HTTP Response Smuggling / DesyncBlaaier HTTP Versoek Smuggling (Kliëntkant)
Versoek Smuggling in HTTP/2 Downgrades
Van https://hipotermia.pw/bb/http-desync-idor
Van: https://hipotermia.pw/bb/http-desync-account-takeover
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Hierdie hulpmiddel is 'n grammatika-gebaseerde HTTP Fuzzer wat nuttig is om vreemde versoek smuggling verskille te vind.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
