Va bene usare il cookie di sessione (crittograficamente valido) come token CSRF?

Question

Lettura OWASP CSRF prevention cheat sheet, uno dei metodi proposti per prevenire questo tipo di attacchi è il modello di token di sincronizzazione.

Se il token di sessione è crittograficamente forte, può raddoppiare come token csrf come descritto nel seguente pseudocodice?

Cliente:

<script> 
dom.replace(placeholder, getCookie("session-cookie")) 
</script> 

<form> 
<input type="hidden" name="csrf-cookie" value="placeholder-value"/> 
<input type="text" /> 
</form> 

Server:

if(request.getParameter("csrf-cookie") != user.getSessionCookie()) 
    print "get out you evil hacker" 

Il cookie è impostato con javascript caricamento della pagina per impedire agli utenti di fuoriuscita accidentale il cookie di sessione se per esempio Invia una copia della pagina a un amico.

Answer 1

Tutto ciò che non può essere recuperato da un sito esterno può essere utilizzato come token CSRF. Quindi il contenuto del cookie di sessione va bene per questo.

Answer 2

No, non è necessario riutilizzare il token di sessione come token CSRF. La prevenzione foglietto OWASP CSRF dà motivi per cui utilizzare l'identificatore di sessione come un token CSRF è indesiderabile:

Anche se questo approccio è efficace nel limitare il rischio di cross-site request forgery, tra identificativi di sessione autenticati nei parametri HTTP possono aumentare il rischio generale di dirottamento di sessione. Architetti e sviluppatori devono garantire che nessun dispositivo di rete o codice di applicazione personalizzato o moduli registrino esplicitamente o altrimenti divulgino i parametri POST HTTP.

e

inclusione della identificatore di sessione entro HTML può anche essere sfruttato da attacchi cross-site scripting per bypassare le protezioni HttpOnly. La maggior parte dei browser moderni impedisce agli script lato client di accedere ai cookie HTTPOnly. Tuttavia, questa protezione viene persa se gli identificativi di sessione di HTTPOnly sono posizionati all'interno dell'HTML in quanto lo script lato client può facilmente attraversare ed estrarre l'identificativo dal DOM. Gli sviluppatori sono comunque incoraggiati ad implementare il modello di token di sincronizzazione come descritto in questo articolo.

Here ci sono alcune altre considerazioni sul perché potrebbe non essere una buona idea usare l'ID di sessione come token CSRF. This article menziona il pacchetto sniffing su semplici connessioni http e la possibilità di fare attacchi man-in-the-middle su di loro come potenziali rischi.

Quindi è essenziale che il token CSRF sia diverso, altrimenti il ​​token CSRF sarebbe banalmente ipotetico se supponiamo che l'utente malintenzionato conosca già l'identificatore di sessione! Metti di più sulla difensiva: probabilmente non è una buona idea giocare con il fuoco: non c'è bisogno di riutilizzare l'ID di sessione come token CSRF, così facendo apri solo un'altra superficie di attacco che potrebbe potenzialmente essere sfruttata. Nessun riutilizzo, nessuna preoccupazione al riguardo.

Di conseguenza, nonostante il token di sessione sia crittograficamente sicuro, dovrebbe inoltre essere indipendente (anche in senso probabilistico) dal token CSRF affinché tutto funzioni in base alle suddette ipotesi. Questo è anche il motivo per cui qualsiasi esempio di implementazione crea sempre il proprio token da zero.

È possibile utilizzare un generatore di numeri casuali protetto da crittografia per creare una sequenza di byte, esadecimale o Base64, codificarli per ottenere una stringa da incorporare nella pagina. OWASP raccomanda una lunghezza di 128 bit dove assumono 64 bit di entropia (ad esempio 8 byte casuali trasformati in una stringa esadecimale a 16 byte). La lunghezza di tale sequenza determina il livello di sicurezza: l'ipotesi di un numero casuale sicuro di 10 byte (che ha 80 bit di entropia) ha esito positivo con probabilità 2^(- 80), che dovrebbe essere sufficiente nella maggior parte delle applicazioni. Quindi il tuo token finale dovrebbe avere una lunghezza di 20 byte, un numero casuale di 10 byte trasformato in codifica esadecimale.