JWT: struktura i słabości

1) Co to jest JWT i gdzie jest używany

JWT to kompaktowy, samodzielny kontener oświadczeń w formacie „BaseUrl (nagłówek)”. Base64Url (ładunek użytkowy). Base64Url (podpis) ".

• JWS (podpisane tokeny - autentyczność/integralność),
• JWE (szyfrowane żetony - prywatność),
• OIDC/OAuth2 jako tokeny dostępu/identyfikatora, a także uwierzytelnianie usług.

Plusy: autonomia, pamięć podręczna, niskie koszty ogólne. Minusy: ryzyko nieprawidłowej walidacji, złożone przypadki wycofania.

2) Struktura JWT

2. 1 Nagłówek (JSON)

Minimum: algorytm i identyfikator klucza.

json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }

„alg”: algorytm podpisu/szyfrowania (RS256/ES256/PS256/HS256 itp.).
„dziecko”: wskaźnik do klucza (dla rotacji JWKS).
Opcjonalne źródła kluczowe: 'jku', 'x5u' (zob. luki ust. 6. 3).

2. 2 Ładunek użytkowy (JSON)

• „iss' (emitent),” aud' (publiczność), „sub” (przedmiot)
• „exp” (czas ważności), „nbf” (nie wcześniej), „iat” (wydany)
• 'jti' (token ID, odwołalne)
• znaczki domeny: „zakres/role”, „najemca”, „kyc _ level” itp.

2. 3 Podpis

JWS = 'znak (base64url (nagłówek) + ". + base64url (ładunek użytkowy), private_key)'

Weryfikacja: ściśle odpowiadający klucz publiczny i dokładnie algorytm, którego oczekuje serwer.

3) Kontrola podstawowa niezmienna

1. Algorytm jest ustawiony przez konfigurację serwera zasobów (lista zezwoleń) i nie jest ufany zawartości 'headera. alg '.
2. Sprawdź 'iss' i' aud' dla dokładnego dopasowania, 'exp/nbf' - biorąc pod uwagę małe 'zegar _ skew' (± 30-60s).
3. Odmówić żetonów bez „dziecka” tylko wtedy, gdy istnieje jeden klucz i nie ma obrotu; w przeciwnym razie zażądaj „dziecka”.
4. Nie ufaj żadnym znaczkom bez autoryzacji poziomu obiektu (BOLA-first).
5. Parsing - po weryfikacji kryptograficznej; podstawowe kontrole rozmiaru przed dekodowaniem.

4) JWS vs WiI

JWS: podpisane, ale czytelne. Nie wkładać ładunku PII/tajemnic.
JWE: szyfruje ładunek użytkowy; integracja jest trudniejsza, kluczowy model jest krytyczny.
W większości API, JWS + zakaz danych wrażliwych w ładunku wystarczy.

5) Token cyklu życia

Dostęp: krótkoterminowy (5-30 minut).
Odśwież: dłuższy (7-30 dni), obrót w użyciu (jednorazowy), zachowaj „czarną listę” jti/sid'.
Odwołanie: wykazy 'jti' z TTL, introspekcja dla nieprzezroczystych żetonów, skrót' exp 'dla incydentów.
Rotacja klucza: JWKS z nakładaniem się (stary + nowy), patrz artykuł „Rotacja klucza”.

6) Częste zagrożenia i sposób ich zamykania

6. 1 'alg = brak '/zastąpienie algorytmem

Linia dolna: Serwer ufa polu 'alg' i akceptuje niezapisany token.
Ochrona: twarda lista algorytmów na serwerze; odrzucić 'brak' i nieoczekiwane wartości.

6. 2 RS256 → swap HS256 (symetria)

Najważniejsze: napastnik zastępuje 'alg' z HS256 i używa klucza publicznego jako tajemnicy HMAC.
Ochrona: powiązać klucz z algorytmem z konfiguracją; nie mieszać dostawców symetrycznych/asymetrycznych w jednym dziecku.

6. 3 wtrysk klucza („kid/jku/x5u”)

