Strumenti per sviluppatori · Decodificatore JWT
RFC 8725 Spiegazione: JWT Migliori pratiche attuali per i verificatori
· Sfondo
jwt sicurezza autenticazione
IETF ha raccolto le insidie note di JWT in un unico documento sulle migliori pratiche attuali. Questo post illustra i suoi consigli e li collega alla classe di incidenti che previene.
Gli errori ricorrenti di JWT motivano una lista di controllo del verificatore; le fonti del repository non stabiliscono la cronologia delle pubblicazioni
I formati di token flessibili consentono combinazioni che un verificatore deve vincolare. Gli errori ripetuti includono la fiducia nelle etichette degli algoritmi, l'accettazione di un token sotto l'emittente o il pubblico sbagliato e il seguire il materiale chiave selezionato dall'aggressore. Una lista di controllo converte questi rischi ampi in test di rifiuto al limite di accettazione effettiva.
Lo schema attribuisce la cronologia delle pubblicazioni a un anno particolare, ma le fonti del repository non verificano tale cronologia, quindi questa sezione la omette. La distinzione attuabile viene stabilita localmente: ToolAcre solo decodifica, mentre ogni decisione sulle migliori pratiche appartiene a un verificatore configurato.
Algoritmi blocca e rifiuta nessuno: le raccomandazioni che affrontano alg:none e la confusione dei tasti
Gli algoritmi consentiti sono bloccati indipendentemente dall'intestazione e rifiutano l'input non firmato nei flussi che richiedono una firma. Associa ciascuna famiglia di algoritmi accettata al tipo di chiave corretto. Non consentire a un token di cambiare un verificatore dal controllo asimmetrico a HMAC o di disabilitare il controllo con `none`.
ToolAcre segnala `none` e spiega le etichette riconosciute, ma questi avvisi non impongono nulla. Dimostra la vera politica con test negativi sul backend: algoritmi imprevisti, firme vuote e tipi di chiavi errati devono fallire anche se i loro primi due segmenti rimangono decodificabili.
Convalida del pubblico e dell'emittente: raccomandazioni contro la riproduzione cross-service
Autentica l'emittente con la configurazione della chiave attendibile, quindi confronta il pubblico previsto con il servizio che lo utilizza. Una firma valida senza controlli delle attestazioni contestuali può comunque autorizzare un token nel posto sbagliato. Una stringa dell'emittente copiata di per sé non costituisce un'associazione di tasti.
Il decodificatore mostra i valori `iss` e `aud` senza conoscere la configurazione prevista. Usa quella visibilità per identificare i casi di test, non per emettere un verdetto. I test di accettazione dovrebbero distinguere l’emittente sbagliato, il pubblico sbagliato e il fallimento della firma in modo che i registri operativi rimangano utili.
Utilizza la digitazione esplicita: l'intestazione typ come difesa contro la sostituzione dei token
La tipizzazione esplicita del token può separare i profili che altrimenti riutilizzerebbero forme di attestazione simili. Il verificatore dovrebbe sapere quale tipo si aspetta per un particolare endpoint e rifiutare profili incompatibili anziché trattare ogni JWT firmato come intercambiabile.
Un'intestazione `typ` non è ancora attendibile fino alla verifica e ToolAcre avvisa solo quando la sua stringa è diversa da `JWT`. Non convalida i profili dei token di accesso, i contenuti nidificati o le convenzioni dei provider. Definire le regole del tipo nell'applicazione e testare i tentativi di sostituzione.
Non fidarti di jku, x5u o delle chiavi incorporate: i consigli sulla fonte delle chiavi
Non consentire che i dati `jku`, `x5u`, i dati JWK incorporati o gli array di certificati stabiliscano un'origine della chiave semplicemente perché compaiono in un'intestazione protetta. Risolvi le chiavi attraverso una relazione con un emittente di fiducia indipendente e una politica di recupero vincolato. Tratta `kid` solo come un selettore all'interno di quel limite.
ToolAcre non esegue alcuna ricerca di rete dai valori dell'intestazione. Questo è il comportamento corretto per un ispettore generico. Durante un audit, traccia ogni percorso dai metadati dell'intestazione alle operazioni di file system, cache, database e rete, quindi rifiuta qualsiasi percorso che crei fiducia dall'input controllato da token.
L'input crittografico e le indicazioni sul contenuto crittografato devono essere controllati nella libreria e nel profilo scelti
Le implementazioni crittografiche devono convalidare gli input e seguire le regole del profilo selezionato. Anche i progetti di crittografia richiedono attenzione alla compressione e ai dati osservabili. Le API esatte e le impostazioni predefinite sono specifiche della libreria e non sono presenti in questo repository, quindi questo articolo non inventa opzioni né rivendica il supporto universale.
Leggi la documentazione corrente per la libreria e la versione distribuita, quindi crea test di input non valido e di mancata corrispondenza delle policy. Gli errori INVALID_JWT puliti del decodificatore dimostrano una buona ergonomia di ispezione, ma non sono la prova che un verificatore separato gestisca correttamente i casi limite crittografici.
Esempio pratico: controllo di una routine di verifica rispetto alla lista di controllo
Controlla una routine di verifica elencando la configurazione dell'emittente attendibile, gli algoritmi accettati, la fonte della chiave, il pubblico, il tipo di token, la policy temporale e le attestazioni dell'applicazione. Per ogni elemento, aggiungi un token negativo che sia sintatticamente leggibile ma che violi esattamente un'aspettativa. Confermare il rifiuto al confine reale.
Utilizza ToolAcre solo per verificare ciò che afferma ciascun dispositivo e garantire che sia presente la mutazione prevista. Non utilizzare il suo output come affermazione che l'apparecchiatura non è valida. La risposta del verificatore e i log forniscono tale prova, mentre il decodificatore rimane costante negli esempi accettati e rifiutati.
Conclusione: una lista di controllo, non una libreria: il decodificatore ToolAcre JWT ti aiuta a ispezionare i token durante l'audit; le pratiche si applicano al verificatore che scrivi
Un documento di best practice è una lista di controllo, non una libreria di verifica. Il suo valore appare quando i team traducono le raccomandazioni in configurazioni esplicite, relazioni di fiducia ristrette e test che non riescono a chiudersi. Un decodificatore può rendere leggibile l'input del token durante quel lavoro ma non può implementare i controlli.
Mantenere il confine nella documentazione e nell'interfaccia utente: decodificato significa leggibile, non autentico, non modificato, autorizzato o accettabile. Blocca la policy all'esterno del token, verifica prima e poi applica le rivendicazioni. ToolAcre si ferma intenzionalmente prima di tutte queste decisioni.