błędna implementacja JWT

Błędna implementacja JWT to usterka w sposobie generowania lub weryfikacji tokenów tego standardu uwierzytelniania.

Na czym polega błędna implementacja JWT

Błędna implementacja JWT oznacza nieprawidłowe użycie tokenów JSON Web Token podczas ich tworzenia, przekazywania albo weryfikowania. JWT jest formatem zdefiniowanym w RFC 7519. Token ma zwykle trzy części zapisane jako ciągi Base64URL i rozdzielone kropkami: nagłówek, ładunek oraz podpis. Nagłówek opisuje między innymi algorytm, na przykład HS256 albo RS256, a ładunek zawiera zestaw deklaracji, takich jak iss, sub, aud, exp i iat. Samo zakodowanie danych w JWT nie zapewnia ich poufności, ponieważ standardowy token podpisany przez JWS nie jest szyfrowany.

Usterka może powstać wtedy, gdy aplikacja ufa algorytmowi odczytanemu z nagłówka bez ograniczenia go do wcześniej ustalonej listy, używa innego klucza przy generowaniu i sprawdzaniu podpisu albo akceptuje token bez poprawnej walidacji czasu ważności. Problemem jest również traktowanie dowolnego pola z ładunku jako wiarygodnego bez sprawdzenia podpisu i kontekstu żądania. W efekcie aplikacja może odrzucać prawidłowych użytkowników, przyjmować token wystawiony dla innej usługi albo utrzymywać dostęp po upływie deklarowanego terminu.

Algorytm, klucz i podpis w procesie weryfikacji

Podstawą bezpiecznej obsługi JWT jest jednoznaczne określenie algorytmu oraz sposobu przechowywania klucza. Przy algorytmach HMAC, takich jak HS256, ten sam tajny klucz służy do podpisywania i weryfikacji. Przy algorytmach RSA, takich jak RS256, podpis powstaje z użyciem klucza prywatnego, natomiast weryfikacja korzysta z odpowiadającego mu klucza publicznego. Nie można bez kontroli zamieniać tych modeli ani przyjmować klucza wskazanego przez klienta. Biblioteka powinna otrzymać konfigurację określającą dopuszczalny algorytm i właściwy materiał kryptograficzny.

Weryfikacja podpisu nie kończy całej kontroli. Należy sprawdzić między innymi exp, czyli czas wygaśnięcia, oraz w razie użycia tych pól także nbf, oznaczające najwcześniejszy moment ważności, iss, wskazujące wystawcę, i aud, określające odbiorcę tokenu. Czas powinien być interpretowany zgodnie z zasadami biblioteki i z uwzględnieniem niewielkiej, jawnie skonfigurowanej tolerancji na różnicę zegarów. Brak exp nie powinien być automatycznie traktowany jako zgoda na bezterminowy dostęp, jeżeli polityka aplikacji wymaga tokenów czasowych.

Typowe objawy w aplikacji i ślady w logach

Nieprawidłowość JWT może objawiać się komunikatem HTTP 401 Unauthorized, gdy serwer odrzuca token jako nieważny, albo kodem 403 Forbidden, gdy token został rozpoznany, lecz nie zapewnia wymaganych uprawnień. W logach mogą pojawić się informacje o niezgodnym podpisie, nieobsługiwanym algorytmie, wygasłym tokenie, nieprawidłowym wystawcy lub odbiorcy oraz tokenie użytym przed czasem nbf. Te komunikaty trzeba interpretować razem z czasem żądania, identyfikatorem sesji, adresem wywołującego i wersją konfiguracji, ponieważ podobny objaw może wynikać zarówno z błędu kodu, jak i z rozbieżności zegara lub zmiany klucza.

Warto rozdzielić etap wystawiania tokenu od etapu jego użycia. Jeżeli podpis jest poprawny, ale występuje błąd aud, problem może dotyczyć tokenu przeznaczonego dla innego odbiorcy. Jeżeli token jest odrzucany po ponownym uruchomieniu programu, należy sprawdzić sposób ładowania klucza i konfiguracji. Jeśli część żądań działa, a część kończy się błędem, możliwe jest używanie różnych instancji aplikacji z niespójnymi kluczami, algorytmami lub ustawieniami czasu. Nie należy uznawać samego odczytania ładunku za dowód autentyczności; do diagnostyki można go dekodować, ale decyzja o dostępie musi wynikać z zakończonej weryfikacji.

Bezpieczne rozpoznanie problemu na komputerze

Diagnostyka powinna rozpocząć się od ustalenia, która aplikacja wystawia token, która go sprawdza oraz jaki przepływ uwierzytelniania jest używany. Następnie porównuje się konfigurację algorytmu, źródło klucza, identyfikator wystawcy, odbiorcę i reguły dotyczące czasu. Przydatne jest prześledzenie jednego żądania od logowania do odpowiedzi chronionego endpointu, bez zapisywania pełnych tokenów w logach. Token jest poświadczeniem, dlatego do diagnostyki należy ograniczać jego ekspozycję i maskować wartość podpisu oraz wrażliwe elementy.

Na laptopie lub komputerze PC można sprawdzić, czy problem występuje wyłącznie w jednej przeglądarce, profilu użytkownika albo lokalnej instalacji programu. Trzeba też rozważyć wpływ nieprawidłowej daty i godziny systemowej, wygasłej sesji, uszkodzonego magazynu danych aplikacji oraz niezgodnej wersji biblioteki JWT. Zmiana biblioteki lub algorytmu bez przejrzenia konfiguracji może tylko ukryć przyczynę. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i podzespołów, a w przypadku problemu z aplikacją może pomóc ustalić, czy źródło objawów znajduje się w lokalnym środowisku komputera, konfiguracji programu czy w komunikacji z usługę uwierzytelniającą.