更新
- 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 會分兩階段推出這項異動,讓網站有時間察覺 並據此做出調整
在 Chrome 104 中:
- 透過私人網路傳送預檢要求,藉此執行 Chrome 實驗功能 子資源要求。
- 預檢失敗只會在開發人員工具中顯示警告,如果沒有其他錯誤 以及限制私人網路要求
- Chrome 會收集相容性資料,並聯絡受訪最大的受影響國家/地區 網站。
- 我們期望這項工具能與現有網站廣泛相容。
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 位址更加私密。
![如果有更多可用的網路傳送要求給
較不可用的網路](https://developer.chrome.com/static/blog/private-network-access-preflight/image/requests-are-private-a-m-009fa2902388e.jpg?authuser=7&hl=zh-tw)
詳情請參閱需要的意見回饋:私人網路 (RFC1918) 的 CORS。
預檢要求
背景
預檢要求是跨源資源共享 (CORS) 標準所導入的機制 先向目標網站要求權限,再傳送 HTTP 要求 瞭解推辭原因的技巧這可確保目標伺服器 CORS 通訊協定,並大幅降低 CSRF 攻擊的風險。
權限要求會以 OPTIONS
HTTP 要求的形式傳送,包含特定 CORS 要求標頭
說明即將推出的 HTTP 要求回應必須包含特定的 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 版開始,如果偵測到私人網路要求,就會進行預檢 提前傳送要求如果這項預檢要求失敗, 傳送要求,但開發人員工具中會顯示警告訊息 問題面板。
您也可以透過網路面板查看及診斷受影響的預檢要求:
如果您的要求觸發一般 CORS 預檢,且沒有 私人網路存取權規則,那麼在 但第一個顯示為失敗這是 已知錯誤,可以放心忽略。
如要查看系統強制執行預檢之後會發生什麼事 傳送下列指令列引數 從 Chrome 98 版開始:
--enable-features=PrivateNetworkAccessRespectPreflightResults
任何失敗的預檢要求都會導致擷取失敗。這樣一來 測試你的網站能否在 推出計畫的第二階段。錯誤可於 與使用上述開發人員工具面板的警告相同
網站受影響時的處理方式
這項異動在 Chrome 104 中推出時,應該不會有任何破壞 網站。不過,我們強烈建議您將受影響的要求路徑更新為 確保網站能持續正常運作
我們提供兩種解決方案:
- 在伺服器端處理預檢要求
- 使用企業政策停用 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。