• 'jku' punkty do JWKS kontrolowanego przez atakującego (przesuwa klucz).
• "x5u "/" x5c' nadużycie świadectw zewnętrznych.
• „wtrysk ścieżki dziecięcej/SQL (”.. "/../privkey. pem „'lub' 'OR 1 = 1 --”').

• Ignoruj usunięte 'jku/x5u' lub filtr przez ścisłe domeny listy permit.
• 'kid' może być używany tylko jako klucz w katalogu lokalnym (tabela/pamięć podręczna), bez ścieżek plików/konkatenacji SQL.
• Ładowanie JWKS z zaufanych adresów URL, krótki TTL, kanał podpisu/pinning.

6. 4 Słabe tajemnice HS256 (brutalna siła)

Bottom line: HMAC secret is short/leaked → signature spoofing.
Ochrona: używać asymetrii (RS/ES/PS) lub sekretnej długości ≥ 256 bitów, tajemnice - tylko w KMS.

6. 5 Brakujące/nieprawidłowe znaczki

Brak 'aud '/' iss'/' exp' → token jest obsługiwalny krzyżowo lub nieskończony.
Zbyt długi 'exp' → ryzyko kompromisu.
Ochrona: wymagać pełnego zestawu znaków, 'exp' krótki, 'nbf '/' iat' zwalidować z 'zegar _ skew'.

6. 6 Powtórka i token kradzież

Istota: przechwytywanie/powtarzanie tokena (wyciek logów, XSS, MitM bez TLS).

• TLS веба, 'Secure' + 'Only' cookie, Site = Lax/Strict.
• DPoP/PoP (powiązanie tokena z kluczem klienta) i/lub mTLS dla partnerów.
• Krótkie 'exp', odświeżanie, wiązanie urządzenia.

6. 7 XSS/wycieki do przechowywania

Linia końcowa: Przechowywanie JWT w pamięci „Z pamięci ”/„ Z” jest → dostępne dla JS.
Ochrona: tokeny dostępu do sklepu w Pliku Only-cookie (jeśli model cookie jest możliwy) + rygorystyczne typy CSP/Trusted.
Dla SPA bez ciasteczek - odizolować token w pamięci, żyć minimalnie, chronić przed XSS.

6. 8 CSRF

Najważniejsze: podczas sesji cookies, prośby strony trzeciej.
Ochrona: Site, żetony anty-CSRF (podwójne przesłanie), kontrola „Origin/Referer”, filtry Fetch-Metadata.

6. 9 Nadmierne nadużywanie rozmiarów

Gist: ogromny ładunek/nagłówki, DoS na parsing.
Ochrona: ograniczenia wielkości tytułu/nadwozia, wczesne odrzucenie 431/413, stały zestaw znaczków.

6. 10 Substytucja „typ ”/„ typ”

Istota: zamieszanie typów ('typ:' JWT'), gniazdowane obiekty JOSE.
Ochrona: ignorować „typ/cty” dla bezpieczeństwa, polegać na stałych algorytmach i schemacie marki.

7) Token do przechowywania i przenoszenia

7. 1 Interfejsy API serwera (maszyna-maszyna)

mTLS/HMAC, najlepiej asymetria dla JWT, kanały przez siatkę.
Sklep kluczy - KMS/HSM, zaplanowana rotacja, nakładanie się JWKS.

7. 2 Klienci przeglądarki

Tylko bezpieczne pliki cookie дла access/refresh; krótki TTL; aktualizacja - za pomocą „silent refresh” z 'Site = None' only under HTTPS.
Ścisłe CSP, zaufane typy, ochrona przed XSS; dla SPA - jeśli to możliwe, nie przechowywać tokena na dysku.

8) JWKS, rotacja i wycofanie

JWKS jest publikowany przez autoryzatora; konsumenci buforują przez 5-15 minut.
Plan rotacji: dodać nowe 'dziecko' → rozpocząć ich podpisywanie → po N dni usunąć stary z JWKS → oczyścić.
Informacje zwrotne: listy 'jti/sid' z TTL; w przypadku incydentu, czasowo zmniejszyć 'exp' i force-logout (wyłączyć odświeżanie).

9) Wielokrotny najemca i minimalizacja danych

umieścić „najemcę ”/„ org” w tokenie tylko w razie potrzeby przez architekturę; w przeciwnym razie pobierz atrybuty z PDP przez 'sub'.
Brak PIIs; minimalny zestaw znaczków → mniejsze ryzyko wycieków i korelacji.

10) Praktyczna lista kontrolna walidacji (serwer zasobów)

• Parsim tylko po weryfikacji podpisu i podstawowych limitów wielkości.
• „alg” z konfiguracji; odrzucić nieoczekiwane.
• Sprawdź 'iss',' aud', ',' exp ',', ', nbf', ',' iat '(z' zegar _ skew ').
• Sprawdź 'dzieciak' w katalogu lokalnym/JWKS (short TTL).
• Filtrowanie/normalizacja wskaźników zewnętrznych ('jku/x5u' - tylko list zezwoleń).
• Ograniczona długość/skład pieczęci (schemat).
• Zastosuj autoryzację zasobów obiektu (BOLA-first).
• Log 'kid', 'sub', 'aud',' iss', 'jti', 'exp', 'lokator', 'trace _ id' (bez PII).
• Wskaźniki błędów w podpisie, opóźnień, audytów rotacyjnych.

