发布于 由admin

JS 引擎对 `SharedArrayBuffer` 的安全限制：幽灵漏洞（Spectre）防护与站点隔离策略

各位来宾，各位技术同仁，大家好。

今天，我们将深入探讨一个在现代Web开发中既带来巨大潜能，又引发深刻安全考量的话题：JavaScript引擎对SharedArrayBuffer的安全限制。我们将聚焦于“幽灵漏洞”（Spectre）防护以及浏览器所采取的站点隔离策略，理解这些限制背后的技术原理、历史演进以及对Web开发实践的深远影响。

SharedArrayBuffer的崛起：Web并发的曙光

在JavaScript的世界里，并发处理一直是一个挑战。传统的Web Workers通过消息传递（postMessage）实现与主线程的通信，但每次传递数据时，如果数据结构复杂或体积庞大，都需要进行序列化和反序列化，这会引入显著的性能开销，因为数据实际上是被“复制”而不是“共享”的。这使得在Worker之间或者Worker与主线程之间高效地共享大型数据集变得困难。

SharedArrayBuffer（简称SAB）的出现，正是为了解决这一痛点。它提供了一种在多个执行上下文（主线程和Web Workers）之间共享内存的机制，而无需进行数据复制。想象一下，你有一块巨大的白板，所有的画家（线程）都可以在上面同时创作，而不是每个人都拿到一块白板的副本。

什么是SharedArrayBuffer？

SharedArrayBuffer是一种特殊的ArrayBuffer，其内容可以被多个Web Worker或主线程同时访问。它代表了一个固定长度的原始二进制数据缓冲区，一旦创建，其大小就不能改变。

// 创建一个大小为1KB的SharedArrayBuffer
const sharedBuffer = new SharedArrayBuffer(1024);

// 基于SharedArrayBuffer创建一个视图，例如Int32Array
// 这个视图可以被多个线程共享
const sharedInt32Array = new Int32Array(sharedBuffer);

console.log(`SharedArrayBuffer创建成功，大小为 ${sharedBuffer.byteLength} 字节。`);
console.log(`Int32Array视图创建成功，包含 ${sharedInt32Array.length} 个32位整数。`);
console.log(`初始值：${Atomics.load(sharedInt32Array, 0)}`); // 使用Atomics确保原子性操作

Atomics：共享内存的守护神

仅仅共享内存是不够的，如果多个线程同时读写同一块内存区域，就会出现竞态条件（race condition），导致数据损坏或不可预测的行为。为了解决这个问题，JavaScript提供了Atomics对象。Atomics提供了一组静态方法，用于执行原子性的共享内存操作。原子性意味着这些操作是不可中断的，要么完全执行，要么不执行，从而保证了数据的一致性。

常用的Atomics方法包括：

  • Atomics.load(typedArray, index): 原子性地读取指定索引的值。
  • Atomics.store(typedArray, index, value): 原子性地写入指定索引的值。
  • Atomics.add(typedArray, index, value): 原子性地对指定索引的值进行加法操作。
  • Atomics.sub(typedArray, index, value): 原子性地对指定索引的值进行减法操作。
  • Atomics.and(typedArray, index, value): 原子性地对指定索引的值进行按位与操作。
  • Atomics.or(typedArray, index, value): 原子性地对指定索引的值进行按位或操作。
  • Atomics.xor(typedArray, index, value): 原子性地对指定索引的值进行按位异或操作。
  • Atomics.exchange(typedArray, index, value): 原子性地将指定索引的值替换为新值，并返回旧值。
  • Atomics.compareExchange(typedArray, index, expectedValue, replacementValue): 原子性地比较指定索引的值与expectedValue，如果相等则替换为replacementValue，并返回旧值。
  • Atomics.wait(typedArray, index, value, timeout): 阻塞等待，直到指定索引的值不再是value，或者超时。
  • Atomics.notify(typedArray, index, count): 唤醒在指定索引上等待的一个或多个线程。

这些方法是实现高效并发算法（如锁、信号量、无锁队列等）的基础。

