Same-site cookie support arriving on Chrome later this year

Google engineers have laid out how to best secure web applications using new and upcoming features in Chrome.

At the annual Google I/O conference this week, Artur Janc and Lukas Weichselbaum gave their tips on how to implement some of Chrome’s security-focused attributes to protect against malicious attacks.

The big news from I/O was Google’s announcement that it will be introducing support for same-site cookies on Chrome in 2019.

These changes will allow developers to use a SameSite attribute within HTTP headers, introduced by the website owner, that can be set to strict, lax, or none.

‘Strict’ instructs browsers to only send cookies from pages on the same site, whereas ‘lax’ or ‘none’ can be loaded from other sites.

It will allow web developers to explicitly differentiate between same-site and cross-site cookies, enabling them to store their sensitive cookies on same-site and protecting against a series of attacks including cross-site request forgery (CSRF).

Same-site cookies have notably been supported by Firefox since April 2018.

Microsoft Edge and Internet Explorer began support for same-site cookies in June 2018, whereas Safari began its support in iOS 12.

“The problem with same-site cookies is while they are very powerful and very useful for security, it’s a little difficult to know what the consequences are of setting the SameSite attribute in your cookies,” said Janc.

But this can be mitigated using fetch metadata request headers, he said.

“With fetch metadata you get the information that lets you see if your application is fully compatible,” Janc told attendees.

“The gist is that fetch metadata headers help you test the deployment of same-site cookies in your application.”

These headers can be used to both test same-site cookies and also to protect against further attacks.

With this feature enabled, browsers send HTTP request headers that contain relevant security information to the server.

“So for example, the Sec-Fetch-Site header tells you which site made the request that ends up in your application. If it was your own application, the value of that header will be same origin, if it was some other completely unrelated website that made the request to you, it will be cross-site,” explained Janc.

Without the headers, a same-site origin request would appear identical to a cross-site origin request.

Fetch metadata request headers check that the request is from the same origin and checks it is from the same site before allowing it to execute.

This feature is implemented in Chrome now, shipping in the latest version.

Rewarding bug hunters

During their presentation at Google I/O, the engineers also discussed Google’s Vulnerability Reward Program, which has so far paid out around $1 million annually for web application vulnerabilities.

At 35% of the overall reports, cross-site scripting (XSS) has been the number one attack discovered by bug bounty hunters.

To mitigate against XSS in web apps, Weichselbaum recommended using nonce-based Content Security Policy (CSP).

CSP isn’t a new idea – it has been seen since 2010, and basically sets a policy to prevent unauthorized scripts from executing.

The issue lies with whitelisting domains that are allowed to inject scripts. Research by Google found that 95% of whitelist-based CSPs can by bypassed.

Chrome supports nonce-based CSP, which whitelists an entire block of script regardless of what it might contain. But with the nonce attribute implemented, the browser blocks any unauthorized script from running.

Nonce attributes use random, non-guessable tokens for authentication.

They change with every response and always match the header in the CSP – meaning that if an attacker injected their own script tag, it won’t match the header and will fail to authenticate. This means their XSS attack won’t execute.

Historically, nonce attributes have not worked with third-party script or widgets, and developers faced a large refactoring effort in implementing them.

Chrome’s CSP3 now contains what’s called a strict dynamic keyboard, mitigating these issues.