6 ms·

The Great SameSite Confusion

87 points by arkadiyt 6y ago

momothereal 6y ago
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 https://mywebsite.com to https://mywebsite.com/internal/ 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/ 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>?
- arkadiyt 6y ago
  > If I want a cookie to be only sent in requests from a page on https://mywebsite.com https://mywebsite.com to https://mywebsite.com/internal/ 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/ 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_Request_Forgery_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
  - namibj 6y ago
    Indeed. With https there is no good reason to not have a hard dependency on the origin/referrer header to enforce same-site restrictions.
    - bawolff 6y ago
      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.
      - namibj 6y ago
        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?
        nulbyte 6y ago
        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 https://wiki.mozilla.org/Security/Referrer
        namibj 6y ago
        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 https://tools.ietf.org/html/rfc7231#section-5.5.2
        bawolff 6y ago
        Sure, but there is a reason why everyone uses tokens to fix csrf and not referrer.
- bawolff 6y ago
  > If I want a cookie to be only sent in requests from a page on https://mywebsite.com https://mywebsite.com to https://mywebsite.com/internal/ 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 I use HttpOnly cookies and Access-Control-Allow-Credentials=false on https://mywebsite.com/internal/ 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>? 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.
thitcanh 6y ago
My eyes are bleeding, can you lower the contrast further on the dark theme? #777 text on #666 background would be great.
- jub0bs 6y ago
  Sorry! I like the dark theme the way it is, I'm afraid. Have you tried the light one?
  - Talanes 6y ago
    Color preferences are strange. Their is a slight fuzziness to the color contrast on dark mode, but for me it just reads more like a natural grain, compared to the light modes strict contrast being more obviously digital. Which is to say, I like the dark theme the way it is too. Rock on.
  - gegtik 6y ago
    okay but his eyes are bleeding don't you think you have a moral responsibility for his health
    - thitcanh 6y ago
      I don’t think I’ve ever laughed so much on HN. May the doge be with you
  - chrismorgan 6y ago
    While we’re on the topic of the styling: you should basically never adjust the letter-spacing on body type. The font designers made the font the way they did on purpose; with the notable exception of all-caps text which does call for increasing letter-spacing, you will make it worse in almost all situations (>99.9%) for almost all body fonts (>99%). I find your chosen letter-spacing of 0.06em decidedly uncomfortable (it’d be too much even for all-caps loosening, that normally calls for something like 0.04em).
- deleted 6y ago
  [deleted]
bawolff 6y ago
Honestly i feel like this is making a big deal out of not that much. Yes terminology is important and its important to realize that there are differences, but honestly it doesnt seem that important a distinction for broad overview articles to make. Otoh being able to set cookies cross origin within same site (except those starting with __host-) seems like a much poorer understood thing and one more likely to lead to vulns.
- jub0bs 6y ago
  You'd be surprised by how many organizations completely disregard the security of their non-essential subdomains. The point of my post is that one subdomain takeover (or some XSS or some HTML injection) on a different subdomain of the same site is enough to bypass the protection that SameSite provides to the origin of interest. And I feel that is something worth understanding well.
- johnmaguire2013 6y ago
  IMO, the points are valid but the post is extremely long-winded.
  - jub0bs 6y ago
    Apologies about that. There is a TL;DR and an estimated reading time at the top, though. You can also skip the addendum.
    - Noumenon72 6y ago
      The tl;dr didn't help me because "the concept of site is difficult to apprehend" doesn't summarize anything. I was looking for a takeaway like "tl;dr -- 'Site' includes other subdomains of your site as cross-domain, while 'Origin' doesn't. Use SameSite=strict for the most safety". If I got that wrong, it's because I didn't finish reading the post. I quit around "what do we mean by 'origin'?" because it was clear there was a lot more background to go and not clear I would learn anything practical.
      - 6y ago
deleted 6y ago
[deleted]
timdaub 6y ago
When having a local frontend and a backend online, sameSite cookies can become a debugging hurdle. When I encounteted the problem, I wrote this practical post to resolve the problem via browser configurations: https://timdaub.github.io/2020/12/03/samesite/ https://timdaub.github.io/2020/12/03/samesite/
- qwtel 6y ago
  Something I do sometimes is launch Chrome with --disable-web-security --user-data-dir=tmp This disables almost everything that's annoying during development. Of course you have to remember not to use this browser for browsing during and after development, which is easier said than done.
