Chrome 重大更新，將限制 localhost 訪問？

Chrome 正在計劃禁止從非安全網(wǎng)站發(fā)起的專用網(wǎng)絡請求，目的是保護用戶免受針對專用網(wǎng)絡上的路由器和其他設備的跨站點請求偽造 (CSRF) 攻擊：

• 從 Chrome 94 開始阻止來自不安全公共網(wǎng)站的私有網(wǎng)絡請求。
• 在 Chrome 101 中結束的棄用試驗。
• 在 Chrome 92 中引入一些 Chrome 策略，允許托管的 Chrome 部署永久繞過棄用。

啥是專用網(wǎng)絡？

在互聯(lián)網(wǎng)的地址架構中，專用網(wǎng)絡是指遵守 RFC 1918（IPV4）和 RFC 4193（IPV6）規(guī)范，使用專用 IP 地址空間的網(wǎng)絡。私有 IP 無法直接連接互聯(lián)網(wǎng)，需要使用網(wǎng)絡地址轉換（Network Address Translator，NAT）或者代理服務器 （proxy server）來實現(xiàn)。

一般，我們在企業(yè)里搭建的局域網(wǎng)、家庭網(wǎng)絡里的局域網(wǎng)、你本地的 localhost ，都屬于專用網(wǎng)絡。

專用網(wǎng)絡訪問規(guī)范

專用網(wǎng)絡訪問規(guī)范（以前稱為 CORS-RFC1918）會限制網(wǎng)站向專用網(wǎng)絡上的服務器發(fā)送請求的能力。它只允許來自安全上下文（HTTPS）的此類請求。該規(guī)范還擴展了跨域資源共享 (CORS) 協(xié)議，因此網(wǎng)站現(xiàn)在必須要經(jīng)過專用網(wǎng)絡上的服務器授權會才能發(fā)送請求。

私有網(wǎng)絡請求是其目標服務器的 IP 地址比獲取請求發(fā)起者的 IP 地址更私有的請求。例如，從公共網(wǎng)站 ( https://example.com) 到私有網(wǎng)站 (http://router.local) 的請求，或從私有網(wǎng)站到 localhost 的請求。

我們在開發(fā)過程中，這幾種情況實際上是比較常見的，所以需要開發(fā)者提前試用并作出應對。

訪問 localhost

如果你的網(wǎng)站需要向 localhost 發(fā)出請求，那么你只需要將你的網(wǎng)站升級到 HTTPS。

混合內(nèi)容不會阻止以 http://localhost（或 http://127.*.*.*、http://[::1]）為目標的請求，即使是從安全上下文發(fā)出的。

請注意，這里有個坑，WebKit 引擎和基于它的瀏覽器（比如 Safari）這里并沒有遵循 W3C 混合內(nèi)容規(guī)范，上面這些請求會作為混合內(nèi)容并禁止訪問。它們也沒有實現(xiàn)專用網(wǎng)絡訪問，因此網(wǎng)站如果使用此類瀏覽器的客戶端，需要試用 HTTP 協(xié)議，此類瀏覽器仍允許向 localhost 發(fā)出請求。

訪問私有 IP

如果你的網(wǎng)站需要向私有 IP 地址上的目標服務器發(fā)出請求，那么簡單地將發(fā)起方網(wǎng)站升級到 HTTPS是行不通的?；旌蟽?nèi)容會阻止安全上下文通過明文 HTTP 發(fā)出請求，因此新獲得安全保護的網(wǎng)站仍會發(fā)現(xiàn)自己無法發(fā)出請求。有幾種方法可以解決這個問題：

將兩端都升級為HTTPS

這個方案難度有點大，因為 HTTPS 只會面向公共域名辦法，你需要先給你的私有 IP 注冊一個公共域名，然后配置 DNS 解析把公共域名指向這個私有 IP，最后再給域名配置 TLS 證書。

使用 WebTransport

這個方案不需要自己控制 DNS 解析，你需要在私有網(wǎng)絡上自己搭建一個 WebTransport 服務器。

WebTransport 是 WebRTC 體系下的一套瀏覽器API ，提供低延遲，client 和 server之間雙向通信的能力。

• WebTransport 提供基于 QUIC 和 HTTP3 實現(xiàn)的API ，自動獲得 QUIC 和 HTTP3本身的特性，比如應用層的擁塞，避免隊頭阻塞。
• 雙向通信的能力，多個傳輸通道復用一個連接的能力，能夠很好的替代 WebSocket。
• 提供發(fā)送/接受不可靠 UDP 的能力，這個是瀏覽器一直欠缺的能力。

重要的是，通過使用 WebTransport 的證書鎖定機制，你可以繞過缺少由受信任 CA 簽署的有效 TLS 證書的問題。

反向嵌入。

網(wǎng)站的框架可以從私有服務器獲取，然后從公共服務器(如CDN)獲取它的所有子資源(如 script 或 image)。這樣生成的網(wǎng)站可以向私有服務器發(fā)出請求，因為這些請求是同源的，它甚至可以向其他使用私有 ip 發(fā)出請求。

這個方案可以臨時用，官網(wǎng)所可能以后對這種情況也會有所限制。

CORS 預檢請求的變化

CORS 預檢請求是一個 HTTP OPTIONS 請求，它帶有一些 Access-Control-Request-* 標頭，表明后續(xù)請求的性質，例如是否允許跨域訪問。

專用網(wǎng)絡訪問規(guī)范 的第二部分是使用 CORS 預檢請求 來控制從安全上下文發(fā)起的專用網(wǎng)絡請求。即使請求是從安全上下文發(fā)起的，目標服務器也會被要求向發(fā)起者提供明確的授權，只有在授權成功時才會發(fā)送請求。

最后

大家趕快檢查一下自己負責的網(wǎng)站是否有專有網(wǎng)絡訪問的情況，有的話趕快處理起來吧～