Cosa succede se il mio token anti-CSRF è compromesso da un attacco XSS?

7

L'interessante domanda Stack Overflow "I cookie proteggono i token dagli attacchi XSS?" è stato chiuso come troppo ampio, ma come menzionato in un commento su di esso, esiste una domanda tangibile su "Cosa succede se il mio token anti-CSRF viene compromesso da un attacco XSS?"; mi sembra che le risposte a questa domanda possano fornire informazioni che aiuteranno le persone a formare opinioni sulle domande poste su Stack Overflow. Quindi sto ponendo la domanda tangibile.

Supponiamo che utilizziamo il metodo Double Submit Cookies (a meno che non conosca un metodo migliore di cui sono inconsapevole) e archiviamo i JWT (ad esempio i token di autenticazione) in HttpOnly, Secure cookies.

Le seguenti pagine Exchange Stack di sicurezza sono rilevanti:

UPDATE:

Ho letto di più sui metodi anti-CSRF e ho trovato questa pagina OWASP confrontando il metodo di Double Submit Cookies con il Pattern di progettazione di Synchronizer alternativo e il Pattern token crittografato, e dichiarando che in termini di forza di difesa possono essere ordinati come:

  1. Token Synchronizer (cioè CSRF)
  2. Double Cookie Defence
  3. Modello token crittografato

(OWASP afferma anche che 1. richiede lo stato della sessione mentre 2. e 3. non richiedono uno stato lato server. C'è una discussione sul fatto che il pattern token crittografato sia effettivamente stateless nei commenti all'articolo Sfruttando il modello di token crittografato . Detto articolo descrive anche le carenze di 1. e 2. che 3. risolve, apparentemente senza introdurre nuovi problemi di sicurezza o problemi di architettura. In quanto tale, non so perché OWASP lo abbia elencato come terzo in termini di forza di difesa, forse a causa della quantità di test che è stato sottoposto a questo punto nel tempo, poiché sia esso sia Double Submit I cookie sono relativamente nuovi, forse a causa della discussione sull'apolidia / stato d'animo e la protezione degli attacchi di replay nei commenti dell'articolo? Sarebbe bello se ci fosse una spiegazione di quell'ordinamento.)

Ad ogni modo ... Se qualcuno vuole rispondere a questa domanda con l'ipotesi alternativa che sia usato il Pattern token sincronizzatore o il Pattern token crittografato, sarebbe perfetto.

    
posta Daniel 11.01.2018 - 05:34
fonte

2 risposte

8

Se qualcuno ha un XSS nel tuo sito, può fare qualsiasi che desidera su quella origine - inviare qualsiasi modulo, eseguire qualsiasi operazione, ecc. Javascript può modificare il DOM in modi arbitrari, inviare moduli, modifica la vista dell'utente, ecc.

Di conseguenza, rubare il token CSRF è l'ultima delle tue preoccupazioni: l'XSS consente qualsiasi cosa sulla stessa origine che un CSRF consentirebbe. L'unica volta che ti devi preoccupare di questo è se condividi lo stesso token CSRF su più origini (il che sarebbe una pratica inadeguata per iniziare).

    
risposta data 11.01.2018 - 07:12
fonte
3

Con XSS, hai accesso in lettura e scrittura al DOM, tra gli altri, dell'utente attaccato. Ad esempio, puoi leggere dati sensibili o eseguire attacchi di phishing.

Ma se non puoi leggere il token anti-CSRF (che ovviamente puoi) - e non puoi leggere il token di sessione -, non puoi eseguire azioni di scrittura sul server nel nome dell'utente attaccato. È comunque possibile eseguire azioni di lettura sul server, in modo da poter ottenere dati sensibili che non sono già visualizzati all'utente, ma non è possibile eseguire azioni che modificano le cose.

Ma quando il tuo token anti-CSRF è compromesso, un utente malintenzionato potrebbe eseguire qualsiasi azione che non sia ulteriormente protetta dai meccanismi di risposta alle sfide (questo è spesso il caso quando, per esempio, cambiando la password o indirizzo email, che in genere richiede l'inserimento della password corrente).

Quindi non sono d'accordo con le persone che direbbero che non è nulla di cui preoccuparsi. Compromettere il token anti-CSRF consente a un utente malintenzionato di fare molto più danni, poiché aggiorna l'accesso in sola lettura al server per accedere in lettura e scrittura nel nome dell'utente attaccato; è solo per quanto irrilevante che non puoi impedire la compromissione del token una volta che hai una vulnerabilità XSS.

    
risposta data 11.01.2018 - 10:50
fonte

Leggi altre domande sui tag