专用网络访问：简介

Titouan Rigoudy
Titouan Rigoudy
Eiji Kitamura
Yifan Luo
Yifan Luo
GitHub

更新

  • 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 将分两个阶段推出此变更，以便让网站有时间发出通知 并进行相应的调整

  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 地址更私密。

<ph type="x-smartling-placeholder">
</ph> 当一个可用性更强的网络向某个 可用网络减少。 <ph type="x-smartling-placeholder">
</ph> 专用网络中公共、专用和本地网络之间的关系 访问权限 (CORS-RFC1918)

如需了解详情，请参阅反馈：适用于专用网络的 CORS (RFC1918)。

预检请求

背景

预检请求是由跨域资源共享 (CORS) 标准引入的机制， 先向目标网站请求权限，然后再发送 HTTP 请求 可能会引起副作用这可确保目标服务器理解 CORS 协议，并显著降低 CSRF 攻击的风险。

权限请求以具有特定 CORS 请求标头的 OPTIONS HTTP 请求的形式发送 用于描述即将到来的 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 攻击， 而不管请求模式，以及是否发出了响应内容， 提供给发起者使用

如果 目标 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 开始，如果检测到专用网络请求， 请求会提前发送如果此预检请求失败，则最终 请求仍会发送，但在开发者工具中会显示警告消息 问题面板。

Devtools 问题面板中显示失败预检请求警告。其中包括： 确保仅向允许专用网络的资源发出专用网络请求； 以及有关特定请求的详细信息以及列出的受影响资源

还可以在“网络”面板中查看和诊断受影响的预检请求：

开发者工具 Network 面板中本地主机的预检请求失败 给出 501 状态

如果您的请求在不触发任何 CORS 预检的情况下 专用网络访问规则，那么系统可能会在 网络面板，第一个面板一直显示为已失败。这是一个 已知 bug，则可以放心地忽略它。

在成功进行预检之前，出现虚假的预检请求 找到它

如需了解预检成功强制执行后会出现什么情况，您可以 传递以下命令行参数， 从 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 将扩展专用网络访问检查，以涵盖 Web Worker： 专用工作器、共享工作器和 Service Worker。我们暂定 Chrome 107 开始显示警告。

然后，Chrome 将扩展专用网络访问检查，以涵盖导航、 包括 iframe 和弹出式窗口我们暂定计划在 Chrome 108 中推出 显示警告。

在这两种情况下，我们会谨慎地继续进行类似的分阶段部署， ，以便为 Web 开发者留出调整和评估兼容性风险的时间。

致谢

Mark Olsen 的封面照片 不启动。