有一天, 打开浏览器看到控制台报错:
Cross-Origin Read Blocking (CORB) 已屏蔽 MIME 类型为 text/html 的跨域响应 https://xx.xxxx.com/stat/record?it=0&lshowp=2560x1440&0.1996155506933639 如需了解详情，请参阅
https://www.chromestatus.com/feature/5629709824032768
于是乎, 就去了解一下什么是 CORB. 具体如下
Cross-Origin Read Blocking (CORB)
是一个新的 web 平台安全功能, 它能够帮助减少线程之间的
旁路攻击(side-channel attacks)
;
CORB 的目的是防止浏览器向网页接收某些跨源网络响应，因为这些响应可能包含敏感信息，而且现有的网页功能不需要这些响应。
例如: 它将清除一个从
<script>
或者
<img>
标签发起的跨源
text/html
响应. 将响应的内容,用空值代替.
这是
网站隔离(Site Isolation)
非常重要的一部分.
In Chrome M68 and later CORB is active by default - no special actions need to be taken to activate CORB
在同源策略(same-origin policy)下通常会阻止一个网站读取其它源的任意网络资源.
但是, 在实际情况中, 实施同源策略并非只是简单阻止所有的跨域资源.
浏览器对于有些情况是允许加载跨域资源的, 例如
<img>
,
<script>
标签, 它们可以加载跨域的资源;
并且
跨源资源共享（CORS）
选择性地可以读取跨域的资源;
允许加载跨域资源, 意味着存在着安全隐患.
场景: 用户登录了 victim.com 之后, 又去访问了 evil.com 的恶意站点.
在 evil.com 中有
<script src="victim.com/login">
的元素, 则浏览器会向 victim.com 发起请求, 且会把敏感信息返回给浏览器. 此时, 用户在 evil.com 页面所在的内存中就留有的 victim.com 的敏感数据;
CORB 会在敏感信息加载到页面内存之前，将其拦截掉，如此，敏感信息既不会暴露于浏览器，也不会进驻内存空间，得到了很好的保护。
XSSI 是一种攻击方式. 它通过
<script>
指向一个不是 JavaScript 代码文件的目标资源, 并且让浏览器执行.
具体的情况, 可以看看
JSON_Hijacking_Gareth_Heyes
<script charset="ISO-8859-1" src="polyglot/uploads/xss.jpg"></script>
CORB 阻止了这一类攻击, 因为 CORB 将阻止<script> 标签发起的这种请求;
- 通过 CPU 预测执行,而引起的旁路攻击 (例如 Spectre).
例如: 攻击者会使用 img标签来加载跨域的文件, 让 JavaScript 在执行过程中, 将进程中的信息暴露给攻击者
<img src="https://example.com/secret.json" />
CORB 通过阻止 JSON 的资源加载到进程的内存中, 可以阻止这一类攻击.
当 CORB 判断出需要对响应做出 CORB-protected, 响应则会
为了有效地对抗预测执行的旁路攻击，CORB 阻塞必须在响应到达承载跨源请求发起者的进程之前发生。
CORB 并不会影响下面的情况
<a href="/images/myw3schoolsimage.jpg" download></a>
- XHR and fetch()
- ping, navigator.sendBeacon()
<link rel="prefetch" ...>- Requests with the following request destination
- “image” requests like
<img> tag, /favicon.ico, SVG‘s <image>, CSS’ background-image, etc. - “audio”, “video” or “track”
- “font”
- “style”
当跨域请求回来的数据 MIME type 同跨域标签应有的 MIME 类型不匹配时，浏览器会启动 CORB 保护数据不被泄漏.
例如: script 标签请求的响应是 json. img 标签请求回来的是 json.
目前, 针对下面的响应类型会触发 CORB
浏览器判断响应类型: 浏览器拥有Content_sniffing的功能, 会尝试判断响应类型, 并不依赖Content-Type;
除非响应头指定 “X-Content-Type-Options: nosniff”, 此时浏览器会直接根据Content-Type的格式进行处理;
一个 img 标签, 请求一个 html 的数据
- 响应体 Body: 是一个 HTML document
- Content-Type: text/html
- No X-Content-Type-Options header
此时, 浏览器尝试判断响应内容, 如果发现是 html 标签. 则触发 CORB-protected
更多具体的案例: determining-whether-a-response-is-corb_protected
攻击场景:
- 登录 victim 网站, 返回用户的 cookie
- 请求 victim 网站的数据
secret-info.json - 点击 evil 网站
- evil 网站通过
JSON Vulnerability 来窃取信息; (JSON Vulnerability 只存在于特别老的浏览器)
<script>
var secrets;
Array = function () {
secrets = this;
</script>
<script src="https://victim.com/demos/secret-info.json"></script>
<script>
var yourData = '';
var i = -1;
while (secrets[++i]) {
yourData += secrets[i] + ' ';
alert('I stole your data: ' + yourData);
</script>
如果返回的 json 数据是["Philha", "my-confession-to-crimes", 7423.42], 数据则有可能被窃取;
CORB 可以阻止此类事情的发生.
<script>
{"d": ["Philha", "my-confession-to-crimes", 7423.42]}
</script>
https://anforowicz.github.io/xsdb-demo/index.html
JSONP 算是一种讨巧的跨域请求方式. 具体的情况可以看看 说说 JSON 和 JSONP，也许你会豁然开朗，含 jQuery 用例, 这里不再赘述;
JSONP 和 CORB 有什么关系呢?
在某些情况下, JSONP 会触发 CORB
- 响应体 Body: 是 js 代码
- Content-Type: text/html
- X-Content-Type-Options: ‘nosniff’
通过 script 标签, 获取到 html 的内容(因为指定了 nosniff, 浏览器会直接认为响应内容是 text/html). 从而会触发 CORB, 响应会被清空;
Cross-Origin Read Blocking (CORB)背景有一天, 打开浏览器看到控制台报错:Cross-Origin Read Blocking (CORB) 已屏蔽 MIME 类型为 text/html 的跨域响应 https://xx.xxxx.com/stat/record?it=0&lshowp=2560x1440&0.1996155506933639 如需了解详情，请参阅 https://www.chromestatus.com/feature/56297098
《解决浏览器请求成功数据被拦截，获取不到数据问题》
**备注：**先保存3条cmd代码,执行后会重启浏览器
原文链接：https://blog.csdn.net/MisTTT/article/details/75976123
解决chrome对跨域请求禁止的约束：
在命令行执行命令：
start chrome.exe --args --disable-web-security --user-dat...
1、问题描述
在使用geoserver搭建的gis服务过程中，在利用WMS请求相关图层时，出现了多个“Cross-Origin Read Blocking (CORB)已屏蔽 MIME 类型为 text/xml 的跨域响应”的跨域提示，造成图层没有呈现出来。
2、解决方法
经过查询资料，通过修改geoserver的配置文件和扩展jar可以实现跨域响应的问题。
3、解决过程
第一步，如果geoserver服务正在运行，建议先关闭geoserver服务；
第二部，打开geoserver\WEB-IN
文章目录一、背景二、描述问题1、前因后果2、分析三、CORS1、 概念四、CORB1、概念2、一些概念3、说正事4、分析
最近一直在做项目联调，由于系统对接了N个第三方厂商，于是乎扯出了一堆的跨域问题，他们是下面这样的：
https域名访问http域名被浏览器禁止
接口未开放跨域能力
有一天 我看到了这个：
看不清的话看这里
Cross-Origin Read Blocking (CORB) blocked cross-origin response https://a.g.t.cn
<h3>回答1：</h3><br/>Cross-Origin Read Blocking (CORB) 是一项安全功能，用于阻止网页从不同源（即不同域名）读取敏感数据。如果 CORB 检测到跨域请求的数据属于敏感类型，它将阻止该请求并返回错误信息。
<h3>回答2：</h3><br/>首先，我们需要了解同源策略（Same Origin Policy）。同源策略是一种安全机制，限制了网站在脚本中如何操作来自不同来源的文档、窗口或框架。简而言之，如果两个页面拥有协议、主机和端口号完全相同，那么它们就是同源的。
而当请求跨域资源时，服务器必须在响应中设置特定的HTTP头——CORS（Cross-Origin Resource Sharing）授权。这个头告诉浏览器是否允许一个页面访问来自不同源服务器的特定资源。如果服务器没有设置这个HTTP头，浏览器默认会阻止请求。
那么，什么是CORB呢？CORB是Chrome浏览器所实现的另一种安全机制，其目的在于防止来自不同源服务器的恶意代码，以及保护隐私信息。它会拦截并阻止一部分潜在的XSS攻击，并使渲染过程更高效。
当我们在Chrome中请求跨域资源时，如果返回的内容被Chrome识别为危险的MIME类型，并且服务器没有设置CORS授权的HTTP头，就会出现“Cross-Origin Read Blocking（CORB）Blocked Cross-Origin Response”的错误。这个错误意味着浏览器无法读取来自另一个域的响应，因此，浏览器会阻止访问这些跨域资源。
所以，解决这个错误的方法是服务器需要设置CORS授权的HTTP头。如果服务器无法设置这个HTTP头，我们就不能直接从JS中访问这些跨域资源了，而需要采取其它的处理方式，比如通过代理等。
<h3>回答3：</h3><br/>Cross-origin read blocking (CORB)是一种浏览器安全机制，旨在防止跨站脚本攻击和信息泄漏，防止恶意网站通过注入恶意脚本来窃取用户敏感信息。在实际应用中，由于站点间跨域问题，有可能会经常遭遇到“cross-origin read blocking (corb) blocked cross-origin response”的提示。
“cross-origin read blocking (corb) blocked cross-origin response”提示意味着当前页面试图读取另一个域名下的资源，然而在跨域请求中，目标站点返回了一个被拦截的响应。这通常意味着当前页面试图从一个不受信任的域名下请求资源。浏览器会拦截这个跨域请求，防止页面从其他站点获取潜在的危险信息。
要解决“cross-origin read blocking (corb) blocked cross-origin response”问题，有几种方法：
1. 通过设置CORS（跨域资源共享）来允许站点间跨域访问。这需要在目标站点上设置一些标头，例如“Access-Control-Allow-Origin”。
2. 可以考虑使用JSONP（JSON with padding）方法，这是一种跨域请求的方法，它可以通过动态地在页面上添加一个脚本来请求数据。
3. 使用代理服务器可以将跨域请求转发到另一个域名下，以避免被拦截。
总体而言，“cross-origin read blocking (corb) blocked cross-origin response”提示意味着当前页面试图从一个不受信任的站点获取潜在的危险信息。为了保障用户安全和信息安全，浏览器会阻止这样的跨域请求。开发者可以通过设置CORS或使用JSONP等方法来解决这一问题。
