OWASP JWT: brute-force su 10.000 secret + kid injection

Il rischio reale dei JWT viene dalla configurazione, non dal formato. Leggere il payload di un token (cosa fa il JWT decoder) è la parte facile: chiedersi se quel token è esposto a uno dei pattern noti di compromissione è ciò che separa un'integrazione production-grade da un incidente in attesa di accadere. Le CVE storiche su librerie JWT diffuse (jsonwebtoken < 8.5, jose < 4, python-jwt, ruby-jwt) sono tutte conseguenza di assunzioni implicite del backend che il tool fa emergere dal solo manifest del token.

I quattro vettori classici verificati dall'audit. (1) alg=none e permutazioni: librerie storicamente vulnerabili accettavano header {"alg":"none"} bypassando la verifica. Il check copre la stringa esatta e tutte le permutazioni di case (None, NONE, nULL, null, alg vuoto, alg numerico, alg mancante). (2) HS256 con weak secret: HMAC con secret condiviso brute-forzabile offline se il secret è una passphrase umana. L'audit prova un dataset curato di 10.000 secret comuni (wallarm/jwt-secrets + SecLists/scraped-JWT-secrets, ricompilato giornalmente) verificando ogni candidato via WebCrypto HMAC-SHA256 in locale. (3) alg confusion attack: il backend è configurato per RS256 ma accetta anche HS256, e usa la public key RSA come secret HMAC. Vettore documentato in CVE storiche (jsonwebtoken pre-8.5). Se fornisci la public key, il tool tenta la verifica HMAC con la pubkey come secret e segnala critical se passa: significa che il backend accetterebbe token attacker-controllati firmati con la sua stessa public key (chiave pubblica per definizione). (4) kid injection / jku-x5u abuse: header che dichiarano la chiave da usare per la verifica. Se il backend non li sanitizza (kid usato come key path o lookup SQL) o non li pinna a domini fidati (jku/x5u), un attaccante che controlla l'input controlla la chiave.

Claim mancanti. RFC 7519 definisce claim opzionali con valore di sicurezza concreto: exp (expiration, scadenza temporale), nbf (not before, ritardo di attivazione), iat (issued at, timestamp di emissione), jti (JWT ID, anti-replay), aud (audience, mitigazione del confused deputy attack), iss (issuer, mitigazione del rogue IdP). Anti-pattern frequente: token senza exp, che vivono per sempre senza possibilità di revoca server-side né rotazione automatica; oppure senza aud, che il service A può inoltrare al service B che lo accetta perché coperto dallo stesso identity provider, anche se non era destinato a lui.

