更新
- 2022 年 7 月 7 日:更新了当前状态并添加了 IP 地址空间定义。
- 2022 年 4 月 27 日:更新了时间表。
- 2022 年 3 月 7 日:宣布在 Google Cloud 中发现问题后 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 地址更私密。
<ph type="x-smartling-placeholder">![当一个可用性更强的网络向某个
可用网络减少。](https://developer.chrome.com/static/blog/private-network-access-preflight/image/requests-are-private-a-m-009fa2902388e.jpg?authuser=1&hl=zh-cn)
如需了解详情,请参阅反馈:适用于专用网络的 CORS (RFC1918)。
预检请求
背景
预检请求是由跨域资源共享 (CORS) 标准引入的机制, 先向目标网站请求权限,然后再发送 HTTP 请求 可能会引起副作用这可确保目标服务器理解 CORS 协议,并显著降低 CSRF 攻击的风险。
权限请求以具有特定 CORS 请求标头的 OPTIONS
HTTP 请求的形式发送
用于描述即将到来的 HTTP 请求响应必须包含特定的 CORS 响应标头
明确同意接下来的请求。
专用网络访问通道的新变化
预检请求引入了一对新的请求和响应标头:
- 已针对所有 PNA 预检请求设置
Access-Control-Request-Private-Network: true
- 必须为所有 PNA 预检响应设置
Access-Control-Allow-Private-Network: true
系统会为所有专用网络请求发送 PNA 预检请求,
而无论请求方法如何
mode。邮件
在 cors
模式以及 no-cors
和所有其他模式下,低于请求的值。这个
这是因为所有专用网络请求都可用于 CSRF 攻击,
而不管请求模式,以及是否发出了响应内容,
提供给发起者使用
如果 目标 IP 地址比发起者更私密。这与常规的 CORS(预检请求仅适用于跨源请求)。预检 针对同源请求的 DNS 重新绑定攻击。
示例
可观察的行为取决于 请求的模式。
无 CORS 模式
说 https://foo.example/index.html
嵌入
<img src="https://bar.example/cat.gif" alt="dancing cat"/>
和
bar.example
将解析为 192.168.1.1
,这是一个专用 IP 地址,
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 预检的情况下 专用网络访问规则,那么系统可能会在 网络面板,第一个面板一直显示为已失败。这是一个 已知 bug,则可以放心地忽略它。
如需了解预检成功强制执行后会出现什么情况,您可以 传递以下命令行参数, 从 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 将扩展专用网络访问检查,以涵盖 Web Worker: 专用工作器、共享工作器和 Service Worker。我们暂定 Chrome 107 开始显示警告。
然后,Chrome 将扩展专用网络访问检查,以涵盖导航、 包括 iframe 和弹出式窗口我们暂定计划在 Chrome 108 中推出 显示警告。
在这两种情况下,我们会谨慎地继续进行类似的分阶段部署, ,以便为 Web 开发者留出调整和评估兼容性风险的时间。
致谢
Mark Olsen 的封面照片 不启动。