Session hijacking oznacza przejęcie aktywnej sesji użytkownika, a session fixation polega na podsunięciu mu znanego identyfikatora sesji przed logowaniem. W obu przypadkach efekt może być podobny: ktoś obcy działa w systemie tak, jakby był zalogowanym klientem, pracownikiem albo administratorem.

To nie jest abstrakcyjny problem z podręcznika. Dotyczy sklepów, paneli klienta, portali członkowskich, aplikacji z kontami i każdego serwisu, w którym po zalogowaniu użytkownik może zobaczyć dane albo wykonać akcję.

Jak działa session hijacking?

Po zalogowaniu aplikacja zwykle rozpoznaje użytkownika po identyfikatorze sesji zapisanym w ciasteczku. Jeśli atakujący zdobędzie ten identyfikator, może próbować użyć go u siebie. Do przejęcia może dojść przez XSS, niezabezpieczone połączenie, wyciek logów, złośliwe rozszerzenie przeglądarki, phishing albo słabą konfigurację cookies.

Nie każdy atak zaczyna się od hasła. Czasem hasło zostaje bezpieczne, a problemem jest aktywna sesja.

Na czym polega session fixation?

W session fixation atakujący próbuje sprawić, żeby ofiara zalogowała się z wcześniej znanym identyfikatorem sesji. Jeśli aplikacja nie zmieni ID sesji po udanym logowaniu, stara sesja może stać się sesją zalogowaną. To błąd projektowy, który łatwo przeoczyć przy własnych systemach logowania.

Dlatego po zmianie poziomu uprawnień, szczególnie po logowaniu, aplikacja powinna wygenerować nowy identyfikator sesji. OWASP podkreśla, że regeneracja ID sesji po uwierzytelnieniu jest obowiązkowym elementem obrony przed session fixation.

Podstawowe zabezpieczenia

Regeneruj ID sesji po logowaniu. To najważniejszy punkt przy session fixation.
Wymuś HTTPS na całej stronie. Także poza formularzem logowania.
Ustaw cookies jako HttpOnly, Secure i SameSite. Ogranicza to wyciek i nadużycia w przeglądarce.
Nie zapisuj sesji w URL. Linki z identyfikatorem sesji łatwo trafiają do historii, logów i narzędzi analitycznych.
Wygaszaj sesje rozsądnie. Panel administracyjny i konto klienta nie powinny wisieć aktywne bez końca.
Unieważniaj sesje po zmianie hasła. Użytkownik powinien mieć możliwość wylogowania innych urządzeń.

Co sprawdzić w istniejącej stronie?

Najpierw wykonaj zwykły test użytkownika: zaloguj się, wyloguj, zmień hasło, otwórz konto w drugiej przeglądarce, sprawdź zachowanie po dłuższej bezczynności. Potem dopiero przejdź do technikaliów: nagłówki cookies, przekierowania HTTP→HTTPS, endpointy logowania, reset hasła, panel administratora i logi.

W praktyce problemy często pojawiają się nie w głównym formularzu logowania, tylko w dodatkowych miejscach: podglądach zamówień, linkach magic login, panelach partnerów, starych wtyczkach WordPressa albo integracjach z zewnętrznym CRM-em.

Czego nie robić?

Nie traktuj HTTPS jako jedynego zabezpieczenia sesji.
Nie trzymaj tokenów sesyjnych w localStorage, jeśli nie masz mocnego powodu.
Nie wysyłaj ciasteczek do zbyt szerokiej domeny.
Nie mieszaj sesji użytkownika z tokenami API bez jasnego modelu uprawnień.
Nie zakładaj, że framework sam naprawi złą konfigurację.

Kiedy warto zrobić audyt?

Jeśli strona ma logowanie, panel klienta, płatności, dane osobowe albo konta pracowników, warto sprawdzić sesje przed większą kampanią, migracją lub wdrożeniem nowych integracji. Ataki na sesje są niewdzięczne, bo dla użytkownika mogą wyglądać jak zwykłe logowanie z innego urządzenia.

Dobra konfiguracja sesji nie jest efektowna. Po prostu sprawia, że konto użytkownika nie zależy od szczęścia, tylko od przewidywalnych reguł bezpieczeństwa.

Źródło pomocnicze: OWASP Session Management Cheat Sheet.