代码示例：一个简单的生产者-消费者模型

让我们通过一个生产者-消费者模型来演示SharedArrayBuffer和Atomics的强大之处。我们将创建一个共享缓冲区，一个生产者Worker将数据写入其中，一个消费者Worker将数据从中读取。

<!-- index.html -->
<!DOCTYPE html>
<html>
<head>
    <title>SharedArrayBuffer Producer-Consumer Demo</title>
</head>
<body>
    <h1>SharedArrayBuffer Producer-Consumer Demo</h1>
    <p>请打开控制台查看Worker的输出。</p>
    <button id="startWorkers">启动生产者和消费者</button>
    <script>
        const startButton = document.getElementById('startWorkers');
        let producerWorker = null;
        let consumerWorker = null;

        startButton.addEventListener('click', () => {
            if (self.crossOriginIsolated) {
                console.log("页面已跨域隔离，SharedArrayBuffer可用。");

                // 创建一个SharedArrayBuffer，用于存储数据和状态
                // 索引0: 缓冲区中的数据
                // 索引1: 生产者写入数据的标志 (0: 空, 1: 有数据)
                const sharedBuffer = new SharedArrayBuffer(Int32Array.BYTES_PER_ELEMENT * 2);
                const sharedArray = new Int32Array(sharedBuffer);

                // 初始化状态
                Atomics.store(sharedArray, 1, 0); // 初始状态为“空”

                console.log("主线程: SharedArrayBuffer初始化完成。");

                producerWorker = new Worker('producer.js');
                consumerWorker = new Worker('consumer.js');

                producerWorker.postMessage({ sharedBuffer });
                consumerWorker.postMessage({ sharedBuffer });

                producerWorker.onmessage = (e) => {
                    console.log(`主线程收到生产者消息: ${e.data}`);
                };
                consumerWorker.onmessage = (e) => {
                    console.log(`主线程收到消费者消息: ${e.data}`);
                };

            } else {
                console.error("页面未进行跨域隔离。SharedArrayBuffer不可用。请确保设置了COOP和COEP头。");
            }
        });
    </script>
</body>
</html>
// producer.js (Web Worker)
onmessage = (e) => {
    const { sharedBuffer } = e.data;
    const sharedArray = new Int32Array(sharedBuffer);
    let counter = 0;

    function produce() {
        // 等待缓冲区为空 (状态为0)
        console.log("生产者: 尝试写入数据...");
        // Atomics.wait会阻塞，直到sharedArray[1]的值不再是0，或者超时
        // 这里我们期望它为0，表示消费者已经取走了数据
        Atomics.wait(sharedArray, 1, 1); // 阻塞直到 sharedArray[1] == 1 (即消费者取走了数据，将状态重置为0)

        // 此时 sharedArray[1] 应该是 0 (消费者已将其设置为0)
        // 写入数据
        Atomics.store(sharedArray, 0, counter++);
        console.log(`生产者: 写入数据 ${sharedArray[0]}`);

        // 设置状态为1，表示有数据可供消费
        Atomics.store(sharedArray, 1, 1);
        // 唤醒所有等待在sharedArray[1]上的消费者
        Atomics.notify(sharedArray, 1, Infinity);

        if (counter < 10) { // 生产10个数据
            setTimeout(produce, 1000);
        } else {
            postMessage("生产者: 任务完成。");
            console.log("生产者: 任务完成。");
            // 可选：发送一个特殊值通知消费者停止
            Atomics.store(sharedArray, 0, -1); // 哨兵值
            Atomics.store(sharedArray, 1, 1);
            Atomics.notify(sharedArray, 1, Infinity);
        }
    }

    // 初始生产
    produce();
};
// consumer.js (Web Worker)
onmessage = (e) => {
    const { sharedBuffer } = e.data;
    const sharedArray = new Int32Array(sharedBuffer);

    function consume() {
        // 等待缓冲区有数据 (状态为1)
        console.log("消费者: 尝试读取数据...");
        // Atomics.wait会阻塞，直到sharedArray[1]的值不再是1，或者超时
        // 这里我们期望它为1，表示生产者已经写入了数据
        Atomics.wait(sharedArray, 1, 0); // 阻塞直到 sharedArray[1] == 0 (即生产者已写入数据，将状态重置为1)

        // 此时 sharedArray[1] 应该是 1 (生产者已将其设置为1)
        const data = Atomics.load(sharedArray, 0);
        console.log(`消费者: 读取到数据 ${data}`);

        if (data === -1) { // 检查哨兵值
            postMessage("消费者: 接收到停止信号，任务完成。");
            console.log("消费者: 接收到停止信号，任务完成。");
            return;
        }

        // 设置状态为0，表示缓冲区为空，可供生产者写入
        Atomics.store(sharedArray, 1, 0);
        // 唤醒所有等待在sharedArray[1]上的生产者
        Atomics.notify(sharedArray, 1, Infinity);

        setTimeout(consume, 1500); // 模拟消费延迟
    }

    // 初始消费
    consume();
};

