Posso impedire un attacco di riproduzione dei miei JWT firmati?

La rivendicazione jti come descritto qui è un meccanismo facoltativo per impedire ulteriori attacchi di riproduzione. Dalla specifica:

4.1.7. "jti" (JWT ID) Claim

The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The "jti" claim can be used to prevent the JWT from being replayed. The "jti" value is a case- sensitive string. Use of this claim is OPTIONAL.

Questo in definitiva rende lo stato del tuo server, ma previene i replay illimitati se rilevi comportamenti anomali o se un utente segnala attività sospette. Considera il seguente scenario.

1. Un utente effettua l'accesso. Il server genera una JWT e memorizza la firma e alcuni metadati (l'ID utente e il tipo di client che effettua la richiesta, forse, e jti ).
2. L'utente segnala comportamenti sospetti.
3. L'applicazione "firma" l'utente di tutti i dispositivi eliminando tutti i JWT nel backend store collegato a quell'utente. Ora l'applicazione può dire "So che hai una firma valida, ma non la accetto perché non l'ho creata".
   • Se i tuoi metadati sono sufficientemente precisi, puoi utilizzare jti e ulteriori informazioni, ad esempio, solo per firmare l'utente da determinati dispositivi.

Come accennato in precedenza, questo rende inevitabilmente lo stato del tuo server. Questo inoltre non esclude a priori gli attacchi di replay, ma può bloccare ulteriormente tali attacchi dopo che uno è stato rilevato.

Un metodo alternativo / aggiuntivo PU CAN a titolo definitivo prevenire attacchi di replay in una certa misura, a rischio di potenziali disagi per l'utente. Rendi l'indirizzo IP dell'utente parte della richiesta E memorizza i metadati al momento dell'accesso e verifica che l'IP che utilizza il JWT sia quello che ti aspetti. Questo può essere frustrante per un utente che dice che lavora sia da casa che da un bar, ma potrebbe essere un requisito accettabile per applicazioni ad alta sicurezza.

Se c'è codice in esecuzione nello stesso contesto della tua applicazione web, se faceva parte di un attacco XSS nel browser, o qualche malware / virus sulla macchina degli utenti, sarebbe difficile (impossibile?) differenziare quelli richieste da parte tua.

Se l'utente malintenzionato ha accesso al computer, potrebbe anche solo rubare i dati dalle normali richieste delle applicazioni al tuo server.

Potenzialmente, potresti eseguire un'analisi dello stile di rilevamento delle intrusioni sul lato server: ad es. verificare un numero elevato di richieste o conteggi di articoli; applica alcuni schemi di referrer personalizzati dove sai quali componenti della tua applicazione web fanno richieste di dati. Quindi potrebbe attivare una riautenticazione quando si rileva un comportamento anomalo? Avresti anche bisogno di un modo lato server per far scadere il tuo JWT sopra il exp incorporato nel JWT.

Perché non avere una data come carico utile e scadenza? Non è necessario modificare il payload e la logica dell'applicazione può far scadere il token. Oppure usa un nuovo segreto basato su una natura foglia (simile a DUKPT ) così una nuova richiesta di token invalida quella precedente.