通过几行JS就可以读取电脑上的所有数据？

　　如果一个漏洞很难构造，就算他能够造成再大的危害，可能也不会引起太大重视。但是我们今天要介绍的的  旁路攻击  ，是又容易构造，又能造成很大的危害的漏洞。
　　利用 旁路攻击 ，通过几行 js 代码，就可以读取到电脑/手机上的所有数据，浏览器中的网页可以读取你所有的密码，知道其他程序在干什么，这甚至不需要你写出来的程序是有漏洞的，因为这是一个计算机硬件层面上的漏洞。
　　让我们先从＂内存的工作方式＂开始吧。  内存的工作方式
　　首先，我们的电脑是由很多零部件构成的：  存储：内存、硬盘等等  CPU  输入输出设备：键盘鼠标等
　　我们的计算机运行的时候呢，从存储设备加载程序进入  CPU ，CPU  负责进行运算，这些运算需要内存的数据进行多次读取。然后把结果输出到我们的显示器等输出设备里面，这大概是是一个计算机简单的工作原理。
　　下面我们把关注点放到  CPU  和内存上面，内存里存放着你正在运行的很多程序，包括系统、用户数据等等、同时也存储了 CPU  运算的中间结果。
　　要存储这么多信息，需要一个规范化的存储方式，我们可以把内存想像成一堆排列好的小的内存块，每个内存块里保存着一位信息。
　　另外，内存是有很多层的，CPU 去里面读一个数据是很慢的，所以我们又在 CPU 和 内存中建立了几级缓存，当我们取到一个被缓存过的数据时，速度会快一点。那当访问一个没被缓存过的数据时，数据会在缓存内存里创建一个副本，下次再访问到它就会很快。
　　这就是内存大概的工作原理，当然这个过程简化了很多，我们在这里只需要简单理解即可。  旁路攻击
　　那么啥是旁路（ side-channel ）呢？
　　我们可以简单这样理解：你的程序在执行时，会产生了一些额外的特征，这些特征反映了程序的某些运行状态。通过分析这个特征，就能推导出程序的信息。这个特征，就叫旁路。
　　比如你的内存在运算的时候，产生了一个电波，这个电波反映了内存中的内容，有人用特定的手段收集到这个电波，这就产生了一个旁路。基于旁路的攻击，就称为旁路攻击。
　　常见的旁路还有：时延，异常，能耗，电磁，噪声，可见光，错误消息，频率，等等，反正运行程序总是有特征的，一不小心这些特征就成了泄密的机会。
　　我们来举个基于时延来进行旁路攻击的例子：
　　假设我们想让电脑验证一下密码，比如我们的密码是  ConardLi 。
　　下面我们从攻击者的角度来猜一下，密码是啥，我们从一个字母开始猜：  密码是  A ，计算机 1ms  后告诉我：不对！ 密码是  B ，计算机 1ms  后告诉我：不对！
　　密码是  C ，计算机 1.1ms  后告诉我：不对！
　　有没有发现啥问题？我们第一个字母猜对了，但是计算机告诉我们密码错误的时间增加了  0.1ms。
　　因为这次，计算机发现第一位匹配后，需要验证第二位是否匹配，所以会多花费一些时间。是不是很巧妙！
　　我们可以以同样的方式，再继续验证  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 会阻止这一操作，抛出一个错误：＂非法操作＂，然后操作会被强制结束 ，然而我们可以试图观测这个过程，构造旁路攻击。
　　举个例子，在我们允许访问的内存范围内再次新建一个区域，如下图所示的 Tools 工具箱。
　　我们特别要求 CPU 对这段数据不要拷贝到缓存，只保留于内存，这是一段连续的内存区域。
　　假设我们执行的指令长这样，首先有个 if 判断语句：  if(name === ＂code秘密花园＂){   // ... }
　　一般来讲，CPU 执行会先无视这个判断，因为它需要等待内存返回  name  的值是不是等于 code秘密花园 ，因为有预测执行这样的技术，if 语句中的东西会被预先执行。 if(name === ＂code秘密花园＂){   access Tools[A[x]] }
　　我们尝试读取  Tools  的第（A的第X元素）个元素。假如我们读到的这个受害者内存中包含 3 :
　　这是我们不应该读取到的，但是我们可以通过预测执行做下面的事情：
　　CPU  执行了这个不应该被执行的命令后，CPU  认为它需要看一下 A[X]  的值是什么，这时 CPU  并未检查 A[X]  是否已经下标越界，因为 CPU  认为之后内核总会验证下标是否越界，如果越界就强制结束程序。
　　于是，预测执行就直接查询了  A[X]  的值，然后发现 A[X] = 3 ，也就是： Tools[A[x]] = Tools[3]
　　也就是我们实际内存中  Tools  存储的第四个元素 a ，下面重点来了：
　　CPU 访问到  a  后，将 a （即Tools[3] ） 放入了高速缓存！
　　最后一步，就是遍历  Tool  中的每一个元素，我们发现访问前几个元素都有点慢，直到访问到第 3 个突然很快！因为第 3 个元素 a  在缓存中存储了一份！
　　当预测执行发现错误的时候，它就会回滚寄存器的变化，但是不会回滚高速缓存！
　　信息就这样的被泄漏了，因为访问第  3  个元素所需时间比其他要短！这也就是基于时间的旁路。
　　于是，我们知道 ＂受害者＂ 在内存的这个位置有个  3 。
　　接下来，我们可以把  Tools  的内存区域搞得更大，你就可以猜出其他更多的数据！当然，这就是实际去攻击需要考虑的失去了  给Web带来的影响
　　上面的原理我们已经分析清楚了，实际上使用  JavaScript  实现这个攻击非常容易，在 JavaScript  里几乎所有的边界检查都可以被绕过，从而实现任意内存边界读取。
　　为此浏览器出了很多的安全策略来解决这个问题，比如：  浏览器策略缓存推荐设置为了防止中间层缓存，建议设置： Cache-Control: private  建议设置适当的二级缓存  key ：如果我们请求的响应是跟请求的 Cookie  相关的，建议设置：Vary: Cookie
　　这下应该更明白为要这俩缓存配置了吧，浏览器没有权利把缓存干掉，它只能做到最大程度的收紧缓存的宽松程度，增加攻击的难度。  禁用高分辨率计时器
　　要利用  旁路攻击 ，攻击者需要精确测量从内存中读取某个值所需的时间。所以需要一个可靠且准确的计时器。
　　浏览器提供的一个  performance.now() API  ，时间精度可以精确到 5  微秒。作为一种缓解措施，所有主要浏览器都降低了 performance.now()  的分辨率，这可以提高攻击的难度。
　　获得高分辨率计时器的另一种方法是使用  SharedArrayBuffer 。web worker  使用 Buffer  来增加计数器。主线程可以使用这个计数器来实现计时器。浏览器就是因为这个原因禁用了 SharedArrayBuffer 。 rel=＂noopener＂
　　浏览器  Context Group  是一组共享相同上下文的 tab、window  或 iframe  。例如，如果网站（https://a.example ）打开弹出窗口（https://b.example ），则打开器窗口和弹出窗口共享相同的浏览上下文，并且它们可以通过 DOM API  相互访问，例如 window.opener 。
　　所以浏览器推荐大家在打开不信任的外部页面时指定  rel=＂noopener＂  。 跨源开放者策略（COOP）
　　利用 旁路攻击 ，攻击者可以读取到在统一浏览器下任意 Context Group  下的资源。
　　COOP ：跨源开放者政策，对应的 HTTP Header  是 Cross-Origin-Opener-Policy 。
　　通过将  COOP  设置为 Cross-Origin-Opener-Policy: same-origin ，可以把从该网站打开的其他不同源的窗口隔离在不同的浏览器 Context Group ，这样就创建的资源的隔离环境。
　　详细的可以看我这篇文章：新的跨域策略：使用COOP、COEP为浏览器创建更安全的环境  跨源嵌入程序政策（COEP）
　　COEP ：跨源嵌入程序政策，对应的 HTTP Header  是 Cross-Origin-Embedder-Policy 。
　　启用  Cross-Origin-Embedder-Policy: require-corp ，你可以让你的站点仅加载明确标记为可共享的跨域资源，或者是同域资源。
　　详细的也不多介绍了，其实都在这篇文章里讲过了：新的跨域策略：使用COOP、COEP为浏览器创建更安全的环境  跨域读取阻止（CORB）
　　即使所有不同源的页面都处于自己单独的进程中，页面仍然可以合法的请求一些跨站的资源，例如图片和  JavaScript  脚本，有些恶意网页可能通过   元素来加载包含敏感数据的 JSON  文件。
　　如果没有  站点隔离  ，则 JSON  文件的内容会保存到渲染器进程的内存中，此时，渲染器会注意到它不是有效的图像格式，并且不会渲染图像。但是，攻击者随后可以利用 旁路攻击  之类的漏洞来潜在地读取该内存块。
　　跨域读取阻止（ CORB ）可以根据其 MIME  类型防止 balance  内容进入渲染器进程内存中。
　　详细的原理，可以看这篇文章：跨域，不止CORS  最后
　　浏览器做了这么多的策略，其实只能说可以在一定程度上缓解这个漏洞，实际上并不能从根源上消除，因为本质上  旁路攻击  还是一个硬件层面上的漏洞、提升漏洞的攻击成本。
　　这个漏洞本身也很难解，无论是预测执行还是缓存，做了限制就代表性能会大大降低，所以硬件层面上也一直没有解决这个问题。  参考https://www.bilibili.com/video/av18144159/  https://zhuanlan.zhihu.com/p/32784852