Skip to Content
Technical Articles

Handling Google Chrome SameSite cookie change in SAP on-prem applications

Google Chrome will roll out an incompatible change regarding the “SameSite” cookie attribute starting Feb 17, 2020. All cross-domain browser scenarios could be critically affected.

In this blog, I would like to inform you on the technical background, the affected scenarios and provide a solution of the problem.

This blog focuses on scenarios containing the following SAP products:

  • SAP NetWeaver Application Server for ABAP
  • SAP NetWeaver Application Server for Java
  • SAP HANA extended application services, classic model
  • SAP HANA extended application services, advanced model

These products are based on SAP Kernel or SAP Web Dispatcher as a base technology.

Issue description

The “SameSite” attribute of cookies controls the cross-domain behavior of cookies. See this article for details: SameSite cookies explained. Up to now, all browsers had the implicit default SameSite=None, which imposes no restriction on cross-domain cookies.

Google will activate a stricter cookie handling starting February 17, 2020 in Chrome version 80. With that change, the browser will use the cookie attribute SameSite=Lax as default if no value is explicitly specified by the server. In addition, the browser will require the Secure attribute in case SameSite=None is provided by the server.

The reasoning behind this change is to provide protection against cross-site request forgery (CSRF) attacks. However, SAP applications are already protected against this type of attack by other means; therefore, the change does not provide additional security for them.

The problem with this change is that many applications integrate different web sites within a single browser window and rely on cross-domain cookies. Such scenarios may not work properly with the changed default unless the cookie attribute is set explicitly by the application server.  See Developers: Get Ready for New SameSite=None Cookie Settings.

The SameSite cookie attribute governs cookie exchange between different registrable domains (which is the domain’s public suffix plus the label to its left, see Public Suffix List). Services that share a common registrable domain do not require the SameSite=None cookie attribute (e.g. “www.sap.com” and “support.sap.com” share the common registrable domain “sap.com”).

Affected scenarios

Currently, the SAP products listed above that are based on SAP kernel or SAP Web Dispatcher do not set the SameSite=None attribute.

All scenarios that integrate these products with web services from different registrable domains within a single browser window are potentially affected. We currently know of the following affected scenarios, but there may be more:

  • Logon and single sign-on using SAML2. To be more precise, the SAML2 POST binding against a SAML Identity Provider (IdP) that resides in a different registrable domain is affected. An example is using SAP ID service with your intranet systems. Both the IdP and the ABAP system issue cross-domain cookies that need to set the SameSite=None attribute. The SAP ID service already does this correctly.
  • SAP Analytics Cloud (SAC). Here, the SAC web site makes XMLHttpRequests to the ABAP backend system, which use cross-domain cookies issued by the ABAP system for authentication. See Direct Live Connections in SAP Analytics Cloud and SameSite Cookies and FAQ: SameSite Cookie and Direct Live Connections in SAP Analytics Cloud for details.

If you operate any scenario that integrate web services from different registrable domains, we strongly recommend testing whether it is affected by the issue. See Tips for testing and debugging SameSite-by-default and “SameSite=None; Secure” cookies.

Not affected scenarios

A scenario that does not span multiple registrable domains (see above for a definition) is not affected. Especially, pure intranet scenarios within a corporate DNS domain (e.g. *.acme.corp) are not affected.

If you observe an issue – how to find out if it is caused by the SameSite change

The page Tips for testing and debugging SameSite-by-default and “SameSite=None; Secure” cookies describes how to analyze SameSite cookie issues using the Chrome version 80 browser.

The SameSite change does not cause your issue if one of the following is the case:

  • The issue persists with different browsers apart from Google Chrome version 80, like Internet Explorer, Safari or Firefox.
  • The issue persists if I set the following two Chrome flags to “Disabled”: chrome://flags/#same-site-by-default-cookies and chrome://flags/#cookies-without-same-site-must-be-secure (see “Browser-side solution” below).

Recommendation

If your scenario is affected, implement one of the solutions described below. If you are not sure you may want to implement the solution as a precautionary measure.

Solution

If a scenario requires cookies to be used for requests spanning multiple registrable domains, the solution is to restore the previous SameSite=None behavior for these cookies. This can be implemented either in the browser or the server.

Security considerations

Why is it safe to restore the previous behavior? As mentioned above, SAP applications already implemented comprehensive protection against cross-site request forgery (CSRF) attacks with a token-based approach. So the new behavior does not add security for SAP solutions. And therefore, reverting to the previous behavior does not cause any security risks.

Browser-side solution

The first way to revert to the old behavior is to configure the way the browser handles cookies. Google recommends using Cookie Legacy SameSite Policies to achieve this. This solution has certain advantages:

  • Central roll-out to corporately managed devices (Windows, Mac, Android) is possible. For example, on Windows the roll-out involves just setting one registry entry.
  • Solves all issues, not just ABAP-based application servers.
  • Stricter cookie policies that may be implemented in the future are not invalidated.

Disadvantages are:

  • The browser-side solution is only useful for scenarios if you have control over the browser installations. It is not useful for scenarios in the public Internet or with a diverse set of client computers.
  • May work only for a limited time.

It is also possible to configure individual Chrome browser installations to retain the legacy behavior for cookies by setting both flags to “Disabled”: chrome://flags/#same-site-by-default-cookies and chrome://flags/#cookies-without-same-site-must-be-secure (copy these links into the address bar or the browser).

Both the policies and the chrome://flags will be supported at least until February 2021.

An alternative browser-side solution is to switch to a different browser. As of February 2020, only Google Chrome versions 80 and higher implement the SameSite=Lax default.

Server-side solution

The server-side solution reverts to the previous behavior by explicitly setting the SameSite=None and Secure attribute to all cookies issued by the SAP system. This solution has different advantages:

  • Available to all clients without need to touch the browser installation.
  • Long-term solution even after browsers policies are removed.
  • Allows stricter cookie policies for individual cookies in the future.

Disadvantages are:

  • The server-side solution handles only cookies issued by the SAP systems listed above or systems sitting behind an SAP Web Dispatcher. Third-party servers, like a SAML IdP, are not covered.
  • The solution works only for HTTPS, not for unencrypted HTTP, due to the required Secure attribute. We recommend using HTTPS for security reasons, anyway.

SAP note 2887651 explains in detail how to configure the SAP kernel or SAP Web Dispatcher for setting the SameSite=None and Secure attribute.

Conclusion

If you operate browser-based scenarios that integrate multiple registrable domains you may be affected by the disruptive change of cookie handling that Google rolls out in Chrome version 80 starting Feb 17, 2020.

We recommend you analyze and test your browser-based integration scenarios even if it is just single sign-on using an external SAML provider. Pure intranet scenarios using a single common domain name (like *.acme.corp) are not affected.

If your applications are affected, follow one of the solution options described above. And as always, should you be uncertain don’t hesitate to ask for help.

1 Comment
You must be Logged on to comment or reply to a post.