要运行这个示例，index.html需要通过一个本地HTTP服务器提供服务，并且该服务器需要设置特定的HTTP响应头（我们稍后会详细讨论）。

SAB和Atomics为Web应用程序带来了真正的多线程计算能力，使得复杂的计算、游戏物理引擎、视频处理等性能敏感型任务可以在Web Workers中并行执行，从而显著提升用户体验。然而，这种强大的能力也伴随着巨大的安全风险。

幽灵漏洞（Spectre）：CPU的阿喀琉斯之踵

2018年初，一系列与CPU设计相关的安全漏洞被披露，震惊了整个技术界，其中最著名的就是“幽灵”（Spectre）和“熔断”（Meltdown）。这些漏洞并非软件错误，而是利用了现代CPU为了提高性能而采用的“乱序执行”（out-of-order execution）和“推测执行”（speculative execution）等高级特性。

推测执行的原理

为了充分利用CPU资源，现代处理器不会严格按照程序指令的顺序执行。它们会提前预测程序接下来可能要执行的分支，并先行执行这些预测到的指令。如果预测正确，那么结果就直接生效，省去了等待时间；如果预测错误，CPU会回滚（rollback）这些推测执行的结果，就好像它们从未发生过一样。从逻辑上讲，推测执行是不可见的，因为它不会改变程序的最终结果。

Spectre如何利用推测执行

Spectre攻击的核心思想是，虽然推测执行的结果会被回滚，但其在CPU内部留下的“副作用”——特别是对CPU缓存的影响——却可能不会被完全清除。

攻击者可以精心构造一段代码，诱导CPU在推测执行模式下访问其本无权访问的内存区域（例如，来自另一个进程的敏感数据）。即使CPU最终发现预测错误并回滚了数据读取操作，但这次“非法”的访问会在CPU的L1/L2/L3缓存中留下痕迹。

随后，攻击者可以通过测量访问不同内存地址所需的时间来判断哪些数据在缓存中（缓存命中速度快），哪些数据不在缓存中（缓存未命中速度慢）。通过这种“侧信道”（side channel）分析，攻击者可以逐步推断出被推测性访问的敏感数据的值。这个过程就像是观察一个幽灵，它虽然没有留下实体，但却在环境中留下了可观测的涟漪。

Spectre与JavaScript的结合：一个危险的组合

为什么Spectre对JavaScript，特别是对SharedArrayBuffer构成了如此大的威胁？

  1. 高精度计时器： JavaScript提供了performance.now()等高精度计时器，以及Atomics.wait()的精确超时机制。这些计时器能够测量微秒甚至纳秒级别的延迟，这正是进行缓存侧信道攻击所必需的工具。攻击者需要精确测量内存访问时间，以区分缓存命中和缓存未命中。
  2. SharedArrayBuffer： SharedArrayBuffer允许在多个线程之间共享内存，这为攻击者构建“定时器”或“探测器”提供了极其便利的工具。攻击者可以在一个Worker中诱导推测执行，并在另一个Worker中通过访问共享内存并测量时间来观察缓存状态的变化。SAB甚至可以被用来构建基于内存的计时器，以绕过浏览器对performance.now()精度的限制。
  3. JIT编译器的复杂性： 现代JavaScript引擎（如V8、SpiderMonkey）使用即时编译（JIT）技术，将JavaScript代码编译成高度优化的机器码。JIT编译器为了性能，可能会生成一些对推测执行更友好的代码，或者使得攻击者更容易控制推测执行的条件。

