4 ms·

No, it is not. And I hope I never end up using any application developed this way. Tokens stored in those storages you mention can be read by any javascript co

by midrus 6y ago

No, it is not. And I hope I never end up using any application developed this way. Tokens stored in those storages you mention can be read by any javascript code, even third party. That doesn't happen with http-only cookies. Be careful with what you recommend publicly, as others might end up assuming this is fine, when it is clearly not.

warent 6y ago
If your third party libraries are so poisoned that you're leaking localstorage, you've got bigger problems than just localstorage... This argument against using localstorage makes no sense
- tmpz22 6y ago
  Chrome extensions can also inject code via a content script and gather local storage data. You can't control what extensions people are running.
  - minhazm 6y ago
    That also applies to cookies. Users can run any browser or script to access your site and do whatever they want with the cookies.
    - gigaftp 6y ago
      In the context of a compliant web browser you can set a cookie as http only as to disallow access it via Js.
    - Jenk 6y ago
      Not for http-only cookies it doesn't.
    - fractionalhare 6y ago
      No they can’t, refer to the documentation on cookie flags and attributes like httpOnly: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
- deleted 6y ago
  [deleted]
- midrus 6y ago
  Security is not black and white. It is a spectrum of possibilities and an arms race between security measures and new attack strategies. So lowering all your barriers because one of them could be already weak is not a good strategy. If you're sending your password in plain text without HTTPs, then saying "ok, nevermind, we already have that problem so let's just not use any CSRF protection" you're just making things worse. Authentication tokens that allow anyone reading them to impersonate you are bad, no discussion about it. Go and google for this if you don't believe me. Ask any security expert (which I'm not). Cookies have the exact same problem. Except if you set the http-only flag in them, which is what I'm advocating for here. You can still use localStorage, just not for security tokens.
  - anaphor 6y ago
    You seem to be unaware of the existence of capability based security. https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security
rwieruch 6y ago
Related to this I was always wondering where to store refresh tokens when using both, access token and refresh token. Reference: https://stackoverflow.com/q/57650692 https://stackoverflow.com/q/57650692
timw4mail 6y ago
So the article is about being unable to access third-party cookies due to browser privacy updates. 1. If you are using Http-only cookies, these are clearly unrelated. 2. If you are sharing an authentication token with the browser, cookie or not, it can be read by any scripts on the same origin. So...what exactly are you trying to say?
- midrus 6y ago
  > If you are sharing an authentication token with the browser, cookie or not, it can be read by any scripts on the same origin. No, it can't. Read about http-only cookies.
wayneftw 6y ago
Meh. Working at a consulting shop I've seen hundreds of apps built with tokens stored in the big bad localStorage. It's easy, it works and if you don't load scripts from untrustworthy sources then there is no attack vector outside of rendering un-sanitized user input as HTML or browser extensions. We've dealt with plenty of security issues and exactly zero of them centered around XSS. I've seen more issues surrounding bad dependencies that could end up running right inside your API server. Browser extensions can do so many other things, like reading all the forms and middling your API requests. So, I can't take responsibility for that. I would recommend http-only cookies over localStorage, but if you protect yourself in other ways then putting auth tokens in localStorage is not the end of the world. It hasn't ever affected us, so I'll leave the pearl-clutching over this up to the experts.
- midrus 6y ago
  Yep, better to wait until the security issues happen to fix them. Great mentality.
  - wayneftw 6y ago
    I hate to break it to you but that's largely the way the world works. But, we haven't had any issues with using localStorage. Probably mainly because we are not a huge target. Nobody is going to write a chrome extension to try to hack one of our tiny little sites.
inetknght 6y ago
> And I hope I never end up using any application developed this way. Slack [0] has entered the chat. Jira [1] has entered that chat. I could go on but I don't need to. Many web applications that people use store an unnecessarily obnoxious amount of data locally. I can only imagine how much of that is used just once or possibly even never (like images in settings windows that were never accessed). [0]: On one instance of Firefox on one computer, app.slack.com has stored 1.9GB. On another instance of Firefox on another computer, app.slack.com has stored about 633KB. On a third instance of Firefox on yet another computer, app.slack.com has stored about 600MB. [1]: Jira doesn't load _at all_ if you've got any secure settings enabled (like... no CORS and no cross-domain cookies and no cross-domain XHRs and ... the list goes on). So Jira loads in an incognito window in a VM. But suffice to say that its local storage is even more _fucking obnoxious_. > Tokens stored in those storages you mention can be read by any javascript code, even third party. I don't doubt you. But I am not a javascript developer. I'd like it if you could link to some demonstrations of how that can be abused.
- midrus 6y ago
  I'm not saying you shouldn't use localStorage, or sessionStorage, or indexedDB. They are valid tools and they are there for a reason. I'm saying you should not use for SECURITY tokens which, if leaked, can allow others to impersonate your user. So it doesn't matter it uses 40Gb of cached data. Security is not black or white, it is a full spectrum and despite it would be bad for a hacker to obtain a full chat historory or your list of jira card titles it is still less worrysome that somebody able to impersonate you in those services. Security is an arms race....you need to raise the barrier more and more as attacks get more and more sophisticated. So the "then just don't run extensions" or "just don't use untrusted third party scripts", despite it is something we should do, it is not a justification for lowering the bar of all the other stuff we should be doing. Regarding the references you ask for, what can I say. localStorage can be accessed by any JavaScript running in the page, even from browser extensions or XSS attacks. I'm pretty sure you will find people more knowledgeable than me here [1] and overal just googling for it you will find a lot of resources about why storing authentication tokens in localStorage is a bad idea [1] https://security.stackexchange.com/search?q=localstorage+security https://security.stackexchange.com/search?q=localstorage+sec...

by midrus 6y ago

warent 6y ago

If your third party libraries are so poisoned that you're leaking localstorage, you've got bigger problems than just localstorage... This argument against using localstorage makes no sense

tmpz22 6y ago
Chrome extensions can also inject code via a content script and gather local storage data. You can't control what extensions people are running.
- minhazm 6y ago
  That also applies to cookies. Users can run any browser or script to access your site and do whatever they want with the cookies.
  - gigaftp 6y ago
    In the context of a compliant web browser you can set a cookie as http only as to disallow access it via Js.
  - Jenk 6y ago
    Not for http-only cookies it doesn't.
  - fractionalhare 6y ago
    No they can’t, refer to the documentation on cookie flags and attributes like httpOnly: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
deleted 6y ago
[deleted]
midrus 6y ago
Security is not black and white. It is a spectrum of possibilities and an arms race between security measures and new attack strategies. So lowering all your barriers because one of them could be already weak is not a good strategy. If you're sending your password in plain text without HTTPs, then saying "ok, nevermind, we already have that problem so let's just not use any CSRF protection" you're just making things worse. Authentication tokens that allow anyone reading them to impersonate you are bad, no discussion about it. Go and google for this if you don't believe me. Ask any security expert (which I'm not). Cookies have the exact same problem. Except if you set the http-only flag in them, which is what I'm advocating for here. You can still use localStorage, just not for security tokens.
- anaphor 6y ago
  You seem to be unaware of the existence of capability based security. https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security

rwieruch 6y ago

Related to this I was always wondering where to store refresh tokens when using both, access token and refresh token. Reference: https://stackoverflow.com/q/57650692 https://stackoverflow.com/q/57650692

timw4mail 6y ago

So the article is about being unable to access third-party cookies due to browser privacy updates. 1. If you are using Http-only cookies, these are clearly unrelated. 2. If you are sharing an authentication token with the browser, cookie or not, it can be read by any scripts on the same origin. So...what exactly are you trying to say?

midrus 6y ago
> If you are sharing an authentication token with the browser, cookie or not, it can be read by any scripts on the same origin. No, it can't. Read about http-only cookies.

wayneftw 6y ago

Meh. Working at a consulting shop I've seen hundreds of apps built with tokens stored in the big bad localStorage. It's easy, it works and if you don't load scripts from untrustworthy sources then there is no attack vector outside of rendering un-sanitized user input as HTML or browser extensions. We've dealt with plenty of security issues and exactly zero of them centered around XSS. I've seen more issues surrounding bad dependencies that could end up running right inside your API server. Browser extensions can do so many other things, like reading all the forms and middling your API requests. So, I can't take responsibility for that. I would recommend http-only cookies over localStorage, but if you protect yourself in other ways then putting auth tokens in localStorage is not the end of the world. It hasn't ever affected us, so I'll leave the pearl-clutching over this up to the experts.

midrus 6y ago
Yep, better to wait until the security issues happen to fix them. Great mentality.
- wayneftw 6y ago
  I hate to break it to you but that's largely the way the world works. But, we haven't had any issues with using localStorage. Probably mainly because we are not a huge target. Nobody is going to write a chrome extension to try to hack one of our tiny little sites.

inetknght 6y ago

> And I hope I never end up using any application developed this way. Slack [0] has entered the chat. Jira [1] has entered that chat. I could go on but I don't need to. Many web applications that people use store an unnecessarily obnoxious amount of data locally. I can only imagine how much of that is used just once or possibly even never (like images in settings windows that were never accessed). [0]: On one instance of Firefox on one computer, app.slack.com has stored 1.9GB. On another instance of Firefox on another computer, app.slack.com has stored about 633KB. On a third instance of Firefox on yet another computer, app.slack.com has stored about 600MB. [1]: Jira doesn't load _at all_ if you've got any secure settings enabled (like... no CORS and no cross-domain cookies and no cross-domain XHRs and ... the list goes on). So Jira loads in an incognito window in a VM. But suffice to say that its local storage is even more _fucking obnoxious_. > Tokens stored in those storages you mention can be read by any javascript code, even third party. I don't doubt you. But I am not a javascript developer. I'd like it if you could link to some demonstrations of how that can be abused.

midrus 6y ago
I'm not saying you shouldn't use localStorage, or sessionStorage, or indexedDB. They are valid tools and they are there for a reason. I'm saying you should not use for SECURITY tokens which, if leaked, can allow others to impersonate your user. So it doesn't matter it uses 40Gb of cached data. Security is not black or white, it is a full spectrum and despite it would be bad for a hacker to obtain a full chat historory or your list of jira card titles it is still less worrysome that somebody able to impersonate you in those services. Security is an arms race....you need to raise the barrier more and more as attacks get more and more sophisticated. So the "then just don't run extensions" or "just don't use untrusted third party scripts", despite it is something we should do, it is not a justification for lowering the bar of all the other stuff we should be doing. Regarding the references you ask for, what can I say. localStorage can be accessed by any JavaScript running in the page, even from browser extensions or XSS attacks. I'm pretty sure you will find people more knowledgeable than me here [1] and overal just googling for it you will find a lot of resources about why storing authentication tokens in localStorage is a bad idea [1] https://security.stackexchange.com/search?q=localstorage+security https://security.stackexchange.com/search?q=localstorage+sec...