We’ve updated Sitefinity to make sure the full set of built-in capabilities is completely in tune with the imminent changes to how the most popular web browsers out there handle cross-domain cookies. Read on to learn what has changed, how to get and apply the latest patch for your Sitefinity version, and everything you need to do to ensure continuous operations.
In this post, we’re looking at what the new requirements about to be introduced in Chrome 80 are, and the specific Sitefinity setup and configurations that make these latest patches a must.
The short of it, if you’re using OpenID Connect authentication in a multiple-domain scenario where one of them is an identity provider (as in SSO), you’ll need the patch regardless of the version you’re running.
Chrome 80, SameSite Cookie Changes, Sitefinity Cookies and What’s Updated
Word got out a few months back and you’re likely well aware of a potentially disruptive upcoming update that will first hit Chrome 80, with other browsers certain to follow suit too. The changes to the SameSite attribute are aimed at an even tighter level of security against cross-site request forgery (CSRF).
Sitefinity is well-equipped in terms of cookie protection courtesy of the Web Security Module introduced in v11 and enhanced with CSRF protection in v12.1. Yet, the upcoming update has a number of potential implications for authentication, your development setup and workflow, and any third-party integrations you may be running that involve cross-domain cookies. Their scope varies according to the Sitefinity version you’re on.
To begin with, patches are available for versions going all the way back to 10.2. While we encourage everyone to carefully review the table at the end of this blog and upgrade, it depends on your specific setup whether the patch is essential
to operations or is just a sensible choice to keep your system stable and future-proofed. Either way, we strongly recommend applying the patches.
Speaking of specific setups, some Sitefinity versions are ... well ... more equal than others. So, if you’re on 12.1 or above, and have enabled the WebSecurity module, you’re in a pretty good shape—except if you’re using an external OpenID Connect authentication provider.
For older versions than 12.1, as a minimum you need to review, deprecate and replace any cookies you may be using cross-site for integration with external services.
Before we get into the details, let’s look back at what the commotion is all about.
To briefly put everything in context, a new secure-by-default model for cookies was announced last year and is about to start being enforced—albeit with some mitigating exemptions over an unspecified grace period—in February. This is the time frame subscribed to and communicated by Google and Chrome, but other browser makers have also indicated they will be adopting the new model.
Over the last couple of months, you may have regularly noticed console warnings about cookies missing the SameSite attribute. Several versions of Chrome, going back to v76, provide a means to test your cookies against the new requirements. More details about how to test are available at the end of this blog.
The changes aim to bolster the protection of cookies from unauthorized and/or malicious access and revolve around the SameSite attribute, which specifies the intended use of a cookie in a strictly same-site context or across multiple domains. All that said, our immediate concern is cookies involved in authentication and that’s what we’re going to delve into in the next chapter.
One last note before we get there. Microsoft released a relevant update to the .Net Framework in December to accommodate the changes to SameSite cookie handling in Chrome. And now, we’ve done our part too by implementing the required changes to bring Sitefinity in line with the new standard and its requirements.
If you’re hosting Sitefinity in the cloud, you’ll be glad to know the .NET Framework SameSite patches are being added to Azure App Service.
Authentication and Cross-Domain Cookies, OpenID Connect Provider
The Sitefinity authentication model is based on OAuth2 and the OpenID Connect protocol. On top of the default options, you can enable authentication via external identity providers that also support the OpenID Connect protocol. For yet another extra layer of extensibility, there’s support, right out-of-the-box, for setting up a number of external providers such as social network accounts, Google, Microsoft and ADFS, among others, for Sitefinity authentication.
The latter are independent, third-party services and therefore completely out of the scope of this update. It’s the responsibility of the respective platform and these identity providers are presumed already (or imminently) compatible with the requirements of the secure-by-default cookie model.
Anyway, the patches we just released are recommended if you’re using OpenID Connect authentication in a multi-domain setup, where one of multiple domains is used as a single-sign-on identity provider for all the others.
To make sure the out-of-the-box functionality is fully intact, the provided patches modify the OpenIdConnect.nonce cookies to also carry the required SameSite=None and Secure attributes when intended for cross-site use, e.g. in the multi-site setup described above.
Now, having factored in the implications this change can potentially have on your workflow, we’ve added an extra configuration layer to let you exempt the OpenIDConnect.nonce cookie from the default behavior in scenarios specific to your Sitefinity operation.
Let’s say your dev environment isn’t SSL-secured or you develop locally (which is probably the most common scenario). The highest security option, which states that all requests require the OpenIdConnect.nonce cookie for authentication is not applicable for the lack of SSL.
You can therefore specify that remote requests require the OpenIdConnect.nonce authentication cookie, but requests to and from localhost don’t. You can even disable it altogether if you have a valid use case that doesn’t pose a significant security risk. You can find out more in a duly updated article of our documentation.
We believe these extra settings are the right thing to do to let you continue developing locally or under HTTP. But since they’re essentially exceptions with certain security implications, it made sense to give Sitefinity admins a tool to always keep an eye on them. The System Status widget was updated accordingly to always display insecure authentication provider warnings.
Cookie Protection and the Sitefinity WebSecurity Module
In your Sitefinity project, you may be using cookies cross-site with various external services and third-party integrations. Needless to say, these cookies should comply with the new requirements as well.
If you’re on Sitefinity version 12.1 and above and have enabled the Web Security Module and turned cookie protection on, you have the means to conveniently configure minimum cookie security policies project-wide, as well as set exceptions as needed. You’ll typically want cookies excluded from the security policies exactly when they’re intended for cross-site use to support shared functionality across multiple domains.
The great thing about using a recent Sitefinity version (12.1 and 12.2) is that the out-of-the-box cookie protection is fully compatible with the upcoming SameSite changes. Cookie protection has been developed and refined over several consecutive releases and has been thoroughly tested against the new requirements.
So, if your setup involves cross-site cookies and they have been working trouble-free so far with the default settings of the Web Security module, you can be sure they will continue to do so after the SameSite changes start being enforced.
The important thing to note here is that the Web Security module sets the SameSite value to LAX by default. If you have configured the module differently, be sure to carefully review and update the project-wide cookie protection and any custom exceptions, so that they meet the new requirements.
Now, that goes without saying for versions 10.2 through 12.0. If that’s what you’re running, you need to carefully review and update any cookies being used cross-site to make sure they comply with the secure-by-default model: SameSite=Lax
is the new default if no SameSite attribute is specified. The SameSite=None value requires a new "Secure" attribute.
Wrap-up
You may have already noticed the patches in your account under downloads. Before I leave you to it, just a quick word on how to test the current cookie behavior prior to applying a patch. Your Chrome version, assuming it’s fairly recent, allows you to test cookies against the new requirements. Turning on #same-site-by-default-cookies and #cookies-without-same-site-must-be-secure flags in the browser settings will replicate the expected behavior in Chrome 80.
I must note that Chrome has confirmed a grace period of sorts, during which the new standard will not be strictly enforced for cookies less than 2 minutes old. To be precise, cookies set less than 2 minutes ago without a SameSite attribute will still be allowed in top-level cross-site post requests. The unspecified grace period is a mitigating measure against potentially breaking POST based authentication flows, giving developer teams time to prepare and adjust.
Here’s a refresher on how to download patches and the upgrade procedure in general, if you need to get back on track. There’s a longer piece explaining SameSite cookies if you want the theory out of the way first.
When you’re ready to proceed, rest assured that Sitefinity support is ready to respond if you run into trouble patching your specific Sitefinity version. Click on the image below to expand the table.
Sitefinity versions prior to 10.2 don’t support Open ID Connect authentication out-of-the-box. If you’re running a Sitefinity version prior to 10.2 and have a custom implementation of an OpenID Connect authentication provider, we recommend you test your login flow extensively against the new requirements and update any cookies involved that may be affected. The same applies to projects using cookies cross-site for third-party integrations or external services. We're not releasing patches for those older versions.
We strongly recommend that you consider upgrading, as more recent Sitefinity versions offer multiple performance benefits and a higher level of security.
If you need a refresher on how to leverage the full power of Sitefinity, we welcome you to join our free courses designed to help developers get up to speed. Sign up here.
Anton Tenev
Anton Tenev was a Sitefinity Product Marketer.