Usando il pattern token di sincronizzazione, dovresti assicurarti che il token CSRF sia comunicato solo tramite HTTPS?

2

In parole semplici, i token CSRF possono essere eliminati dalle risposte dal server a meno che la richiesta / risposta non venga trasmessa tramite crittografia. È abbastanza preoccupante da preoccuparsi o è ragionevole consentire la trasmissione del token CSRF tramite testo in chiaro?

Nel nostro caso, il framework che stiamo utilizzando prevede esattamente un token CSRF per sessione e la nostra applicazione ha sia moduli HTTP che HTTPS da proteggere. La mia preoccupazione è che un utente malintenzionato possa annusare il token CSRF mentre la vittima sta visitando una pagina HTTP con un modulo su di esso e quindi invogliare la vittima a visitare una pagina HTTPS dannosa che invia a un gestore di richieste HTTPS più sensibile sulla nostra applicazione con la corretta Token CSRF (messo lì dall'attaccante che lo ha annusato prima).

    
posta user1483512 16.04.2014 - 20:44
fonte

2 risposte

1

Esatto, il tuo token deve rimanere segreto, oppure un utente malintenzionato può duplicare il token. È più difficile prendere in prestito il cookie di sessione, ma il principio di base è lo stesso.

Se generi un token CSRF unico per ogni richiesta & Richiedere che venga utilizzato solo una volta e sempre su richiesta, è quindi possibile assicurarsi che il token non venga riprodotto. Anche allora è ancora possibile per l'attaccante ottenere il token & usalo prima che l'utente reale lo faccia.

In definitiva dovrai utilizzare HTTPS per poterti fidare completamente del token CSRF.

    
risposta data 17.04.2014 - 02:12
fonte
3

Se un utente malintenzionato può annusare il token CSRF, può anche annusare il cookie di sessione e non ci sarebbe alcun motivo per lanciare un attacco CSRF. O mi sto perdendo qualcosa?

    
risposta data 16.04.2014 - 23:33
fonte

Leggi altre domande sui tag