Implementazione della protezione del pattern Token crittografato CSRF

Question

Implementazione della protezione del pattern Token crittografato CSRF

#1 da (2 voti)
#2 da (2 voti)

3

Sto implementando la protezione CSRF utilizzando il modello di token crittografato (come per link ).

Capisco che le 2 differenze principali tra quel pattern e il pattern Double Submit Cookie sono: 1. il token stesso è un token crittografato, con scadenza 2. il token è memorizzato non in cookie, ma invece in elemento DOM o variabile JS (tramite file JS esterno minificato e offuscato).

Capisco anche che, proprio come altri metodi di prevenzione, anche questo non è sicuro se il tuo sito è vulnerabile agli attacchi XSS.

le mie domande sono: 1. quale sarebbe la scadenza raccomandata da dare al token? per esempio se la mia sessione del sito dura 12 ore, sarebbe OK impostare la scadenza di 1 ora, o si consiglia di limitarsi a minuti / secondi? 2. Come gestisci la scadenza dalla prospettiva UX, nel caso in cui la scadenza sia breve? per esempio - se la pagina è stata caricata su 0sec, ma l'azione è stata inviata dall'utente a 80sec e la scadenza è 60 secondi - il token inviato sarebbe scaduto e l'azione non sarebbe riuscita.

Grazie, Gonen

csrf

posta Gonen 05.03.2015 - 13:47

fonte

2 risposte

2

Ecco un'analisi molto concisa sulle differenze tra i modelli di token crittografati e sincronizzatori:

I modelli di token crittografati non richiedono lo stato del server
Non richiede i cookie Non richiede due token
Non richiede alcuno sforzo sul lato client se non quello di includere il token nelle richieste HTTP
Non richiede alcuna altra applicazione in un sottodominio per essere XSS-proof

Essenzialmente, la principale differenza dal punto di vista dell'implementazione è che il token pattern di sincronizzazione richiede 2 token, mentre il pattern token crittografato sfrutta un singolo token. La risposta di Michael copre le tue domande in termini di timeout e di aggiornamento dell'interfaccia utente. Per ulteriori informazioni sull'argomento, ho appena postato questa voce su come sfruttare il modello di token crittografato in ASP.NET. Sono felice di rispondere a qualsiasi domanda tu possa avere sull'argomento (ho progettato il modello di token crittografato).

risposta data 13.04.2015 - 09:08

fonte

Leggi altre domande sui tag csrf

Esistono programmi antivirus che hanno un bot che fa clic sui collegamenti di posta elettronica? [chiuso] A quali criteri dovrebbe essere considerata compromessa una macchina priva di patch? [chiuso]

score 2 · Accepted Answer

La mia prima domanda sarebbe: perché non usi il raccomandato? modello di token ?

Ad ogni modo, anche se le risposte alle tue domande non sono state formalmente definite, è possibile fornire raccomandazioni generali basate sul modello di token del sincronizzatore.

Il tempo di scadenza consigliato è la durata della sessione (.NET l'attributo antiforgerytoken , ad esempio, sarà in grado di convalidare il token anti-CSRF fintanto che i cookie di sessione sono validi, anche se si presenta una sola volta al termine della sessione.)
Non lo fai, nel caso di un token scaduto, devi semplicemente ricaricare la pagina e dire all'utente che qualcosa è andato storto e che lui / lei deve inviare di nuovo il modulo. Facendo riferimento a 1, ciò avverrà solo in caso di scadenza della sessione.