brak sprawdzania ważności tokenu

Brak sprawdzania ważności tokenu to luka bezpieczeństwa dopuszczająca korzystanie z wygasłych danych uwierzytelniających.

Na czym polega brak sprawdzania ważności tokenu

Token uwierzytelniający jest wartością, która potwierdza, że klient został wcześniej uwierzytelniony albo otrzymał określone uprawnienia. Może być przechowywany po stronie aplikacji, przekazywany w nagłówku HTTP lub zapisany w formacie zawierającym informacje o użytkowniku, czasie wystawienia i czasie wygaśnięcia. Sam fakt posiadania tokenu nie oznacza jednak, że powinien on być akceptowany bezterminowo. Serwer musi ocenić, czy token jest poprawnie podpisany, pochodzi z zaufanego źródła, jest przeznaczony dla konkretnej aplikacji oraz nadal mieści się w okresie ważności.

Brak sprawdzania ważności tokenu oznacza błąd w logice autoryzacji. Aplikacja może sprawdzać jedynie obecność tokenu albo poprawność jego formatu, pomijając pole określające termin wygaśnięcia. W rezultacie token, który powinien przestać działać po upływie określonego czasu, nadal może otwierać dostęp do zasobów. Problem może dotyczyć zarówno tokenów sesyjnych przechowywanych po stronie serwera, jak i tokenów samowystarczalnych, na przykład podpisanych tokenów zawierających znacznik czasu wygaśnięcia. W obu przypadkach kluczowe jest wykonanie kontroli po stronie serwera, ponieważ wartość przesłana przez klienta nie może być traktowana jako dowód aktualnych uprawnień.

Jak wygasły token wpływa na przepływ żądania

Typowy przepływ obejmuje wysłanie żądania do punktu końcowego aplikacji, odczyt tokenu z nagłówka lub ciasteczka, jego weryfikację, ustalenie tożsamości oraz sprawdzenie uprawnień do żądanego zasobu. Jeżeli kontrola ważności została pominięta, żądanie może przejść przez kolejne etapy wyłącznie dlatego, że token ma właściwy kształt lub podpis. Odpowiedź aplikacji może wtedy zawierać dane albo pozwalać na wykonanie operacji, mimo że czas dostępu już minął.

Skutki zależą od zakresu uprawnień zapisanych w tokenie i od tego, jak długo pozostaje on użyteczny. Wygasła sesja może nadal pozwalać na odczyt profilu, dostęp do historii operacji lub używanie funkcji dostępnych po zalogowaniu. Jeżeli token zawiera uprawnienia do zmiany danych, problem może również obejmować operacje modyfikujące. Szczególne znaczenie ma sytuacja, w której token został skopiowany z pamięci przeglądarki, pliku konfiguracyjnego, historii żądań albo logów diagnostycznych. Pominięcie kontroli terminu wygaśnięcia wydłuża wtedy okres, w którym przejęta wartość może być wykorzystana.

Nie należy utożsamiać sprawdzania podpisu ze sprawdzaniem ważności. Podpis potwierdza integralność tokenu i pozwala wykryć jego zmianę, ale sam w sobie nie musi oznaczać, że token jest nadal aktualny. Osobne kontrole mogą obejmować czas wygaśnięcia, czas rozpoczęcia obowiązywania, identyfikator wystawcy, odbiorcę tokenu oraz unieważnienie konkretnej sesji. Brak którejkolwiek z tych kontroli może powodować inną klasę błędu, dlatego analiza wymaga ustalenia, jakie dokładnie warunki akceptuje aplikacja.

Rozpoznawanie problemu w działającej aplikacji

Weryfikację należy rozpocząć od odtworzenia pełnego cyklu życia tokenu: jego wystawienia, przekazania klientowi, użycia w żądaniu, odświeżenia oraz wygaśnięcia. W bezpiecznym scenariuszu żądanie wykonane po terminie powinno otrzymać odpowiedź odmowną, zwykle z kodem HTTP 401, gdy brak jest aktualnego uwierzytelnienia. Kod 403 może być używany wtedy, gdy tożsamość została rozpoznana, lecz nie ma wymaganych uprawnień. Sam kod odpowiedzi nie rozstrzyga jednak przyczyny; trzeba sprawdzić zachowanie endpointu i decyzję podjętą przez warstwę autoryzacji.

W testach można użyć tokenu, którego ważność została celowo ustawiona na krótki okres, a następnie powtórzyć identyczne żądanie po jego wygaśnięciu. Wynik należy porównać z żądaniem wykonanym przed upływem terminu. W przypadku tokenu zawierającego informacje o czasie nie wolno modyfikować jego treści i oczekiwać, że taki test zachowa poprawność podpisu. Należy korzystać z kontrolowanego środowiska testowego oraz obserwować, czy aplikacja odrzuca token na podstawie czasu, a nie tylko na podstawie składni lub podpisu.

Przy diagnozie warto prześledzić middleware uwierzytelniający, bibliotekę obsługującą tokeny, konfigurację czasu życia sesji i mechanizm odświeżania. Należy sprawdzić, czy zegar systemowy działa poprawnie, ponieważ duża różnica czasu między klientem a serwerem może powodować przedwczesne odrzucanie albo nieprawidłowe akceptowanie tokenów. Trzeba także zweryfikować, czy wszystkie ścieżki korzystają z tej samej kontroli. Częstym problemem logicznym jest poprawna walidacja w głównym endpointcie i pominięcie jej w pomocniczej trasie, alternatywnej wersji API albo funkcji obsługującej odświeżanie sesji.

Naprawa kontroli czasu życia i sesji

Naprawa polega na wymuszeniu serwerowej walidacji ważności przed wykonaniem operacji chronionej. Kontrola powinna obejmować co najmniej termin wygaśnięcia, jeśli taki mechanizm został przewidziany, oraz spójne odrzucanie tokenów nieaktualnych, uszkodzonych, przeznaczonych dla innego odbiorcy albo wystawionych przez nieznane źródło. W przypadku sesji przechowywanych po stronie serwera trzeba dodatkowo sprawdzić, czy rekord sesji nadal istnieje, nie został unieważniony i nie przekroczył skonfigurowanego czasu bezczynności lub maksymalnego czasu życia.

Po wdrożeniu poprawki testy powinny obejmować token przed wygaśnięciem, dokładnie po terminie, znacznie po terminie, po wylogowaniu oraz po próbie użycia na innym chronionym zasobie. Warto sprawdzić także odświeżanie tokenu, ponieważ mechanizm odświeżania nie powinien bez kontroli wydawać nowego dostępu na podstawie nieważnego albo unieważnionego tokenu. Logi diagnostyczne powinny rejestrować typ odrzucenia i identyfikator żądania, ale nie pełną wartość tokenu. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, w tym diagnostyką problemów z oprogramowaniem oraz konfiguracją systemów używanych na tych urządzeniach.