È possibile attivare il pulsante Indietro se utilizziamo un token CSRF per richiesta?

Question

È possibile attivare il pulsante Indietro se utilizziamo un token CSRF per richiesta?

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

2

Dobbiamo compromettere la navigazione del pulsante Indietro se usiamo un token CSRF per richiesta invece di un token per sessione?

(Ho avuto successo nell'utilizzare un token per sessione senza problemi di navigazione ma non sono riuscito a fare lo stesso con un token CSRF per richiesta.)

web-application csrf

posta Girish 14.06.2016 - 06:56

fonte

2 risposte

Leggi altre domande sui tag web-application csrf

Lo spoofing degli indirizzi Mac in Kali ripristina l'addr MAC. dopo aver effettuato il collegamento alla WLAN Come implementare la correzione per Forward Secrecy su Debian Apache OpenSSL? [chiuso]

score 1 · Answer 1

La soluzione utilizzata nelle mie Web-Applications (JSF) è quella di dire al browser di fare una nuova richiesta GET sul browser-back (o riaprire la scheda). Questo viene fatto con la seguente intestazione di risposta HTTP:

Cache-Control: no-store, no-cache, must-revalidate
Expires: [in the past]

La prima riga è per HTTP 1.1, la seconda è per Proxy-Server.
Questo dovrebbe funzionare (almeno) in tutti i principali browser.

Per i dettagli vedi questa risposta su StackOverflow

score 0 · Answer 2

Penso che stai sprecando il tuo tempo cercando di implementare i token di richiesta. D.W. lo spiega in questa risposta :

Of course, I know the argument why some people might recommend generating a new CSRF token for every request. They are thinking, if you also have a XSS vulnerability on your website, then if you use a single CSRF token per session it will be easy to use XSS to recover the CSRF token, whereas if you generate a new CSRF token per request, it will take more work to recover the CSRF token.

Personally, I don't find this a terribly compelling argument. If you have a XSS vulnerability on your site, it's still possible to recover CSRF tokens even if you generate a new CSRF token for every request, it just takes a few extra lines of malicious Javascript. Either way, if you have a XSS vulnerability on your site and you face a serious, knowledgeable attacker, it's hard to guarantee security, no matter how you generate your CSRF tokens.

Detto questo, se vuoi ancora farlo, forse il seguente approccio funzionerebbe:

Quando viene caricato un modulo, esegui una chiamata AJAX con JavaScript a getCsrfToken.php o qualcosa del genere. Assicurati di avere CORS rigoroso su questo.
Sul lato server, genera un token casuale se la sessione è valida e la rimanda al client.
Potresti voler invalidare tutti i token più vecchi per quella sessione. Tuttavia, questo causerà problemi se l'utente ha il tuo sito aperto in più schede. Dall'altra parte, se non lo fai, qual è il punto?

Ho appena immaginato questa soluzione ora, quindi considerala più come un suggerimento da valutare che come una risposta sicura definitiva.