Struttura e vulnerabilità JWT

1) Cosa è JWT e dove viene utilizzato

JWT è un contenitore di affermazioni autosufficiente compatto (clims) in formato "Base64Url (header). Base64Url(payload). Base64Url(signature)`.

• JWS (token firmati - autenticità/integrità),
• JWE (token crittografati - privacy),
• OIDC/OAuth2 come token access/ID e autenticazione service-to-service.

Vantaggi: autonomia, cache, costi generali ridotti. Contro: rischio di convalida errata, valigette di richiamo complesse.

2) Struttura JWT

2. 1 Titolo (header, JSON)

Minimo: algoritmo e ID chiave.

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

«alg» è un algoritmo di firma/crittografia (RS256/ES256/PS256/HS256, ecc.).
«kid» è il puntatore della chiave (per la rotazione JWKS).
Le fonti di chiave opzionali sono «jku», «x5u» (vedere le vulnerabilità dell'articolo 6. 3).

2. 2 Carico utile (payload, JSON)

• `iss` (issuer), `aud` (audience), `sub` (subject)
• «exp», «nbf» (non prima), «iat» (emesso)
• «jti» (identificatore di token utilizzabile per le recensioni)
• «scope/roles», «tenant», «kyc _ level», ecc.

2. 3 Firma (firma)

JWS = `sign(base64url(header) + "." + base64url(payload), private_key)`

Verifica: la chiave pubblica e esattamente l'algoritmo che il server sta aspettando.

3) Invarianti di controllo di base

1. L'algoritmo viene rilevato dalla configurazione del server (allow-list) e non dal contenuto "header. alg`.
2. Controlla "iss'e" aud "per la corrispondenza esatta," exp/nbf "per la piccola" clock _ skew "(© 30-60s).
3. Disabilitare i token senza «kid» solo se l'unica chiave è senza rotazione; altrimenti, richiedere «kid».
4. Non fidarsi di nessun marchio senza autorizzazione a livello di oggetto (BOLA-first).
5. Parsing - dopo il criptoprover; controlli di base della quota prima del decodifica.

4) JWS vs JWE

JWS firmato, ma leggiamo. Non inserire nel payload PII/segreti.
JWE: crittografa payload; più difficile da integrare, il modello chiave è critico.
Nella maggior parte delle API è sufficiente JWS + divieto di dati sensibili in payload.

5) Ciclo di vita del token

Access: breve durata (5-30 minuti).
Refresh: più lungo (7-30 giorni), rotate-on-use (usa e getta), conservare «lista nera» «jti/sid».
Revocation: elenchi «jti» con TTL, introspezione per opache-token, riduzione «exp» in caso di incidenti.
Rotazione chiavi: JWKS sovrapposto (vecchio + nuovo), vedere Rotazione chiavi.

6) Frequenti vulnerabilità e come chiuderle

6. 1 'alg = none '/cambio algoritmo

Il punto è che il server si fida del campo alg e accetta un token non firmato.
Protezione: hard allow-list algoritmi sul server rifiutare «none» e i valori inaspettati.

6. 2 RS256→HS256 swap (simmetrizzazione)

L'intruso sostituisce Alg con HS256 e usa la chiave pubblica come segreto HMAC.
Protezione: allinea la chiave alla configurazione dell'algoritmo non mescolare i provider simmetrici/asimmetrici in «kid».

6. 3 Iniezione di chiavi ('kid/jku/x5u')

• JKU indica JWKS controllato da un intruso.
• «x5u »/« x5c» abuso di certificati esterni.
• «kid» con iniezione del percorso/SQL ('.../../privey. pem «o» «OR 1 = 1 -»).

• Ignora i domini eliminati «jku/x5u» o filtra con un allow-list rigoroso.
• «kid» usa solo come chiave nella directory locale (tabella/cache), senza percorsi di file/SQL concatenazioni.
• JWKS carica da URL affidabili, TTL breve, firma/pinning canale.

6. 4 Segreti deboli HS256 (forza bruta)

Il segreto HMAC è breve/anatra per la sostituzione della firma.
Protezione: usa l'asimmetria (RS/ES/PS) o la lunghezza del segreto di 256 bit, i segreti solo in KMS.

6. 5 Marchi mancanti/nevalidi

No «aud »/« iss »/« exp», il token cross-servizio è utilizzabile o infinito.
Il rischio di compromissione è troppo lungo.
Protezione: richiede un set completo di marchi, 'exp'breve,' nbf '/' iat'convalida con'clock _ skew '.

6. 6 Replay e furto di token

Il punto è l'intercettazione/ripetizione di token (fuga di dati, XSS, MitM senza TLS).

• TLS везде, `Secure`+`HttpOnly` cookie, SameSite=Lax/Strict.
• DPoP/PoP (mappando il token alla chiave client) e/o mTLS per i partner.
• Brevi «exp», rotazione refresh, device-binding.

6. 7 Fughe tramite XSS/storage

Il punto è che l' JWT è disponibile per JS.
Protezione: memorizzare i token access nel HttpOnly-cookie (se possibile, cookie-model) + CSP/Trusted Tykes rigorosi.
Per una SPA senza cookie, isolare il token nella memoria, vivere al minimo, proteggere da XSS.

6. 8 CSRF

Il punto è che i cookie vengono richiesti da un sito esterno.
Protezione: SameSite, anti-CSRF token (doppio sottomit), 'Origin/Referer'convalida, filtri Fetch-Metadata.

6. 9 Oversize/abuso di dimensioni

Il punto è che ci sono enormi pagload/titoli che fanno parsing.
Protezione: limiti di dimensioni intestazione/corpo, early-reject 431/413, set di marchi fix.

6. 10 Cambio «typ »/« cty»

Oggetto: confusione dei tipi ('typ: JWT'), oggetti JOSE nidificati.
Protezione: ignora «typ/cty» per la protezione, si basa su algoritmi fissi e schemi di marcatura.

7) Stoccaggio e trasferimento di token

