brak systemu rotacji tokenów

Brak systemu rotacji tokenów to luka bezpieczeństwa dopuszczająca długotrwałe utrzymywanie tych samych danych uwierzytelniających.

Brak systemu rotacji tokenów — czym jest ten problem

Brak systemu rotacji tokenów oznacza sytuację, w której token uwierzytelniający pozostaje ważny przez zbyt długi czas albo nie jest wymieniany w przewidzianych momentach. Token jest ciągiem danych rozpoznawanym przez aplikację jako potwierdzenie wcześniejszego uwierzytelnienia. Po zalogowaniu nie zawsze trzeba ponownie wpisywać hasło, ponieważ przeglądarka lub aplikacja przekazuje token przy kolejnych żądaniach. Jeżeli taki token nie ma sprawnego mechanizmu odświeżania, unieważniania i zastępowania nowym, przejęcie jednej sesji może wywołać skutki utrzymujące się długo po pierwotnym zdarzeniu.

Nie chodzi wyłącznie o brak automatycznej zmiany pojedynczego ciągu znaków. Prawidłowa rotacja tokenów obejmuje cały cykl życia sesji: utworzenie tokenu, jego bezpieczne przekazanie, przechowywanie, używanie, odświeżenie, wycofanie oraz usunięcie po zakończeniu pracy. W zależności od zastosowanego rozwiązania mogą występować tokeny dostępu, tokeny odświeżające, identyfikatory sesji, klucze tymczasowe oraz tokeny używane przy potwierdzaniu dodatkowego etapu logowania. Każdy z tych elementów powinien mieć określony zakres uprawnień, czas ważności i sposób unieważnienia.

W praktyce podatność może pozostać niezauważona, ponieważ system działa poprawnie z punktu widzenia zwykłego użytkownika. Logowanie przebiega bez błędu, aplikacja odpowiada, a dostęp do danych jest utrzymany. Problem ujawnia się dopiero wtedy, gdy token zostanie skopiowany z pamięci urządzenia, pliku cookie, dziennika zdarzeń, historii przeglądarki, niechronionego magazynu aplikacji albo przechwyconego kanału komunikacji. Sam fakt poprawnego logowania nie świadczy więc o tym, że sesja jest odpowiednio zabezpieczona.

Brak rotacji tokenów a kontekst techniczny i porównania

W bezpieczniejszym modelu token dostępu działa przez ograniczony czas, a dalsze korzystanie z aplikacji wymaga uzyskania kolejnego tokenu. Przy wymianie można sprawdzić ważność dotychczasowych danych, ograniczyć zakres dostępu i oznaczyć poprzedni token jako wykorzystany albo nieważny. Dzięki temu przejęcie tokenu nie musi oznaczać stałego dostępu. Jeżeli rotacja nie występuje, ten sam token bywa używany wielokrotnie przez wiele dni, tygodni lub do momentu ręcznego wylogowania. Wówczas długie okno czasowe zwiększa prawdopodobieństwo wykorzystania skopiowanych danych.

Warto odróżnić brak rotacji od długiego czasu ważności. Są to problemy powiązane, ale nieidentyczne. Token może mieć relatywnie krótki termin ważności, a mimo to nie być wymieniany po ważnych zdarzeniach, takich jak zmiana hasła, podniesienie uprawnień czy ponowne uwierzytelnienie. Z drugiej strony token może być regularnie odświeżany, ale procedura odświeżania może nie unieważniać starej wersji. Ocena bezpieczeństwa powinna zatem uwzględniać zarówno czas życia tokenu, jak i zasady jego zastępowania.

Przydatne jest porównanie trzech scenariuszy:

