6 ms·

Cookies suck. The interface is beyond terrible, they were never scoped properly, and they don't have to be used. Browser storage (sessionStorage, localStorage)

Cookies suck. The interface is beyond terrible, they were never scoped properly, and they don't have to be used. Browser storage (sessionStorage, localStorage) is perfectly valid for storing an authentication token.

kostarelo 6y ago
By interface you mean.. the HTTP protocol? At least they can be scoped on the domain level. Browser storage can't.
- leipert 6y ago
  Local storage and Session Storage are scoped per origin as well: https://developer.mozilla.org/en-US/docs/Glossary/Origin https://developer.mozilla.org/en-US/docs/Glossary/Origin
  - pmlnr 6y ago
    origin != domain level. See https://publicsuffix.org/list/public_suffix_list.dat https://publicsuffix.org/list/public_suffix_list.dat
    - wdb 6y ago
      Got to admit I only learned about this because of the Github Private Page item posted earlier on HN. I still not clear what this list does or tries to do. Can't find much about it on MDN. Need to do a bit more digging
kadfak 6y ago
Leaking your auth tokens through XSS sucks more.
- leipert 6y ago
  I don’t know whether you are referring to only local and session storage being feasible or not, but on can access cookies from JS as well.
  - AlbinoDrought 6y ago
    Normal cookies are JS-accessible, but HTTP-only cookies should not be: "A cookie with the HttpOnly attribute is inaccessible to the JavaScript Document.cookie API; it is sent only to the server." https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#re...
    - leipert 6y ago
      Ah thanks! This is new to me. That is indeed a concern, but probably can be worked around, e.g. by proxying requests to third party domains through the same Domain.
      - kreetx 6y ago
        You can't make the browser to send you cookies for other origins so you won't be able to use them from your server.
  - fractionalhare 6y ago
    Which is why you use domain scoping, httpOnly and Secure cookie flags so they can only be read by matching hosts (with greater granularity than same-origin policy) over HTTPS and can’t be read by JavaScript. The Web Storage API does not offer these protections.
    - dkarras 6y ago
      They can't be read BUT the browser will send the cookie with every request. If you have an XSS, it is game over. The attacker can just send requests from your browser. Slightly less convenient. You are merely taking away the convenience of the attacker doing the attack manually on his own browser, which he probably doesn't want to do anyways. If he can inject js into your site, he will make your browser send the request(s) to do the actions with your credentials in an automated and quick way. Your browser will send the cookie automatically. From the attacker, it would merely be nice if he could read your tokens, but it is absolutely not necessary. Like some here, I don't understand the hate around keeping tokens in localstorage. People immediately say "but js can read it!" but so what? If someone can put malicious js in my site, it is GAME OVER, secure http-only cookie or not. When that is the case, the saner option is doing away with an old and misused invention called cookies. The upside with ditching cookies is that you are an order of magnitude safer against CSRF since your browser does not send anything automatically. You don't need to keep CSRF token state in your server(s) either (helps with scale, one less state to worry about), it is a win. http-only secure cookies do not give you any additional security. Ditching cookies does.
- asabil 6y ago
  If you have an xss your problem is much bigger than leaking an ephemeral access token through localStorage
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
notsureaboutpg 6y ago
localStorage doesn't work in many browsers' private modes, so no... it's not

kostarelo 6y ago

By interface you mean.. the HTTP protocol? At least they can be scoped on the domain level. Browser storage can't.

leipert 6y ago
Local storage and Session Storage are scoped per origin as well: https://developer.mozilla.org/en-US/docs/Glossary/Origin https://developer.mozilla.org/en-US/docs/Glossary/Origin
- pmlnr 6y ago
  origin != domain level. See https://publicsuffix.org/list/public_suffix_list.dat https://publicsuffix.org/list/public_suffix_list.dat
  - wdb 6y ago
    Got to admit I only learned about this because of the Github Private Page item posted earlier on HN. I still not clear what this list does or tries to do. Can't find much about it on MDN. Need to do a bit more digging

kadfak 6y ago

Leaking your auth tokens through XSS sucks more.

leipert 6y ago
I don’t know whether you are referring to only local and session storage being feasible or not, but on can access cookies from JS as well.
- AlbinoDrought 6y ago
  Normal cookies are JS-accessible, but HTTP-only cookies should not be: "A cookie with the HttpOnly attribute is inaccessible to the JavaScript Document.cookie API; it is sent only to the server." https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#re...
  - leipert 6y ago
    Ah thanks! This is new to me. That is indeed a concern, but probably can be worked around, e.g. by proxying requests to third party domains through the same Domain.
    - kreetx 6y ago
      You can't make the browser to send you cookies for other origins so you won't be able to use them from your server.
- fractionalhare 6y ago
  Which is why you use domain scoping, httpOnly and Secure cookie flags so they can only be read by matching hosts (with greater granularity than same-origin policy) over HTTPS and can’t be read by JavaScript. The Web Storage API does not offer these protections.
  - dkarras 6y ago
    They can't be read BUT the browser will send the cookie with every request. If you have an XSS, it is game over. The attacker can just send requests from your browser. Slightly less convenient. You are merely taking away the convenience of the attacker doing the attack manually on his own browser, which he probably doesn't want to do anyways. If he can inject js into your site, he will make your browser send the request(s) to do the actions with your credentials in an automated and quick way. Your browser will send the cookie automatically. From the attacker, it would merely be nice if he could read your tokens, but it is absolutely not necessary. Like some here, I don't understand the hate around keeping tokens in localstorage. People immediately say "but js can read it!" but so what? If someone can put malicious js in my site, it is GAME OVER, secure http-only cookie or not. When that is the case, the saner option is doing away with an old and misused invention called cookies. The upside with ditching cookies is that you are an order of magnitude safer against CSRF since your browser does not send anything automatically. You don't need to keep CSRF token state in your server(s) either (helps with scale, one less state to worry about), it is a win. http-only secure cookies do not give you any additional security. Ditching cookies does.
asabil 6y ago
If you have an xss your problem is much bigger than leaking an ephemeral access token through localStorage

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

notsureaboutpg 6y ago

localStorage doesn't work in many browsers' private modes, so no... it's not