token sesyjny

Token sesyjny to wartość, którą aplikacja wydaje po zalogowaniu i którą przeglądarka dołącza do kolejnych żądań zamiast hasła. OWASP opisuje identyfikator albo token sesji jako parę nazwa=wartość, przypisaną przy tworzeniu sesji i wymienianą przez cały czas interakcji użytkownika z aplikacją, na potrzeby uwierzytelniania i kontroli dostępu ^[1]. Kto ma token, ten dla serwera jest zalogowanym użytkownikiem. Dlatego jego kradzież pozwala przejąć konto bez znajomości hasła.

Jak działa

Protokół HTTP nie pamięta, kto wysłał poprzednie żądanie. Po poprawnym logowaniu serwer tworzy więc sesję, generuje losowy token i odsyła go przeglądarce, najczęściej w ciasteczku. Każde następne żądanie niesie ten token, a serwer sprawdza, czy pasuje do aktywnej sesji.

RYS. 1Życie tokenu sesyjnego

Z przebiegu na schemacie wynika najważniejsza cecha tokenu: hasło i drugi składnik sprawdzane są tylko raz, na początku. Później liczy się wyłącznie token. Serwer nie wie, czy żądanie wysłała przeglądarka właściciela, czy ktoś, kto skopiował ciasteczko na inny komputer. Dlatego ochrona tokenu jest tak samo ważna jak ochrona hasła, a czas jego ważności wyznacza, jak długo skradziona wartość pozostaje użyteczna.

Siła tokenu zależy od tego, czy da się go odgadnąć. OWASP wymaga co najmniej 64 bitów entropii w identyfikatorze sesji, co przy zapisie szesnastkowym oznacza minimum 16 znaków ^[1].

Odmiany

Tokeny różnią się tym, gdzie leży stan sesji i jak są przenoszone.

W WordPressie

WordPress po zalogowaniu ustawia ciasteczka uwierzytelniające funkcją wp_set_auth_cookie(). Są to AUTH_COOKIE albo SECURE_AUTH_COOKIE, zależnie od HTTPS, oraz LOGGED_IN_COOKIE ^[5]. Wszystkie dostają flagę HttpOnly ^[5]. Bez zaznaczenia „Zapamiętaj mnie” ciasteczko wygasa po 2 dniach albo z zamknięciem przeglądarki, a z zaznaczeniem po 14 dniach; czas można zmienić filtrem auth_cookie_expiration ^[5].

Od wersji 4.0 w ciasteczku siedzi też token sesji zarządzany przez klasę WP_Session_Tokens ^[4]. Token jest losowy i przed zapisem w bazie haszowany algorytmem SHA-256; razem z nim zapisywane są czas wygaśnięcia, adres IP, przeglądarka i moment logowania ^[4]. Klasa pozwala zniszczyć wszystkie sesje użytkownika oprócz bieżącej albo wszystkie bez wyjątku ^[4]. Pozwala też pobrać listę wszystkich sesji danego konta ^[4], a zapisane przy sesji dane pozwalają pokazać, z jakich adresów i przeglądarek ktoś jest zalogowany.

Haszowanie tokenu ma praktyczny sens. W bazie leży tylko skrót, a nie sam token, więc odczyt tabeli metadanych użytkowników nie daje od razu gotowego ciasteczka do podstawienia. Weryfikacja sprawdza przy każdym żądaniu, czy token istnieje i czy nie wygasł ^[4]. Usunięcie wpisu sesji z bazy natychmiast odbiera ciasteczku ważność, nawet jeśli w przeglądarce jeszcze nie wygasło.

Ciasteczka podpisywane są kluczami z pliku wp-config.php, czyli kluczami bezpieczeństwa i solami. Dokumentacja WordPressa podaje, że ich zmiana w dowolnym momencie unieważnia wszystkie istniejące ciasteczka, a użytkownicy muszą zalogować się ponownie ^[6]. To najprostszy sposób, by po incydencie wylogować wszystkich naraz.

// wylogowanie z pozostałych urządzeń bieżącego użytkownika
wp_destroy_other_sessions();

Zagrożenia i skutki

Skradziony token działa jak klucz do otwartej już sesji. Włączone uwierzytelnianie wieloskładnikowe (MFA) nie pomaga, bo drugi składnik sprawdzono przy logowaniu, a nie przy każdym żądaniu ^[7].

• Przejęcie sesji (session hijacking) przez XSS (Cross-Site Scripting): skrypt czyta ciasteczko, jeśli nie ma ono flagi HttpOnly ^[1].
• Kradzież plików cookie z przeglądarki przez infostealer na komputerze administratora.
• phishing AiTM (adversary-in-the-middle), w którym fałszywa strona pośredniczy w logowaniu i przechwytuje wydany token.
• session fixation: napastnik podsuwa ofierze znany sobie identyfikator. MITRE opisuje błąd jako uwierzytelnienie użytkownika bez unieważnienia istniejącego identyfikatora sesji ^[2].
• Zbyt długie sesje. CWE-613 to sytuacja, w której witryna pozwala ponownie użyć starych danych sesji albo identyfikatorów ^[3].

Jak się bronić

OWASP zaleca kilka zasad, które łatwo sprawdzić w każdej aplikacji ^[1]:

• Flagi ciasteczek (cookie security attributes): HttpOnly blokuje dostęp skryptów, Secure wymusza przesyłanie tylko przez HTTPS, a SameSite=Strict ogranicza CSRF (Cross-Site Request Forgery) ^[1].
• Nowy identyfikator po zalogowaniu i po każdej zmianie poziomu uprawnień ^[1]. MITRE zaleca unieważnić istniejące identyfikatory przed autoryzacją nowej sesji ^[2].
• Limity czasu: bezczynności od 2 do 5 minut dla aplikacji wysokiego ryzyka i od 15 do 30 minut dla pozostałych, bezwzględny od 4 do 8 godzin przy całodziennej pracy ^[1].
• Wylogowanie unieważnia sesję na serwerze, a nie tylko usuwa ciasteczko w przeglądarce ^[1].
• Cały ruch przez TLS, aby token nie wyciekł w sieci.

W WordPressie oznacza to HTTPS w całym panelu, krótszy czas „Zapamiętaj mnie” dla kont administratorów i zmianę kluczy w wp-config.php po podejrzeniu włamania ^[6].

Historia i przykłady

28 września 2018 roku Facebook poinformował o ataku, w którym błąd funkcji „Wyświetl jako” pozwalał kraść tokeny sesyjne i przejmować cudze konta ^[7]. Dotyczyło to 50 milionów kont ^[7]. Serwis zresetował tokeny 90 milionom użytkowników: 50 milionom poszkodowanych i zapobiegawczo 40 milionom, których profile oglądano tą funkcją w ostatnim roku ^[7]. Niebezpiecznik zwrócił uwagę, że dwuetapowe uwierzytelnienie nie chroni przed dostępem do konta w razie wycieku tokenu sesyjnego ^[7].