11) Przykłady bezpiecznych polityk (pseudo)

11. 1 Konfiguracja oczekiwań algorytmu

yaml jwt:
expected_issuer: "https://auth. example. com"
expected_audience: ["wallet-service"]
allowed_algs: ["ES256"] # fix the jwks_url: "https ://auth. example. com/.well-known/jwks. json"
jwks_cache_ttl: 600s clock_skew: 60s required_claims: ["iss","aud","sub","exp","iat"]

11. 2 Upuszczanie zdalnego 'jku/x5u'

yaml reject_untrusted_key_sources: true allowed_jku_hosts: ["auth. example. com"] # if absolutely necessary

11. 3 Przykładowa lista opinii (Redis)

pseudo if redis. exists("revoke:jti:" + jti) then deny()
if now() > exp then deny()

12) Obserwowalność i częstość występowania

Метрика: 'jwt _ verify _ fail _ total {reason}', 'jwt _ expired _ total', 'jwks _ refresh _ total', дола 'kid'.
Kłody (strukturyzowane): "iss/aud/sub/kid/jti/exp/najemca/trace _ id', powód awarii.
Deski rozdzielcze: „wygasa wkrótce”, wzrost błędów walidacyjnych, dystrybucja według regionu/klienta.
Alerty: wzrost 'verify _ fail' (podpis/algorytm), błędy JWKS, udział wygasłych żetonów.

13) Antypattery

Zaufanie 'alg' z tokena; wsparcie „żadnego”.
Długotrwałe żetony dostępu i brak odświeżania.
HS256 z krótką tajemnicą/tajemnicą bez KMS.
Akceptuj 'jku/x5u' z dowolnej domeny; dynamicznie ładować JWKS bez listy zezwoleń.
Umieść PII/sekrety w ładunku JWS.
Zapisz żetony w 'Zapamiętywanie', gdy istnieje ryzyko XSS.
Tłumić błędy walidacji (zwraca 200 s „błąd miękki”).
Brak kontroli BOLA i poleganie wyłącznie na „zakresie/roli”.

14) Szczegóły dotyczące iGaming/Finance

Marki: 'kyc _ level', 'risk _ tier', 'lokator', 'aud'.
Krótki TTL dla operacji zapisu (depozyty/wyjścia), PoP/DPoP lub mTLS dla tras krytycznych.
Audyt regulacyjny: niezmienne dzienniki wejść/awarii, przechowywanie kłód w granicach regionu.
Partnerzy/PSP mają oddzielne klucze/' aud', klucze lokatora i oddzielny JWKS.

15) Lista kontrolna gotowości Prod

• Twarda lista algorytmów; „żaden” nie jest dozwolony.
• sprawdza się „iss/aud/exp/nbf/iat/jti”; krótkie 'exp'.
• pokrywała się JWKS, krótka pamięć podręczna TTL; monitorowanie udziałów „dzieciaków”.
• Odśwież - obrót w użyciu; "jti/sid' listy z TTL; recenzja playbook.
• PoP/DPoP lub mTLS na trasach krytycznych.
• Tylko pliki cookie dla przeglądarki, CSP/Zaufane typy kontra XSS; Ochrona CSRF.
• Brak PII w ładunku; minimalny zestaw znaków.
• Mierniki walidacji i błędów/kłody; alerty JWKS/verify_fail.
• Negatywne testy scenariusza: RS → swap HS, 'kid' -injections, 'jku' spoofing, oversize, clock-skew.

16) TL; DR

Naprawić algorytm i klawisze po stronie serwera, nie ufać 'alg' z tokena, żądać 'iss/aud/exp/nbf/iat/jti'. Obróć klucze poprzez nakładanie się JWKS, zachować żetony krótkotrwałe i odświeżyć jednorazowe. Bezpiecznie przechowywać żetony (Tylko pliki cookie dla sieci), minimalizować znaczki, nie umieszczać PII. Zamknij wektory 'jku/x5u/kid', unikaj HS256 słabymi tajemnicami, dodaj PoP/DPoP lub mTLS na ścieżkach krytycznych i zawsze wykonuj kontrole BOLA na poziomie zasobów.