ostatnio duzo myslalem o sesjach i tak sie zastanawialem, ktory sposob przekazywania zmiennych jest lepszy: przez cookies czy przez przekazywanie id sesji w adresie (url). jak wiadomo w tej pierwszej metodzie problem pojawia się gdy ktoś ma wyłączoną obsługę cookies, w tej drugiej gdy ktoś da adres strony (a w nim tez id) znajomemu. standardowe polaczenie tych dwoch metod nie likwiduje problemu drugiego. osobiscie mysle, ze stanowi to dosyc duza dziure w sytsemie i zastanawialem sie czy po prostu nie wymuszac na uzytkownikach wlaczania cookies (z jasnym wytlumaczeniem w jakim celu). co o tym sadzicie?

Możesz zrobic wlasne 'zabezpieczenia' wystarczy poczytac o artykule na php.pl jak zrobic aby sesje sie zapisaywaly do bazy. Mozesz tam juz dowalnie rozszerzyc 'wybieranie' danych z sesji nie tylko po session id ale mozesz dodac takrze przegladarke ip i takie tam :]

sprawdzanie przeglądarki może być pewnym rozwiązaniem, ale oczywiście nie w pełni zadowalającym (wystarczy ze te 2 osoby maja ta samo, o co nie jest trudno).

co do kontroli IP to też o tym myślałem, ale ma to też jedną wadę, tzn. co gdy IP jest przydzielany dynamicznie, tak jak np. w neostradzie? IP się zmienia, a wtedy użytkownik "wypada" z sesji.

z chęcią bym poznał co rozumiesz przez "i takie tam" bo ja nie mogę za bardzo nic wymyślić...

Najlepsze rozwiazanie podal hwao - link do artykułu.

- Cookie nie kazdy ma wlaczone i nie bedzie przestawial bo ty tak bedziesz wymagal
- IP sa dynamiczne lub jedno na cala siec...

artykul znam dobrze, ale nie on jest przedmiotem tej dyskusji. co prawda jest bardzo pomocny w robieniu wlasnych 'sprawdzaczy' sesji... sęk w tym, że nie za bardzo mogę się doszukać jakichś konkretnych sensownych rozwiązań na podstawie których możnaby weryfikować sesję.

cookies dalej wydają mi się najbezpieczniejszym rozwiązaniem...

tzw "wypadanie" z sesji w neostradzie niew powinno byc groźne. IP nie jest zmieniany w trakcie polaczenia, tylko po odłączeniu, mozna uzyskac inny IP, tak jak to bylo podczas laczenia przez modem (tak mi sie wydaje)

mysle, ze jesli bezpieczenstwo jest naprawde istotne trzeba dolaczyc krycie poprzez ip, ewentualnie zaimplemntowac system logowania, ktory po prostu po zalogowaniu odsyla od razu na poprzednio ogladana strone.

IP jest zmieniany w trakcie połączenia. Inaczej od ponad roku miałbym ten sam IP .

chodzi o to ze nie jest zmieniany co 2 minuty. jak ci sie zmieni IP to wywalam prosbe o ponowne zalogowanie i kontunuujesz wedrowke po stronie.

A jak nie wywalisz prośby o ponowne zalogowanie i ktoś dostanie jego IP to się zdziwi

nie rozumiem, na jakiej zasadzie ktos mialby dostac jego IP?

Choćby z takiej że adres PI wróci do puli przydzielanych adresów...

powiem szczerze, ze w tym momencie sie zgubilem i nie wiem o co chodzi. w moim rozumieniu to jest tak, ze ktos wchodzi na stronie, dostaje id sesji, jako sprawdzacz pobieram jego ip jako jedna ze zeminnych sesji. potem ten ktos wywoluja kolejna strone i sprawdzam czy ip przypisane do id jest to samo co wysylajacego zadanie. jesli nie to wyskauje prosba o ponowne zalogowanie.

probelmem postawionym na poczatku byla kwestia dynamicznego ip i czy mozna wiec opierac sie na ip jako zabezpieczenia, skoro moze sie zmienic. wniosek byl taki, ze ip nie zmienia sie na tylo czesto, aby byl to bardzo powazny problem, uniemozliwiajacy zastosowanie ip do walidacji id sesji.

Ja powiem, że w niektórych przypadkach IP zmiena się nadzwyczaj często. Kieydś z qmplem na neostradzie ściagaliśmy Counter-Strike. Poszło za 3 próbą, bo zmianie IP towarzyszyło rozłączenie.

