DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   Zaštita od hakovanja (http://www.devprotalk.com/showthread.php?t=1779)

dee 08. 11. 2006. 21:58

Samo vas gledam i razmišljam da li da vam predočim svoje poglede i tehnike vezane uz temu, ali uzimajući u obzir vaše iskustvo, obrazovanje i inteligenciju, prilično sam siguran da vi to ne bi mogli razumjeti :D

-------

alzo...

kad smo vec kod hakovanja... da ne otvaram novi topic. kako rjesavate login sistem? mislim cisto nacelno kao ideju? ono sta sam ja do sad koristio je otprilike:

- korisnik unosi usr/pass (filter podataka)
- kreira se session sa custom IDjem
- taj ID se sprema u cookie
- pri ponovnom dolasku, provjerava se
a) ima li covjek cookie? (ako nema -> login.php)
b) ako ima, pokreni session ciji ID je zapisan u cookie
c) ako ima i cookie i postoji taj sessID -> dozvoli pristup, else -> login.php

i cookie lifetime stavim na 15 minuta.

po literaturi o sigurnosti nailazio sam i na prijedloge da se pri svakom requestu provjerava User-Agent jer je malo vjerojatno da ga covjek mijenja pri aktivnosti na stranici, a ako ga je vec promijenio, nece zamjerit ponovni login. tako da mi se to cini ko dobra usputna provjera (nisam koristio).

sta se jos koristi i kako?

Ilija Studen 08. 11. 2006. 23:26

^ Cookie lifetime ti je prekratak. U tom slučaju slobodno možeš da koristiš i sesije jer im je trajanje duže od navedenog lifetime (ali nije trajno).

Cookie bi trebalo da koristiš kada ti sesije ne rade posao (traju prektratko, recimo kod webmaila gde korisnici cepaju jedan email dosta dugo) ili gde jednostavno hoćeš da obezbediš remember me funkcionalnost (remember me for 14 days ili remember me forever).

Jedan od meni poznatih problema sa čuvanje SID-a u cookieju je što isti podaci mogu lako da budu pročitani ako ti skripta ima neke druge propuste, XSS pre svega (recimo, JS ima mogućnost da pročita vrednosti cookie-a i ako ti neko ubaci maliciozan JS taj kod može da pošalje vrednosti unutar cookie-a napadaču). Tu bi fazon sa proverom user agenta odradio posao ako ga malo "posoliš" (dodaš mu neki prefix ili sufix znan samo skripti koji ne može da se pročita iz JS-a).

Ima tu peripetija... Recimo, problem je što će korisnik biti izlogovan ako recimo upgraduje browser.

Pogledaj linkove ovde. Pokriveno je dosta situacija povezanih sa logovanjem korisnika i sesijama koje su potencijalne rupe, a nisu odmah očigledne. Dovitljivi su hakerani, teško im je stati na rep :D

dee 09. 11. 2006. 00:02

Citat:

Originalno napisao Ilija Studen
Cookie bi trebalo da koristiš kada ti sesije ne rade posao (traju prektratko, recimo kod webmaila gde korisnici cepaju jedan email dosta dugo) ili gde jednostavno hoćeš da obezbediš remember me funkcionalnost (remember me for 14 days ili remember me forever).

ovo bi filtriranje ulaznih podataka trebalo rijesiti, zar ne? recimo prosto htmlspecialchars() i htmlentities()?

Ilija Studen 09. 11. 2006. 00:13

Citat:

Originalno napisao dee
ovo bi filtriranje ulaznih podataka trebalo rijesiti, zar ne? recimo prosto htmlspecialchars() i htmlentities()?

Možeš odmah pri inputu da escapeuješ, a možeš i prilikom prikazivanja. Preferiram ovo drugo jer volim da imam originalne podatke u bazi.

Primer, ja na activeCollab želim da dozovolim da ljudi postoju JavaScript kod (recimo, dva developera diskutuju o nekoj JS funkciji u messages sekciji). Ono što ne smem da dozvolim je da to bude renderovano kao JS i intepretirano već kao klasičan output. Zato escapeuješ content...

clean() funkcija mi do sada nije pravila problema. Za razliku od čiste htmlspecialchars() ona se ne gubi sa kodiranim UTF-om. Preuzeto iz punBB-a (doduše, tamo se drugačije zove) :)

Pedja 09. 11. 2006. 08:40

