PHP fórum

danaketh · 6. 1. 2009 16:56

Zdravím,

stále častěji na webu narážím na hlášku „Pro přihlášení musíte mít povolené koláčky“. Právě přepisuji autorizační knihovnu kterou používám ve svém rádobyframeworku a rád bych vyřešil otázku přihlašování co nejbezpečněji. Proto bych se rád zeptal jakým způsobem řešit přihlašování a ověřování přihlášeného uživatele. Dosud jsem používal buď $_SESSION, do které jsem si uložil potřebné informace a pak ověřoval její existenci nebo jsem webové rozhraní uzavřel do chráněného adresáře.

V souvislosti s výše zmíněnou větou o koláčcích usuzuji, že lepší/bezpečnější je používat právě koláčky ale než něco takového implementuji, tak si raději nechám poradit jak se k tomu postavit, na co si dávat pozor atd.

Díky za odpověď :)

Martin Mates · 6. 1. 2009 17:31

K tomu, aby fungovaly SESSION je zapotřebí, aby měl uživatel povolené COOKIES (pokud tedy nechceš session id posílat v adrese, což je, pokud vím, považováno za bezpečnostní díru). Takže proto to nejspíš mají všude napsáno.

Jinak, jak pracovat se SESSION přihlášeného uživatele co nejbezpečněji bych nechal na někom zkušenějším. Řeším to běžně asi podobně jako ty. Teď jsem začal používat Nette framework a ten to má celé ošetřené, doporučuju (http://nette.org/…uthenticator)

srigi · 7. 1. 2009 0:01

Odporucam jednoducho povolene COKKIEs vyzadovat (dnes to ma zakazane iba malokto, napr. Věra Pohlová :D ). Prenasat PHPSESSID v URL vobec neodporucam.

Pre zlepsenie bezpecnosti je vhodne PHPSESSID vdzy nanovo vygenerovat pomocou fnce session_regenerate_id(), hned po volani session_start(). Zabrani sa tak utoku nazvanemu session fixation.

Editoval srigi (7. 1. 2009 0:02)

danaketh · 7. 1. 2009 1:28

PHPSESSID v URL považuju za prasárnu od prvních krůčků v PHP :) Nějak mi ale uniklo, že session bez koláčků ne-e. Díky za tip se session_regenerate_id(), hned jsem to připsal.

Martin: mrknu se na to. Nette se mi tu povaluje ku testování a budoucímu využití na jednom rozměrnějším projektu.

Tomik · 7. 1. 2009 16:36

Nette se o toto (pokud si to člověk nepředefinuje) stará samo. A stará se o to dobře – nemusíš se tedy bát o bezpečnost svých aplikací. Takže doporučuju! :)

Jinak rozdíl mezi SESSIONS a COOKIES je ten, že SESSIONS jsou už od začátku (a automaticky) zahashovaná, a ukládají se na straně serveru, zatímco COOKIES se ukládají na straně klienta, při vyžádání SESSIONS server vydá PHPku daný soubor dat pouze pokud je v COOKIES uvedena stejná hodnota, pod kterou byla daná hodnota uložena, pokud ne, je uživatel odhlášen.

COOKIES vydá PHPku klient (tedy prohlížeč) v podstatě komukoli ze stejné domény, tzn. jedná se o mnohem větší bezpečnostní riziko.

Warden · 7. 1. 2009 19:33

Doporučuji nastudovat něco o session hijacking – něco na blogu Jana Tichého dále na blogu Jakuba Vrány případně strejda Google :)

Kevujin · 8. 1. 2009 0:20

Tomik napsal(a):

Nette se o toto (pokud si to člověk nepředefinuje) stará samo. A stará se o to dobře – nemusíš se tedy bát o bezpečnost svých aplikací. Takže doporučuju! :)

Jinak rozdíl mezi SESSIONS a COOKIES je ten, že SESSIONS jsou už od začátku (a automaticky) zahashovaná, a ukládají se na straně serveru, zatímco COOKIES se ukládají na straně klienta, při vyžádání SESSIONS server vydá PHPku daný soubor dat pouze pokud je v COOKIES uvedena stejná hodnota, pod kterou byla daná hodnota uložena, pokud ne, je uživatel odhlášen.

