需要反馈：专用网络的 CORS (RFC1918)

降低与客户端内部网络上的设备和服务器意外暴露给整个网络相关的风险。

Eiji Kitamura

恶意网站向专用网络上托管的设备和服务器发出请求长期以来一直是一种威胁。例如，攻击者可能会更改无线 路由器的配置以启用 Man-in-the-Middle 攻击。CORS-RFC1918 是一项提案，旨在默认情况下在浏览器上阻止此类请求，并要求内部设备选择接受来自公共互联网的请求。

为了解此项变更对 Web 生态系统的影响，Chrome 团队正在征求为专用网络构建服务器的开发者的反馈。

现状有什么问题？

许多 Web 服务器都在专用网络中运行，例如无线路由器、打印机、内网网站、企业服务和物联网 (IoT) 设备。 它们似乎比暴露给公众的服务器更安全，但攻击者可以使用网页作为代理来滥用这些服务器。例如，恶意网站可以嵌入一个网址，当受害者（在启用 JavaScript 的浏览器上）仅查看该网址时，该网址会尝试更改受害者家庭宽带路由器上的 DNS 服务器设置。这种类型的攻击称为 "Drive-By Pharming"， 它发生在 2014 年。 超过 30 万个易受攻击的无线路由器遭到攻击，其 DNS 设置被更改，从而允许攻击者将用户重定向到恶意服务器。

CORS-RFC1918

为了降低类似攻击的威胁，Web 社区推出了 CORS-RFC1918，即专门针对 RFC1918 中定义的专用网络的跨源资源共享 (CORS)。

实现 CORS 的浏览器会检查目标资源是否可以从不同的来源加载。这是通过内嵌描述访问权限的额外标头或使用一种称为预检请求的机制来实现的，具体取决于复杂性。如需了解详情，请参阅跨源资源共享 。

借助 CORS-RFC1918，浏览器默认会阻止 通过专用网络加载资源，但服务器使用 CORS 并通过 HTTPS 明确允许的资源除外。向这些资源发出请求的网站需要发送 CORS 标头，并且服务器需要通过使用相应的 CORS 标头进行响应来明确声明它接受非同源请求。（确切的 CORS 标头 仍在开发中。）

此类设备或服务器的开发者将被要求执行以下两项操作：

  • 确保向专用网络发出请求的网站通过 HTTPS 提供服务。
  • 设置服务器以支持 CORS-RFC1918，并使用预期的 HTTP 标头进行响应。

哪些类型的请求会受到影响？

受影响的请求包括：

  • 从公共网络到专用网络的请求
  • 从专用网络到本地网络的请求
  • 从公共网络到本地网络的请求

专用网络 解析为 IPv4 中 RFC1918 第 3 节中定义的专用地址空间的目标位置、映射的 IPv4 地址本身为专用的 IPv4 映射 IPv6 地址，或 ::1/128、2000::/3 和 ff00::/8 子网之外的 IPv6 地址。

本地网络 解析为 IPv4 中 RFC1122 的第 3.2.1.3 节中定义的“环回”空间 (127.0.0.0/8)、IPv4 中 RFC3927 中定义的“链路本地”空间 (169.254.0.0/16)、IPv6 中 RFC4193 的第 3 节中定义的“唯一本地地址”前缀 (fc00::/7)，或 IPv6 中 RFC4291 的第 2.5.6 节中定义的“链路本地”前缀 (fe80::/10) 的目标位置。

公共网络 ：所有其他网络。

CORS-RFC1918 中公共网络、专用网络和本地网络之间的关系
CORS-RFC1918 中公共网络、专用网络和本地网络之间的关系。

Chrome 启用 CORS-RFC1918 的计划

Chrome 将分两步推出 CORS-RFC1918：

第 1 步：仅允许来自 HTTPS 网页的请求访问专用网络资源

Chrome 87 添加了一个标志，该标志强制要求向专用网络资源发出请求的公共网站必须使用 HTTPS。您可以前往 about://flags#block-insecure-private-network-requests 以启用该标志。启用此标志后，来自 HTTP 网站的任何对专用网络资源的请求都将被阻止。

从 Chrome 88 开始，CORS-RFC1918 错误将在控制台中报告为 CORS 政策错误。

CORS-RFC1918 错误将在控制台中报告为 CORS 政策错误。
CORS-RFC1918 错误将在控制台中报告为 CORS 政策错误。

在 Chrome 开发者工具的网络 面板中，您可以选中已屏蔽的请求 复选框，以重点关注已屏蔽的请求：

CORS-RFC1918 错误也会在“网络”面板中报告为 CORS 错误。
CORS-RFC1918 错误还将在网络 面板中报告为 CORS 错误。

在 Chrome 87 中，CORS-RFC1918 错误仅在开发者工具控制台中报告为 ERR_INSECURE_PRIVATE_NETWORK_REQUEST。

您可以使用此测试网站自行尝试。

第 2 步：发送带有特殊标头的预检请求

未来，每当公共网站尝试从专用网络或本地网络提取资源时，Chrome 都会在实际请求之前发送预检请求。

除了其他 CORS 请求标头之外，该请求还将包含 Access-Control-Request-Private-Network: true 标头。除其他事项外，这些标头还会标识发出请求的来源，从而实现精细的访问权限控制。服务器可以使用 Access-Control-Allow-Private-Network: true 标头进行响应，以明确表明它授予对资源的访问权限。

欢迎提供反馈

如果您在专用网络中托管网站，并且该网站需要接受来自公共网络的请求，Chrome 团队很想了解您的反馈和使用情形。您可以执行以下两项操作来提供帮助：

  • 前往 about://flags#block-insecure-private-network-requests，启用该标志，并查看您的网站是否按预期向专用网络资源发送请求。
  • 如果您遇到任何问题或有反馈，请在 crbug.com 上提交问题，并将组件设置为 Blink>SecurityFeature>CORS>RFC1918。

反馈示例

我们的无线路由器通过 HTTP 为同一专用网络提供管理网站。如果嵌入管理网站的网站需要使用 HTTPS，则会成为混合内容。我们是否应在封闭网络中的管理网站上启用 HTTPS？

这正是 Chrome 正在寻找的反馈类型。请在 crbug.com 上提交问题 ，并说明您的具体使用情形。Chrome 期待您的反馈。