token JWT bez algorytmu podpisu

Token JWT bez algorytmu podpisu (alg none) to poważna luka pozwalająca sfałszować jego zawartość.

Token JWT bez algorytmu podpisu – czym jest problem „alg none”

Token JWT bez algorytmu podpisu to nieprawidłowo zabezpieczony dokument uwierzytelniający, w którym mechanizm potwierdzania autentyczności został wyłączony albo nie jest skutecznie egzekwowany. JWT, czyli JSON Web Token, jest zwykle wykorzystywany do przekazywania informacji o zalogowanej osobie, jej uprawnieniach, czasie ważności sesji lub zakresie dostępu do określonych funkcji aplikacji. Typowy token składa się z trzech części oddzielonych kropkami: nagłówka, treści oraz podpisu. Każda część jest zapisana w formacie Base64URL, dlatego sama obecność pozornie losowego ciągu znaków nie oznacza jeszcze, że zawartość jest zaszyfrowana.

W nagłówku JWT znajduje się między innymi pole alg, określające sposób ochrony tokenu. Wartość none oznacza brak podpisu kryptograficznego. Historycznie taka opcja mogła mieć zastosowanie w niektórych kontrolowanych scenariuszach testowych, ale przy obsłudze rzeczywistych uprawnień stanowi poważne zagrożenie. Jeżeli aplikacja przyjmie token z algorytmem „none” i nie sprawdzi, czy podpis jest wymagany, osoba nieuprawniona może zmienić treść tokenu, na przykład podstawić inne oznaczenie użytkownika albo podwyższyć deklarowany poziom uprawnień.

Nie chodzi więc wyłącznie o samą możliwość odczytania danych. Najważniejsze jest to, że odbiorca tokenu może błędnie uznać zmodyfikowaną informację za wiarygodną. JWT nie powinien być traktowany jako pojemnik, którego treść automatycznie zasługuje na zaufanie. Zaufanie wynika dopiero z poprawnie zweryfikowanego podpisu, zgodności algorytmu z polityką aplikacji, kontroli wystawcy oraz sprawdzenia czasu ważności i przeznaczenia tokenu.

Token JWT bez algorytmu podpisu a podpis, kodowanie i szyfrowanie

W analizie problemu warto rozdzielić trzy pojęcia: kodowanie, podpis cyfrowy i szyfrowanie. Kodowanie Base64URL zmienia sposób zapisu danych, lecz nie chroni ich przed odczytem ani modyfikacją. Nagłówek i treść większości tokenów JWT można zdekodować bez znajomości sekretu. Podpis cyfrowy ma inny cel: pozwala sprawdzić, czy token został utworzony przez zaufaną stronę oraz czy jego zawartość nie zmieniła się po wystawieniu. Szyfrowanie ukrywa dane przed osobami, które nie posiadają odpowiedniego klucza, ale standardowy JWT używany jako JWS nie musi zapewniać poufności.

Podstawowe warianty podpisywania różnią się sposobem użycia kluczy. Algorytmy symetryczne, takie jak rodzina HMAC, wykorzystują wspólny sekret po obu stronach. Algorytmy asymetryczne, na przykład RSA lub ECDSA, opierają się na parze kluczy: prywatny służy do podpisywania, a publiczny do weryfikacji. Niezależnie od wybranego wariantu aplikacja powinna mieć jasno ustaloną listę dopuszczalnych algorytmów. Nie powinno się pozwalać, aby klient samodzielnie wskazywał dowolną metodę, a odbiorca bez dodatkowej kontroli ją akceptował.

Podobne ryzyko pojawia się przy pomieszaniu algorytmów symetrycznych i asymetrycznych. Jeżeli biblioteka lub konfiguracja pozwala potraktować klucz publiczny jako sekret dla algorytmu HMAC, atakujący może próbować wykorzystać różnicę w sposobie weryfikacji. Z tego powodu wybór algorytmu powinien wynikać z konfiguracji po stronie aplikacji, a nie tylko z pola przesłanego w tokenie. Istotne są również standardowe kontrole pól iss, aud, exp, nbf i iat. Każde z nich ma inne znaczenie, a pominięcie kilku kontroli może osłabić ochronę nawet wtedy, gdy podpis jest poprawny.

