Hacker News Reader

Comment by vbezhenar | Hacker News Reader

You can specify Path attribute for cookie and it will only be sent to URls with this prefix. I'm not completely sure, but I think that it should solve those security flaws.

View on HN

It would not. It would stop the cookie from being sent to things outside of the path specified, but the Same Origin Policy is about, among other things, gaining read-access to the responses of fetch/XMLHttpRequest/AJAX requests.

If there is a cookie set for the path '/secret' and I can host content at '/attacker', then some of my JavaScript under /attacker could do a fetch request to /secret/something. This fetch request would carry the cookie for /secret, and the response would be readable by my JavaScript (due to Same Origin Policy). I could read the response, extract sensitive content, or even extract CSRF tokens to allow me to do state-changing CSRF-protected things under /secret

What about setting Cookie with Path and SameSite=LAX? I would expect it to prevent sending cookies in that request, although I did not test it.

I tested with SameSite being Lax and Strict. Neither block the attack in Chrome. My reading of the SameSite spec indicates that it doesn't take cookie path into account.

If you own example.com and want to have cookies accessible in the root (e.g. example.com/login.html) then you can't prevent example.com/users/~evildoer from accessing them.

No, but you could redirect your root requests to example.com/home and serve from there with relevant cookies restricted to the /home path.

Don't we have equivalent problems with evildoer.example.com trying to get and set example.com cookies? Hence why Google and Github and other major sites use separate domain for user hosted content vs first party content.

Cookies are a terrible security model in general.

Reply on news.ycombinator.com