总结来说，SAB、高精度计时器与推测执行的CPU特性结合，使得恶意网站理论上能够从同一浏览器进程中的其他网站（甚至可能来自用户操作系统）读取敏感数据，例如登录凭据、个人信息等。这是一种极其严重的跨域信息泄露漏洞。

初步反应：SharedArrayBuffer的短暂“撤回”

当Spectre漏洞在2018年初被披露时，浏览器厂商面临着一个严峻的选择：如何快速有效地保护用户？由于Spectre是CPU层面的漏洞，无法通过简单的软件补丁完全修复。而JavaScript中的SharedArrayBuffer和高精度计时器是实施Spectre攻击的关键工具。

因此，浏览器厂商采取了最直接、最快速的缓解措施：

  • 禁用SharedArrayBuffer： 谷歌Chrome、Mozilla Firefox和Apple Safari等主流浏览器迅速地在默认情况下禁用了SharedArrayBuffer功能。这意味着，即使你的代码中使用了SAB，它也会表现得像一个普通的ArrayBuffer，或者直接抛出错误。
  • 降低高精度计时器精度： performance.now()的精度被大幅降低，从微秒级降至几十微秒甚至100微秒。这使得进行精确的缓存定时攻击变得极其困难。

这一举措虽然有效地遏制了Spectre在Web环境中的直接威胁，但也给依赖SAB进行高性能计算的Web应用程序带来了巨大的影响。许多WebAssembly应用程序（例如某些游戏引擎、CAD工具等）也受到了冲击，因为它们常常依赖SAB来实现高效的线程间通信。Web开发者们被迫寻找替代方案，或者等待更长期的解决方案。

迈向安全重启用：站点隔离与跨域隔离策略

浏览器的禁用SAB策略是权宜之计。Web平台的目标是提供更强大的能力，而不是永久地限制它们。因此，浏览器厂商和Web标准组织开始积极寻求一种既能保护用户免受Spectre攻击，又能重新启用SharedArrayBuffer的方案。

这个方案的核心思想是：通过在操作系统层面和Web应用策略层面进行隔离，使得即使发生推测执行攻击，攻击者也无法访问到不属于自己源（origin）的敏感数据。

1. 站点隔离（Site Isolation）：进程级的防御

谷歌Chrome团队率先推出了“站点隔离”架构。其核心理念是：将不同源的网站内容放置在完全独立的操作系统进程中。

  • 工作原理： 当你在Chrome中打开多个标签页，访问example.com和malicious.com时，example.com的所有内容（包括其iframe和子资源）都将在一个独立的渲染进程中运行，而malicious.com的内容则在另一个完全独立的渲染进程中运行。
  • 安全优势： 即使一个渲染进程被恶意代码攻破（例如，通过一个JavaScript漏洞），它也只能访问到该进程内部的数据，而无法直接访问其他进程中的数据。操作系统级别的内存保护机制确保了不同进程之间的严格隔离。这使得Spectre攻击即使能泄露本进程内的数据，也无法轻易地跨越进程边界去窃取其他网站的敏感信息。
  • 局限性： 站点隔离增加了内存开销。此外，它主要针对的是不同主文档之间的隔离。如果一个页面嵌入了大量的跨域iframe，这些iframe可能仍然共享一些浏览器内部资源，或者存在其他潜在的侧信道。

站点隔离为Spectre防护提供了坚实的基础，但为了重新启用像SharedArrayBuffer这样高风险的功能，还需要更进一步的、针对Web内容加载和交互的策略。

