2015-06-26 16 views
9

Esistono molti articoli in cui si discute su quale sia il posto migliore per memorizzare JWT sul lato client. In breve, sono tutti circa -: cookie vs intestazione

  • solo HTTP sicuro cookie - non XSS, ma vulnarable a XSRF

  • Header (salvato nella memoria locale o DOM) - non XSRF, ma vulnarable a XSS

penso di trovare una soluzione estremamente di buon senso a questo, ma, visto che sono niubbo completo in sicurezza non sono sicuro se è davvero di buon senso o stupido.

Quindi, cosa succede se dividere JWT e salvarne una parte nel cookie e un'altra parte nell'intestazione? Sarebbe inviolabile?

Questo dovrebbe anche risolvere 'disconnettersi' problematici -. L'eliminazione di parte di testa del browser renderebbe incapace di registrazione in

Con i migliori saluti, Eugene.

risposta

8

Il JWT deve rimanere insieme, altrimenti la convalida della firma non funzionerà.

La protezione da XSRF è piuttosto semplice, è sufficiente un altro cookie.

Non utilizzare mai la memoria locale per la memorizzazione delle informazioni di autenticazione, non segue le stesse regole di dominio e di origine dei cookie. Per saperne di più qui:

https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Storage_APIs

Disclaimer: lavorare a Stormpath, abbiamo una soluzione di gestione degli utenti ospitato e spendiamo un sacco di tempo in materia di sicurezza. Ho scritto due post del blog in cui discuto JWTs e autenticazione front-end:

Token Based Authentication for Single Page Apps (SPAs)

https://stormpath.com/blog/build-secure-user-interfaces-using-jwts/

Spero che questo aiuti!

+0

Ma un cookie aggiuntivo per la protezione da XSRF significa mantenere la sessione lato server, giusto? Se è così, incollare JWT insieme è molto più semplice e leggero. E ancora, se solo una parte di JWT è immagazzinata nell'archivio locale, può essere di qualsiasi valore per un utente malintenzionato? – user656449

Problemi correlati