从chrome v8 讲安全

# 一、Chrome 整体架构：安全是“设计出来的”

# 1️⃣ Chrome 为什么必须多进程？

一句话：

把不可信的网页，关进不同的笼子里

早期浏览器（单进程）：

JS / DOM / 网络 / UI 在一起
一个漏洞 = 整个浏览器崩溃

Chrome 的核心思想：

稳定性 = 安全性

# 2️⃣ Chrome 核心进程划分（必考）

Browser Process（大脑）
 ├── Renderer Process（网页）
 ├── Network Process（网络）
 ├── GPU Process（图形）
 └── Utility Process（解码/存储）

1
2
3
4
5

# 各进程安全职责

进程	安全作用
Browser	权限仲裁、UI
Renderer	不可信 JS
Network	统一网络策略
GPU	防止显卡攻击

# 二、Renderer 进程：网页的“监狱”

Renderer 是最危险的地方

# Renderer 里有什么？

Blink（DOM / CSS）
V8（JS 引擎）
JS Heap
DOM Tree

# 1️⃣ Site Isolation（关键安全机制）⭐⭐⭐⭐⭐

不同站点 → 不同 Renderer 进程

# 为什么？

防止：

XSS 后横向读取其他站点数据
Spectre 跨站侧信道攻击

example.com → Renderer A
bank.com     → Renderer B

1
2

iframe 不同源：

也会进不同进程

# 2️⃣ 即使 XSS 成功，也只能拿到什么？

能力	是否能
当前站点 Cookie	✅
其他站点 Cookie	❌
本地文件	❌
操作系统	❌

👉 进程隔离是最后一道防线

# 三、V8 架构：JS 引擎如何“自我保护”

# 1️⃣ V8 的执行层级

JS Source
  ↓
Parser
  ↓
Ignition（解释器）
  ↓
TurboFan（JIT 编译）

1
2
3
4
5
6
7

⚠️ 安全问题主要出现在：

JIT 优化
内存管理

# 2️⃣ V8 内存模型（攻击重点）

Heap
 ├── New Space（短命对象）
 ├── Old Space
 ├── Code Space
 └── Large Object Space

1
2
3
4
5

# JS 不能：

随意访问内存
指针运算
读写任意地址

👉 这是 V8 安全的第一层

# 3️⃣ JIT 为什么是“高危区”？

因为：

会做激进假设（类型稳定）
会跳过检查
有 bug = 越界读写

真实漏洞：

type confusion
out-of-bounds

# 4️⃣ V8 如何降低 JIT 风险？

1️⃣ 多层校验

Ignition（慢但安全）
TurboFan（快但可回退）

2️⃣ 去优化（Deopt）

假设失效 → 回退解释执行

3️⃣ Pointer Compression

减少可利用空间

# 四、V8 + Chrome：双重沙箱

# 1️⃣ Renderer 进程沙箱

OS 级 sandbox
禁止系统调用
文件系统隔离

# 2️⃣ V8 自身沙箱（Sandboxing）

即使拿到 RCE，也困在 V8 内

Heap 边界检查
Wasm sandbox
隔离 Code / Data

# 五、Spectre：为什么它改变了一切？

# 问题本质

CPU 乱序执行
可跨进程泄露数据

# Chrome 应对

手段	作用
Site Isolation	最关键
禁用高精度 Timer	防侧信道
ArrayBuffer 隔离	防内存探测

# 六、一个真实攻击路径（你应该知道）

XSS
 ↓
利用 JIT bug
 ↓
逃逸 V8 沙箱
 ↓
突破 Renderer 沙箱
 ↓
攻击操作系统

1
2
3
4
5
6
7
8
9

👉 Chrome 的目标：

让每一步都极难

# 七、为什么前端工程师也要懂这些？

因为你每天在做：

eval
动态 script
第三方 SDK
iframe
WebAssembly

👉 都在触碰安全边界

# 八、面试“Chrome / V8 安全”标准答案模板

Chrome 通过多进程架构和 Site Isolation 将不同站点隔离在不同 Renderer 进程中；Renderer 进程运行在操作系统沙箱内，限制系统资源访问；V8 引擎通过内存隔离、边界检查和 JIT 回退机制防止 JS 越界执行，从而形成多层防御体系。

上次更新: 2026/01/07, 09:20:46

← 浏览器安全模型 WebAssembly（Wasm）→