Warto odróżnić błąd dotyczący JWT od sytuacji, w której aplikacja korzysta z ciasteczka sesyjnego, pojedynczego klucza API albo mechanizmu OAuth. Nazwy technologii mogą się łączyć, lecz sposób potwierdzania tożsamości i uprawnień powinien być badany osobno. Samo znalezienie ciągu alg:none w pliku konfiguracyjnym lub kodzie nie dowodzi jeszcze podatności. Należy ustalić, czy ta opcja jest faktycznie dostępna w ścieżce obsługującej logowanie oraz czy zmodyfikowany token zostaje zaakceptowany przez aplikację.

Token JWT bez algorytmu podpisu – typowe objawy i scenariusze błędu

Jednym z typowych objawów jest możliwość przesłania tokenu, którego nagłówek wskazuje brak algorytmu, przy jednoczesnym zachowaniu dostępu do zasobów wymagających uwierzytelnienia. Innym sygnałem może być akceptowanie tokenu bez trzeciej części, czyli bez podpisu, mimo że aplikacja powinna wymagać pełnego formatu. Podejrzane zachowanie pojawia się także wtedy, gdy zmiana danych w treści tokenu nie powoduje odrzucenia żądania. Takie testy powinny być wykonywane wyłącznie w środowisku, do którego uzyskano upoważnienie.

Najbardziej niebezpieczne są roszczenia dotyczące tożsamości i uprawnień. W zależności od projektu mogą one znajdować się w polach takich jak sub, role, scope lub w niestandardowych właściwościach. Jeżeli aplikacja bezkrytycznie ufa takim wartościom, zmiana identyfikatora może prowadzić do dostępu do cudzych danych, a zmiana roli do wykorzystania funkcji administracyjnych. Ryzyko zależy od tego, gdzie token jest używany, jak długo pozostaje ważny, czy występują dodatkowe kontrole oraz czy zasoby są chronione niezależnie od deklaracji klienta.

Nie każdy token zapisany w przeglądarce jest automatycznie podatny. Ocenie powinien podlegać cały przepływ: wystawienie tokenu, jego przechowywanie, przesłanie, weryfikacja i unieważnienie. Należy sprawdzić, czy serwer akceptuje wyłącznie oczekiwany typ tokenu, czy rozpoznaje właściwego wystawcę, czy ogranicza odbiorców oraz czy odrzuca dokumenty po upływie terminu. Ujawnienie treści tokenu w narzędziu deweloperskim nie jest samo w sobie dowodem włamania, ponieważ podpisany JWT często nie jest szyfrowany. Kluczowe pytanie brzmi, czy każda zmiana zostaje wykryta.

W logach mogą wystąpić błędy walidacji podpisu, nieznanego algorytmu, niezgodnego wystawcy albo nieprawidłowej grupy odbiorców. Nie powinno się ich wyłączać tylko po to, aby ukryć komunikaty przed użytkownikiem. Bezpieczniejszym rozwiązaniem jest rejestrowanie zdarzeń w sposób nienarażający danych tokenu, ograniczenie szczegółów prezentowanych na zewnątrz oraz analiza powtarzających się prób użycia nieprawidłowych nagłówków.

Token JWT bez algorytmu podpisu – praktyczne zabezpieczenie aplikacji

Najważniejszym działaniem jest wymuszenie konkretnego algorytmu po stronie weryfikatora. Biblioteka powinna otrzymać jawnie zdefiniowaną listę dopuszczalnych wartości, a token wskazujący none powinien zostać odrzucony jeszcze przed analizą uprawnień. Nie należy przekazywać niezweryfikowanych danych z tokenu do warstwy autoryzacji. Weryfikacja podpisu powinna poprzedzać wykorzystanie pól opisujących użytkownika, zakres dostępu i czas sesji.