2. 跨域隔离（Cross-Origin Isolation）：COOP与COEP的组合拳

为了实现完全的跨源隔离，确保Web页面能够安全地使用SharedArrayBuffer和高精度计时器，浏览器引入了两个新的HTTP响应头：Cross-Origin-Opener-Policy (COOP) 和 Cross-Origin-Embedder-Policy (COEP)。当一个页面同时设置了这两个头，并且满足其要求时，它就被认为是“跨域隔离”的（Cross-Origin Isolated）。

只有在页面处于“跨域隔离”状态时，SharedArrayBuffer和高精度计时器（如performance.now()）才会被完全启用。

2.1 Cross-Origin-Opener-Policy (COOP)

COOP头主要用于隔离窗口和标签页，防止它们之间进行跨源通信。

  • 目的： 防止恶意页面通过window.opener等方式，获取到打开它的页面或它打开的页面的引用，从而进行DOM操作、信息窃取等攻击。
  • 可用值：
    • same-origin: 这是最严格的策略。如果一个文档设置了COOP: same-origin，那么它打开的任何跨源窗口（通过window.open()）都将会在一个不同的浏览上下文组中打开，彼此之间无法通过window.opener等属性进行交互。同样，如果它被一个跨源窗口打开，window.opener也将为null。
    • same-origin-allow-popups: 允许当前文档打开的弹出窗口与当前文档保持相同的浏览上下文组，前提是这些弹出窗口也来自同源。但如果弹出窗口是跨源的，则仍会被隔离。
    • unsafe-none: 这是默认行为，不施加任何限制。

示例：
如果 https://example.com/index.html 设置了：
Cross-Origin-Opener-Policy: same-origin

当 index.html 打开 https://malicious.com/evil.html 时，evil.html 的 window.opener 将为 null。
当 https://another.com/page.html 打开 index.html 时，index.html 的 window.opener 也将为 null。

COOP确保了不同源的顶级文档在不同的进程组中运行，即使它们之间存在父子关系，也无法直接访问彼此的DOM或执行JavaScript。

2.2 Cross-Origin-Embedder-Policy (COEP)

COEP头主要用于限制一个文档可以嵌入哪些跨源资源。

  • 目的： 防止恶意页面嵌入未经授权的跨源资源（如图片、脚本、iframe），这些资源可能被用来进行侧信道攻击，或者暴露敏感信息。
  • 可用值：
    • require-corp: 这是最严格的策略。只有满足以下条件之一的跨源资源才能被嵌入：
      • 资源设置了Cross-Origin-Resource-Policy: cross-origin头。
      • 资源设置了Cross-Origin-Resource-Policy: same-site头，并且来自同一站点。
      • 资源与嵌入它的文档同源。
      • 资源通过CORS（跨域资源共享）加载成功（例如，<img>标签的crossorigin属性）。
    • credentialless: 允许加载不带凭据（如cookies、HTTP认证）的跨源资源。这些资源不需要设置Cross-Origin-Resource-Policy。这对于嵌入不需要用户认证的公共资源很有用，但安全性略低于require-corp。
    • unsafe-none: 默认行为，不施加任何限制。

示例：
如果 https://example.com/index.html 设置了：
Cross-Origin-Embedder-Policy: require-corp

  • 它可以嵌入 https://example.com/image.png (同源)。
  • 它可以嵌入 https://cdn.com/script.js，前提是 cdn.com 服务器为 script.js 响应了 Cross-Origin-Resource-Policy: cross-origin 头。
  • 它不能嵌入 https://malicious.com/ad.png，除非 malicious.com 为 ad.png 响应了 Cross-Origin-Resource-Policy: cross-origin 头，否则浏览器将阻止加载。

COEP确保了在跨域隔离的页面中，所有加载的跨源子资源都必须明确地“选择加入”（opt-in）这种嵌入方式。这构建了一个“围墙花园”，极大地限制了攻击者利用嵌入资源进行侧信道攻击的可能性。