Samo jedna kratka poaska na temu INI-ja: ne volim d aih korsitim u PHP zato sto je to neuobicajen tip dokument za web serer i po pravilu znaci da moram da podesavam server da ne prikazuje INI korisniku. Ja sve drzim kao PHP (cak i sablone) jer sam tako siguran da sadrzaj koji predstavlja kod nece biti prikazan korisnisku.

Osnovni princip koga se drzim kada pisem skript, to je da on ne trazi neka specijalna podesavanja servera. Razlog je ocigledan: nikad ne znam na kom serveru ce taj skript da se vrti i da li ce taj server moci da se prilagodjava.

Zbog toga i konfiguraciju drzim u PHP i to upravo kao niz. Niz ima i jos jednu lepu prednost: ima hijerarhijsku strukturu za razliku od INI-a koji ima samo dve dimenzije.

Sto se tice logina, nikada mi nije bas sasvim bilo jasno zasto login sistemi nude koridniku opciju da ga automatski uloguju. Meni se to cini kao poprilican rizik, a kao opcija mi se cini nepotrebno, jer svaki veb citac ima opciju da to sam uradi, i to jos da podatke cuva u kriptovanom obliku, ne u kolacicu, na mestu koje je hakerima mnogo nedostupnije.

Ilija Studen 09. 11. 2006. 10:56

Off Topic:
Citat:

Originalno napisao Pedja
Sto se tice logina, nikada mi nije bas sasvim bilo jasno zasto login sistemi nude koridniku opciju da ga automatski uloguju. Meni se to cini kao poprilican rizik, a kao opcija mi se cini nepotrebno, jer svaki veb citac ima opciju da to sam uradi, i to jos da podatke cuva u kriptovanom obliku, ne u kolacicu, na mestu koje je hakerima mnogo nedostupnije.

Browseri imaju mogućnost da popune polja login forme, ne i da automatski uloguju korisnika (ili grešim???). Ovo je jako bitna opcija za stvari koje korisnici jako mnogo koriste (forumi) i gde mnogo pišu. Bar malo olakšaš ljudima život, cene to ;)

Recimo, imaš situaciju gde čovek 2h piše specifikaciju ili neki timeline - nakon submita skripta skonta da je sesija istekla i da ovaj treba da se uloguje. U tim slituacija će imati ili frustriranog korisnika koji će da ti okrene familiju po spisku jer mu je propalo dva sata posla (nisi mu sačuvao podatke) ili moraš da obezbediš mehanizam za resubmitovanje forme (podaci se pamte zajedno sa login podacima i nakon uspešnog logovanja ponovo submituju). Doduše, ovu drugu funkcionalnost je dobro imati za korisnike koji nisu čekirali Remember me pri loginu tako da će opet izgubiti rad nakon par sati idleovanja...

Najjednostavnije rešenje je održavanje sesije tako što je pamtiš u cookie-ju na više od session lifetimea. Klasičan remember me pamti na par dana, meseci ili beskonacno, ali možeš da koristiš recimo čuvanje na 5 sati čisto da bi se ogradio od slučajeva kao što je gore (retko će se desiti da neko submituje formu 5 sati nakon poslednje aktivnosti na sistemu).

