Nel contesto dei JWT , Stormpath ha scritto un articolo abbastanza utile delineando possibili modi per memorizzarli e i (dis) vantaggi relativi a ciascun metodo.
Ha anche una breve panoramica degli attacchi XSS e CSRF e su come combatterli.
Ho allegato alcuni brevi frammenti dell'articolo qui sotto, nel caso in cui il loro articolo venga portato offline / il loro sito non funzioni.
Memoria locale
I problemi:
L'archiviazione Web (localStorage / sessionStorage) è accessibile tramite JavaScript sullo stesso dominio. Ciò significa che qualsiasi JavaScript in esecuzione sul tuo sito avrà accesso all'archiviazione Web e per questo motivo può essere vulnerabile agli attacchi cross-site scripting (XSS). XSS in breve è un tipo di vulnerabilità in cui un utente malintenzionato può iniettare JavaScript che verrà eseguito sulla tua pagina. Gli attacchi XSS di base tentano di iniettare JavaScript attraverso gli input del modulo, in cui l'attaccante mette in allerta ("Sei violato"); in un modulo per vedere se è gestito dal browser e può essere visualizzato da altri utenti.
Prevenzione:
Per impedire XSS, la risposta comune è quella di fuggire e codificare tutti i dati non attendibili. Ma questo è lontano dalla storia completa. Nel 2015 le moderne app Web utilizzano JavaScript ospitato su CDN o infrastrutture esterne. Le app Web moderne includono librerie JavaScript di terze parti per test A / B, analisi di canalizzazione / mercato e pubblicità. Utilizziamo gestori di pacchetti come Bower per importare il codice di altre persone nelle nostre app.
Che cosa succede se solo uno degli script che usi è compromesso? JavaScript dannoso può essere incorporato nella pagina e l'archiviazione Web è compromessa. Questi tipi di attacchi XSS possono ottenere l'archiviazione Web di tutti che visita il tuo sito, a loro insaputa. Questo è probabilmente il motivo per cui un gruppo di organizzazioni consiglia di non archiviare nulla di valore o di fidarsi di qualsiasi informazione nella memoria web. Ciò include identificatori di sessione e token.
Come meccanismo di archiviazione, l'archiviazione Web non applica alcun standard sicuro durante il trasferimento. Chiunque legga l'archiviazione Web e la usi deve fare la dovuta diligenza per assicurarsi di inviare sempre il JWT su HTTPS e mai HTTP.
Biscotti
I problemi:
I cookie, se utilizzati con il flag dei cookie HttpOnly, non sono accessibili tramite JavaScript e sono immuni da XSS. È inoltre possibile impostare il flag Secure cookie per garantire che il cookie venga inviato solo su HTTPS. Questo è uno dei motivi principali per cui i cookie sono stati sfruttati in passato per memorizzare token o dati di sessione. Gli sviluppatori moderni sono restii a usare i cookie perché tradizionalmente richiedono che lo stato sia archiviato sul server, infrangendo così le migliori pratiche RESTful. I cookie come meccanismo di archiviazione non richiedono che lo stato sia archiviato sul server se si memorizza un JWT nel cookie. Questo perché JWT incapsula tutto ciò di cui il server ha bisogno per soddisfare la richiesta.
Tuttavia, i cookie sono vulnerabili a un diverso tipo di attacco: falsificazione di richieste tra siti (CSRF). Un attacco CSRF è un tipo di attacco che si verifica quando un sito Web, e-mail o blog dannoso fa sì che il browser Web di un utente esegua un'azione indesiderata su un sito attendibile su cui l'utente è attualmente autenticato. Questo è un exploit di come il browser gestisce i cookie. Un cookie può essere inviato solo ai domini in cui è consentito. Per impostazione predefinita, questo è il dominio che ha originariamente impostato il cookie. Il cookie verrà inviato per una richiesta indipendentemente dal fatto che tu sia su galaxies.com o hahagonnahackyou.com.
Prevenzione:
I browser moderni supportano la SameSitebandiera , oltre a HttpOnlye Secure. Lo scopo di questo flag è impedire la trasmissione del cookie nelle richieste tra siti, impedendo molti tipi di attacchi CSRF.
Per i browser che non supportano SameSite, CSRF può essere prevenuto utilizzando modelli di token sincronizzati. Sembra complicato, ma tutti i moderni framework web hanno il supporto per questo.
Ad esempio, AngularJS ha una soluzione per confermare che il cookie è accessibile solo dal tuo dominio. Direttamente dai documenti di AngularJS:
Quando si eseguono richieste XHR, il servizio $ http legge un token da un cookie (per impostazione predefinita, XSRF-TOKEN) e lo imposta come intestazione HTTP (X-XSRF-TOKEN). Dal momento che solo JavaScript che viene eseguito sul tuo dominio può leggere il cookie, il tuo server può essere certo che l'XHR provenga da JavaScript in esecuzione sul tuo dominio. Puoi rendere questa protezione CSRF apolide includendo un xsrfTokenreclamo JWT:
{
"iss": "http://galaxies.com",
"exp": 1300819380,
"scopes": ["explorer", "solar-harvester", "seller"],
"sub": "tom@andromeda.com",
"xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}
Sfruttando la protezione CSRF del framework dell'app Web, i cookie sono estremamente affidabili per l'archiviazione di un JWT. CSRF può anche essere parzialmente prevenuto controllando l'intestazione HTTP Referer e Origin dalla tua API. Gli attacchi CSRF avranno intestazioni Referer e Origin non correlate alla tua applicazione.
L'articolo completo è disponibile qui:
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/
Hanno anche un utile articolo su come progettare e implementare al meglio i JWT, per quanto riguarda la struttura del token stesso:
https://stormpath.com/blog/jwt-the-right-way/