Glittering's blog

Appearance

一、为什么 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 保护
text
bank.com Wasm → Renderer A
evil.com Wasm → Renderer B

即使 Wasm 被攻破：

  • 不能跨站
  • 不能访问 OS

2️⃣ OS 级沙箱 ​

Renderer 进程：

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

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

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

这是 Wasm 最核心的安全点。

1️⃣ 没有“任意指针” ​

c
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 在执行前：

  • 先验证字节码
  • 控制流合法
  • 类型正确
  • 栈平衡
text
非法模块 → 拒绝加载

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

1️⃣ 编译流程 ​

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

安全策略 ​

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

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

即使是 JIT：

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

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

Wasm 不能主动：

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

只能：

js
imported_function()

👉 JS 是 能力代理（Capability Broker）

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

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

举例 ​

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

Wasm 只能：

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

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

七、Wasm vs JS：谁更危险？ ​

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

💡 现实中：

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

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

❌ 不能 ​

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

⚠️ 可能的风险 ​

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

九、Wasm + CSP 安全策略 ​

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

⚠️ Wasm 受：

  • script-src
  • wasm-unsafe-eval（新）
http
script-src 'self' 'wasm-unsafe-eval';

👉 默认更严格

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

攻击链（极难） ​

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

👉 Chrome 安全目标：

让这条链几乎不可行

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

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

Copyright © 2026