brak revokacji tokenów po wylogowaniu

Brak revokacji tokenów po wylogowaniu to luka bezpieczeństwa pozostawiająca dane uwierzytelniające ważne mimo zakończenia sesji.

Brak revokacji tokenów po wylogowaniu – czym jest ten problem

Brak revokacji tokenów po wylogowaniu oznacza sytuację, w której token uwierzytelniający nadal może być używany po zakończeniu pracy użytkownika. Samo kliknięcie przycisku „Wyloguj” nie zawsze powoduje unieważnienie wszystkich danych sesyjnych. Jeżeli aplikacja wydaje token dostępu, token odświeżania albo ciasteczko sesyjne, każde z tych poświadczeń powinno mieć jasno określony cykl życia. W przeciwnym razie osoba, która wcześniej uzyskała token, może nadal próbować korzystać z konta, mimo że użytkownik zakończył sesję.

Token jest ciągiem danych potwierdzającym, że klient został wcześniej uwierzytelniony. Może być przekazywany w nagłówku żądania, przechowywany w ciasteczku albo obsługiwany przez mechanizm aplikacji mobilnej. Wylogowanie powinno zmienić stan po stronie serwera w taki sposób, aby dalsze użycie tokenu nie było akceptowane. Samo usunięcie tokenu z przeglądarki nie wystarcza, jeżeli jego kopia znajduje się w historii, pamięci aplikacji, logach pośrednich, rozszerzeniu przeglądarki albo na urządzeniu, do którego dostęp uzyskała niepowołana osoba.

Problem może występować zarówno w aplikacjach internetowych, jak i w programach działających lokalnie, systemach obsługi kont, panelach administracyjnych oraz usługach korzystających z kilku niezależnych interfejsów. Szczególne znaczenie ma to przy dostępie do poczty, dokumentów, danych klientów, ustawień konta i funkcji pozwalających na zmianę kolejnych danych uwierzytelniających.

Revokacja tokenów po wylogowaniu na tle innych metod sesji

W klasycznej sesji serwerowej identyfikator sesji jest przechowywany po stronie serwera. Po wylogowaniu można usunąć powiązany wpis lub oznaczyć go jako nieważny. W modelu opartym na tokenach bezstanowych serwer często sprawdza podpis, termin ważności i podstawowe atrybuty tokenu, ale nie przechowuje jego bieżącego statusu. Taki model upraszcza obsługę wielu instancji aplikacji, jednak utrudnia natychmiastowe unieważnienie poświadczenia.

Nie powinno się utożsamiać wygaśnięcia tokenu z jego revokacją. Wygaśnięcie następuje po upływie ustalonego czasu, natomiast revokacja jest świadomą decyzją o odebraniu ważności wcześniej wydanemu poświadczeniu. Token może więc być formalnie poprawny i mieścić się w swoim okresie ważności, a mimo to powinien zostać odrzucony, ponieważ użytkownik się wylogował, zmienił hasło, zgłosił utratę urządzenia albo administrator wykrył podejrzaną aktywność.

Ważne jest również odróżnienie tokenu dostępu od tokenu odświeżania. Krótkotrwały token dostępu ogranicza czas wykorzystania pojedynczego poświadczenia, ale nie rozwiązuje problemu, jeżeli długotrwały token odświeżania nadal pozwala uzyskać następne tokeny. Bezpieczniejszy model obejmuje rotację tokenów odświeżania, zapisywanie ich identyfikatorów po stronie serwera oraz unieważnianie całego łańcucha po wylogowaniu lub wykryciu ponownego użycia.

W praktyce spotyka się także listy odwołanych identyfikatorów, wersjonowanie sesji, centralny rejestr aktywnych sesji oraz krótkie okresy ważności połączone z ponownym uwierzytelnieniem. Każda metoda ma swoje ograniczenia. Lista odwołanych tokenów wymaga ochrony i sprawnego czyszczenia, wersja sesji wymaga sprawdzania jej przy każdym żądaniu, a krótki czas ważności może pogorszyć wygodę użytkowania. Rozwiązanie powinno odpowiadać wartości chronionych danych oraz sposobowi działania aplikacji.

Typowe objawy braku revokacji tokenów

Pierwszym objawem może być możliwość otwarcia chronionego panelu w starej karcie przeglądarki po wylogowaniu z innej karty. Podobny sygnał pojawia się wtedy, gdy wcześniej skopiowany adres API nadal zwraca dane po zakończeniu sesji. W aplikacji mobilnej symptomem bywa działanie funkcji synchronizacji po usunięciu konta z urządzenia albo dostęp do danych po zmianie hasła na innym urządzeniu.

• Stary token nadal pozwala pobierać dane użytkownika.
• Token odświeżania wydaje nowe tokeny po wylogowaniu.
• Wylogowanie z jednego urządzenia nie kończy sesji na urządzeniach pozostałych.
• Zmiana hasła nie powoduje unieważnienia wcześniejszych poświadczeń.
• Usunięcie ciasteczka lokalnego nie wpływa na stan sesji po stronie serwera.
• Żądania z wcześniejszego urządzenia są akceptowane mimo ręcznego zakończenia sesji.

