[es] - kontrola pristupa skripti

peromalosutra
Ivan Rajkovic
Software engineer
Luxoft
Berlin

Član broj: 54774
Poruke: 876
*.teol.net.

+148 Profil

^{12.07.2007. u 21:27 - pre 204 meseci}

Pravim skriptu koja ce da sluzi kao administratorski panel. Kroz nju ce biti moguce odrzavanje mysql baze tipa brisanje odredjenih unosa iz baze ili brisanje cijele tabele (u sustini nebitno). Poenta je da ne zelim da bas svako ima pristup tom panelu.

Ja sam rjesio ovaj problem na sledeci nacin: Kada korisnik klikne na link za admin panel prvo se otvori skripta admin_login.php koja trazi da se unese sifra i provjerava da li je unesena sifra ispravna. Prava sifra se nalazi u obicnoj php varijabli tipa $sifra="neka_sifra". Ako sifra nije ispravna, skripta izbacuje gresku i trazi da se ona ponovo unese, a ukoliko jeste skripta pravi cookie koji traje odredjeno vrijeme (par minuta) i preusmjerava korisnika (preko header f-je) na skriptu admin_panel.php. Skriptu za admin_panel nisam do kraja dovrsio, ali zamislio sam da na svaki zahtjev korisnika skripta provjerava da li on ima odgovarajuci cookie koji nije istekao i tek onda mu dopusti odredjenu akciju, inace ga opet sa header f-jom preusmjerava na skriptu admin_login...

Sad me zanima koliko je ovaj nacin pouzdan, pogotovo sto se tice cuvanja sifre u obliku php varijable. Ne trazim neku top sigurnost, ali ne zelim ni da bude previse naivno.. Pa zato pitam: da li ovaj nacin gore valja, ako ne valja zasto i kako biste vi rjesili taj problem?

Poz.

Odgovor na temu

VladaSu

Član broj: 31634
Poruke: 1099
77.46.159.*

+218 Profil

Re: kontrola pristupa skripti

^{12.07.2007. u 22:48 - pre 204 meseci}

U tabeli "korisnici" napravi novu kolonu i stavi neki ranom parametar svaki put kada se loguje.
U cookie pamti id korisnika i ovaj parametar.

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
91.150.127.*

+11 Profil

Re: kontrola pristupa skripti

^{12.07.2007. u 22:56 - pre 204 meseci}

Ako to pamtis u cookie, korisnik lako moze da iznemi njegov sadrzaj i tako neograniceno korsiti pristup, a da ne pricamo o toem da neko moze podesavanjem tog cookiea da dobije pristup cak i ako ne zna lozinku.

Koristi sesije, imas ovde na forumu bar dve teme koje su se time bavile.

Odgovor na temu

VladaSu

Član broj: 31634
Poruke: 1099
77.46.159.*

+218 Profil

Re: kontrola pristupa skripti

^{12.07.2007. u 22:59 - pre 204 meseci}

A sta je cookie a sta sesija?
I sesija se pamti u cookie-ju, pa opet neko na isti nacin moze da te zezne.

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

Odgovor na temu

mb_sa

Član broj: 50529
Poruke: 172
89.146.172.*

Profil

Re: kontrola pristupa skripti

^{13.07.2007. u 07:44 - pre 204 meseci}

Citat:

VladaSu: A sta je cookie a sta sesija?
I sesija se pamti u cookie-ju, pa opet neko na isti nacin moze da te zezne.

Ko reče da se sesija morati cuvati u cookie-u? :D

@peromalosutra,
sigurnije ti je korstiti sesije, u biti logika je jako slicna onom sto si napisao, samo sto korists sesije. Imas na ovu temu milion tutoriala i slicno!

Ako te brine sto je sifra u varijbali, u biti ne predstavlja neki sigurnosi propust, jedino bi bilo pametno da sifru cuvas u kriptiranom obliku (md5() ili sha1())

I onda kada korsinik unese sifru, kriptiras je i provjeras sa vec kriptiranom sifrom!

Ako ti se server vrti na linuxu, razmisli o .httaccess zastiti foldera, pa samim tim i ctave administracije!

Odgovor na temu

VladaSu

Član broj: 31634
Poruke: 1099
*.tippnet.co.yu.

+218 Profil

Re: kontrola pristupa skripti

^{13.07.2007. u 10:27 - pre 204 meseci}

Pa onda bi siftu pamtio u URL pa opet neko moze da vidi kao i u kukiju.
Poenta je kriptovati i pamtiti u bazi kriptovanu, a ostalo je manje bitno.
I ES pamti u kukiju. :)

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

Odgovor na temu

bzero
dev null
europe

Član broj: 5907
Poruke: 371
*.dynamic.sbb.co.yu.

Jabber: bzero@elitesecurity.org
Sajt: www.google.com/search?q=b..

Profil

Re: kontrola pristupa skripti

^{13.07.2007. u 10:35 - pre 204 meseci}

Citat:

VladaSu: A sta je cookie a sta sesija?
I sesija se pamti u cookie-ju, pa opet neko na isti nacin moze da te zezne.

Ne pamti se sesija u kukiju nego ID sesije. Podaci vezani za sesiju se cuvaju na serveru.

Never trust an operating system you don't have sources for.

Odgovor na temu

mb_sa

Član broj: 50529
Poruke: 172
*.PPPoE-6673.sa.bih.net.ba.

Profil

Re: kontrola pristupa skripti

