# 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.