undefined | Better HN

0 pointsmoltar7y ago0 comments

How is that better than a cookie though? Cookies already provide automatic storage and expiry mechanism. Bonus feature is that they are not accessible by JS code at all, if set httponly flag.

0 comments

5 comments · 1 top-level

metafunctor7y ago· 4 in thread

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.

jakelazaroff7y 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.

metafunctor7y 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?

2 more replies

SahAssar7y 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.

metafunctor7y 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.

j / k navigate · click thread line to collapse

0 comments

5 comments · 1 top-level

metafunctor7y ago· 4 in thread

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.

jakelazaroff7y ago

If you use cookies as a storage mechanism and ignore the cookie header on your backend, you close the door to CSRF attacks.

metafunctor7y ago

That's true, but if you run untrusted scripts on your site it's pretty much game over, anyway.

2 more replies

SahAssar7y 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.

metafunctor7y ago

j / k navigate · click thread line to collapse