Per i motivi già discussi, non è necessario generare un nuovo token per richiesta. Porta un vantaggio di sicurezza quasi nullo e ti costa in termini di usabilità: con un solo token valido alla volta, l'utente non sarà in grado di navigare normalmente nella webapp. Ad esempio, se premono il pulsante "indietro" e inviano il modulo con nuovi valori, l'invio fallirà e probabilmente li saluterà con un messaggio di errore ostile. Se provano ad aprire una risorsa in una seconda scheda, troveranno che la sessione si interrompe casualmente in una o entrambe le schede. Di solito non vale la pena menomare l'usabilità della tua applicazione per soddisfare questo requisito inutile.

C'è un posto in cui vale la pena emettere un nuovo token CSRF, però: su principal-change inside una sessione. Cioè, principalmente, all'accesso. Questo serve per evitare che un attacco di riparazione della sessione porti a una possibilità di attacco CSRF.

Ad esempio: l'attaccante accede al sito e genera una nuova sessione. Prendono l'ID di sessione e lo iniettano nel browser della vittima (ad es. Scrivendo un cookie da un dominio vicino vulnerabile o utilizzando un'altra vulnerabilità come gli URL jsessionid) e iniettano anche il token CSRF in un modulo nel browser della vittima. Attendono che la vittima acceda con quel modulo, quindi utilizza un altro post del modulo per convincere la vittima a eseguire un'azione con il token CSRF ancora attivo.

Per evitare ciò, invalida il token CSRF e emettine uno nuovo nei punti (come login) in cui stai già facendo lo stesso con l'ID di sessione per prevenire attacchi di riparazione della sessione.

Panoramica. Il consiglio standard è di utilizzare un token CSRF univoco che sia univoco per ogni richiesta. Perché? Perché un token per richiesta è leggermente più resistente a determinati tipi di errori di implementazione rispetto a un token per sessione. Ciò rende i token per richiesta probabilmente la scelta migliore per lo sviluppo di nuove applicazioni web. Inoltre, nessun revisore della sicurezza ti darà fastidio sull'utilizzo di un token CSRF per richiesta.

Se sei uno sviluppatore di applicazioni web, questo è tutto ciò che devi sapere e puoi smettere di leggere qui. Ma se sei un esperto di sicurezza e ti chiedi quale sia la logica dettagliata alla base di questo consiglio, o se ti stai chiedendo quanto sia grande il rischio se usi un token per sessione, continua a leggere ...

Scavando un po 'più a fondo. La verità è che, se non hai altre vulnerabilità nel tuo sito web, un singolo token CSRF per sessione è OK. Non c'è motivo per cui devi generare un nuovo token CSRF per richiesta.

Ciò è dimostrato dal fatto che troverai anche rispettabili esperti di sicurezza che affermano che un altro ragionevole Un modo per difendersi da CSRF è utilizzare il doppio invio dei cookie: in altre parole, si utilizza un Javascript lato client che calcola un hash del cookie di sessione e lo aggiunge a ogni richiesta POST, trattando l'hash come il token CSRF. Puoi vedere che questo essenzialmente genera al volo un token CSRF che è lo stesso per l'intera sessione.

Naturalmente, conosco l'argomento per cui alcune persone potrebbero consigliare di generare un nuovo token CSRF per ogni richiesta. Stanno pensando, se hai anche una vulnerabilità XSS sul tuo sito web, se usi un singolo token CSRF per sessione sarà facile usare XSS per recuperare il token CSRF, mentre se generi un nuovo token CSRF per richiesta, richiederà più lavoro per recuperare il token CSRF. Personalmente, non trovo questo un argomento estremamente convincente. Se hai una vulnerabilità XSS sul tuo sito, è comunque possibile recuperare i token CSRF anche se generi un nuovo token CSRF per ogni richiesta, bastano poche righe in più di Javascript dannoso. In ogni caso, se hai una vulnerabilità XSS sul tuo sito e affronti un aggressore serio e informato, è difficile garantire la sicurezza, indipendentemente da come generi i token CSRF.

Nel complesso, non può far male per generare un nuovo token CSRF per ogni richiesta. E forse è meglio farlo in questo modo, solo per toglierti di dosso i revisori della sicurezza. Ma se hai già un'applicazione legacy che utilizza un singolo token CSRF per l'intera sessione, spendere i soldi per convertirlo per generare un nuovo token CSRF per ogni richiesta probabilmente non sarebbe molto alto nella mia lista di priorità: scommetto che io potrebbe trovare altri usi per quei soldi e l'energia degli sviluppatori che migliorerebbero ulteriormente la sicurezza.

XSS può essere utilizzato per leggere un token CSRF, anche se è un singolo token di invio, questo è un gioco da ragazzi. È probabile che questa raccomandazione di un singolo token di invio provenga da qualcuno che non comprende CSRF.

L'unico motivo per utilizzare un "token di invio singolo" è se desideri impedire all'utente di fare clic accidentalmente su Invia due volte. Un buon uso di questo è impedire che l'utente faccia clic due volte su "checkout" e addebiti accidentalmente il cliente due volte.

Un CAPTCHA o la richiesta della password corrente dell'utente può essere utilizzato come misura anti-csrf essere bypassato da XSS.

Consiglio di leggere il CSRF Prevention Cheat Sheet.

Se il token è lo stesso per l'intera sessione, potrebbe essere possibile per un utente malintenzionato trapelare un token da una pagina e utilizzarlo per un'azione diversa.

Ad esempio, potresti utilizzare un iframe per caricare una pagina, quindi estrarre il token utilizzando una vulnerabilità XSS. Da lì, potresti usare quel token per inviare un modulo di modifica della password

Usare un token per richiesta invece di uno a livello di sessione rende più difficile, ma non impedisce CSRF. Un utente malintenzionato può semplicemente sfruttare un XSS per leggere il token dalla pagina, quindi attivarlo. Tuttavia, se il token è globale anziché limitato a quella singola pagina, un utente malintenzionato può prendere di mira qualsiasi pagina per rubare il token. L'utilizzo di token separati per ogni richiesta rende tutto più difficile.

Oltre alle altre risposte, potrebbe essere saggio aggiornare anche il token se il tuo server è suscettibile all ' attacco BREACH.

Ciò richiede le seguenti tre condizioni:

• Essere servito da un server che utilizza la compressione a livello HTTP
• Riflette l'input dell'utente nei corpi di risposta HTTP
• Riflette un segreto (come come token CSRF ) nei corpi di risposta HTTP

Per mitigare BREACH dovresti aggiornare il token CSRF sulla richiesta GET che carica un modulo per invalidare tutti i token precedenti. In questo modo, un MITM (Man-In-The-Middle) che crea richieste aggiuntive per scoprire il token nella pagina riceverà ogni volta un token diverso. Ciò significa che l'utente reale non sarà in grado di inviare il modulo in una situazione MITM.

Naturalmente hai bisogno che anche le altre due condizioni siano vere. Probabilmente sarebbe più facile mantenere un token CSRF per sessione e disabilitare la compressione a livello HTTP per tutte le pagine che servono moduli.

Non è un fatto molto noto, ma il normale confronto di stringhe è vulnerabile agli attacchi di temporizzazione ( come questo. Per farla breve, normali operazioni di confronto di stringhe ( == o === ) confronteranno due stringhe carattere per carattere da sinistra a destra e restituiranno false una volta che hanno incontrato un carattere che non è uguale in una determinata posizione in entrambe le stringhe. Questo dà una minuscola differenza di tempistica che è stata dimostrata essere rilevabile.

Utilizzando un attacco a tempo per provare ogni possibile personaggio per ogni posizione, è possibile capire quale sia il gettone effettivo. Creando un nuovo token ogni volta che viene inviata una richiesta con un token, questo attacco può essere prevenuto.

Naturalmente, questo funziona solo se si ricrea anche il token se un non valido è stato inviato il token, il che potrebbe non essere desiderabile. Pertanto, è meglio risolvere questo problema utilizzando una funzione di confronto delle stringhe insensibile al tempo come questa.

Un motivo per voler cambiare il token CSRF per richiesta è mitigare la perdita di compressione del token. Ciò che intendo con questo è che se l'attaccante Eve può iniettare dati su una pagina contenente il token in cui viene inviata la pagina compressa, Eva può quindi indovinare il primo carattere della stringa che riceve un set di dati più piccolo per la pagina sapendo di aver indovinato, quindi vai al carattere successivo.

Questo è simile a un attacco a tempo.

Al momento non c'è motivo (che io sappia) per cambiare il token se viene inviato solo nelle intestazioni HTTP.

Un altro metodo consiste nel modificare il token non appena viene rilevata una richiesta non riuscita, ma ciò potrebbe avere problemi con l'utente che non è in grado di inviare alcun modulo.

Se lo stesso token viene utilizzato per l'intera sessione, è probabile che l'autore dell'attacco possa dirottare il token utilizzando XSS e utilizzare la sessione della vittima per svolgere alcune attività dannose come cambiare la password .

Possono modificare le password inserendo un iframe nel sito che stai utilizzando.

Quindi è meglio utilizzare un token per richiesta per evitare che l'attaccante ottenga l'accesso a quel token.