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

向私有网络上的设备和服务器发出请求的恶意网站长期以来一直是一种威胁。例如，攻击者可能会更改无线路由器的配置，以启用中间人攻击。CORS-RFC1918建议在浏览器上默认阻止此类请求，并要求内部设备选择加入来自公共互联网的请求。

为了了解这一变化对网络生态系统的影响，Chrome团队正在寻找为私有网络构建服务器的开发人员的反馈。

许多Web服务器在专用网络中运行-无线路由器、打印机、Intranet网站、企业服务和物联网(IoT)设备只是其中的一部分。它们似乎比暴露在公众面前的环境更安全，但这些服务器可能会被使用网页作为代理的攻击者滥用。例如，恶意网站可以嵌入一个URL，当受害者(在启用了JavaScript的浏览器上)简单地查看该URL时，它会试图更改受害者家庭宽带路由器上的DNS服务器设置。这种类型的攻击被称为Drive-ByPharming，发生在2014年。超过30万台易受攻击的无线路由器被利用，他们的DNA设置被更改，攻击者可以将用户重定向到恶意服务器。

为了减轻类似攻击的威胁，网络社区正在引入专门针对RFC1918中定义的专用网络的CORS-RFC1918-跨域资源共享(CORS)。

实现CORS的浏览器会检查目标资源是否可以从不同的来源加载。这可以通过内联描述访问的额外标头来实现，也可以通过使用称为印前检查请求的机制来实现，具体取决于复杂性。阅读跨地域资源共享了解更多信息。

使用CORS-RFC1918，默认情况下，浏览器将阻止私有网络上的资源加载，但服务器使用CORS和HTTPS明确允许的资源除外。对这些资源的网站制作请求将需要发送CORS报头，服务器将需要明确声明它通过使用相应的CORS报头响应来接受跨源请求。(确切的CORS头仍在开发中。)。

专用网络解析为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)、IPv6 RFC4193第3节中定义的唯一本地地址前缀(fc00：：/7)的目的地。在IPv6的RFC4291的2.5.6节中定义的前缀(fe80：：/10)。

第一步：只允许来自HTTPS网页的内网资源请求#。

Chrome87增加了一个标志，要求公共网站请求私有网络资源时必须使用HTTPS。您可以访问chrome://flags#block-insecure-private-network-requests来启用它。打开此标志后，任何来自HTTP网站的对专用网络资源的请求都将被阻止。

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

在Chrome DevTools的网络面板中，您可以启用被阻止的请求复选框以专注于被阻止的请求：

将来，当一个公共网站试图从个人或本地网络获取资源时，Chrome会在实际请求之前发送一个印前检查请求。

除了其他CORS请求头之外，该请求还将包括Access-Control-Request-Private-Network：TrueHeader。其中，这些eHeader标识发出请求的来源，从而允许细粒度的访问控制。服务器可以使用Access-Control-Allow-Private-Network：True标头进行响应，以明确指示它授予对资源的访问权限。

这些标头仍在开发中，未来可能会发生变化。目前不需要采取任何行动。

如果您在私有网络中托管一个网站，而该网站需要来自公共网络的请求，Chrome团队会对您的反馈和使用案例感兴趣。您可以做两件事来帮助您：

转到chrome://flags#block-insecure-private-network-requests，，打开旗帜，看看您的网站是否按预期向内网资源发送请求。

如果您遇到任何问题或有反馈，请在crbug.com上提交问题，并将组件设置为Blink>；SecurityFeature&>CORS&gT；RFC1918。

我们的无线路由器通过HTTP为同一私有网络的管理网站提供服务。如果嵌入管理网站的网站需要HTTPS，它将是混合内容。我们应该在封闭网络中的管理网站上启用HTTPS吗？

这正是Chrome正在寻找的反馈类型。请将您的具体用例问题提交到crbug.com。Chrome会很高兴听到你的消息。