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

降低因客户端内部网络上的设备和服务器无意中向整个网络公开而产生的风险。

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

为了了解这项变更对网络生态系统有何影响,Chrome 团队希望从为专用网络构建服务器的开发者那里获得反馈。

现状有什么问题?

许多 Web 服务器都在专用网络中运行,无线路由器、打印机、企业服务器、企业服务和物联网 (IoT) 设备只是其中的一部分。它们可能看起来比公开的服务器处于更安全的环境中,但攻击者可以使用网页作为代理来滥用这些服务器。例如,恶意网站可能会嵌入一个网址,当受害者(在支持 JavaScript 的浏览器中)仅查看该网址时,该网址就会尝试更改受害者家用宽带路由器上的 DNS 服务器设置。此类攻击称为“路过式 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 映射的 IPv6 地址(其中映射的 IPv4 地址本身是专用地址),或 ::1/1282000::/3ff00::/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 期待收到您的反馈。

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