• Token stały: raz wydany token jest używany aż do ręcznego wylogowania albo do administracyjnego usunięcia sesji. To wariant o wysokim ryzyku przy wycieku.
• Token wygasający bez rotacji: token traci ważność po określonym czasie, lecz w okresie aktywności pozostaje niezmienny. Ryzyko jest mniejsze niż przy tokenie stałym, ale nadal zależy od długości okresu ważności.
• Token rotowany: po odświeżeniu wydawany jest nowy token, a poprzedni zostaje ograniczony lub unieważniony. Dodatkowe reguły mogą wykrywać ponowne użycie starej wersji i zamykać całą sesję.

Wymiana tokenu nie zastępuje szyfrowania, ochrony haseł ani kontroli uprawnień. Jeżeli token jest przechowywany w miejscu dostępnym dla nieuprawnionego kodu, sama rotacja nie rozwiąże problemu. Potrzebne są również bezpieczne atrybuty ciasteczek, ochrona przed skryptami odczytującymi dane sesyjne, sprawdzanie pochodzenia żądań oraz ograniczenie dostępu do danych zgodnie z zasadą najmniejszych uprawnień.

Brak systemu rotacji tokenów — typowe problemy i skutki

Najczęstszym skutkiem jest utrzymanie aktywnego dostępu po przejęciu tokenu. Osoba posiadająca taki token może nie potrzebować hasła, kodu jednorazowego ani ponownego potwierdzenia tożsamości. Zakres możliwych działań zależy od uprawnień przypisanych do sesji. W niektórych przypadkach dostęp ogranicza się do odczytu danych, w innych pozwala także na zmianę ustawień, dodawanie kolejnych urządzeń, pobieranie dokumentów lub wykonywanie operacji w imieniu użytkownika.

Ryzyko rośnie, gdy token nie jest zmieniany po zdarzeniach związanych z bezpieczeństwem. Zmiana hasła może wtedy nie zakończyć wcześniejszych sesji. Usunięcie urządzenia z listy zaufanych może nie odebrać dostępu już wydanemu tokenowi. Zmiana roli użytkownika może nie zostać odzwierciedlona w aktywnej sesji. W rezultacie odebranie uprawnień jest pozorne, ponieważ poprzedni token nadal jest akceptowany przez aplikację.

Problem może dotyczyć także procesów automatycznych. Token zapisany w skrypcie, narzędziu synchronizacyjnym albo konfiguracji programu bywa kopiowany do wielu miejsc. Gdy nie ma kontrolowanej rotacji, jedna omyłkowo ujawniona wartość może pozostać aktywna mimo usunięcia pliku źródłowego. Dodatkowym utrudnieniem jest brak centralnej informacji o tym, gdzie token został użyty oraz czy korzysta z niego użytkownik, urządzenie czy aplikacja.

Trudności sprawia również wykrywanie nadużycia. Sam token może wyglądać jak zwykły ciąg znaków, a logowanie z jego użyciem nie musi generować komunikatu o błędnym haśle. W dziennikach powinny być rejestrowane między innymi: identyfikator sesji, czas użycia, źródło żądania, zmiana tokenu, próba użycia unieważnionej wartości oraz nietypowe przejście między urządzeniami. Brak takich informacji utrudnia ustalenie, czy token został skopiowany, kiedy doszło do użycia i jakie działania wykonano.

W systemach użytkowanych na wielu urządzeniach może powstać dodatkowy problem z zarządzaniem sesjami. Jedno wylogowanie powinno mieć jasno określony zakres: może zamykać tylko bieżące urządzenie albo wszystkie aktywne sesje. Bez spójnej polityki użytkownik nie wie, czy wylogowanie rzeczywiście odebrało dostęp wcześniej wydanym tokenom. Z perspektywy ochrony danych bezpieczniejsze jest zapewnienie możliwości przeglądania aktywnych sesji i ich selektywnego unieważniania.

Brak rotacji tokenów — praktyczne wskazówki diagnostyczne

