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:
These products are based on SAP Kernel or SAP Web Dispatcher as a base technology.
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").
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:
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.
Scenarios that do not span multiple registrable domains (see above for a definition), like pure intranet scenarios within a corporate DNS domain (e.g. *.acme.corp), are not affected.
The SameSite change also does not cause your issue if one of the following is the case:
The article 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.
We recommend the following: Use Chrome version 80 or higher. Enable the new SameSite behavior like described in the article "Tipps for testing". Activate the browser's DevTools by pressing the F12 button on your keyboard. Open the "Network" panel and reproduce your scenario.
Then activate the check boxes "Preserve log", "Only show requests with SameSite issues" and "show filtered out request cookies" like shown in the picture:
If there are no requests shown, there should be no SameSite issue.
If you need help analyzing an issue, make sure to save the network trace. Use the downward arrow button marked in the screen shot above to save the trace as a so-called HAR archive to your computer.
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.
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.
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.
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:
Disadvantages are:
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).
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.
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:
Disadvantages are:
For the server-side solution it is sufficient to implement setting the SameSite cookie attribute it in either one of:
Preferred solution: Use a current SAP kernel or SAP Web Dispatcher patch level and set a profile parameter to activate setting the SameSite cookie attribute. See SAP note 2893546 "SameSite support in SAP Web Dispatcher and ICM" for details on required patch levels and implementation.
Alternative solution: In case you cannot apply the latest patch level or your kernel version does not yet have a patch level that supports it, you can use modification rules for setting the SameSite cookie attribute as a temporary workaround. SAP note 2887651 explains in the second half how to configure the modification rule for setting the SameSite=None and Secure attribute in SAP kernel or SAP Web Dispatcher.
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. The preferred solution is to use a current patch level of SAP kernel or SAP Web Dispatcher and activate the SameSite=None cookie attribute by profile parameter. And as always, should you be uncertain don't hesitate to ask for help.
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
Scenarios that do not span multiple registrable domains (see above for a definition), like pure intranet scenarios within a corporate DNS domain (e.g. *.acme.corp), are not affected.
The SameSite change also 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).
How to analyze SameSite issues
The article 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.
We recommend the following: Use Chrome version 80 or higher. Enable the new SameSite behavior like described in the article "Tipps for testing". Activate the browser's DevTools by pressing the F12 button on your keyboard. Open the "Network" panel and reproduce your scenario.
Then activate the check boxes "Preserve log", "Only show requests with SameSite issues" and "show filtered out request cookies" like shown in the picture:
If there are no requests shown, there should be no SameSite issue.
If you need help analyzing an issue, make sure to save the network trace. Use the downward arrow button marked in the screen shot above to save the trace as a so-called HAR archive to your computer.
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. Google promises to support the policies at least until February 2021.
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).
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.
For the server-side solution it is sufficient to implement setting the SameSite cookie attribute it in either one of:
- Internet Communication Manager (ICM) of SAP Web Application Server ABAP or Java.
- SAP Web Dispatcher (also the built-in Web Dispatcher in HANA XS-Classic).
Preferred solution: Use a current SAP kernel or SAP Web Dispatcher patch level and set a profile parameter to activate setting the SameSite cookie attribute. See SAP note 2893546 "SameSite support in SAP Web Dispatcher and ICM" for details on required patch levels and implementation.
Alternative solution: In case you cannot apply the latest patch level or your kernel version does not yet have a patch level that supports it, you can use modification rules for setting the SameSite cookie attribute as a temporary workaround. SAP note 2887651 explains in the second half how to configure the modification rule for setting the SameSite=None and Secure attribute in SAP kernel or SAP Web Dispatcher.
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. The preferred solution is to use a current patch level of SAP kernel or SAP Web Dispatcher and activate the SameSite=None cookie attribute by profile parameter. And as always, should you be uncertain don't hesitate to ask for help.
- SAP Managed Tags:
3 Comments
