Original text link (need to cross the wall):
Developers.google.com/web/updates…The original article was last updated on February 7, 2018
Translator: Listening to the rain in the West building
(Please note the source for reprint)
The Overview introduction
On January 3rd Project Zero revealed vulnerabilities in modern CPUs that a process can use to read (at worst) arbitrary Memory — including memory that doesn’t belong to that process. These December have been named Spectre and all of those vulnerabilities had been rejected Meltdown. What is Chrome doing to help keep the web secure, and what should web developers do for their own sites?
On January 3, Project Zero revealed a vulnerability in modern cpus that allows processes to read arbitrary memory (at worst) — including memory that doesn’t belong to it. The flaws are named Spectre and Meltdown. So what can Chrome do to secure the Web? What should Web developers do for their sites?
TL; DR conclusion (” Too long to read “)
As a user browsing the web, you should make sure you keep your operating system and your browser updated. In addition, Chrome users can consider enabling Site Isolation.
As a web user, you should make sure your operating system and browser are up to date at all times. Alternatively, Chrome users can consider turning site Quarantine on.
If you are a web developer, the Chrome team advises:
- Where possible, prevent cookies from entering the renderer process’ memory by using the SameSite and HTTPOnly cookie attributes, and by avoiding reading from document.cookie.
- Make sure your MIME types are correct and specify an
X-Content-Type-Options: nosniffheader for any URLs with user-specific or sensitive content, to get the most out of cross-site document blocking for users who have Site Isolation enabled. - Enable Site Isolation and let the Chrome team know if it causes problems for your site.
If you’re a Web developer, the Chrome team suggests:
- Wherever possible, prevent cookies from entering the rendering process’s memory by setting the SameSite and HTTPOnly properties of cookies and avoiding reading Document. cookies.
- Make sure the MIME type is correct and specify one for any URL that is relevant to a particular user or contains sensitive content
X-Content-Type-Options: nosniffResponse headers,To provide maximum cross-site blocking benefits to users who have turned on site isolation. - Enable site isolation and let the Chrome team know if it might cause problems for your site.
If you are wondering why these steps help, read on!
If you’re interested in why all of this is useful, keep reading!
The risk of risk
There have been a wide variety of explanations of these vulnerabilities, so I am not going to add yet another one. If you are interested in how these vulnerabilities can be exploited, I recommend taking a look at the blog post by my colleagues from the Google Cloud team.
There are already many explanations for these loopholes, so I won’t repeat them. If you’re interested in how they can be leveraged, I recommend reading this blog post by my colleague on the Google Cloud team.
Both Meltdown and Spectre potentially allow a process to read memory that it is not supposed to be able to. Sometimes, multiple documents from different sites can end up sharing a process in Chrome. This can happen when one has opened the other using window.open, or <a href="..." target="_blank">, or iframes. If a website contains user-specific data, there is a chance that another site could use these new vulnerabilities to read that user data.
Both Meltdown and Spectre have the potential to allow a process to read memory that it was not intended to read. In Chrome, it is sometimes possible for multiple documents from different sites to share a process. This can happen if a site uses window.open or or iframes to open another site. If one site contains user-specific data, there is an opportunity for other sites to exploit these new vulnerabilities to read user data.
Mitigations
There are multiple efforts the Chrome and V8 engineering team is deploying to mitigate this threat.
The Chrome and V8 engineering teams are making every effort to release deployments to mitigate this threat.
Site Isolation Site Isolation
The impact of successfully exploiting Spectre can be greatly reduced by preventing sensitive data from ever sharing a Process with controlled code. The Chrome team has been working on a feature to achieve this called “Site The Isolation “:
If we can completely prevent sensitive data from being shared with the process in which the attacker controls the code, we can greatly mitigate the impact of a successful exploitation of Spectre. The Chrome team is already working on a new feature that could do just that:
“It’s Websites and typically cannot access each other’s data inside the browser. . Occasionally, security bugs are found in this code and malicious websites may try to bypass these rules to attack other websites. […]. Site Isolation offers a second line of defense to make such attacks less likely to succeed. It ensures that pages from different websites are always put into different processes, Each running in a sandbox that limits what the process is allowed to do.”
“Typically, in a browser, you can’t access each other’s data from one site to the other… . Occasionally, there are security bugs that might try to bypass these rules to attack other sites. … ‘Site isolation’ provides a second line of defense against such attacks, thereby mitigating their likelihood. It ensures that pages from different websites are always placed in different processes, each running in a sandbox that limits what they can access. ”
Site Isolation has not been enabled by default yet as there are a couple of known issues and the Chrome team would like as much field testing as possible. If you are a web developer, you should enable Site Isolation and check whether your site remains functional. If you’d like to opt-in now, enable chrome://flags#enable-site-per-process. If you find a site that doesn’t work, please help us by filing a bug and mention that you have Site Isolation enabled.
Site Isolation is not currently enabled by default because there are known issues and the Chrome team wants to test it as much as possible. As a Web developer, you should turn it on and check that your site is still working. If you want to enable it now, open chrome://flags#enable-site-per-process. If you find that a site does not work properly after enabling it, please help us by filling in a bug and mentioning that you have turned on Site Quarantine.
Cross-site document blocking cross-site document blocking
Even when all cross-site pages are put into separate processes, pages can still legitimately request some cross-site subresources, such as images and JavaScript. To help prevent sensitive information from leaking this information, Site Isolation includes a “cross-site document blocking” feature that limits which network responses are delivered to the renderer process.
Even if all cross-site pages are placed in separate processes, pages can still legally request cross-site resources, such as images and JavaScript. To prevent sensitive information from being exposed from here, Site isolation includes a feature called Cross-site document blocking, which controls whether a network response can enter the rendering process.
A website can request two types of data from a server: “Documents” and “resources” Here, documents are HTML, XML, JSON and TXT files. A website is able to receive documents from its own domain or from other domains with permissive CORS headers. Resources include things like images, JavaScript, CSS and fonts. Resources can be included from any site.
Web sites can request two types of data from servers: “documents” and “resources.” By “documents” I mean HTML, XML, JSON, and TXT files. A web site can receive documents from the same domain, or from documents whose CORS headers are allowed across domains. “Resources” include images, JavaScript, CSS, and fonts that can be referenced by any site.
Prevents a process from receiving “documents” from other origins if:
- They have an HTML, XML, JSON, or text/plain MIME type, and
- They have either a “X-Content-Type-Options: Nosniff “HTTP response header, or a quick content analysis (” Sniffing”), confirm that the type is correct
- CORS doesn’t explicitly allow access to the document
Cross-site document blocking policies block the receipt of documents from other domains when:
- “Document” is HTML, XML, JSON, or
text/plainMIME type, and - Either the “document” response header has a “X-Content-type-options: nosniff” or the browser’s Quick Content analysis confirms that the Type is correct.
- Not explicitly allowed by CORS
Documents that are blocked by this policy are presented to the process as empty, although the request still happens in the background.
Documents blocked by this policy enter the process as blank, even though the request is actually in the background.
For example: Imagine an attacker creating an 
For example: imagine an attacker, he created an < img > tag, and this tag pointing to a JSON file containing sensitive data, such as < img SRC = “https://yourbank.com/balance.json” >. Without site isolation, the contents of the JSON file will enter the renderer’s memory, at which point the renderer will notice that it is not a correct image format and will abandon rendering it as an image. However, there is now a potential opportunity for Spectre to read the memory block. The cross-site document blocking policy prevents this JSON file from entering the memory of the renderer process because the cross-site document blocking function blocks it just by its MIME type.
According to user metrics, there are a lot of JavaScript and CSS files that are delivered with text/html or text/plainMIME types. To avoid blocking resources that are accidentally marked as documents, Chrome attempts to sniff the response to ensure the MIME type is correct. This sniffing is imperfect, so if you are sure that you are setting the correct Content-Type headers on your website, the Chrome team recommends adding the X-Content-Type-Options: nosniff header to all your responses.
As a result of the user data matrix, there are many JavaScript and CSS files that are transmitted as text/ HTML or TEXT /plain MIME types. To prevent blocking resources that are inadvertently flagged as document types, Chrome tries to sniff the response to ensure that the MIME type is correct. There are drawbacks to this approach, so if you’re sure all your resources have the correct content-type header, the Chrome team suggests adding an X-Content-Type-options: nosniffing header to all responses.
If you want to try cross-site document blocking, opt-in to Site Isolation as described above.
If you want to try cross-site document blocking, see the section “Site Isolation” above to turn it on.
SameSite cookies are the same as site cookies
Let’s go back to the example above: tag. SameSite cookies are a new attribute that specify that a cookie should only be attached to a request that originates from the same site, hence the name. Sadly, at the time of writing, only Chrome and Firefox 58+ support this attribute.
Back in the above example: < img SRC = “https://yourbank.com/balance.json” >. It only works if yourbank.com saves cookies that are automatically saved when users log in. Cookies are usually sent with all requests to the site that set them up — even if the request was initiated by a third party, such as above. SameSite is a new cookie property that specifies that a cookie should only be sent when a request is initiated by a page from the SameSite, hence its name. Unfortunately, at the time of this writing, only Chrome and Firefox 58+ support this property.
HTTPOnly and document.cookie
If your site’s cookies are only used server-side, not by client JavaScript, there are ways you can stop the cookie’s data from entering the renderer process. You can set the HTTPOnly cookie attribute, which explicitly prevents the cookie from being accessed through client side script on supported browsers, such as Chrome. If setting HTTPOnly isn’t possible, you can help limit the exposure of loading cookie data to the rendered process by not reading document.cookie unless absolutely necessary.
If your site’s cookies are only used on the server and not on the client, there are several ways to prevent cooike data from entering the rendering process. You can set cookies to the HTTPOnly attribute, which is supported by all browsers (such as Chrome), to explicitly prevent client scripts from accessing cookies. If HTTPOnly cannot be set, you also need to ensure that document.cookie is not read unless absolutely necessary to limit exposure to cookie data loading.
Open External Links Using rel=”noopener” to Open External Links
When you link to another page using target="_blank", the opened page has access to your window object, can navigate your page to a different URL, and without Site Isolation will be in the same process as your page. To better protect your page, links to external pages that open in a new window should always specify rel="noopener".
If you use target=”_blank” to link to other pages, the target page that opens can access your window object, navigate your page to another URL, and be in the same process as your page if there is no site isolation. So, to better protect your pages, you should always specify rel=”noopener” for external page links that need to open in a new window.
High-resolution timers
To exploit Meltdown or Spectre, an attacker needs to measure how long it takes to read a certain value from memory. For this, a reliable and accurate timer is needed.
To exploit Meltdown and Spectre, an attacker must measure how long it takes to read a value from memory. And this kind of measurement, must use a high reliable, high precision timer.
One API the web platform offers is performance.now() which is accurate to 5 microseconds. As a mitigation, all major browsers have decreased the resolution of performance.now() to make it harder to mount the attacks.
One of the apis provided by the Web platform is performance.now(), which can be accurate to 5 subtleties. To mitigate attacks, all browsers have reduced the accuracy of the API to make it a difficult entry point for attacks.
Another way to get a high-resolution timer is to use a SharedArrayBuffer. The buffer is used by a dedicated worker to increment a counter. The main thread reads this counter and uses that as a timer. For the time being browsers have decided to disable SharedArrayBuffer until other mitigations are in place.
Another way to get a high precision timer is to use SharedArrayBuffer. For example, add a count variable with a dedicated worker, and the main thread reads the variable as a timer. All browsers have decided to disable SharedArrayBuffer until other measures are in place.
V8
To exploit Spectre, a specifically crafted sequence of CPU instructions is needed. The V8 team has implemented mitigations for known attack proofs of concept, and is working on changes in TurboFan, their optimizing compiler, that make its generated code safe even when these attacks are triggered. However, these code generation changes may come at a performance penalty.
To take advantage of Spectre, you must have a carefully prepared sequence of CPU instructions. The V8 team has mitigated some of the known theoretical potential attacks and is working to make changes to TurboFan to optimize their compiler to ensure code generation is safe, even in the event of an attack. However, these code generation changes come with a performance cost.