Chrome Tightens CSRF Protection

The Chrome 76 browser, which is expected in July 2019, will include tighter controls for the SameSite cookie attribute. This attribute is used by website or web application developers when they set cookies. It specifies whether the cookie may be used in a third-party context. If this attribute is set correctly, it prevents the possibility of using your cookies for a Cross-site Request Forgery (CSRF) attack.

How Does the SameSite Attribute Work?

A cookie is always tied to a particular domain. However, let us say that you have a website and you embed a YouTube video on it. When a user who is logged onto YouTube visits your site, by default YouTube receives a request, too. That request includes information that it comes from your site and it includes YouTube cookies. This is called a third-party context.

The SameSite attribute of the Set-Cookie header was introduced as an IETF draft in April 2016 by Mike West from Google and Mark Goodwin from Mozilla. The attribute is sent when setting a cookie, for example:

Set-Cookie: my_cookie=1; SameSite=Strict

The attribute may have one of the following values:

• SameSite=Strict: The cookie is only sent if you are currently on the site that the cookie is set for. If you are on a different site and you click a link to a site that the cookie is set for, the cookie is not sent with the first request.
• SameSite=Lax: The cookie is not sent for embedded content but it is sent if you click on a link to a site that the cookie is set for. It is sent only with safe request types that do not change state, for example GET.
• SameSite=None: The cookie is sent even for embedded content. Until recently, this was also the current behavior of many browsers if the SameSite attribute is not set.

If the value of the SameSite attribute is invalid, most browsers assume that SameSite is not set and therefore apply their default setting. Rowan Merewood from Google wrote an excellent article explaining this mechanism in more detail.

The SameSite=Strict and SameSite=Lax settings protect your cookies from being used in CSRF attacks. However, they make tracking more difficult. These settings should be used for authentication cookies but they are not good for tracking cookies used in advertising.

How Does Chrome 76 Handle SameSite Cookies

Chrome 76 introduces a new user flag: same-site-by-default-cookies. If you set this flag in your chrome://flags, all cookies that do not have the SameSite attribute will be treated as if they had SameSite=Lax.

For an average user, there will be no changes. Security-conscious users who know how to configure Chrome will be able to turn this extra protection on manually. Chrome developers are hoping, that this change will make website and web application creators more security-conscious and that they will add the SameSite attribute to all their cookies.

What Can You Expect in the Future?

This introductory step in Chrome will hopefully increase the use of this method of protection, which has been around for more than three years now so it can be considered mature. In future versions, Chrome will probably set the same-site-by-default-cookies flag by default. This may initially cause a bit of mayhem for advertisers who use tracking cookies and who don’t use the SameSite attribute.

Perhaps this step will also cause more browsers to support the SameSite attribute. At the moment of writing, this attribute is supported by most desktop browsers (except IE on older Windows) but not by several mobile browsers.

Will This Eliminate CSRF Attacks?

The SameSite attribute is only one of the methods that may be used to protect your website or web application against CSRF attacks. At the moment, it cannot be treated as a universal remedy. It is not supported by some modern browsers and old browsers that are still in use (for example, on older Windows versions). It may also be a problem for developers who use older web development languages because these languages may not let them set the attribute.

To protect your website or web application, you should keep using other methods along with the SameSite attribute, for example, anti-CSRF tokens. To test if your website or web application is vulnerable to CSRF, run an automated web scan using the Acunetix vulnerability scanner, which includes a specialized CSRF scanner module. Take a demo and find out more about running CSRF scans against your website or web application.

THE AUTHOR

Tomasz Andrzej Nidecki
Principal Cybersecurity Writer
LinkedIn

Tomasz Andrzej Nidecki (also known as tonid) is a Primary Cybersecurity Writer at Invicti, focusing on Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.