Un token CSRF per sessione è adeguato con HTTPS?

Per prevenire CSRF è necessario avere qualcosa di non accessibile nella parte esplicita della richiesta (GET o POST). È preferibile inserirlo nella parte POST, dal momento che è più difficile trovarlo e di solito si proteggono solo le richieste che attivano un'azione, che dovrebbe essere POST.

Un valore casuale per sessione non è percettibile e dovrebbe svolgere il lavoro. Il meccanismo di token anti CSRF standard integrato in ASP.net funziona proprio così.

HTTPS impedisce la perdita del token sul filo e impedisce anche gli attacchi di riproduzione. Quindi un token a tempo solo non sembra necessario.

Un token CSRF per sessione potrebbe fornire una protezione adeguata contro CSRF, ma è possibile ottenere una maggiore sicurezza utilizzando un diverso token CSRF per ogni modulo.

In caso di altre vulnerabilità, un utente malintenzionato può rubare o utilizzare in modo improprio un token CSRF. In tal caso, è consigliabile limitare il più possibile il token CSRF. Questa Ruby on Rails PR cambia il token CSRF per essere valido solo per un'azione e un metodo specifici, in modo che il CSRF rubato i token non possono essere usati per nessun altro scopo. Questo è descritto un po 'di più in un blog di ingegneria GitHub .

Questa è una difesa che misura in profondità. Nel caso in cui qualche altra vulnerabilità renda possibile rubare un token CSRF, è una buona idea limitare la validità dei token CSRF.