专用网络访问：简介

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

更新

• 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 会收集兼容性数据并与受影响最大的客户联系 。
   • 我们希望这与现有网站大致兼容。
   。
   警告：为了限制对尚不支持预检的网站造成的影响， 在 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 地址空间包含采用 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 响应标头 明确同意接下来的请求。

专用网络访问通道的新变化

预检请求引入了一对新的请求和响应标头：

• 已针对所有 PNA 预检请求设置 Access-Control-Request-Private-Network: true
• 必须为所有 PNA 预检响应设置 Access-Control-Allow-Private-Network: true

系统会为所有专用网络请求发送 PNA 预检请求， 而无论请求方法如何 mode。邮件 在 cors 模式以及 no-cors 和所有其他模式下，低于请求的值。这个 这是因为所有专用网络请求都可用于 CSRF 攻击， 而不管请求模式，以及是否发出了响应内容， 提供给发起者使用

注意：如果专用网络请求是在 cors 模式下发出的，那么 CORS 标头 除了预检响应之外，还要针对最终响应设置。

如果 目标 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

警告：服务器可以设置 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 预检的情况下 专用网络访问规则，那么系统可能会在 网络面板，第一个面板一直显示为已失败。这是一个 已知 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），以确保可安全允许请求。 通常，您应允许访问您控制的单个源。

警告：请提防不安全（非 https）源，因为它们未通过身份验证。路上 攻击者可能会伪装成任何此类来源！

您的服务器决定允许该请求后，就会做出响应 204 No Content（或 200 OK）与必要的 CORS 标头和新的 PNA 标头。这些头文件包括 Access-Control-Allow-Origin 和 Access-Control-Allow-Private-Network: true，以及所需的其他库。

如需了解具体场景，请参阅相关示例。

使用企业政策停用专用网络访问检查

如果您对用户拥有管理控制权，则可以停用“不公开” 使用以下任一政策检查网络访问权限：

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

有关详情，请参阅了解 Chrome 政策管理。

向我们提供反馈

如果您的网站托管在专用网络内，且该网络需要 公共网络，那么 Chrome 小组将非常关注您的反馈和使用案例。 若要告知我们，请在 crbug.com 上提交 Chromium 问题并将 将组件设为 Blink>SecurityFeature>CORS>PrivateNetworkAccess。

后续步骤

接下来，Chrome 将扩展专用网络访问检查，以涵盖 Web Worker： 专用工作器、共享工作器和 Service Worker。我们暂定 Chrome 107 开始显示警告。

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

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

致谢

Mark Olsen 的封面照片 不启动。