Aspnetcore: SameSite=None without HTTPS should log warning

[brockallen]

Describe the bug

When using SameSite=none, the Secure flag must also be set, otherwise the browser will ignore the cookie (tested in Chrome 80).

ASP.NET Core can issue a SameSite=none cookie without the Secure flag. For the cookie authentication handler configured with SameSite=none and when running over HTTP (not HTTPS) then the cookie authentication handler will emit a SameSite=none but no Secure flag (most likely because the SecurePolicy is SameAsRequest).

I'd imagine that the fix should be that when SameSite=none is configured but the request is not HTTPS, then SameSite flag should be omitted from the cookie.

To Reproduce

Use Chrome 80. Configure cookie authentication with SameSite=none and the default SecurePolicy. Try to issue the cookie (e.g. from a login page) and Chrome will issue a warning and ignore the cookie, and from the user's perspective they're not logged in. If you run over HTTPS then it works fine.

Tested in ASP.NET Core 3.1.

[brianbarnett316]

We are now getting this issue after the recent Chrome 80 update rollout. Switching to HTTPS does work, but in our dev/test environments we typically run with HTTP so this has become an issue for us.

[blowdart]

Part of Chrome's "strategy" was to make this break, to force HTTPS everywhere, so we're mirroring that. Given that, since 1.1, we supported self signed certs for dev hosting and it's a checkbox honestly it seems, to me at least, that having the break, mirroring what would happen in production if you tried this is the right way to go.

[brianbarnett316]

Those of us that have encountered the issue have switched to HTTPS in dev/test and that did fix our issue. I wasn't sure if the intent was to 'break' HTTP but it seems like that was the intent. And you are correct, we need to get everyone on HTTPS anyway :-).

[brockallen]

Part of Chrome's "strategy" was to make this break, to force HTTPS everywhere, so we're mirroring that. Given that, since 1.1, we supported self signed certs for dev hosting and it's a checkbox honestly it seems, to me at least, that having the break, mirroring what would happen in production if you tried this is the right way to go.

Would you consider writing a warning log entry to inform the dev of what's going on then? Even from the chrome log (which only some people are even noticing), a lot don't know what's happening.

[blowdart]

A log entry would work. @Tratcher is this possible, or does DI lock it away in a place where we can't resolve logs?

[brockallen]

This is what we've added to our IdentityServer host to make it work:

https://github.com/IdentityServer/IdentityServer4/commit/aa57833f2e048eb2f6be279260fccdd27c5a7ea9

[Tratcher]

Should be doable. Where is an interesting question. Cookie Auth, Response.Cookies.Add, CookiePolicy?

[Tratcher]

I'd imagine that the fix should be that when SameSite=none is configured but the request is not HTTPS, then SameSite flag should be omitted from the cookie.

No, dropping SameSite=None still breaks the scenarios that need it. Our options are to log or throw.

[brockallen]

No, dropping SameSite=None still breaks the scenarios that need it. Our options are to log or throw.

Can you elaborate?

[Tratcher]

Take OIDC's nonce cookie for example. It needs to be set to SameSite=None or the flow doesn't work. Excluding SameSite=None for HTTP requests doesn't make the flow succeed, it just makes it fail differently. This isn't something the server can work around so the question becomes how do we communicate the failure?

[brockallen]

Ok I see. But a local cookie is more common than a cookie intended for cross-site, no doubt?

Anyway, yes, a log entry will help at least.

[Tratcher]

But a local cookie is more common than a cookie intended for cross-site, no doubt?

I don't follow. This applies to any cookie that requires SameSite=None to work. If you're not using SameSite then it's not relevant.

[brockallen]

This applies to any cookie that requires SameSite=None to work. If you're not using SameSite then it's not relevant.

Yea, ok. I guess I was more thinking of a scenario where you have a main auth cookie that was set with SameSite=none (and for whatever reason you have set SameSite), vs. a correlation cookie which was more specific to that scenario.

[Tratcher]

Which makes me ask why your main auth cookie is set to None? You need None for some scenario to work, and if you drop it that scenario breaks, right?

[brockallen]

Which makes me ask why your main auth cookie is set to None?

I've seen things man... scary things where people do iframe mashups and other nonsense. But specifically for IdentityServer it's needed for JS clients doing authorization in iframes for silent token renewal.

[Tratcher]

Makes sense. And those scenarios break if you drop the SameSite property so that's not really an option.

[anurse]

Triage: We think the best approach here is to log a warning if a cookie has SameSite=None and no Secure attribute.

[BenShapira]

Hey guys, would love some help.
Storing a cookie with the Secure and SameSite.None flags still cause problems on some computers.
Meaning - same chrome version will sometimes treat the cookie as Same-site connections only instead of Any kind of connections as it should.
Elaborated with code samples here -
https://stackoverflow.com/questions/60832416/storing-cookie-with-samesite-option-as-any-kind-of-connection

If anyone have some insights that would be great, thanks!

[anurse]

@BenShapira please file a new issue for that. It seems to be a different issue.

[Tratcher]

Triage: We think the best approach here is to log a warning if a cookie has SameSite=None and no Secure attribute.

Hmm, where do we actually do that? Cookies are a very distributed thing in the framework. CookieAuth? CookieBuilder? Response.Cookies.Append? CookiePolicy?