Moze da se imitira, nije problem. Problem je doci do njega, sto je vrlo tesko ako se koristi ssl/tls.
Pogledaj gde browser koji koristis skladisti privremene podatke, kod linux firefoxa je ~/.mozilla/firefox/ a u Windowsu u AppData folderu unutar korisnickog home foldera. Stikliraj opciju da vidis skrivene (hidden) fajlove i pronaci ces.

Naravno da moze. Zato stitis i sesiju, koristis csrf i jos neke stvari kada pravis aplikaciju.

Inace pre 6 7 godina je najjaca fora bila sesti sa snifferom u kafic... ne trebaju ti nicije sifre niti bilo sta drugo.

Ograniciti validnost sesije na IP adresu i User Agent string uz isticanje i obnavljanje i vecina sigurnosnih problema mogu biti reseni.

Ne. I jedno i drugo se usnifa sve zajedno ako nemas https konekciju. Jedino resenje za bezbednu sesiju je enkriptovana sesija. Ako je cookie session tipa onde bar traziti re-login (ako to ne omogucis nekako) kad se neko drugi okaci pre tebe....

Naravno, ako imas REST i nemas sesiju, prica se menja. :) Onda stitis token...

Ako neko zeli da hakuje i dovoljno je sposoban, bilo sta sem ssl/tls je nedovoljno, kad vec neko ima nameru da krade broj kreditne kartice i takve stvari.
Http user agent se lako moze da proizvoljno postavi, ip malo teze, ali i to moze recimo na linuxu, i ako os ne podrzava to direktno iz sigurnosnih razloga, kao windows, ne mozes racunati da je napadac nesposoban da to izprogramira od nule.

Enkripcija nece pomoci kod session hijacking napada, jer je sama enkripcija beznacajna kako se verbatim string iz cookie moze ukrasti.

Druga stvar XSS je veci problem nego MITM. Sto se tice laziranja IP adrese, to je nemoguce. Moze se prikriti uz proxy ali nikako promeniti na proizvoljnu vrednost.

U pravu si, moze da se posalje paket sa kastom hederom koji sadrzi laznu IP, ali nece moci da se rutira odgovor.

sta bi bio session hijacking napad? Mislim mogu da zamislim tako nesto, ali bez pristupa zrtvinom kompu tesko izvodljivo.

to ti je isto kao kad posaljes pismo sa laznom povratnom adresom :P

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:



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.

"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."

Za tako nesto ti treba da haknes server sto je jos teze. Ne verujem da JS moze kako hoce da skida fajlove sa diska...

Zašto bi morao da čita fajlove sa diska? Sa čijeg diska?

Korisnikov browser će cookies upisati u document.cookie.

Poenta je impersonirati korisnika na nekom sajtu, dakle, haker će kasnije sa prikupljenim podacima [automatski, verovatno] pristupiti tom sajtu pritom pružajući cookie sa session id koji je ukraden od korisnika.

Dakle, sa strane gledišta servera gde je sajt, haker je žrtva, jer imaju isti session id. Sa strane žrtve, sajt je zatražio da očita cookies i onda poslao na drugi domen, što je dozvoljeno*. Dakle, sve OK, a ovamo ti neko ukrade nalog.

* Jedini problem može da bude CORS, ali to je sa strane domena hakera, tj. zabrana slanja POST request-a drugom domenu. Haker može zaobići taj problem tako što će na svom serveru staviti header

Access-Control-Allow-Origin: *

Cekaj bre malo...

Ti na svoj server stavis javascript koji odradi {cookies: document.cookie}. To ti vrati sve cookies za domen ka kome ide request, sve ql. Kako ti CORS policy Allow Origin * pomaze? Nece ti, sta god ti stavio u CORS, browser poslati cookies za drugi domen....

edit: Jedino sto Bane kaze, ako to stavis na server kome hoces da ukrades login, ali ako mozes da stavis nesto na server, onda koj' ce ti djavo cookie od jednog usera. ;) Udji lepo u bazu, napravi sebi user sa kojim 'oces privilegijama....

Jaoj kao Kineski da pišem.

XSS omogući izvršavanje hakerovog JS koda na sajtu koji posećuje žrtva. Taj JS kod šalje cookies AJAX request-om na sajt koji kontroliše haker a koji je podešen da CORS omogući primanje tih cookies sa 3rd party domena.

Bukvalno jedan od najpopularnijih načina krađe kredencijala korisnicima na OWASP listi...

https://pentest-tools.com/blog/xss-attacks-practical-scenarios/

Ne. To sto on prica je AKO postoji bug na toj web aplikaciji takav da taj kod vrati u okviru html-a a pri tome ne escape-uje. No, to je suvise specifican slucaj za ovu pricu.

Pa ok, sad kapiram ali sto kaze @Shadowed to znaci da imas bug koji ti omoguci XSS.

Napraviste celu filozofiju oko obične sesije. :)

Pa dobro, o sigurnosti sajta treba pripaziti.

Proveri da li ti cuva HttpOnly cookies. Oni ne mogu da se procitaju javascriptom. To bi trebalo da resi skoro sve XSS napade (ako slucajno napravis propust u kodu).
Ako koristis neki framework, oni obicno koriste "signed cookies". Tako da je tesko da neko nasumicno pogodi, mora i da ga sifruje da bi ga server prihvatio.

@Deunan

Ekstra! Ja sam bukvalno skroz zaboravio za HttpOnly. Bonus je i Secure flag, onda će biti dostupni samo serveru i samo na https:// :) Dobijaš +1 internet cookie :P

BTW, što se tiče tih propusta sa XSS, ima ih dosta, neki link je na svom sajtu (mikicaivosevic.info) napisao par komada, npr.

http://mikicaivosevic.info/201...agrada-od-5000---hall-of-fame/ (google.com, doduše Google ima HttpOnly i Secure odavno, ali eto moglo je drugačije štete biti)
https://mikicaivosevic.info/20...do---multiple-vulnerabilities/
http://mikicaivosevic.info/201...-od-1000-dinara-od-donesi.com/
http://mikicaivosevic.info/201...rs---cross-site-scripting-xss/
http://mikicaivosevic.info/201...-multiple-xss-vulnerabilities/
http://mikicaivosevic.info/2018/04/prva-srpska-televizija---xss/
https://mikicaivosevic.info/20...-multiple-xss-vulnerabilities/ (ebay.com)

Proverio sam, ima ga na Google Hall of Fame i eBay Hall of Fame, ovi domaći sajtovi su raspad i to nemaju.

Svejedno, XSS propusti su veoma rasprostranjeni po sajtovima i aplikacijama, i zbog toga se treba zaštititi.

Scenario koji sam ja opisao nije uopšte nemoguć, zapravo se takve stvari redovno dešavaju.

Zaštita je jednostavna -- kao što je Deunan rekao, HttpOnly i Secure.