3 ms·

Browsers automatically attach cookies to HTTP requests, opening the door to attacks like CSRF. The security impact of automatic client-side expiry is tiny, sin

Browsers automatically attach cookies to HTTP requests, opening the door to attacks like CSRF. The security impact of automatic client-side expiry is tiny, since token expiration must be done server-side anyway. The HttpOnly flag as an XSS mitigation is almost useless; competent attackers will simply run their code from the victim's browser and session. To protect against XSS, HttpOnly doesn't really help you at all. You should be setting a CSP that prevents inline and 3rd party scripts by default, and whitelist what you must. Overall, cookies may seem like they have a lot of security features, but in reality they are just patches over poor original design. IMHO, using local storage is probably better, because there's less room to get it wrong.

jakelazaroff 8y ago
If you use cookies as a storage mechanism and ignore the cookie header on your backend, you close the door to CSRF attacks. Here's one glaring problem with local storage: literally any script on your page can access it (for example, vendor scripts). Cookies can only be accessed by scripts from the same domain from which they're created.
- metafunctor 8y ago
  That's true, but if you run untrusted scripts on your site it's pretty much game over, anyway. Why should those scripts limit themselves to stealing tokens when they can send authenticated requests from the browser? To put it another way, why would you care about knowing the root password when you have a way to run a root shell at will?
  - jakelazaroff 8y ago
    How can they send authenticated requests if they can't access your cookies and your backend ignores the cookie header?
    - metafunctor 8y ago
      The scenario is XSS, where the attacker manages to run their JS code on your page, and get all the same privileges as your own code on the page. Whatever mechanism your own JS code uses to perform authenticated requests, the attacker can do the same.
      - jakelazaroff 8y ago
        That is not the scenario you described (running untrusted scripts on your site). Cookies are not protected from XSS, but they are protected against malicious or compromised vendor/CDN scripts and browser extensions. Local storage, however, is vulnerable to all of the above.
        metafunctor 8y ago
        It seems that you are saying that cookies are more protected from third party code than your own code. That is incorrect. Let's get specific: let's say you have a page on mysite.com. When a user signs in, the server sets a HttpOnly session cookie to authenticate later requests from the user. Now let's assume your page loads evilsite.com/tracker.js. The code in tracker.js can now send requests to mysite.com, and your HttpOnly session cookie will be sent. There is no extra protection for cookies that would check if the JS code doing the sending came from mysite.com. Obviously tracker.js cannot read the value of your session cookie (and, indeed, neither can your own code), but mysite.com is more or less totally compromised.
        jakelazaroff 8y ago
        You're describing CSRF, but again: this vulnerability doesn't exist in the scenario I'm describing. If you don't set HttpOnly on your cookies and ignore the cookie header on your backend (i.e. only use cookies for storage, not for transport), cookies are strictly better than local storage, since the only difference between the two is now local storage's lax access policy. The scenario you're describing can also be solved by using a CSRF token retrieved from the backend. Meanwhile, there is literally no way to secure secrets kept in local storage from third party scripts.
  - filleduchaos 8y ago
    It's interesting that every time this comes up people talk as though the only vector for a malicious script running on your site is you serving it yourself. A reminder that browsers have a ridiculously lax permissions/security model for extensions which extension developers have been shown again and again to abuse (see the Stylish incident for instance).
SahAssar 8y ago
> competent attackers will simply run their code from the victim's browser and session What do you mean? JS even on the same page can't read HTTPOnly cookies. If you are assuming that the browser has been hacked then it is pretty much game over regardless of what you use.
- metafunctor 8y ago
  We are talking about XSS, where an attacker can run their JS code on your page. If the attacker can run JS on your page, they can already do whatever your signed-in user can do. No need to read the cookie to make authenticated requests, just like your own code doesn’t need to read the cookie.

jakelazaroff 8y ago

If you use cookies as a storage mechanism and ignore the cookie header on your backend, you close the door to CSRF attacks. Here's one glaring problem with local storage: literally any script on your page can access it (for example, vendor scripts). Cookies can only be accessed by scripts from the same domain from which they're created.

metafunctor 8y ago
That's true, but if you run untrusted scripts on your site it's pretty much game over, anyway. Why should those scripts limit themselves to stealing tokens when they can send authenticated requests from the browser? To put it another way, why would you care about knowing the root password when you have a way to run a root shell at will?
- jakelazaroff 8y ago
  How can they send authenticated requests if they can't access your cookies and your backend ignores the cookie header?
  - metafunctor 8y ago
    The scenario is XSS, where the attacker manages to run their JS code on your page, and get all the same privileges as your own code on the page. Whatever mechanism your own JS code uses to perform authenticated requests, the attacker can do the same.
    - jakelazaroff 8y ago
      That is not the scenario you described (running untrusted scripts on your site). Cookies are not protected from XSS, but they are protected against malicious or compromised vendor/CDN scripts and browser extensions. Local storage, however, is vulnerable to all of the above.
      - metafunctor 8y ago
        It seems that you are saying that cookies are more protected from third party code than your own code. That is incorrect. Let's get specific: let's say you have a page on mysite.com. When a user signs in, the server sets a HttpOnly session cookie to authenticate later requests from the user. Now let's assume your page loads evilsite.com/tracker.js. The code in tracker.js can now send requests to mysite.com, and your HttpOnly session cookie will be sent. There is no extra protection for cookies that would check if the JS code doing the sending came from mysite.com. Obviously tracker.js cannot read the value of your session cookie (and, indeed, neither can your own code), but mysite.com is more or less totally compromised.
        jakelazaroff 8y ago
        You're describing CSRF, but again: this vulnerability doesn't exist in the scenario I'm describing. If you don't set HttpOnly on your cookies and ignore the cookie header on your backend (i.e. only use cookies for storage, not for transport), cookies are strictly better than local storage, since the only difference between the two is now local storage's lax access policy. The scenario you're describing can also be solved by using a CSRF token retrieved from the backend. Meanwhile, there is literally no way to secure secrets kept in local storage from third party scripts.
- filleduchaos 8y ago
  It's interesting that every time this comes up people talk as though the only vector for a malicious script running on your site is you serving it yourself. A reminder that browsers have a ridiculously lax permissions/security model for extensions which extension developers have been shown again and again to abuse (see the Stylish incident for instance).

SahAssar 8y ago

> competent attackers will simply run their code from the victim's browser and session What do you mean? JS even on the same page can't read HTTPOnly cookies. If you are assuming that the browser has been hacked then it is pretty much game over regardless of what you use.

metafunctor 8y ago
We are talking about XSS, where an attacker can run their JS code on your page. If the attacker can run JS on your page, they can already do whatever your signed-in user can do. No need to read the cookie to make authenticated requests, just like your own code doesn’t need to read the cookie.