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

缓解与客户端内部网络上的设备和服务器意外泄露给网络相关的风险。

Eiji Kitamura

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

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

现状有什么问题？

许多 Web 服务器都在专用网络中运行，无线路由器、打印机、内网网站、企业服务和物联网 (IoT) 设备只是其中的一部分。这些服务器似乎处于比公开环境更安全的环境，但这些服务器可能会被攻击者使用网页作为代理。例如，恶意网站可以嵌入一个网址，当受害者（在启用 JavaScript 的浏览器上）直接查看该网址时，该网址会尝试更改受害者的家庭宽带路由器上的 DNS 服务器设置。此类攻击称为“免下车制药”，发生在 2014 年。超过 30 万个易受攻击的无线路由器被利用，攻击者更改了其 DNS 设置，并允许攻击者将用户重定向到恶意服务器。

CORS-RFC1918

为了缓解类似攻击的威胁，网络社区推出了 CORS-RFC1918 - 专用于 RFC1918 中定义的专用网络的跨域资源共享 (CORS)。

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

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

此类设备或服务器的开发者需要完成以下两项操作：

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

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

受影响的请求包括：

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

专用网络：一个目的地，解析为 IPv4 中 RFC1918 第 3 节中定义的专用地址空间，一个 IPv4 映射 IPv6 地址（映射的 IPv4 地址本身是专用地址），或一个位于 ::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)、IPv1 第 3 节的“RFC2 IPv1 的 RFC2 前缀”。fc00::/7RFC4193fe80::/10RFC4291

公共网络 所有其他网络。

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 提交与您的具体用例相关的问题。我们期待收到您的反馈意见。

主打图片：Unsplash 用户 Stephen Philips 提供。