Duga priča :( :1075:

Pedja 09. 11. 2006. 14:55

Off Topic:

Citac zapamti user i pass tako da korisniku ostaje samo da klikne na login. To je cak i prakticno jer mnogi forum i kada se izlogujes resetuju pokazivace na procitane poruke pa ako samo na brzaka zelis da udjes na forum da nesto pogledas a on te autologuje onda moras da pregledas sve neprocitane poruke jer ti je to jedina sansa da ih vidis kao neprocitane.

Meni se to redovno desava sa ES-om, jer mi je kod njega ukljucen autologin i svaki put kada trazeci nesto na Google otvorim ES link, ugrizem se za kaziprst, jer onda moram da proverim poruke (posto sam moderator, moram da o tome vodim racuna)

Ako nisi autologovan uvek imas mogucnost da izbegnes login i samo bacis pogled na forum.

Takodje je veliki problem ako pises poruku pa oduzis i forum te izloguje sto ce autologin da odradi stvar a ti to neces ni primetiti, i opet imas isti problem - izgubljeni su pokazivaci na neprocitane poruke ali ovaj put ti to i ne znas jer nisi ni primetio da si bio izlogovan.


MorenoArdohain 09. 11. 2006. 15:06

^ Mislim da je onda greska do lose napisanog softvera, jer bi pokazivaci na neprocitane poruke trebale da se oslanjaju ne na vreme logina, vec na flag za svaku poruku, za tog usera, tj tebe (procitano/neprocitano).

ivanhoe 09. 11. 2006. 15:18

Off Topic:
Citat:

Originalno napisao Ilija Studen
Recimo, imaš situaciju gde čovek 2h piše specifikaciju ili neki timeline - nakon submita skripta skonta da je sesija istekla i da ovaj treba da se uloguje.

ovaj problem se elegantno resava ajaxom...samo osvezis sesiju svakih 15-20 minuta tako sto cimnes neku skriptu na serveru.. ne mora naravno XMLHttpRequest da se koristi, moze obicna slika kojoj se setuje novi src sa setTimeout...



takodje za login je odlicna ideja da se generise novi session id kod svakog pristupa, pri cemu se pazi da jedan korisnik ne moze da ima 2 sesije otvorene istovremeno... napadac mora da uzme friski SID i da ga iskoristi pre korisnika da bi mogao da pristupi sajtu, ali onda korisnik dobije login formu i nakon sto se uloguje, napadac je opet izlogovan..

sto se provere user-agenta tice, meni se to cini kao nepotreban trud...onaj ko moze da mazne SID, moze i da pogleda koji je user-agent u pitanju, a ionako ljudi masovno koriste IE pa nije tesko cak i pogoditi.. daleko korisnije bi bilo kad bi mogla da se proverava IP adresa, jer tu nema prevare...ali to je diskutabilno zbog ljudi/firmi koje koriste farme proxija, pa im se ip menja..

bluesman 09. 11. 2006. 16:08

Citat:

Originalno napisao Ilija Studen
Off Topic:

Browseri imaju mogućnost da popune polja login forme, ne i da automatski uloguju korisnika (ili grešim???). Ovo je jako bitna opcija za stvari koje korisnici jako mnogo koriste (forumi) i gde mnogo pišu. Bar malo olakšaš ljudima život, cene to ;)

Recimo, imaš situaciju gde čovek 2h piše specifikaciju ili neki timeline - nakon submita skripta skonta da je sesija istekla i da ovaj treba da se uloguje. U tim slituacija će imati ili frustriranog korisnika koji će da ti okrene familiju po spisku jer mu je propalo dva sata posla (nisi mu sačuvao podatke) ili moraš da obezbediš mehanizam za resubmitovanje forme (podaci se pamte zajedno sa login podacima i nakon uspešnog logovanja ponovo submituju). Doduše, ovu drugu funkcionalnost je dobro imati za korisnike koji nisu čekirali Remember me pri loginu tako da će opet izgubiti rad nakon par sati idleovanja...

Najjednostavnije rešenje je održavanje sesije tako što je pamtiš u cookie-ju na više od session lifetimea. Klasičan remember me pamti na par dana, meseci ili beskonacno, ali možeš da koristiš recimo čuvanje na 5 sati čisto da bi se ogradio od slučajeva kao što je gore (retko će se desiti da neko submituje formu 5 sati nakon poslednje aktivnosti na sistemu).

Duga priča :( :1075:

Ne znam zašto ovoliki offtopic, ali aj'... Ja sam to rešio tako što ako mu je istekla sesija (možda neko drži jednu stranu otvorenu ceo dan... pa nastavi "kasnije") onda mu izbacim opet sve što je napisao uz komentar tipa: istekla vam je sesija, morate ponovo da se ulogujte, ovo je tekst koji ste napisali, kopirajte ga da ne bi morali da pišete ponovo. To pali čak su mi neki ljudi sa sajta pisali da im je to "spasilo život" jer bi se roknuli da su morali ponovo da pišu sve.

Kada sam proverio kako je došlo do toga, kaže da je počeo da piše odgovor pa je seo da večera, odgledao film i nastavio 3 sata kasnije, dovršio (ogromnu) poruku i kliknuo "send". Zašto bi on i morao da zna da mu sesija traje 1 sat ili 15 minuta....

Drugo rešenje koje sam koristio, ali se nije pokazalo kao sjajno iako na prvo pogled tako izgleda, je da ubaciš neki brojač na stranu i recimo posle 15 minuta ispiše nešto tipa: vaša sesija će isteći za 5 minuta, refreshujte stranu ili ćete morati ponovo da se ulogujete. Naravno, problem je bio što kada čovek nije ispred računara, kao recimo onaj gore što je odgledao film, ne može ni da vidi takvu poruku pa da reaguje.

Eto,... šta sam ono hteo da kažem? :)


Vreme je GMT +2. Trenutno vreme je 00:04.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.