Vulnerabilità di JWT: alg=none e confusione delle chiavi

I JWT sono firmati crittograficamente, ma molte librerie presentavano vulnerabilità gravi. Le più sfruttate sono l'attacco alg=none, l'attacco di confusione RS256→HS256 e il brute forcing di segreti deboli. Tutte derivano dal fidarsi di campi dell'header controllati dall'attaccante.

La specifica JWT consente alg:"none" per i token non protetti. Le librerie difettose lo accettavano e saltavano completamente la verifica della firma. Un attaccante modifica il payload (ad es. "role":"admin"), imposta alg:"none", rimuove la firma e il server accetta il token.

Originale: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG Attacco: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (firma vuota, punto finale). Un server vulnerabile verifica con successo e concede l'accesso da amministratore.

Non accettare mai alg:"none" in produzione. Inserire esplicitamente nella whitelist gli algoritmi consentiti: jwt.decode(token, key, algorithms=["HS256"]). La maggior parte delle librerie moderne (PyJWT 2+, jsonwebtoken 9+) rifiuta alg=none per impostazione predefinita.

Se un server usa RS256 e un client modifica alg in HS256, il server potrebbe verificare usando la propria chiave pubblica RSA come segreto HMAC. Dato che la chiave pubblica è... pubblica, l'attaccante firma payload arbitrari con essa e il server li verifica.

Passaggi: 1) Recuperare la chiave pubblica dall'endpoint JWKS. 2) Costruire un payload dannoso. 3) Firmare con HMAC-SHA256 usando i byte PEM grezzi della chiave pubblica come segreto HMAC. 4) Impostare alg:"HS256" nell'header. 5) Il percorso HS256 del server verifica con successo.

Specificare sempre esplicitamente l'algoritmo previsto nella chiamata di verifica. Non ricavare mai l'algoritmo dall'header del token. Usare percorsi di codice separati per RS256 e HS256, che non possano essere scambiati dal chiamante.

HS256 con segreti deboli (meno di 256 bit di entropia) può essere violato con un attacco di forza bruta offline. Strumenti come hashcat supportano il cracking dei JWT: hashcat -a 0 -m 16500 token.txt wordlist.txt. Usare segreti crittograficamente casuali di almeno 32 byte.

L'header kid (ID della chiave) seleziona quale chiave usare. Se il server usa kid come parametro di una query SQL o come percorso del filesystem senza sanificarlo: kid="../../dev/null" → HMAC con chiave vuota → token contraffatto accettato. Sanificare sempre kid.

L'header jwk incorpora una chiave pubblica per la verifica. Un server vulnerabile potrebbe usare direttamente la chiave incorporata, consentendo all'attaccante di fornire la propria coppia di chiavi, firmare il token con la chiave privata e incorporare quella pubblica. Verificare solo rispetto a chiavi registrate.

Alcune implementazioni dimenticavano di controllare il claim exp oppure usavano l'ora del server in modo incoerente. Validare sempre esplicitamente exp, nbf e iat. Usare una libreria che li controlli per impostazione predefinita e non disabilitare mai la validazione dei claim in produzione.

Le vulnerabilità JWT derivano dal fidarsi dell'header alg, dall'accettare alg=none e dall'usare segreti deboli. Correzione: vincolare gli algoritmi nel verificatore, usare segreti robusti e sanificare kid. Prossimo argomento: pratiche per un'implementazione sicura dei JWT.