Zastanawiam się nad bezpieczeństwem skryptów opartych o php-owskie sesje oraz bazę MySQL. Załóżmy, że przy logowaniu, wyszukuję w bazie czy istnieje user o podanym haśle i nicku. Jeśli istnieje to tworzę sesję. No i właśnie... Do sesji nie powinno się przypisywać żadnych haseł/nicków, ale czy można przypisać ID danego usera? Co jeśli przypiszę sesję tak:

[PHP] pobierz, plaintext 
$_SESSION['login'] = $user_id;
[PHP] pobierz, plaintext 

gdzie $user_id to np. 1, czyli admin? Czy to jest 100% bezpieczne rozwiązanie? No bo jeśli w jakiś sposób dałoby się zmienić zawartość sesji i ktoś przypisze sobie do swojej sesji 1 to automatycznie jest na koncie admina i robi co chce. Pytanie czy tak się da?

No i druga sprawa - dostęp do Panelu Admina (PA). Czy wystarczy, jeśli do PA będę wpuszczał osoby, które w bazie mają przypisane user_level (pole tinyint(1) default 0) == 1 ? Teoretycznie nikt sobie nie zmieni sam tej wartości bo musiałby mieć dostęp do bazy, a jesli już miałby dostęp do bazy to może wszystko, wiec czy taka alternatywa wytarczy, czy raczej trzeba dorzucić jakieś oddzielne logowania, cuda wianki?

A niby czemu nie można?

Nie pytaj czy można, tylko jak działają sesje, a to jest wytłumaczone w bardzo wielu miejscach na google.pl .

Jak zrozumiesz ich działanie to nie będziesz już musiał o cokolwiek pytać.

Ze względów bezpieczeństwa ;] Działanie sesji znam, pytam o ich bezpieczeństwo, przeczytaj to co napisałem jeszcze raz. Nie proszę o tutorial 'jak zrobić logowanie krok po kroku, oparte o sesje'.

Nie znasz, bo te pytania:





To właściwie są pytania o to jak działają sesje.

Odpowiadając na pierwsze pytanie dane takie da się modyfikować i odczytywać przy istnieniu innych luk w systemie, często przeze mnie spotykanych na hostingach współdzielonych. Takie ataki nazywają się session poisoning.

Nie, to są pytania o bezpieczeństwo, konkretniej czy da się zmienić zawartość sesji z zewnątrz, nie widzę tu nic co tyczyłoby się działania sesji od strony PHP, ale nie będę się z Tobą spierał.

Da się zmienić zawartość sesji na współdzielonym serwerze, jeśli nie używasz jakiegoś włanego handlera, albo własnego ustwienia session.save_path.

W takim razie jakie będzie najlepsze ustawienie session_save_path() ?

@up Po prostu inne niż domyślne na hostingu?

Dodatkowo należy zadbać o to, aby session id NIDGY nie było przekazywane w adresie.

Uzasadnij proszę.

Session Hijacking

Mnie osobiście to nie przekonuje. Moim zdaniem wykradnięcie identyfikatora sesji jest tak samo możłiwe z url jak i z cookie. Na twórcy strony spoczywa obowiązek zabezpiecznia przed uzyskaniem dostępu za pomocą wykradzionego identyfikatora. Ot, tyle jak dla mnie.

Nie do końca, znaczniej łatwiej wykraść url niż cookies, choćby referrer, głupota użytkownika, czy luki w przeglądarkach.

Ja nie napisałem że nie jest łatwiej, tylko że jedno i drugie jest możliwe. Nie zgadzam się po prostu z podejściem że nie zezwolenie na przekazywanie identyfikatora sesji w url'u jest receptą na bezpieczeństwo. Do tego pewnie są tacy użytkownicy którzy ciasteczek z różnych powodów nie zaakceptują i czy oni powinni być ignorowani?. Goły mechanizm sesji w PHP nie jest zabezpieczony w żaden sposób przed session hijacking ( a z tego co mi się kojarzy nie był kiedyś nawet przed null-byte), więc zawsze trzeba mieć na uwadze że jak chcemy dbać o bezpieczeństwo uzytkowników to musimy zabezpieczyć sesje sami. A jeżeli np mam stronę gdzie nie daje się użytkownikowi możliwości wstawiania treści, to zaryzukję stwierdzenie że przy zabezpieczeniu polegającym na porównywaniu referera z ostatnio odwiedzoną stroną (przy krótkim czasie życia sesji), to będziemy już tak samo bezpieczni na ciastku i na url-u. Więc chyba jednak dużo zależy od specyfiki strony i stwierdzenie że session id nigdy nie może być przekazywane w url-u jest nieco wyolbrzymione.

