2

ASP.NET will soon begin reflecting Google's decision to default cookies to SameSite="strict" in a defense against CSRF attacks:

https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/

This means that if I own foo.com, any logged-in users who are directed to foo.com from off-site will consume the content as if they are not logged in, as the browser will refuse to send the forms authentication headers with the request by default.

This is a poor user experience, and I'm tempted to simply specify SameSite="Lax" to ensure that users are not surprised by this behavior.

Is there any way to have my cake and eat it too, in this scenario?

Improve this question
4
  • Help me understand, why would there be a problem specifying SameSite="lax", when that's exactly what you want? Just because the default is changing, it isn't necessarily forcing a "strict" state. (Did I misunderstand your question?)
    – s h a a n
    Oct 27, 2019 at 17:19
  • 3
    From the link it seems that google is changing the default to lax, not strict. A default strict seems like it would break quite a bit so I'm not sure that's going to happen.
    – tim
    Oct 27, 2019 at 17:29
  • 1
    What do you mean by "forms authentication headers"?
    – curiousguy
    Oct 28, 2019 at 2:51
  • @tim Strict is anti UI and to me just inane. It means that landing on a page would have a effect and then doing ^L <enter> (page reload from URL) another. And then I don't know what ^R would do (the semantic diff between ^L <enter> and ^R is interesting).
    – curiousguy
    Oct 28, 2019 at 2:53

1 Answer 1

Reset to default
2

Short answer: No, there's no way to have the benefit of Strict SameSite without the drawbacks of Strict SameSite. However, you can get most of the benefits (and fewer drawbacks) by using Lax SameSite.

I think you quite badly misread that article you linked. Google is not, and has no plans to, change the default SameSite behavior to Strict. All they are doing is changing the default to "Lax" and adding "None" as a new option to override this default. ASP.NET is making no changes except adding the None to the enum values.

The concern is that, if you send SameSite=None to a browser that doesn't yet know about this value, it will interpret it as SameSite=Strict because that's what the standard says to do when the value isn't recognized. Therefore, IF and ONLY IF you DON'T want to use SameSite at all, you will need to do user-agent sniffing to determine "this browser still defaults to no SameSite and will freak if I say SameSite=None" vs. "this browser defaults to lax SameSite and I need to tell it to not do that".

If you expect top-level navigation from other sites to yours, but do not expect to need cross-site authenticated requests other than top-level GET navigation, then you should already be setting SameSite=Lax, and this change (neither Google's change nor ASP.NET's change) has no impact on you.

If you are already using Lax SameSite, you literally don't need to do anything at all (I guess you could save a few bytes by sniffing new Chrome builds and not sending the now-redundant header, but it's probably not worth the effort).

If you actually want to use Strict SameSite, do it exactly the way you would today; nothing has changed there either.

As a final word of advice, bear in mind that there are still a lot of people using outdated browsers that don't support SameSite at all. It's potentially valuable as a defense-in-depth measure against CSRF, the same way CSP is a defense-in-depth against XSS, but you still need some other anti-CSRF mechanism for anybody on browsers that don't support SameSite, unless you block all such browsers from signing in at all.

Improve this answer
5
  • Even if SameSite is supported, you'd better check whether SameSite for the browser means "same as your site" (controlled by you), according to your DNS naming hierarchy. Beware of subdomains that are delegated to someone else.
    – curiousguy
    Oct 28, 2019 at 2:51
  • You should indeed. Cookies confusingly allow sharing with subdomains and parents, up to the mysterious notion of "registered domain". It's a complicated story. And ppl can disagree about whether sharing would be allowed, and over what SameSite would do. Cookies were never aligned with JS.
    – curiousguy
    Oct 28, 2019 at 5:42
  • Replacing a previous comment that (incorrectly) claimed that "sites" as in SameSite were the same as "Origins" as in Same Origin Policy. They very much are not(different sites are always different origins; the reverse is not true). Sites are based only on domain (not port or protocol) and all domains including and under the "effective TLD plus one" (e.g. "example.com" or "example.co.uk"; what you might think of as the "primary" domain of the site) are considered the same site as well.
    – CBHacking
    Feb 11 at 23:55
  • "under the "effective TLD plus one" ... what you might think of as the "primary" domain of the site" Which means SameSite depends on the (subjective) definition of TLD/primary domain.
    – curiousguy
    Feb 28 at 22:56
  • 1
    @curiousguy It's rigorously (though not immutably) defined by the public suffix list; I certainly wouldn't call it "subjective" (what would that even mean for software?). The mutability, which isn't even entirely in the developer's control, does definitely pose a risk, though. I'm amused that ICANN literally uses tumblr.com as its example of a domain which should be considered a public suffix, but Tumblr isn't actually on the PSL.
    – CBHacking
    Mar 1 at 8:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .