# HTTP Response Smuggling / Desync
{% hint style="success" %}
Leer & oefen AWS Hacking:
[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Leer & oefen GCP Hacking: 
[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Kyk na die [**subskripsie planne**](https://github.com/sponsors/carlospolop)!
* **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}
**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)
## HTTP Request Queue Desynchronisation
Eerstens, hierdie tegniek **misbruik 'n HTTP Request Smuggling kwesbaarheid**, so jy moet weet wat dit is:
Die **hoof** **verskil** tussen hierdie tegniek en 'n algemene HTTP Request smuggling is dat **in plaas van** om die **aanvraag** van die **slagoffer** **te aanval** **deur 'n voorvoegsel daaraan toe te voeg**, gaan ons die **antwoord wat die slagoffer ontvang** **lek of wysig**. Dit word gedoen deur, in plaas daarvan om 1 aanvraag en 'n half te stuur om die HTTP Request smuggling te misbruik, **2 volledige versoeke te stuur om die proxies se antwoordqueue te desynchroniseer**.
Dit is omdat ons in staat gaan wees om die **antwoordqueue te desynchroniseer** sodat die **antwoord** van die **legitieme** **aanvraag** van die **slagoffer na die aanvaller gestuur word**, of deur **aanvallers beheerde inhoud in die antwoord aan die slagoffer in te spuit**.
### HTTP Pipeline Desync
HTTP/1.1 laat toe om **verskillende hulpbronne te vra sonder om te wag vir vorige**. Daarom, as daar 'n **proxy** in die **middel** is, is dit die proxies se taak om 'n **gesinkroniseerde ooreenstemming van versoeke wat na die agtergrond gestuur is en antwoorde wat daaruit kom, te handhaaf**.
Daar is egter 'n probleem om die antwoordequeue te desynchroniseer. As 'n aanvaller 'n HTTP Response smuggling aanval stuur en die antwoorde op die **aanvanklike aanvraag en die gesmugde een onmiddellik beantwoord word**, sal die gesmugde antwoord nie in die queue van die slagoffer se antwoord ingevoeg word nie, maar sal **net as 'n fout weggegooi word**.
.png>)
Daarom is dit nodig dat die **gesmugde** **aanvraag** **meer tyd neem om verwerk te word** binne die agtergrond bediener. Daarom, teen die tyd dat die gesmugde aanvraag verwerk word, sal die kommunikasie met die aanvaller verby wees.
As in hierdie spesifieke situasie 'n **slagoffer 'n aanvraag gestuur het** en die **gesmugde aanvraag voor** die legitieme aanvraag beantwoord word, sal die **gesmugde antwoord na die slagoffer gestuur word**. Daarom sal die aanvaller die **aanvraag "uitgevoer" deur die slagoffer** **beheer**.
Boonop, as die **aanvaller dan 'n aanvraag uitvoer** en die **legitieme antwoord** op die **slagoffer** se aanvraag **beantwoord** **voor** die aanvaller se aanvraag. Die **antwoord aan die slagoffer gaan na die aanvaller gestuur word**, **steel** die antwoord aan die slagoffer (wat byvoorbeeld die header **Set-Cookie** kan bevat).
.png>)
.png>)
### Meervoudige Geneste Inspuitings
Nog 'n **interessante verskil** met algemene **HTTP Request Smuggling** is dat, in 'n algemene smuggling aanval, die **doel** is om die **begin van die slagoffer se aanvraag** te **wysig** sodat dit 'n onverwagte aksie uitvoer. In 'n **HTTP Response smuggling aanval**, aangesien jy **volledige versoeke stuur**, kan jy **in een payload tiener antwoorde inspuit** wat **tieners gebruikers gaan desynchroniseer** wat die **ingespuite** **antwoorde** gaan **ontvang**.
Afgesien van die vermoë om **meer maklik tiener exploits** oor legitieme gebruikers te versprei, kan dit ook gebruik word om 'n **DoS** op die bediener te veroorsaak.
### Exploit Organisasie
Soos voorheen verduidelik, om hierdie tegniek te misbruik, is dit nodig dat die **eerste gesmugde boodskap** in die bediener **baie tyd neem om verwerk te word**.
Hierdie **tydrowende aanvraag is genoeg** as ons net wil **probeer om die slagoffer se antwoord te steel.** Maar as jy 'n meer komplekse exploit wil uitvoer, sal dit 'n algemene struktuur vir die exploit wees.
Eerstens die **aanvanklike** aanvraag wat **HTTP** **Request** **smuggling** misbruik, dan die **tydrowende aanvraag** en dan **1 of meer payload versoeke** waarvan die antwoorde aan die slagoffers gestuur sal word.
## Misbruik van HTTP Response Queue Desynchronisation
### Vasvang ander gebruikers se versoeke
Soos met HTTP Request Smuggling bekende payloads, kan jy **die slagoffer se aanvraag steel** met een belangrike verskil: In hierdie geval het jy net die **gestuurde inhoud wat in die antwoord weerspieël moet word**, **geen volhoubare berging** is nodig nie.
Eerstens, die aanvaller stuur 'n payload wat 'n **finale POST aanvraag met die weerspieëlde parameter** aan die einde en 'n groot Content-Length bevat.
.png>)
Dan, sodra die **aanvanklike aanvraag** (blou) verwerk is en **terwyl** die **slaapagtige** een verwerk word (geel) gaan die **volgende aanvraag wat van 'n slagoffer aankom** in die queue **net na die weerspieëlde parameter** ingevoeg word:
.png>)
Dan, die **slagoffer** sal die **antwoord** op die **slaapagtige** aanvraag ontvang en as intussen die **aanvaller** **nog 'n** **aanvraag gestuur het**, sal die **antwoord van die weerspieëlde inhoud aanvraag na hom gestuur word**.
## Antwoord Desynchronisation
Tot op hierdie punt, het ons geleer hoe om HTTP Request Smuggling aanvalle te misbruik om die **aanvraag** **waarvan** die **antwoord** 'n **klient** gaan **ontvang** te **beheer** en hoe jy dan die **antwoord wat bedoel was vir die slagoffer** kan **steel**.
Maar dit is steeds moontlik om die antwoorde **nog meer te desynchroniseer**.
Daar is interessante versoeke soos **HEAD** versoeke wat gespesifiseer is om **geen inhoud binne die antwoord se liggaam** te hê nie en wat moet (moet) **die Content-Length** van die aanvraag bevat soos **as dit 'n GET aanvraag was**.
Daarom, as 'n aanvaller 'n **HEAD** aanvraag **inspuit**, soos in hierdie beelde:
.png>)
Dan, **sodra die blou een aan die aanvaller beantwoord word**, gaan die volgende slagoffer se aanvraag in die queue ingevoer word:
.png>)
Dan, die **slagoffer** sal die **antwoord** van die **HEAD** aanvraag ontvang, wat **'n Content-Length gaan bevat maar geen inhoud nie**. Daarom, die proxy **sal hierdie antwoord nie aan die slagoffer stuur nie**, maar sal **wag** vir 'n **inhoud**, wat eintlik die **antwoord op die geel aanvraag** gaan wees (ook deur die aanvaller ingespuit):
.png>)
### Inhoud Verwarring
Volgende die vorige voorbeeld, wetende dat jy die **liggaam** van die aanvraag kan **beheer** waarvan die antwoord die slagoffer gaan ontvang en dat 'n **HEAD** **antwoord** gewoonlik in sy headers die **Content-Type en die Content-Length** bevat, kan jy **'n aanvraag soos die volgende** stuur om **XSS** in die slagoffer te veroorsaak sonder dat die bladsy kwesbaar is vir XSS:
.png>)
### Cache Vergiftiging
Deur die voorheen bespreekte antwoord desynchronisering Inhoud Verwarring aanval te misbruik, **as die cache die antwoord op die aanvraag wat deur die slagoffer uitgevoer is, stoor en hierdie antwoord 'n ingespuite een is wat 'n XSS veroorsaak, dan is die cache vergiftig**.
Kwaadwillige aanvraag wat die XSS payload bevat:
.png>)
Kwaadwillige antwoord aan die slagoffer wat die header bevat wat aan die cache aandui om die antwoord te stoor:
.png>)
{% hint style="warning" %}
Let daarop dat in hierdie geval as die **"slagoffer" die aanvaller** is, hy nou **cache vergiftiging in arbitrêre URL's** kan uitvoer aangesien hy die **URL wat in die cache gestoor gaan word** met die kwaadwillige antwoord kan **beheer**.
{% endhint %}
### Web Cache Misleiding
Hierdie aanval is soortgelyk aan die vorige een, maar **in plaas daarvan om 'n payload binne die cache in te spuit, sal die aanvaller slagofferinligting binne die cache stoor:**
.png>)
### Antwoord Splitting
Die **doel** van hierdie aanval is om weer die **antwoord** **desynchronisering** te misbruik om die **proxy 'n 100% aanvaller gegenereerde antwoord** te laat stuur.
Om dit te bereik, moet die aanvaller 'n eindpunt van die webtoepassing vind wat **sekere waardes binne die antwoord weerspieël** en **weet die inhoud lengte van die HEAD antwoord**.
Hy sal 'n **exploit** soos volg stuur:
.png>)
Nadat die eerste aanvraag opgelos is en aan die aanvaller teruggestuur is, word die **slagoffer se aanvraag in die queue ingevoeg**:
.png>)
Die slagoffer sal as antwoord die **HEAD antwoord + die inhoud van die tweede aanvraag se antwoord (wat 'n deel van die weerspieëlde data bevat):**
.png>)
Let egter op hoe die **weerspieëlde data 'n grootte gehad het volgens die Content-Length** van die **HEAD** antwoord wat **'n geldige HTTP antwoord in die antwoordqueue** gegenereer het.
Daarom, die **volgende aanvraag van die tweede slagoffer** sal as **antwoord iets heeltemal deur die aanvaller saamgestel ontvang**. Aangesien die antwoord heeltemal deur die aanvaller saamgestel is, kan hy ook **die proxy laat cache die antwoord**.
{% hint style="success" %}
Leer & oefen AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Leer & oefen GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Kyk na die [**subskripsie planne**](https://github.com/sponsors/carlospolop)!
* **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}