CSRF: valore casuale o HMAC

The first one uses randomly generated CSRF tokens which uses a cryptographic strong random generator to generate the token.

Questo è l'ideale. In questo caso, il token è un blocco opaco assolutamente imprevedibile senza alcun significato al di fuori del contesto previsto.

The second implementation I found uses HMAC which encrypts the session id with secret key stored in the server side config.

È più semplice da implementare. Presumibilmente gli ID di sessione sono già stati generati, quindi non è necessario perseguire nulla di aggiuntivo. Poiché non è necessario ulteriore spazio di archiviazione, è possibile che questo meccanismo possa essere implementato in situazioni in cui un token casuale non può essere utilizzato in un progetto legacy. Questa è una soluzione relativamente elegante. Supponendo che la chiave segreta non diventi nota all'attaccante, il token non dovrebbe essere riproducibile al di fuori del server.

The third implentation I saw uses a combination of both, a secret key stored in the server side config is used to HMAC a random generated value

Questo è un po 'sciocco. Presumibilmente spinto dal fatto che un HMAC è un concetto di sicurezza, l'autore tenta di aggiungere sicurezza al suo progetto includendo qualcosa legato alla sicurezza. Una sorta di magico talismano della sicurezza. Presumibilmente non è peggiore che usare solo il numero casuale, ma certamente non è meglio. A meno che non si contenga la calda sensazione di confusione derivante dall'utilizzo di HMAC nell'implementazione della sicurezza.

È è , tuttavia, una soluzione ragionevole se hai un RNG scadente, anche se in questo caso probabilmente combinerei l'ID di sessione o qualcosa di simile lì prima dell'hashing in modo che tu sia garantito che il numero di hash in unico.

So che asp.net MVC 3/4 usa un metodo simile a 2. Il problema che trovo con questo approccio è che esiste un solo token CSRF per la sessione, a differenza di quello della forma. Quindi, per esempio, se ottengo il token CSRF una volta, quel token è valido per qualsiasi modulo post nel corso della sessione. Quando collaudo con uno strumento come ZAP, una richiesta mi dà il token che posso poi riutilizzare a mio piacimento. Oltre a ciò, il token deve essere scritto da qualche parte nella pagina HTML (non è memorizzato in un cookie, ad esempio) e quindi può essere facilmente letto da un utente malintenzionato che cerca la stringa specifica.

Mi piace l'idea di 1/3. La casualità fornisce sicurezza su base per modulo / chiamata, al contrario di una per sessione. Può anche essere utilizzato per impedire più post dello stesso modulo. Ciò sarebbe utile in un sistema transazionale in cui si vorrebbe garantire che un invio avvenga solo una volta. Quando il server riceve il primo invio, invalida il token. Il prossimo invio fallirebbe. L'hacker ora deve prendere possesso di un token e usarlo prima che l'utente lo faccia.

Riesco a vedere il tuo punto riguardo il clustering / bilanciamento del carico, ma la maggior parte dei load balancer può / inoltrerà richieste dalla stessa sessione allo stesso host back-end.