Witam, mam pyt odnośnie bezpieczeństwa mojego systemu sesji. Juz tlumacze na czym on polega. Uzytkownik loguje sie poprzez strone glowna w domena.pl - nast gdy dane sa poprawne do bazy serwera s1.domena.pl zostaje wpisany rekord w tabele session (ip usera, jego id uzytkownika w serwisie, dane przegladarki -> $_SERVER['HTTP_USER_AGENT'] - czas sesji). Nastepnie user zostaje przeniesiony na strone glowna s1.domena.pl, po czym plik index.php odpowiadajacy za cala strone pobiera rekord z tej tabeli session gdzie jest takie samo ip, taka sama przegladarka oraz gdzie czas jest > czasu aktualnego (wczesniej czas sesji zostal zapisany time() + 900 czyli na 15 min). Jezeli wszystko sie zgadza system pobiera dane o userze z tabeli users ( z pomoca id usera z tabeli session) i za kazdym odswiezeniem strony aktualizuje rekord sesji w session ustawiajac ponownie sesje wazna na 15 min (przez co mozna sprawdzic kiedy jest aktywny). I to chyba na tyle, prosilbym o jakies odpowiedzi czy jest to bezpieczne, a jesli nie jest to jakies male wytlumaczenie z gory dzieki

W teorii odradza się trzymanie sesji na serwerach współdzielonych - ktoś może przechwycić twoje sesje. Ile w tym prawdy nie wiem - sam od dawna używam tylko cookie i bazy danych. Daje mi to większe pole manewru niż "zwykłe" sesje np. zamkniecie przeglądarki nie powoduje wylogowania no i z bezpieczeństwem też nigdy nie miałem problemów.

Był ten temat poruszany, choćby zmienić ścieżkę gdzie będą trzymane pliki sesji.

A od kiedy sesje z php przy zamknięciu się tracą, zakładając że cookie nie są usuwane?

Nie ma kodu, nie ma o czym dyskutować. Możesz się pochwalić jak zabezpieczyłeś. ;]

Nie wiem ,ale czytałem gdzieś ,że popularne allegro zbudowane n php ,w taki sposób przechowuje sesje.


A pro po tematu , sesje można także trzymać w bazie danych ,trochę bezpieczniejsze niż tradycyjna metoda.

No i teraz wyobraź sobie początkującego programistę, który ustawi ścieżkę na folder główny strony i jej odpowiednio nie zabezpieczy Co jest bardziej niż bardzo prawdopodobne


Nie mówię o cookie tylko o "zwykłych" sesjach [dla jasności ;P session_start, session_close]. Nie wiem jak u Ciebie ale ja po restarcie przeglądarki muszę się logować na serwisy, które nie korzystają z cookie


Hehe to się szantaż emocjonalny nazywa ogólnie to nic szczególnego.. zebranie wszystkich "rad i zaleceń" w jedno. No i jak dotąd nie miałem problemów z włamaniami itp.


Rid: tylko jest pewna różnica między zespołem pracującym w allegro a ludźmi odwiedzającymi to forum ;] zwie się doświadczenie


Mylisz pojęcia.. pliki sesji nadal istnieją na serwerze nawet jeżeli ich "odpowiednik"(nie wiem jak to nazwać) trzymasz w bazie

Nie wydaje mi się- po stronie serwera przechowywany jest tylko id sesji,wartość sesji natomiast przechowywana jest w bazie.

No a o czym ja mówię... hjacking

Myśli Pan ,że będzie możliwy Session Hijacking,jak się stronkę jak i połączenie z bazą MYSQL postawi na SSL?
Myślę ,że normalna sesja jest bardziej narażona na ataki.

Hmmm jak by Ci to wytłumaczyć.. załóżmy, że logujesz się na jakiś serwis, który nie używa ciasteczek(serwer tworzy ID aktualnej sesji). Wchodzisz na podstronę np. Edytuj konto i podczas tego przejścia ID sesji z twojej przeglądarki zostaje przesłane z powrotem na serwer i tam porównane. W ten właśnie sposób serwer rozpoznaje kto jest kto. Teraz wyobraź sobie, że znalazłem folder z zapisanymi aktualnymi sesjami, więc podpinam się pod jedną z nich i spokojnie edytuję sobie np. Twoje hasło do konta

I SSL nie ma tu co robić ponieważ nie przechwytuję request'a tylko biorę gotowca z serwera ;]

Jeżeli włamywacz ma dostęp do serwera to żadne zabezpieczenia Ci nic nie dadzą.

Co do zmiany ścieżki - fakt, jest to niezwykle trudne. ^^

Zacznijmy od tego - jeżeli kradniemy sesje, to nie z serwera a komputera użyszkodnika. Jeżeli wykradniemy ID sesji, to nie ma różnicy czy było w cookie czy w pasku adresu bo dostęp prawdopodobnie będziemy mieli (nie licząc sprawdzania ip, przeglądarki)

Poza tym, nie mieliśmy rozmawiać o wykradaniu sesji, lecz o zabezpieczeniach.

Ja proponuję artykuł na ten temat:
http://niebezpiecznik.pl/post/firesheep-fi...ataki-na-sesje/
A jak ktoś ,nie jest pewny bezpieczeństwa SSL to może jeszcze skorzystać z IPSec-i myśle ,że raczej przechwycenie sesji
nie będzie możliwe.



A czym jest SSL??

@up ... chyba niedoczytałeś co ten firesheep robi .
Czyli to jest po prostu sniffer , to nie problem naszego skryptu bo ktoś może mieć cały batalion , a sprawdzanie IP w tym przypadku nie pomoże .. bo łączymy się przez to samo Wi-Fi . Ale sprawdzenie useragenta już może dać jakiś efekt co nie?

Rid: ja nie mówię o podsłuchach... tylko wykradnięciu sesji u źródła... dlatego SSL nie będzie miało znaczenia :|

nekomata: IP i useragent... hmmm w dobie zmiennego IP neostrady punkt 1 odpada. Jedynym rozsądnym wyjściem wydaje się sprawdzenie wersji przeglądarki..

Zmienne IP eliminuje możliwość? Czy ja wiem ? Można dodać monit o powtórne podanie hasła w przypadku innego ip + tickbox "nie pytaj ponownie" , w ten sposób użytkownicy których nie obchodzi bezpieczeństwo mają spokój , a bezpieczni mają swoją rzecz.

Co Ty pier... gadasz. Co ma zmienne ip do sesji? W czasie sesji ip się nie zmienia, chyba że zostaniemy rozłączeni ew. sami się rozłączymy i połączymy ponownie.

Może zsumujmy co robimy do zabezpieczenia sesji , według mnie to :
1.Blokujemy XSS (javascripty w postach itd ,podstawa ale warto wymienić)
2.Sprawdzanie User Agent'a : jeśli user agent inny niż w poprzedniej sesji -> niszczymy.
3.Sprawdzanie IP użytkownika : jeśli inne -> wyrzucamy monit i ponowne wpisanie hasła .
4.Zmieniamy folder zapisu sesji (własny session handler albo session_save_path )

To by chyba było na tyle?

@autor topic'u jeśli nie zmienisz domyślnego czasu sesji (10 minut) to może gdzieś się skrypt wywalić .

Ja bym jeszcze do wyżej wymienionego postu dodał:
ustawienie flag secure oraz httpOnlyCoockie na true dla sesji .Jak to zrobić:
http://php.net/manual/en/function.session-...okie-params.php