Ocena problemu powinna rozpocząć się od ustalenia, jakie tokeny występują w danym rozwiązaniu i za co odpowiada każdy z nich. Należy sprawdzić, czy token dostępu jest oddzielony od tokenu odświeżającego, gdzie są przechowywane oba elementy, jaki jest ich okres ważności oraz jakie zdarzenia powodują unieważnienie. Warto również ustalić, czy token jest przypisany do konkretnego urządzenia, aplikacji lub sesji, czy może być używany z dowolnego miejsca.

Podczas testów należy przeprowadzić kontrolowaną próbę użycia starego tokenu po odświeżeniu sesji. Jeżeli poprzednia wartość nadal daje taki sam dostęp, rotacja może być tylko pozorna. Kolejnym sprawdzeniem jest zmiana hasła, wylogowanie, odebranie urządzenia oraz zmiana poziomu uprawnień. Po każdym z tych zdarzeń powinno być możliwe jednoznaczne stwierdzenie, które tokeny pozostają ważne. Testy trzeba wykonywać na środowisku przeznaczonym do takich działań, z zachowaniem kopii konfiguracji i bez wykorzystywania cudzych danych.

W konfiguracji warto zastosować zasadę ograniczonego zaufania do każdej wartości sesyjnej. Token powinien być nieprzewidywalny, przechowywany w sposób ograniczający dostęp skryptów i nieumieszczany w adresach stron, logach ani komunikatach diagnostycznych. Mechanizm odświeżania powinien wykrywać ponowne użycie wycofanego tokenu, a w razie podejrzenia przejęcia umożliwiać zamknięcie powiązanej sesji. Wskazane jest także rozdzielenie tokenów dla różnych celów, aby naruszenie jednego procesu nie zapewniało dostępu do wszystkich funkcji.

Przydatne jest utrzymywanie krótkiej dokumentacji obejmującej źródło tokenu, jego odbiorcę, zakres uprawnień, sposób odświeżania, reguły unieważnienia i procedurę awaryjnej wymiany. Należy unikać sytuacji, w której tylko jedna osoba zna sposób ręcznego wycofania tokenu. Procedura powinna być możliwa do wykonania po utracie urządzenia, podejrzeniu wycieku, zmianie hasła oraz zakończeniu współpracy z użytkownikiem lub dostawcą.

Kiedy zgłosić brak systemu rotacji tokenów do serwisu

Zgłoszenie jest uzasadnione, gdy sesja pozostaje aktywna mimo wylogowania, stary token nadal działa po zmianie hasła albo w ustawieniach programu znaleziono dane wyglądające na klucz sesyjny. Wskazaniem może być także nietypowe pojawienie się aktywnej sesji, powiadomienie o logowaniu z nieznanego urządzenia, nieoczekiwane zmiany konfiguracji lub obecność tokenu w pliku, do którego dostęp mają inne osoby. W razie podejrzenia przejęcia należy najpierw odłączyć zagrożone urządzenie od sieci, nie usuwać pochopnie dowodów i zmienić dane dostępowe z bezpiecznego urządzenia.

Przed przekazaniem sprzętu lub dokumentacji warto przygotować opis objawów, czas zauważenia problemu, używany program oraz wykonane działania. Nie należy przesyłać pełnych tokenów w wiadomości ani umieszczać ich w publicznym zgłoszeniu. Jeżeli pokazanie konfiguracji jest konieczne, powinny zostać zamaskowane wartości uwierzytelniające, identyfikatory użytkowników i inne dane pozwalające na dostęp.

W sprawach związanych z bezpieczeństwem sprzętu i oprogramowania można skorzystać z pomocy Warszawskiego Pogotowia Komputerowego 24/7, gdzie analizuje się objawy, ustawienia aplikacji oraz sposób przechowywania danych sesyjnych. Po sprawdzeniu możliwe jest wskazanie, czy problem dotyczy samego urządzenia, programu, konfiguracji konta czy procedury wylogowania. W przypadku potwierdzenia ryzyka zalecane jest przeprowadzenie kontrolowanej wymiany tokenów, przegląd aktywnych sesji i uporządkowanie zasad dostępu.