diff --git a/src/pentesting-web/http-request-smuggling/README.md b/src/pentesting-web/http-request-smuggling/README.md index d7c6b77e9..9502e4141 100644 --- a/src/pentesting-web/http-request-smuggling/README.md +++ b/src/pentesting-web/http-request-smuggling/README.md @@ -5,8 +5,8 @@ ## Šta je -Ova ranjivost se javlja kada postoji **desyncronization** između **front-end proxies** i **back-end** servera što omogućava **attacker**-u da **send**-uje HTTP **request** koji će **interpreted** biti kao **single request** od strane **front-end** proxies (load balance/reverse-proxy), a **as 2 request** od strane **back-end** servera.\ -To dozvoljava korisniku da **modify the next request that arrives to the back-end server after his**. +Ova ranjivost se javlja kada **desinhronizacija** između **front-end proxies** i **back-end** servera dozvoli **napadaču** da **pošalje** HTTP **request** koji će biti **interpretiran** kao **jedan request** od strane **front-end** proxyja (load balance/reverse-proxy) i **kao 2 requesta** od strane **back-end** servera.\ +Ovo omogućava korisniku da **izmeni sledeći request koji stigne do back-end servera nakon njegovog**. ### Teorija @@ -25,58 +25,58 @@ To dozvoljava korisniku da **modify the next request that arrives to the back-en ### Realnost -The **Front-End** (a load-balance / Reverse Proxy) **process** the _**content-length**_ or the _**transfer-encoding**_ header i **Back-end** server **process the other**, što izaziva **desyncronization** između ta dva sistema.\ -Ovo može biti veoma kritično jer **an attacker will be able to send one request** ka reverse proxy-ju koji će **interpreted** od strane **back-end** servera **as 2 different requests**. **Danger** ove tehnike leži u tome što će **back-end** server tretirati **2nd request injected** kao da je **came from the next client**, dok će **real request** tog klijenta postati **part** od **injected request**-a. +**Front-End** (a load-balance / Reverse Proxy) **obrađuje** _**Content-Length**_ ili _**Transfer-Encoding**_ header, dok **Back-end** server **obrađuje drugi**, izazivajući **desinhronizaciju** između ta dva sistema.\ +Ovo može biti jako kritično jer će **napadač moći da pošalje jedan request** ka reverse proxyju koji će **back-end** server **interpretirati** **kao 2 različita requesta**. Opasnost ove tehnike leži u tome što će **back-end** server **interpretirati** **injektovani 2. request** kao da je **došao od sledećeg klijenta**, dok će **stvarni request** tog klijenta postati **deo injektovanog requesta**. ### Posebnosti -Zapamtite da u HTTP-u **karakter novog reda se sastoji od 2 bajta:** +Zapamtite da je u HTTP-u **karakter novog reda sastavljen od 2 bajta:** -- **Content-Length**: Ovaj header koristi **decimal number** da označi **number** of **bytes** tela zahteva. Body se očekuje da se završi na poslednjem karakteru, **a new line is not needed in the end of the request**. -- **Transfer-Encoding:** Ovaj header koristi u **body**-u **hexadecimal number** da označi **number** of **bytes** narednog chunk-a. **Chunk** mora **end**-ovati sa **new line** ali taj new line **nije uračunat** u indikator dužine. Ovaj način prenosa mora da se završi sa **chunk**-om veličine 0 koji je praćen sa **2 new lines**: `0` -- **Connection**: Iz ličnog iskustva, preporučuje se korišćenje **`Connection: keep-alive`** na prvom request-u pri pokušaju request Smuggling-a. +- **Content-Length**: Ovaj header koristi **decimalni broj** da pokaže **broj** **bajtova** tela requesta. Očekuje se da telo prestane na poslednjem karakteru; **novi red na kraju requesta nije potreban**. +- **Transfer-Encoding:** Ovaj header u **telu** koristi **heksadecimalni broj** da označi **broj** **bajtova** narednog chunk-a. **Chunk** mora **završiti** novim redom, ali taj novi red **nije uračunat** u indikator dužine. Ovaj način transfera mora da se završi **chunk-om veličine 0 praćenim sa 2 nova reda**: `0` +- **Connection**: Iz mog iskustva preporučuje se korišćenje **`Connection: keep-alive`** u prvom requestu pri request smuggling-u. ### Visible - Hidden -Glavni problem sa HTTP/1.1 je što svi zahtevi idu kroz isti TCP socket, pa ako postoji razlika u načinu na koji dva sistema primaju zahteve, moguće je poslati jedan request koji će biti tretiran kao dva različita (ili više) zahteva od strane finalnog backend-a (ili čak posredničkih sistema). +Glavni problem sa http/1.1 je što svi requesti idu kroz isti TCP socket, pa ako se nađu razlike između dva sistema koji primaju requeste, moguće je poslati jedan request koji će konačni backend (ili čak međusistemi) tretirati kao 2 različita requesta (ili više). -**[This blog post](https://portswigger.net/research/http1-must-die)** predlaže nove načine za otkrivanje desync napada na sistem koji neće biti detektovani od strane WAF-ova. Radi toga predstavlja Visible vs Hidden ponašanja. Cilj je pokušati pronaći discrepancije u odgovoru koristeći tehnike koje bi mogle izazvati desynce bez stvarnog eksploatisanja. +**[This blog post](https://portswigger.net/research/http1-must-die)** predlaže nove načine da se detektuju desync napadi na sistem koji neće biti flagovan od strane WAF-ova. Za ovo predstavlja Visible vs Hidden ponašanja. Cilj u ovom slučaju je pokušati pronaći razlike u odgovoru koristeći tehnike koje bi mogle izazvati desync bez stvarnog eksploatisanja. -Na primer, slanje zahteva sa normalnim Host header-om i sa " host" header-om — ako backend odbaci taj zahtev (možda zato što je vrednost " host" netačna) to može značiti da front-end nije uzeo u obzir " host" header dok je finalni backend koristio tu vrednost, što visoko verovatno ukazuje na desync između front-end-a i backend-a. +Na primer, slanje requesta sa normalnim Host headerom i sa " host" headerom — ako backend prigovori na ovaj request (možda zato što je vrednost " host" netačna), to može značiti da front-end nije uočio " host" header dok ga je konačni backend upotrebio, što snažno ukazuje na desync između front-end-a i back-end-a. -Ovo bi bila **Hidden-Visible discrepancy**. +Ovo bi bio **Hidden-Visible discrepancy**. -Ako je front-end uzeo u obzir " host" header ali backend nije, to bi mogao biti **Visible-Hidden** slučaj. +Ako bi front-end uzeo u obzir " host" header ali back-end ne, to bi mogao biti **Visible-Hidden** slučaj. -Na primer, ovo je omogućilo otkrivanje desync-ova između AWS ALB kao front-end-a i IIS kao backend-a. Kada je poslat "Host: foo/bar", ALB je vratio `400, Server; awselb/2.0`, ali kada je poslat "Host : foo/bar", vratio je `400, Server: Microsoft-HTTPAPI/2.0`, što ukazuje da backend šalje odgovor. Ovo je Hidden-Visible (H-V) situacija. +Na primer, ovo je omogućilo otkrivanje desync-a između AWS ALB kao front-end-a i IIS-a kao back-end-a. To je zato što kada je poslat "Host: foo/bar", ALB je vratio `400, Server; awselb/2.0`, ali kada je poslat "Host : foo/bar", vratio je `400, Server: Microsoft-HTTPAPI/2.0`, što ukazuje da backend šalje odgovor. Ovo je Hidden-Visible (H-V) situacija. -Napomena: ovo nije automatski ispravljeno u AWS-u, ali može se prevenirati postavljanjem `routing.http.drop_invalid_header_fields.enabled` i `routing.http.desync_mitigation_mode = strictest`. +Napomena: ovo nije ispravljeno u AWS-u, ali se može ublažiti postavljanjem `routing.http.drop_invalid_header_fields.enabled` i `routing.http.desync_mitigation_mode = strictest`. ## Osnovni primeri > [!TIP] -> Kada pokušavate da eksploatišete ovo sa Burp Suite-om, **disable `Update Content-Length` and `Normalize HTTP/1 line endings`** u repeater-u zato što neki gadgets zloupotrebljavaju newlines, carriage returns i malformed content-lengths. +> Kada pokušavate da eksploatišete ovo sa Burp Suite **onemogućite `Update Content-Length` i `Normalize HTTP/1 line endings`** u repeater-u jer neki gadgeti zloupotrebljavaju nove redove, carriage return-e i malformisane content-length vrednosti. -HTTP request smuggling napadi se grade slanjem dvosmislenih zahteva koji iskorišćavaju discrepancije u načinu na koji front-end i back-end serveri interpretiraju `Content-Length` (CL) i `Transfer-Encoding` (TE) header-e. Ovi napadi se pojavljuju u različitim oblicima, pretežno kao **CL.TE**, **TE.CL**, i **TE.TE**. Svaka vrsta predstavlja jedinstvenu kombinaciju prioriteta ovih header-a između front-end i back-end servera. Ranjivosti nastaju jer serveri obrađuju isti zahtev na različite načine, što vodi do neočekivanih i potencijalno malicioznih posledica. +HTTP request smuggling napadi se kreiraju slanjem dvosmislenih requestova koji iskorišćavaju razlike u načinu na koji front-end i back-end serveri interpretiraju `Content-Length` (CL) i `Transfer-Encoding` (TE) headere. Ovi napadi se mogu manifestovati u različitim oblicima, pre svega kao **CL.TE**, **TE.CL**, i **TE.TE**. Svaka vrsta predstavlja jedinstvenu kombinaciju prioriteta ovih headera između front-end i back-end servera. Ranjivosti nastaju kada serveri obrađuju isti request na različite načine, što vodi do neočekivanih i potencijalno malicioznih ishoda. ### Osnovni primeri tipova ranjivosti ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg) > [!TIP] -> Uz prethodnu tabelu treba dodati tehniku TE.0, slično tehnici CL.0 ali koristeći Transfer-Encoding. +> U prethodnu tabelu treba dodati i TE.0 tehniku, slično CL.0, ali koristeći Transfer-Encoding. -#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End) +#### CL.TE ranjivost (Content-Length koristi Front-End, Transfer-Encoding koristi Back-End) -- **Front-End (CL):** Procesira zahtev na osnovu `Content-Length` header-a. -- **Back-End (TE):** Procesira zahtev na osnovu `Transfer-Encoding` header-a. -- **Attack Scenario:** +- **Front-End (CL):** Procesira request na osnovu `Content-Length` headera. +- **Back-End (TE):** Procesira request na osnovu `Transfer-Encoding` headera. +- **Scenarij napada:** -- Napadač pošalje zahtev gde vrednost `Content-Length` header-a ne odgovara stvarnoj dužini sadržaja. -- Front-end server prosleđuje ceo zahtev ka back-end-u bazirano na vrednosti `Content-Length`. -- Back-end server obrađuje zahtev kao chunked zbog `Transfer-Encoding: chunked` header-a, interpretirajući preostale podatke kao poseban, naknadni zahtev. -- **Example:** +- Napadač šalje request gde se vrednost `Content-Length` headera ne poklapa sa stvarnom dužinom sadržaja. +- Front-end server prosleđuje ceo request ka back-end-u na osnovu vrednosti `Content-Length`. +- Back-end server obrađuje request kao chunked zbog `Transfer-Encoding: chunked` headera, tumačeći preostale podatke kao zaseban, naredni request. +- **Primer:** ``` POST / HTTP/1.1 @@ -91,16 +91,16 @@ GET /404 HTTP/1.1 Foo: x ``` -#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End) +#### TE.CL ranjivost (Transfer-Encoding koristi Front-End, Content-Length koristi Back-End) -- **Front-End (TE):** Procesira zahtev na osnovu `Transfer-Encoding` header-a. -- **Back-End (CL):** Procesira zahtev na osnovu `Content-Length` header-a. -- **Attack Scenario:** +- **Front-End (TE):** Procesira request na osnovu `Transfer-Encoding` headera. +- **Back-End (CL):** Procesira request na osnovu `Content-Length` headera. +- **Scenarij napada:** -- Napadač pošalje chunked zahtev gde veličina chunk-a (`7b`) i stvarna dužina sadržaja (`Content-Length: 4`) nisu usklađene. -- Front-end server, poštujući `Transfer-Encoding`, prosleđuje ceo zahtev ka back-end-u. -- Back-end server, poštujući `Content-Length`, obrađuje samo početni deo zahteva (`7b` bajtova), ostavljajući ostatak kao deo nenamernog narednog zahteva. -- **Example:** +- Napadač šalje chunked request gde se veličina chunk-a (`7b`) i stvarna dužina sadržaja (`Content-Length: 4`) ne poklapaju. +- Front-end server, poštujući `Transfer-Encoding`, prosleđuje ceo request ka back-end-u. +- Back-end server, poštujući `Content-Length`, obrađuje samo početni deo requesta (`7b` bajtova), ostavljajući ostatak kao deo nenameravanog narednog requesta. +- **Primer:** ``` POST / HTTP/1.1 @@ -120,15 +120,15 @@ x= ``` -#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation) +#### TE.TE ranjivost (Transfer-Encoding koristi oba, sa obfuskovanjem) -- **Servers:** Oba podržavaju `Transfer-Encoding`, ali jedan može biti prevaren da ga ignoriše putem obfuskacije. -- **Attack Scenario:** +- **Serveri:** Oboje podržavaju `Transfer-Encoding`, ali jedan može biti zavaravan da ga ignoriše putem obfuskovanja. +- **Scenarij napada:** -- Napadač pošalje zahtev sa obfuskovanim `Transfer-Encoding` header-ima. -- U zavisnosti od toga koji server (front-end ili back-end) ne prepozna obfuskaciju, može se eksploatisati CL.TE ili TE.CL ranjivost. -- Nepostradati deo zahteva, kako ga vidi jedan od servera, postaje deo narednog zahteva, što dovodi do smuggling-a. -- **Example:** +- Napadač šalje request sa obfuskovanim `Transfer-Encoding` header-ima. +- U zavisnosti od toga koji server (front-end ili back-end) ne prepozna obfuskovanje, može se iskoristiti CL.TE ili TE.CL ranjivost. +- Neobrađeni deo requesta, kako ga vidi jedan od servera, postaje deo narednog requesta, što dovodi do smuggling-a. +- **Primer:** ``` POST / HTTP/1.1 @@ -147,11 +147,11 @@ Transfer-Encoding : chunked ``` -#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)** +#### **CL.CL scenario (Content-Length koristi i Front-End i Back-End)** -- Oba servera procesuiraju zahtev isključivo na osnovu `Content-Length` header-a. -- Ovaj scenario obično ne vodi ka smuggling-u, jer postoji usklađenost u načinu na koji oba servera interpretiraju dužinu zahteva. -- **Example:** +- Obe strane procesuiraju request isključivo na osnovu `Content-Length` headera. +- Ovaj scenario obično ne vodi do smuggling-a, jer postoji usklađenost u načinu kako oba servera interpretiraju dužinu requesta. +- **Primer:** ``` POST / HTTP/1.1 @@ -162,11 +162,11 @@ Connection: keep-alive Normal Request ``` -#### **CL.0 Scenario** +#### **CL.0 scenario** -- Odnosi se na scenarije gde `Content-Length` header postoji i ima vrednost različitu od nule, što označava da telo zahteva ima sadržaj. Back-end ignoriše `Content-Length` header (tretira ga kao 0), ali front-end ga parsira. -- Ovo je važno za razumevanje i kreiranje smuggling napada, jer utiče na to kako serveri određuju kraj zahteva. -- **Example:** +- Odnosi se na slučajeve gde je `Content-Length` header prisutan i ima vrednost različitu od nule, što ukazuje da telo requesta sadrži sadržaj. Back-end ignoriše `Content-Length` header (koji se tretira kao 0), ali front-end ga parsira. +- Ovo je ključno za razumevanje i kreiranje smuggling napada, jer utiče na to kako serveri određuju kraj requesta. +- **Primer:** ``` POST / HTTP/1.1 @@ -177,11 +177,11 @@ Connection: keep-alive Non-Empty Body ``` -#### TE.0 Scenario +#### TE.0 scenario - Kao prethodni, ali koristeći TE. -- Tehnika [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) -- **Example**: +- Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) +- **Primer**: ``` OPTIONS / HTTP/1.1 Host: {HOST} @@ -201,7 +201,7 @@ EMPTY_LINE_HERE ``` #### `0.CL` Scenarij -U `0.CL` scenariju request se šalje sa Content-Length kao: +U `0.CL` situaciji, zahtev se šalje sa Content-Length kao: ``` GET /Logon HTTP/1.1 Host: @@ -211,46 +211,46 @@ Content-Length: GET /404 HTTP/1.1 X: Y ``` -A front-end ne uzima u obzir `Content-Length`, pa pošalje samo prvi zahtev ka backendu (do 7 u primeru). Međutim, backend vidi `Content-Length` i čeka telo koje nikada ne stigne jer je front-end već u čekanju odgovora. +Front-end ne uzima u obzir `Content-Length`, pa šalje samo prvi request ka backendu (do 7 u primeru). Međutim, backend vidi `Content-Length` i čeka body koji nikada ne stigne jer front-end već čeka response. -Međutim, ako postoji zahtev koji je moguće poslati backendu i na koji se odgovori pre nego što stigne telo zahteva, ovaj zastoj se neće dogoditi. Na primer, u IIS ovo se dešava kada se šalju zahtevi za zabranjene nazive kao što je `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), na taj način početni zahtev će biti odgovorен direktno, a drugi zahtev će sadržati zahtev žrtve kao: +Međutim, ako postoji request koji je moguće poslati backendu i na koji se odgovori pre nego što stigne body, ovaj deadlock se neće desiti. U IIS, na primer, to se dešava slanjem requestova ka zabranjenim imenima kao što je `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), tako da početni request bude odmah odgovoren, a drugi request će sadržati request žrtve kao: ``` GET / HTTP/1.1 X: yGET /victim HTTP/1.1 Host: ``` -Ovo je korisno za izazivanje desync-a, ali do sada nije imalo nikakav uticaj. +Ovo je korisno za izazivanje desync-a, ali do sada to nije imalo uticaja. Međutim, post nudi rešenje za ovo pretvaranjem **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**. #### Rušenje web servera -Ova tehnika je takođe korisna u scenarijima gde je moguće **prekinuti rad web servera dok se čitaju početni HTTP podaci** ali **bez zatvaranja konekcije**. Na taj način, **telo** HTTP zahteva biće smatrano **sledećim HTTP zahtevom**. +Ova tehnika je takođe korisna u scenarijima gde je moguće **slomiti web server dok se čitaju početni HTTP podaci**, ali **bez zatvaranja konekcije**. Na taj način, **telo** HTTP zahteva će biti smatrano **sledećim HTTP zahtevom**. -Na primer, kako je objašnjeno u [**this writeup**](https://mizu.re/post/twisty-python), u Werkzeug-u je bilo moguće poslati neke **Unicode** karaktere i to će server **srušiti**. Međutim, ako je HTTP konekcija kreirana sa headerom **`Connection: keep-alive`**, telo zahteva neće biti pročitano i konekcija će ostati otvorena, tako da će se **telo** zahteva tretirati kao **sledeći HTTP zahtev**. +Na primer, kao što je objašnjeno u [**this writeup**](https://mizu.re/post/twisty-python), u Werkzeug-u je bilo moguće poslati neke **Unicode** karaktere i to će naterati server da se sruši. Međutim, ako je HTTP konekcija kreirana sa headerom **`Connection: keep-alive`**, telo zahteva neće biti pročitano i konekcija će ostati otvorena, tako da će **telo** zahteva biti tretirano kao **sledeći HTTP zahtev**. -#### Forsiranje preko hop-by-hop zaglavlja +#### Primoravanje putem hop-by-hop hedera -Zloupotrebom hop-by-hop zaglavlja možete naterati proxy da **obriše zaglavlje Content-Length ili Transfer-Encoding, čime postaje moguće iskoristiti HTTP request smuggling**. +Zloupotrebom hop-by-hop hedera možete naterati proxy da **obriše header Content-Length ili Transfer-Encoding, čime se omogućava da se HTTP request smuggling zloupotrebi**. ``` Connection: Content-Length ``` -For **više informacija o hop-by-hop headers** pogledajte: +Za **više informacija o hop-by-hop headers** posetite: {{#ref}} ../abusing-hop-by-hop-headers.md {{#endref}} -## Pronalaženje HTTP Request Smuggling +## Finding HTTP Request Smuggling -Identifikacija HTTP request smuggling ranjivosti često se može postići korišćenjem tehnika zasnovanih na vremenu, koje se oslanjaju na posmatranje koliko vremena serveru treba da odgovori na manipulisane zahteve. Ove tehnike su posebno korisne za otkrivanje CL.TE i TE.CL ranjivosti. Pored ovih metoda, postoje i druge strategije i alati koji se mogu koristiti za pronalaženje ovakvih ranjivosti: +Identifikacija ranjivosti HTTP request smuggling-a često se može postići korišćenjem tehnika vremenskog merenja, koje se oslanjaju na posmatranje koliko serveru treba da odgovori na manipulisan zahtev. Ove tehnike su posebno korisne za detekciju CL.TE i TE.CL ranjivosti. Pored ovih metoda, postoje i druge strategije i alati koji se mogu koristiti za pronalaženje ovakvih ranjivosti: -### Pronalaženje CL.TE ranjivosti korišćenjem tehnika zasnovanih na vremenu +### Pronalaženje CL.TE ranjivosti korišćenjem tehnika vremenskog merenja -- **Metoda:** +- **Metod:** -- Pošaljite zahtev koji će, ukoliko je aplikacija ranjiva, naterati back-end server da čeka dodatne podatke. +- Pošaljite zahtev koji, ako je aplikacija ranjiva, natera back-end server da čeka dodatne podatke. - **Primer:** ``` @@ -266,18 +266,18 @@ A ``` - **Posmatranje:** -- Front-end server obrađuje zahtev na osnovu `Content-Length` i prekida poruku prerano. -- Back-end server, očekujući chunked poruku, čeka sledeći chunk koji nikada ne stigne, što uzrokuje kašnjenje. +- Front-end server obrađuje zahtev na osnovu `Content-Length` i preseče poruku pre vremena. +- Back-end server, očekujući chunked poruku, čeka sledeći chunk koji nikada ne stigne, što izaziva kašnjenje. - **Indikatori:** -- Timeouti ili duga kašnjenja u odgovoru. -- Primanje 400 Bad Request greške od back-end servera, ponekad sa detaljnim informacijama o serveru. +- Timeout-ovi ili dugačka kašnjenja u odgovoru. +- Prijem 400 Bad Request greške od back-end servera, ponekad sa detaljnijim informacijama o serveru. -### Pronalaženje TE.CL ranjivosti korišćenjem tehnika zasnovanih na vremenu +### Pronalaženje TE.CL ranjivosti korišćenjem tehnika vremenskog merenja -- **Metoda:** +- **Metod:** -- Pošaljite zahtev koji će, ukoliko je aplikacija ranjiva, naterati back-end server da čeka dodatne podatke. +- Pošaljite zahtev koji, ako je aplikacija ranjiva, natera back-end server da čeka dodatne podatke. - **Primer:** ``` @@ -297,44 +297,44 @@ X ### Druge metode za pronalaženje ranjivosti -- **Differential Response Analysis:** -- Pošaljite blago promenjene verzije zahteva i posmatrajte da li se odgovori servera razlikuju na neočekivan način, što ukazuje na neslaganje u parsiranju. +- **Analiza diferencijalnih odgovora:** +- Pošaljite blago izmenjene verzije zahteva i posmatrajte da li se odgovori servera razlikuju na neočekivan način, što ukazuje na neusaglašenost u parsiranju. - **Korišćenje automatizovanih alata:** -- Alati poput Burp Suite-ovog dodatka 'HTTP Request Smuggler' mogu automatski testirati ove ranjivosti slanjem različitih oblika dvosmislenih zahteva i analizom odgovora. -- **Content-Length Variance Tests:** -- Pošaljite zahteve sa različitim vrednostima `Content-Length` koje nisu usklađene sa stvarnom dužinom sadržaja i posmatrajte kako server obrađuje takva neslaganja. -- **Transfer-Encoding Variance Tests:** -- Pošaljite zahteve sa obfuskiranim ili malformiranim `Transfer-Encoding` headerima i pratite kako se front-end i back-end serveri različito ponašaju na takve manipulacije. +- Alati poput Burp Suite-ovog 'HTTP Request Smuggler' ekstenzije mogu automatski testirati ove ranjivosti slanjem različitih oblika dvosmislenih zahteva i analizom odgovora. +- **Testovi varijacije Content-Length:** +- Pošaljite zahteve sa različitim `Content-Length` vrednostima koje nisu usklađene sa stvarnom dužinom sadržaja i posmatrajte kako server postupa sa takvim neusaglašenostima. +- **Testovi varijacije Transfer-Encoding:** +- Pošaljite zahteve sa zamaskiranim ili neispravnim `Transfer-Encoding` header-ima i pratite kako se front-end i back-end serveri različito ponašaju na takve manipulacije. -### Zaglavlje `Expect: 100-continue` +### The `Expect: 100-continue` header -Proverite kako ovo zaglavlje može pomoći u iskorišćavanju http desync-a u: +Proverite kako ovaj header može pomoći pri eksploatisanju http desync-a u: {{#ref}} ../../network-services-pentesting/pentesting-web/special-http-headers.md {{#endref}} -### Testiranje ranjivosti HTTP Request Smuggling +### HTTP Request Smuggling Vulnerability Testing -Nakon potvrde efikasnosti tehnika zasnovanih na vremenu, ključno je proveriti da li se zahtevi klijenta mogu manipulisati. Jednostavan metod je pokušaj poisoning vaših zahteva — na primer, naterati zahtev ka `/` da vrati 404 odgovor. Primeri `CL.TE` i `TE.CL` ranije diskutovani u [Basic Examples](#basic-examples) pokazuju kako poisonovati klijentov zahtev da izazove 404 odgovor, iako klijent pokušava da pristupi drugom resursu. +Nakon potvrde efikasnosti tehnika vremenskog merenja, ključno je verifikovati da li klijentski zahtevi zaista mogu biti manipulisani. Jednostavan metod je pokušaj "poison"-ovanja (zatrovanja) vaših zahteva — na primer, naterajte zahtev ka `/` da proizvede 404 odgovor. Primeri `CL.TE` i `TE.CL` iz [Basic Examples](#basic-examples) ranije pokazuju kako zatrovati klijentov zahtev da izazove 404 odgovor, uprkos tome što klijent pokušava da pristupi drugom resursu. **Ključna razmatranja** -Kada testirate ranjivosti request smuggling ometanjem drugih zahteva, imajte na umu: +Pri testiranju za request smuggling ranjivosti mešanjem sa drugim zahtevima, imajte u vidu: -- **Odvojene mrežne konekcije:** "attack" i "normal" zahtevi treba da budu poslati preko odvojenih mrežnih konekcija. Korišćenje iste konekcije za oba ne potvrđuje prisustvo ranjivosti. -- **Konzistentan URL i parametri:** Težite da koristite identične URL-ove i nazive parametara za oba zahteva. Moderne aplikacije često usmeravaju zahteve ka specifičnim back-end serverima na osnovu URL-a i parametara. Usklađivanje ovih povećava verovatnoću da će oba zahteva obrađivati isti server, što je preduslov za uspešan attack. -- **Vremenski uslovi i trke:** "normal" zahtev, koji služi za detekciju interferencije od "attack" zahteva, takmiči se sa ostalim istovremenim zahtevima aplikacije. Zato pošaljite "normal" zahtev odmah nakon "attack" zahteva. Zauzete aplikacije mogu zahtevati više pokušaja za konačnu potvrdu ranjivosti. -- **Izazovi load balancera:** Front-end serveri koji deluju kao load balanceri mogu distribuirati zahteve na različite back-end sisteme. Ako se "attack" i "normal" zahtevi nađu na različitim sistemima, attack neće uspeti. Ovaj aspekt load balancing-a može zahtevati više pokušaja da se potvrdi ranjivost. -- **Neželjeni uticaj na korisnike:** Ako vaš attack nenamerno utiče na zahtev drugog korisnika (ne "normal" zahteva koji ste poslali radi detekcije), to ukazuje da je vaš attack uticao na drugog korisnika aplikacije. Kontinuirano testiranje može ometati druge korisnike, što zahteva oprezan pristup. +- **Različite mrežne konekcije:** "attack" i "normal" zahtevi treba da budu poslati preko odvojenih mrežnih konekcija. Korišćenje iste konekcije za oba ne potvrđuje postojanje ranjivosti. +- **Konzistentan URL i parametri:** Težite da koristite identične URL-ove i nazive parametara za oba zahteva. Moderne aplikacije često rutiraju zahteve ka specifičnim back-end serverima na osnovu URL-a i parametara. Podudaranje ovih podataka povećava verovatnoću da će oba zahteva obraditi isti server, što je preduslov za uspešan napad. +- **Vremenski uslovi i trkanje (racing):** "Normal" zahtev, koji treba da detektuje interferenciju od "attack" zahteva, takmiči se sa drugim istovremenim zahtevima aplikacije. Zato pošaljite "normal" zahtev odmah nakon "attack" zahteva. Zauzete aplikacije mogu zahtevati više pokušaja za konačnu potvrdu ranjivosti. +- **Izazovi balansiranja opterećenja:** Front-end serveri koji rade kao balanseri opterećenja mogu raspoređivati zahteve na različite back-end sisteme. Ako "attack" i "normal" zahtevi završe na različitim sistemima, napad neće uspeti. Ovaj aspekt balansiranja opterećenja može zahtevati više pokušaja da biste potvrdili ranjivost. +- **Neželjeni uticaj na korisnike:** Ako vaš napad nenamerno utiče na zahtev nekog drugog korisnika (ne na "normal" zahtev koji ste poslali za detekciju), to ukazuje da je vaš napad uticao na drugog korisnika aplikacije. Kontinuirano testiranje može ometati druge korisnike, pa postupajte oprezno. -## Razlikovanje HTTP/1.1 pipelining artefakata od pravog request smuggling-a +## Distinguishing HTTP/1.1 pipelining artifacts vs genuine request smuggling -Ponovno korišćenje konekcije (keep-alive) i pipelining lako mogu stvoriti iluzije "smuggling"-a u alatima za testiranje koji šalju više zahteva preko istog soketa. Naučite da razlikujete bezopasne artefakte sa klijentske strane od stvarnog desync-a na serverskoj strani. +Poništavanje konekcije (keep-alive) i pipelining lako mogu proizvesti iluzije "smuggling"-a u alatima za testiranje koji šalju više zahteva na istom socket-u. Naučite da odvojite bezopasne artefakte sa klijentske strane od stvarne desinhronizacije na strani servera. -### Zašto pipelining stvara klasične lažne pozitivne rezultate +### Why pipelining creates classic false positives -HTTP/1.1 ponovo koristi jednu TCP/TLS konekciju i konkatenira zahteve i odgovore na istom toku. U pipeliningu klijent šalje više zahteva jedan za drugim i oslanja se na odgovore u istom redosledu. Uobičajen lažno-pozitivan slučaj je ponovno slanje malformiranog CL.0-style payload-a dva puta na jednoj konekciji: +HTTP/1.1 ponovo koristi jednu TCP/TLS konekciju i konkatenira zahteve i odgovore na istom toku. U pipelining-u, klijent šalje više zahteva jedan za drugim i oslanja se na odgovore u istom redu. Uobičajen false-positive je ponovo slanje malformiranog CL.0-stila payload-a dva puta na jednoj konekciji: ``` POST / HTTP/1.1 Host: hackxor.net @@ -343,7 +343,7 @@ Content_Length: 47 GET /robots.txt HTTP/1.1 X: Y ``` -Niste priložili sadržaj. Pošaljite tekst fajla src/pentesting-web/http-request-smuggling/README.md koji želite da prevedem. +Ne vidim sadržaj fajla. Pošaljite tekst iz src/pentesting-web/http-request-smuggling/README.md i prevešću ga na srpski, zadržavajući sve markdown/html tagove i linkove. ``` HTTP/1.1 200 OK Content-Type: text/html @@ -357,7 +357,7 @@ Content-Type: text/plain User-agent: * Disallow: /settings ``` -Ako server ignoriše malformirani `Content_Length`, ne postoji FE↔BE desync. Sa reuse, vaš klijent je zapravo poslao ovaj byte-stream, koji je server parsirao kao dva nezavisna zahteva: +Ako server ignoriše neispravan `Content_Length`, nema FE↔BE desync. Sa reuse, vaš klijent je zapravo poslao ovaj byte-stream, koji je server parsirao kao dva nezavisna zahteva: ``` POST / HTTP/1.1 Host: hackxor.net @@ -371,34 +371,34 @@ Content_Length: 47 GET /robots.txt HTTP/1.1 X: Y ``` -Impact: nema. Samo ste desynced svoj client od framinga servera. +Uticaj: nijedan. Samo ste desinhronizovali klijenta u odnosu na framing servera. > [!TIP] -> Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse". +> Burp moduli koji zavise od reuse/pipelining: Turbo Intruder sa `requestsPerConnection>1`, Intruder sa "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" ili "Enable connection reuse". -### Litmus tests: pipelining or real desync? +### Litmus testovi: pipelining ili realni desync? 1. Disable reuse and re-test -- U Burp Intruder/Repeateru, isključite HTTP/1 reuse i izbegavajte "Send group in sequence". -- U Turbo Intruderu, postavite `requestsPerConnection=1` i `pipeline=False`. -- Ako ponašanje nestane, verovatno je u pitanju client-side pipelining, osim ako ne radite sa connection-locked/stateful targetima ili client-side desync. +- U Burp Intruder/Repeater, isključite HTTP/1 reuse i izbegavajte "Send group in sequence". +- U Turbo Intruder, postavite `requestsPerConnection=1` i `pipeline=False`. +- Ako se ponašanje ukloni, verovatno je u pitanju client-side pipelining, osim ako ne radite sa connection-locked/stateful targetima ili client-side desync. 2. HTTP/2 nested-response check -- Pošaljite HTTP/2 zahtev. Ako response body sadrži kompletnu nested HTTP/1 response, dokazali ste backend parsing/desync bug umesto čistog client artefakta. +- Pošaljite HTTP/2 request. Ako telo odgovora sadrži kompletan ugnježdeni HTTP/1 response, dokazali ste backend parsing/desync bug umesto čistog client artefakta. 3. Partial-requests probe for connection-locked front-ends -- Neki FE-ovi ponovo koriste upstream BE konekciju samo ako je klijent ponovo koristio svoju. Koristite partial-requests da detektujete FE ponašanje koje prati client reuse. +- Neki FEs ponovo koriste upstream BE konekciju samo ako je klijent ponovo koristio svoju. Koristite partial-requests da detektujete FE ponašanje koje reflektuje reuse klijenta. - Pogledajte PortSwigger "Browser‑Powered Desync Attacks" za connection-locked tehniku. 4. State probes - Tražite razlike između prvog i narednih zahteva na istoj TCP konekciji (first-request routing/validation). -- Burp "HTTP Request Smuggler" uključuje connection‑state probe koji ovo automatizuje. +- Burp "HTTP Request Smuggler" uključuje connection‑state probe koja automatizuje ovo. 5. Visualize the wire -- Koristite Burp "HTTP Hacker" ekstenziju da direktno pregledate concatenation i message framing dok eksperimentišete sa reuse i partial requests. +- Koristite Burp "HTTP Hacker" ekstenziju da direktno pregledate konkatenaciju i framing poruka dok eksperimentišete sa reuse i partial requests. ### Connection‑locked request smuggling (reuse-required) -Neki front-endovi reuse-uju upstream konekciju samo kada klijent reuse-uje svoju. Stvarna smuggling eksploatacija postoji, ali zavisi od client-side reuse. Da razlikujete i dokažete uticaj: +Neki front-endovi ponovo koriste upstream konekciju samo kada klijent ponovo koristi svoju. Stvarni smuggling postoji, ali je uslovljen client-side reuse-om. Da biste razlikovali i dokazali uticaj: - Prove the server-side bug - Koristite HTTP/2 nested-response check, ili -- Koristite partial-requests da pokažete da FE reuse-uje upstream samo kada to klijent čini. +- Koristite partial-requests da pokažete da FE ponovo koristi upstream samo kada to client radi. - Pokažite stvarni uticaj čak i ako je direktna cross-user socket zloupotreba blokirana: - Cache poisoning: poison shared caches via the desync so responses affect other users. - Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass. @@ -412,14 +412,13 @@ Neki front-endovi reuse-uju upstream konekciju samo kada klijent reuse-uje svoju > >{{#ref}} >../http-connection-request-smuggling.md -> -{{#endref}} +>{{#endref}} ### Client‑side desync constraints -Ako ciljate browser-powered/client-side desync, zlonamerni zahtev mora biti poslat iz browser-a cross-origin. Header obfuscation tricks neće raditi. Fokusirajte se na primitive dostupne kroz navigation/fetch, pa zatim pivotujte na cache poisoning, header disclosure, ili front-end control bypass gde downstream komponente reflektuju ili keširaju odgovore. +Ako ciljate browser-powered/client-side desync, maliciozni zahtev mora biti poslativ od strane browsera cross-origin. Header obfuscation trikovi neće raditi. Fokusirajte se na primitive dostupne preko navigation/fetch, pa zatim pivotirajte na cache poisoning, header disclosure, ili front-end control bypass gde downstream komponente reflektuju ili keširaju odgovore. -For background and end-to-end workflows: +Za pozadinu i end-to-end workflow-e: {{#ref}} browser-http-request-smuggling.md @@ -427,19 +426,19 @@ browser-http-request-smuggling.md ### Tooling to help decide -- HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation. +- HTTP Hacker (Burp BApp Store): prikazuje nisko-nivo HTTP ponašanje i socket concatenation. - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda -- Turbo Intruder: precise control over connection reuse via `requestsPerConnection`. -- Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation. +- Turbo Intruder: precizna kontrola nad connection reuse-om putem `requestsPerConnection`. +- Burp HTTP Request Smuggler: uključuje connection‑state probe za otkrivanje first‑request routing/validation. > [!NOTE] -> Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.). +> Smatrajte efekte koji zavise samo od reuse-a nebitnim osim ako ne možete dokazati server-side desync i priložiti konkretan uticaj (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, itd.). ## Abusing HTTP Request Smuggling ### Circumventing Front-End Security via HTTP Request Smuggling -Ponekad front-end proxyji primenjuju sigurnosne mere i pregledaju dolazne zahteve. Međutim, ove mere se mogu zaobići iskorišćavanjem HTTP Request Smuggling-a, što omogućava neovlašćen pristup zaštićenim endpoint-ima. Na primer, pristupanje `/admin` može biti zabranjeno spolja, a front-end proxy aktivno blokira takve pokušaje. Ipak, taj proxy može zanemariti inspekciju embedded requests unutar smuggled HTTP zahteva, ostavljajući rupu za zaobilaženje ovih ograničenja. +Ponekad front-end proxyji primenjuju sigurnosne mere, brižljivo proveravajući dolazeće zahteve. Međutim, ove mere se mogu zaobići iskorišćavanjem HTTP Request Smuggling-a, omogućavajući neovlašćeni pristup ograničenim endpoint-ima. Na primer, pristup `/admin` može biti zabranjen spolja, pri čemu front-end proxy aktivno blokira takve pokušaje. Ipak, taj proxy može zanemriti inspekciju ugrađenih zahteva unutar smuggled HTTP zahteva, ostavljajući rupu za zaobilaženje ovih ograničenja. Razmotrite sledeće primere koji ilustruju kako se HTTP Request Smuggling može koristiti za zaobilaženje front-end sigurnosnih kontrola, posebno ciljajući putanju `/admin` koja je obično zaštićena front-end proxyjem: @@ -460,9 +459,11 @@ Content-Length: 10 x= ``` -U CL.TE napadu, zaglavlje `Content-Length` se koristi za početni zahtev, dok ugrađeni naredni zahtev koristi zaglavlje `Transfer-Encoding: chunked`. front-end proxy obrađuje početni `POST` zahtev, ali ne uspeva da pregleda ugrađeni `GET /admin` zahtev, što omogućava neovlašćen pristup putanji `/admin`. +U CL.TE napadu, zaglavlje `Content-Length` se koristi za inicijalni zahtev, dok naknadni ugrađeni zahtev koristi zaglavlje `Transfer-Encoding: chunked`. -**TE.CL Example** +Front-end proxy obrađuje inicijalni `POST` zahtev, ali ne uspeva da ispita ugrađeni `GET /admin` zahtev, što omogućava neovlašćen pristup putanji `/admin`. + +**TE.CL Primer** ``` POST / HTTP/1.1 Host: [redacted].web-security-academy.net @@ -478,13 +479,13 @@ a=x 0 ``` -Suprotno tome, u TE.CL napadu, inicijalni `POST` zahtev koristi `Transfer-Encoding: chunked`, a naknadni ugrađeni zahtev se obrađuje na osnovu `Content-Length` zaglavlja. Slično CL.TE napadu, front-end proxy zanemaruje smuglovani `GET /admin` zahtev, nesvesno omogućavajući pristup ograničenom `/admin` putu. +Suprotno tome, u TE.CL attacku, početni `POST` zahtev koristi `Transfer-Encoding: chunked`, a naknadni ugrađeni zahtev se obrađuje na osnovu `Content-Length` headera. Slično CL.TE attacku, front-end proxy previdi smuggled `GET /admin` request, nenamerno omogućavajući pristup ograničenom `/admin` path-u. ### Otkrivanje prepisivanja zahteva na front-endu -Aplikacije često koriste **front-end server** da izmenjuju dolazne zahteve pre nego što ih proslede na back-end server. Tipična izmena uključuje dodavanje zaglavlja, poput `X-Forwarded-For: `, kako bi se IP klijenta prosledio back-endu. Razumevanje ovih izmena može biti ključno, jer može otkriti načine za **zaobilaženje zaštita** ili **otkrivanje skrivenih informacija ili krajnjih tačaka**. +Aplikacije često koriste **front-end server** da modifikuju dolazne zahteve pre nego što ih proslede back-end serveru. Tipična modifikacija uključuje dodavanje headera, kao što je `X-Forwarded-For: `, kako bi se IP klijenta prosledio back-endu. Razumevanje ovih izmena može biti ključno, jer može otkriti načine za **bypass protections** ili **uncover concealed information or endpoints**. -Da biste istražili kako proxy menja zahtev, pronađite POST parametar koji back-end reflektuje u odgovoru. Zatim sastavite zahtev, koristeći taj parametar poslednjim, slično sledećem: +Da biste ispitali kako proxy menja zahtev, pronađite POST parameter koji back-end vraća u odgovoru. Zatim sastavite zahtev, koristeći taj parameter poslednjim, slično sledećem: ``` POST / HTTP/1.1 Host: vulnerable-website.com @@ -501,19 +502,19 @@ Content-Length: 100 search= ``` -U ovoj strukturi, naredne komponente zahteva se dodaju nakon `search=`, koji je parametar reflektovan u odgovoru. Ova refleksija će otkriti zaglavlja narednog zahteva. +U ovoj strukturi, naknadne komponente zahteva se dodaju posle `search=`, koji je parametar reflektovan u odgovoru. Ovo reflektovanje će otkriti zaglavlja narednog zahteva. -Važno je uskladiti header `Content-Length` ugneždenog zahteva sa stvarnom dužinom sadržaja. Početak sa malom vrednošću i postepeno povećavanje je preporučljivo, jer previše niska vrednost skraćuje reflektovane podatke, dok previše visoka vrednost može prouzrokovati grešku zahteva. +Važno je uskladiti zaglavlje `Content-Length` ugnježdenog zahteva sa stvarnom dužinom sadržaja. Preporučljivo je početi sa malom vrednošću i postepeno je povećavati, jer će premala vrednost skratiti reflektovane podatke, dok prevelika vrednost može prouzrokovati grešku zahteva. -Tehnika je primenljiva i u kontekstu TE.CL ranjivosti, ali zahtev bi trebalo da se završi sa `search=\r\n0`. Bez obzira na karaktere novog reda, vrednosti će se dodavati u search parametar. +Ova tehnika je takođe primenljiva u kontekstu TE.CL ranjivosti, ali zahtev bi trebalo da se završi sa `search=\r\n0`. Bez obzira na karaktere za novi red, vrednosti će se dodati parametru search. -Ova metoda prvenstveno služi da se razumeju izmene zahteva koje pravi front-end proxy, u suštini vršeći samoinicijativnu istragu. +Ovaj metod prvenstveno služi za razumevanje izmena zahteva koje pravi front-end proxy, praktično obavljajući samostalnu istragu. ### Presretanje zahteva drugih korisnika -Moguće je presresti zahteve narednog korisnika tako što se tokom POST operacije kao vrednost parametra doda specifičan zahtev. Evo kako se to može izvesti: +Moguće je presresti zahteve narednog korisnika tako što se tokom POST operacije doda specifičan zahtev kao vrednost parametra. Evo kako se to može izvesti: -Dodavanjem sledećeg zahteva kao vrednosti parametra, možete uskladištiti zahtev narednog klijenta: +Dodanjem sledećeg zahteva kao vrednosti parametra, možete sačuvati zahtev narednog klijenta: ``` POST / HTTP/1.1 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net @@ -533,20 +534,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment= ``` -U ovom scenariju, **comment parameter** služi za čuvanje sadržaja iz sekcije komentara objave na javno dostupnoj stranici. Shodno tome, sadržaj narednog zahteva pojaviće se kao komentar. +U ovom scenariju, **comment parameter** je namenjen za čuvanje sadržaja u sekciji komentara objave na javno dostupnoj stranici. Posledično, sadržaj narednog zahteva će se pojaviti kao komentar. -Međutim, ova tehnika ima ograničenja. Generalno, ona hvata podatke samo do delimitera parametra koji se koristi u smuggled request. Za URL-encoded form submissions, taj delimiter je karakter `&`. To znači da će uhvaćeni sadržaj iz zahteva žrtve stati na prvom `&`, koji može biti čak i deo query stringa. +Međutim, ova tehnika ima ograničenja. Generalno, ona hvata podatke samo do delimitera parametra koji se koristi u smuggled zahtevu. Za URL-encoded form submissions, taj delimiter je karakter `&`. To znači da će uhvaćeni sadržaj iz zahteva žrtve prestati na prvom `&`, koji čak može biti deo query stringa. -Vredno je napomenuti i da je ovaj pristup izvodljiv i kod TE.CL ranjivosti. U takvim slučajevima zahtev treba da se završi sa `search=\r\n0`. Bez obzira na znakove novog reda, vrednosti će biti dodatе parametru search. +Takođe, vredi napomenuti da je ovaj pristup moguć i kod TE.CL ranjivosti. U takvim slučajevima, zahtev treba da se završi sa `search=\r\n0`. Bez obzira na newline karaktere, vrednosti će biti dodate parametru search. -### Korišćenje HTTP request smuggling za iskorišćavanje reflected XSS +### Korišćenje HTTP Request Smuggling za iskorišćavanje Reflected XSS -HTTP Request Smuggling može se iskoristiti za napad na veb stranice ranjive na **Reflected XSS**, nudeći značajne prednosti: +HTTP Request Smuggling može se iskoristiti za napad na veb-stranice ranjive na **Reflected XSS**, nudeći značajne prednosti: - Interakcija sa ciljnim korisnicima **nije potrebna**. -- Dozvoljava iskorišćavanje XSS-a u delovima zahteva koji su **obično nedostižni**, poput HTTP request headers. +- Dozvoljava iskorišćavanje XSS-a u delovima zahteva koji su **obično nedostupni**, kao što su HTTP request headers. -U scenarijima gde je veb-sajt podložan Reflected XSS preko User-Agent header-a, sledeći payload pokazuje kako iskoristiti ovu ranjivost: +U scenarijima gde je veb-sajt podložan Reflected XSS preko User-Agent zaglavlja, sledeći payload pokazuje kako iskoristiti ovu ranjivost: ``` POST / HTTP/1.1 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net @@ -569,24 +570,24 @@ A= ``` Ovaj payload je strukturiran da iskoristi ranjivost na sledeći način: -1. Pokretanjem `POST` zahteva, naizgled tipičnog, sa zaglavljem `Transfer-Encoding: chunked` koje označava početak smuggling-a. -2. Zatim `0`, koji označava kraj chunked message body. -3. Potom se ubacuje smuggled `GET` zahtev, gde je `User-Agent` header injektovan skriptom ``, što pokreće XSS kada server obradi ovaj naredni zahtev. +1. Pokretanje `POST` request-a, naizgled tipičnog, sa `Transfer-Encoding: chunked` header-om koji označava početak smuggling. +2. Sledeće dolazi `0`, što označava kraj chunked tela poruke. +3. Zatim se uvodi smuggled `GET` request, gde je `User-Agent` header ubrizgan skriptom ``, što pokreće XSS kada server obradi ovaj naredni request. -Manipulišući `User-Agent` kroz smuggling, payload zaobilazi normalna ograničenja zahteva i tako iskorišćava Reflected XSS ranjivost na nestandardan ali efikasan način. +Manipulišući `User-Agent` kroz smuggling, payload zaobilazi normalna ograničenja zahteva i na taj način, na nestandardan ali efektan način, iskorišćava Reflected XSS ranjivost. #### HTTP/0.9 > [!CAUTION] -> U slučaju da se korisnički sadržaj reflektuje u odgovoru sa **`Content-type`** kao što je **`text/plain`**, što sprečava izvršenje XSS. Ako server podržava **HTTP/0.9** možda je moguće zaobići ovo! +> U slučaju da se korisnički sadržaj reflektuje u odgovoru sa **`Content-type`** kao što je **`text/plain`**, to sprečava izvršavanje XSS. Ako server podržava **HTTP/0.9 možda je moguće zaobići ovo**! -Verzija HTTP/0.9 je postojala pre 1.0 i koristi isključivo **GET** zahteve i **ne** odgovara sa **headers**, već samo body. +Verzija HTTP/0.9 je prethodila 1.0 i koristi samo **GET** verbs i **doesn’t** odgovara sa **headers**, već samo telo. -U [**this writeup**](https://mizu.re/post/twisty-python), ovo je zloupotrebljeno koristeći request smuggling i **vulnerable endpoint that will reply with the input of the user** da bi se smuglovao zahtev sa HTTP/0.9. Parametar koji je reflektovan u odgovoru sadržao je **fake HTTP/1.1 response (with headers and body)** pa će odgovor sadržati validan izvršni JS kod sa `Content-Type` `text/html`. +U [**this writeup**](https://mizu.re/post/twisty-python), ovo je zloupotrebljeno pomoću request smuggling i **vulnerable endpoint that will reply with the input of the user** da bi se smugglao request sa HTTP/0.9. Parametar koji će biti reflektovan u odgovoru sadržao je **fake HTTP/1.1 response (with headers and body)**, tako da odgovor sadrži validan izvršni JS kod sa `Content-Type` `text/html`. -### Exploiting On-site Redirects with HTTP Request Smuggling +### Eksploatisanje on-site redirect-ova pomoću HTTP Request Smuggling -Aplicacije često preusmeravaju sa jednog URL-a na drugi koristeći hostname iz `Host` header`-a u redirect URL-u. Ovo je uobičajeno kod web servera kao što su Apache i IIS. Na primer, zahtev za folder bez trailing slash-a rezultira preusmeravanjem da se uključi slash: +Aplikacije često preusmeravaju sa jednog URL-a na drugi koristeći hostname iz `Host` header-a u redirect URL-u. Ovo je uobičajeno kod web servera kao što su Apache i IIS. Na primer, zahtev za folder bez završnog kosa crte rezultira preusmerenjem koje dodaje kosu crtu: ``` GET /home HTTP/1.1 Host: normal-website.com @@ -596,7 +597,7 @@ Rezultira u: HTTP/1.1 301 Moved Permanently Location: https://normal-website.com/home/ ``` -Iako naizgled bezopasno, ovo ponašanje može biti iskorišćeno pomoću HTTP request smuggling da preusmeri korisnike na eksterni sajt. Na primer: +Iako naizgled bezopasno, ovo ponašanje se može iskoristiti pomoću HTTP request smuggling da preusmeri korisnike na eksterni sajt. Na пример: ``` POST / HTTP/1.1 Host: vulnerable-website.com @@ -617,22 +618,22 @@ Host: attacker-website.com Foo: XGET /scripts/include.js HTTP/1.1 Host: vulnerable-website.com ``` -Rezultira u: +Dovodi do: ``` HTTP/1.1 301 Moved Permanently Location: https://attacker-website.com/home/ ``` -U ovom scenariju zahtev korisnika za JavaScript fajlom je otet. Napadač može potencijalno kompromitovati korisnika tako što će poslati maliciozni JavaScript u odgovoru. +U ovom scenariju, zahtev korisnika za JavaScript fajlom se otima. Napadač može kompromitovati korisnika tako što će u odgovoru poslati maliciozni JavaScript. -### Eksploatacija Web Cache Poisoning putem HTTP Request Smuggling +### Exploiting Web Cache Poisoning via HTTP Request Smuggling -Web cache poisoning može biti izveden ako bilo koja komponenta **front-end infrastrukture kešira sadržaj**, obično radi poboljšanja performansi. Manipulacijom serverovog odgovora moguće je **poison the cache**. +Web cache poisoning može biti izveden ako bilo koja komponenta **front-end infrastrukture kešira sadržaj**, obično radi poboljšanja performansi. Manipulacijom odgovora servera, moguće je **poison the cache**. -Ranije smo videli kako se odgovori servera mogu izmeniti da vrate 404 grešku (pogledajte [Basic Examples](#basic-examples)). Na sličan način moguće je prevariti server da u odgovoru dostavi sadržaj `/index.html` na zahtev za `/static/include.js`. Kao posledica, sadržaj `/static/include.js` biva zamenjen u kešu sadržajem od `/index.html`, čime `/static/include.js` postaje nedostupan korisnicima i potencijalno dovodi do Denial of Service (DoS). +Ranije smo videli kako se odgovori servera mogu izmeniti da vrate 404 grešku (pogledajte [Basic Examples](#basic-examples)). Na sličan način moguće je prevariti server da u odgovoru za zahtev za `/static/include.js` isporuči sadržaj `/index.html`. Kao posledica, sadržaj `/static/include.js` se u kešu zamenjuje sadržajem `/index.html`, čineći `/static/include.js` nedostupnim korisnicima, što potencijalno vodi do Denial of Service (DoS). -Ova tehnika postaje posebno snažna ako se otkrije **Open Redirect vulnerability** ili ako postoji **on-site redirect to an open redirect**. Takve ranjivosti mogu se iskoristiti da zamene keširani sadržaj `/static/include.js` skriptom pod kontrolom napadača, suštinski omogućavajući masovni Cross-Site Scripting (XSS) napad na sve klijente koji zahtevaju ažurirani `/static/include.js`. +Tehnika postaje posebno potentna ako se otkrije **Open Redirect vulnerability** ili ako postoji **on-site redirect to an open redirect**. Takve ranjivosti se mogu iskoristiti da se keširani sadržaj `/static/include.js` zameni skriptom pod kontrolom napadača, što u suštini omogućava rašireni Cross-Site Scripting (XSS) napad na sve klijente koji zahtevaju ažurirani `/static/include.js`. -Ispod je ilustracija iskorišćavanja **cache poisoning combined with an on-site redirect to open redirect**. Cilj je izmeniti keširani sadržaj `/static/include.js` da servira JavaScript kod pod kontrolom napadača: +U nastavku je ilustracija iskorišćavanja **cache poisoning combined with an on-site redirect to open redirect**. Cilj je promeniti keširani sadržaj `/static/include.js` tako da servira JavaScript kod pod kontrolom napadača: ``` POST / HTTP/1.1 Host: vulnerable.net @@ -650,18 +651,18 @@ Content-Length: 10 x=1 ``` -Obratite pažnju na ugrađeni zahtev koji cilja `/post/next?postId=3`. Ovaj zahtev će biti preusmeren na `/post?postId=4`, koristeći **Host header value** da odredi domen. Menjanjem **Host header**-a, napadač može preusmeriti zahtev na svoj domen (**on-site redirect to open redirect**). +Note the embedded request targeting `/post/next?postId=3`. This request will be redirected to `/post?postId=4`, utilizing the **Host header value** to determine the domain. By altering the **Host header**, the attacker can redirect the request to their domain (**on-site redirect to open redirect**). -Nakon uspešnog **socket poisoning**, treba inicirati **GET request** za `/static/include.js`. Taj zahtev će biti kompromitovan prethodnim **on-site redirect to open redirect** zahtevom i preuzeće sadržaj skripta kojim upravlja napadač. +After successful **socket poisoning**, a **GET request** for `/static/include.js` should be initiated. This request will be contaminated by the prior **on-site redirect to open redirect** request and fetch the content of the script controlled by the attacker. -Nakon toga, svaki zahtev za `/static/include.js` poslužiće keširani sadržaj napadačevog skripta, efektivno pokrećući široko rasprostranjen XSS napad. +Subsequently, any request for `/static/include.js` will serve the cached content of the attacker's script, effectively launching a broad XSS attack. -### Korišćenje HTTP request smuggling za izvođenje web cache deception +### Using HTTP request smuggling to perform web cache deception > **Koja je razlika između web cache poisoning i web cache deception?** > -> - U **web cache poisoning**, napadač navodi aplikaciju da sačuva neki maliciozni sadržaj u kešu, i taj sadržaj se iz keša posluži drugim korisnicima aplikacije. -> - U **web cache deception**, napadač navodi aplikaciju da sačuva osetljiv sadržaj koji pripada drugom korisniku u kešu, a napadač zatim preuzima taj sadržaj iz keša. +> - Kod **web cache poisoning**, napadač natera aplikaciju da sačuva neki maliciozni sadržaj u kešu, i taj sadržaj se posluži iz keša drugim korisnicima aplikacije. +> - Kod **web cache deception**, napadač natera aplikaciju da sačuva osetljiv sadržaj koji pripada drugom korisniku u kešu, a zatim napadač preuzme taj sadržaj iz keša. Napadač kreira smuggled request koji preuzima osetljiv sadržaj specifičan za korisnika. Razmotrite sledeći primer: ```markdown @@ -674,17 +675,17 @@ Napadač kreira smuggled request koji preuzima osetljiv sadržaj specifičan za `GET /private/messages HTTP/1.1`\ `Foo: X` ``` -Ako ovaj podmetnuti zahtev zagadi cache unos namenjen statičkom sadržaju (npr. `/someimage.png`), osetljivi podaci žrtve sa `/private/messages` mogu biti keširani pod tim unosom statičkog sadržaja. Kao posledica, napadač bi potencijalno mogao da preuzme te keširane osetljive podatke. +Ako ova smuggled request otruje cache entry namenjen static content-u (npr. `/someimage.png`), osetljivi podaci žrtve iz `/private/messages` mogu biti keširani pod tim cache entry-jem. Posledično, napadač bi potencijalno mogao dohvatiti te keširane osetljive podatke. -### Abusing TRACE via HTTP Request Smuggling +### Zloupotreba TRACE via HTTP Request Smuggling -[**In this post**](https://portswigger.net/research/trace-desync-attack) se sugeriše da ako server ima omogućenu metodu TRACE, može biti moguće zloupotrebiti je sa HTTP Request Smuggling. Ovo je zato što ova metoda reflektuje svaki header poslat serveru kao deo body response-a. Na primer: +[**In this post**](https://portswigger.net/research/trace-desync-attack) je sugerisano da, ako server ima omogućenu metodu TRACE, može biti moguće zloupotrebiti je pomoću HTTP Request Smuggling. Ovo je zato što ta metoda reflektuje svaki header poslat serveru kao deo body odgovora. Na primer: ``` TRACE / HTTP/1.1 Host: example.com XSS: ``` -Pošaljite sadržaj datoteke src/pentesting-web/http-request-smuggling/README.md koju želite da prevedem na srpski. Prevod će zadržati svu markdown/html sintaksu, code blokove, linkove i posebne tagove neprevodljivima, kao što ste naveli. +Pošaljite sadržaj (markdown) koji želite da prevedem — nalepite ovde sadržaj datoteke src/pentesting-web/http-request-smuggling/README.md. ``` HTTP/1.1 200 OK Content-Type: message/http @@ -695,17 +696,17 @@ Host: vulnerable.com XSS: X-Forwarded-For: xxx.xxx.xxx.xxx ``` -Jedan primer kako zloupotrebiti ovo ponašanje bio bi da se prvo **smuggle first a HEAD request**. Na ovaj request će biti odgovoreno samo sa **headers** od GET request-a (među njima **`Content-Type`**). I odmah posle HEAD-a **smuggle a TRACE request**, koji će **reflektovati poslate podatke**.\ -Pošto HEAD response sadrži `Content-Length` header, **response of the TRACE request će biti tretiran kao body HEAD response-a, te će u odgovoru reflektovati proizvoljne podatke**.\ -Ovaj odgovor će biti poslat narednom request-u preko konekcije, pa se ovo može **iskoristiti u keširanom JS fajlu, na primer, za injektovanje proizvoljnog JS koda**. +Primer kako zloupotrebiti ovo ponašanje bio bi da se **smuggle first a HEAD request**. Ovaj request će biti odgovorен samo sa **headers** od GET request-a (među njima **`Content-Type`**). I smuggle **immediately after the HEAD a TRACE request**, koji će **reflecting the sent data**.\ +Pošto HEAD response sadrži `Content-Length` header, **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** u odgovoru.\ +Taj odgovor će biti poslat sledećem request-u preko konekcije, pa se ovo može **used in a cached JS file for example to inject arbitrary JS code**. -### Zloupotreba TRACE путем HTTP Response Splitting +### Zloupotreba TRACE via HTTP Response Splitting -Preporučuje se da pratite [**this post**](https://portswigger.net/research/trace-desync-attack) za još jedan način zloupotrebe TRACE metode. Kao što je pomenuto, smuggling a HEAD request i a TRACE request omogućava da se **kontrolišu neki reflektovani podaci** u odgovoru na HEAD request. Dužina tela HEAD odgovora je u osnovi naznačena u `Content-Length` headeru i formirana je od odgovora na TRACE request. +Nastavljanje praćenja [**this post**](https://portswigger.net/research/trace-desync-attack) predlaže drugi način zloupotrebe TRACE metode. Kao što je pomenuto, smuggling a HEAD request and a TRACE request omogućava **control some reflected data** u odgovoru na HEAD request. Dužina body-ja HEAD request-a je u osnovi naznačena u `Content-Length` header-u i formira se iz odgovora na TRACE request. -Dakle, nova ideja bi bila da, poznavajući taj `Content-Length` i podatke iz TRACE response-a, bude moguće da TRACE response sadrži validan HTTP response posle poslednjeg bajta obuhvaćenog `Content-Length`-om, što napadaču omogućava potpunu kontrolu nad request-om koji će biti sledeći obrađen (što se može iskoristiti za cache poisoning). +Stoga bi nova ideja bila da, znajući ovaj `Content-Length` i podatke date u TRACE response-u, bude moguće učiniti da TRACE response sadrži validan HTTP response posle poslednjeg bajta navedenog u `Content-Length`, što napadaču omogućava potpunu kontrolu nad request-om za sledeći odgovor (što bi moglo biti iskorišćeno za cache poisoning). -Primer: +Example: ``` GET / HTTP/1.1 Host: example.com @@ -724,7 +725,7 @@ Content-Length: 44\r\n \r\n ``` -Generisaće ove odgovore (obratite pažnju kako HEAD odgovor ima Content-Length, zbog čega je TRACE odgovor deo HEAD tela, i kada HEAD Content-Length istekne validan HTTP odgovor je smuggled): +Generisaće ove odgovore (obratite pažnju kako HEAD odgovor ima Content-Length, što čini TRACE odgovor delom HEAD tela, i kada se HEAD Content-Length završi, validan HTTP odgovor je smuggled): ``` HTTP/1.1 200 OK Content-Type: text/html @@ -745,16 +746,16 @@ Content-Length: 50 ``` -### Weaponizacija HTTP Request Smuggling pomoću HTTP Response Desynchronisation +### Oružavanje HTTP Request Smuggling pomoću HTTP Response Desynchronisation -Пронашли сте неку HTTP Request Smuggling ranjivost и не знате како да је exploit-ујете? Испробајте следеће методе exploitation: +Da li ste pronašli neku HTTP Request Smuggling ranjivost i ne znate kako da je iskoristite? Probajte ove druge metode eksploatacije: {{#ref}} ../http-response-smuggling-desync.md {{#endref}} -### Ostale HTTP Request Smuggling технике +### Druge HTTP Request Smuggling tehnike - Browser HTTP Request Smuggling (Client Side) @@ -774,7 +775,7 @@ request-smuggling-in-http-2-downgrades.md ### CL.TE -Из [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor) +Iz [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor) ```python def queueRequests(target, wordlists): @@ -859,14 +860,14 @@ table.add(req) ``` ## Alati -- HTTP Hacker (Burp BApp Store) – vizualizuje concatenation/framing i ponašanje HTTP-a na niskom nivou +- HTTP Hacker (Burp BApp Store) – vizualizuje concatenation/framing i ponašanje HTTP‑a na niskom nivou - https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?" - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling) - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler) - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py) - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler) - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz) -- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Ovaj alat je grammar-based HTTP Fuzzer koristan za pronalaženje neobičnih request smuggling neslaganja. +- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Ovaj alat je grammar-based HTTP Fuzzer, koristan za otkrivanje čudnih neslaganja u request smuggling‑u. ## Reference @@ -879,7 +880,7 @@ table.add(req) - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/) - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack) - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) -- Pažnja na false false‑positive: kako razlikovati HTTP pipelining od request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling) +- Pazite na lažno false‑positive: kako razlikovati HTTP pipelining od request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling) - [https://http1mustdie.com/](https://http1mustdie.com/) - Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks) - PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)