I pericoli del JWT senza scadenza: vulnerabilità di sicurezza nascoste

I token web JSON (JWT) sono diventati il metodo di autenticazione preferito da molte organizzazioni. Sono facili da implementare e rappresentano una scelta popolare per proteggere le API e le applicazioni web. Tuttavia, se non gestiti correttamente, i JWT possono introdurre vulnerabilità di sicurezza, mettendo a rischio i vostri sistemi. Probabilmente li avete usati anche voi.

Ma li avete implementati e gestiti in modo sicuro?

Un post sul blog di Akamai ha evidenziato diverse vulnerabilità di sicurezza comuni associate ai JWT. È stato un campanello d'allarme sui rischi potenziali di una gestione impropria dei JWT. In questo blog post, desidero fare leva su questo aspetto, concentrandomi su un'ulteriore vulnerabilità spesso trascurata: i JWT che non scadono. Analizzeremo come si presenta questo problema e le vulnerabilità di sicurezza associate. Poi vi offrirò alcune indicazioni per sapere come proteggervi da queste vulnerabilità di sicurezza.

Panoramica delle vulnerabilità JWT comuni

Prima di immergerci nella questione, rivediamo brevemente le vulnerabilità dei JWT evidenziate nel post del blog di cui sopra. Le sei minacce ai JWT citate dall'autore sono:

1. Consentire al server di utilizzare un token senza convalida: Questo può accadere quando il server non verifica l'integrità del token, rendendo più facile per gli aggressori manipolarlo e sfruttarlo. Gli aggressori possono anche impostare l'algoritmo di verifica (alg) su nessuno, cercando di manipolare il server affinché non convalidi affatto il token.
2. Utilizzo della stessa chiave privata per applicazioni diverse: Questa pratica può compromettere più applicazioni se la chiave viene esposta.
3. Utilizzo di un algoritmo di firma debole: Gli algoritmi di firma deboli possono essere violati più facilmente, con conseguente accesso non autorizzato.
4. Scegliere una chiave privata breve e/o a bassa entropia: Le chiavi troppo corte o prive di casualità sono più suscettibili agli attacchi di forza bruta.
5. Mantenere i dati sensibili nel payload di un JWT: Le informazioni sensibili memorizzate nel payload possono essere esposte se il token viene intercettato.
6. Confondere le chiavi: Una gestione errata delle chiavi può portare a una convalida non corretta, consentendo un accesso non autorizzato.

Per una descrizione dettagliata di queste vulnerabilità, consultate il post sul blog. Passiamo ora a un'altra vulnerabilità: il JWT che non scade.

Vulnerabilità aggiuntiva: JWT non scadenti

Vediamo il seguente JWT, basato su un esempio reale che ho incontrato non molto tempo fa:

Si tratta di un JWT utilizzato per autenticare e autorizzare l'accesso di un utente a un'API. È firmato con un segreto sicuro per evitare lo spoofing. A prima vista, sembra tutto a posto. Ma guardiamo più da vicino il payload:

Quando si guarda all'indicazione ttl, probabilmente si pensa al time-to-live, perché questo è il significato tipico di TTL. Quindi, probabilmente ha a che fare con la durata della validità del JWT. Questo deve essere il tempo di scadenza.

Possiamo fare qualche semplice calcolo. Forse 86.400.000 è il numero di secondi, nel qual caso l'emittente intende che questo JWT sia valido per 1000 giorni. O forse intendono millisecondi, nel qual caso intendono che questo JWT sia valido per 1 giorno. Anche questo potrebbe avere senso.

Ma ecco il problema: le specifiche JWT dicono che il tempo di scadenza è specificato come exp, non come ttl:

Abbiamo quindi un paio di problemi.

Innanzitutto, l'emittente di questo JWT utilizza ttl per specificare la scadenza, ma ttl non è un'istruzione JWT standard. La maggior parte delle librerie progettate per gestire i JWT non riconoscerà ttl come un'istruzione relativa alla scadenza del token. Ciò comporterà problemi di compatibilità e il token sarà probabilmente trattato come non scadente.

In secondo luogo, l'indicazione exp richiede un timestamp effettivo di scadenza, non un numero relativo di millisecondi (o secondi) dal momento dell'emissione. Questa confusione deriva probabilmente dall'uso di ttl piuttosto che di exp. Tuttavia, l'emittente deve comprendere il formato previsto per la richiesta di scadenza per garantire la corretta scadenza del token.

Se si trascura di impostare il tempo di scadenza di un JWT o lo si imposta in modo errato (come nel nostro esempio), il JWT verrà trattato come non scadente. E questo rappresenta una significativa falla nella sicurezza.  

Mitigazione delle vulnerabilità della sicurezza JWT

Ora che abbiamo analizzato le potenziali vulnerabilità di sicurezza, la domanda successiva è: cosa fare? Fortunatamente, la mitigazione di questa vulnerabilità è semplice e immediata!

Utilizzate sempre la richiesta discadenza. Impostate un tempo di scadenza per ogni token generato. Quando lo si fa, assicurarsi di usare il claim exp standard con il formato del valore atteso per garantire che sia conforme alle specifiche JWT e che scada come previsto.

Aggiornare applicazioni e librerie. Assicuratevi che la vostra applicazione e le librerie utilizzate siano aggiornate e aderiscano agli ultimi standard JWT. Gli aggiornamenti regolari aiutano a risolvere le vulnerabilità di sicurezza e a migliorare la compatibilità.

Tutto qui. Seguendo queste semplici linee guida, ridurrete significativamente il rischio di accesso non autorizzato tramite un JWT non scaduto. Questo migliorerà la sicurezza complessiva delle vostre implementazioni JWT.

Conclusione

Comprendere e affrontare le vulnerabilità dei JWT è fondamentale per mantenere la sicurezza delle vostre applicazioni. In questo post abbiamo evidenziato il rischio dei token che non scadono. Utilizzando correttamente l'exp claim e mantenendo aggiornate le librerie, è possibile mitigare efficacemente questo rischio.

Per ulteriori soluzioni di sicurezza e best practice, esplorare le risorse disponibili nella documentazione Linode. Linode offre guide complete per aiutarvi a rimuovere le vulnerabilità di sicurezza dalle vostre applicazioni.