brak sprawdzania audience w tokenie JWT

Brak sprawdzania audience w tokenie JWT to luka bezpieczeństwa umożliwiająca wykorzystanie tokenu poza jego zamierzonym odbiorcą.

Brak sprawdzania audience w tokenie JWT – czym jest ten problem

Token JWT jest podpisanym dokumentem, który przekazuje aplikacji informacje o tożsamości użytkownika, jego uprawnieniach oraz czasie ważności sesji. Jednym z pól takiego tokenu jest aud, czyli audience, rozumiane jako zamierzony odbiorca tokenu. Wartość ta powinna wskazywać konkretną aplikację, usługę albo interfejs, który może zaakceptować dany dokument uwierzytelniający. Brak sprawdzania audience w tokenie JWT oznacza, że odbiorca przyjmuje token wyłącznie dlatego, że podpis jest poprawny, pomijając pytanie, czy token został wystawiony właśnie dla niego.

W praktyce podpis odpowiada na pytanie, czy token został zmieniony i czy pochodzi od zaufanego wystawcy. Pole aud odpowiada natomiast na inne pytanie: dla kogo ten token jest przeznaczony. Są to dwa odrębne mechanizmy. Poprawny podpis nie potwierdza, że każdy system korzystający z tego samego wystawcy powinien uznać token za swój. Jeżeli aplikacja nie weryfikuje audience, może zaakceptować dokument wydany dla innego odbiorcy, mimo że jego treść jest spójna kryptograficznie.

Nie należy utożsamiać tego problemu z brakiem szyfrowania. Typowy JWT jest podpisany, ale jego treść może być możliwa do odczytania przez stronę, która otrzyma token. Bezpieczeństwo zależy więc od prawidłowej walidacji wszystkich istotnych parametrów, a nie od samego faktu, że token wygląda poprawnie i zawiera znany identyfikator użytkownika.

Audience w JWT na tle iss, sub i zakresu uprawnień

Ocena tokenu JWT powinna uwzględniać kilka pól, z których każde pełni inną funkcję. iss wskazuje wystawcę dokumentu, sub opisuje podmiot, którego dotyczy uwierzytelnienie, a aud określa odbiorcę. Pola związane z czasem, takie jak exp, nbf i iat, pomagają ustalić, czy token jest używany w odpowiednim okresie. Z kolei scope, roles albo podobne deklaracje mogą określać zakres operacji dostępnych dla użytkownika.

Te wartości nie zastępują się wzajemnie. Sprawdzenie wystawcy nie potwierdza odbiorcy. Sprawdzenie użytkownika nie potwierdza, że token może być używany w danej usłudze. Sprawdzenie czasu ważności nie rozstrzyga, czy dokument trafił do właściwego systemu. Również zakres uprawnień nie powinien być traktowany jako dowód przeznaczenia tokenu. Token z ograniczonym zakresem nadal może zostać użyty w niewłaściwym miejscu, jeżeli odbiorca akceptuje go bez weryfikacji aud.

W środowisku z kilkoma aplikacjami wspólny wystawca może wydawać tokeny dla różnych odbiorców. Przykładowo dokument przeznaczony dla panelu użytkownika może być podpisany tym samym kluczem co dokument wydany dla interfejsu obsługującego zamówienia albo aplikacji mobilnej. Jeżeli każdy odbiorca uznaje dowolny token tego wystawcy, granice między usługami zostają osłabione. Wtedy token przeznaczony do jednego zastosowania może zostać przedstawiony innemu systemowi i potraktowany jako prawidłowe uwierzytelnienie.

Znaczenie ma także sposób interpretacji pola aud. W zależności od specyfikacji i biblioteki wartość może występować jako pojedynczy tekst albo tablica tekstów. Walidator powinien stosować reguły przewidziane dla używanego standardu, a nie proste porównanie wykonane przypadkowo w kodzie aplikacji. Należy ustalić, czy odbiorca wymaga konkretnej wartości, czy może należeć do zdefiniowanego zbioru odbiorców, oraz czy porównanie jest odporne na pomyłki związane z formatem, wielkością liter i nieoczekiwanymi znakami.

Brak sprawdzania audience w tokenie JWT a typowe scenariusze wykorzystania

Najczęstszy scenariusz zaczyna się od uzyskania prawidłowego tokenu w jednym miejscu. Może on zostać zapisany w historii przeglądarki, przechwycony przez błędnie zabezpieczony mechanizm przekazywania danych, ujawniony w logu albo pobrany przez złośliwe rozszerzenie działające w kontekście użytkownika. Samo przejęcie tokenu jest problemem, lecz brak weryfikacji audience może poszerzyć zakres jego użycia. Dokument, który powinien działać tylko wobec jednego odbiorcy, może zostać przedstawiony innemu punktowi dostępowemu.

Skutki zależą od podobieństwa reguł autoryzacji w poszczególnych usługach. Jeżeli różne systemy korzystają z tych samych nazw ról, podobnego formatu identyfikatora użytkownika i wspólnego klucza podpisującego, odbiorca może uznać token za wystarczający do wykonania operacji. Nawet gdy zakres uprawnień jest ograniczony, może dojść do ujawnienia danych, odczytu zasobów, modyfikacji ustawień albo wykonania działania, którego wystawca tokenu nie przewidywał dla tego systemu.