7. 1 API server (machine-to-machine)

mTLS/HMAC, preferibilmente asimmetria per JWT, canali tramite mesh.
Archivio chiavi - KMS/HSM, rotazione pianificata, JWKS sovrapposto.

7. 2 Browser client

HttpOnly Secure Cookie для access/refresh; TTL brevi; l'aggiornamento è «silent refresh» con «SameSite=None» solo sotto HTTPS.
Protezione da XSS rigorosa, Trusted Types; per SPA - se possibile, non memorizzare il token su disco.

8) JWKS, rotazione e recensione

JWKS viene pubblicato dall'autorizzatore; I consumatori sono nella cache per 5-15 minuti.
Piano di rotazione: aggiungi un nuovo «kid» per iniziare a firmare il in N giorni per rimuovere il vecchio da JWKS purge.
Recensione: elenchi «jti/sid» c TTL; in caso di incidente, ridurre temporaneamente «exp» e forza-logout (invalidare refresh).

9) Multi-tenant e minimizzazione dei dati

Includere «tenant »/« org» nel token solo se necessario in base all'architettura; altrimenti allungare gli attributi da PDP per sub.
Niente PII; Un set minimo di marchi è meno rischioso di fuoriusciti e collassi.

10) Assegno di convalida pratico (server risorsa)

• Parsim solo dopo aver controllato la firma e i limiti di base della quota.
• 'alg'dalla configurazione; Rifiutare quelli inaspettati.
• Controlla «iss» «aud» «exp» «nbf» «iat» (c «clock _ skew»).
• Controlla «kid» dalla directory locale/JWKS (TTL breve).
• Filtra/normalizza i puntatori esterni ('jku/x5u' - solo allow-list).
• Limita lunghezza/composizione dei marchi (schema).
• Applica autorizzazione oggetto a risorsa (PALLA-first).
• Logica «kid», «sub», «aud», «iss», «jti», «exp», «tenant», «trace _ id» (senza PII).
• Metriche di errori di firma, ritardo, controllo di rotazione.

11) Esempi di regole sicure (pseudo)

11. 1 Configurazione delle aspettative dell'algoritmo

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 Disdetta remote'jku/x5u '

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

11. 3 Elenco di recensioni (Redis)

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

12) Osservabilità e forenza

Метрики: `jwt_verify_fail_total{reason}`, `jwt_expired_total`, `jwks_refresh_total`, доля `kid`.
Loghi (strutturati): 'iss/aud/sub/kid/jti/exp/tenant/trace _ id', causa di guasto.
Dashboard: «presto scaduto», aumento degli errori di validazione, distribuzione per regione/cliente.
Alert: altezza «verify _ fail» (firma/algoritmo), errori JWKS, percentuale di token scaduti.

13) Antipattern

Fidarsi dì alg "dal token; mantenere'none '.
Token access a lunga durata e nessuna rotazione refresh.
HS256 con un segreto breve/il segreto è ENV senza KMS.
Accetta «jku/x5u» da qualsiasi dominio; scaricare dinamicamente JWKS senza allow-list.
Inserisci PII/segreti in payload JWS.
Immagazzina i token in «localStorage» in presenza di rischi XSS.
Interrompi gli errori di convalida (restituisci 200 con «soft error»).
Nessun controllo di BOLA e affidamento solo a scope/role.

14) Specificità iGaming/finanza

Etichette: «kyc _ level», «risk _ tier», «tenant», «aud».
TTL brevi per operazioni write (depositi/conclusioni), PoP/DPoP o mTLS per rotte critiche.
Controllo regolatorio: registri immutabili di ingressi/guasti, conservazione dei cavi nei confini della regione.
I partner/PSP hanno chiavi separate/' aud ', chiavi per tenente e JWKS separate.

15) Assegno-foglio prod-pronto

• Hard allow-list algoritmi; 'none'.
• 'iss/aud/exp/nbf/iat/jti' sono controllati; brevi «exp».
• JWKS sovrapposto, cache TTL breve Monitoraggio della quota «kid».
• Refresh — rotate-on-use; elenchi «jti/sid» con TTL; playbook di recensioni.
• PoP/DPoP o mTLS su percorsi critici.
• HttpOnly-cookies per il browser, CSP/Trusted Types contro XSS; Protezione CSRF.
• Senza PII in payload; Set minimo di marchi.
• Metriche/fogli di convalida e guasti; alert JWKS/verify _ fail.
• Test di script negativi: RS→HS swap, «kid» -iniezione, «jku» spoofing, oversize, clock-skew.

16) TL; DR

Fissare l'algoritmo e le chiavi sul lato server, non fidarsi dì alg "dal token, richiedere" iss/aud/exp/nbf/iat/jti ". Rotate le chiavi tramite JWKS sovrapposte, tenete i token corti e i refresh monouso. Memorizza i token in modo sicuro (HttpOnly-cookie per il web), minimizza i marchi, non posiziona il PII. Chiudete «jku/x5u/kid», evitate HS256 con segreti deboli, aggiungete PoP/DPoP o mTLS sui binari critici e fate sempre i controlli BOLA a livello di risorsa.