08. 11. 2006. | #41 |
Domagoj Horvat
Expert
|
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
------- 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?
__________________
postoje ludosti bez kojih je nemoguce ljudsko dostojanstvo |
09. 11. 2006. | #42 |
Direktor Kombinata
Invented the damn thing
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
|
^ 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
__________________
activeCollab - Project Management and Collaboration Tool iz domaće kuhinje | area51.rs - Blog Poslednja izmena od Ilija Studen : 09. 11. 2006. u 00:29. |
09. 11. 2006. | #43 | |
Domagoj Horvat
Expert
|
Citat:
__________________
postoje ludosti bez kojih je nemoguce ljudsko dostojanstvo |
|
09. 11. 2006. | #44 | |
Direktor Kombinata
Invented the damn thing
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
|
Citat:
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)
__________________
activeCollab - Project Management and Collaboration Tool iz domaće kuhinje | area51.rs - Blog |
|
09. 11. 2006. | #45 |
Predrag Supurović
Grand Master
Datum učlanjenja: 24.01.2006
Lokacija: Užice
Poruke: 791
Hvala: 3
200 "Hvala" u 12 poruka
|
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.
__________________
Peđina beležnica (blog) - www.uzice.net - wireless.uzice.net - www.vokabular.org - www.vodic.net - forum.uzice.net |
09. 11. 2006. | #46 | |
Direktor Kombinata
Invented the damn thing
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
|
Off Topic: Citat:
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
__________________
activeCollab - Project Management and Collaboration Tool iz domaće kuhinje | area51.rs - Blog |
|
09. 11. 2006. | #47 |
Predrag Supurović
Grand Master
Datum učlanjenja: 24.01.2006
Lokacija: Užice
Poruke: 791
Hvala: 3
200 "Hvala" u 12 poruka
|
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.
__________________
Peđina beležnica (blog) - www.uzice.net - wireless.uzice.net - www.vokabular.org - www.vodic.net - forum.uzice.net |
09. 11. 2006. | #48 |
Knowledge base
Wrote a book
Datum učlanjenja: 16.06.2005
Lokacija: Novi Sad
Poruke: 1.437
Hvala: 37
131 "Hvala" u 82 poruka
|
^ 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).
__________________
Năo quero mais seguir um só caminho |
09. 11. 2006. | #49 | |
Ivan Dilber
Sir Write-a-Lot
|
Off Topic: Citat:
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..
__________________
Leadership is the art of getting people to want to do what you know must be done. |
|
09. 11. 2006. | #50 | |
Goran Pilipović
Sir Write-a-Lot
|
Citat:
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?
__________________
Goran Pilipović a.k.a. Ugly Fingers Bradley f.k.a. bluesman I don't always know what I'm talking about but I know I'm right! |
|
|
|
Slične teme | ||||
Tema | Početna poruka teme | Forum | Odgovori | Poslednja poruka |
Pokusaj hakovanja ili... | mLAN | Sva početnička pitanja | 3 | 06. 12. 2010. 00:41 |
zaštita fotografija na web-u | japan | Web aplikacije, web servisi i software | 6 | 14. 12. 2007. 19:16 |
Zaštita od DDoS napada | LiquidBrain | Web Hosting, web serveri i operativni sistemi | 16 | 05. 08. 2007. 20:52 |