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:

DuendeArchive/IdentityServer4@aa57833

[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.