提供意見回饋：私人網路的 CORS (RFC1918)

降低用戶端內部網路上的裝置和伺服器意外暴露於整個網際網路的風險。

Eiji Kitamura

惡意網站向私人網路託管的裝置和伺服器發出要求，這類威脅由來已久。舉例來說，攻擊者可能會變更無線路由器設定，發動Man-in-the-Middle攻擊。CORS-RFC1918 提案建議在瀏覽器上預設封鎖這類要求，並要求內部裝置選擇接收來自公開網際網路的要求。

為瞭解這項異動對網路生態系統的影響，Chrome 團隊正在徵求為私人網路建構伺服器的開發人員提供意見。

現狀有什麼問題嗎？

許多網頁伺服器都在私人網路中執行，無線路由器、印表機、內部網路網站、企業服務和物聯網 (IoT) 裝置只是其中一部分。這些伺服器可能看似比公開伺服器安全，但攻擊者可以利用網頁做為 Proxy 濫用這些伺服器。舉例來說，惡意網站可能會嵌入網址，只要受害者在啟用 JavaScript 的瀏覽器中查看該網址，系統就會嘗試變更受害者家用寬頻路由器上的 DNS 伺服器設定。這類攻擊稱為「路過式網路釣魚」，2014 年就曾發生過。 攻擊者變更了超過 30 萬個無線路由器中的 DNS 設定，將使用者重新導向惡意伺服器，藉此發動攻擊。

CORS-RFC1918

為防範類似攻擊，網路社群正在導入 CORS-RFC1918，也就是專為 RFC1918 中定義的私人網路設計的跨來源資源共用 (CORS)。

實作 CORS 的瀏覽器會檢查目標資源，確認是否可從其他來源載入。視複雜程度而定，這項作業可透過內嵌的額外標頭說明存取權，或使用稱為「預檢要求」的機制完成。詳情請參閱「跨源資源共享」。

根據 CORS-RFC1918，瀏覽器預設會封鎖透過私人網路載入資源，但伺服器透過 CORS 和 HTTPS 明確允許的資源除外。向這些資源發出要求的網站必須傳送 CORS 標頭，而伺服器也必須傳送相應的 CORS 標頭，明確表示接受跨來源要求。(確切的 CORS 標頭仍在開發階段。)

我們會要求這類裝置或伺服器的開發人員執行兩項操作：

  • 請確認向私人網路傳送要求的網站是透過 HTTPS 提供服務。
  • 設定伺服器支援 CORS-RFC1918，並以預期的 HTTP 標頭回應。

哪些類型的要求會受到影響？

受影響的請求包括：

  • 從公用網路向私人網路傳送的要求
  • 私人網路向區域網路傳送的要求
  • 從公用網路傳送至區域網路的要求

私人網路 目的地會解析為 RFC1918 第 3 節中定義的私人位址空間 (IPv4)、對應 IPv4 的 IPv6 位址 (對應的 IPv4 位址本身為私人位址)，或 ::1/128、2000::/3 和 ff00::/8 子網路以外的 IPv6 位址。

本機網路 目的地會解析為 IPv4 RFC1122 第 3.2.1.3 節定義的「迴路」空間 (127.0.0.0/8)、IPv4 RFC3927 定義的「連結本機」空間 (169.254.0.0/16)、IPv6 RFC4193 第 3 節定義的「專屬本機位址」前置字元 (fc00::/7)，或是 IPv6 RFC4291 第 2.5.6 節定義的「連結本機」前置字元 (fe80::/10)。

公用網路 所有其他網路。

CORS-RFC1918 中的公用、私人和本機網路關係
CORS-RFC1918 中公用、私人和本機網路之間的關係。

Chrome 啟用 CORS-RFC1918 的計畫

Chrome 會分兩個步驟導入 CORS-RFC1918：

步驟 1：只允許 HTTPS 網頁要求私人網路資源

Chrome 87 新增了旗標，規定公開網站向私人網路資源發出要求時，必須使用 HTTPS。如要啟用，請前往 about://flags#block-insecure-private-network-requests。開啟這項標記後，系統會封鎖 HTTP 網站對私人網路資源的所有要求。

從 Chrome 88 開始，系統會在控制台中將 CORS-RFC1918 錯誤回報為 CORS 政策錯誤。

控制台會將 CORS-RFC1918 錯誤回報為 CORS 政策錯誤。
CORS-RFC1918 錯誤會回報為控制台中的 CORS 政策錯誤。

在 Chrome 開發人員工具的「網路」面板中，勾選「已封鎖的要求」核取方塊，即可專注於已封鎖的要求：

網路面板也會將 CORS-RFC1918 錯誤回報為 CORS 錯誤。
CORS-RFC1918 錯誤也會在「網路」面板中回報為 CORS 錯誤。

在 Chrome 87 中，CORS-RFC1918 錯誤只會在開發人員工具控制台中回報為 ERR_INSECURE_PRIVATE_NETWORK_REQUEST。

您可以使用這個測試網站自行測試。

步驟 2：使用特殊標頭傳送預檢要求

日後，每當公開網站嘗試從私人或本機網路擷取資源時，Chrome 會在實際要求之前傳送預檢要求。

除了其他 CORS 要求標頭外，要求也會包含 Access-Control-Request-Private-Network: true 標頭。這些標頭會識別提出要求的來源，以便進行精細的存取控管。伺服器可以傳送 Access-Control-Allow-Private-Network: true 標頭，明確指出授予資源存取權。

歡迎提供意見

如果您在私人網路中代管網站，且預期會收到來自公開網路的要求，Chrome 團隊很想聽取您的意見和瞭解您的用途。你可以採取以下兩種做法：

  • 前往 about://flags#block-insecure-private-network-requests，開啟標記，然後查看網站是否如預期將要求傳送至私有網路資源。
  • 如有任何問題或意見回饋，請前往 crbug.com 回報問題，並將元件設為 Blink>SecurityFeature>CORS>RFC1918。

意見回饋範例

無線路由器會透過 HTTP 提供相同私人網路的管理網站。如果嵌入管理網站的網站需要 HTTPS，就會出現複合型內容。在封閉式網路中，是否應在管理網站上啟用 HTTPS？

這正是 Chrome 需要的意見回饋。請前往 crbug.com 回報問題，並說明具體用途。Chrome 很期待收到您的意見。