jub0bs 6y ago
Hey! I don't usually hang out on Hacker News. Thanks for sharing the post here :)
politelemon 6y ago
That helped me understand how to roughly tell, given two URLs, they can be cross-site or same-site. The addition of Public Suffix in this mix slightly confuses things, but I can see why it's necessary for services that give out subdomains. This is actually my first time hearing of it (or to be precise, knowing of it as a concept), and yet it seems to have been around since 2007!
- colordrops 6y ago
  What I don't understand is why there needs to be a public shared list of suffixes. Couldn't a cookie attribute define the suffix itself?
  - jub0bs 6y ago
    You'll find an answer in https://web.dev/same-site-same-origin/ https://web.dev/same-site-same-origin/: [...] for domains such as .co.jp or .github.io, just using the TLD of .jp or .io is not granular enough to identify the "site". And there is no way to algorithmically determine the level of registrable domains for a particular TLD. That's why a list of "effective TLDs"(eTLDs) was created. If foo.github.io and bar.github.io were considered same-site, one subdomain could mount cross-origin same-site attacks against the other. I'm guessing that's why companies that have multiple tenants on the same domain (github.io, in this case) ask that the domain be added to the public-suffix list: for isolation purposes. Other examples of public suffixes are azurewebsites.net (Azure App Services) and repl.co (Repl.it).
  - Thorrez 6y ago
    We don't want people setting cookies on com . You might say "oh, just don't set cookies on single-label hosts", well you still have problems with co.uk . There needs to be a list of things like co.uk that you can't set cookies on.
    - the8472 6y ago
      Since this is a domain name concern, couldn't this be solved with some DNS record indicating that?
weinzierl 6y ago
This is a good article. What I only understood after reading it a second time is this: The quotes from other blogs and articles using the term "cross-origin" are not wrong, just imprecise. They use cross-origin when they mean cross-origin and cross-site. I think the term cross-origin could - and should - be avoided altogether. In the end of the day a request is either * same-origin (which implies same-site) * same-site (cross-origin or not, doesn't matter) * cross-site (implying cross-origin, again doesn't matter) That's all there is to it, and sufficiently describes the situation. cross-origin on the other hand is rather ambiguous when used alone.
- jub0bs 6y ago
  Thanks. Yes, that's a good point. The difficulty for me in writing the post was not to spoil how origin and site intersect too early. ¯\_(ツ)_/¯
silviogutierrez 6y ago
Curious in the Strict example, what happens if you arrive from another Site (so no cookie is readable) and you do something that sets a cookie? Have you split the universes? Is there now an alternate reality of some kind? To read that second cookie, do you always have to arrive from the first site?

87 points by arkadiyt 6y ago

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 https://mywebsite.com to https://mywebsite.com/internal/ 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/ 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>?

arkadiyt 6y ago
> If I want a cookie to be only sent in requests from a page on https://mywebsite.com https://mywebsite.com to https://mywebsite.com/internal/ 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/ 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_Request_Forgery_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
- namibj 6y ago
  Indeed. With https there is no good reason to not have a hard dependency on the origin/referrer header to enforce same-site restrictions.
  - bawolff 6y ago
    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.
    - namibj 6y ago
      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?
      - nulbyte 6y ago
        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 https://wiki.mozilla.org/Security/Referrer
        namibj 6y ago
        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 https://tools.ietf.org/html/rfc7231#section-5.5.2
        bawolff 6y ago
        Sure, but there is a reason why everyone uses tokens to fix csrf and not referrer.
bawolff 6y ago
> If I want a cookie to be only sent in requests from a page on https://mywebsite.com https://mywebsite.com to https://mywebsite.com/internal/ 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 I use HttpOnly cookies and Access-Control-Allow-Credentials=false on https://mywebsite.com/internal/ 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>? 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.

thitcanh 6y ago

My eyes are bleeding, can you lower the contrast further on the dark theme? #777 text on #666 background would be great.

jub0bs 6y ago
Sorry! I like the dark theme the way it is, I'm afraid. Have you tried the light one?
- Talanes 6y ago
  Color preferences are strange. Their is a slight fuzziness to the color contrast on dark mode, but for me it just reads more like a natural grain, compared to the light modes strict contrast being more obviously digital. Which is to say, I like the dark theme the way it is too. Rock on.
- gegtik 6y ago
  okay but his eyes are bleeding don't you think you have a moral responsibility for his health
  - thitcanh 6y ago
    I don’t think I’ve ever laughed so much on HN. May the doge be with you
- chrismorgan 6y ago
  While we’re on the topic of the styling: you should basically never adjust the letter-spacing on body type. The font designers made the font the way they did on purpose; with the notable exception of all-caps text which does call for increasing letter-spacing, you will make it worse in almost all situations (>99.9%) for almost all body fonts (>99%). I find your chosen letter-spacing of 0.06em decidedly uncomfortable (it’d be too much even for all-caps loosening, that normally calls for something like 0.04em).