实现跨域隔离：HTTP响应头

为了让一个页面成为“跨域隔离”的，它的HTTP响应必须包含以下两个头：

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

当这些头被正确设置后，浏览器会自动将该页面置于一个特殊的、更严格隔离的环境中，并重新启用SharedArrayBuffer和高精度计时器。

代码示例：跨域隔离环境下的SAB使用

为了演示这一点，我们需要一个Web服务器来设置这些HTTP头。以下是一个Node.js Express服务器的简单示例：

// server.js (Node.js Express)
const express = require('express');
const path = require('path');
const app = express();
const port = 3000;
const crossOriginPort = 3001; // 另一个源的端口

// 主应用
app.use((req, res, next) => {
    // 设置COOP和COEP头，使页面成为跨域隔离
    res.setHeader('Cross-Origin-Opener-Policy', 'same-origin');
    res.setHeader('Cross-Origin-Embedder-Policy', 'require-corp');
    next();
});

app.use(express.static(path.join(__dirname, 'public')));

app.listen(port, () => {
    console.log(`主应用服务器运行在 http://localhost:${port}`);
    console.log(`请访问 http://localhost:${port}/index.html`);
});

// 模拟另一个源的服务器，提供需要COEP的资源
const crossOriginApp = express();
crossOriginApp.use((req, res, next) => {
    // 允许跨域请求
    res.setHeader('Access-Control-Allow-Origin', '*');
    // 设置CORP头，允许被跨域嵌入
    res.setHeader('Cross-Origin-Resource-Policy', 'cross-origin');
    next();
});
crossOriginApp.use(express.static(path.join(__dirname, 'cross-origin-public')));

crossOriginApp.listen(crossOriginPort, () => {
    console.log(`跨域资源服务器运行在 http://localhost:${crossOriginPort}`);
});

目录结构：

project/
├── server.js
├── public/
│   ├── index.html
│   └── producer.js
│   └── consumer.js
└── cross-origin-public/
    └── external-script.js

public/index.html (与前面相同，但请注意crossOriginIsolated检查):

<!DOCTYPE html>
<html>
<head>
    <title>SharedArrayBuffer Producer-Consumer Demo</title>
</head>
<body>
    <h1>SharedArrayBuffer Producer-Consumer Demo</h1>
    <p>请打开控制台查看Worker的输出。</p>
    <button id="startWorkers">启动生产者和消费者</button>
    <script>
        const startButton = document.getElementById('startWorkers');
        let producerWorker = null;
        let consumerWorker = null;

        startButton.addEventListener('click', () => {
            if (self.crossOriginIsolated) {
                console.log("页面已跨域隔离，SharedArrayBuffer可用。");

                const sharedBuffer = new SharedArrayBuffer(Int32Array.BYTES_PER_ELEMENT * 2);
                const sharedArray = new Int32Array(sharedBuffer);
                Atomics.store(sharedArray, 1, 0);

                console.log("主线程: SharedArrayBuffer初始化完成。");

                producerWorker = new Worker('producer.js');
                consumerWorker = new Worker('consumer.js');

                producerWorker.postMessage({ sharedBuffer });
                consumerWorker.postMessage({ sharedBuffer });

                producerWorker.onmessage = (e) => {
                    console.log(`主线程收到生产者消息: ${e.data}`);
                };
                consumerWorker.onmessage = (e) => {
                    console.log(`主线程收到消费者消息: ${e.data}`);
                };

            } else {
                console.error("页面未进行跨域隔离。SharedArrayBuffer不可用。请确保设置了COOP和COEP头。");
                alert("SharedArrayBuffer不可用。请确保页面通过HTTP服务器提供服务，并设置了正确的COOP和COEP头。");
            }
        });
    </script>
    <!-- 尝试嵌入一个跨域资源 -->
    <script src="http://localhost:3001/external-script.js"></script>
</body>
</html>

cross-origin-public/external-script.js:

