# HTTP Response Smuggling / Desync
{% hint style="success" %}
Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}
**Tehnika ovog posta je preuzeta iz videa:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
## HTTP Request Queue Desynchronisation
Prvo, ova tehnika **zloupotrebljava HTTP Request Smuggling ranjivost**, tako da treba da znate šta je to:
**Glavna** **razlika** između ove tehnike i uobičajenog HTTP Request smuggling-a je to što **umesto** da **napadamo** **zahtev** **žrtve** **dodavanjem prefiksa**, mi ćemo **ukrasti ili izmeniti odgovor koji žrtva prima**. To se postiže tako što, umesto da pošaljemo 1 zahtev i po da zloupotrebimo HTTP Request smuggling, **pošaljemo 2 potpuna zahteva da desinkronizujemo redosled odgovora proksija**.
To je zato što ćemo moći da **desinkronizujemo redosled odgovora** tako da **odgovor** iz **legitimnog** **zahteva** **žrtve bude poslat napadaču**, ili tako što ćemo **ubaciti sadržaj pod kontrolom napadača u odgovor žrtvi**.
### HTTP Pipeline Desync
HTTP/1.1 omogućava da se traže **različiti resursi bez potrebe da se čeka na prethodne**. Stoga, ako postoji **proksi** u **sredini**, zadatak proksija je da **održi sinhronizovanu podudarnost zahteva poslatih ka backend-u i odgovora koji dolaze iz njega**.
Međutim, postoji problem sa desinkronizacijom redosleda odgovora. Ako napadač pošalje HTTP Response smuggling napad i odgovori na **početni zahtev i smugglovani zahtev budu odmah poslati**, smugglovani odgovor neće biti umetnut u redosled odgovora žrtve, već će **biti odbijen kao greška**.
![](<../.gitbook/assets/image (633).png>)
Stoga, potrebno je da **smugglovani** **zahtev** **traje duže da bude obrađen** unutar backend servera. Tako da, dok se smugglovani zahtev obrađuje, komunikacija sa napadačem će biti završena.
Ako u ovoj specifičnoj situaciji **žrtva pošalje zahtev** i **smugglovani zahtev bude odgovoreno pre** legitimnog zahteva, **smugglovani odgovor će biti poslat žrtvi**. Tako da će napadač **kontrolisati zahtev "izvršen" od strane žrtve**.
Štaviše, ako **napadač zatim izvrši zahtev** i **legitimni odgovor** na **zahtev žrtve** bude **odgovoren** **pre** napadačevog zahteva. **Odgovor žrtvi će biti poslat napadaču**, **kradući** odgovor žrtvi (koji može sadržati, na primer, zaglavlje **Set-Cookie**).
![](<../.gitbook/assets/image (1020).png>)
![](<../.gitbook/assets/image (719).png>)
### Multiple Nested Injections
Još jedna **zanimljiva razlika** sa uobičajenim **HTTP Request Smuggling** je to što, u uobičajenom smugglovanju, **cilj** je da se **izmeni početak zahteva žrtve** tako da izvrši neočekivanu akciju. U **HTTP Response smuggling napadu**, pošto šaljete **pune zahteve**, možete **ubaciti u jedan payload desetine odgovora** koji će **desinkronizovati desetine korisnika** koji će **primati** **ubacene** **odgovore**.
Pored toga što možete **lakše distribuirati desetine eksploita** među legitimnim korisnicima, ovo se takođe može koristiti za izazivanje **DoS** na serveru.
### Exploit Organisation
Kao što je ranije objašnjeno, da biste zloupotrebili ovu tehniku, potrebno je da **prva smugglovana poruka** unutar servera **zahteva puno vremena da bude obrađena**.
Ovaj **zahtev koji zahteva vreme** je dovoljan ako samo želite da **pokušate da ukradete odgovor žrtve.** Ali ako želite da izvršite složeniji exploit, ovo će biti uobičajena struktura za exploit.
Prvo, **početni** zahtev koji zloupotrebljava **HTTP** **Request** **smuggling**, zatim **zahtev koji zahteva vreme** i zatim **1 ili više payload zahteva** čiji će odgovori biti poslati žrtvama.
## Abusing HTTP Response Queue Desynchronisation
### Capturing other users' requests
Kao i sa poznatim payload-ima HTTP Request Smuggling-a, možete **ukrasti zahtev žrtve** sa jednom važnom razlikom: U ovom slučaju vam je samo potrebno da **sadržaj bude reflektovan u odgovoru**, **nije potrebno trajno skladištenje**.
Prvo, napadač šalje payload koji sadrži **konačni POST zahtev sa reflektovanim parametrom** na kraju i velikim Content-Length.
![](<../.gitbook/assets/image (1053).png>)
Zatim, kada je **početni zahtev** (plavi) bio **obrađen** i **dok** se **spori** obrađuje (žuti), **sledeći zahtev koji dolazi od žrtve** će biti **dodato u redosled odmah nakon reflektovanog parametra**:
![](<../.gitbook/assets/image (794).png>)
Zatim, **žrtva** će **primiti** **odgovor na spori** zahtev i ako u međuvremenu **napadač** **pošalje** **još jedan** **zahtev**, **odgovor iz zahteva reflektovanog sadržaja će biti poslat njemu**.
## Response Desynchronisation
Do ovog trenutka, naučili smo kako da zloupotrebimo HTTP Request Smuggling napade da **kontrolišemo** **zahtev** **čiji** **odgovor** će **klijent** **primiti** i kako možete zatim **ukrasti odgovor koji je bio namenjen žrtvi**.
Ali je još uvek moguće **desinkronizovati još** više odgovore.
Postoje zanimljivi zahtevi kao što je **HEAD** zahtev koji su specificirani da nemaju **nikakav sadržaj unutar tela odgovora** i koji bi trebali (moraju) **sadržati Content-Length** zahteva kao **da je to GET zahtev**.
Stoga, ako napadač **ubaci** **HEAD** zahtev, kao u ovim slikama:
![](<../.gitbook/assets/image (1107).png>)
Zatim, **kada plavi zahtev bude odgovoreno napadaču**, sledeći zahtev žrtve će biti uveden u redosled:
![](<../.gitbook/assets/image (999).png>)
Zatim, **žrtva** će **primiti** **odgovor** iz **HEAD** zahteva, koji će **sadržati Content-Length ali nikakav sadržaj**. Stoga, proksi **neće poslati ovaj odgovor** žrtvi, već će **čekati** na neki **sadržaj**, koji će zapravo biti **odgovor na žuti zahtev** (takođe ubačen od strane napadača):
![](<../.gitbook/assets/image (735).png>)
### Content Confusion
Prateći prethodni primer, znajući da možete **kontrolisati telo** zahteva čiji odgovor će primiti žrtva i da **HEAD** **odgovor** obično sadrži u svojim zaglavljima **Content-Type i Content-Length**, možete **poslati zahtev kao što je sledeći** da **uzrokujete XSS** kod žrtve bez da stranica bude ranjiva na XSS:
![](<../.gitbook/assets/image (688).png>)
### Cache Poisoning
Zloupotrebljavajući prethodno komentarisani odgovor desinkronizacije Content Confusion napad, **ako keš skladišti odgovor na zahtev izvršen od strane žrtve i ovaj odgovor je ubačen izazivajući XSS, tada je keš otrovan**.
Maliciozni zahtev koji sadrži XSS payload:
![](<../.gitbook/assets/image (614).png>)
Maliciozni odgovor žrtvi koji sadrži zaglavlje koje ukazuje kešu da skladišti odgovor:
![](<../.gitbook/assets/image (566).png>)
{% hint style="warning" %}
Napomena da u ovom slučaju ako je **"žrtva" napadač**, on sada može izvršiti **keš otrovanje na proizvoljnim URL-ovima** jer može **kontrolisati URL koji će biti keširan** sa malicioznim odgovorom.
{% endhint %}
### Web Cache Deception
Ovaj napad je sličan prethodnom, ali **umesto da ubacuje payload unutar keša, napadač će keširati informacije o žrtvi unutar keša:**
![](<../.gitbook/assets/image (991).png>)
### Response Splitting
**Cilj** ovog napada je ponovo zloupotreba **odgovora** **desinkronizacije** kako bi se **proksi naterao da pošalje 100% napadačem generisan odgovor**.
Da bi to postigao, napadač treba da pronađe krajnju tačku web aplikacije koja **reflektuje neke vrednosti unutar odgovora** i **zna sadržaj dužine HEAD odgovora**.
On će poslati **eksploit** kao:
![](<../.gitbook/assets/image (911).png>)
Nakon što je prvi zahtev rešen i poslat nazad napadaču, **zahtev žrtve se dodaje u redosled**:
![](<../.gitbook/assets/image (737).png>)
Žrtva će primiti kao odgovor **HEAD odgovor + sadržaj odgovora drugog zahteva (sadrži deo reflektovanih podataka):**
![](<../.gitbook/assets/image (356).png>)
Međutim, obratite pažnju kako su **reflektovani podaci imali veličinu prema Content-Length** **HEAD** odgovora koji je **generisao validan HTTP odgovor u redosledu odgovora**.
Stoga, **sledeći zahtev drugog žrtve** će **primiti** kao **odgovor nešto potpuno kreirano od strane napadača**. Kako je odgovor potpuno kreiran od strane napadača, on takođe može **naterati proksi da kešira odgovor**.
{% hint style="success" %}
Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}