3 ms·

No need to stop. The XSS argument also applies when using cookies. JWTs are just tokens like session data but in JSON format. What format you choose to go with

No need to stop. The XSS argument also applies when using cookies. JWTs are just tokens like session data but in JSON format. What format you choose to go with doesn't matter. You can keep storing JWTs in local storage and still be secure. Discord removes it on page load and restores it when the tab is closed. Also if your website is susceptible to XSS, skill issue, exactly like in the case of SQL injections. That wouldn't have happened had people used the right tools and not played with fire.

wccrawford 4mo ago
I think anything can be abused, and too many people don't have a security-first mindset. One of the advantages of JWTs is that you don't have to check your database or filesystem to make sure the the user is valid and logged in. All that data is in the JWT. If it's just a static page, it doesn't need to hit any data. The problem then comes that some developers think that makes it secure, and don't check the database for revocation before doing anything with the account. Especially not for giving out private data. They might check before changing any data. I think it's a really neat idea that is far too easy to mishandle and create a bad situation. It can save a lot of bandwidth and CPU cycles if you have a lot of non-interactive pages and all you need to know is whether to show that the user is logged in or not. But for actually doing anything, it's practically no better than a session cookie, and it's got a lot of foot-guns.
dariosalvi78 4mo ago
with cookies you can restrict them to HttpOnly so that they are not exposed to client-side scripts. This reduces the chances of XSS to access the long-lived access tokens (JWT or session ids).
- littlecranky67 4mo ago
  This. I store my JWT in a cookie, and the cookie is of course set to HttpOnly,Secure and SameSite=strict. That basically kills XSS. I do not use openid connect, and one of my pet peeves with OIDC is that the access/refresh tokens are always exposed to the JS side (not in a cookie using HttpOnly) in any impl. i've seen.
- Sohcahtoa82 4mo ago
  HttpOnly makes it so XSS can't steal your token, but that won't stop XSS from using your token.
  - unscaled 4mo ago
    True. But XSS stealing your token (which is always possible with localStorage) is still worse than XSS using your token. It's the principle of least privilege all over again.
jkrejcha 4mo ago
A lot of times local storage is much less secure than using cookies. Cookies have about 20 years of infra built around it (HttpOnly, SameSite, Secure, etc). There's some weird parts about cookies, but local storage really shouldn't be used for anything security sensitive
- megous 4mo ago
  20 years of security: sqlite3 cookies.sqlite 'SELECT name, value FROM moz_cookies WHERE isSecure AND isHttpOnly' And that's a supposedly a master password protected browser. They can't even bother encrypting cookies. Don't be ridiculous.
  - jkrejcha 4mo ago
    If the attacker can already execute code as you unrestricted, then you've kinda already lost. Local storage isn't any better in this regard
    - szmarczak 4mo ago
      That's why I wouldn't say the below. > A lot of times local storage is much less secure Without XSS, local storage is actually more secure. You don't have worry 'did I set up this right' because there is nothing to set up and CSRF is impossible to execute. If you're still paranoid about XSS, CSP is your friend. Also check isTrusted on events.
      - jkrejcha 4mo ago
        If you exclude all of the flaws of one implementation and include all of the flaws of another, then of course you can say one is better than the other. But that's not a fair comparison of implementations CSRF has incredibly simple mitigations with cookies (SameSite=strict) and can even work across different path segments (although this tends to be uncommon) and has mitigations against XSS which local storage does not. XSS is bad in either case (CSPs aren't usually an effective mitigation for a variety of reasons[1]) but being able to outright steal the session token is worse than being able to use it in a potentially more limited context [1]: Primarily that they're generally just not implemented and that a lot of web frameworks require incredibly loose CSPs up to and including unsafe-eval since they often need to dynamically load JS. In addition, this doesn't protect from supply chain attacks (JS that is injected as the result of it being loaded from another domain, like from a CDN for example).
adithyassekhar 4mo ago
> Discord removes it on page load and restores it when the tab is closed. How does this work? You have no real control over what the browser does when it closes a tab.
- efilife 4mo ago
  I've always wondered how they do it as well. Second problem - if they remove it from localstorage they still need to hold them somewhere. So are they moved to a simple variable then? It's just as accessible as localStorage. Maybe it's randomized every load?
  - szmarczak 4mo ago
    > I've always wondered how they do it as well. See https://news.ycombinator.com/item?id=48574402 https://news.ycombinator.com/item?id=48574402 > So are they moved to a simple variable then? Yup, it has to exist somewhere.
