Cosa fare dopo aver rifiutato un token CSRF non valido?

Suppongo che questo sia per "token di sincronizzazione" modello, e non "doppio invio cookie" , poiché i token non 'scade davvero nel secondo caso.

Puoi mitigare il problema rendendo i token CSRF più longevi. Hai solo un token per sessione (in contrapposizione a per modulo) e rendilo tanto longevo quanto la sessione. Quindi se il token CSRF è scaduto, lo stesso vale per la sessione. E poi la richiesta dovrebbe essere respinta comunque.

Detto questo, se per qualche motivo ottieni una richiesta con una sessione valida ma un token CSRF non valido, cosa dovresti fare? Come dici tu, lo stato 403 è una buona scelta. Per un'API, potresti rispondere con qualche tipo di errore oggetto o messaggio che spiega al cliente cosa è andato storto. O solo un corpo vuoto, se è così che ti occupi degli errori.

Per le presentazioni di moduli classici, è un po 'più complicato. Se vuoi giocare davvero bene, dovresti rispondere con il modulo nello stesso stato in cui l'utente ha provato a inviarlo, oltre a un messaggio di errore. Questo è un po 'un vantaggio da implementare, ma forse hai già un sistema simile già in funzione per altri errori.

Si noti che è possibile restituire il nuovo token (come cookie, o campo modulo o qualsiasi altra cosa) già nella risposta alla prima richiesta con il token scaduto. Non è necessario che il client faccia un'altra richiesta solo per averlo.

Nell'equilibrio si cerca di colpire tra sicurezza e usabilità, ci sono molti dettagli contestuali che pesano strongmente o debolmente in una direzione o nell'altra-

• quali sono i rischi di una richiesta falsificata e i relativi benefici per un utente malintenzionato?
• quanto è plausibile un CSRF per la tua base di utenti; in relazione, quali altre difese sono in atto (ad es. frame busting, TLS forzato, CSP, ecc.) contro tipi simili di attacchi che il sito e gli utenti potrebbero incontrare?
• quanto è doloroso per gli utenti essere sottoposti a rinnovo di token o a un meccanismo di rielaborazione di moduli?

Ecc. Quindi dipende davvero.

In generale, una sessione di 30 giorni e un token di 12 ore sono pesati molto più strongmente nella direzione dell'usabilità. Quindi, dovresti confermare che è appropriato per il tuo contesto.

Supponendo che sia, in un contesto orientato all'usabilità, avere un flusso di lavoro qualsiasi o una condizione di errore che richiede agli utenti di fare qualcosa una seconda volta sarà subottimale. Quindi, l'adozione di una soluzione che preservi gli input dell'utente in tutti i casi in cui il token scade o informa l'utente che il token è sull'orlo della scadenza e dovrebbe essere rinnovata, o una qualsiasi delle molte altre opzioni, è probabilmente una buona idea.