console.log("外部脚本已加载，来自 http://localhost:3001");

当你运行server.js并通过http://localhost:3000/index.html访问页面时，你会在控制台中看到页面已跨域隔离，SharedArrayBuffer可用。的输出，并且生产者-消费者模型将正常运行。同时，external-script.js也会因为设置了Cross-Origin-Resource-Policy: cross-origin而被成功加载。

检测跨域隔离状态：self.crossOriginIsolated

在JavaScript中，你可以通过检查self.crossOriginIsolated属性来判断当前页面是否处于跨域隔离状态。这是一个布尔值，如果为true，则表示SharedArrayBuffer和高精度计时器可用。

if (self.crossOriginIsolated) {
    console.log("当前页面是跨域隔离的。");
    // 可以安全地使用SharedArrayBuffer和高精度计时器
} else {
    console.log("当前页面不是跨域隔离的。");
    // SharedArrayBuffer不可用，高精度计时器精度降低
}

高精度计时器精度的恢复

与SharedArrayBuffer类似，performance.now()等高精度计时器的精度也会在页面处于“跨域隔离”状态时恢复到最高水平（通常是微秒甚至亚微秒级）。这对于需要精确时间测量的Web应用程序至关重要，例如WebAssembly游戏、音频/视频处理等。

特性/API 非跨域隔离页面 跨域隔离页面
SharedArrayBuffer 不可用（抛出错误或行为异常） 完全可用
Atomics 依赖于SharedArrayBuffer，因此不可用 完全可用
performance.now() 精度降低（例如，100微秒） 恢复高精度（例如，5微秒或更低）
PerformanceObserver 精度降低 恢复高精度
WebAssembly.Memory (growable with shared) 行为受限或不可用 完全可用
WebGPU 部分功能受限 完全可用

对Web开发者的实际影响与挑战

重新启用SharedArrayBuffer的安全策略，虽然解决了Spectre的威胁，但也给Web开发者带来了显著的挑战和迁移成本。

1. 巨大的迁移工作量

对于那些想要利用SharedArrayBuffer或高精度计时器，或者仅仅是嵌入了大量第三方资源的网站来说，实现跨域隔离可能需要大量的工作。

  • 所有嵌入资源必须“选择加入”： 这是最棘手的部分。如果你的页面嵌入了来自不同源的图片、脚本、样式表、字体、视频、iframe等，那么所有这些资源都必须在其HTTP响应头中包含Cross-Origin-Resource-Policy: cross-origin或通过CORS机制明确允许跨域加载。
  • 第三方服务的配合： 许多网站依赖于第三方分析、广告、社交媒体插件、CDN等服务。这些第三方服务提供商需要更新他们的服务器配置，以发送正确的Cross-Origin-Resource-Policy头。如果某个第三方服务未能配合，你的页面就无法实现完全的跨域隔离，也就无法使用SAB。
  • Iframes的特殊处理： 嵌入跨源iframe时，如果iframe内部的文档也需要跨域隔离，它同样需要设置COOP/COEP。如果只是想嵌入一个普通的跨源iframe而不破坏父页面的隔离状态，可以使用<iframe>的credentialless属性或者确保iframe的源也设置了正确的CORP头。

2. CORS与COEP的区别

开发者经常混淆CORS（Cross-Origin Resource Sharing）和COEP。理解它们的区别至关重要：

  • CORS (Access-Control-Allow-Origin):
    • 目的： 允许或拒绝跨域请求的数据访问。
    • 控制方： 资源服务器。
    • 行为： 如果资源服务器允许，客户端脚本可以读取跨域响应。
    • 侧重： 数据的可读性。
  • COEP (Cross-Origin-Embedder-Policy) & CORP (Cross-Origin-Resource-Policy):
    • 目的： 限制跨域资源嵌入到页面中，防止侧信道攻击。
    • 控制方： 嵌入页面（COEP）和资源服务器（CORP）。
    • 行为： 如果资源服务器未设置CORP: cross-origin，即使CORS允许访问，COEP也会阻止资源加载。
    • 侧重： 资源的“可嵌入性”和页面的隔离状态。

