Menu
There are a lot of blog posts from Stormpath that talk about how you ought to use cookies to store your JWT instead of sessionStorage/localStorage:
The main stated reason is that if a 3rd-party javascript dependency that you load is compromised that it can pilfer through sessionStorage/localStorage and transmit off the JWT to somewhere.
But this is confusing as a reason to me. I understand the attack vector, but if you have a compromised 3rd-party javascript dependency, aren't you effectively screwed anyway, since it can listen-in/capture anything your users do as they interact with your app?
815
To keep them secure, you should always store JWTs inside an httpOnly cookie. This is a special kind of cookie that's only sent in HTTP requests to the server. It's never accessible (both for reading or writing) from JavaScript running in the browser.
A JWT needs to be stored in a safe place inside the user's browser. Any way,you shouldn't store a JWT in local storage (or session storage). If you store it in a LocalStorage/SessionStorage then it can be easily grabbed by an XSS attack.
The server side can send the JWT token to the browser through a cookie, and the browser will automatically bring the JWT token in the cookie header when requesting the server-side interface, and the server side can verify the JWT token in the cookie header to achieve authentication.
Cookies and tokens are two common ways of setting up authentication. Cookies are chunks of data created by the server and sent to the client for communication purposes. Tokens, usually referring to JSON Web Tokens (JWTs), are signed credentials encoded into a long string of characters created by the server.
I'm the author of https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
When XSS exist on a page, an attacker is privileged to:
You can also start to formulate attacks to get around XSRF protection.
When an XSRF vulnerability exists, an attacker is privileged to:
You can see that when an XSS vulnerability exists, you are able to make unauthorized requests and an attacker would need to jump through some more hoops to exploit XSRF. This means that when XSS exists (regardless of XSRF protection or not), the attack vector of making unauthorized requests will exist.
Hopefully, that clears things up for my next point.
An XSRF attacks or unauthorized requests has less impact and scope than stealing a stateless token that represents the user's identity and session. Leaking the token means that an attacker will have full control to formulate an attack on behalf of the user, on his time, on his machines.
In conclusion, in presence of XSS when you:
store an access token in web storage, the tokens for any user that uses your site during the time of the existence of XSS is compromised. This means an attacker could get thousands of valid access tokens and can possibly do a lot of harm (even more if you store refresh tokens in web storage). The users are also vulnerable to making unauthorized requests from their own browser.
store an access token in a httpOnly cookie, the tokens for any user are not compromised. But, the users are also vulnerable to making unauthorized requests from their own browser even in the presence of XSRF protection.
Hope this information helps.
181
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