Header esoterici. Due header meno noti che il tool segnala come info: cty (content type, abilita nested JWT - un JWT dentro un JWT, vettore di confusione se il backend lo de-wrappa senza riautenticare), zip (compression: l'header {"zip":"DEF"} abilita la decompressione DEFLATE del payload, ed è stato vettore di attacchi reali via zip bomb su librerie che non limitavano la dimensione output).

Privacy operativa. Il token JWT contiene il payload con i claim utente e l'header con la configurazione di firma: in audit reali non vuoi caricarlo su un servizio terzo, anche con TLS. Qui non parte nessuna richiesta di rete con i dati del token. Il dataset di secret (10.000 entries, ~180 KB raw) viene scaricato dal browser una sola volta al primo utilizzo e cachato in localStorage per le sessioni successive (invalidazione automatica via SHA-256 sul file pubblico). Audit, parsing del JWT, verifica HMAC, brute-force sui secret, lettura della pubkey: tutto in locale via WebCrypto API.

Quando il triage statico è il livello giusto. Casi tipici. (a) Review preliminare di un'API legacy senza accesso al backend: hai catturato un token dal frontend e vuoi capire se la configurazione lato server è solida. (b) Pre-engagement audit per stimare lo sforzo di un eventuale incarico di hardening JWT prima di firmare il preventivo. (c) Screen iniziale prima di un assessment cyber serio: la lista dei high/critical va approfondita con esercizio di exploitability assessment, mappatura dei codepath di verifica nel backend, verifica della whitelist di algoritmi accettati e del pinning JWKS. (d) Self-check periodico per il proprietario dell'API che vuole sapere se l'integrazione è stata fatta a regola d'arte.

Limite di scope. L'audit non sostituisce: una review architetturale del flusso completo (rotazione delle chiavi, refresh token rotation, logout server-side con blacklist jti, audience binding, gestione del kid e jku/x5u in produzione, configurazione del provider OIDC); l'analisi statica del codice di verifica nel backend (whitelist algoritmi, leeway sull'exp, gestione delle eccezioni); lo studio del threat model specifico dell'applicazione. È un triage e si propone come tale.

L'audit applica 18 check distribuiti su 4 famiglie. Tutti i check girano in locale nel browser via WebCrypto (per le verifiche HMAC) e via parsing JSON puro per gli altri.

Famiglia 1 - Algoritmo (4 check). alg_none verifica la stringa esatta none in qualsiasi case. alg_permutation copre le varianti malevole: alg vuoto, alg numerico, alg null JSON, alg NULL/None/NoNe/nULL. alg_confusion_confirmed (richiede pubkey opzionale): se il token è HS256 e l'utente ha fornito una public key RSA, il tool tenta una verifica HMAC-SHA256 usando la pubkey come secret. Se la verifica passa, il backend accetta token HS256 firmati con la sua public key (chiave pubblica per definizione). Vettore confermato. weak_secret: bottone Audit = test contro tier fast (1.000 secret comuni, <1s); bottone Audit profondo = test contro tier full (10.000 secret aggiuntivi, 5-10s).

Famiglia 2 - Header esoterici (4 check). kid_suspicious: il valore di kid contiene caratteri tipici di path traversal (../) o SQLi (UNION, SELECT, OR, AND, --, '). jku_present e x5u_present: header che dichiarano la URL di una public key esterna; senza pinning whitelist, l'attaccante che controlla la URL controlla la chiave (HIGH). typ_missing: assenza di typ, raccomandato da RFC 7519 par. 5.1. cty_present e zip_present: header che abilitano nested JWT e DEFLATE, segnalati come INFO per ispezione manuale del codepath.

Famiglia 3 - Claim del payload (8 check). Per ogni claim RFC 7519 rilevante: presenza, formato, valore. exp_missing: token senza scadenza (HIGH). exp_expired: scadenza nel passato (INFO, mitigazione attiva). exp_far_future: exp > 1 anno nel futuro (MEDIUM). iat_missing: assenza di issued-at (LOW). lifetime_too_long: exp - iat > 30 giorni (HIGH, configurabile). aud_missing: nessun audience binding (MEDIUM, confused deputy). iss_missing: nessun issuer (MEDIUM, rogue IdP). jti_missing: nessun anti-replay ID (LOW).

Famiglia 4 - Brute-force HS256 (1 check, 2 modalità). Implementazione: il browser importa via crypto.subtle.importKey ogni candidato come HMAC key, calcola la firma del segmento header.payload via crypto.subtle.verify, confronta con la signature presente nel token. Sequenziale (HMAC-SHA256 su input piccolo non beneficia di parallelismo browser). Throughput tipico: 1.000-2.000 verify/secondo su laptop moderno. Tier fast 1.000 secret = sub-secondo. Tier full 10.000 secret = 5-10 secondi. Il dataset è ricompilato ogni notte da shared/cron/build_jwt_secrets_db.php tramite union(wallarm, SecLists), dedup case-insensitive, cap a 10.000 entries (gli oltre 90.000 della long tail vengono droppati: dopo i primi 10k il match rate aggiuntivo è marginale e il costo browser non lo giustifica).

Atomicità delle pubblicazioni. Il job cron applica una scrittura atomica multifile: i tier vengono scritti su file temporanei, rinominati uno per uno, e l'index.json con i nuovi SHA-256 è l'ultimo file rinominato. Se il processo muore a metà, i client continuano a leggere il dataset precedente. Mai dataset parziale. Se le sorgenti upstream falliscono, il job aborta senza pubblicare: meglio dataset vecchio di un giorno che dataset incompleto.

Punteggio aggregato 0-100. Calcolato come 100 - somma(severity_weights), dove i pesi sono: critical 50, high 20, medium 10, low 5, info 0. Lettura: 80-100 verde (postura ragionevole), 50-79 giallo (interventi pianificabili), 0-49 rosso (rischio significativo, alcuni vettori richiedono mitigation immediata). Il punteggio non misura la qualità del backend complessivo, solo la postura del singolo token rispetto ai pattern OWASP/CVE noti.

Severity dei finding. critical: vettore confermato che permette forgery o bypass di firma diretto (alg=none accettato, alg confusion verificato, secret HS256 trovato nel dataset). Mitigation immediata. high: vettore probabile ma non confermato dal solo manifest (jku/x5u senza poter verificare il pinning lato backend, secret weak in tier non testato, lifetime troppo lungo, exp missing). Da approfondire e mitigare in sprint corrente. medium: pratica subottimale che riduce le difese in profondità (aud/iss missing, kid suspicious, exp far future). Backlog di hardening. low: best practice mancata (iat/jti missing). Cleanup quando opportuno. info: stato osservazionale (typ missing, exp expired, cty/zip present). Reporting only.

Cosa fare in concreto, per priorità. (1) alg=none / alg permutation CRITICAL: il backend deve rifiutare esplicitamente tutti i valori di alg fuori da una whitelist (HS256, RS256, ES256). Patch immediata, test di regressione con token malformati. (2) alg confusion confermato CRITICAL: il backend deve usare API con verifica per algoritmo specifico (es. jwt.verify(token, key, { algorithms: ['RS256'] }) in jsonwebtoken), non auto-detect dell'algoritmo dall'header. (3) weak secret HIGH/CRITICAL: ruotare immediatamente il secret a una stringa casuale crypto-safe da 32+ byte (openssl rand -base64 32) e invalidare tutti i token in circolazione. (4) jku/x5u HIGH: il backend deve pinnare la URL whitelist o ignorare completamente questi header e usare solo JWKS endpoint hardcoded. (5) kid suspicious MEDIUM: validare kid contro whitelist alfanumerica, lookup esatto in mappa interna, mai usarlo come parametro di query SQL o file path. (6) claim missing: aggiungere exp, aud, iss, jti al template di emissione del token. Validare lato server con leeway ragionevole (5-30 secondi).

Format del finding alg confusion. Quando il check passa con la pubkey fornita, il finding riporta: il token, la public key usata come secret, l'algoritmo dichiarato nell'header, una descrizione testuale del vettore. Da girare al team con il messaggio operativo: "il backend deve verificare il token con l'algoritmo specifico atteso, non con quello dichiarato dall'header. Patch suggerita: vincolare l'algoritmo nella signature di verify, oppure rifiutare HS256 a livello applicativo se l'architettura usa RS256".