Konfiguracja powinna zawierać również prawidłowy klucz, oczekiwanego wystawcę i odbiorcę tokenu. Wartość iss powinna odpowiadać zaufanemu wystawcy, a aud właściwej usłudze lub aplikacji. Pole exp powinno ograniczać czas ważności, natomiast nbf może blokować użycie tokenu przed określonym momentem. Dopuszczalny margines czasu powinien być niewielki i uzasadniony działaniem środowiska. Tokeny o długim czasie życia wymagają dodatkowych mechanizmów, takich jak odświeżanie, rotacja kluczy i możliwość unieważnienia.

Przydatne jest zastosowanie testów automatycznych obejmujących modyfikację nagłówka, usunięcie podpisu, zmianę identyfikatora użytkownika, podmianę roli oraz zmianę terminu ważności. Oczekiwanym wynikiem jest odrzucenie każdego tokenu, którego podpis nie pasuje do treści albo którego parametry nie spełniają polityki. Testy regresyjne powinny być uruchamiane po aktualizacji biblioteki JWT, zmianie dostawcy tożsamości i modyfikacji middleware odpowiedzialnego za autoryzację.

Warto ograniczyć zakres danych przechowywanych w tokenie. JWT nie powinien zawierać haseł, pełnych danych osobowych ani informacji, których ujawnienie byłoby problemem. Minimalny zestaw deklaracji ułatwia kontrolę i zmniejsza skutki przypadkowego ujawnienia. W przypadku stwierdzenia błędu należy unieważnić lub wymienić klucze, ocenić ważność wcześniej wystawionych tokenów, sprawdzić logi oraz rozważyć wymuszenie ponownego logowania. Samo usunięcie możliwości użycia algorytmu „none” może nie wystarczyć, jeśli wcześniej zaakceptowane tokeny nadal działają.

Kiedy zgłosić token JWT bez algorytmu podpisu do serwisu

Do serwisu warto zgłosić urządzenie, na którym pojawiają się objawy wskazujące na przejęcie sesji, nieznane rozszerzenia przeglądarki, przekierowania na obce strony, powtarzające się komunikaty o logowaniu albo nietypowe zachowanie narzędzi używanych do pracy z aplikacjami. Sama podatność alg:none zwykle dotyczy konfiguracji lub kodu po stronie aplikacji, jednak komputer może być miejscem, z którego wykonano nieautoryzowane testy, skopiowano token albo zainstalowano złośliwe oprogramowanie. Przed przekazaniem sprzętu nie powinno się kasować logów, resetować przeglądarki ani nadpisywać podejrzanych plików, jeśli potrzebne jest ustalenie przebiegu zdarzeń.

W Warszawie wsparcie w ocenie stanu laptopa i komputera PC można uzyskać w Warszawskim Pogotowiu Komputerowym 24/7 pod numerem +48 22 100 48 29. Przy zgłoszeniu dobrze opisać, czy problem dotyczy konkretnej aplikacji, konta, przeglądarki lub sieci, a także podać moment zauważenia nieprawidłowości. Nie należy przekazywać haseł ani aktywnych tokenów w treści wiadomości. Do analizy powinny trafić przede wszystkim komunikaty błędów, bezpiecznie zanonimizowane fragmenty konfiguracji i informacje o wykonanych zmianach.

Jeśli problem dotyczy samej aplikacji internetowej, konieczna może być współpraca z osobą odpowiedzialną za jej kod, konfigurację uwierzytelniania i logi. Serwis sprzętowy może pomóc ustalić, czy komputer jest stabilny, czy środowisko użytkownika nie zostało naruszone i czy nie występują objawy infekcji, lecz poprawa konfiguracji walidatora JWT wymaga dostępu do projektu oraz uprawnień administratora aplikacji. Najbezpieczniejsze postępowanie łączy oba obszary: zabezpieczenie urządzenia, ochronę kont, wymianę podejrzanych danych uwierzytelniających i poprawienie reguł akceptowania tokenów.