Google has made a change to its Chrome browser recently. The change affects the way the browser handles cookies.

In previous versions of Chrome (Pre-version 80), cookies are sent in a cross-site request by default. This could result in a security issue such as CSRF (Cross-Site Request Forgery). This is where someone tricks a victim to perform a request on the attackers’ behalf.

The SameSite attribute was available as an optional attribute within Chrome until now. 

What is the SameSite attribute? As you might imagine, SameSite refers to the site in which it is associated. This attribute has three values:

• None – A cookie will be sent in all cross-site requests (Pre- version 80). However, within Chrome this is only possible when the ‘Secure’ attribute is assigned. 
• Lax – A cookie will be sent SameSite as Strict, but also in cross-site requests via top-level navigations using a safe HTTP method (e.g. GET).
• Strict – A cookie will only be sent if the site that is associated with the cookie matches the site in the browsers address bar. 

In the new version of Chrome (version 80), any cookie that hasn’t got the SameSite attribute specified will, by default be treated as ‘Lax’.

This means that cookies will be sent in cross-site requests but limited to only top-level navigations using a defined safe HTTP method in addition to SameSite. While the SameSite attribute has generally been supported in the past, it wasn’t fully utilised by developers.

How does this affect CSRF? CSRF replies upon the changing of a state, this being writing or modifying data. The consensus is that HTTP methods that are defined as safe should only get data. So, the value ‘Lax’ would allow cookies to be sent cross-site via top-level navigation (e.g. GET), meaning any dangerous action shouldn’t be allowed unlike the unsafe POST method.

However, according to this reference, Chrome will make an exception.

Note: Chrome will make an exception for cookies set without a SameSite attribute with a duration of ‘less than 2 minutes ago’. Such cookies will also be sent with non-idempotent (e.g. POST) top-level cross-site requests despite normal SameSite=Lax cookies requiring top-level cross-site requests to have a safe (e.g. GET) HTTP method. Support for this intervention (“Lax + POST”) will be removed in the future.

This means a cookie within 2 minutes of being set or changed will be sent via an unsafe POST method via top-level navigation, while Lax restricts this behaviour to safe methods only. This is an interim measure until the feature is removed. As this feature is related to Chrome, and Chrome being the first to implement this by default, it will still be possible to perform CSRF attacks by targeting other browsers when this SameSite attribute has not been explicitly set by the developer. 

These changes are also available in Firefox version 69 but will be made default in the future. Microsoft also plan on making the change in its Edge browser to enforce the attribute too. Ultimately, developers will need to specify this SameSite attribute explicitly stating how they want cookies to be used.

In the next article, the change will be explored in more detail.