Mechanizm logowania-sesja.

[Tomahawk]

Witam!

Piszę ostatnio mechanizm logowania do mojego systemu i mam tutaj mały problem.

Otóż ta aplikacja którą piszę jest bardziej rozbudowana niż inne. W prostszych zawsze do logowania stosowałem surowe session z php.

Teraz dużo się mówi o tym że session jest dziurawe i że warto napisać własny mechanizm sesji.

Widziałem w necie dziesiątki mechanizmów sesji i każdy miał wiele zalet i wad a niektóre same zalety ale miałem wrażenie że każdy realizuje zupełnie coś innego.

Wiem jak dzieła sesja wbudowana w php ale nie wiem jak powinien działać własny mechanizm sesji. Chce sobie to przybliżyć jak to działa. Nie interesuje mnie kod tylko schemat. Co się skąd bierze, gdzie jest i poco przesyłane itd.

No cóż z góry wielkie dzięki.

[Mion]

Chce sobie to przybliżyć jak to działa. Nie interesuje mnie kod tylko schemat. [...]No cóż z góry wielkie dzięki.

php własny mechanizm sesji

[Tomahawk]

Ale nie rozumiem jednej rzeczy. Po co te dane trzymać w bazie danych i męczyć serwer zapytaniami mysql skoro można je przechowywać w tablicy $_SESSION?

[Tomahawk]

No dobra załóżmy że mam taki mechanizm sesji:

$id_sesji=$_cookie['id_sesji'];

Wchodzi użytkownik na stronę i sprawdzane jest czy istnieje zmienna $id_sesji.

Jeżeli nie istnieje to wyświetlany jest formularz logowania. Logowanie odbywa się poprzez zapisanie w cookie identyfikatora sesji, oraz zapisanie w bazie danych następujących informacji:

id_sesji | id_usera | IP | User_agent | time

Jeżeli natomiast $id_sesji istnieje to robione jest zapytanie które robi update time (w bazie danych) gdzie id_sesji=$id_sesji.

Jeżeli ilość zmodyfikowanych rekordów jest większa niż 0 to jest wszystko ok i dalej user śmiga po stronie.

Jeżeli natomiast zmodyfikowanych rekordów jest 0 to wyświetlany jest formularz logowania.

Jeżeli user chce się wylogować to usuwane jest z ciastka id sesji i wszystkie dane z tabeli gdzie id_sesji=$id_sesji.

Problem jest wtedy gdy się nie wyloguje a a chce żeby sesja trwała 15minut. Wtedy nie wiem jak zrobić żeby kiedy time+15minut<czas teraz usuwany był rekord.

Takie coś wymyśliłem. Proszę o jakieś sugestie czy to mniej więcej tak może wyglądać lub jakieś inne propozycje bo dla mnie trochę załamka że będe miał +1 zapytanie na każdej podstronie.

[mkr]

Tomahawk przy wiekszej odwiedzalnosci rozwiazanie na bazie jest nie wydajne. W sesji rownie dobrze mozesz zapisac useragent czy IP i sprawdzic czy sie zgadza. Wydajnosc bedzie duzo wieksza.

[Tomahawk]

No tak ale wszystkie większe aplikacje fora, cmsy a także mechanizmy które widziałem w internecie mają właśnie rozwiązanie na bazie danych.

Nierozumiem dlaczego tak.

[nrm]

bo tak masz większe możliwości, tylko na bazie możesz zrobić masę rzeczy, których na plikach nie wykonasz. "Niewydajność" tego rozwiązania to jakiś mit, to zaledwie jakieś 3sqle więcej. Ja w tej chwili mam kilka tysięcy wpisów w tabeli sessions (utrzymywanie nieaktywnej sesji do 30 minut) a serwer (P4) nie ma z tym problemów. Największe testowanie obciążenie: około 40 tysięcy uników dziennie, load ponad 1.

[Tomahawk]

No ok ale jak minie 30 minut to jak są te sesje kasowane?

[nrm]

normalnie. DELETE FROM sessions WHERE ostatnia_aktywnosc < $okres_aktywnosci

[Tomahawk]

