Vantaggi di più token CSRF validi

My question is: What are advantages of multiple valid CSRF tokens?

In generale, non c'è un particolare vantaggio in termini di sicurezza ... il bit importante su un token è quando e come diventa non valido (come nella precedente discussione sull'eventualità che un token non sia valido dopo una singola richiesta o meno). Quando e quanti token sono generati è più un dettaglio di implementazione:

Se si implementano token CSRF come valori casuali archiviati in modo persistente (il modello 'token sincronizzatore'), non si desidera realmente archiviare più di un token per sessione, in quanto sarà necessario un numero sempre maggiore di larghezza di banda del database. Quindi è naturale in questo modello avere un solo token memorizzato come attributo nella sessione.

Se si implementano i token CSRF come firma (in genere: HMAC) sull'asserzione della sessione, allora si convalida quel token controllando la firma con la chiave segreta dell'applicazione, quindi non è necessario memorizzare il token sul server lato a tutti. In questo modello è economico generare / firmare un nuovo token ogni volta, e poiché i token di solito includono un timestamp e un salt casuale, saranno diversi ogni volta.

Il solito vantaggio del metodo di firma è che non è necessario l'archiviazione, quindi può potenzialmente far parte di uno schema di controllo accessi senza sessione. Lo svantaggio è che devi gestire la chiave segreta in modo sicuro. (Ma spesso hai già questo carico.)

Tuttavia ...

So why did Connect developers decide to generate a new token on each request

non chiara. Giudicando dal codice sulla pagina collegata Connect ha un valore casuale memorizzato nella sessione, ma i token che emette sono le firme su questo valore casuale e un altro valore casuale per-token.

Questo non sembra avere alcun vantaggio rispetto al semplice token sincronizzatore: è ancora necessario memorizzare gli attributi di sessione, ei token emessi non sono limitati da altre restrizioni firmate (ad esempio scadenza timestamp o revoca). Quindi la conoscenza del token emesso garantisce lo stesso accesso alla conoscenza del valore casuale memorizzato. Sono completamente equivalenti, quindi non vi è alcun punto ovvio nell'avere i vari token emessi, si potrebbe semplicemente emettere il valore casuale memorizzato senza alcuno svantaggio di sicurezza.

Secondo OWASP e secondo la mia opinione personale, generando CSRF i token per sessione sono un'opzione molto più valida rispetto alla generazione di un token per richiesta.

Questo può essere attribuito a pochi motivi principali:

• La generazione di un token per sessione aumenta la facilità di utilizzo, poiché eseguirla per richiesta garantendo nel contempo un livello di sicurezza più elevato richiederebbe la scadenza del token precedente.
• Generare token per richiesta e mantenere i vecchi token come validi ridurrebbe solo la sicurezza poiché, maggiore è il numero di token generati, maggiore è la probabilità di forza bruta su uno di essi. (anche se è improbabile che si verifichi se i token sono abbastanza complessi, questa affermazione è ancora vera)

A mio parere, la creazione di più token CSRF su una base di richiesta rende solo leggermente più facile indovinare un token CSRF valido. Se i token stessi sono ad alta entropia e contengono un livello moderato di casualità - pur essendo collegati a sessioni, è probabile che la protezione CSRF sia stata implementata correttamente.

L'unico vantaggio che vedo con questo è che gli utenti saranno in grado di premere il pulsante Indietro, ma anche se questo è il caso, perché non usare solo token CSRF basati su sessione solo?

Quasi tutti i siti web, compreso il banking online, devono utilizzare token per sessione. Se la tua app lancia armi nucleari, forse potresti volere token di richiesta, ma dubito che useresti un'app Web per questo scopo.

Si nota molta attenzione ai token per richiesta nelle guide sulla sicurezza, ma non c'è una buona ragione per questo. Se un attaccante è in grado di rubare un token CSRF, allora devi preoccuparti di più di CSRF. È probabile che siano in grado di rubare anche il cookie di sessione e rendere il tuo token CSRF per richiesta non è d'aiuto.

Non c'è alcun vantaggio per la sicurezza nell'approccio che Node Connect ha adottato. Mi aspetto che abbiano appena letto alcune di queste guide di sviluppo sicure che parlano di token di richiesta, hanno trovato il problema del pulsante indietro e sono finite con uno stupido kludge.