Flusso di lavoro di protezione JWT e CSRF

Question

Flusso di lavoro di protezione JWT e CSRF

#1 da (1 voti)
#2 da (0 voti)

2

Ho uno schema di autenticazione e autorizzazione personalizzato basato su tre token JWT: token di riferimento (opaco), token di accesso e token di aggiornamento. Il backend imposta il token di riferimento in un cookie e lo invia ad ogni richiesta al server.

Poiché, sto usando i cookie, ho bisogno di prevenire l'attacco CSRF. Ho scritto questo SO thread e questo articolo di stormpath , ma non riesco ancora a ottenere il flusso di lavoro, che dovrei seguire per prevenire l'attacco CSRF.

Il mio payload del token di riferimento è simile a

{
    "iss": "http://galaxies.com",
    "exp": 1300819380,
    "scopes": ["explorer", "solar-harvester", "seller"],
    "sub": "[email protected]",
    "jti": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

solo una proprietà xsrfToken , sto usando un campo standard jti . Quindi, il mio cliente ha questo token di riferimento con questo campo jti , questo token di riferimento viene inviato al server ad ogni richiesta, il server può decodificare questo token di riferimento e trovare da jti il valore corrispondente token di accesso nella sua cache. Ora mi chiedo se questo schema mi impedisce attacchi CSRF o dovrei fare alcuni passaggi aggiuntivi sul lato server e lato client per fare questo?

Quello che non capisco è perché dovrei impostare un nuovo X-XSRF-TOKEN di intestazione sul lato server e cosa dovrei fare con questa intestazione in seguito.

jwt csrf

posta Jacobian 29.08.2017 - 12:50

fonte

2 risposte

Leggi altre domande sui tag jwt csrf

Per quanto tempo dovrebbe essere un codice di conferma dell'email per evitare la forzatura bruta Quali requisiti di sicurezza dovrebbero implementare una VPN L2L al fine di proteggere un'estremità dall'altra?

score 1 · Answer 1

Sono nella tua stessa situazione, ed ecco come ho capito il processo:

Il server invia il token JWT tramite Set-Cookie ... ; Secure ; HttpOnly . Ciò impedirà a Javascript sul client di leggere il token JWT e quindi impedirà agli attacchi XSS di rubare il token JWT.
Il server invia anche un token XSRF che il Javascript sul lato client può accedere, in un'intestazione aggiuntiva, in un cookie leggibile sul lato client o come risposta alla richiesta di token JWT. Il client deve quindi aggiungere attivamente questo token XSRF a ogni richiesta, ad esempio come intestazione aggiuntiva. Anche il token XSRF fa parte del token JWT, quindi il server può verificare che entrambi corrispondano.

Ciò impedisce gli attacchi CSRF, perché mentre l'attaccante CSRF può far sì che il cookie con il token JWT sia inviato insieme a una richiesta, non può leggere il token XSRF e, quindi, non può aggiungerlo alla richiesta.
Il token di aggiornamento funziona allo stesso modo.

Questo non impedisce lo scenario in cui un attacco XSS esegue richieste includendo il token XSRF da solo. Impedisce solo a un attacco XSS di rubare il token completo e usarlo da qualche altra parte. Tuttavia, dato che gli attacchi XSS possono fare praticamente tutto ciò che Javascript sul lato client può, questo è probabilmente il più lontano possibile.

La protezione del token JWT di accesso contro il furto tramite XSS non è così importante, tuttavia proteggere il token JWT refresh contro il furto è estremamente importante. Il token JWT di accesso ha speranze di avere una breve scadenza, ma un token JWT di aggiornamento rubato non può essere revocato, poiché il token è senza stato, quindi garantisce l'accesso illimitato all'utente malintenzionato. È ancora possibile modificare le chiavi utilizzate per firmare il token JWT, ma invalida tutti i token JWT.

Anche il processo hwole non protegge da alcun tipo di attacco MITM, quindi usare https è importante.

Poiché l'XSRF può davvero essere qualsiasi cosa, non vedo perché non si possa usare il campo jti che è già presente. Tuttavia, lo sforzo extra da parte del cliente per aggiungere queste informazioni ad ogni richiesta è fondamentale.

score 0 · Answer 2

In breve, l'attacco XSRF può essere sfruttato quando visiti un sito Web di un utente malintenzionato e fai clic su un modulo che si innesca, ad esempio, transazioni monetarie su un sistema bancario online che non dispone della protezione XSRF, ovviamente devi anche avere una sessione attiva su quel sistema.

Affinché l'attacco abbia esito positivo, tutti i tuoi cookie di sessione devono essere trasferiti al sistema bancario e poiché tutti i cookie vengono trasferiti di default dal browser, l'attacco avrà esito positivo.

Quindi per prevenire l'attacco qualcosa in più dovrebbe essere richiesto dal server, nel caso con XSRF quella cosa è un token, il cosiddetto token XSRF.

Nel tuo caso hai usato il cookie di riferimento come cookie XSRF e come cookie di sessione, quindi l'attacco sarebbe sfruttabile. Ciò significa che è necessario separare il token XSRF dal cookie di riferimento