Qual è un buon periodo di tempo prima di aggiornare il token CSRF della sessione utente?

4

Sto utilizzando un token modulo per impedire attacchi CSRF. Quei token sono memorizzati e legati alla sessione di un utente. Ora voglio aggiornare il token solo ogni N minuti o ore in modo che l'utente non riscontri problemi di usabilità come il pulsante Indietro del browser che non funziona correttamente.

La mia domanda è, quale sarebbe un buon periodo di tempo prima di aggiornare il token della sessione utente?

    
posta Kid Diamond 23.04.2014 - 15:38
fonte

2 risposte

1

Bene, dovresti studiare le tue statistiche personali. Dovresti porsi le seguenti domande:

  1. Quanto tempo un utente spende nel tuo sistema?
  2. Qual è l'impatto sull'usabilità non modificandolo in una sessione?
  3. Qual è il tuo tempo di sessione in scadenza? ...

Nessuno qui può rispondere a queste domande (tra le altre) meglio di te.

    
risposta data 23.04.2014 - 16:35
fonte
1

La mia raccomandazione: mai.

Dovresti avere un solo token CSRF per sessione. Se la sessione scade, il token CSRF scade a questo punto.

Poiché non è possibile per un utente malintenzionato leggere il token CSRF (almeno non c'è il rischio che un utente malintenzionato legga un token CSRF come cookie Session ID), non è necessario generarne uno nuovo a meno che avere una nuova sessione per andare con esso.

L'unica eccezione a ciò che vedo è che se si tenta di inviare un modulo con un cookie di sessione utente valido, ma con un token CSRF errato (ad esempio, l'utente viene attaccato da un altro sito che sta utilizzando). In questo caso potresti voler generare un nuovo token CSRF e segnalare un avviso a te stesso in modo che le richieste possano essere esaminate. È possibile che si desideri generare l'avviso dopo il primo token CSRF non corretto (poiché le richieste contenenti un token CSRF errato non dovrebbero accadere affatto), ma è possibile aggiornare il token dopo n tentativi falliti per ridurre le possibilità di un token che viene forzato come bruto mentre consente all'utente di utilizzare il proprio sistema senza che gli venga negato il servizio (sebbene la negazione del servizio sia un problema minore in questo caso in quanto l'attacco arriverà dalla propria macchina).

    
risposta data 24.04.2014 - 12:03
fonte