Cross-Origin Read Blocking (CORB)

本文的开始源于落地页项目中遇到的 Chrome 控制台 warn 提示，担心影响页面渲染，特此弄个究竟。提示如下，

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://www.example.com/example.html with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.
复制代码

除非特殊说明，否则本文中的浏览器均指 Chrome Browser。

前言

本文将从以下几个方面对 CORB 进行探讨，

什么是 CORB
为什么会产生 CORB
什么情况下会出现 CORB
出现 CORB 时，我们可以如何看待

CORB 发生时浏览器表现

CORB 是一种判断是否要在跨站资源数据到达页面之前阻断其到达当前站点进程中的算法，降低了敏感数据暴露的风险。

- Chrome 浏览器提示

当请求发生 CORB 时，浏览器控制台会打印如下警告内容，

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://www.example.com/example.html with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details
复制代码

在 chrome 66或这个版本之前，提示信息有细微不同，

Blocked current origin from receiving cross-site document at https://www.example.com/example.html with MIME type text/html
复制代码

当请求的响应结果本身就出错或为空时，早期版本 Chrome 依旧会出现上述提示，但 Chrome 69 之后的版本不再出现上述提示。下文实验一和实验二验证了该描述。

- Chrome 浏览器行为

The response body is replaced with an empty body. // 响应数据置为空
The response headers are removed. // 移除响应请求头
复制代码

CORB 启动时，虽然响应结果会被置空，但是请求的服务仍然成功，`status: 200`。比如：使用 `img` 标签上报页面监控数据，尽管响应结果为空，但请求依旧发送成功，服务器亦正常响应。下文实验一已验证。

为什么会有 CORB 的出现？

简单来说，就是出现了一些网络安全漏洞，为防止漏洞肆虐，便出现了站点隔离（Site Isolation），CORB 则是其中的一种实现策略。

Spectre 和 Meltdown 漏洞

当恶意代码和正常站点存在于同一个进程时，恶意代码便可以访问进程内的内存，进行一系列访问攻击，此时，恶意代码窃取数据的唯一难点在于不知道敏感数据的具体存储位置，但通过 CPU 预执行和 SCA 可以一步步试探出来。详细了解可参看: zhuanlan.zhihu.com/p/32784852

什么是 CPU 预执行？

if(condition)
   do_sth();
复制代码

CPU 执行速度大于内存读取速度，为了提升 CPU 使用率，在从内存中读取 condition 完成之前，CPU 就已经开始执行下文内容。即不管 if 条件是否返回 true，CPU 都会提前执行里面的语句do_sth()。 CPU 预执行是芯片制造者决定的，为了提升 CPU 使用速度和效率而建的，预执行红利不是轻易就能放弃的，因此，目前或短期来看基本没可能改变。

普通浏览器中，不同的站点可能共享同一个进程

在某些情况下，没有实现 Site Isolution 的普通浏览器会出现一个进程里面同时运行多个站点的代码，这就让恶意站点有机可乘。比如恶意站点 a.dd.com 在自己的代码中嵌入，这时，普通浏览器就会把带有恶意站点 a.dd.com 的恶意代码和 v.qq.com 放在同一个内存中运行。

SCA(Side-Channel Attacks) 旁道攻击

简单来说，就是利用程序运行时，系统产生的一些物理特征（如：时延，能耗，电磁，错误消息，频率等）进行推测型攻击。看起来有点不可思议，但早在 1956 年，英国已经利用 SCA 获取了埃及驻伦敦的加密机。

缓冲时延（Cache Timing）旁路是通过内存访问时间的不同来产生的旁路。假设访问一个变量，这个变量在内存中，这需要上百个时钟周期才能完成，但如果变量访问过一次，这个变量被加载到缓冲（Cache）中了，下次再访问，可能几个时钟周期就可以完成了，可根据这种访问速度窃取特定数据。Spectre 和 Meltdown 漏洞便是利用了这种特性。

如何预防 Spectre 和 Meltdown 漏洞呢？

漏洞三大关键点是 CPU 预执行、SCA 和共享进程。预防就得从这三个方面着手。先看 SCA，算法运行时间的变化本质就是源于数据处理，根据时间变化推测运算操作和数据存储位置，因此 SCA 可预防性极低。再看 CPU 预执行，性能至少提高 10%，一片可观的红利，芯片厂商如何舍得放弃。如此，只能针对共享进程下手了，Site Isolation 便是剥离共享进程的一项技术，采用独立站点独立进程的方式实现，降低漏洞的威胁。

Site Isolation

站点隔离保证了不同站点页面始终被放入不同的进程，每个进程运行在一个有限制的沙箱环境中，在该环境中可能会阻止进程接收其它站点返回的某些特殊类型敏感信息，恶意站点不再和正常站点共享进程，这就让恶意站点窃取其它站点的信息变得更加困难。从 Chrome 67 开始，已默认启用 Site Isolation。

经验证，Site Isolation 关于进程独立的原则是只要一级域名一样，站点实例就共享一个进程，无论子域名是否一样。如果使用 iframe 嵌入了一级域名不一样的跨域站点，则会生成一个新的进程维护该跨域站点运行，这一点同前文介绍的普通浏览器共享进程不同。更详细的内容参看 www.yaoyanhuo.com/blog/site_i…

这是 Site Isolation 的进程设计，那么其中的 CORB 扮演了什么角色呢？

在同源策略下，Site Isolation 已经很好地隔离了站点，只是还有跨域标签这样的东西存在，敏感数据依旧会暴露，依旧会进驻恶意站点内存空间。有这样一个场景，用户登录某站点 some.qq.com后，又访问了 bad.dd.com 恶意站点，恶意站点有如下代码，