Token CSRF nella richiesta GET

Se stai generando i token in modo casuale e sicuro, un attaccante non può dedurre il token successivo da quelli precedenti. Quindi non dovrebbe esserci alcun rischio realistico.

Un altro punto importante qui è usare SSL. Qualsiasi proxy / proxy inverso tra l'utente e il server non può nemmeno visualizzare i parametri GET per registrarli. Le uniche posizioni in cui viene registrato il token si trovano ai due estremi della connessione SSL.

L'accesso alla fine dell'utente (la cronologia, ad esempio) avviene dopo aver fatto clic sul collegamento. La registrazione sul server non comporta alcun rischio (se non ti fidi del posto in cui il traffico SSL viene decifrato, ci sono problemi più grandi).

Le richieste GET dovrebbero essere idempotenti, il che significa che non è possibile invalidare il token una volta utilizzato perché eventuali richieste ripetute non daranno la stessa risposta.

Le richieste GET non dovrebbero mai apportare modifiche di stato al sistema, pertanto non dovrebbe essere richiesto di avere una protezione CSRF. Anche il logout non dovrebbe essere una richiesta GET per il metodo che esegue effettivamente il logout (sebbene sia possibile avere un collegamento GET che si sposta su un'altra pagina prima che una richiesta POST esegua l'azione).

Per risolvere il problema idempotent, con una richiesta GET ripetuta e con lo stesso token CSRF fornito, è possibile visualizzare la risposta memorizzata nella cache dalla prima richiesta, senza apportare alcuna modifica di stato. Tuttavia, stai ancora violando lo standard in caso di modifiche dello stato, vedi rfc7231 :

Request methods are considered "safe" if their defined semantics are
essentially read-only

Of the request methods defined by this specification, the GET, HEAD,
OPTIONS, and TRACE methods are defined to be safe.

Come nota a margine, vorrei anche sostenere che i processi ad uso intensivo di risorse dovrebbero essere anche POST (con protezione CSRF) piuttosto che GET, altrimenti un utente malintenzionato potrebbe eseguire un sistema utilizzando un vettore CSRF.

Pertanto, se hai bisogno di CSRF per un metodo, non implementarlo come GET.

Considering that by the time someone logs the token, it will already be invalidated and unusable should the attacker want to perform CSRF.

C'è un caso d'angolo se l'utente ottiene l'indirizzo ma non riesce a utilizzare effettivamente il token (a causa di errori di rete transitori, ecc.). È improbabile che questo sia abbastanza significativo da preoccuparsi per un token CSRF, ma può essere un problema per altri token più sensibili.

I token CSRF monouso tendono a porre problemi di usabilità, ad esempio rompendo la navigazione e la navigazione con più schede ... per non dire che sono super-brutti. :-) Dato che le richieste GET dovrebbero essere idempotenti e quindi non necessitano di protezione CSRF, token-in-URL è solitamente un odore di progettazione. Ma dubito che ci sia molto che puoi sfruttare qui.

Probabilmente è abbastanza sicuro, ma non elimina completamente il problema della navigazione e della registrazione della spalla. Un utente malintenzionato potrebbe temporaneamente eseguire il DoS sulla rete in modo che possa utilizzare un token surfato prima che l'utente abbia la possibilità di farlo e una richiesta potrebbe essere visualizzata nei registri ma non essere invalidata quando il sito Web (o il database o la rete) non è attivo durante un tentativo di pageload. Oltre a ciò, non riesco a pensare a eventuali vulnerabilità che non si verificano anche quando si inserisce il token nei dati POST.

Non sono sicuro che sia pratico invalidare tutti i token dopo l'uso. Apro spesso più pagine in una nuova scheda di sfondo, ad esempio nei vecchi forum SMF. Faccio clic con il pulsante centrale del pulsante Elimina dei messaggi privati in modo che non sia necessario ricaricare la pagina prima di poterne eliminare un'altra. Puoi generare un token univoco per tutti i link che compaiono in una pagina, ma poi raggiungi un livello di complessità in cui potresti anche iniziare a utilizzare HMAC anziché un token semplice.