deleted 6y ago
[deleted]

bawolff 6y ago

Honestly i feel like this is making a big deal out of not that much. Yes terminology is important and its important to realize that there are differences, but honestly it doesnt seem that important a distinction for broad overview articles to make. Otoh being able to set cookies cross origin within same site (except those starting with __host-) seems like a much poorer understood thing and one more likely to lead to vulns.

jub0bs 6y ago
You'd be surprised by how many organizations completely disregard the security of their non-essential subdomains. The point of my post is that one subdomain takeover (or some XSS or some HTML injection) on a different subdomain of the same site is enough to bypass the protection that SameSite provides to the origin of interest. And I feel that is something worth understanding well.
johnmaguire2013 6y ago
IMO, the points are valid but the post is extremely long-winded.
- jub0bs 6y ago
  Apologies about that. There is a TL;DR and an estimated reading time at the top, though. You can also skip the addendum.
  - Noumenon72 6y ago
    The tl;dr didn't help me because "the concept of site is difficult to apprehend" doesn't summarize anything. I was looking for a takeaway like "tl;dr -- 'Site' includes other subdomains of your site as cross-domain, while 'Origin' doesn't. Use SameSite=strict for the most safety". If I got that wrong, it's because I didn't finish reading the post. I quit around "what do we mean by 'origin'?" because it was clear there was a lot more background to go and not clear I would learn anything practical.
    - 6y ago

deleted 6y ago

[deleted]

timdaub 6y ago

When having a local frontend and a backend online, sameSite cookies can become a debugging hurdle. When I encounteted the problem, I wrote this practical post to resolve the problem via browser configurations: https://timdaub.github.io/2020/12/03/samesite/ https://timdaub.github.io/2020/12/03/samesite/

qwtel 6y ago
Something I do sometimes is launch Chrome with --disable-web-security --user-data-dir=tmp This disables almost everything that's annoying during development. Of course you have to remember not to use this browser for browsing during and after development, which is easier said than done.

jub0bs 6y ago

Hey! I don't usually hang out on Hacker News. Thanks for sharing the post here :)

politelemon 6y ago

That helped me understand how to roughly tell, given two URLs, they can be cross-site or same-site. The addition of Public Suffix in this mix slightly confuses things, but I can see why it's necessary for services that give out subdomains. This is actually my first time hearing of it (or to be precise, knowing of it as a concept), and yet it seems to have been around since 2007!

colordrops 6y ago
What I don't understand is why there needs to be a public shared list of suffixes. Couldn't a cookie attribute define the suffix itself?
- jub0bs 6y ago
  You'll find an answer in https://web.dev/same-site-same-origin/ https://web.dev/same-site-same-origin/: [...] for domains such as .co.jp or .github.io, just using the TLD of .jp or .io is not granular enough to identify the "site". And there is no way to algorithmically determine the level of registrable domains for a particular TLD. That's why a list of "effective TLDs"(eTLDs) was created. If foo.github.io and bar.github.io were considered same-site, one subdomain could mount cross-origin same-site attacks against the other. I'm guessing that's why companies that have multiple tenants on the same domain (github.io, in this case) ask that the domain be added to the public-suffix list: for isolation purposes. Other examples of public suffixes are azurewebsites.net (Azure App Services) and repl.co (Repl.it).
- Thorrez 6y ago
  We don't want people setting cookies on com . You might say "oh, just don't set cookies on single-label hosts", well you still have problems with co.uk . There needs to be a list of things like co.uk that you can't set cookies on.
  - the8472 6y ago
    Since this is a domain name concern, couldn't this be solved with some DNS record indicating that?

weinzierl 6y ago

This is a good article. What I only understood after reading it a second time is this: The quotes from other blogs and articles using the term "cross-origin" are not wrong, just imprecise. They use cross-origin when they mean cross-origin and cross-site. I think the term cross-origin could - and should - be avoided altogether. In the end of the day a request is either * same-origin (which implies same-site) * same-site (cross-origin or not, doesn't matter) * cross-site (implying cross-origin, again doesn't matter) That's all there is to it, and sufficiently describes the situation. cross-origin on the other hand is rather ambiguous when used alone.

jub0bs 6y ago
Thanks. Yes, that's a good point. The difficulty for me in writing the post was not to spoil how origin and site intersect too early. ¯\_(ツ)_/¯

silviogutierrez 6y ago

Curious in the Strict example, what happens if you arrive from another Site (so no cookie is readable) and you do something that sets a cookie? Have you split the universes? Is there now an alternate reality of some kind? To read that second cookie, do you always have to arrive from the first site?