Hacker News new | ask | show | jobs
by jakelazaroff 2730 days 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.
1 comments
metafunctor 2730 days ago
No, I'm describing XSS. You know, where an attacker injects scripts on your pages, and the attacker's requests come from the same origin as your own requests. In CSRF, the attack is hosted outside the target site.

I don't believe a situation exists where using cookies for client-side storage is more secure than local storage. Could you please explain this in more detail?

link
jakelazaroff 2730 days ago
Your page is mysite.com. When a user signs in, you save some sort of session token to a non-HttpOnly cookie. Your backend ignores the cookie header, and you send the session token as a different header with every request. (Basically, the same way you'd authenticate if you were to use local storage).

Now assume your page loads evilsitem.com/tracker.js. They can send requests to your backend, and the cookie will be included, but since your backend ignores the cookie header it doesn't matter. The malicious script, however, cannot access the cookie directly, since the script's origin is not the same.

That's why I say cookies used this way are strictly more secure than local storage: the fact that they're included with every request is irrelevant, and they're protected from direct access by third party scripts. Local storage is not. Even if you use JWT for auth, you should still store it in a cookie.

link
metafunctor 2730 days ago
You are misunderstanding how the same-origin policy applies to scripts. If a page on mysite.com loads evilsite.com/tracker.js, then tracker.js runs with the same "origin" as the rest of the page that loaded it. The script has all the same access, including document.cookie, as a scripts loaded from mysite.com. Try it.

The same-origin policy only limits access between windows and frames. All scripts loaded on a page will have the same "origin".

link