Nie każdy taki objaw musi oznaczać identyczną usterkę. Czasem przyczyną jest opóźnione odświeżenie interfejsu, pamięć podręczna albo działanie usługi pośredniczącej. Weryfikacja powinna jednak obejmować rzeczywiste żądania do serwera, odpowiedzi, nagłówki, identyfikatory sesji i zachowanie po ponownym uruchomieniu aplikacji. Sam wygląd ekranu logowania nie daje pewności, że poświadczenie zostało wycofane.

Ryzyko rośnie, gdy token jest przechowywany w miejscu dostępnym dla wielu procesów, przekazywany w adresie strony, utrwalany w logach lub używany bez ochrony przed przechwyceniem. Niebezpieczne bywa także pozostawianie długiej ważności przy braku mechanizmu centralnego unieważniania. W takim układzie zgubione urządzenie albo skopiowany token może zachować znaczenie długo po świadomym zakończeniu pracy.

Praktyczne wskazówki dotyczące tokenów po wylogowaniu

Najpierw należy ustalić, jakie rodzaje tokenów są wydawane i gdzie są przechowywane. Warto rozdzielić token dostępu, token odświeżania, ciasteczko sesyjne, token jednorazowy oraz poświadczenia używane przez zadania działające w tle. Dla każdego rodzaju powinny zostać opisane: odbiorca, zakres uprawnień, czas ważności, sposób rotacji, warunek unieważnienia i zachowanie po zmianie hasła.

Wylogowanie powinno wywoływać operację po stronie serwera, a nie tylko usuwać lokalny wpis. Serwer może usunąć sesję, oznaczyć identyfikator tokenu jako odwołany, zwiększyć wersję sesji lub unieważnić cały zestaw tokenów przypisanych do urządzenia. W przypadku tokenów odświeżania należy rozważyć rotację przy każdym użyciu. Ponowne użycie już wykorzystanego tokenu powinno być traktowane jako sygnał możliwego przejęcia i prowadzić do unieważnienia powiązanego łańcucha.

Warto ograniczać zakres uprawnień tokenu do minimum potrzebnego dla konkretnej funkcji. Token przeznaczony do odczytu nie powinien umożliwiać zmiany hasła, danych kontaktowych ani ustawień bezpieczeństwa. Operacje szczególnie wrażliwe mogą wymagać ponownego uwierzytelnienia, dodatkowego składnika lub potwierdzenia niezależnym kanałem.

Testy powinny obejmować co najmniej kilka scenariuszy: wylogowanie w jednej karcie i użycie starego tokenu w drugiej, wylogowanie na jednym urządzeniu i próbę dostępu z innego, zmianę hasła przy aktywnej sesji, wycofanie dostępu administratora, ponowne użycie tokenu odświeżania oraz próbę korzystania z tokenu po restarcie aplikacji. Sprawdza się nie tylko kod odpowiedzi, lecz także to, czy nie są zwracane częściowe dane, metadane lub informacje ujawniające istnienie zasobu.

W systemie powinno się rejestrować zdarzenia logowania, wylogowania, odświeżenia i unieważnienia tokenu, przy czym nie należy zapisywać pełnych tokenów w logach. Przydatne są skrócone identyfikatory, czas zdarzenia, źródło żądania, urządzenie oraz wynik operacji. Monitoring pozwala wykryć sytuację, w której po wylogowaniu pojawiają się kolejne żądania z użyciem tego samego poświadczenia.

Kiedy zgłosić brak revokacji tokenów do serwisu

Do serwisu warto zgłosić problem, gdy po wylogowaniu nadal można otworzyć chronione dane, gdy urządzenie zostało zgubione albo gdy zmiana hasła nie kończy wcześniejszych sesji. Pomoc techniczna może obejmować sprawdzenie ustawień przeglądarki, aplikacji, magazynu ciasteczek, zapisanych danych logowania i komunikacji z usługą uwierzytelniającą. W przypadku sprzętu używanego do dostępu do ważnych kont należy również zweryfikować aktualizacje, ochronę przed złośliwym oprogramowaniem i nieznane rozszerzenia.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się analizą problemów z laptopami i komputerami PC, w tym sytuacji, w których po zakończeniu sesji urządzenie nadal zachowuje dostęp do konta. Przed przekazaniem sprzętu nie powinno się podawać pełnych haseł ani wysyłać aktywnych tokenów. Bezpieczniej jest wylogować wszystkie konta, unieważnić sesje z poziomu zaufanego urządzenia i przygotować opis kolejnych działań, po których problem występuje.

Jeżeli nie ma pewności, czy wylogowanie rzeczywiście odebrało dostęp, należy potraktować token jak ujawnione poświadczenie. Zalecane jest zakończenie wszystkich sesji, zmiana hasła, włączenie dodatkowego składnika uwierzytelniania oraz sprawdzenie listy urządzeń i ostatnich aktywności. Następnie można powtórzyć test na czystej sesji przeglądarki i zweryfikować, czy wcześniejsze żądania są odrzucane. Takie działanie ogranicza skutki usterki i ułatwia ustalenie, czy problem dotyczy samego urządzenia, aplikacji, czy mechanizmu obsługi sesji po stronie usługi.