No tak, ale nie da się tego jakoś bardziej wydajnie? Bo jak dołoże jeszcze to zapytanie to będe miał +2 zapytanie na każdej podstronie.

[kawa]

Teraz dużo się mówi o tym że session jest dziurawe i że warto napisać własny mechanizm sesji.

Bzdury. Ludzie którzy to piszą nie wiedzą co mówią. Mechanizm sesji jest tak dziurawy, jak dziurawy jest dostęp do katalogu przechowującego sesje, tzn. jak ktoś nie umie administrować serwerem to tak czy inaczej taki sam dostęp inni mają do katalogu domowego danego usera (gdzie można zapisywać sesje) - a co za tym idzie mają wszystkie hasła, także do bazy.

No tak ale wszystkie większe aplikacje fora, cmsy a także mechanizmy które widziałem w internecie mają właśnie rozwiązanie na bazie danych. Nierozumiem dlaczego tak.

To dokładnie tak samo jak ja, pliki (odpowiednio skonfigurowane) są dużo szybsze i bezpieczniejsze od bazy danych bo żeby się do nich dostać trzeba złamać hasło serwera a nie hasło do bazy. Mi się wydaje, że takie fora po prostu często chodzą na dzielonych hostingach, gdzie admini sobie nie radzą. Zrobienie serwisu do hostingu for jest też dużo prostsze, jeśli sesje są w bazie danych.

$_SESSION['t'] = mktime();
if ($_SESSION['t'] > mktime() + 15*60)
foreach ($_SESSION as $k=>$v)
 unset($_SESSION[$k]);

[Bełdzio]

przeczytaj => https://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji.freez zastosuj i będzie bezpieczniej :-)

[kawa]

Dobry artykuł, jadnak z paroma informacjami się nie zgadzam:

W jaki sposób mechanizm sesji na bazie danych uchroni przed atakiem CSRF i Session poisoning bo ja nie widzę żadnego (piszesz, że to uchroni od niedoskonałości natywnej obsługi sesji co może to sugerować).

XSS / Cross Site Scripting - piszesz, że nie powinno się przekazywać SID w adresie strony. Jaki problem napisać prosty skrypt js który wyciągnie zawartość wszystkich zmiennych z ciasteczka (w tym również identyfikator sesji)? Poza tym skutkiem session_regenerate() będzie to, że użytkownik nie będzie mógł otworzyć podstrony w nowym oknie (bo w poprzednim oknie zostanie wylogowany), czy wyświetlić popupa - więc to raczej kiepski pomysł.

Najbezpieczniejszym miejscem na przechowywania danych jest baza danych.

Bardzo dużo serwisów umożliwia ataki typu SQL Injection, np. na jednej z 50 podstron ktoś czegoś nie przypilnował. Jak to się ma do tego, że tak prosty atak dla plików po prostu nie istnieje. Przy odpowiednio zabezpieczonym serwerze nikt nieuprawniony nie jest w stanie plików sesji zmodyfikować, przy odpowiednio zabezpieczonej bazie i "chwili nieuwagi" może to zrobić każdy.

Twierdzenie, że baza danych jest bardziej bezpieczna niż system plików to nieporozumienie bo... baza danych znajduje się w systemie plików.

[nrm]

No tak, ale nie da się tego jakoś bardziej wydajnie? Bo jak dołoże jeszcze to zapytanie to będe miał +2 zapytanie na każdej podstronie.

+2 to jest NIC ("dla mnie zabicie pana to jak splunięcie"). Nie popadaj w skrajność.

[Bełdzio]

1. thx

2. ogólnie różnica między plikami, a bazą jest taka, że w "bazowej sesji" musisz wykonać SQL Injection żeby wyciągnąć dane

3. zeby wyciągnąć dane z ciastka musisz wykonać XSS'a

4. cóż w wiekszosci przypadkow zwiekszenie bezpieczenstwa odbija sie na uzytecznosci

Twoje "zarzuty" opierają się na tym, że app będzie podatny na SQLI albo XSS, a przecież chodzi o to, żeby zabezpieczyć system przed tym art nie jest o tym jak bronić sesji jeśli system jest podatny na kazdy inny mozliwy atak