Hacker News Reader

Comment by momothereal | Hacker News Reader

I read through this piece and the web.dev one, and I'm still confused between SameSite=Lax and Strict. Two-part question:

If I want a cookie to be only sent in requests from a page on https://mywebsite.com to https://mywebsite.com/internal/..., but not from any other origins, should I use Lax or Strict?

If I use HttpOnly cookies and Access-Control-Allow-Credentials=false on https://mywebsite.com/internal/..., does that make SameSite irrelevant? Would there be a security risk even if SameSite=None? Is the only security risk related to <img>?

View on HN

> If I want a cookie to be only sent in requests from a page on https://mywebsite.com to https://mywebsite.com/internal/..., but not from any other origins, should I use Lax or Strict?

Neither setting will do what you want since the flag acts on Sites and not Origins. That is, even in SameSite=Strict mode, requests from subdomain.mywebsite.com will send cookies to mywebsite.com/internal, because they're the same Site.

> If I use HttpOnly cookies and Access-Control-Allow-Credentials=false on https://mywebsite.com/internal/..., does that make SameSite irrelevant? Would there be a security risk even if SameSite=None? Is the only security risk related to <img>?

HttpOnly is irrelevant for same-/cross- site/origin discussions - it just means that javascript can't read your cookie. Similarly CORS can only weaken the same origin policy - best to not send it at all. If you want to protect yourself against CSRF attacks on /internal then your best bet is still using standard protections like a double submit cookie or checking the origin/referrer headers. OWASP has a great cheat sheet on it:

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

Indeed. With https there is no good reason to not have a hard dependency on the origin/referrer header to enforce same-site restrictions.

Even with https, people can have privacy extensions that mess with referrers. I wouldn't consider referer 100% reliable and origin header isn't always sent for all request types.

Blocking same-site referer beyond stripping the path is something where I'd draw the line to protect the user against CSRF attacks. Do you have any evidence for a modern browser sending a harmful referer or allowing sending of one?

Firefox can be configured[1] to never send the header or always send the target URL as the header.

[1]: https://wiki.mozilla.org/Security/Referrer

Interesting. Especially the latter, considering that even the RFC [0] mentions it's usage for CSRF protection.

This seems to be about as harsh as reasonable without breaking CSRF protection:

  network.http.sendRefererHeader=1
  network.http.referer.trimmingPolicy=2
  network.http.referer.XOriginPolicy=2

[0]: https://tools.ietf.org/html/rfc7231#section-5.5.2

Sure, but there is a reason why everyone uses tokens to fix csrf and not referrer.

> If I want a cookie to be only sent in requests from a page on https://mywebsite.com to https://mywebsite.com/internal/..., but not from any other origins, should I use Lax or Strict?

Strict. If you use lax the cookies would be sent when clicking on a link cross origin.

Most people however do want cookies to be sent on cross origin link navigation.

[Edit: someone else pointed out that you would still get cookies from requests sent from subdomains, and indeed that is what the article is about. For lots of people that is probably not a big deal]

If samesite=none, (and you didnt implement csrf tokens) you could still send cookies from other sites via forms. So you can pull off old style csrf (like how you would exploit a csrf in the 90s before ajax was even a thing).

Also i think (but not 100% sure) that cookies would still be sent for ajax requests not requiring a preflight or for script inclusions.

Reply on news.ycombinator.com