Ryzyko rośnie wtedy, gdy aplikacje mają odmienne wymagania dotyczące dostępu, lecz walidują token w identyczny, uproszczony sposób. Jeden system może oczekiwać wyłącznie odczytu danych, a inny może traktować tę samą rolę jako uprawnienie do zmiany. W takim układzie brak granicy wyznaczonej przez aud pozwala przenieść dokument między kontekstami, w których te same deklaracje znaczą coś innego.

Nie każda próba użycia niewłaściwego tokenu musi od razu zakończyć się pełnym przejęciem funkcji. Czasem problem ujawnia się jako częściowe obejście kontroli, możliwość odpytywania nieprzeznaczonego interfejsu, różnice w komunikatach błędów albo dostęp do informacji pomocnych przy dalszym ataku. Dlatego ocenę należy prowadzić nie tylko przez sprawdzenie, czy da się wykonać pojedyncze żądanie, lecz także przez analizę wszystkich operacji dostępnych po pomyślnym uwierzytelnieniu.

Weryfikacja audience w JWT – praktyczne wskazówki dla aplikacji

Najważniejszym krokiem jest zdefiniowanie oczekiwanej wartości audience po stronie każdego odbiorcy. Nie powinno się pozostawiać tej decyzji domyślnej konfiguracji biblioteki ani przekazywać jej wyłącznie do kodu wywołującego bez kontroli. Wymagana wartość powinna wynikać z konfiguracji konkretnej aplikacji i być traktowana jako element polityki bezpieczeństwa. Walidacja powinna zakończyć się odmową, jeśli pole aud nie występuje, ma nieprawidłowy typ albo nie zawiera oczekiwanego odbiorcy.

Warto sprawdzić jednocześnie wystawcę, podpis, dozwolony algorytm, czas ważności, czas rozpoczęcia obowiązywania oraz odbiorcę. Konfiguracja algorytmu nie powinna być wybierana na podstawie wartości dostarczonej w tokenie bez ograniczeń narzuconych przez aplikację. Należy także zweryfikować, czy biblioteka rzeczywiście wykonuje kontrolę aud, ponieważ samo odczytanie pola z obiektu tokenu nie jest walidacją.

Przydatne jest rozdzielenie etapów uwierzytelnienia i autoryzacji. Najpierw należy ustalić, czy dokument jest ważny dla danego odbiorcy. Dopiero potem można analizować tożsamość i uprawnienia. Dzięki temu token wydany dla innej usługi nie zostanie zaakceptowany jako punkt wyjścia do dalszych decyzji. Dobrą praktyką jest również ograniczenie wspólnego użycia kluczy oraz jasne przypisanie odbiorców do konkretnych interfejsów.

Testy powinny obejmować co najmniej token z prawidłowym aud, token z inną wartością, token bez tego pola, token z pustą wartością oraz token z tablicą zawierającą właściwego i niewłaściwego odbiorcę. Należy sprawdzić także zachowanie przy różnicach w zapisie wartości, nieoczekiwanych typach danych i próbach dodania dodatkowych elementów do deklaracji. Wynik negatywny powinien być przewidywalny i nie powinien ujawniać nadmiarowych szczegółów osobie wysyłającej żądanie.

W logach warto rejestrować fakt odrzucenia tokenu z powodu odbiorcy, ale bez zapisywania pełnej wartości tokenu. Przydatne są identyfikator żądania, nazwa aplikacji, czas zdarzenia oraz bezpieczny identyfikator tokenu, jeśli taki mechanizm jest używany. Ułatwia to wykrycie prób przenoszenia dokumentów między usługami, a jednocześnie ogranicza ryzyko ponownego wykorzystania danych ujawnionych w logach.

Kiedy zgłosić brak sprawdzania audience w tokenie JWT do serwisu

Do analizy warto zgłosić się wtedy, gdy nie jest jasne, które komponenty wystawiają i odbierają tokeny JWT, jakie wartości aud są wymagane oraz czy używana biblioteka faktycznie wymusza ich sprawdzanie. Szczególnej uwagi wymaga sytuacja, w której kilka aplikacji korzysta ze wspólnego wystawcy, wspólnych kluczy lub podobnych ról, a dokument pobrany w jednym miejscu jest akceptowany w innym. Niepokojącym sygnałem jest także możliwość wykonania żądania po podmianie samej wartości audience bez odrzucenia tokenu przez odbiorcę.

W ramach przeglądu można przeanalizować konfigurację walidatora, sposób budowania tokenów, mapowanie uprawnień i zachowanie punktów dostępowych. Należy zachować ostrożność, aby testy nie zmieniały danych i nie powodowały przerw w działaniu. W przypadku podejrzenia ujawnienia aktywnego tokenu rozsądne jest jego unieważnienie lub skrócenie okresu użycia zgodnie z procedurą administratora, a następnie sprawdzenie logów pod kątem nietypowych żądań.

Wsparcie techniczne w takich sprawach można uzyskać w firmie Warszawskie Pogotowie Komputerowe 24/7, przedstawiając opis objawu, fragment bezpiecznie zanonimizowanej konfiguracji oraz informację, jakie systemy uczestniczą w procesie uwierzytelnienia. Nie należy przesyłać pełnych aktywnych tokenów, kluczy podpisujących, haseł ani danych użytkowników. Samo wykrycie braku sprawdzania audience nie przesądza jeszcze o sposobie naprawy, ale jest wyraźnym sygnałem do uporządkowania walidacji i rozdzielenia zaufania między odbiorcami.