3 ms·
> Not really talking about sessions Well, mostly a JWT lets you know the user that is signed in. A server-side session generally does the same thing, but can
by stephenr 10y ago
> Not really talking about sessions
Well, mostly a JWT lets you know the user that is signed in.
A server-side session generally does the same thing, but can be used to store larger amounts of data.
> I'm trying to understand what you were saying about whatever your Javascript has access to, their Javascript does as well. Why should this be a criticism of JWT and not CSRF?
They're unrelated attack vectors.
CSRF is about bad actors producing links and/or forms on a different site to your own, that a legitimate user clicks/submits (either through social engineering or some kind of javascript in their page) causing them to make a request to your server. A CSRF token prevents this because it ensures that form submission requests have come from a form hosted on your server.
In the situation where we're worried about what someone else's JavaScript has access to, it means their javascript is already loaded into your page: a vulnerability with poorly escaped user content, a rogue browser extension, a malicious or compromised CDN, etc.
In that situation, CSRF is irrelevant. The CS in CSRF is "Cross Site" - this is no longer cross site, as the script is running in the context of your own page.
So in this situation nothing we do can prevent them from making requests within the current user session.
But what we can prevent them from doing, is stealing a user identifying token: e.g. a session cookie, by marking it HTTP Only, so the JS environment doesn't see it.
JWT's accessed over XHR/etc and stored in local storage are available to any malicious scripts running, meaning they can grab the user's JWT and send it off to their own server, allowing them to make requests as the user.
If you send JWT's as cookies and mark them as HTTP only, you've defeated the "don't send session cookies with every request" goal of JWT, and the cookie will be bigger than most session cookies.
- robertlagrant 10y ago> Well, mostly a JWT lets you know the user that is signed in. In my case I'm happy to use non-JWT methods to hold a user's session information (e.g. an HTTP-only cookie) and just want JWT to authenticate with other systems' APIs without needing to centralise auth/auth. > They're unrelated attack vectors. Good point. I guess I more just meant that what can malicious Javascript do with endpoints protected by JWT that it can't do with endpoints protected another way. > JWT's accessed over XHR/etc and stored in local storage are available to any malicious scripts running, meaning they can grab the user's JWT and send it off to their own server, allowing them to make requests as the user. I guess this answers the above question: the difference isn't in what can be executed in the browser, but what can be shipped to a different server to be used in attacks from there. To mitigate that, then, how's this setup: 1) User's session is maintained in HTTP-only cookies. 2) Browser can use (1) to request a JWT token (and a refresh key) to hit a 3rd-party API endpoint. The token is valid for 5 minutes. 3) Browser can use the refresh key from (2) to request another JWT token. Does that pretty much bring it up to parity with using cookies everywhere, while keeping the goal of noncentral auth/auth?