# HTTP Response Smuggling / Desync
Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)! Ander maniere om HackTricks te ondersteun: * As jy jou **maatskappy geadverteer wil sien in HackTricks** of **HackTricks in PDF wil aflaai**, kyk na die [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)! * Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com) * Ontdek [**The PEASS Family**](https://opensea.io/collection/the-peass-family), ons versameling 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 hacktruuks 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 berig is geneem uit die video: [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)** ## HTTP Aanvraag-ry Desinkronisasie Eerstens, hierdie tegniek **misbruik 'n HTTP Aanvraag Smuggling kwesbaarheid**, so jy moet weet wat dit is: 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**, ons die **reaksie wat die slagoffer ontvang lek of wysig**. Dit word gedoen deur, in plaas van om 1 en 'n half aanvraag te stuur om die HTTP Aanvraag-smuggling te misbruik, **2 volledige aanvrae te stuur om die reaksie-ry van die proksi te desinkroniseer**. Dit is omdat ons in staat sal 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 na die slagoffer in te spuit**. ### HTTP Pyplyn Desinkronisasie HTTP/1.1 maak dit moontlik om **verskillende hulpbronne aan 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 word 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 beantwoord word**, sal die gesmokkelde reaksie nie in die ry van die slagoffer se reaksie ingevoeg word nie, maar sal **net as 'n fout verwerp word**. ![](<../.gitbook/assets/image (635) (1) (1) (1).png>) Daarom is dit nodig dat die **gesmokkelde** **aanvraag langer tyd neem om in die agterste bediener verwerk te word**. Teen die tyd dat die gesmokkelde aanvraag verwerk word, 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 voordat** die aanvaller se aanvraag. Die **reaksie na die slagoffer sal na die aanvaller gestuur word**, wat die reaksie na die slagoffer steel (wat byvoorbeeld die kop **Set-Cookie** kan bevat). ![](<../.gitbook/assets/image (658) (1).png>) ![](<../.gitbook/assets/image (655) (1) (1) (1).png>) ### Meervoudige Geneste Inspuitings '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 **verander** sodat dit 'n onverwagte aksie uitvoer. In 'n **HTTP Reaksie-smokkelingsaanval**, aangesien jy **volledige aanvrae stuur**, kan jy **tientalle reaksies in een payload inspuit** wat **tientalle gebruikers sal desinkroniseer** wat die **ingespuite reaksies sal 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. ### Exploit Organisasie 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 exploit wil uitvoer, sal dit 'n algemene struktuur vir die exploit wees. Eerstens die **oorspronklike** aanvraag wat **HTTP Aanvraag-smuggling misbruik**, dan die **tydrowende aanvraag** en dan **1 of meer payloads** wat se reaksies na die slagoffers gestuur sal word. ## Misbruik van HTTP Reaksie-ry Desinkronisasie ### Vaslegging van ander gebruikers se aanvrae Soos met bekende HTTP Aanvraag-smuggling payloads, kan jy die slagoffer se aanvraag **steel** met een belangrike verskil: In hierdie geval het jy net die **gestuurde inhoud nodig om in die reaksie gereflekteer te word**, **geen volgehoue berging** is nodig nie. Eerstens stuur die aanvaller 'n payload wat 'n **finale POST-aanvraag met die gereflekteerde parameter** aan die einde en 'n groot Content-Length bevat ![](<../.gitbook/assets/image (625).png>) Dan, sodra die **oorspronklike aanvraag** (blou) **verwerk** is en **terwyl** die **slaperige** een verwerk word (geel), sal die **volgende aanvraag wat van 'n slagoffer afkomstig is, in die ry na die gereflekteerde parameter ingevoeg word**: ![](<../.gitbook/assets/image (634) (1).png>) 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 gereflekteerde inhoudsaanvraag na hom gestuur word**. ## Reaksie Desinkronisasie Tot dusver het ons geleer hoe om HTTP Aanvraag ### Inhoudsverwarring Na die vorige voorbeeld, wetende dat jy die liggaam van die versoek kan **beheer** waarvan die slagoffer die respons gaan ontvang en dat 'n **HEAD** **respons** 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 vatbaar is vir XSS: ![](<../.gitbook/assets/image (654) (1) (1) (1) (1).png>) ### Cache-vergiftiging Deur misbruik te maak van die voorheen bespreekte respons-desinkronisasie van inhoudsverwarringsaanval, **as die cache die respons op die versoek wat deur die slagoffer uitgevoer is, stoor en hierdie respons 'n ingespuit een is wat 'n XSS veroorsaak, dan is die cache vergiftig**. Boosaardige versoek wat die XSS-lading bevat: ![](<../.gitbook/assets/image (644) (1).png>) Boosaardige respons aan die slagoffer wat die kop bevat wat die cache aandui om die respons te stoor: ![](<../.gitbook/assets/image (629) (1).png>) {% hint style="warning" %} Let daarop dat in hierdie geval as die **"slagoffer" die aanvaller** is, kan hy nou **cache-vergiftiging in willekeurige URL's** uitvoer omdat hy die URL wat met die boosaardige respons gestoor gaan word, kan **beheer**. {% endhint %} ### Webkassaverwarring Hierdie aanval is soortgelyk aan die vorige een, maar **in plaas daarvan om 'n lading binne die cache in te spuit, sal die aanvaller slagofferinligting binne die cache stoor:** ![](<../.gitbook/assets/image (643) (1) (1).png>) ### Responsverdeling Die **doel** van hierdie aanval is om weer die **respons-desinkronisasie** te misbruik om 'n 100% aanvaller gegenereerde respons deur die proksi te laat stuur. Om dit te bereik, moet die aanvaller 'n eindpunt van die webtoepassing vind wat **waardes binne die respons reflekteer** en die inhoudslengte van die HEAD-respons ken. Hy sal 'n **uitbuiting** soos die volgende stuur: ![](<../.gitbook/assets/image (649) (1) (1) (1).png>) Nadat die eerste versoek opgelos en teruggestuur is na die aanvaller, word die versoek van die slagoffer by die waglys gevoeg: ![](<../.gitbook/assets/image (661) (1) (1) (1).png>) Die slagoffer sal as respons die **HEAD-respons + die inhoud van die tweede versoekrespons (wat 'n deel van die gereflekte data bevat)** ontvang: ![](<../.gitbook/assets/image (633) (1).png>) Let egter daarop hoe die **gereflekte data 'n grootte gehad het volgens die Content-Length** van die **HEAD**-respons wat 'n geldige HTTP-respons in die responswag gekry het. Daarom sal die **volgende versoek van die tweede slagoffer** as **respons iets heeltemal deur die aanvaller vervaardig** ontvang. Aangesien die respons heeltemal deur die aanvaller vervaardig is, kan hy ook **die proksi die respons laat stoor**.
Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)! Ander maniere om HackTricks te ondersteun: * As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks in PDF aflaai**, kyk na die [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)! * Kry die [**amptelike PEASS & HackTricks-uitrusting**](https://peass.creator-spring.com) * Ontdek [**The PEASS Family**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFT's**](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.