News
Microsoft Warns SameSite Cookie Changes Could Break Some Apps
IT pros could face Web application issues as early as next month with the implementation of a coming SameSite Web change, which will affect how cookies are used across sites.
Specifically, some browser makers, principally Google and Microsoft, are starting to enforce a 2019 draft proposal by the Internet Engineering Task Force (IETF). This document, called "Incrementally Better Cookies," outlines a rudimentary approach to better securing cookie data across sites, which involves a change in how a Web site header attribute called "SameSite" works.
The idea is to somewhat address cross-site security issues, in which cookie data associated with a user can get used in attacks, typically by so-called "third parties."
Update 2/3: For a good walkthrough on what to expect with the SameSite changes, see this Jan. 3 blog post by Troy Hunt, a software security expert and Microsoft Most Valuable Professional.
Update 2/6: How the SameSite changes are affecting ASP.NET Web sites is explained in a series of IIS support blog posts, principally by Paul Cociuba, an engineer on the Microsoft ASP.NET team. The posts include an overview, a Lax default explanation and talk about session logic.
Coming SameSite Changes
The SameSite attribute can have "Strict," "Lax" or "None" values. Strict keeps cookie data within a site's domain. Lax permits cross-site cookie data sharing but avoids the unsafe HTTP POST method for third-party sharing. None is a new value introduced by Google. These nuances are somewhat described in this IETF document on cookies and HTTP state management.
Per the IETF's "Incrementally Better Cookies" document, the SameSite attribute will default to the "Lax" value for users if that property wasn't defined on a Web site's header. If the "None" value is specified for the SameSite attribute on a site, then a Secure attribute also needs to be specified, which causes the cookie data to use the more secure HTTPS protocol -- otherwise, a third-party shared cookie will get rejected.
Cookies are text strings used by Web sites ("first parties") to add a persistent state for browser users, such as remembering that a person has viewed a particular advertisement in a past site visit. However, third parties can use the cookie data for potentially malicious efforts, which is known as a "cross-site request forgery" attack.
According to a definition by the OWASP Foundation, "Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated." With a little trickery, an attacker can "force the user to perform state changing requests like transferring funds, changing their email address, and so forth," it explained.
The use of the Lax value with SameSite isn't an absolute protection against CSRF attacks, though. Attackers can still pop up new windows or exploit browser prerendering, the IETF explained in Section 5.3.7.1 of its cookies and state management document.
Google described the new SameSite change as a "Lax + POST mitigation," and indicated in a SameSite FAQ document that "this is purely a temporary solution and will be removed in the future."
Update 1/29: A Chromium developer clarified that it's just the POST method that's temporary and that the SameSite changes are "here to stay." Here's how it was explained:
What is temporary is the "+POST" part of the "Lax+POST" setting, which carves out a special exception for certain cookies and certain types of POST requests. It's described more fully here. We don't have a concrete timeline for deprecating "Lax+POST", but we have stated from the beginning that it is only a temporary workaround to mitigate the blocking of cookies on POST requests critical to login flows.
Since October, "a very modest amount of breakage" was reported with the SameSite changes, based on browser field trials, per this Jan. 21 Chromium forum post.
The IETF's "Incrementally Better Cookies" document doesn't perceive a cookie replacement to be on the immediate horizon, so that's why it proposed an incremental measure with the SameSite changes. Cookies are considered by the IETF to be a "primitive mechanism" for achieving state during sessions. They are "visible to anyone on the network" and have the additional drawback of being used for "pervasive monitoring."
Despite those limitations, and the limitations of the new SameSite behavior, IT pros could face issues as these new SameSite changes get rolled out.
SameSite Rollout Plans
Google's SameSite implementation for its Chrome browser will be coming up fairly soon. It's planning to launch Chrome version 80 as early as next month (February) with enforcement of the new settings, but they'll only be in effect with the "stable" browser release, according to the Chromium Project's "SameSite Updates" document. The SameSite change won't be coming to Chrome browsers on iOS, Google explained in its SameSite FAQ document.
Here's how Google explained the coming change in an Oct. 23 Chromium blog post:
With Chrome 80 in February, Chrome will treat cookies that have no declared SameSite value as SameSite=Lax cookies. Only cookies with the SameSite=None; Secure setting will be available for external access, provided they are being accessed from secure connections.
Microsoft took a similar course with its Microsoft Edge and Internet Explorer browsers. Support for the SameSite change has been in place with those browsers since the June 2018 Windows Update releases, the company explained in a blog post. The SameSite change in Edge will ship "at the same time or later than Google," Microsoft indicated in this document.
Google's Oct. 23 Chromium blog post suggested that Microsoft first started implementing the changes with the "Microsoft Edge 80" browser. It added that "Mozilla has affirmed their support of the new cookie classification model" in a future Firefox browser release.
Broken OpenID Apps
Microsoft early on warned that the SameSite changes could break sites and applications that rely on OpenID-based federation.
"We love the intent and spirit of this change, but we fairly quickly determined that this breaks a large number of our sites leveraging Azure Active Directory (AAD) and Microsoft Account (MSA) authentication using the contract as defined here," wrote Erik Anderson in a July 23 Chromium Forum post on the use of cookies with SameSite. "We suspect that other OpenID-based federated auth providers may have similar scenarios be broken," he added.
Google warned IT pros in its Oct. 23 Chromium blog post that there could be problems with internal applications and single sign-on implementations:
Enterprise IT administrators may need to implement special policies to temporarily revert Chrome Browser to legacy behavior if some services such as single sign-on or internal applications are not ready for the February launch.
IT Pro Warnings
Microsoft has issued a specific warning about the coming SameSite changes. Effects could be felt when using Microsoft Teams client applications. There are considerations for sites that use ASP.NET. Exchange Server, SharePoint Server and the Skype for Business client all will need to have the latest updates installed.
With regard to the Teams client, Microsoft warned in this Microsoft Teams and SameSite cookies document that "Applications running in the Teams desktop client are incompatible with the SameSite=None attribute, and they will not work as expected." The document offered a couple of "workaround" options. It also explained that the Secure attribute needs to be used when the SameSite attribute's value is set to None to assure that third-party cookies won't get rejected.
For sites using ASP.NET or ASP.NET Core, Microsoft warned in an Oct. 18 ASP.NET blog post that the new SameSite changes will be in effect with ".NET 4.7.2 and in .NET Core 2.1 and above" and they could break OpenIDConnect log-ins. Updates to .NET that were released back in December and November added support for the new SameSite behavior.
The ASP.NET post also offered a guess on when the Chrome browser changes will get turned on.
"Chrome 80 is scheduled to turn on the new behavior in February or March 2020, including a temporary mitigation added in Chrome 79 Beta," the ASP.NET blog post indicated.
Essentially, "each ASP.NET component that emits cookies needs to decide if SameSite is appropriate," Microsoft advised in its document, titled "Work with SameSite Cookies in ASP.NET." There's a particular caution offered for sites using iframes.
"Applications that use iframe may experience issues with SameSite=Lax or SameSite=Strict cookies because iframes are treated as cross-site scenarios," the document stated.
Microsoft also warned developers of SharePoint provider-hosted App Parts add-ins using ASP.NET that they may have to make a change to the "system.web" declaration and use the SameSite="None" value. The reason for having to make that change is that the coming default "Lax" value "prevents the cookie from being sent to an iframe if the domain of the iframe is different than the host page," throwing a 405 error for end users.
Microsoft published a general article on how the changes in the stable Google Chrome browser, version 80 or later, will affect Web sites in this document, which is dated Jan. 21. It stated that this stable version of Chrome is "scheduled for release on February 4, 2020."
Microsoft's Jan. 21 document also included recommendations for IT pros. Certain January updates need to be in place if organizations use Windows Server 2019 or Windows Server 2016 with federation or proxy services:
Microsoft customers who use Active Directory Federation Services (AD FS) or Web Application Proxy must deploy one of the following Windows Server updates:
Microsoft's Jan. 21 document also suggested that it's possible to disable the new SameSite behavior using "Group Policy, System Center Configuration Manager, or Microsoft Intune (or any Mobile Device Management software)" until it's possible to have the time to verify that apps won't get broken by the changes.
Lastly, the Exchange team issued a notice last week that it will issue cumulative updates (CUs) for Exchange Server 2019 and Exchange Server 2016 that will support the SameSite changes. However, those CUs will arrive in March, while Google's Chrome changes are scheduled for a Feb. 4, 2020 rollout.
"Given the date of our scheduled CU's comes after Google Chrome's release date of February 4th there might be some issues experienced by users," the Exchange Team explained.
The team suggested, as a workaround, that users could switch to another browser, or the Outlook Web App could be set to use the legacy SameSite cookie behavior.