Qual è il modo corretto per implementare token modulo anti-CSRF?

Il modo migliore per creare correttamente la protezione CSRF:

Don't.

La maggior parte dei framework comuni ha già questa protezione incorporata (ASP.NET, Struts, Ruby, credo), o ci sono già librerie già controllate. (ad es. CSRFGuard di OWASP ).

Un'altra opzione, a seconda del contesto, consiste nell'imporre la riautenticazione dell'utente, ma solo per operazioni sensibili specifiche.

Come per i tuoi commenti, se hai bisogno di implementarlo tu stesso, la tua soluzione non è male, ma lo semplificerei.
Puoi generare un nonce crittografico casuale (abbastanza lungo), memorizzarlo nella memoria di sessione e cambiarlo ogni X minuti (anche tu memorizzi il tempo di scadenza nella sessione). In ogni modulo, includi il nonce in un campo modulo nascosto e confronti quel valore quando il modulo è pubblicato.
Se il token del modulo corrisponde, sei chiaro. In caso contrario, puoi accettare ad es. il token precedente pure, per gestire i casi limite.

Anche se devo dire che ho visto troppi tentativi falliti per implementare questo da soli, per raccomandare davvero questo percorso. Stai ancora meglio trovando un pacchetto minimo per farlo per te.

C'è una buona spiegazione su OWASP: Foglio cheat di prevenzione OWASP CSRF

In breve, dicono che ci sono due modi:

1. Aggiungi un token casuale a ogni sessione utente. Solo se questo token è presente e corretto verranno applicate le modifiche, altrimenti la richiesta dovrebbe essere respinta. È importante che il token venga inviato solo con una richiesta POST, poiché le richieste GET possono perdere il token in posti diversi (cronologia browser, file di registro, ecc.).

   È anche possibile generare un token per richiesta, ma questo porta a problemi di usabilità. Ad esempio il pulsante Indietro non funzionerebbe più correttamente. Ma ovviamente la sicurezza sarebbe aumentata.

   Assicurati anche (per migliorare ancora di più la sicurezza) che il token sia inviato solo su TLS, quindi non ci sarà alcun uomo nei problemi centrali.

2. L'altra opzione consiste nell'usare una sorta di sfida - risposta (ad esempio CAPTCHA o token una tantum).

La pagina OWASP elenca anche alcune misure che non funzionano. Questi sono

• Utilizzo dei cookie (segreti)
• Non usando le richieste GET
• Transazioni a più fasi
• Riscrittura URL

Oltre alla risposta @Andreas Arnold c'è un'alternativa. Ho implementato Encrypted Token Pattern da OWasp.

Oltre a prevenire gli attacchi csrf, ha il vantaggio aggiuntivo di implementare la sicurezza degli oggetti.

Solo coloro che sono autorizzati a modificare oggetti, possono farlo. Gli altri non avranno il testo o la chiave di cifratura corretta / valida. Di solito criptico sessionId , timestamp , userId e / o recordId .

timestamp impedisce replayAttacks. sessionid isola solo le modifiche a questa sessione userId isola le modifiche solo a questo utente. Se includi recordId , al costo dell'elaborazione aggiuntiva ottieni maggiore sicurezza.

Non penso che ci sia molto sbagliato (anche se potrei sbagliarmi;) includendo un timestamp nel token da hash e includendo questo timestamp come un campo di forma nascosto - forse esadecimale come offuscamento di base - puoi quindi verificare la presenza di tracce sulla presentazione.

Tendo a pensare che la protezione CSRF basata su token possa essere facilmente infranta: un utente malintenzionato deve solo sapere come richiedere una pagina protetta da CSRF, normalmente queste pagine hanno il token come campo nascosto. L'attaccante quindi afferra il token dalla pagina (abbastanza banale) e lo usa per costruire un attacco CSRF.