Dnn.platform: Cookie "<dnncookie>" will soon be rejected

[Navilois]

Description of bug

The latest versions of Firefox and Chrome both issue the following warning @dev tools console:

• 'Some cookies are misusing the recommended "sameSite" attribute [12]'
  -- 'Cookie “dnn_IsMobile” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To learn more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Cookies'

Other cookies affected are:

• .ASPXANONYMOUS
• language
• __RequestVerificationToken
• __gcl_au

Steps to reproduce

List the precise steps to reproduce the bug:

1. Open dev tools -> console in Firefox or Chrome
2. Go to www.sierzega.com
3. See warnings in the console

Current behavior

See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite#Fixing_common_warnings

Additional context

Honestly, I didn't dig in very deep - seems to be a policy change coming. That said, when you go on the linked mozilla.org page with the console open, even the Google analytics cookies issue the same warning.

Affected version

• [ ] 10.00.00 alpha build
• [x] 09.06.01 latest supported release

Affected browser

• [x] Chrome
• [x] Firefox
• [ ] Safari
• [ ] Internet Explorer 11
• [ ] Microsoft Edge (Classic)
• [ ] Microsoft Edge Chromium

[mitchelsellers]

I will look at getting something in for this.

We have a minimum version requirement of .NET Framework 4.7.2 already so we have support from Microsoft in this based on this guidance (https://docs.microsoft.com/en-us/aspnet/samesite/system-web-samesite)

The question is what should the defaults be? I'm inclined to say Lax by default?

[bdukes]

The issue isn't the SameSite attribute (it being set to None is fine), it's that the Secure attribute isn't set (SameSite is invalid unless Secure is set). Should we always be setting the Secure if the connection is secure?

[mitchelsellers]

Well, the question is, is None really the right value? Maybe it is, a simple fix of Secure if HTTPS is being used might be a good solution.

However, I'd argue that None is NOT the right solution for this, as the dnn_ismobile cookie isn't really needed elsewhere.

[bdukes]

Sorry, you're right that None doesn't really make sense in this scenario. That said, looking at the example site, the warning doesn't really appear to be valid, because SameSite _isn't_ being set on those cookies. So, explicitly setting the cookie to Lax would be good, but I think the Secure flag being missing is probably what triggered the warning in the first place.

[mitchelsellers]

Looking at Chrome's behavior, it appears to think that not setting == None, which per the RFC is not the case. Not set is supposed to be Lax, with the option of explicit None with the secure flag.

I think at a minimum we should discuss this overall.

[thabaum]

I have been recently reading up on this as I did notice these warnings and how to handle things. Using Lax or None with Secure seem to be the two options I recall for resolving this issue.

Should there be a way in the platform for an administrator host to set this as desired?

Since Microsoft is almost the same as a Chrome browser here is some more food for thought.

https://www.chromium.org/updates/same-site/test-debug

Lax seems to be what you would think would be choice as you don't really want cookies from other sites on your site.

And if you do... make sure they are secured cookies.

https://www.chromium.org/updates/same-site/test-debug

I found the problematic cookie(s). Now what?
If the cookie is on a domain you control: You will need to update that cookie by setting SameSite=None; Secure on it. See resources here and here.

If the cookie is on a third-party domain: You should reach out to the owner of the domain setting that cookie and ask them to update it with SameSite=None; Secure.

Still stuck? Post a question with the “samesite” tag on Stack Overflow, or file a Chrome bug using this template.

For site groups this can be something that should be considered into discussions as SameSite=None Secure maybe choice?

[stephen-lim]

We've had some production experience with this. On DNN 9.4+ or targeting .NET Framework 4.7.2, you can simply edit the web.config to change the default cookie behavior to set the cookieSameSite="None", sameSite="None" and requireSSL="true" in these places for it to work correctly. Furthermore, the site must be on HTTPS otherwise the samesite=None and Secure flags will not be observed by browsers. Implementing these changes seems to be relatively stable.

<system.web>
    ...
    <sessionState cookieSameSite="None" />
    ...
    <authentication mode="Forms">
        <forms cookieSameSite="None" requireSSL="true" />
    </authentication>
    ...
    <httpCookies sameSite="None" requireSSL="true" />
    ...
</system.web>

There was a reported case that a few DNN users could not login after setting the samesite=None and secure flag. We suspect the problem might be due to the user's computer going through a proxy that is not preserving the cookie flags correctly?

[gnossosp]

.ASPXANONYMOUS still reporting error with stephen-lims edits.

Change the value in anonymousIdentification from cookieRequireSSL="false" to "true"

[mitchelsellers]

Given that we cannot deploy with this as SSL by default without breaking installation options, I think we should revert this to a documentation bit, rather than a code change at this time.

[mitchelsellers]

Based on the commentary above, I don't believe we can support an SSL only deployment at this time. Closing this issue for now