The Spectre Attack and Critical CSS
Posted by John 1/5/2018
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.
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
These exploits should be a concern for web developers since a cookie that is not flagged as
HttpOnly on the server may be more likely to expose the cookie data to a third party.
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
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
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.
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.
Many of the patches and recommendations for users and site operators (site isolation,
HttpOnlycookies, reduced performance sampling, etc) are labeled as mitigations and not fixes. It seems these vulnerabilities may be with us for the forseable future.