深入解读Chrome94新跨域政策说没用。如果用户允许你F12进行网络交互或控制台输出查看，你会发现这样的错误：AccesstoXMLHttpRequestat'http://[some_url]'fromorigin'http://[some_url]'hasbeenblockedbyCORS策略：请求客户端不是安全上下文，资源位于更私有的“私有”地址空间中。那么请求就中断了，后面的逻辑自然就无法进行了。乍一看好像是跨域策略（CORS策略）的问题，于是赶紧查看跨域相关接口的ResponseHeader的配置：Access-Control-Allow-Origin:*Access-Control-Allow-Headers:X-Requested-With,Content-Range,Content-TypeAccess-Control-Expose-Headers:Range和跨域相关的配置也返回（否则之前的系统无法正常运行），为什么会这样突然报错？如果您遇到了同样的问题，请继续阅读本文。重现问题首先，你所运行的业务系统的域名必须指向一个公网IP地址。这里我们假设名字是“out.com”；其次，在上述业务系统中调用了另一个系统的接口，该子系统的域名指向一个内网IP地址（不分A类、B类、C类子网）（localhost除外，127.*.*.*,[::1])。这里我们假设名称是“in.com”。最后肯定是以上两个系统使用http协议访问。例如*：pingout.com从110.242.68.66回复：byte=32time=12msTTL=48pingin.com从10.29.10.136回复：byte=32time=12msTTL=48操作页面：http://out.com/article/process，该页面有如下JS：$.ajax({url:"http://in.com/api/auditors",method:"GET",success:function(ret){}})那么此时就会重现文章开头所述的问题。*注：以上数据已经过脱敏处理，涉及的域名和IP地址并非真实数据，仅供内容阐述。问题原因为什么升级到Chrome94后出现问题？在此版本中，它不允许从公共非安全上下文（广义上讲，不是通过HTTPS的网站或来自私有IP地址的网站）到私有网络的请求。听起来很难理解。我们把这句话的关键词提炼出来：publiccontext/request/privatenetwork。这里不得不说一下现在的网络应用背景。嵌入式设备出现在越来越多的家庭中。这些设备的安全性一般都不是很高。只提供简单的http配置接口给用户。如果别有用心的访问外网的网页，里面嵌入了内网的ajax请求，那么这些家族的嵌入式设备就很容易被攻击。下面是我总结的一张表，意思是结合外部网络资源使用不同的协议访问内部网络资源。外网访问内网httphttpshttpChorme94禁止Chorme94禁止https安全内容加载不安全内容，禁止访问跨域策略。这是给你的例子。部分型号的TP-Link路由器，为了方便用户配置，只要连接上（有线或无线），在浏览器输入：tplogin.cn即可自动打开管理界面（域名自动为解析为默认网关）。在Chrome94之前，当用户打开一个“精心设计”的http页面时，里面写了一组针对tplogin.cn的攻击JS。那么内网中的路由器就有被入侵的风险。事实上，这可以与当前的智能手机相关联。在iOS中，如果应用需要网络权限，用户可以选择蜂窝网络和无线网络，无线网络可以选择是否允许访问本地网络。这个特性其实是基于和Chrome的跨域策略升级一样的考虑。方案一：同时升级外部系统和内部系统，使用https协议访问；方案二：如果你有控制外部系统的权限，让外部系统在公司内网也解析到内网地址。如果必须使用http访问（例如：没有对应的https证书），那么用户可以在浏览器中禁用该策略。在chrome中打开这个地址：chrome://flags/#block-insecure-private-network-requests来禁用Blockinsecureprivatenetworkrequests配置（Disable）。但必须注意的是，修改完配置后，此时必须点击Chrome右下角出现的“重启”按钮才能生效。如果你主动关闭浏览器的所有页面再打开，不会触发Chrome更新配置。参考文献[1]TitouanRigoudy，专用网络访问更新：引入弃用试验[EB/OL]。https://developer.chrome.com/blog/private-network-access-update/，2022-02-10。