简而言之，CORS关心“我能否通过脚本读取这个数据？”，而COEP关心“我能否把这个跨域资源放进我的页面，同时保持我的隔离状态？”。COEP是比CORS更严格的嵌入限制。

3. 开发和调试的复杂性

在开发环境中，你需要确保你的开发服务器能够正确地发送COOP、COEP和CORP头。这可能需要调整Web服务器（如Apache、Nginx）或Node.js/Python等后端框架的配置。同时，调试加载失败的跨域资源也变得更加复杂，因为浏览器会明确地阻止这些资源的加载，并在控制台给出警告或错误。

4. 渐进增强与优雅降级

由于并非所有网站都能立即实现完全的跨域隔离，开发者需要考虑如何优雅地处理SharedArrayBuffer不可用的情况。使用self.crossOriginIsolated进行特性检测，并提供备用方案（例如，退回到postMessage复制数据，或使用WebAssembly单线程版本），是必不可少的。

表格：不同COEP/CORP配置下的资源加载行为

嵌入页面COEP配置 嵌入资源CORP配置 加载行为（假设不同源）
unsafe-none (默认) 任何 允许加载（默认行为，不提供隔离）
require-corp same-origin 阻止加载（资源不是同源）
require-corp same-site 阻止加载（资源不是同源且不是同站点）
require-corp cross-origin 允许加载（资源明确选择允许跨域嵌入）
require-corp 未设置CORP/CORS 阻止加载（除非通过CORS明确允许并带有crossorigin属性）
credentialless 任何 允许加载（但不发送凭据，如cookie）

更广泛的安全视野：Web平台的持续演进

SharedArrayBuffer的旅程——从引入、禁用、到通过严格的跨域隔离策略重新启用——是Web平台安全性发展的一个缩影。它揭示了几个重要的趋势：

  1. 硬件漏洞的软件缓解： Spectre事件表明，即使是底层的CPU硬件漏洞，也需要Web浏览器等上层软件采取复杂的缓解措施来保护用户。
  2. 默认安全的转变： Web平台正在从“默认允许”向“默认拒绝，明确选择加入”的方向发展。COOP和COEP就是这种趋势的体现，它们要求开发者明确声明其意图，以换取更强大的功能。
  3. 浏览器作为安全边界： 现代浏览器不仅仅是渲染网页的工具，它们已经演变为复杂的安全沙箱，负责隔离不同来源的内容，并抵御各种高级攻击。站点隔离是这一趋势的标志性成果。
  4. 性能与安全之间的永恒权衡： SharedArrayBuffer带来了巨大的性能提升潜力，但它的安全性问题迫使我们重新审视这种权衡。最终的解决方案是引入了额外的安全约束，以确保功能的可用性。

除了COOP和COEP，Web平台还在不断探索和引入其他安全机制，例如：

  • Fetch Metadata Request Headers： 允许服务器根据请求的来源、目的地等元数据做出更细粒度的访问控制决策。
  • Trusted Types： 旨在防止DOM XSS攻击，通过确保只有受信任的函数才能创建某些类型的DOM值。
  • WebAssembly沙盒化： 对WebAssembly模块的内存访问和外部交互进行严格控制。

这些机制共同构建了一个日益强大和复杂的Web安全生态系统，以应对不断演变的网络威胁。

结语

SharedArrayBuffer是Web并发编程的基石，为高性能Web应用开启了新的可能。然而，CPU幽灵漏洞的出现，迫使Web浏览器对其进行了严格的安全限制，并最终通过引入站点隔离和跨域隔离策略（COOP/COEP）将其重新启用。这一过程不仅深刻地改变了Web开发者使用SAB的方式，也标志着Web平台在安全性方面迈出了重要一步，优先确保了用户的隐私与安全。未来，Web平台将继续在性能与安全之间寻求最佳平衡，不断演进其架构和安全策略，以应对层出不穷的挑战。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注