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

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

一句话：

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

早期浏览器（单进程）：

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

Chrome 的核心思想：

稳定性 = 安全性

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

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

各进程安全职责

进程	安全作用
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

iframe 不同源：

• 也会进不同进程

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

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

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

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

1️⃣ V8 的执行层级

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

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

• JIT 优化
• 内存管理

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

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

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 沙箱
 ↓
攻击操作系统

👉 Chrome 的目标：

让每一步都极难

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

因为你每天在做：

• eval
• 动态 script
• 第三方 SDK
• iframe
• WebAssembly

👉 都在触碰安全边界

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

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