Token JWT in sessioneStorage vs cookie?

Question

Ci sono un sacco di post di blog da Stormpath che parlano di come si dovrebbe utilizzare i cookie per memorizzare la JWT invece di sessionStorage/localStorage:

• https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
• https://stormpath.com/blog/token-auth-spa
• https://stormpath.com/blog/build-secure-user-interfaces-using-jwts

Il motivo principale dichiarato è che se una dipendenza javascript di terze parti che viene caricata è compromessa dal fatto che può pilferare sessionStorage/localStorage e trasmettere il JWT ad alcuni dove.

Ma questo per me è fonte di confusione. Capisco il vettore di attacco, ma se hai una dipendenza da javascript di terze parti compromessa, non sei effettivamente avvitato comunque, dal momento che può ascoltare/catturare qualsiasi cosa facciano gli utenti mentre interagiscono con la tua app?

Answer 1

Sono l'autore di https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

Quando XSS esiste in una pagina, un attaccante ha il privilegio di:

• stoccaggio HTML5 web (locale e di sessione)
• cookie che non sono impostati con flag http ON
• Controllo della scheda fino alla sua chiusura e possibilità di effettuare richieste non autorizzate

È anche possibile iniziare a formulare attacchi per aggirare la protezione XSRF.

Quando esiste una vulnerabilità XSRF, un utente malintenzionato è privilegio di:

• Fare richieste non autorizzate da un dominio 3a parte, se si può attirare un utente lì (o inviarli lì in presenza di XSS).

È possibile notare che quando esiste una vulnerabilità XSS, è possibile effettuare richieste non autorizzate e un utente malintenzionato dovrebbe passare da qualche altro anello per sfruttare XSRF. Ciò significa che quando esiste XSS (indipendentemente dalla protezione XSRF o meno), il vettore di attacco di effettuare richieste non autorizzate esisterà.

Speriamo che questo chiarisca le cose per il mio prossimo punto.

Gli attacchi XSRF o le richieste non autorizzate hanno meno impatto e portata rispetto al furto di un token senza stato che rappresenta l'identità e la sessione dell'utente. Perdere il token significa che un attaccante avrà il pieno controllo per formulare un attacco a nome dell'utente, a suo tempo, sulle sue macchine.

In conclusione, in presenza di XSS quando:

• negozio di un token di accesso a Web Storage, i token per qualsiasi utente che utilizza il sito durante il tempo dell'esistenza di XSS è compromessa. Ciò significa che un utente malintenzionato potrebbe ottenere migliaia di token di accesso validi e può fare molto danno (anche di più se si archiviano i token di aggiornamento nella memoria Web). Gli utenti sono anche vulnerabili a fare richieste non autorizzate dal proprio browser.

• memorizzare un token di accesso in un cookie httpOnly, i token per qualsiasi utente non vengono compromessi. Ma gli utenti sono anche vulnerabili a fare richieste non autorizzate dal proprio browser anche in presenza della protezione XSRF.

Spero che questa informazione sia d'aiuto.