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

降低客戶內部網路中裝置和伺服器意外暴露在網路上的風險。

Eiji Kitamura

惡意網站向私人網路中託管的裝置和伺服器發出請求，一直都是威脅。例如，攻擊者可能會變更無線路由器的設定，藉此啟用Man-in-the-Middle攻擊。CORS-RFC1918 建議在瀏覽器上預設封鎖這類要求，並要求內部裝置選擇接受來自公開網際網路的要求。

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

現狀有什麼問題嗎？

許多網路伺服器是在私人網路中執行，包括無線路由器、印表機、內部網路網站、企業服務以及物聯網 (IoT) 裝置。看起來可能比對外暴露在更安全的環境中，不過攻擊者可能會濫用網頁做為 Proxy，藉此濫用這些伺服器。舉例來說，惡意網站可以嵌入一個網址，當受害者 (在啟用 JavaScript 的瀏覽器) 上查看該網址時，會嘗試在受害者的家用寬頻路由器上變更 DNS 伺服器設定。這類攻擊稱為「偷駕車」，並在 2014 年發生。改變了 DNS 設定並允許攻擊者將使用者重新導向至惡意伺服器，藉此入侵超過 30 萬個易受攻擊的無線路由器。

CORS-RFC1918

為減輕類似攻擊的威脅，網路社群推出了 CORS-RFC1918，跨源資源共享 (CORS)：適用於 RFC1918 中定義的私人網路。

採用 CORS 執行 CORS 檢查的瀏覽器，不論是否能從其他來源載入。這種做法可以是內嵌提供存取權的額外標頭，或是利用稱為預檢要求的機制 (視複雜度而定)。詳情請參閱跨源資源共享。

使用 CORS-RFC1918 時，瀏覽器預設會封鎖透過私人網路載入資源，但伺服器使用 CORS 和 HTTPS 明確允許的資源除外。對這些資源發出要求的網站需要傳送 CORS 標頭，而伺服器需要透過對應的 CORS 標頭回應，明確指出其接受跨源要求。(確切的 CORS 標頭仍處於開發階段)。

此類裝置或伺服器的開發人員應執行以下兩項行動：

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

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

受影響的要求包括：

  • 從公用網路向私人網路發出的要求
  • 從私人網路向區域網路發出的要求
  • 從公用網路向區域網路發出的要求

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

本機網路 這個目的地會解析為 IPv4 第 3.2.1.3 節定義的「loopback」空間 (127.0.0.0/8)，也就是 IPv4 的「連結本機」空間 (169.254.0.0/16)，定義於 RFC3927 的 RFC3927 中，IP419 或 IPv1 的「不重複的本機位址」前置字串 (fc00::/7)，RFC1122RFC4193fe80::/10RFC4291

公用網路 所有其他網路。

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 政策錯誤。
在 Console 中，CORS-RFC1918 錯誤會回報為 CORS 政策錯誤。

在 Chrome 開發人員工具的「Network」面板中，您可以啟用「Block requests」核取方塊，專注於封鎖的要求：

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 非常樂意傾聽你的想法。

主頁橫幅由 Stephen Philips 透過 Unsplash 提供的。