Strumenti per sviluppatori · Decodificatore JWT
L'attacco alg:none e la confusione dei tasti: perché i verificatori devono bloccare gli algoritmi
· Perché è importante
jwt sicurezza crittografia
Se un verificatore consente al token di scegliere il proprio algoritmo, un utente malintenzionato può sceglierne nessuno o scambiare RSA con HMAC. Questo post spiega sia gli attacchi che la regola che li previene.
Il token che si è verificato: come un campo di intestazione è diventato una superficie di attacco
Un'etichetta dell'algoritmo si trova all'interno dell'input del token controllato dall'aggressore. Se un verificatore tratta quell'etichetta come un'autorizzazione a selezionare qualsiasi modalità di convalida disponibile, il token inizia a influenzare la regola utilizzata per giudicare se stesso. ToolAcre espone l'etichetta in modo preciso in modo che i revisori possano vederla, ma non agisce mai in modo crittografico.
La direzione sicura è l'inverso: la configurazione del servizio affidabile definisce le famiglie di algoritmi accettabili e le chiavi associate, quindi le intestazioni in entrata devono corrispondere a tale politica. Un pannello di decodifica non può fornire tale policy e non deve essere confuso con protezione semplicemente perché evidenzia un valore sospetto.
Il repository contrassegna alg:none ma non stabilisce la cronologia delle specifiche dietro i JWT non protetti
L'implementazione tratta `alg: none` come una dichiarazione non firmata e avverte che accettandola si accetterebbero contenuti arbitrari. Inoltre segnala separatamente un terzo segmento vuoto. Le prove del repository supportano il rifiuto di tale input nei flussi di lavoro autenticati; non documenta il motivo per cui i JWT non garantiti erano originariamente inclusi in una specifica.
Quella formulazione storica è quindi corretta piuttosto che inventata. Ciò che conta dal punto di vista operativo è chiaro: un servizio che prevede credenziali firmate non deve consentire a un'intestazione del token di disabilitare il controllo della firma. ToolAcre di per sé non esegue alcuna verifica, quindi la sua capacità di visualizzare `none` è il rilevamento solo a scopo di ispezione.
L'attacco alg:none: rimuove la firma e chiede al verificatore di accettarne una vuota
Un attacco non firmato modifica l'intestazione nella richiesta `none`, modifica le attestazioni se lo si desidera e non fornisce byte di firma. Ogni segmento può ancora essere sintatticamente valido e i primi due decodificati in JSON lucido. Un verificatore permissivo convertirebbe la preferenza dell’aggressore in un bypass dell’autenticazione.
Un verificatore rigoroso non ha un ramo che aggiorna questo input allo stato attendibile quando sono richiesti token firmati. L'avviso di ToolAcre aiuta a identificare la forma durante il debug, ma leggere la parola `none` non impedisce a un backend di prendere una decisione sbagliata. L'applicazione avviene nel luogo in cui vengono consumate le credenziali.
Confusione delle chiavi: presentazione di una chiave pubblica come segreto HMAC in modo che i token RS256 vengano verificati come HS256
La confusione sulle chiavi si verifica quando un verificatore consente famiglie di algoritmi con ruoli chiave incompatibili e non riesce a associare ciascuna scelta al tipo di chiave corretto. Una chiave di verifica pubblica RSA non è un segreto HMAC. Trattare i suoi byte come uno solo dopo che un utente malintenzionato ha modificato l'etichetta di un algoritmo comprime la separazione public/private prevista.
Prevenire questa classe di errore richiede qualcosa di più del semplice controllo di un segmento a forma di firma. Il servizio deve associare l'algoritmo previsto, il tipo di chiave, l'emittente e il profilo del token tramite una configurazione attendibile. Un decodificatore che mostra RS256 o HS256 non può dire se il backend mantiene tali associazioni.
La soluzione: blocca gli algoritmi accettati nel verificatore e non ricavarli mai dal token
Blocca gli algoritmi accettati nella configurazione del verificatore e mantieni l'elenco ristretto quanto consentito dal contratto dell'emittente. Rifiuta `none` per i flussi di credenziali firmate e rifiuta le mancate corrispondenze anziché provare un altro algoritmo. Non derivare la lista consentita dall'intestazione non verificata o da un'attestazione di payload.
La ricerca chiave segue lo stesso principio. Un `kid` può scegliere tra candidati già attendibili, ma non deve creare una nuova fonte di attendibilità. Gli URL di intestazione o le chiavi incorporate non devono essere seguiti semplicemente perché il token li richiede. Il verificatore decide autonomamente le sue fonti.
Esempio funzionante: leggere un'intestazione nel decodificatore ToolAcre JWT per individuare alg:none e perché individuarlo non equivale a essere protetto
Crea un'intestazione del token innocua che dichiari `none` e lascia vuoto il terzo segmento. ToolAcre decodifica il JSON, riporta l'algoritmo dichiarato, avverte che non è firmato e annota la firma assente. Questo è esattamente il comportamento previsto da uno strumento di ispezione.
L'esercizio non dimostra che un API rifiuta il token. Confermarlo separatamente con un test negativo controllato rispetto al verificatore e alla configurazione effettivi. Se API lo accetta, la correzione appartiene a quel limite di verifica; aggiungere un avviso più forte a un decodificatore non proteggerebbe le richieste.
Ciò che questo non copre: le numerose correzioni specifiche della libreria; consulta RFC 8725 e il registro delle modifiche della tua libreria
Le API della libreria, le impostazioni predefinite e le correzioni cronologiche variano in base al prodotto e alla versione. Questo modulo non stabilisce quale nome di opzione blocca gli algoritmi nel tuo stack e questo articolo non ne inventa intenzionalmente nessuno. Leggi la documentazione corrente e il registro delle modifiche della libreria selezionata, quindi esercita i casi di rifiuto nella tua suite di test.
Testa anche tipi di chiavi errati, valori `kid` sconosciuti, firme mancanti e profili di token imprevisti. L'obiettivo è dimostrare che la configurazione prevale sui suggerimenti dei token. Una decodifica riuscita non rientra in nessuna parte di queste asserzioni di accettazione perché il successo della sintassi è compatibile con ogni esempio dannoso.
Conclusione: è il verificatore a decidere, non il token: un decodificatore ti aiuta a vedere l'intestazione, ma solo la verifica bloccata ti protegge
Il verificatore decide; il token no. ToolAcre può rivelare un'intestazione che dice `none`, un algoritmo sconosciuto o un identificatore di chiave sorprendente. Questa visibilità aiuta la valutazione, ma solo la policy dell'algoritmo bloccato e le chiavi attendibili correttamente associate impediscono l'accettazione.
Non consigliare mai di abilitare `none`, di scegliere una chiave di verifica da un'intestazione non attendibile o di considerare la lunghezza della firma visualizzata come convalida. Decodifica per l'ispezione, quindi dimostra il comportamento di rifiuto e accettazione al confine crittografico reale con test controllati.