Chrome即将禁止从非安全网站发起的专用网络请求

问题：生产环境191.168.1.22去请求 http://127.0.0.1，第一次请求会被拦截，第二次又不会

chrome更新到94之后，会自动阻止发送不安全的内网请求。解决办法，就是关闭这个新特性

浏览器输入：chrome://flags/#block-insecure-private-network-requests

 

Private Network Access(私有网络请求PNA）

出于安全方面的考量以及过去被恶意软件滥用的情况，Google 表示 Chrome 浏览器近期将阻止互联网网站和本地私人网络内的设备/服务器之间的查询和互动。

这一变化将通过实施新的 W3C 规范来实现，该规范被称为Private Network Access(私有网络请求PNA），将在今年上半年推出。

私有网络是指目标服务器的IP地址比从其获取请求服务器的IP地址更私有的请求。

例如，从公共网站（ https://example.com ）向私有网站（ http://router.local ）的请求，或从私有网站向 localhost 的请求

 

据Google称，PNA 的一个版本已经与 2021 年 11 月发布的 Chrome 96 一起上线，但全面支持将在今年分两个阶段推出，分别是 Chrome 98（3月初）和Chrome 101（5月底）的发布，详情如下。

在 Chrome 98 中

● Chrome会在私有网络子资源请求之前发送预检请求。

● 预检失败只在DevTools中显示警告，不影响私人网络请求。

● Chrome收集兼容性数据，并向受影响最大的网站伸出援手。

● Google 预计这将与现有网站广泛兼容。

最早在Chrome 101 中全面部署

● 只有当兼容性数据表明该变化足够安全，并且我们在必要时直接进行了外联时，这才会开始。

● Chrome浏览器强制要求预检请求必须成功，否则会导致请求失败。

● 废弃试验也同时开始，以允许受此阶段影响的网站请求延长时间。该试验将持续至少6个月。

 

 

Chrome 正在计划禁止从非安全网站发起的专用网络请求

目的是保护用户免受针对专用网络上的路由器和其他设备的跨站点请求伪造 (CSRF) 攻击：

• 从 Chrome 94 开始阻止来自不安全公共网站的私有网络请求。
• 在 Chrome 101 中结束的弃用试验。
• 在 Chrome 92 中引入一些 Chrome 策略，允许托管的 Chrome 部署永久绕过弃用。

啥是专用网络？

在互联网的地址架构中，专用网络是指遵守 RFC 1918（IPV4）和 RFC 4193（IPV6）规范，使用专用 IP 地址空间的网络。私有 IP 无法直接连接互联网，需要使用网络地址转换（Network Address Translator，NAT）或者代理服务器 （proxy server）来实现。

一般，我们在企业里搭建的局域网、家庭网络里的局域网、你本地的 localhost ，都属于专用网络

专用网络访问规范

专用网络访问规范（以前称为 CORS-RFC1918）会限制网站向专用网络上的服务器发送请求的能力。它只允许来自安全上下文（HTTPS）的此类请求。该规范还扩展了跨域资源共享 (CORS) 协议，因此网站现在必须要经过专用网络上的服务器授权会才能发送请求。

私有网络请求是其目标服务器的 IP 地址比获取请求发起者的 IP 地址更私有的请求。例如，从公共网站 ( https://example.com) 到私有网站 (http://router.local) 的请求，或从私有网站到 localhost 的请求。

我们在开发过程中，这几种情况实际上是比较常见的，所以需要开发者提前试用并作出应对。

访问 localhost

如果你的网站需要向 localhost 发出请求，那么你只需要将你的网站升级到 HTTPS。

混合内容不会阻止以 http://localhost（或 http://127.*.*.*、http://[::1]）为目标的请求，即使是从安全上下文发出的。

请注意，这里有个坑，WebKit 引擎和基于它的浏览器（比如 Safari）这里并没有遵循 W3C 混合内容规范，上面这些请求会作为混合内容并禁止访问。它们也没有实现专用网络访问，因此网站如果使用此类浏览器的客户端，需要试用 HTTP 协议，此类浏览器仍允许向 localhost 发出请求。

访问私有 IP

如果你的网站需要向私有 IP 地址上的目标服务器发出请求，那么简单地将发起方网站升级到 HTTPS是行不通的。混合内容会阻止安全上下文通过明文 HTTP 发出请求，因此新获得安全保护的网站仍会发现自己无法发出请求。有几种方法可以解决这个问题：

将两端都升级为HTTPS

这个方案难度有点大，因为 HTTPS 只会面向公共域名办法，你需要先给你的私有 IP 注册一个公共域名，然后配置 DNS 解析把公共域名指向这个私有 IP，最后再给域名配置 TLS 证书。

使用 WebTransport

这个方案不需要自己控制 DNS 解析，你需要在私有网络上自己搭建一个 WebTransport 服务器。

WebTransport 是 WebRTC 体系下的一套浏览器API ，提供低延迟，client 和 server之间双向通信的能力。

• WebTransport 提供基于 QUIC 和 HTTP3 实现的API ，自动获得 QUIC 和 HTTP3本身的特性，比如应用层的拥塞，避免队头阻塞。
• 双向通信的能力，多个传输通道复用一个连接的能力，能够很好的替代 WebSocket。
• 提供发送/接受不可靠 UDP 的能力，这个是浏览器一直欠缺的能力。

重要的是，通过使用 WebTransport 的证书锁定机制，你可以绕过缺少由受信任 CA 签署的有效 TLS 证书的问题。

反向嵌入。

网站的框架可以从私有服务器获取，然后从公共服务器(如CDN)获取它的所有子资源(如 script 或 image)。这样生成的网站可以向私有服务器发出请求，因为这些请求是同源的，它甚至可以向其他使用私有 ip 发出请求。

这个方案可以临时用，官网所可能以后对这种情况也会有所限制。

CORS 预检请求的变化

CORS 预检请求是一个 HTTP OPTIONS 请求，它带有一些 Access-Control-Request-* 标头，表明后续请求的性质，例如是否允许跨域访问。

专用网络访问规范 的第二部分是使用 CORS 预检请求 来控制从安全上下文发起的专用网络请求。即使请求是从安全上下文发起的，目标服务器也会被要求向发起者提供明确的授权，只有在授权成功时才会发送请求。