Ale jest receptą na niebezpieczeństwo



No cóż... niemal wszystkie istniejące strony oparte o PHP używają z ciasteczek, więc jak ktoś wyłącza ich obsługę to sam sobie szkodzi.



Ahh... NULL byte... to były piękne czasy. Co do "gołego" mechanizmu PHP, sam w sobie nie zabezpiecza przed session hijacking, ale nie stwarza też sam z siebie zagrożenia tak jak robi to trans_sid = On



No cóż... ryzyko tym razem nie popłaciło, bo jako inny user łatwo odgadnąć jaki jest referer i go podrobić. Poza tym dużo użytkowników wyłącza w przeglądarce referer / user-agent.



Nie jest wyolbrzymione, jednak rzeczywiście mogą mieć miejsce sytuacje, gdzie użycie trans_sid ma sensowne uzasadnienie. Ale to są rzadkie przypadki.

To w jednym się zgadzamy. Ale to z refererem... słów mi brakło, jaka w tym wypadku jest różnica między bezpieczeństwem cookie vs url?? albo masz dostęp do maszyny albo snifujesz nic więcej nie zrobisz. Warto czytać ze zrozumieniem zamiast się gadać, że się ryzyko nie opłaciło bo to stwierdzenie Tobie się nie opłaciło. Dajesz tutaj scenariusz ataku na url, który przy tych samych założeniach nie powiedzie się na cookie, nie ma wstawianej treści na stronę i nie ma linków na zewnątrz.

Edit: Co gorsza wydaje mi się że url będzie bardziej odporne na CSRF

To samo mi mówili ludzie, dla których aplikacji wykonywałem pełen audyt bezpieczeństwa na umowę. Zarzucono mi, że na siłę pakuję nieznaczące błędy do raportu, bo niby chcę więcej zarobić w ten sposób. Jak za jakiś czas wysłałem screenshot, w którym jestem zalogowany jako administrator z nowym nickiem, osoby te nigdy więcej nie zarzuciły mi próby naciągactwa. Mało tego nazwano mnie geniuszem, a nie trzeba być wcale geniuszem ("Ale jakto? Przecież był sprawdzany referer i user-agent!"), tylko znajomość działania danych technologii.



No widzisz - zarzucasz mi nieczytanie ze zrozumieniem, a sam nie czytasz tego co piszę, a dodatkowo wciskasz mi jeszcze coś na usta, czego nigdy nie powiedziałem. Nigdy nie twierdziłem, że przy sprawdzaniu referera jest większe bezpieczeństwo przy sesjach stricte cookie. Według mnie w obu przypadkach sprawdzanie referera to słabe zabezpieczenie (tak naprawdę to tylko niewielkie utrudnienie), a nie tylko w jednym z nich.

Po pierwsze dałem przykład i poprosiłem Cię o wskazanie korzyści w bezpieczeństwie na korzyść COOKIE w tym konkretnym przykładzie. Nie dałeś.

Po drugie nie twierdzę że sprawdzanie referera jest receptą na bezpieczną sesję.

Po trzecie cała nasza dyskusja zaczęła się od mojej opinii że stwierdzenie NIGDY jest nad wyrost. Sam nigdy nie dopuściłem przekazywania id w sesji, ale potrafię sobie wyobrazić kiedy bez obaw mógłbym na to zezwolić. Skoro robisz audyty bezpieczeństwa to chyba wiesz że złamać da się wszystko, tylko kwestia czy atak nie jest droższy od wartości zdobytej informacji. Dlatego myślę że można by powiedzieć zamiast NIGDY, np "staraj się unikać, jeśli nie rozumiesz zagrożeń z tym związanych lub nie ma szczególnych powodów do zezwolenia na to". Bo tak jakiś nowicjusz przeczyta to i zawsze będzie miał w głowie, że tak nie można bo mu stronę shaczą, nie rozumiejąc jak i dlaczego.

I to wszystko co miałem do powiedzenia w temacie. O zagrożeniach można by tu było sypnąć autorowi wiele lektur, ale on tylko pytał czy da się zmienić zawartość sesji, a ja o uzasadnienie poprosiłem kolegę reptile_rex sądząc, że być może ja o czymś nie pomyślałem, a nie po to żeby wywoływać burzę w szklance wody i czytać o przeprowadzoncyh audytach bezpieczeństwa (choć warto mieć w świadomości, że są tacy którzy przeprowadzają je nie posiadając stosownych umów :]).

