JWT deve essere archiviato in localStorage o cookie? [duplicare]

99

Allo scopo di proteggere l'API REST utilizzando JWT, secondo alcuni materiali (come questa guida e questa domanda ), il JWT può essere memorizzato in localStorage o Cookie . Sulla base della mia comprensione:

localStorage è soggetto a XSS e generalmente non è consigliabile archiviarvi informazioni sensibili.
Con i cookie possiamo applicare il flag "httpOnly" che mitiga il rischio di XSS. Tuttavia, se dobbiamo leggere il JWT dai cookie sul back-end, siamo quindi soggetti a CSRF.

Quindi, in base alla premessa di cui sopra, sarà meglio se memorizziamo JWT nei cookie. Ad ogni richiesta al server, il JWT verrà letto dai cookie e aggiunto nell'intestazione di autorizzazione utilizzando lo schema Bearer. Il server può quindi verificare il JWT nell'intestazione della richiesta (invece di leggerlo dai cookie).

La mia comprensione è corretta? In caso affermativo, l'approccio di cui sopra ha qualche problema di sicurezza? O in realtà possiamo semplicemente farla franca usando localStorage in primo luogo?

— pkid169
fonte

4

controlla questo: cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions

— corlaez

@ lrn2prgrm poiché non si dovrebbero usare JWT (senza stato) e semantica di sessione (con stato) insieme.

— ozanmuyes

56

Mi piace il metodo XSRF Double Submit Cookies menzionato nell'articolo detto da @ pkid169, ma c'è una cosa che l'articolo non ti dice. Non sei ancora protetto da XSS perché ciò che l'attaccante può fare è iniettare uno script che legge il tuo cookie CSRF (che non è HttpOnly) e quindi effettuare una richiesta a uno dei tuoi endpoint API utilizzando questo token CSRF con il cookie JWT inviato automaticamente.

Quindi in realtà sei ancora suscettibile a XSS, è solo che l'attaccante non può rubarti il token JWT per un uso successivo, ma può comunque effettuare richieste per conto dei tuoi utenti utilizzando XSS.

Sia che memorizzi il tuo JWT in un localStorage o che archivi il tuo token XSRF in un cookie non solo http, entrambi possono essere facilmente acquisiti da XSS. Anche il tuo cookie JWT in HttpOnly può essere catturato da un attacco XSS avanzato.

Quindi, oltre al metodo Double Submit Cookies, devi sempre seguire le migliori pratiche contro XSS, incluso l'escape dei contenuti. Ciò significa rimuovere qualsiasi codice eseguibile che indurrebbe il browser a fare qualcosa che non vuoi che faccia. In genere ciò significa rimuovere i tag // <! [CDATA [e gli attributi HTML che determinano la valutazione di JavaScript.

— Iman Sedighi
fonte

11

Puoi chiarire come si può prendere un JWT in HttpOnly cookie? Può essere utilizzato da XSRF se il token XSRF è compromesso da XSS, ma può davvero essere afferrato da solo?

— Jacek Gorgoń

1

So che questo è un vecchio post, ma vorrei porre alcune domande ... Significa che script ben congegnati possono leggere sia localStorage che cookie? In tal caso, è lecito ritenere che un JWT possa essere rubato indipendentemente da dove lo memorizziamo in un browser? Quindi, mi sento come se fare affidamento esclusivamente su un JWT sia molto rischioso.

— Hiroki

2

"Anche il tuo cookie JWT in HttpOnly può essere catturato da un attacco XSS avanzato." è falso. Post originale modificato per correggere questo problema.

— java-addict301

"Anche il tuo JWT nel cookie HttpOnly può essere catturato da un attacco XSS avanzato" Posso immaginare che qualcuno prenda il cookie inviandolo al proprio server. Per questo può utilizzare fetch con il valore appropriato del flag delle credenziali. Il problema principale qui è la protezione CORS ma in alcune circostanze penso che sia possibile.

— bartnikiewi.cz

"Inject script che legge il cookie CSRF (che non è HttpOnly)" L'implementazione predefinita di Html.AntiForgeryToken()in ASP.NET MVC utilizza un cookie HttpOnly per il token CSRF. Penso che tu sia ancora suscettibile a determinati XSS, ma ho pensato che valesse la pena menzionarlo.

— Lovethenakedgun

21

Un tempestivo post di Stormpath ha praticamente elaborato i miei punti e risposto alla mia domanda.

TL; DR

Memorizza il JWT nei cookie, quindi passa il JWT nell'intestazione di autorizzazione su ogni richiesta come ho menzionato, o come suggerisce l'articolo, fai affidamento sul backend per prevenire CSRF (ad esempio usando xsrfTokenin caso di Angular).

— pkid169
fonte

2

Ciao, non sono sicuro che sia corretto, ma ci sono alcuni svantaggi particolari nell'usare i cookie per memorizzare jwt quando stai implementando CrossOrigin per i tuoi controller, questa è una scena in cui la mia app server si trova in un posto diverso e stiamo chiamando il api da esso nella nostra app client che si trova diciamo in un'altra città? Non è per questo che molti fornitori di servizi web si astengono dall'utilizzare i cookie?

— valik

CrossOrigin non significa luoghi fisici. Si riferisce a richieste provenienti da altri domini. In .net core quando decidi di utilizzare CORS specifichi quali domini consentirai; quali intestazioni consentire, ecc.

— Brian Allan West

11

Non memorizzare il tuo token in LocalStorage o SessionStorage, perché tale token può essere letto da javascript e quindi è vulnerabile ad attacchi XSS.
Non memorizzare il tuo token in Cookie. Cookie (con flag HttpOnly) è un'opzione migliore: è soggetto a XSS, ma è vulnerabile agli attacchi CSRF

Al momento dell'accesso, puoi invece fornire due token: token di accesso e token di aggiornamento. Il token di accesso deve essere archiviato nella memoria Javascript e il token di aggiornamento deve essere archiviato in HttpOnly Cookie. Il token di aggiornamento viene utilizzato solo e solo per creare nuovi token di accesso, niente di più.

Quando l'utente apre una nuova scheda o durante l'aggiornamento del sito, è necessario eseguire una richiesta per creare un nuovo token di accesso, in base al token di aggiornamento archiviato in Cookie.

Consiglio vivamente anche di leggere questo articolo: https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/

— devstructor
fonte

5

Perché la complessità aggiunta quando puoi semplicemente trattare il token di aggiornamento come un token di accesso? Come è questo approccio più sicuro dato che segnalare il mio token di accesso come secure, samesite: strict, http-only?

— Charming Robot

non è più sicuro

— Chris Hawkes il

2

Per aiutare a prevenire attacchi CSRF che sfruttano i cookie esistenti, puoi impostare il tuo cookie con la SameSitedirettiva. Impostalo su laxo strict.

Questa è ancora una bozza e dal 2019 non è completamente supportata da tutti i browser attuali , ma a seconda della sensibilità dei dati e / o del controllo sui browser utilizzati dagli utenti, potrebbe essere un'opzione praticabile. L'impostazione della direttiva con SameSite=laxconsentirà "navigazioni di primo livello che utilizzano un metodo HTTP" sicuro "."

— Ian Hunter
fonte