Chrome 80 update – Security improvements may break less secure web services

Share on facebook
Share on google
Share on twitter
Share on linkedin

In May 2019, Chrome announced a secure-by-default model for cookies, enabled by a new cookie classification system (spec). This initiative is part of Google’s ongoing effort to improve protection of users’ privacy and security across the web.

This is a significant improvement to users online safety and prevents non-secure sites from accessing your login cookies, the files that mean you don’t need to re-login to a website every time you visit it.  This will also improve the security of Single Sign On (SSO) Systems and services like “Sign in with Google” and “Sign in with Facebook” etc. 

You can read the announcement about Chrome Version 80 here:

https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html

Despite the fundamental importance of this basic security change, we have already been contacted by users who have received warnings from service and application developers who have failed to adequately secure their systems. 

In this case, such insecure apps can now only be used on less secure browsers such as Internet Explorer, Microsoft Edge and Firefox.  However, users should note that both Firefox and Edge are going to implement the same update shortly. 

From Chrome 80 in February 2020, all cross-site Cookies must use SSL, that is HTTPS. Mozilla and Microsoft have also indicated intent to implement the new model in Firefox and Edge.  Microsoft had said it would implement the change at the same time as Google but has not given a specific date, however, it is expected to ship with the next update to Microsoft Edge. Mozilla Firefox has also included this change within its current beta versions and is expected to roll out the update in Firefox 72 and the end of February.

https://redmondmag.com/articles/2020/01/28/samesite-cookie-changes-break-apps.aspx 

On a 21 January posting a Senior Googler reported that they “believe the field trial results [from this improvement] indicate a very modest amount of breakage.“

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/AknSSyQTGYs/U4RVwbF2DwAJ

Does this mean that XYZ website is not secure? 

If this site is affected by this update, it has always had a significant security flaw which has been exposing your data for some time, this highlights a concern as to the reliability of that service, will it keep your data secure, follow security best practice and, security by design standards?  This is something you should discuss with them. 

Technical detail: 

Cookies intended to be accessed in a first-party context should have one of two settings (SameSite=Lax or SameSite=Strict) applied to prevent external access. In practice, very few developers have been following this best practice leaving a large number of single-site cookies exposed to security threats such as Cross-Site Request Forgery attacks.

The new secure-by-default proposed in IETF draft proposed a model that assumes all cookies should be protected from external access unless otherwise explicitly specified. Therefore developers would be required to use the cookie setting, SameSite=None, to designate cookies for cross-site access. When the SameSite=None attribute is present, an additional Secure attribute must be used so cross-site cookies can only be accessed over HTTPS connections. This will not mitigate all risks associated with cross-site access but it will provide protection against network attacks.

With Chrome 80 in February and other browsers shortly afterwards, Chrome will treat cookies missing a 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 SSL / HTTPS secure connections. 

Update:

Though Chrome 80 is due for release February 4, 2020, Google has said that the SameSite-by-default and SameSite=None-requires-Secure behaviours will begin rolling out, week commencing February 17, 2020. https://www.chromium.org/updates/same-site 

If you have any further questions or think your error may be unrelated please give our support desk a call.