- szmarczak 4mo ago
  Except you do. https://developer.mozilla.org/en-US/docs/Web/API/Window/unload_event https://developer.mozilla.org/en-US/docs/Web/API/Window/unlo... What happens if you lose power? You're logged out because it didn't save the token back. Verified this by pausing JS execution and killing Firefox. (the local storage key is "token")

wccrawford 4mo ago

I think anything can be abused, and too many people don't have a security-first mindset. One of the advantages of JWTs is that you don't have to check your database or filesystem to make sure the the user is valid and logged in. All that data is in the JWT. If it's just a static page, it doesn't need to hit any data. The problem then comes that some developers think that makes it secure, and don't check the database for revocation before doing anything with the account. Especially not for giving out private data. They might check before changing any data. I think it's a really neat idea that is far too easy to mishandle and create a bad situation. It can save a lot of bandwidth and CPU cycles if you have a lot of non-interactive pages and all you need to know is whether to show that the user is logged in or not. But for actually doing anything, it's practically no better than a session cookie, and it's got a lot of foot-guns.

dariosalvi78 4mo ago

with cookies you can restrict them to HttpOnly so that they are not exposed to client-side scripts. This reduces the chances of XSS to access the long-lived access tokens (JWT or session ids).

littlecranky67 4mo ago
This. I store my JWT in a cookie, and the cookie is of course set to HttpOnly,Secure and SameSite=strict. That basically kills XSS. I do not use openid connect, and one of my pet peeves with OIDC is that the access/refresh tokens are always exposed to the JS side (not in a cookie using HttpOnly) in any impl. i've seen.
Sohcahtoa82 4mo ago
HttpOnly makes it so XSS can't steal your token, but that won't stop XSS from using your token.
- unscaled 4mo ago
  True. But XSS stealing your token (which is always possible with localStorage) is still worse than XSS using your token. It's the principle of least privilege all over again.

jkrejcha 4mo ago

A lot of times local storage is much less secure than using cookies. Cookies have about 20 years of infra built around it (HttpOnly, SameSite, Secure, etc). There's some weird parts about cookies, but local storage really shouldn't be used for anything security sensitive

megous 4mo ago
20 years of security: sqlite3 cookies.sqlite 'SELECT name, value FROM moz_cookies WHERE isSecure AND isHttpOnly' And that's a supposedly a master password protected browser. They can't even bother encrypting cookies. Don't be ridiculous.
- jkrejcha 4mo ago
  If the attacker can already execute code as you unrestricted, then you've kinda already lost. Local storage isn't any better in this regard
  - szmarczak 4mo ago
    That's why I wouldn't say the below. > A lot of times local storage is much less secure Without XSS, local storage is actually more secure. You don't have worry 'did I set up this right' because there is nothing to set up and CSRF is impossible to execute. If you're still paranoid about XSS, CSP is your friend. Also check isTrusted on events.
    - jkrejcha 4mo ago
      If you exclude all of the flaws of one implementation and include all of the flaws of another, then of course you can say one is better than the other. But that's not a fair comparison of implementations CSRF has incredibly simple mitigations with cookies (SameSite=strict) and can even work across different path segments (although this tends to be uncommon) and has mitigations against XSS which local storage does not. XSS is bad in either case (CSPs aren't usually an effective mitigation for a variety of reasons[1]) but being able to outright steal the session token is worse than being able to use it in a potentially more limited context [1]: Primarily that they're generally just not implemented and that a lot of web frameworks require incredibly loose CSPs up to and including unsafe-eval since they often need to dynamically load JS. In addition, this doesn't protect from supply chain attacks (JS that is injected as the result of it being loaded from another domain, like from a CDN for example).

adithyassekhar 4mo ago

> Discord removes it on page load and restores it when the tab is closed. How does this work? You have no real control over what the browser does when it closes a tab.

efilife 4mo ago
I've always wondered how they do it as well. Second problem - if they remove it from localstorage they still need to hold them somewhere. So are they moved to a simple variable then? It's just as accessible as localStorage. Maybe it's randomized every load?
- szmarczak 4mo ago
  > I've always wondered how they do it as well. See https://news.ycombinator.com/item?id=48574402 https://news.ycombinator.com/item?id=48574402 > So are they moved to a simple variable then? Yup, it has to exist somewhere.
szmarczak 4mo ago
Except you do. https://developer.mozilla.org/en-US/docs/Web/API/Window/unload_event https://developer.mozilla.org/en-US/docs/Web/API/Window/unlo... What happens if you lose power? You're logged out because it didn't save the token back. Verified this by pausing JS execution and killing Firefox. (the local storage key is "token")