^{13.07.2007. u 13:40 - pre 204 meseci}

Citat:

VladaSu: Pa onda bi siftu pamtio u URL pa opet neko moze da vidi kao i u kukiju.

Samo da ukazem da ovo nije tacno, tj. obavezujuce rješenje ... ;)

Kao sto rece bzero, podaci o sesiji se cuvaju u folder na serveru ili u bazi (ako tako isprogramiras)!

Pozdrav.

Odgovor na temu

VladaSu

Član broj: 31634
Poruke: 1099
77.46.156.*

+218 Profil

Re: kontrola pristupa skripti

^{15.07.2007. u 14:58 - pre 204 meseci}

Nisam bio dovoljno precizan sa recima pa sam napravio malu pometnju...

Dobro, mislim ne aj dobro nego i jeste. Podaci o sesiji mogu da se pamte u folderu na serveru,
ali koliko znam mora se negde cuvati odnosno prenositi ID sesije.

Evo iz knjige Prof. Jim Whitehead - PHP Session Management

Problems with Cookies
• Problems with Cookies
– Browsers can refuse to accept cookies.
– Additionally, it adds network overhead to
send lots of information back and forth.
– There are also limits to the amount of
information that can be sent
– Some information you just don’t want to save
on the client’s computer.

Security of Session Data

• In general, cannot guarantee that session data will
remain private
• Often, the session data files can be read by any web
application on the same server
• The session ID can be grabbed by looking at the GET
parameters (for GET-based passing of the session ID),
or by eavesdropping the on-the-wire protocol (to get the
cookie with the session ID)
– If the session holds a password, someone can then “replay” the
session ID back to the server
• Cookie data, though stored on the client side, are sent
across the wire in-the-clear
– Client machines might be compromised, such as by malicious
software inadvertently downloaded, or by a virus

Mislim da nema svrhe nesto preterano cimati se oko ovakvih pitanja kada postoje druga resenja sto se tice sigurnosti,
ali ovde koliko vidim nije potreban taj nivo sigurost.
Tako da je svejedno sta ce se koristiti. ili mozda gresim?
Iskreno, ni meni ovaj deo nikada nije do kraja razjasnjen jer nisam nikada probao provaliti nesto, sesiju ili kuki.

Znam da se obe stvari mogu provaliti (sve se moze provaliti) samo je pitanje sta lakse i brze.

Nije mi cilj da se prepucavam ovde nego bih hteo necije strucno misljenje sa obrazlozenjem.
Sta je bolje cookie ili sesija za ovakav slucaj?
Ili mozda bolje da otvrama novu temu?
Moje misljenje je da je svejedno sto se tice sigurnosti, presudne su neke druge stvari.
Daaaaa, a kome je stalo da moga misljenja?:)

_{[Ovu poruku je menjao VladaSu dana 15.07.2007. u 17:05 GMT+1]}

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

Odgovor na temu

beep
Srbija/Vrbas

Član broj: 19294
Poruke: 198
*.adsl-1.sezampro.yu.

Sajt: keselj.xyz

+1 Profil

Re: kontrola pristupa skripti

^{15.07.2007. u 16:10 - pre 204 meseci}

Kad ti se korisnik registruje zasto bi cuvo njegovu sifru?

Odgovor na temu

VladaSu

Član broj: 31634
Poruke: 1099
77.46.156.*

+218 Profil

Re: kontrola pristupa skripti

^{15.07.2007. u 16:32 - pre 204 meseci}

Ma ne pamti se sifra, nego id i random parametar.

Sada ovo ispade kao neko forum prepucavanje, ali nije:)

Ova tema mi je bas zanimljiva jer nije mi u glavi bas sroz kristalno cisto sto se tice sesije i kukija, a nisam se pretrao ni trudio.

Citat:

broker: Ako to pamtis u cookie, korisnik lako moze da iznemi njegov sadrzaj i tako neograniceno korsiti pristup, a da ne pricamo o toem da neko moze podesavanjem tog cookiea da dobije pristup cak i ako ne zna lozinku.

Koristi sesije, imas ovde na forumu bar dve teme koje su se time bavile.

Kako neko podesavanjem tog kukija moze da dobije pristup?
Iskreno, bas me zanima, ne pada mi na pamet kako to moze lakse da se odradi u odnosu na sesiju.
Kazi mi kod sesije ovako kod kukija ovako, za , protiv..

Pa ako imas id korisnika i neki random parametar koji se menja svaki put kada se korisnik loguje onda teze moze da se provali. Samo malo teze.
I u ovom slucaju ostali podaci bi se pamtili na serveru,a mozes da prenosis i preko URL-a ova dva parametra, ili opet ova dva paramtera spojena u jedan..
E sada kada imas sesiju onda opet barem nesto treba da ide preko URL-a ili kukuja. Opet neki random parametra...
Kakva je tu razlika?

Kada radis preko kukija onda taj isit korisnik moze da se automatski loguje i sutra kada ukljuci racunar.
Kada radis preko sesije onda mozes da pamtis vise dodatnih podataka koji ti trenutno trebaju, mada to mozes i u kukiju ali si ogranicen velicinom fajla
+ ne moras te dodatne podatke da prenosis Client-Server kao kod kukija.

Kako su ovaj problem resili mnogo veci od nas, Google i Yahoo?
Vidi kako se oni resili i misim da se ne treba pitat zasto su to tako resili.

Oni manje brinu za sigurnost korisnika?

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

Odgovor na temu