COOKIES vydá PHPku klient (tedy prohlížeč) v podstatě komukoli ze stejné domény, tzn. jedná se o mnohem větší bezpečnostní riziko.

no chlape, myslím, že jsi to popsal dost nešťastně. raději jsi měl napsat, že session se identifikuje pomocí cookie, která obsahuje název session a její hodnotu (onen hash). ten se pak na serveru spáruje s existující session (pokud existuje) a tím se do aplikace dostanou data v oné session. takže session se ukládají nejen na straně serveru, ale její identifikátor i na straně klienta. to s tím odhlášením taky není pravda, záleží na programátorovi aplikace, co s tím provede.

jo cookies rozhodně nevydá někdo jen tak někomu a ani na stejné doméně (parametr path v setcookie). a pak taky ještě existujou další formy cookies (implementovaný prohlížečem) jako např. http only cookie atp. ale tohle už záleží, jak má prohlížeč nastaven. klidně může veškerej obsah cookies někam posílat (google sběrna atp.).

romansklenar · 8. 1. 2009 1:45

Sessions a cookies jsou ty místa ve webových aplikacích, které dělají začátečníkům problémy, případně nechávají bezpečnostní díry při špatném používání. Je dobré si práci s nima si nějak zastřešit a zautomatizovat.

Nette\Web\Session ji právě hezky zapouzdřuje a zjednodušuje na maximum, krásně to ukazuje práce například s nastavením expirace.

Práce s uživateli, autorizace a autentizace je pak hodně podobná – rozumněj stejně jednoduchá :-) jelikož využívá té práce se session.

Minimálně jako inspirace ti to může pomoct, ale není nad to si Nette vyzkoušet ;-) a protože se na to rychle zvyká, tak se ti už třeba nebude chtít zpět k čistému phpčku jako mě – každý přechod zpět velmi těžce psychicky nesu a moji práci doprovázejí nespisovná slova :(

EDIT: Co jsem chtěl ale zmínit a na co jsem zapomněl je, že samotné bezpečné naprogramování nemusí nutně znamenat, že je vše v bezpečí.

Editoval romansklenar (8. 1. 2009 2:12)

Tomik · 8. 1. 2009 18:58

Kevujin napsal(a):

no chlape, myslím, že jsi to popsal dost nešťastně. raději jsi měl napsat, že session se identifikuje pomocí cookie, která obsahuje název session a její hodnotu (onen hash). ten se pak na serveru spáruje s existující session (pokud existuje) a tím se do aplikace dostanou data v oné session. takže session se ukládají nejen na straně serveru, ale její identifikátor i na straně klienta. to s tím odhlášením taky není pravda, záleží na programátorovi aplikace, co s tím provede.

jo cookies rozhodně nevydá někdo jen tak někomu a ani na stejné doméně (parametr path v setcookie). a pak taky ještě existujou další formy cookies (implementovaný prohlížečem) jako např. http only cookie atp. ale tohle už záleží, jak má prohlížeč nastaven. klidně může veškerej obsah cookies někam posílat (google sběrna atp.).

Ano, máš pravdu. Nešťastně jsem to formuloval.

PHP fórum

#1 6. 1. 2009 16:56

Bezpčené přihlášení a držení uživatelské session

#2 6. 1. 2009 17:31

Re: Bezpčené přihlášení a držení uživatelské session

#3 7. 1. 2009 0:01

Re: Bezpčené přihlášení a držení uživatelské session

#4 7. 1. 2009 1:28

Re: Bezpčené přihlášení a držení uživatelské session

#5 7. 1. 2009 16:36

Re: Bezpčené přihlášení a držení uživatelské session

#6 7. 1. 2009 19:33

Re: Bezpčené přihlášení a držení uživatelské session

#7 8. 1. 2009 0:20

Re: Bezpčené přihlášení a držení uživatelské session

#8 8. 1. 2009 1:45

Re: Bezpčené přihlášení a držení uživatelské session

#9 8. 1. 2009 18:58

Re: Bezpčené přihlášení a držení uživatelské session

Zápatí