Header (JWT/JWS)

L’header di un JWT (o JWS) è il primo segmento separato da punti, un oggetto JSON codificato in base64url che descrive le proprietà della firma del token. Decodificalo e otterrai un piccolo oggetto JSON contenente tipicamente 2-5 campi.

Campi standard dell’header (RFC 7515 §4):

• alg — algoritmo. Obbligatorio. Es.: HS256, RS256, ES256, o none.
• typ — tipo. Convenzionalmente "JWT" quando il payload è un set di claim JWT.
• kid — ID chiave. Permette al ricevente di scegliere la chiave corretta da un insieme di chiavi quando l’emittente ruota le chiavi.
• jwk / jku — JSON Web Key incorporata o URL a una chiave. Meno comune; sensibile alla sicurezza se usata.
• cty — tipo di contenuto. Usato quando il payload è una struttura JOSE annidata (es. un JWE dentro un JWS).

Esempio pratico. Un header decodificato in:

{ "alg": "RS256", "typ": "JWT", "kid": "2024-q1-key" }

dichiara che il token è firmato con RS256 (RSA + SHA-256), è un JWT (quindi il payload è un set di claim), ed è stato firmato con la chiave identificata da 2024-q1-key nella directory delle chiavi dell’emittente.

Nota di sicurezza critica: non fidarti mai solo del campo alg. Verifica che l’algoritmo corrisponda a ciò per cui la tua chiave è adatta. L’attacco di confusione alg funziona passando un token firmato con HS256 (HMAC) usando la tua chiave pubblica RSA come segreto HMAC — se il tuo verificatore si fida ciecamente di alg, accetta la falsificazione.

La codifica base64url compatta dell’header lo rende ispezionabile dall’uomo: incollare il primo segmento separato da punti di qualsiasi JWT in un decodificatore base64url rivela l’algoritmo e il riferimento alla chiave in pochi secondi. Questo è il punto di ingresso di ogni sessione di debug JWT — se l’header si decodifica in spazzatura, il token è malformato; se si decodifica in un oggetto JSON che non riconosci, l’emittente ha cambiato qualcosa.

Quando e perché è importante

L’header JWT è importante ogni volta che un servizio verifica un token. La catena CVE classica: un verificatore accetta il campo alg per quello che è e lascia passare un token che specifica "alg": "none" senza alcuna verifica della firma. Questo bug è arrivato in librerie di produzione fino al 2015 (CVE-2015-9235, che ha interessato node-jsonwebtoken di Auth0). La difesa è imporre, nella chiamata di verifica, l’algoritmo esatto che la libreria dovrebbe accettare — es. jwt.verify(token, key, { algorithms: ['RS256'] }) — e non fidarsi mai dell’header per scegliere l’algoritmo. Una seconda classe di bug, l’attacco di confusione alg, sfrutta librerie che selezionano automaticamente HMAC vs RSA in base all’header: l’attaccante passa al verificatore un token che dichiara HS256 ma lo firma con la chiave pubblica RSA (che è pubblica) usata come segreto HMAC. Il verificatore valida rispetto alla chiave pubblica e accetta la falsificazione. Entrambi i bug sono problemi di fiducia nell’header. Per le nuove integrazioni JWT, controlla la chiamata di verifica e verifica che fissi l’algoritmo. Riferimento: OWASP — Cheat sheet JSON Web Token.

Il campo kid nell’header per la rotazione delle chiavi in produzione: in qualsiasi sistema reale che emette token su larga scala, la chiave di firma deve ruotare periodicamente — ogni 90 giorni è una politica comune. Il campo kid consente all’emittente di pubblicare più chiavi contemporaneamente (chiavi vecchie per token in transito, nuove chiavi per nuove emissioni) e al verificatore di scegliere quella giusta da un endpoint JWKS. Il pattern di rotazione standard: annunciare la nuova chiave nel JWKS continuando a firmare con quella vecchia, attendere un token-lifetime, passare l’emissione alla nuova chiave, attendere un altro lifetime, poi rimuovere la vecchia chiave dal JWKS. Il campo kid è ciò che rende questo processo fluido — senza di esso, la rotazione delle chiavi richiede una migrazione sincronizzata in un giorno preciso.

Come appare il vettore di attacco jku / x5u: alcune implementazioni consentono all’header di puntare a un URL arbitrario dove presumibilmente risiede la chiave di verifica. Un attaccante che imposta jku a un URL che controlla può presentare qualsiasi chiave voglia e il verificatore la userà. Le linee guida moderne (RFC 8725, best practice JOSE) sono di rifiutare completamente jku/x5u oppure imporre una lista di URL affidabili. Le nuove integrazioni JWT non dovrebbero fare affidamento sulla posizione della chiave controllata dall’header. Riferimento: RFC 8725 — Best Current Practices per JSON Web Token.