<summary><strong>Leer AWS-hacking vanaf nul tot held met</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* As jy jou **maatskappy geadverteer wil sien in HackTricks** of **HackTricks in PDF wil aflaai** Kyk na die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
* Ontdek [**Die PEASS Familie**](https://opensea.io/collection/the-peass-family), ons versameling van eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.
**Die tegniek van hierdie pos is geneem uit die video:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
Die **hoofverskil** tussen hierdie tegniek en 'n gewone HTTP Aanvraag-smuggling is dat **in plaas daarvan om die aanvraag van die slagoffer aan te val deur 'n voorvoegsel by te voeg**, gaan ons die **reaksie wat die slagoffer ontvang lek of wysig**. Dit word gedoen deur, in plaas van om 1 aanvraag en 'n half te stuur om die HTTP Aanvraag-smuggling te misbruik, **2 volledige aanvrae te stuur om die proksi se reaksie-ry te desinkroniseer**.
Dit is omdat ons in staat gaan wees om **die reaksie-ry te desinkroniseer** sodat die **reaksie** van die **wettige aanvraag van die slagoffer na die aanvaller gestuur word**, of deur **aanvallersbeheerde inhoud in die reaksie aan die slagoffer in te spuit**.
HTTP/1.1 maak dit moontlik om vir **verskillende bronne te vra sonder om te wag vir voriges**. Daarom, as daar 'n **proksi** in die **middel** is, is dit die proksi se taak om 'n **gesinkroniseerde ooreenstemming van aanvrae wat na die agterste gestuur is en reaksies wat daarvandaan kom, te handhaaf**.
Daar is egter 'n probleem om die reaksies-ry te desinkroniseer. As 'n aanvaller 'n HTTP Reaksie-smuggling-aanval stuur en die reaksies op die **oorspronklike aanvraag en die gesmokkelde een onmiddellik reageer**, sal die gesmokkelde reaksie nie binne die ry van die slagoffer se reaksie ingevoeg word nie, maar sal **net as 'n fout verwerp word**.
Daarom is dit nodig dat die **gesmokkelde aanvraag meer tyd neem om binne die agterste bediener verwerk te word**. Daarom, teen die tyd dat die gesmokkelde aanvraag verwerk is, sal die kommunikasie met die aanvaller verby wees.
As in hierdie spesifieke situasie 'n **slagoffer 'n aanvraag gestuur het** en die **gesmokkelde aanvraag voor** die wettige aanvraag beantwoord word, sal die **gesmokkelde reaksie na die slagoffer gestuur word**. Daarom sal die aanvaller die aanvraag "uitgevoer" deur die slagoffer **beheer**.
Verder, as die **aanvaller dan 'n aanvraag uitvoer** en die **wettige reaksie** op die **slagoffer se** aanvraag **beantwoord word voor** die aanvaller se aanvraag. Die **reaksie na die slagoffer sal na die aanvaller gestuur word**, wat die reaksie aan die slagoffer steel (wat byvoorbeeld die kop Set-Cookie kan bevat).
'n Ander **interessante verskil** met gewone **HTTP Aanvraag-smuggling** is dat, in 'n gewone smokkelingsaanval, die **doel** is om die **begin van die slagoffer se aanvraag te wysig** sodat dit 'n onverwagte aksie uitvoer. In 'n **HTTP Reaksie-smuggling-aanval**, aangesien jy **volledige aanvrae stuur**, kan jy **tientalle reaksies in een nut inpluis** wat **tientalle gebruikers sal desinkroniseer** wat die **ingevoegde reaksies ontvang**.
Afgesien daarvan dat jy makliker tientalle exploits kan **versprei** onder wettige gebruikers, kan dit ook gebruik word om 'n **DoS** in die bediener te veroorsaak.
Soos voorheen verduidelik, om hierdie tegniek te misbruik, is dit nodig dat die **eerste gesmokkelde boodskap** in die bediener **baie tyd neem om verwerk te word**.
Hierdie **tydrowende aanvraag is genoeg** as ons net die slagoffer se reaksie wil **probeer steel**. Maar as jy 'n meer komplekse uitbuiting wil uitvoer, sal dit 'n algemene struktuur vir die uitbuiting wees.
Eerstens die **oorspronklike** aanvraag wat **HTTP Aanvraag-smuggling misbruik**, dan die **tydrowende aanvraag** en dan **1 of meer nutaanvrae** waarvan die reaksies na die slagoffers gestuur sal word.
Soos met bekende HTTP Aanvraag-smuggling-nutladings, kan jy die slagoffer se aanvraag **steel** met een belangrike verskil: In hierdie geval hoef jy net die **gestuurde inhoud te sien in die reaksie**, **geen permanente stoorplek** is nodig nie.
Dan, sodra die **oorspronklike aanvraag** (blou) **verwerk** is en **terwyl** die **slaperige** een verwerk word (geel) gaan die **volgende aanvraag wat van 'n slagoffer afkomstig is, in die ry net na die gereflekte parameter ingevoeg word**:
Dan sal die **slagoffer** die **reaksie op die slaperige** aanvraag ontvang en as intussen die **aanvaller 'n ander aanvraag stuur**, sal die **reaksie van die gereflekte inhoudsaanvraag na hom gestuur word**.
Tot dusver het ons geleer hoe om HTTP Aanvraag-smuggling-aanvalle te misbruik om die **aanvraag te beheer waarvan 'n kliënt die reaksie gaan ontvang** en hoe jy dan die **reaksie wat vir die slagoffer bedoel was, kan steel**.
Daar is interessante aanvrae soos **HEAD**-aanvrae wat gespesifiseer is om **geen inhoud binne die reaksie liggaam te hê** en wat (moet) **die Inhoudslengte bevat** van die aanvraag soos **of dit 'n GET-aanvraag was**.
Dan sal die **slagoffer** die **reaksie** van die **HEAD**-aanvraag ontvang, wat **'n Inhoudslengte maar geen inhoud nie** gaan bevat. Daarom sal die proksi **nie hierdie reaksie na die slagoffer stuur nie**, maar sal wag vir **'n bietjie inhoud**, wat eintlik die **reaksie op die geel aanvraag** gaan wees (ook deur die aanvaller ingespuit):
Na die vorige voorbeeld, wetende dat jy die liggaam van die versoek kan **beheer** waarvan die reaksie deur die slagoffer ontvang gaan word en dat 'n **HEAD****reaksie** gewoonlik die **Content-Type en die Content-Length** in sy koppe bevat, kan jy 'n versoek soos die volgende stuur om 'n XSS in die slagoffer te veroorsaak sonder dat die bladsy kwesbaar is vir XSS:
Deur die voorheen besproke reaksie desinkronisasie Inhoudsverwarring aan te val, **as die kegel die reaksie op die versoek wat deur die slagoffer uitgevoer is stoor en hierdie reaksie 'n geïnspireerde een is wat 'n XSS veroorsaak, dan is die kegel vergiftig**.
Let daarop dat in hierdie geval as die **"slagoffer" die aanvaller** is, kan hy nou **kegelvergiftiging in willekeurige URL's** uitvoer aangesien hy die URL kan beheer wat met die boosaardige reaksie gestoor gaan word.
Hierdie aanval is soortgelyk aan die vorige een, maar **in plaas daarvan om 'n lading binne die kegel in te spuit, sal die aanvaller slagofferinligting binne die kegel stoor:**
Die **doel** van hierdie aanval is om weer die **reaksie desinkronisasie** te misbruik om die proksi te dwing om 'n 100% aanvaller gegenereerde reaksie te stuur.
Om dit te bereik, moet die aanvaller 'n eindpunt van die webtoepassing vind wat **waardes binne die reaksie reflekteer** en die inhoudslengte van die HEAD-reaksie ken.
Let egter daarop hoe die **gereflekteerde data 'n grootte volgens die Content-Length** van die **HEAD**-reaksie gehad het wat 'n geldige HTTP-reaksie in die reaksietou gegenereer het.
Daarom sal die **volgende versoek van die tweede slagoffer** as **reaksie iets heeltemal deur die aanvaller saamgestel ontvang**. Aangesien die reaksie heeltemal deur die aanvaller saamgestel is, kan hy ook **die proksi dwing om die reaksie te stoor**.