Podsumowując proponuję zdrowy rozsądek, bo po co wdrażać zebrane do kupy pomysły wszystkich forumowiczów dla strony która dla zalogowanych wyświetla dowcip dnia.
Osoby biorące udział w tej dyskusji pozdrawiam serdecznie.

(Raczej nie będę kontynuował wypowiadania się w tym wątku bo zrobił się straszny offtop i zbędne bicie piany.)

Nie wszystko, ale prawda jest niestety taka, że osób nie przestrzegających zasad bezpieczeństwa jest znaczny ogrom.



No tak... ale czy warto stosować trans_sid tylko dlatego, że można? Jaki byłby w tym sens, skoro domyślnie w PHP jest wyłączone. Nie dość, że trzeba by zmieniać konfigurację, to jeszcze nie ma w tym większego celu. Poza tym wymyśliłeś sobie przykład, gdzie użytkownik nie robi nic na stronie, a wiadomo, że w znacznej większości skryptów opartych na sesjach user coś jednak robi. Dodatkowo:




No i temat cały czas o tym był.







No tak.. bo rzeczywiście dla strony wyświetlającej dowcip dnia warto tworzyć logowanie.



Może być.

Jeśli znajdziesz 100 ludzi którzy zapłacą 1 zł sms-em za dostęp do tej treści to warto. Dodatkowo włączyć use_trans_id bo może znajdziesz jednego więcej.





Mocne stwierdzenie. Chyba dysponujesz jakąś bezcenną wiedzą

Nie rozumiem o co Ci chodzi z tym:



Ale:





Chodzi o to, że po prostu niektórzy tworzą skrypty tylko tak, żeby działały. I na ten przykład:



Wszystko strony rządowe i wojskowe, a znalazłem je teraz w 3 minuty po przeczytaniu Twojego posta (nie moje linki). Rząd ma pieniądze, a nie może sobie pozwolić na taki wydatek, który stworzy bezpieczne strony i sieci, nie rozumiem tego paradoksu zupełnie.

Swoją drogą podczas ostatnich wyborów dane logowania do panelu administracyjnego PO to.... admin / admin.

Chodziło mi o prosty przykład strony o charkterze płatnym, wyświetlającej nawet jakiś stayczny html z treścią, nie wiem np nowelizacje ustaw. Większym zagrożeniem nieutoryzowanego dostępu będzie przekazywanie loginu niż to że ktoś będzie łamał sesję żeby oszczędzić złotówkę. Ja prowadząc taki szukałbym możliwości włączenia trans_id, żeby umożliwić dostęp większej ilości osób (nawet jeśli byłaby to 5 osób schylałbym się po to, zwłaszcza że się zrobiła nagonka na "CIASTECZKA" śledzące, wchodzą nowe regulacje prawne i pewnie ludzie zaczynają się zastanwiać na akceptowniem ciasteczek). Jeżeli chodzi o przekazanie linka to zawsze można wkleić komuś po prostu goły tekst i wyjdzie na to samo. W prostym zakresie zawsze można niskim nakładem zdecydowanie ograniczyć użyteczność przekazanego id. Do tego zawsze można odejść od sesji PHP i obsługiwać sesję po swojemu wg id w url-u, a wtedy zawsze można skomplikować bardziej kwestię nieautoryzowanego wykorzystania identyfikatora. W sumie napisanie własnych sesji nie jest jakąś czasochłonną magią, choć ze względów bezpieczeństwa nie polecałbym tego rozwiązania raczkującym w temacie bezpieczeństwa skryptów .

Nie do końca, bo x lat temu nie raz na forach spotykałem się z linkami np. na forach, gdzie były doklejane sesje i wystarczyło kliknąć w link, żeby wejść jako zalogowany użytkownik (a potem w panelu był widoczny adres e-mail, można było zmienić hasło itp.). A gdyby tamten skrypt był oparty na ciasteczkach, to wklejenie takiego linku nic by nie dało. I takie sytuacje wynikały nie z głupoty użytkowników, tylko z nieznajomości działania aplikacji www, a przecież nie każdy musi się znać.



page.pl/hidden_content.php - artykuły dostępne po zalogowaniu
page.pl/login.php - logowanie
page.pl/user_panel.php - dane użytkownika, zmiana hasła itp.

I teraz jest różnica czy ktoś wklei link page.pl/?PHPSESSID=123 (trans_sid = On), czy page.pl (trans_sid = Off) tak jak w przykładzie powyżej. Więc jednak nie wyjdzie na to samo.

Chyba starczy w tym temacie, bo kręcimy się już w kółko, a mnie już mdli od gadania o trans_sid