Logowanie - sesje czy cookie, Bezpieczeństwo Opcje

[Gitrix]

Zacząłem ostatnio uzupełniać swoją wiedzę z PHP i mam mętlik w głowie. Zrobiłem sobie prosty system logowania oparty na cookies, jednak teraz dowiaduje się, że bezpieczniej jest robić logowanie na sesjach, gdyż podobno użytkownik może ciasteczka tworzyć sam oraz je edytować (https://www.youtube.com/watch?v=bW64jbnGYHw). Niejednokrotnie widzę na stronach internetowych napis, że ich witryna używa cookies, a po usunięciu ciasteczek z przeglądarki, następuje wylogowanie mnie. To jak to z tym wreszcie jest? Cookies czy sesje?

[kapslokk]

Zeby sesja zadzialala musisz zapisac gdzies jej ID - albo bedziesz je przekazywal w URL'u, albo zapiszesz w ciastku. Na podstawie tego ID identyfikujesz sesje uzytkownika.

Ten post edytował kapslokk 26.08.2016, 10:31:25

[Gitrix]

Ale co jest bezpieczniejsze - logowanie na ciasteczkach czy bardziej w sesje?

[kapslokk]

Sesje - dane sesji sa trzymane na serwerze, a ciastka na komputerze uzytkownika - uzytkownik nie zmieni sam danych sesji, a ciastko tak.

[Gitrix]

Dzięki za odpowiedź. O to mi chodziło.

[Damonsson]

Chyba nie do końca załapałeś. Więc dodam swoje trzy grosze.

Jeśli chcesz używać sesji to musisz też używać cookie, które będzie przechowywało id sesji. Sesja nie będzie działać bez cookie*.

*Oczywiście zamiast cookie, możesz przekazywać id sesji w URLu, czy trzymać go w local.storage czy jeszcze możesz wymyślić jakiś dziwny sposób. Ale id sesji trzyma się w cookie, to jest naturalne i bezpieczne.

Ty po swojej stronie serwera, musisz przechowywać id sesji i użytkownik po swojej też musi go przechowywać, inaczej nie będziecie wzajemnie wiedzieli o sobie. W cookie użytkownika jest tylko id tej sesji, nic więcej.

Mając sesje, masz je przypisane do odpowiedniego użytkownika i możesz utrzymywać np. jego status zalogowania, czy sprawdzać czy to admin. Ale to wszystko robisz po stronie serwera, czyli użytkownik nie ma na to wpływu.

Natomiast kiedy zrezygnowałbyś całkowicie z sesji, to w ciasteczku musiałbyś umieścić np takie informacje jak "czyAdmin=nie" i teraz każdy mógłby sobie to ciasteczko edytować i podmienić wartość na "czyAdmin=tak" i voila miałby dostęp np do panelu admina. Przy używaniu sesji, jedyne co użytkownik może zmienić to jego id sesji w ciasteczku, ale nic mu to nie da, bo nie zna id sesji admina, więc po prostu zostanie wylogowany, bo nie zostanie znaleziony taki id sesji na jaki on zmienił.

Ten post edytował Damonsson 26.08.2016, 11:04:55

[daro0]

Tyle że sesje można trzymać także w ciasteczkach. Tzn. trzyma się tam w jakimś ciasteczku o nazwie dajmy na to session_cookie wszystkie zserializowane dane i jeszcze zaszyfrowane dajmy na to albo base64encode (no ale to łatwo odszyfrować a nawet zidentyfikować) albo pewnie bcryptem czy czymś takim. Tego typu sesje nie mają swojego unikalnego ID. Nie wiem ile frameworków to oferuje ale Kohana to na pewno. Przekazywanie session id przez URL wiąże się z niebezpieczeństwem ataków typu Session Fixation, Session Poisoning, Session Hijacking.

Standardowe logowanie opiera się na sesjach, natomiast opcja zapamiętaj mnie przez dajmy na to miesiąc na odpowiednich dodatkowych tabelach i wpisach w bazie danych użytkowników ale to też stwarza pewne niebezpieczeństwa, o czym się kiedyś przekonałem na własnej skórze :-) Zwłaszcza jeśli się logowaliście na innym laptopie z tą opcją i ktoś inny może Wam łatwo dodać wpisy na Facebooku, których sobie nie życzycie :-)

[viking]

