私人網路存取權：推出預檢

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

更新

• 2022 年 7 月 7 日：更新目前狀態並新增 IP 位址空間定義。
• 2022 年 4 月 27 日：更新作業時間表公告。
• 2022 年 3 月 7 日：宣布在 Chrome 98 版中發現問題後復原的復原。

簡介

Chrome 將依據私人網路存取權 (PNA) 規格，淘汰從公開網站直接存取私人網路端點的功能。

針對子資源的任何私人網路要求，Chrome 會先向目標伺服器要求明確權限，再傳送 CORS 預檢要求。這項預檢要求會採用新的標頭 Access-Control-Request-Private-Network: true，而其回應必須具有對應的標頭 Access-Control-Allow-Private-Network: true。

這項措施旨在保護使用者不受針對路由器和其他透過私人網路使用的裝置進行的跨網站偽造要求 (CSRF) 攻擊。這些攻擊影響了數十萬名使用者，讓攻擊者將使用者重新導向至惡意伺服器。

推出計畫

Chrome 將分兩階段實施這項變更，讓網站有時間注意到變更，並據此調整。

1. 在 Chrome 104 中：

   • Chrome 實驗會在私人網路子資源要求之前傳送預檢要求。
   • 預檢失敗只會顯示開發人員工具中的警告，而不會對私人網路要求產生影響。
   • Chrome 會收集相容性資料，並聯繫最大的受影響網站。
   • 我們希望這種 API 可與現有的網站大致相容。
   警告：為限制不支援預檢的網站受到的影響，在 Chrome 104 中，逾時時間上限為 200 毫秒。限制只會在警告模式下套用。啟用強制執行模式後，系統會在 chrome://flags 中將「採用私人網路存取權預檢的結果」切換為「已啟用」，且預設限制為 5 秒，藉此移除特殊逾時限制。

2. 在 Chrome 113 中，最早：

   • 唯有在相容性資料指出變更安全無虞，且我們有必要時直接聯絡到變更的情況下，您才會開始進行這項程序。
   • Chrome 會強制預檢要求必須成功，否則要求失敗。
   • 淘汰試用期同時開始，允許受該階段影響的網站申請延長期限。試用期至少為 6 個月。

注意：我們稍早嘗試在 Chrome 98 和 Chrome 102 版中推出警告，之前在這篇網誌文章中宣布。在推出期間發現穩定性和相容性問題後，這項功能會復原。這些發現的問題已在 Chrome 104 版中修正。

什麼是私人網路存取權 (PNA)

私人網路存取權 (舊稱 CORS-RFC1918) 會限制網站向私人網路上的伺服器傳送要求的功能。

Chrome 已實作該規格的部分內容：自 Chrome 96 版起，只有安全環境才能提出私人網路要求。詳情請參閱先前的網誌文章。

這個規範也會擴充跨源資源共享 (CORS) 通訊協定，因此網站現在必須明確向私人網路上的伺服器要求授權，才能傳送任意要求。

