WebAssembly（Wasm）
# 一、为什么 WebAssembly 在安全上“看起来很危险”？
先直觉判断：
| 特性 | 安全风险 |
|---|---|
| 接近原生速度 | 类似本地代码 |
| 显式内存 | 容易越界 |
| 可被编译 | 难静态分析 |
| 常来自第三方 | 供应链风险 |
👉 如果 Wasm 能随便访问系统，浏览器安全直接崩溃
所以：
Wasm 从设计之初就是“被关在笼子里的原生代码”
# 二、Chrome 中 Wasm 的整体安全位置
操作系统
↑
Chrome OS Sandbox
↑
Renderer Process
↑
V8 Wasm Engine
↑
WebAssembly Module
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
👉 Wasm 并没有更高权限 👉 它只是 Renderer 里的一个执行引擎
# 三、第一道防线：进程级隔离（Chrome）
# 1️⃣ Wasm 跑在哪？
- Renderer Process
- 与 JS 同级
- 受 Site Isolation 保护
bank.com Wasm → Renderer A
evil.com Wasm → Renderer B
1
2
2
即使 Wasm 被攻破：
- 不能跨站
- 不能访问 OS
# 2️⃣ OS 级沙箱
Renderer 进程：
- 不能读写任意文件
- 不能调用系统 API
- 不能执行系统指令
👉 Wasm 没有“系统调用”概念
# 四、第二道防线：Wasm 的语言级安全模型 ⭐⭐⭐⭐⭐
这是 Wasm 最核心的安全点。
# 1️⃣ 没有“任意指针”
int* p = (int*)0xdeadbeef; // ❌ Wasm 中不存在
1
Wasm：
- 只有 线性内存（Linear Memory）
- 地址 = 偏移量
# 2️⃣ 线性内存模型
Linear Memory
├── 0x0000
├── ...
├── 0x10000
1
2
3
4
2
3
4
访问必须：
- 显式 bounds check
- 越界直接 trap
👉 不能读 Renderer 内存 👉 不能读 JS Heap
# 3️⃣ 不可执行数据（W^X）
- Wasm 内存 ≠ 可执行
- Code Space 与 Data Space 分离
👉 防止：
- shellcode 注入
- JIT spraying
# 4️⃣ 模块验证（Validation）
Wasm 在执行前：
- 先验证字节码
- 控制流合法
- 类型正确
- 栈平衡
非法模块 → 拒绝加载
1
# 五、第三道防线：V8 Wasm 引擎
# 1️⃣ 编译流程
Wasm Binary
↓
Decoder & Validator
↓
Liftoff（baseline compiler）
↓
TurboFan（优化编译）
1
2
3
4
5
6
7
2
3
4
5
6
7
# 安全策略
- 先快编译
- 再安全优化
- 随时可回退
# 2️⃣ 边界检查永不移除（关键）
即使是 JIT：
- memory bounds check 不能被优化掉
- 这是 Wasm 设计硬约束
# 3️⃣ 与 JS 的交互是“受控的”
Wasm 不能主动：
- 访问 DOM
- 发网络请求
- 调用系统 API
只能：
imported_function()
1
👉 JS 是 能力代理（Capability Broker）
# 六、第四道防线：能力模型（Capability-based Security）
Wasm 本身没有能力，能力来自宿主
# 举例
const wasm = new WebAssembly.Instance(module, {
env: {
log: console.log
}
})
1
2
3
4
5
2
3
4
5
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';
1
2
3
2
3
⚠️ Wasm 受：
script-srcwasm-unsafe-eval（新）
script-src 'self' 'wasm-unsafe-eval';
1
👉 默认更严格
# 十、真实攻击视角（非常重要）
# 攻击链（极难）
恶意 Wasm
↓
V8 Wasm JIT bug
↓
突破 Wasm sandbox
↓
突破 Renderer sandbox
↓
OS
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
👉 Chrome 安全目标：
让这条链几乎不可行
# 十一、“WebAssembly 安全模型”终极答案
WebAssembly 在 Chrome 中运行于 Renderer 进程内，受 Site Isolation 和操作系统沙箱保护；其语言层通过线性内存、边界检查、不可执行数据和模块验证实现强内存安全；同时通过能力模型限制其只能调用宿主显式暴露的接口，从而在高性能的同时保持严格的安全隔离。
上次更新: 2026/01/07, 09:20:46