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

降低客戶內部網路中裝置和伺服器不慎曝露於網路的風險。

Eiji Kitamura

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

為瞭解這項異動對網路生態系統的影響，Chrome 團隊希望能收到為私人網路建構伺服器的開發人員提供的意見回饋。

現狀有什麼問題嗎？

許多網路伺服器都會在私人網路中執行，其中包括無線路由器、印表機、內部網路網站、企業服務和物聯網 (IoT) 裝置。這些伺服器看似比公開伺服器更安全，但攻擊者可以利用網頁當作 Proxy，濫用這些伺服器。舉例來說，惡意網站可以嵌入網址，當受害者 (在支援 JavaScript 的瀏覽器上) 瀏覽該網址時，該網址會嘗試變更受害者家中寬頻路由器的 DNS 伺服器設定。這種攻擊稱為「Drive-By Pharming」，於 2014 年發生。攻擊者變更了超過 300,000 個易受攻擊的無線路由器的 DNS 設定，並將使用者重新導向至惡意伺服器。

CORS-RFC1918

為降低類似攻擊的威脅，網路社群推出了 CORS-RFC1918，這是專為 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 位址。

本機網路：解析為「loopback」空間 (127.0.0.0/8) 的目的地，如 RFC1122 的 IPv4 3.2.1.3 節所定義；解析為「link-local」空間 (169.254.0.0/16) 的目的地，如 RFC3927 的 IPv4 3.2.1.3 節所定義；解析為「Unique Local Address」前置字串 (fc00::/7) 的目的地，如 RFC4193 的 IPv6 3 節所定義；或解析為「link-local」前置字串 (fe80::/10) 的目的地，如 RFC4291 的 IPv6 2.5.6 節所定義。

公用網路 其他所有網路。

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 開發人員工具的「網路」面板中，您可以啟用「Blocked Requests」核取方塊，將焦點放在已封鎖的要求：

CORS-RFC1918 錯誤也會在「Network」面板中以 CORS 錯誤的形式回報。
CORS-RFC1918 錯誤也會在「Network」面板中回報為 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 上提供。