重要字詞： 私人網路要求是指目標伺服器的 IP 位址比擷取要求啟動器時更加私密的要求。例如，從公開網站 (https://example.com) 向私人網站 (http://router.local) 發出的要求，或是從私人網站傳送至 localhost 的要求。

PNA 如何分類 IP 位址及識別私人網路

IP 位址分為三個 IP 位址空間： - public - private - local

本機 IP 位址空間包含的 IP 位址，屬於 IPv4 迴圈位址 (127.0.0.0/8)，如 RFC1122 的第 3.2.1.3 節或 RFC4291 第 2.5.3 節所定義。::1/128

私人 IP 位址空間包含僅在目前網路中意義的 IP 位址，包括 RFC1918 中定義的 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16，在 RFC3927 中定義的連結本機位址 169.254.0.0/16，以及 RFC4193 中定義的不重複本機 IPv6 單點傳播位址 fc00::/7 (如 RFC4193 定義)。fe80::/10RFC4291

「公開 IP 位址空間」包含先前未提及的所有其他位址。

相較於私人 IP 位址，本機 IP 位址的私密性比私人 IP 位址更加私密。

私人網路存取權 (CORS-RFC1918) 中公開、私人、區域網路之間的關係

如需瞭解詳情，請參閱需要意見回饋：私人網路的 CORS (RFC1918)。

預檢要求

背景

預檢要求是跨源資源共享 (CORS) 標準引進的機制，可在傳送可能副作用的 HTTP 要求之前，向目標網站要求權限。這可確保目標伺服器瞭解 CORS 通訊協定，並大幅降低 CSRF 攻擊的風險。

權限要求會以 OPTIONS HTTP 要求的形式傳送，其中包含特定的 CORS 要求標頭，說明接下來的 HTTP 要求。回應必須具有特定的 CORS 回應標頭，明確同意即將發出的要求。

私人網路存取權的新功能

預檢要求加入一組新的要求和回應標頭：

• 所有 PNA 預檢要求已設定 Access-Control-Request-Private-Network: true
• 所有 PNA 預檢回應都必須設定 Access-Control-Allow-Private-Network: true

無論要求方法和模式為何，系統都會針對所有私人網路要求，傳送 PNA 的預檢要求。系統會在 cors 模式以及 no-cors 和所有其他模式的要求之前，先傳送這些要求。這是因為所有私人網路要求都可用於 CSRF 攻擊 (無論要求模式為何)，以及叫用者是否可使用回應內容。

注意：如果私人網路要求是在 cors 模式下提出，那麼除了預檢回應之外，最終回應中還須設定 CORS 標頭。

如果目標 IP 位址比啟動器更能私密，系統也會針對相同來源要求傳送 PNA 的預檢要求。這與一般 CORS 不同，因為預檢要求僅適用於跨源要求。相同來源要求的預檢要求可以保護 DNS 重新繫結攻擊。

示例

可觀測的行為取決於要求的模式。

無 CORS 模式

假設 https://foo.example/index.html 嵌入 <img src="https://bar.example/cat.gif" alt="dancing cat"/>，而 bar.example 會解析為 192.168.1.1，這是符合 RFC 1918 的私人 IP 位址。

Chrome 會先傳送預檢要求：

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

伺服器必須回應以下內容，要求才能成功：

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

警告：伺服器可以設定 Access-Control-Allow-Origin: *，但這很危險，我們不建議這麼做。私人網路資源很少可供所有來源存取，因此設定這類標頭時可能會產生風險。

接著，Chrome 會傳送實際要求：

HTTP/1.1 GET /cat.gif
...

伺服器可正常回應的目標。

CORS 模式

假設 https://foo.example/index.html 執行以下程式碼：

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

再次說，假設 bar.example 解析為 192.168.1.1。

Chrome 會先傳送預檢要求：

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

伺服器必須回應以下內容，要求才能成功：

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

接著，Chrome 會傳送實際要求：

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

伺服器可依據一般 CORS 規則回應，如下所示：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

如何判斷網站是否受到影響

自 Chrome 104 版本起，如果偵測到私人網路要求，系統會預先傳送預檢要求。如果這項預檢要求失敗，系統仍會傳送最終要求，但開發人員工具面板中會顯示警告。

您也可以在網路面板中查看及診斷受影響的預檢要求：

如果您的要求在沒有私人網路存取權規則的情況下觸發一般 CORS 預檢，則網路面板中可能會顯示兩項預檢，而且第一個測試一直顯示失敗。這是已知錯誤，您可以放心忽略該錯誤。

如要查看預檢成功後會發生什麼情況，從 Chrome 第 98 版開始，您可以傳遞下列指令列引數：

--enable-features=PrivateNetworkAccessRespectPreflightResults

任何失敗的預檢要求都會導致擷取失敗。這可讓您測試網站在推出計畫的第二階段後，是否能正常運作。診斷錯誤的方式和使用上述開發人員工具面板的警告方法相同。

網站受到影響時的處理方式

當 Chrome 104 版推出這項變更時，應該不會造成任何網站故障。不過，我們極力建議您更新受影響的要求路徑，確保網站能正常運作。

您有兩項解決方案：

1. 在伺服器端處理預檢要求
2. 使用企業政策停用 PNA 檢查

在伺服器端處理預檢要求

更新所有受影響擷取作業的目標伺服器，以處理 PNA 預檢要求。首先，針對受影響的路徑實作標準 CORS 預檢要求的支援。然後新增兩個新回應標頭的支援。

當伺服器收到預檢要求 (包含 CORS 標頭的 OPTIONS 要求) 時，伺服器應檢查是否存在 Access-Control-Request-Private-Network: true 標頭。如果要求中有這個標頭，伺服器應檢查 Origin 標頭、要求路徑以及任何其他相關資訊 (例如 Access-Control-Request-Headers)，確保要求安全無虞。一般而言，您應授予控制項中單一來源的存取權。

警告：請特別留意不安全的來源 (非 https)，因為來源未經驗證。路徑上攻擊者可能會偽裝成任何這類來源！

伺服器決定允許要求後，應以必要的 CORS 標頭和新的 PNA 標頭回應 204 No Content (或 200 OK)。這些標頭包括 Access-Control-Allow-Origin 和 Access-Control-Allow-Private-Network: true，以及其他需要的標頭。

如要瞭解具體情況，請參閱示例。

使用企業政策停用私人網路存取權檢查功能

如果您有使用者的管理控制權，可以使用下列任一政策停用私人網路存取權檢查：

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

詳情請參閱「瞭解 Chrome 政策管理」。

提供意見

如果您將網站託管於私人網路，且該網路會預期來自公用網路的要求，Chrome 團隊很樂意提供意見和用途。請在 crbug.com 向 Chromium 回報問題，並將元件設為 Blink>SecurityFeature>CORS>PrivateNetworkAccess。

後續步驟

接下來，Chrome 將擴充私人網路存取權檢查範圍，以便支援網路工作站：專用工作站、共用工作站和服務工作站。我們目前正打算讓 Chrome 107 版開始顯示警告。

然後，Chrome 將擴充私人網路存取權檢查範圍，涵蓋導覽作業，包括 iframe 和彈出式視窗。我們目前正打算讓 Chrome 108 版開始顯示警告。

無論是哪種情況，我們都會謹慎進行類似的階段推出作業，讓網頁開發人員有時間調整及預估相容性風險。

特別銘謝

Mark Olsen 在 Unsplash 上提供的封面相片。