brak weryfikacji podpisu JWT

Brak weryfikacji podpisu JWT to luka bezpieczeństwa dopuszczająca akceptację tokenów bez potwierdzenia ich integralności.

Na czym polega brak weryfikacji podpisu JWT

JSON Web Token (JWT) jest strukturą służącą do przenoszenia oświadczeń o użytkowniku, sesji albo uprawnieniach. Typowy token składa się z trzech części zapisanych w formacie Base64URL i rozdzielonych kropkami: nagłówka, treści oraz podpisu. Nagłówek określa między innymi typ tokenu i algorytm, treść zawiera oświadczenia, a podpis ma umożliwić sprawdzenie, czy token został utworzony przez zaufaną stronę i nie zmieniono jego zawartości po wystawieniu.

Brak weryfikacji podpisu JWT występuje wtedy, gdy aplikacja odczytuje dane z tokenu i podejmuje decyzję o uwierzytelnieniu lub uprawnieniach bez poprawnego sprawdzenia części podpisowej. Sam fakt, że token ma prawidłową składnię i daje się zdekodować, nie potwierdza jego autentyczności. Zawartość nagłówka i treści JWT nie jest tajna, ponieważ kodowanie Base64URL nie jest szyfrowaniem. Użytkownik może odczytać te fragmenty, a osoba atakująca może również przygotować ich zmodyfikowaną wersję.

Jak podpis potwierdza integralność tokenu

Podpis JWT jest obliczany na podstawie zakodowanego nagłówka i zakodowanej treści. W zależności od zastosowanego algorytmu używany jest klucz tajny, jak w HMAC, albo para kluczy kryptograficznych, jak w algorytmach RSA i ECDSA. Podczas weryfikacji odbiorca powinien ustalić dozwolony algorytm, wybrać właściwy klucz oraz ponownie sprawdzić podpis dla dokładnie tych danych, które otrzymał. Zmiana nawet jednego znaku w nagłówku lub treści powinna spowodować odrzucenie tokenu.

Niebezpieczna implementacja może zaufać wartości alg w nagłówku bez ograniczenia jej do wcześniej ustalonej listy albo dopuścić wariant bez podpisu oznaczany jako algorytm „none”. Może też użyć niewłaściwego typu klucza, zaakceptować pusty lub nieobecny podpis albo potraktować błąd biblioteki jako sytuację pomyślnej autoryzacji. Bezpieczna biblioteka i prawidłowa konfiguracja powinny wymuszać konkretny algorytm, konkretny klucz oraz jednoznaczną reakcję na każdą nieudaną próbę weryfikacji.

Weryfikacja kryptograficzna nie zastępuje kontroli pozostałych parametrów. Po potwierdzeniu podpisu aplikacja powinna sprawdzić między innymi czas ważności exp, czas rozpoczęcia obowiązywania nbf, wystawcę iss oraz odbiorcę aud, jeśli te oświadczenia są wymagane w danym przepływie. Należy także sprawdzić, czy identyfikator tokenu jti nie został unieważniony, gdy system stosuje mechanizm odwoływania tokenów. Odczytanie wartości sub nie jest wystarczającym dowodem tożsamości.

Skutki zaakceptowania zmienionego tokenu

Jeżeli aplikacja nie sprawdza podpisu, modyfikacja oświadczeń może prowadzić do uznania osoby nieuprawnionej za zalogowanego użytkownika. Atakujący może zmienić identyfikator podmiotu w sub, dodać uprawnienie administracyjne w polu roles albo wydłużyć czas ważności exp. Skala skutków zależy od tego, jakie decyzje podejmuje aplikacja na podstawie tokenu. W prostym przypadku może dojść do przejęcia sesji, a w bardziej rozbudowanym przepływie do dostępu do funkcji, których użytkownik nie powinien widzieć.

Podobny problem powstaje, gdy podpis jest technicznie sprawdzany, lecz klucz pobierany jest z niezaufanego miejsca albo wybierany na podstawie niezweryfikowanych danych z tokenu. Ochrona wymaga rozdzielenia danych kontrolowanych przez klienta od konfiguracji zaufanej po stronie serwera. Klucze powinny być dobierane z ustalonego magazynu lub zaufanego zestawu kluczy, a identyfikator kid z nagłówka może służyć wyłącznie do wyboru spośród wcześniej zaakceptowanych wartości. Nie wolno traktować samego kid, iss ani innych pól jako dowodu autentyczności.

Podczas analizy problemu warto sprawdzić, czy wszystkie ścieżki żądań korzystają z tego samego mechanizmu kontroli. Błąd może występować tylko w jednym endpointcie, middleware, module odświeżania tokenu albo funkcji obsługującej token zapisany w ciasteczku. Należy porównać zachowanie dla prawidłowego tokenu, tokenu z uszkodzonym podpisem, tokenu ze zmienionym algorytmem oraz tokenu z wygasłym exp. Każdy z tych przypadków powinien kończyć się odmową dostępu, a log nie powinien ujawniać pełnej wartości tokenu ani klucza.

Rozpoznanie problemu na laptopie i komputerze PC

Na laptopie lub komputerze stacjonarnym objawem nie musi być awaria sprzętowa. Problem może ujawnić się jako nieprawidłowe działanie aplikacji korzystającej z logowania internetowego: konto uzyskuje dostęp mimo nieważnej sesji, aplikacja nie wylogowuje użytkownika po wygaśnięciu tokenu albo po aktualizacji biblioteki pojawiają się błędy uwierzytelniania. Diagnostyka powinna obejmować wersję aplikacji, konfigurację biblioteki JWT, źródło klucza publicznego lub tajnego oraz sposób obsługi wyjątków. Nie należy testować podatności na cudzych kontach ani modyfikować tokenów w działającym systemie bez upoważnienia.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną diagnostykę i naprawę laptopów oraz komputerów PC, w tym problemów z konfiguracją oprogramowania użytkowego, logowaniem i bezpieczeństwem aplikacji uruchamianych na tych urządzeniach. W ramach analizy można ustalić, czy przyczyną jest lokalna konfiguracja, nieaktualna biblioteka, błędna synchronizacja czasu systemowego lub problem po stronie usługi, a następnie przekazać wynik wraz z zaleceniami dotyczącymi bezpiecznej konfiguracji.

Naprawa powinna obejmować wymuszenie weryfikacji podpisu przed użyciem jakichkolwiek chronionych oświadczeń, ograniczenie akceptowanych algorytmów, prawidłową walidację iss, aud, exp i nbf oraz bezpieczną obsługę kluczy. Po zmianie należy wykonać testy negatywne i sprawdzić wszystkie miejsca, w których token jest przyjmowany: nagłówki żądań, ciasteczka, pamięć aplikacji oraz mechanizm odświeżania. Dopiero odrzucenie zmienionych i wygasłych tokenów w każdym z tych przepływów potwierdza, że luka została usunięta.