The Spectre Attack and Critical CSS

Posted by John Bender 01/05/2018

TL;DR

Due to recently disclosed security vulnerabilities for nearly all computers, you should disable any JavaScript cookie manipulation on your website (e.g. when using the critical CSS technique) by setting your cookies to be SameSite and HttpOnly on the server, as recommended on the Chromium wiki. Otherwise, sensitive data, like session keys, may be exposed to malicious third parties.

Meltdown and Spectre Vulnerabilities

Permalink to 'Meltdown and Spectre Vulnerabilities'

Two days ago a group of security researchers at Google disclosed two security flaws, dubbed Meltdown and Spectre, that allow processor exploits to steal passwords and other sensitive user data from almost any device made in the past 20 years.

Taken together these vulnerabilities affect nearly every computer on the web. In this article, we’re focused on mitigating a variant of the Spectre attack since it has a JavaScript proof of concept exploit. In particular we are concerned with how it can be used to expose sensitive data in a site’s cookies.

The attack works by exposing same-process memory that would otherwise be unreadable to JavaScript. This is an issue if a browser loads two sites into the same rendering process, which can happen in spite of process-per-site-instance isolation like that used by default in Chrome.

We haven’t yet seen a detailed description of how the page might be added to another page’s memory (see “Unknowns” below) but one way might be through a same process iframe render. The malicious site would load the target site in an iframe which would run the document.cookie read in the same process, exposing the cookie data to the attack.

Impact on Web Developers

Permalink to 'Impact on Web Developers'

These exploits should be a concern for web developers since a cookie that is not flagged as SameSite and HttpOnly on the server may be more likely to expose the cookie data to a third party.

Until browsers implement mitigations as defaults we recommend using those flags. This is in keeping with the recommendations on the Chromium wiki and it prevents JavaScript from accessing the cookie which should mitigate the attack.

It’s strongly recommended that you examine any plugins, libraries, and 3rd party tools that manipulate cookies to see if they are a potential security concern.

Spectre and CriticalCSS

Permalink to 'Spectre and CriticalCSS'

We frequently use a technique which works by identifying and including the “above the fold” CSS inline in the head of the page for a “fresh” (empty cache) page load to speed up rendering. Then, once the client is likely to have cached the full CSS, typically a cookie is set on the client so that the server can remove the inlined CSS on subsequent page requests, reducing page weight.

The problem is that, in setting the cookie, the page pulls all of the cookie data into memory exposing any sensitive data, like session information, to the Spectre attack.

Our current advice is if you are using CriticalCSS with a cookie on your website, you should disable the document.cookie read by setting the SameSite and HttpOnly flags as mentioned above. Otherwise sensitive data may be exposed to malicious third parties.

It’s important to note the distinction between the CriticalCSS library and the critical CSS technique. The CriticalCSS library extracts above-the-fold CSS that should be inlined in the page. The technique of dynamically inlining CSS based on a cookie value is simply one way this could be served to the browser.

Unknowns

Permalink to 'Unknowns'

As a matter of transparency there are still many facets of these vulnerabilities which are unclear to us:

How precisely can a malicious site get a target site into the render process? We speculated above on that note but it’s not documented anywhere.
Is the danger of loading cookies confined to the first variant of the Spectre Attack? It seems like this is almost certainly not the case, but for now it’s the only variant with a JavaScript proof-of-concept that we are aware of.
Many of the patches and recommendations for users and site operators (site isolation, HttpOnly cookies, reduced performance sampling, etc) are labeled as mitigations and not fixes. It seems these vulnerabilities may be with us for the forseable future.

References

Permalink to 'References'

All blog posts