一、为什么 WebAssembly 在安全上“看起来很危险”？

先直觉判断：

特性	安全风险
接近原生速度	类似本地代码
显式内存	容易越界
可被编译	难静态分析
常来自第三方	供应链风险

👉 如果 Wasm 能随便访问系统，浏览器安全直接崩溃

所以：

Wasm 从设计之初就是“被关在笼子里的原生代码”

二、Chrome 中 Wasm 的整体安全位置

操作系统
  ↑
Chrome OS Sandbox
  ↑
Renderer Process
  ↑
V8 Wasm Engine
  ↑
WebAssembly Module

👉 Wasm 并没有更高权限 👉 它只是 Renderer 里的一个执行引擎

三、第一道防线：进程级隔离（Chrome）

1️⃣ Wasm 跑在哪？

• Renderer Process
• 与 JS 同级
• 受 Site Isolation 保护

bank.com Wasm → Renderer A
evil.com Wasm → Renderer B

即使 Wasm 被攻破：

• 不能跨站
• 不能访问 OS

2️⃣ OS 级沙箱

Renderer 进程：

• 不能读写任意文件
• 不能调用系统 API
• 不能执行系统指令

👉 Wasm 没有“系统调用”概念

四、第二道防线：Wasm 的语言级安全模型 ⭐⭐⭐⭐⭐

这是 Wasm 最核心的安全点。

1️⃣ 没有“任意指针”

int* p = (int*)0xdeadbeef; // ❌ Wasm 中不存在

Wasm：

• 只有 线性内存（Linear Memory）
• 地址 = 偏移量

2️⃣ 线性内存模型

Linear Memory
 ├── 0x0000
 ├── ...
 ├── 0x10000

访问必须：

• 显式 bounds check
• 越界直接 trap

👉 不能读 Renderer 内存 👉 不能读 JS Heap

3️⃣ 不可执行数据（W^X）

• Wasm 内存 ≠ 可执行
• Code Space 与 Data Space 分离

👉 防止：

• shellcode 注入
• JIT spraying

4️⃣ 模块验证（Validation）

Wasm 在执行前：

• 先验证字节码
• 控制流合法
• 类型正确
• 栈平衡

非法模块 → 拒绝加载

五、第三道防线：V8 Wasm 引擎

1️⃣ 编译流程

Wasm Binary
  ↓
Decoder & Validator
  ↓
Liftoff（baseline compiler）
  ↓
TurboFan（优化编译）

安全策略

• 先快编译
• 再安全优化
• 随时可回退

2️⃣ 边界检查永不移除（关键）

即使是 JIT：

• memory bounds check 不能被优化掉
• 这是 Wasm 设计硬约束

3️⃣ 与 JS 的交互是“受控的”

Wasm 不能主动：

• 访问 DOM
• 发网络请求
• 调用系统 API

只能：

imported_function()

👉 JS 是 能力代理（Capability Broker）

六、第四道防线：能力模型（Capability-based Security）

Wasm 本身没有能力，能力来自宿主

举例

const wasm = new WebAssembly.Instance(module, {
  env: {
    log: console.log
  }
})

Wasm 只能：

• 调用 log
• 不能调用 alert
• 不能访问 document

👉 这是最强的安全模型之一

七、Wasm vs JS：谁更危险？

维度	JS	Wasm
内存安全	❌（JIT Bug）	✅（强校验）
执行权限	低	低
性能	中	高
攻击面	大	小

💡 现实中：

V8 的高危漏洞更多来自 JS JIT，不是 Wasm

八、Wasm 能攻击什么？不能攻击什么？

❌ 不能

• 绕过同源策略
• 访问 Cookie
• 操作 DOM
• 直接发请求
• 调系统 API

⚠️ 可能的风险

• DoS（死循环）
• Spectre 侧信道（已缓解）
• JIT 漏洞（极少）

九、Wasm + CSP 安全策略

Content-Security-Policy:
  script-src 'self';
  object-src 'none';

⚠️ Wasm 受：

• script-src
• wasm-unsafe-eval（新）

script-src 'self' 'wasm-unsafe-eval';

👉 默认更严格

十、真实攻击视角（非常重要）

攻击链（极难）

恶意 Wasm
 ↓
V8 Wasm JIT bug
 ↓
突破 Wasm sandbox
 ↓
突破 Renderer sandbox
 ↓
OS

👉 Chrome 安全目标：

让这条链几乎不可行

十一、“WebAssembly 安全模型”终极答案

WebAssembly 在 Chrome 中运行于 Renderer 进程内，受 Site Isolation 和操作系统沙箱保护；其语言层通过线性内存、边界检查、不可执行数据和模块验证实现强内存安全；同时通过能力模型限制其只能调用宿主显式暴露的接口，从而在高性能的同时保持严格的安全隔离。