Changes in SameSite Cookie in ASP.NET/Core and How it Impacts the Browser (Specifically Chrome)

I
This past week, we have seen few Cases where OpenIdConnect authentication operations (e.g. login, logout and other features that send POST requests from an external site to the site requesting the operation) were failing in ASP.NET/Core pages (mostly using iframes posting into 3rd party payment authorization gateways). In some Cases, users were logged out after sending the cross-site post requests. Issue was reproducing mostly with the Chrome browsers (version 79 or higher) with Windows Update KB4530689 applied.



The reason is an update in the standard and it's implementation in the latest version of Chrome.



Background:

SameSite is a 2016 extension to HTTP cookies designed to provide some protection against cross-site request forgery (CSRF) attacks. It had two values: Lax and Strict, and optionally, you could just opt out without setting anything at all. Most of the OpenIdConnect implementations were opting-out of SameSite, by not setting the property at all, to ensure these cookies will be sent during their specialized request flows.



New Changes:

As of Chrome 79, the SameSite cookie now have three values: Lax (default),Strict and None. This breaks OpenIdConnect authentications and potentially other features your web site may rely on, these features will now have to use cookies whose SameSite property is set to a value of “None”.



The upcoming Chrome 80 will:

  • Change default for all cookies to SameSite=”Lax” for those that don’t specify otherwise.
  • Will only allow cookies with SameSite=”None” to be used when the “Secure” attribute is also used.



The Workaround:

The workaround is easy and it will fix issues with Chrome 79 and will future-proof Chrome 80+. So far, this is the configuration that is doing the trick, with the Forms Authentication is being the optional if your are not using it.



<system.web>

<httpCookies ... requireSSL="true" sameSite="None" />

<authentication>

<forms ... requireSSL="true" cookieSameSite="None" />

</authentication>

<sessionState ... cookieSameSite="None" />

</system.web>



Going forward, it would be ideal for app developers to configure their desired cookie policies from code, since the above will blanket all of them if they aren’t configured in code. You can read more details here and here.

Continue reading...
 
Top Bottom