Meltdown/Spectre 在 Web 開發中的防範(中英）

原文連接(需越牆）： https://developers.google.com/web/updates/2018/02/meltdown-spectre

原文做者：Surma  最後更新時間： 2018-2-7

譯者：西樓聽雨

（轉載請註明出處）

Overview 引言

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 vulnerabilities have been named Spectre and Meltdown. What is Chrome doing to help keep the web secure, and what should web developers do for their own sites?

1月3號，Project Zero 揭露了在現代 CPU 中存在的一些漏洞，他們能夠容許進程讀取任意內存（最糟糕狀況）——包括那些自己不屬於它的內存。 這些漏洞被命名爲 Spectre 和 Meltdown。那麼，Chrome 該作些什麼來保障 Web 的安全呢？Web 開發者們又該爲本身的網站作些什麼呢？

TL; DR 結論（"太長，不看了"）

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.

做爲一名瀏覽網頁的用戶，你應該確保你操做系統以及瀏覽器時刻保持最新版本。另外，Chrome 的用戶能夠考慮把「站點隔離」打開。

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: nosniff header 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.

若是你是一名 Web 開發者，Chrome 團隊建議：

• 在任何可能的地方，經過設置 cookie 的 SameSite 和 HTTPOnly 屬性，並避免讀取 document.cookie，來防止 cookies 進入渲染進程的內存。
• 確保 MIME 類型正確，並對任何與特定用戶相關或包含敏感內容的 URL 指定一個X-Content-Type-Options: nosniff 響應頭，以此來爲那些開啓了站點隔離的用戶提供最大的跨站點阻隔好處。
• 啓用站點隔離，並讓 Chrome 團隊知曉這樣是否會給你的站點帶來一些問題。

If you are wondering why  these steps help, read on!

若是你對上面這些爲什們有用感興趣，請繼續往下讀！

The 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.

如今已經有不少對這些漏洞的各類解釋了，因此，我就再也不重複了。若是你對它們能夠被如何拿來利用感興趣，我推薦你看一下個人谷歌雲團隊的同事寫的這篇博客文章。

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.

Meltdown 和 Spectre 都潛在具有讓一個進程讀取本意不被容許讀取的內存的可能。而在 Chrome 中，有時來自不一樣站點的多個文檔是可能共享一個進程的。這種狀況可能會發生在，一個站點使用window.open 或者 <a href="..." target="_blank">，或者 iframes來打開另外一個站點的時候。（這樣的話，）若是某個網站含有特定於用戶的數據，那麼其餘站點就有機會利用這些新漏洞來讀取用戶數據。

Mitigations 緩解措施

There are multiple efforts the Chrome and V8 engineering team is deploying to mitigate this threat.

Chrome 和 V8 工程的團隊正在盡各類努力發佈部署，來緩解這種威脅。

Site Isolation 站點隔離

The impact of successfully exploiting Spectre can be greatly reduced by preventing sensitive data from ever sharing a process with attacker-controlled code. The Chrome team has been working on a feature to achieve this called 「Site Isolation」:

若是咱們能夠完全防止敏感數據與攻擊者控制的代碼所在的進程進行共享，那麼咱們就能夠極大的減輕 Spectre 被成功利用後的影響。Chrome 團隊已經在爲一項能夠實現這種效果的新特性而努力：

「Websites 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.」

「一般，在瀏覽器中，網站與網站之間是不能訪問對方的數據的……。偶爾，也會有安全性bug可能會嘗試繞過這些規則來攻擊其餘網站。……'站點隔離'提供了對製造這種攻擊發生的第二道防線，以此減輕其發生的可能。它確保了來自不一樣網站的頁面老是被置於不一樣的進程中，各自運行在一個限制其可訪問內容的沙盒內。「

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.

"站點隔離"目前尚未在默認狀況下開啓，由於如今還有一些已知的問題，並且 Chrome 團隊也但願對其進行儘量多的測試。做爲一名 Web 開發者，你應該把它開啓並檢查下站點是否仍然正常。假如你想如今就開啓，請打開 chrome://flags#enable-site-per-process(這個 flag）。若是開啓以後你發現某個站點不能正常工做，請填寫一個 bug 並說起你已經打開了"站點隔離"，以此給予咱們幫助。

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.

即使是把全部的跨站頁面置入分離的進程中，頁面仍然能夠合法地請求一些跨站的資源，例如，圖片和JavaScript。爲了防止敏感信息今後處暴露，「站點隔離」包含了一個叫作「跨站文檔阻隔」的特性，它能夠控制網絡響應是否能夠進入渲染進程。

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.

網站能夠從服務器請求兩種類型的數據：「文檔」和「資源」。在這裏所謂的「文檔」指的是 HTML，XML，JSON 和 TXT 文件。一個網站能夠接收來自同域下的文檔，也能夠接收來自跨域的 CORS 頭部爲容許的文檔。而所謂的「資源」則包含有圖片，JavaScript，CSS，字體，他們能夠被任何站點所引用。

The cross-site document blocking policy prevents a process from receiving 「documents」 from other origins if:

1. They have an HTML, XML, JSON, or text/plain MIME type, and
2. They have either a "X-Content-Type-Options: nosniff" HTTP response header, or a quick content analysis (「sniffing」) confirms that the type is correct
3. CORS doesn’t explicitly allow access to the document

跨站文檔阻隔政策會在如下狀況下阻隔來自其餘域下「文檔」的接收：

1. 「文檔」是 HTML，XML，JSON，或者 text/plain MIME 類型，且
2.  要麼「文檔」的響應頭部有一個 "X-Content-Type-Options: nosniff"，要麼在瀏覽器的快速內容分析中(「sniffing」)確認了類型的正確。
3.  沒有獲得 CORS 顯式地容許
   

Documents that are blocked by this policy are presented to the process as empty, although the request still happens in the background.

被這個政策阻隔的這些文檔會以空白的形式進入進程，雖然請求實際還在後臺進行。

For example: Imagine an attacker creating an <img> tag that includes a JSON file with sensitive data, like <img src="https://yourbank.com/balance.json">. Without Site Isolation, the contents of the JSON file would make it to the renderer process’s memory, at which point the renderer notices that it is not a valid image format and doesn’t render an image. With Spectre, however, there is now a way to potentially read that chunk of memory. Cross-site document blocking would prevent the contents of this file from ever entering the memory of the process the renderer is running in because the MIME type is blocked by cross-site document blocking.

例如：想象一個攻擊者，他建立了一個<img>標籤，而這個標籤指向了一個包含敏感數據的JSON文件，如<img src="https://yourbank.com/balance.json">。若是沒有站點隔離，那麼這個JSON文件的內容就會進入渲染進程的內存，此時渲染進程會注意到它不是一個正確的圖片格式，並放棄把它渲染爲一張圖片。然而，這對於 Spectre 來講，如今就有了一條能夠讀取這塊內存塊的潛在機會了。跨站文檔阻隔政策就能夠防止這個JSON文件進入渲染器進程的內存，由於僅經過它的 MIME 類型，跨站文檔阻隔功能就會將其阻隔。

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.

按照用戶數據矩陣的結果，有許多 JavaScript 和 CSS 文件是以 text/html 或者 text/plain MIME 類型來傳輸的。爲了防止哪些不經意被標誌爲了文檔類型的資源被阻隔，Chrome 會嘗試對響應進行嗅探，以此確保 MIME 類型是正確的。這種嘗試存在缺點，因此，若是你確定你全部的資源都設置了正確的 Content-Type 頭的話，Chrome 團隊建議再爲全部響應添加一個 X-Content-Type-Options: nosniff頭。

If you want to try cross-site document blocking, opt-in to Site Isolation as described above.

若是你也想嘗試一下跨站文檔阻隔，請看上面「站點隔離」一節來開啓它。

SameSite cookies 同站 cookie

Let’s go back to the example above: <img src="https://yourbank.com/balance.json">. This only works if yourbank.com has stored a cookie that automatically logs the user in. Cookies typically get sent for all requests to the website that sets the cookie — even if the request is made by a third party using an <img> 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.

回到上面的例子：<img src="https://yourbank.com/balance.json">。其實它只在 yourbank.com 保存了用戶登錄後會自動保存的 cookie 時才起做用。一般 cookie 都會伴隨着全部請求一塊兒發送給設置它的網站——即使請求是由第三方發起的，例如上面的 <img>。SameSite 是一個新的 cookie 屬性，它能夠指定一個 cookie 只在請求是由同一個站點的頁面發起的時候才伴隨發送，這也是它名字的由來。不過遺憾的時，在本文編寫的時間點，還只有 Chrome 和 Firefox 58+ 支持這個屬性。

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.

若是你網站的 cookie 只在服務端用到，客戶端沒有用到，那麼這有多種方式能夠防止 cooike 數據進入渲染進程。你能夠給 cookie 設置 HTTPOnly 屬性，它被全部瀏覽器所支持（如Chrome），這樣能夠顯式地防止客戶端腳本訪問 cookie。 若是沒法設置 HTTPOnly，你也只須要確保不讀取 document.cookie，除非絕對有必要， 以此來限制對加載 cookie 數據的時的暴露。

Open External Links Using rel="noopener"  使用 rel="noopener" 來打開外部連接

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".

若是你使用 target="_blank" 連接其餘頁面，那麼打開後的目標頁面是能夠訪問到你的 window 對象的，而後能夠把你的頁面導航到另一個URL，而且若是沒有站點隔離的話，這個頁面將會和你的頁面在同一個進程裏面。因此，爲了更好地保護你的頁面，對於須要在一個新窗口打開的外部頁面連接，你應該始終爲其指定 rel="noopener"。

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.

想要利用 Meltdown 和 Spectre，攻擊者必須測量出從內存讀取某個值的耗時。而這種測量，必須藉助一個高可靠、高精度的計時器。

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.

Web 平臺提供的其中一個 API 是 performance.now() ，它能夠精確到5微妙。爲了緩解攻擊，全部的瀏覽器都下降了這個 API 的精度，以使得它很難成爲攻擊的入口。

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.

另一種獲取高精度計時器的方式是使用 SharedArrayBuffer。例如，用一個專門的 worker 來增長一個計數變量，而後主線程讀取這個變量，（記錄讀取耗時），以此看成計時器。目前全部瀏覽器都已經決定準備禁用 SharedArrayBuffer，直到其餘措施到位。

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.

要利用 Spectre，必需要有一個精心準備的 CPU 指令序列。V8 團隊對一些已知的理論上可能的攻擊採起了緩解措施，也在努力對 TurboFan 作出改變，優化他們的編譯器，以此保證代碼的生成安全，即使是發生在攻擊的時候。不過，這些代碼生成的改變會帶來性能上的代價。