Są też biblioteki które zwiększają bezpieczeństwo sesji wbudowanej np https://github.com/ezimuel/PHP-Secure-Session

[daro0]

Ogólnie to i tak najlepiej robić takie rzeczy na frameworkach. Cookie można też fajnie zabezpieczyć przed modyfikacją ręczną, taka modyfikacja później zakończy się tym, że ciasteczko nie zostanie po prostu odczytane i takie logowanie się po prostu nie uda, podaję przykład w Kohanie, choć w innych frameworkach może być też coś na wzór tego:

https://kohanaframework.org/3.3/guide-api/Cookie

Tego typu zabezpieczenie jest realizowane przez hashowanie pewnych danych i jeszcze z użyciem soli (bez tego można łatwo sobie poradzić bazując chociażby na kodzie wyżej), użycie tego przy zapisie a potem sprawdzanie czy się zgadza przy odczycie, możecie przeanalizować ten kod.

[Comandeer]

To może ja rzucę: JWT

jeszcze zaszyfrowane dajmy na to albo base64encode (no ale to łatwo odszyfrować a nawet zidentyfikować) albo pewnie bcryptem czy czymś takim.

bcryptem to raczej średnio zaszyfrowane, zważając na fakt, że to algorytm hashujący. Owszem, ciastko będzie bezpieczne. Na tyle, że nawet Ty nie odczytasz zawartych w nim danych

[daro0]

bcryptem to raczej średnio zaszyfrowane, zważając na fakt, że to algorytm hashujący. Owszem, ciastko będzie bezpieczne. Na tyle, że nawet Ty nie odczytasz zawartych w nim danych

A no fakt, używane jest raczej to (sprawdzałem także w źródłach Kohany)
http://php.net/manual/en/function.mcrypt-encrypt.php
http://php.net/manual/en/function.mcrypt-decrypt.php

przy czym i tak z tego co zauważyłem, to po zaszyfrowaniu przez mcrypt_encrypt stosowane jest jeszcze po tej operacji base64encode i dopiero to jest zapisywane a przy operacji odczytu dzieje odwrotnie (base64decode a potem mcrypt_decrypt).

Ten post edytował daro0 26.08.2016, 15:53:31

[lukaskolista]

Ustalmy kilka faktów:
- base64 encode i decode nie ma nic wspólnego z bezpieczeństwem
- wrażliwych danych nie trzyma się w cookie nawet "zaszyfrowanych"
- kohana 3 to prehistoria

Przekazywanie session id przez URL wiąże się z niebezpieczeństwem ataków typu Session Fixation, Session Poisoning, Session Hijacking.

A trzymanie zserializowanych danych w ciasku to niby nie...

Natura cookie jest taka, że trzymasz w nim pary klucz=>wartość w typach prostych. Skoro chcesz do typu prostego wpakować typ złożony, to chociaż powinna Ci się zapalić czerwona lampka.

Nie wypisujcie proszę takich bzdur tutaj, bo ktoś to kiedyś przeczyta i weźmie sobie za fachowe źródło.

Standardowe logowanie opiera się na sesjach, natomiast opcja zapamiętaj mnie przez dajmy na to miesiąc na odpowiednich dodatkowych tabelach i wpisach w bazie danych użytkowników ale to też stwarza pewne niebezpieczeństwa, o czym się kiedyś przekonałem na własnej skórze :-) Zwłaszcza jeśli się logowaliście na innym laptopie z tą opcją i ktoś inny może Wam łatwo dodać wpisy na Facebooku, których sobie nie życzycie :-)

Że co?

[em1X]

Zainteresujcie się JWT. Cała sesja przechowywana jest w ciasteczku, jest to dużo szybszy sposób komunikacji i eliminuje problem, np. podczas skalowania horyzontalnego serwisu, w porównaniu do danych trzymanych na dysku serwera, co jest wolniejsze.

Założenia do JWT:

- ciastka powinny mieć maks 0,5kb
- w ciastkach nie przechowujemy drażliwych danych, np. haseł itp.
- pilnujemy klucza prywatnego na serwerze i nie upubliczniamy go (oczywiście)

[Comandeer]

Niekoniecznie przy JWT sesja siedzi w ciastku. Często JWT są przekazywane jako nagłówek HTTP.

[em1X]

A ciastko to jak jest przekazywane?

[Comandeer]

