Affects Version/s: 13.5.2, 5.5.1, 184.108.40.206, 7.0.0
Google have announced that Chrome will move to treating all cookies as if they were marked SameSite=lax by default as of Chrome 80 (likely to be released Feb 2020). See https://www.chromestatus.com/feature/5633521622188032 for details and status.
NB "Site" in SameSite refers to a "registerable domain" rather than an origin. Requests from foo.example.com to bar.example.com are not impacted as they have the same registerable domain of "example.com". So this only impacts true cross-domain calls such as with federation.
We know from testing after introducing support for SameSite cookies that this will definitely break some features of AM and may impact some customer's use of AM features. A partial list of features likely to be affected is:
- SAML 2 Single Logout (SLO) when using the HTTP POST binding. AM will fail to see the session cookie on the logout request and so logout will fail.
- Some uses of the SAML 2 POST binding and the OpenID Connect Form Post response mode may be impacted. In particular, the common pattern of setting the "state" parameter as a cookie at the client before starting an OIDC flow is likely to be completely broken if the Form Post response mode is used. (Our own social auth module and node appears to be ok)
- Any cross-site use of our REST APIs that has been configured with Access-Control-Allow-Credentials to enable cookie support. SameSite effectively completely disables this usage of CORS.
There may be an impact on agents, as they are known to use the form_post response mode. We need to evaluate any impact on other agent features such as PDP. (Assessment is that no agent features are affected at this time).
Google are introducing a new cookie option SameSite=none to allow opting out of this behaviour. There are some potential problems with this approach though:
- They will only respect the flag if the cookie is also marked as Secure. This means that it will no longer be able to test/evaluate the above features of AM on a non-secure installation and developers will be required to setup SSL before they can test these features. (Probably a good thing, but it will add friction).
- Many web frameworks (including the servlet spec) lack any support for SameSite cookies, so customers may not be able to add SameSite=none to their cookies without writing custom code to generate cookie headers manually (as we currently do to support SameSite).
- Safari has/had a bug that caused it to treat SameSite=none as if it was SameSite=strict, which has the opposite intended meaning. This has been fixed in Mac OS 10.15 and iOS 13 but the comments on the bug indicate that Apple is not going to back-port the fix, meaning that we will need to do useragent sniffing to avoid negative consequences for users on older versions.
It may be possible to capture cross-domain requests and resubmit them from the same origin using a self-submitting form or other trick so that the cookies are now visible. This behaviour would completely bypass the existing CSRF protections though as cross-site requests would be transformed into same-site requests, so we would need an alternative form of anti-CSRF measure to be enforced before doing this.
A more promising solution will be to implement SameSite=none with browser sniffing to either only set this for Chrome or to disable it on older versions of Safari depending on whether other browsers follow Google or not.