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

Titouan Rigoudy
Titouan Rigoudy
Eiji Kitamura
Yifan Luo
Yifan Luo
GitHub

更新

  • 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 會收集相容性資料，並聯絡受訪最大的受影響國家/地區 網站。
    • 我們期望這項工具能與現有網站廣泛相容。
    ，瞭解如何調查及移除這項存取權。

  2. Chrome 113 最早版本：

    • 只有在相容性資料指出 確保變更安全無虞，我們會在必要時直接與您聯絡。
    • Chrome 強制執行預檢要求必須成功，否則會失敗 要求。
    • 淘汰試用期自 允許受到這個階段影響的網站 時間額外資訊試用期至少為 6 個月。
，瞭解如何調查及移除這項存取權。

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

私人網路存取權 (先前稱為 CORS-RFC1918) 會限制網站向私密伺服器傳送要求的功能 更是如此

Chrome 已導入此規格的一部分：自 Chrome 96 版起， 安全環境可發出私人網路要求請參閱 上一篇網誌文章。

這項規格也擴充了跨來源資源分享 (CORS) 通訊協定，因此網站現在必須明確向伺服器請求授權 再允許傳送任意要求。

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

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

「本機 IP 位址空間」包含 IPv4 或 IP 位址。 RFC1122 第 3.2.1.3 節中定義的回送位址 (127.0.0.0/8) RFC4291 的第 2.5.3 節中定義的「IPv6 回送位址」(::1/128)。

「私人 IP 位址空間」包含特定 IP 位址， 目前網路中，包括 10.0.0.0/8、172.16.0.0/12 和 RFC1918 中定義的 192.168.0.0/16， RFC3927 中定義的連結本機位址 169.254.0.0/16， 在 RFC4193 中定義的不重複本機 IPv6 單點傳播位址 fc00::/7， RFC4291 第 2.5.6 節中定義的連結本機 IPv6 單點傳播位址 fe80::/10 以及 IPv4 對應的 IPv6 位址，而對應的 IPv4 位址本身為私人位址。

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

系統會將本機 IP 位址視為私密 IP 位址的私人 IP 位址， 都會視為比公開 IP 位址更加私密。

如果有更多可用的網路傳送要求給 較不可用的網路
私人網路中公開、私人區域網路之間的關係 存取權 (CORS-RFC1918)

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

預檢要求

背景

預檢要求是跨源資源共享 (CORS) 標準所導入的機制 先向目標網站要求權限，再傳送 HTTP 要求 瞭解推辭原因的技巧這可確保目標伺服器 CORS 通訊協定，並大幅降低 CSRF 攻擊的風險。

權限要求會以 OPTIONS HTTP 要求的形式傳送，包含特定 CORS 要求標頭 說明即將推出的 HTTP 要求回應必須包含特定的 CORS 回應標頭 明確同意下一個要求。

代表 CORS 預檢的序列圖。OPTIONS HTTP 要求傳送到目標，因此會傳回 200 OK接著 CORS 要求標頭傳送，並傳回 CORS 回應標頭

私人網路存取權的新功能

系統會為預檢要求引入一對新的要求和回應標頭：

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

PNA 的預檢要求會送交所有私人網路要求， 無論要求方法為何 mode。代表系統傳送 在 cors 模式和 no-cors 以及所有其他模式下，系統將優先處理要求。這個 因為所有私人網路要求都可用於 CSRF 攻擊 無論要求模式為何，以及是否在要求的情況下 僅限發起人使用

同源請求也會傳送 PNA 預檢要求 (如果 目標 IP 位址比發起者更為私密。這不同於一般 CORS，其中預檢要求僅適用於跨源要求。預檢 抵禦同源要求 DNS 重新繫結攻擊。

範例

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

No-CORS 模式

說出 https://foo.example/index.html 個嵌入項目 <img src="https://bar.example/cat.gif" alt="dancing cat"/>和 bar.example 會解析為 192.168.1.1，依據 RFC 1918。

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

接著，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 版開始，如果偵測到私人網路要求，就會進行預檢 提前傳送要求如果這項預檢要求失敗， 傳送要求，但開發人員工具中會顯示警告訊息 問題面板。

開發人員工具問題面板中的預檢要求失敗警告。這包括： 確保私人網路要求只會傳送至允許這類要求的資源 以及特定要求的詳細資料和受影響的資源

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

localhost 的開發人員工具網路面板中的預檢要求失敗 則為 501 狀態

如果您的要求觸發一般 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)，確認允許請求安全無虞。 通常，您應該要允許控制項存取單一來源。

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

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

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

如果您有使用者的管理控制權，就可以停用「私人」 使用下列其中一項政策進行網路存取檢查：

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

提供意見

如果您代管的網站位於會預期 Chrome 團隊很期待聽到您的意見和用途。 請前往 crbug.com 向 Chromium 提交問題告訴我們，然後 將元件設為 Blink>SecurityFeature>CORS>PrivateNetworkAccess

後續步驟

接下來，Chrome 將擴大私人網路存取權檢查的範圍 網路工作站： 共用工作站、共用工作站和服務工作站我們會暫時鎖定這個目標 Chrome 107 版本開始顯示警告。

再者，Chrome 會將私人網路存取權的檢查範圍擴大至涵蓋導覽範圍， 包括 iframe 和彈出式視窗我們會暫定 Chrome 108 版本優先 目前顯示警告。

無論是哪種情況，我們會謹慎地採取類似的階段推出做法 ，讓網頁程式開發人員有時間調整及預估相容性風險。

特別銘謝

開啟 Mark Olsen 的封面相片 Unsplash。