LW IT Solutions
« Blog Overview /Tworzenie stron internetowych / Token JWT jest podpisany, a nie zaszyfrowany
This post in other languages:

Token JWT jest podpisany, a nie zaszyfrowany

Token JWT jest podpisany, a nie zaszyfrowany
Spis treści
  1. Trzy części i co robi każda z nich
  2. Czego ładunek nie powinien zawierać
  3. exp jest jedyną rzeczą kończącą token
  4. Gdzie odczyt myli się ze sprawdzeniem
  5. Co należy do każdego tokenu

Token JSON Web Token wygląda na zaszyfrowany. To długi ciąg znaków bez czytelnych słów, stoi w nagłówku Authorization i traktuje się go jak tajemnicę. Czym jest naprawdę: dwoma obiektami JSON w Base64 plus podpisem – a Base64 to kodowanie, nie zamek.

Wniosek jest krótki. Wszystko w ładunku odczyta każdy, kto ma token: przeglądarka, do której trafił, proxy, przez które przeszedł, plik dziennika, który zapisał adres, i zgłoszenie, do którego ktoś go wkleił. To nie usterka, lecz budowa formatu. Problemem staje się dopiero wtedy, gdy ładunek pisze się tak, jakby nikt go nie czytał.

Token rozłożony na trzy części rozdzielone kropkami, nagłówek i ładunek zdekodowane do czytelnego JSON i oznaczone jako czytelne dla każdego, podpis oznaczony jako jedyna część, która cokolwiek chroni
Dwie z trzech części odczyta każdy. Trzecia jest jedyną, która w ogóle coś chroni.

Trzy części i co robi każda z nich

Token składa się z trzech sekcji rozdzielonych kropkami. Pierwsza podaje algorytm i często użyty klucz. Druga niesie oświadczenia – o kim token mówi, na co pozwala, jak długo obowiązuje. Trzecia to podpis nad dwiema pierwszymi.

Chroni wyłącznie trzecia i chroni dokładnie jedną własność: że dwie pierwsze nie zmieniły się od chwili podpisania. Nie ukrywa ich i nie trzeba jej rozumieć, aby je odczytać. Token wklejony w dowolny dekoder natychmiast oddaje swoją zawartość.

Czego ładunek nie powinien zawierać

Każde pole w ładunku to pole wręczone posiadaczowi tokenu. Adres e-mail, pełne imię i nazwisko, data urodzenia – zamieniają dokument dostępu w przekazanie danych i trafiają tam, gdzie docierają dokumenty dostępu, a dane osobowe trafiać nie powinny: do dzienników proxy, pamięci przeglądarki, raportów o błędach.

Drugi rodzaj to struktura wewnętrzna. Lista ról w rodzaju billing_admin albo numer najemcy zdradza, co istnieje za interfejsem i jak jest uporządkowane – właśnie to atakujący wylicza w pierwszej kolejności. Zwykle wystarczy krótki podmiot i zakres; reszta należy do zapytania, które serwer i tak wykonuje.

Trzeci to wszystko, co przeznaczone było wyłącznie dla wystawcy. Tokeny wkleja się do zgłoszeń, a ładunek z wewnętrznym numerem klienta wędruje razem z nimi.

exp jest jedyną rzeczą kończącą token

Token obowiązuje, bo sam tak o sobie twierdzi. Nie ma stanu po stronie serwera, który by go kończył: raz wystawiony działa, aż minie oświadczenie exp, a token bez exp działa na zawsze.

Dlatego wylogowanie niczego nie unieważnia. Klient odrzuca token, token pozostaje ważny, a kto zachował kopię, zachowuje dostęp. Zakończenie tokenu przed czasem wymaga listy odrzuceń sprawdzanej przez każdą usługę – czyli powrotu dokładnie tego wspólnego stanu, którego format miał unikać.

Układem, który działa, jest krótko żyjący token dostępu i odwoływalny centralnie token odświeżający. Minuty dla pierwszego, a dla drugiego czas życia, który ktoś faktycznie obserwuje: token odświeżający ważny rok to hasło z dodatkowymi krokami.

Gdzie odczyt myli się ze sprawdzeniem

Odczytanie tokenu i zaufanie mu to różne czynności, a różnicą jest wywołanie biblioteki. Dekoder pokazuje oświadczenia każdego tokenu, także takiego, który powstał ręcznie trzy sekundy temu. Weryfikacja przelicza podpis względem klucza i dopiero ona odpowiada, czy oświadczenia pochodzą od kogoś uprawnionego do ich wystawienia.

Z pomylenia obu wynikają dwa obrazy błędu. Pierwszy to alg: none – token oświadczający, że nie ma podpisu. Weryfikator, który odczytuje algorytm z tokenu i się do niego stosuje, przyjmie wszystko; algorytm musi ustalać aplikacja, a nie token. Drugi to ten sam błąd z kluczem: usługę oczekującą RS256, która dostaje token HS256, da się nakłonić do sprawdzenia go kluczem publicznym jako wspólnym sekretem – a klucz publiczny jest publiczny.

Co należy do każdego tokenu

Na trzech oświadczeniach warto nalegać. exp, bo bez niego nic się nie kończy. iss, aby usługa rozpoznała, od którego wystawcy token pochodzi, zamiast przyjmować wszystko, co da się zweryfikować. Oraz aud – to oświadczenie zapobiega przyjęciu przez interfejs rozliczeń tokenu wystawionego dla interfejsu raportów; kontrola, którą łatwo pominąć i trudno zauważyć, gdy jej brak.

Nic z tego nie wymaga rozbudowanych narzędzi. Podzielenie tokenu po kropkach i zdekodowanie środkowej części trwa sekundy i odpowiada na pytania, na które inaczej odpowiada się założeniem: jak długo to obowiązuje, na co pozwala i co zdradza każdemu, kto to przeczyta.

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

Napisanie komentarza

Adres e-mail nie jest publikowany. Pola obowiązkowe oznaczono gwiazdką.

ALL ARTICLES & CATEGORIES

CCTV

Śledź tę kategorię przez RSS

Cloud & AI

Śledź tę kategorię przez RSS

Data Privacy

Śledź tę kategorię przez RSS

Digital Analytics

Wszystkie artykuły w tej kategorii (34) Śledź tę kategorię przez RSS

Digital Marketing

Wszystkie artykuły w tej kategorii (21) Śledź tę kategorię przez RSS

IT & Networks

Wszystkie artykuły w tej kategorii (11) Śledź tę kategorię przez RSS

Raspberry Pi

Śledź tę kategorię przez RSS

Smart Home

Śledź tę kategorię przez RSS

Tworzenie stron internetowych

Śledź tę kategorię przez RSS

Wtyczki i triki WordPress

Śledź tę kategorię przez RSS