之前我已经给大家分析过浏览器的策略：
这个策略提到了一个漏洞：Spectre漏洞，这个漏洞到底有什么魔力，让浏览器频繁更新针对它的策略，明天给大家解释一下。
幽灵
如果一个漏洞构建起来比较困难，即使能够造成很大的危害，也可能不会引起浏览器如此大的关注。 那么我们的主角幽灵就很容易构造，而且造成的伤害也很大。 借助 Spectre，您可以：
只需几行 JavaScript，您就可以读取笔记本电脑/手机上的所有数据。 浏览器中的网页可以读取您的所有密码并知道其他程序在做什么。 这甚至不需要您编写的程序有缺陷。 是的，因为这是计算机硬件层面的漏洞。
要理解Spectre，我们需要以下三个方面的知识：
虽然都是一些特殊的计算机基础知识，但你可能在中学就学过，所以Spectre巧妙地利用了前三个原理，我们来一一看一下。
你完全不用担心，我会用最简单的形式给你讲解，先把这类知识拆解，最后拼凑起来，看起来就很容易理解了。
记忆是如何运作的
首先我们的笔记本是由很多部分组成的：
当我们的计算机运行时，程序从存储设备加载到CPU中，CPU负责处理大量的计算。 该计算需要多次读取显存中的数据。 然后将结果输出到我们的显示器等输出设备上，这大致就是计算机的简单工作原理。
下面我们重点关注CPU和显存。 显存存储了你正在运行的很多程序，包括系统、用户数据等，也存储了CPU运算的中间结果。
要存储如此多的信息，需要标准化的存储形式。 我们可以把显存想象成一堆排列好的小显存块，每个显存块存储一位信息。
另外，显存有很多层，CPU读取上面的一个数据非常慢，所以我们在CPU和显存中构建了几级缓存。 当我们获取缓存的数据时，速度会更快。 。 那么当访问一个没有被缓存的数据时，该数据会在缓存内存中创建一个副本，最后一次访问的时候会非常快。
这就是显存的大致工作原理。 事实上，这个过程被简化了很多。 我们只需要理解这里就可以了。
绕过攻击
那么什么是侧信道呢？
我们可以简单地这样理解：如果你的程序在正常的通信渠道之外形成了另一个特征，这个特征反映了你不希望形成的信息，如果这个信息被别人收到了，你就会泄露它。 这种边缘特征形成的信息通道称为旁路。
比如说你的显存在计算的时候，它形成了一个无线电波，它反映了显存中的内容，有人用特定的方法收集了这个无线电波，这就形成了旁路。 基于旁路的攻击称为旁路攻击。
常见的绕过包括：信噪比、异常、煤耗、电磁、噪音、可见光、错误信息、频率等。总之，你的操作总是有边缘特征，如果你不注意这一点边缘特性，就会成为泄漏的机会。
我们举一个根据信噪比旁路功率的例子：
假设我们希望笔记本验证密码，例如我们的密码是ConardLi。
接下来我们从攻击者的角度来猜测，密码是什么，我们从一个字母来猜测：
您注意到任何问题了吗？ 我们猜对了第一个字母，但计算机在 0.1 毫秒后告诉我们密码错误？
因为这次计算机发现第一个数字匹配后，需要验证第二个数字是否匹配，所以会花费更多的时间。 是不是很巧妙！
我们可以用同样的方式继续验证Ca，Cb，...Co，最终猜出我们的密码。
这时，我们的猜测时间和密码宽度呈线性关系，我们可以在O(n)的时间复杂度内猜出密码。 如果直接爆破的话，我们至少需要估算52的8次方！
这就是旁路，这该死的魅力！
CPU 推测执行
前面我们提到，CPU在运行时，会频繁地从显存中检索信息。 并且读取显存的速度非常慢，因此CPU会花费很长的时间空闲，只是为了等待显存的数据。 这其实并不是一个很好的计划。
那么，人们想，CPU能否推断出需要执行的命令呢？
假设我们有如下代码，根据显存中的某个数据执行不同的语句：
if(Menory === 0){
// 进行第一步计算
// 进行第二步计算
// 进行第三步计算
}
这里有两种可能，Menory为0或不为0。
这时CPU只会预测什么时候等待显存数据。 假设读显存返回0，CPU可以直接跑掉，无需等待显存返回：跳过if判断，直接执行上面的估计命令。
这样，如果显存确实返回0，则CPU已经成功超前运行，CPU就可以继续执行前面的命令了。 而如果显存不返回0，CPU就会回滚之前执行的结果。
因此CPU执行时需要特别小心，不能直接覆盖寄存器的值，然后实际改变程序的状态，一旦发现预测失败就立即回滚改变。
强力攻击原理
后来我们已经掌握了这个漏洞利用的所有诱因，我们来看看它到底是什么。
假设底部是我们的缓存，读取它很慢。 系统内核将其分成块并分配给不同的程序。 如果考虑云计算，可能会分配给不同的虚拟机。
不同程序可能分配的显存块是相邻的，蓝色显存块存储的是我们受害者的数据，比如受害者的某个密码：
操作系统会尽力确保一个程序很难访问属于其他程序的内存块，并且不同程序的内存块会被隔离。
所以其他程序很难直接读取“受害者”（黄色区域）的数据：
如果我们尝试直接访问白色区域，肯定读不到，而且有些数据可能已经存在于缓存中了。 接下来我们可以尝试利用缓存来做一些事情。
我们在蓝色显存块中放入一个链表A。 这个显存是属于我们程序的，可以合法访问，而且它很小，只有两位。
而我们不满足于读取字段A中的两个元素，我们试图超出A的范围（下标越界），访问字段A的第X位。而X可能远远超出了A链表的厚度。
正常情况下，CPU会停止这个操作，并抛出一个错误：“非法操作”，然后操作就会被强行结束，但是我们可以尝试再次观察这个过程，看看它是怎么做的。
我们在允许访问的显存范围内创建一个新区域，可以称为工具箱。
我们非常要求CPU不要把这些数据复制到缓存中，而只保留在显存中，显存是一块连续的显存区域。
假设我们执行的指令是这样的，首先有一个if判断语句：
if(name === 'code'){
// ...
}
一般来说，CPU执行会先忽略这个判断，因为需要等待显存返回name的值是否等于code，因为有预测执行之类的技术，if语句里的东西会提前执行。
if(name === 'code'){
access Tools[A[x]]
}
我们尝试读取 Tools 的第 (A) 个元素。 如果我们读到该受害者的 VRAM 包含 3：
这是我们不应该阅读的内容，我们可以通过推测执行执行以下操作：
当CPU执行完这条不该执行的命令后，CPU认为需要检查A[X]的值。 验证下标是否越界javascript 调用 程序，如果越界，程序将被强制终止。
因此，预测执行直接查询A[X]的值，然后发现A[X]=3，即：
Tools[A[x]] = Tools[3]
也就是我们实际显存中Tools中存放的第四个元素a，这里重点来了：
CPU访问a后，将a（即Tools[3]）倒入缓存中！
最后一步是遍历 Tool 中的每个元素。 我们发现访问前几个元素有点慢，直到访问第三个元素突然非常快！ 因为第三个元素a在缓存中存储了一份副本！
当推测执行发现错误时，它还会回滚对寄存器的更改，但不会回滚缓存！
信息就这样泄露了，因为访问第3个元素所需的时间比其他元素要短！ 这也称为基于时间的旁路。
所以，我们知道“受害者”在显存的这个位置有一个3。
接下来，我们可以把工具区域做得更大，你就可以猜到更多其他数据了！ 其实这就是实际攻击中需要考虑的损失~
对网络的影响
里面的原理我们已经分析过了。 事实上，使用JavaScript来实现这个功能是非常容易的。 在JavaScript中，几乎可以绕过所有的边界检测，进而实现任意显存边界读取。 我们可以看下面的代码：
if(index < array.length){
index = array[index | 0];
index = (((index * TABLE_STRIDE) | 0) & (TABLE_BYTES - 1)) | 0;
localJunk ^= probeTable[index | 0] | 0;
}
来自不同站点的多个页面最终可能会在浏览器中共享单个进程。 当用户使用 window.open 或 iframe 打开另一页面时，可能会出现问题，并且如果一个网站包含特定用户的敏感数据，则另一个网站可能会利用此类漏洞来读取该用户的数据。
只是举了一个简单的例子javascript 调用 程序，虽然实际的攻击范围比这要广得多，所以浏览器制定了很多安全策略来解决这个问题，下面我们就来看看：
浏览器策略缓存推荐设置
现在配置这两个缓存应该更清楚了。 浏览器无权终止缓存。 只能最大程度收紧缓存的下摆，降低攻击难度。
禁用高帧率计时器
为了利用 Spectre，攻击者需要准确测量从视频内存读取值所需的时间。 因此需要一个可靠且精确的计时器。
浏览器提供的performance.now() API，时间精度可以精确到5毫秒。 作为缓解措施，所有主要浏览器都提高了 Performance.now() 的帧速率，这会使攻击变得更加困难。
获得高帧速率计时器的另一种方法是使用 SharedArrayBuffer。 Webworker 使用 Buffer 来递减计数器。 主线程可以使用这个计数器来实现定时器。 由于这个原因，浏览器禁用 SharedArrayBuffer。
rel =“无开瓶器”
浏览器上下文组是一组共享相同上下文的选项卡、窗口或 iframe。 例如，如果 website() 打开 popup()，则打开器窗口和弹出窗口共享相同的浏览上下文，但它们可以通过 DOMAPI 相互访问，例如 window.opener。
所以浏览器建议您在打开不受信任的外部页面时指定rel="noopener"。
跨源开放政策 (COOP)
利用Spectre，攻击者可以读取统一浏览器下任意ContextGroup下的资源。
COOP：Cross-Origin Opener New Policy，对应的HTTP Header为Cross-Origin-Opener-Policy。
通过设置COOP为Cross-Origin-Opener-Policy:same-origin，可以将本网站打开的不同来源的窗口隔离在不同的浏览器ContextGroup中，从而创建资源隔离环境。
详细可以阅读这篇文章：跨域新策略：利用COOP、COEP为浏览器打造更安全的环境
跨源嵌入式程序新政 (COEP)
COEP：New Policy for Cross-Origin Embedded Programs，对应的HTTPHeader为Cross-Origin-Embedder-Policy。
启用 Cross-Origin-Embedder-Policy:require-corp 后，您的站点可以仅加载明确标记为可共享的跨源资源或同一域内的资源。
跨源读阻塞 (CORB)
虽然不同来源的所有页面都在各自独立的进程中，但页面仍然可以合法地请求一些跨站资源，例如图像和JavaScript脚本，并且一些恶意页面可能会通过
元素来加载包含敏感数据的 JSON 文件。
如果没有站点隔离，JSON 文件的内容将保存到渲染器进程的视频内存中，此时渲染器将注意到它不是有效的图像格式，并且不会渲染图像。 而且，攻击者还可以利用 Spectre 等漏洞读取该视频内存块。
跨源读阻塞 (CORB) 可以根据其 MIME 类型阻止平衡内容进入渲染器进程显存。
参考文末
浏览器做出了这么多的策略，虽然只能说可以在一定程度上缓解这个漏洞，但实际上并不能从症结上消除，因为Spectre本质上是一个硬件级的漏洞，增加了攻击的可能性漏洞的成本。
这个漏洞本身也很难解决。 无论是预测执行还是缓存，如果受到限制的话性能都会大幅提升，所以这个问题在硬件层面还没有得到解决。