ale czy jak ktos spedza na stronie np. godzine (w optymistycznym scenariuszu) i przypuscmy, ze 1 czy 2 tylko wyskoczy mu prosba ponownego zalogowania. tak, jest to niedogodnosc, ale jesli bezpieczentstwo odgrywa duza role?

Niedogodnosc moze byc duza, bo niektorzy userzy maja IP, ktore sie zmienia co jedno zadanie HTTP (jesli sa za farma serwerow proxy, to nic nie poradza). Wiec trzymanie IP z sesja bedzie bez sensu - taki ktos po prostu opusci serwis, gdy co chwile bedzie musial sie logowac. Poza tym to nie jest zadna ochrona - jesli juz ktos jest w stanie podsluchac session_id to pewnie przejmie tez i haslo, wiec dostanie nowe, poprawne session_id.

Proponowalbym uzyc SSL - generalnie SSL zwieksza bezpieczenstwo, choc nie gwarantuje (man-in-the-middle attack jest niestety nadal mozliwy, ale jak sie ktos wepnie pozniej, to id sesji juz nie uzyska). Przechowywanie id sesji w ciastku czasem nie dziala, bo niektore przegladarki maja bledy. Np. konqueror ma jedna globalna pule ciastek - nawet tych jednorazowych, wiec gdy otworzysz 2 okienka, to beda obslugiwane w tej samej sesji. Nie wspomne juz, ze uzytkownik moze wylaczyc ciastka.

Moim zdaniem jedynym bezpiecznym i uniwersalnym mechanizmem obslugi sesji sa ukryte pola formularza + przepisywanie adresow + SSL. Id sesji nalezy oczywiscie uniewazniac po jakims czasie lub w momencie, gdy uzytownik sie wyloguje - to dosyc mocno chroni przred wykorzystaniem sesji przez "kolege". Jesli chodzi o bezpieczenstwo sesji po stronie serwera - tu bym generalnie odradzal php, ale zaraz mnie za to zlinczujecie....

Co do proxy, to podobno jest jakiś nagłówek X_FORWARDED_FOR cy cuś innego. Nigdy nie sprawdzałem i nie oznacza to że musi zawsze być.

Co do man-in-the-middle dla SSL, przypomina mi się artykuł o błędzie w MSIE umożliwiający taki atak. Chociaż AFAIK zawsze można dotrzeć do winnego przez certyfikat - jeżeli klient raczy sprawdzić certyfikat który wysłał mu man-in-the-middle.

Ja zawsze preferuję cookie, bo z przepisywaniem URLi są problemy. Raz że to zajmuje czas. Dwa że przy intensywnym JavaScripcie całość może przestać działać.

A co do bezpieczeństwo sesji, to o dziwo generalnie zgadzam się z Królikiem. Jest kiepsko. W php za bardzo poszli w stronę łopatologiczności - session_start, sesja się tworzy i nic więcej nie wiadomo. W J2EE można dowiedzieć się, kiedy stworzono sesję, czy jest stara czy nowa (bardzo ważne - session fixation) itd.

Chociaż, w php można napisać dobry session handler. To jest duży plus - całą obsługę sesji można wymienić, tak więc można z php zrobić system bardzo bezpieczny pod kątem sesji.

@hawk taki nagłówek istnieje i mi pokazuje moje wewnętrzne ip ( 192.168.*.* )

Tak jest w teorii. W praktyce jednak malo kto przejmuje sie ostrzezeniem SSLa o nieoczekiwanej zmianie certyfikatu lub o niemoznosci potwierdzenia certyfikatu. To drugie wystepuje bardzo czesto, bo wiele serwisow usywa "samopodpisanych" (jak to przetlumaczyc: self-signed?) certyfikatow.
A taki falszywy certyfikat nie musi zawierac zadnych prawdziwych danych, wiec dojsc do autora moze byc trudno. Predzej ustali sie atakujacego przez analize czynnosci, ktorych musial dokonac, zeby w ogole stac sie "man-in-the-middle" czyli np. jakis DNS-spoofing, wlam na router/gatway czy cos.

Niemniej przeprowadzenie takiego ataku jest duzo trudniejsze niz wykorzystanie glupiej dziury w Apache'u lub cudzym skrypcie php i wykradzenie session-id z niczym nie chronionego katalogu /tmp, gdzie php je trzyma (jesli uzywa sie domyslnej obslugi sesji).