Due to recently disclosed security vulnerabilities for nearly all computers [1,2], if you are using the critical css technique [3] on your website, you should disable the document.cookie
read by setting your cookies to be SameSite [4] and HttpOnly [5] on the server, as recommended in [6]. Otherwise sensitive data (such as session keys) may be exposed to malicious third
parties.
Two days ago a group of security researchers 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. [1,2].
Taken together these three 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 [link to it here?]. 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 [8].
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 [7]. 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.
These exploits should be a concern for web developers since any JavaScript which reads document.cookie may expose the cookie data to a third party.
Until browsers implement mitigations as defaults we recommend using the SameSite and HttpOnly flags as recommended in the Chrome wiki [6]. Explain what this menas in more detail, any
limitations, etc.
It's strongly recommended that you examine any plugins, libraries, and 3rd party tools that use cookies to see if they are a potential security concern. As part of this assessment, we've been discussing how it impacts our recommendation for our CriticalCSS tool since it is frequently paired with cookies.
We frequently use CriticalCSS [3] 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 POC attack.
Our current advice is if you are using CriticalCSS with a cookie [3] on your website, you should disable the document.cookie read by setting your cookies to be SameSite [4] and
HttpOnly [5] on the server, as recommended in [6]. Otherwise sensitive data (such as session keys) may be exposed to malicious third parties.
It's important to note that the core utility of CriticalCSS is to extract the CSS that should be inlined in the page. The cookie logic to dynamically write in this CSS is mostly provided to show one way this could be implemented but any number of server-side approaches can be used to make this inference (session,etc.).
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.
-
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.
Hopefully more detailed information will be forthcoming.
- https://spectreattack.com 2. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html 3. https://www.filamentgroup.com/lab/performance-rwd.html 4. https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.3.7 5. https://www.owasp.org/index.php/HttpOnly 6. https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca 7. https://www.chromium.org/developers/design-documents/oop-iframes 8. https://sites.google.com/a/chromium.org/dev/developers/design-documents/process-models#Supported_Models