È valido difendere un token CSRF contro la riproduzione (ad esempio con un timestamp)?

Se il token CSRF può essere intercettato, di solito il cookie di sessione può essere intercettato, quindi CSRF non sarebbe la preoccupazione immediata in quello scenario.

Alcune implementazioni di token CSRF hanno scadenze scadute, ma questa è un'ulteriore precauzione e non strettamente necessaria. Questa risposta di tylerl suggerisce che una scadenza è una buona precauzione nel caso in cui il token sia trapelato in qualche modo, ma scadendo il token CSRF quando la sessione finisce è ok.

In un attacco CSRF, l'attaccante ha la possibilità di inviare qualsiasi dato di modulo desiderato dalla tua sessione, ma non può modificare i cookie. Affinché un token CSRF sia efficace dovrebbe essere impossibile per l'attaccante conoscere il suo valore. Se l'utente malintenzionato sfrutta una vulnerabilità per ottenere token CSRF, allora si desidera assicurarsi che i token CSRF non siano più validi una volta risolta la vulnerabilità. Finché il token cookie è scaduto quando la sessione scade, tutto va bene (a patto di forzare le sessioni a scadere se si sospetta che i token siano stati trapelati).

Dalla documentazione che hai collegato sembra che stia effettivamente utilizzando il Pattern token crittografato , che combina un Double Submit Cookie con un token di sincronizzazione.

Abbiamo avuto questa discussione con molti clienti nel corso degli anni. La soluzione più valida per la protezione CSRF è quella in cui il server tiene traccia di quale "pagina" è stata inviata al client, quindi accetta solo dati validi dalla pagina che è stata pubblicata, solo dal client a cui è stato offerto.

È passato un po 'di tempo da quando sono stato sul lato della programmazione con MS, ma @AntiForgeryToken dovrebbe cambiare ad ogni richiesta ed essere convalidato su ogni pagina che riceve i dati.

Sembra che l'applicazione generi solo il token una volta, poi mai più. Dai un'occhiata a questo blog per ulteriori dettagli. link