Quanto frequenti dovrebbero essere gli aggiornamenti dei token nella sicurezza CSRF?

Question

Quanto frequenti dovrebbero essere gli aggiornamenti dei token nella sicurezza CSRF?

#1 da (8 voti)

7

Per iniziare con lo sfondo, questo post è cosa dice Jeff Atwood riguardo ai token CSRF. In questa stessa pagina, continua dicendo:

An even stronger, albeit more complex, prevention method is to leverage server state -- to generate (and track, with timeout) a unique random key for every single HTML FORM you send down to the client. We use a variant of this method on Stack Overflow with great success.

Ma in questo stesso post, Jeff non parla mai di quando e come i token dovrebbero essere aggiornati.

Stavo usando una tecnica simile in un'app web su cui stavo lavorando. Funziona così:

Ogni volta che l'utente metterà POST dati sul mio server, verrà inviato un token csrf lungo.
Questo token CSRF è memorizzato in un cookie crittograficamente valido nella sessione dell'utente.
Se il token è valido, la richiesta dell'utente viene elaborata e viceversa.
Se la richiesta è valida, elimina il vecchio token sul lato server e crea un nuovo token. La risposta dal server contiene un nuovo token csrf da utilizzare nella richiesta successiva. Il vecchio token su tutti i moduli in una pagina viene aggiornato con quello nuovo in modo che la richiesta successiva venga elaborata correttamente.

È saggio aggiornare i token dopo la richiesta di POST o l'aggiornamento deve essere fatto solo quando l'utente fa una richiesta di GET e mantiene lo stesso token fino alla successiva richiesta GET?

programming-practices web-development security patterns-and-practices

posta c0da 17.03.2012 - 08:20

fonte

1 risposta

Leggi altre domande sui tag programming-practices web-development security patterns-and-practices

Come prevenire i problemi a valle dovuti all'ereditarietà Trovare un euristico A * per un grafico diretto

score 8 · Accepted Answer

Il punto principale di un token CSRF è che non può essere stato inviato da un altro sito. Quindi quindi (a) non può essere previsto o rilevato da un utente malintenzionato e (b) non viene automaticamente allegato a una richiesta come avviene per un cookie.

Quindi, in teoria, se un token CSRF non viene mai divulgato a terzi, di nuovo in teoria, non è necessario espirarli affatto. Ma poi corri il rischio che il tuo token venga "filtrato" in qualche modo. Quindi il tuo periodo di scadenza dovrebbe essere abbastanza breve da contrastare la prospettiva che un token possa uscire e essere usato contro il tuo utente.

Non ci sono davvero linee guida, ma una buona tecnica solida è generare automaticamente un nuovo token su OGNI richiesta che incorpori un codice temporale firmato e quindi accettare token fino ad una certa età.

Una funzione di esempio potrebbe essere:

concat(current_time,salt,sha256_sum(concat(salt,userid,current_time,secret_string)))

Il token contiene informazioni sul tempo e un valore salt, ma contiene anche una firma che non può essere falsificata e che è legata al userid.

Quindi puoi definire il tuo intervallo di scadenza - un'ora, un giorno, 2 ore. Qualunque cosa. L'intervallo in questo caso non è legato al token, quindi sei libero di impostare le regole di scadenza come vuoi.

Per lo meno, tuttavia, i token CSRF dovrebbero scadere quando scade la sessione di accesso o quando l'utente si disconnette. Non c'è alcuna aspettativa da parte dell'utente che un modulo che hai richiamato PRIMA di aver effettuato il logout continui a funzionare DOPO che accedi di nuovo.