Touché. Chodziło mi o dedykowany nagłówek Authorization.

[daro0]

Ustalmy kilka faktów:
- base64 encode i decode nie ma nic wspólnego z bezpieczeństwem
- wrażliwych danych nie trzyma się w cookie nawet "zaszyfrowanych"
- kohana 3 to prehistoria

Zostawmy może KO3, dałem przykład (ze źródeł) tylko po to żeby łatwo każdy czytelnik mógł sobie przeanalizować kod i jak się realizuje taką ochronę przed ręczną modyfikacją ciasteczek. Tylko i wyłącznie.

Na ile łatwy do złamania jest Rijndael? No jest jeszcze kwestia tego co uważasz za wrażliwe dane, bo jeśli chodzi o logowanie to nawet session id, które jest trzymane w ciasteczku można by uznać za wrażliwe. Base64 to kodowanie transportowe, oczywiście że nie ma to nic wspólnego z bezpieczeństwem, bo można łatwo to zidentyfikować i równie łatwo rozkodować (nawet bez znajomości PHP bo są serwisy online). Ale jakoś trzeba te dane (nie prosty string) zapisać, bo jak sprawdzałem to na mcrypt to mi wychodziły jakieś krzaczki ale i bez tego jest to też stosowane. W tym sensie z założenia żeby była tylko możliwość a nie koniecznie że jest zalecane czy nie zalecane składowanie złożonych danych.

A trzymanie zserializowanych danych w ciasku to niby nie...

Odnosząc się do tego co wyżej:

1. Jak łatwo rozszyfrować Rijndael i ile to zajmie czasu?
2. Skoro jest używany hash (np. SHA1) do kontroli oraz sól (której haker nie zna) a jest zapisana gdzieś w tym przypadku w Kohanie w bootstrap.php w postaci (przykładowa wartość):

[PHP] pobierz, plaintext 
Cookie::$salt = 'yhpyRbFPj9PPj6Fb'
[PHP] pobierz, plaintext 

oczywiście na serwerze, gdzie nie ma (no chyba że się włamie) dostępu do kodu, to nawet jeśli spróbuje zmodyfikować ciasteczko, to FW tego nie przyjmie. Przynajmniej częściowa ochrona.

Napisałem tylko że istnieje możliwość przetrzymywania sesji w Cookie, KO3 oraz pewnie inne frameworki mają do tego swoje klasy do obsługi tego typu sesji. Jakich więc wrażliwych danych nie należy przetrzymywać w cookie?

A w dalszej części wypowiedzi chodziło mi o to, że łatwo można się przejechać logując się w serwisie zaznaczając przez nieuwagę albo bo tak jest wygodniej checkbox "zapamiętaj mnie", na jakimś innym laptopie. Wydaje mi się że w dużej mierze problem z bezpieczeństwem to nie tylko kwestie techniczne ale i zwykłe naturalne (albo rutynowe) zachowania użytkowników o których hakerzy doskonale wiedzą.

Ten post edytował daro0 27.08.2016, 16:13:51

[Pyton_000]

Co do zapamiętaj mnie to za każdym razem musi być sprawdzanie danych. Więc jeśli gdzieś indziej się zalogujemy to automatem poprzednie "zaloguj mnie" idzie do piachu.

[szajens]

daro0 - ćpiesz? Co ty w ogóle za tezy wymyślasz.

wydaje mi się że Damonsson wyjaśnił to łopatologicznie

[lukaskolista]

daro0 - widzę, że nie ogarniasz podstaw bezpieczeństwa. Co z tego, że rijandel, że trudny do złamania? Na prawdę to jest Twój argument?

Właśnie nam powiedziałeś, jakiego algorytmu szyfrującego użyjesz w swojej "bezpiecznej" sesji. Znając algorytm jestem w stanie wstrzyknąć w sesję cokolwiek łącznie z tym, na jakiego usera jestem zalogowany. Prędzej czy później rozgryzę strukturę Twojego ciasteczka chociażby pisząc prosty skrypt generujący różne warianty struktur danych zawierających login/id usera a wtedy...

W ciastku to sobie możesz trzymać informację o tym, czy user zaakceptował politykę cookie + id jego sesji, która po każdym zapytaniu powinno być przegenerowane.

Pomijam już możliwość popełnienia błędu i braku szyfrowania zawartości ciastka w jakimś określonym przypadku.