PHP - bezpieczeństwo sesji

Question

Witam, programuje w czystym PHP bez żadnych frameworków, chce wstawić serwis z możliwością tworzenia kont, ale zanim to zrobie chciałbym go odpowiednio zabezpieczyć.

 

Posiada coś typu fingerprint, który jest wysyłany do każdego zapytania i musi być zgodny z odciskiem utworzonym w sesji.

Sesja posiada sprawdzanie User_agent przeglądarki oraz adres ip, jeśli których z nich się różni użytkownik zostaje wylogowany.

i tu pojawia się pierwszy problem, niektórzy mają zmienne ip i zostają wylogowani nawet kilka razy w ciągu dnia, natomiast autoryzacja po wyłączeniu sprawdzenia ip tylko polegająca na sprawdzeniu user_agenta użytkownika i ew. wylogowanie go gdy się nie zgadza jest według mnie bardzo niebezpieczna.

 

Drugi problem jest taki że nawet randomowe strony schronisk pisane na cms w ciasteczkach mają ich po kilka, _gat _auth itd. moja ma tylko PHPSESSID + randomowe znaki i nie wygląda mi to na bezpieczne.

 

Jak to wszystko znacznie lepiej zabeczpieczyć jeśli chodzi o sesje?

Comments

Nie mam teraz czasu na pełną odpowiedź, ale...

Posiada coś typu fingerprint, który jest wysyłany do każdego zapytania i musi być zgodny z odciskiem utworzonym w sesji.

...czyli ciastko? AFAIK dokładnie tak działają sesje, z automatu.

_gat

to ciastko google analytics. Nie ma żadnego związku z bezpieczeństwem.

---

Chodzi mi o bardziej w tym pierwszym cytowaniu o dołązanie odcisku do każdego zapytania, aby ktoś zalogowany jako np. nie dostał fake linku, który po otworzeniu przez niego mając uprawnienia administratora nie wykonał akcji, ponieważ dla każdego konta jest dołączany odcisk, wtedy atakujący podsyłający link musiałby znać odcisk sesji administratora, a to jest raczej nie do odkrycia, ten sposób według mnie bardziej kieruje bezpieczeństwo na sesje, które właśnie chce zabezpieczyć lepiej niż dotychczas.

_gat to rzeczywiście ciasteczko od google, mój błąd.

---

aby ktoś zalogowany jako np. nie dostał fake linku, który po otworzeniu przez niego mając uprawnienia administratora nie wykonał akcji

To też ma standardowe rozwiązanie - weryfikację, że żądanie akcji pochodzi z poprawnego źródła. Poczytaj o CSRF i tokenach CSRF.

Na przykład https://stackoverflow.com/a/33829607/2468469 https://stackoverflow.com/q/6287903/2468469 etc

---

Przykładowe rozwiązanie z tokenem to dokładnie to samo tylko u mnie nazwane fingerprintem, z tym wyjątkiem że token jest generowany na każde żądanie inny, u mnie "token" jest generowany na sesje i dołączany do każdego zapytania, w przypadku błędnego wyświetla informacje o problemie, w przypadku kilku nieprawidłowych tokenów w krótkim czasie niszczy sesje (ew. blokuje ip, myślę nad tym jeszcze)

---

Jeden token per sesja to wciąż jest poprawna implementacja CSRF i wciąż spełnia swoje zadanie (może ewentualnie być trochę bardziej podatny na inne ataki na stronę). Patrz na przykład:

https://security.stackexchange.com/questions/22903/why-refresh-csrf-token-per-form-request

Natomiast wciąż silnie rekomenduję korzystać ze sprawdzonych, standardowych rozwiązań, zamiast wymyślać własne.

przypadku kilku nieprawidłowych tokenów w krótkim czasie niszczy sesje (ew. blokuje ip, myślę nad tym jeszcze)

IMO Jeśli atak CSRF jest niemożliwy dzieki zabezpieczeniom, nie ma sensu dodatkowo "karać" użytkownika który kliknął na złośliwy link.