沙盒：页面和系统之间的隔离墙|浏览器篇
# 沙盒：页面和系统之间的隔离墙
30 秒速记
- 单进程浏览器把多个功能放在同一进程中，一个模块异常就可能造成页面卡死或整个浏览器崩溃。
- 更严重的风险来自浏览器自身漏洞：恶意页面可能借助缓冲区溢出等缺陷进入浏览器进程。
XSS的影响范围主要在页面环境，可窃取包括Cookie在内的数据，但按原文讨论的边界，它不能直接攻击操作系统。- 利用浏览器系统级漏洞的攻击可以读取或修改进程内存，并可能进一步安装恶意软件、监听键盘或读取磁盘文件。
- 分析浏览器安全时，需要区分页面脚本注入和获得浏览器进程控制权，两者的权限范围与破坏程度不同。
单进程浏览器的问题不只是容易整体崩溃，更危险的是浏览器漏洞可能让恶意页面接触操作系统。 一个功能异常就可能拖垮整个浏览器，而缓冲区溢出等漏洞还可能让攻击者进入浏览器进程，读取或修改其中的内容。这里要和 XSS 区分开：XSS 主要在页面环境中执行脚本、窃取 Cookie 等数据，按原文边界不能直接攻击操作系统。浏览器进程被控制后，攻击者则可能安装恶意软件、监听键盘或读取磁盘文件，破坏范围大得多。
从稳定性视角来看，单进程架构的浏览器是不稳定的，因为只要浏览器进程中的任意一个功能出现异常都有可能影响到整个浏览器，如页面卡死、浏览器崩溃等。不过浏览器的稳定性并不是本文讨论的重点，我们今天主要聊的是浏览器架构是如何影响到操作系统安全的
浏览器本身的漏洞是单进程浏览器的一个主要问题，如果浏览器被曝出存在漏洞，那么在这些漏洞没有被及时修复的情况下，黑客就有可能通过恶意的页面向浏览器中注入恶意程序，其中最常见的攻击方式是利用缓冲区溢出，不过需要注意这种类型的攻击和 XSS 注入的脚本是不一样的
- XSS 攻击只是将恶意的 JavaScript 脚本注入到页面中，虽然能窃取一些 Cookie 相关的数据，但是 XSS 无法对操作系统进行攻击。
- 而通过浏览器漏洞进行的攻击是可以入侵到浏览器进程内部的，可以读取和修改浏览器进程内部的任意内容，还可以穿透浏览器，在用户的操作系统上悄悄地安装恶意软件、监听用户键盘输入信息以及读取用户硬盘上的文件内容。
和 XSS 攻击页面相比，这类攻击无疑是枚“核弹”，它会将整个操作系统的内容都暴露给黑客，这样我们操作系统上所有的资料都是不安全的了。
面试官追问
追问 1支付页发生 XSS，攻击脚本成功读取了非 HttpOnly 的 Cookie，安全同学据此认定用户硬盘文件也已全部泄露，你怎么纠正这个结论？
现有证据只能说明攻击者获得了页面脚本权限，不能证明其已经读取硬盘。XSS 与利用浏览器漏洞控制浏览器进程不是同一层攻击；若要触及操作系统资源，还需要额外突破浏览器进程及其安全边界，但仍应立即按敏感会话泄露处置。
追问 2广告页加载一张特制图片后，浏览器进程出现异常，安全团队怀疑图片解码触发了缓冲区溢出；你会怎样区分它与普通 XSS 并确定处置优先级？
图片内容若利用浏览器漏洞取得进程内部控制能力，其风险高于仅在页面中执行恶意 JavaScript 的 XSS。应先隔离样本、确认受影响浏览器并推动漏洞修复，同时检查是否存在安装恶意软件、键盘监听或文件读取迹象；仅凭崩溃仍不能断言攻击已经成功。
追问 3一款老式单进程浏览器同时打开二十个页面，其中一个页面解析异常后整个程序退出，产品经理认为这只是页面兼容性问题，你会怎么判断？
整体退出直接暴露了单进程架构的故障扩散风险，因为任一功能异常都可能拖垮整个浏览器。若异常还能被恶意页面稳定触发，就不能只按兼容性缺陷处理，还要评估它是否利用浏览器漏洞进入进程内部并威胁操作系统。
追问 4线上用户反馈访问某资讯页后出现浏览器崩溃和键盘输入异常，但页面代码里没找到可疑脚本；排查时你会先验证哪些攻击边界？
不能因页面中没有可疑 JavaScript 就排除攻击，应同时检查浏览器崩溃信息、资源样本和是否存在进程级漏洞利用。重点区分页面层 XSS 与浏览器进程被控制后的系统级行为；键盘异常只是风险信号，未取得证据前不宜直接归因。
追问 5架构评审中有人主张只加强前端转义就足以保护用户操作系统，因此无需投入浏览器漏洞修复，你会如何反驳？
前端转义主要降低 XSS 注入风险，无法修复图片解码、解析器或其他浏览器内部的系统级漏洞。浏览器漏洞一旦被利用，攻击者可能控制进程内容并进一步触及操作系统；两类防线保护的边界不同，不能用其中一种替代另一种。
# 安全视角下的多进程架构
30 秒速记
- 现代浏览器通过多进程划分同时服务于安全、速度和稳定性目标。
- 原文将核心结构分为浏览器内核与渲染内核：前者包含浏览器主进程、网络进程和
GPU进程，后者对应渲染进程。 - 网络资源由浏览器内核下载，再经
IPC交给渲染进程进行解析和绘制。 - 渲染进程生成页面图像后，不直接展示，而是经
IPC提交给浏览器内核完成显示。 - 这套链路增加了进程间通信和工程复杂度，但为限制渲染进程直接接触网络及系统能力提供了架构基础。
现代浏览器采用多进程架构，是为了同时兼顾安全、速度和稳定性，并隔离高风险的页面渲染工作。 浏览器内核负责网络请求和最终显示，渲染进程负责解析资源、绘制页面，双方通过 IPC 传递数据和页面图像。这样做看起来绕了一层，却避免了渲染进程直接请求网络或操作展示相关的系统能力。它的取舍是进程间通信和工程实现更复杂，但也为后续限制渲染进程权限提供了架构基础。
现代浏览器的设计目标是安全、快速和稳定，而这种核弹级杀伤力的安全问题就是一个很大的潜在威胁，因此在设计现代浏览器的体系架构时，需要解决这个问题。
观察上图，我们知道浏览器被划分为浏览器内核和渲染内核两个核心模块，其中浏览器内核是由网络进程、浏览器主进程和 GPU 进程组成的，渲染内核就是渲染进程。那如果我们在浏览器中打开一个页面，这两个模块是怎么配合的呢？
所有的网络资源都是通过浏览器内核来下载的，下载后的资源会通过 IPC 将其提交给渲染进程（浏览器内核和渲染进程之间都是通过 IPC 来通信的）。然后渲染进程会对这些资源进行解析、绘制等操作，最终生成一幅图片。但是渲染进程并不负责将图片显示到界面上，而是将最终生成的图片提交给浏览器内核模块，由浏览器内核模块负责显示这张图片。
设计现代浏览器体系架构时，将浏览器划分为不同的进程是为了增加其稳定性。虽然设计成了多进程架构，不过这些模块之间的沟通方式却有些复杂，也许你还有以下问题：
- 为什么一定要通过浏览器内核去请求资源，再将数据转发给渲染进程，而不直接从进程内部去请求网络资源？
- 为什么渲染进程只负责生成页面图片，生成图片还要经过 IPC 通知浏览器内核模块，然后让浏览器内核去负责展示图片？
通过以上方式不是增加了工程的复杂度吗？
要解释现代浏览器为什么要把这个流程弄得这么复杂，我们就得从系统安全的角度来分析。
面试官追问
追问 1性能评审中有人要求让商品详情页的渲染进程直接下载上百张图片，以省掉浏览器内核到渲染进程的一次 IPC，你会接受这个改动吗？
不能只凭少一次 IPC 就接受，因为该架构明确由浏览器内核统一下载资源，再把数据交给渲染进程解析和绘制。职责拆分虽然增加通信复杂度，却为限制渲染进程能力和建立系统安全边界提供基础；具体性能收益还需实测，不能预设更快。
追问 2视频页面已经在渲染进程生成最终画面，客户端同学想让它直接写入窗口，认为再提交给浏览器内核只是重复工作，你怎么评审？
按该架构，渲染进程负责解析、绘制并生成图像，最终界面展示仍由浏览器内核完成。直接赋予渲染进程展示等更高层能力会改变既有职责边界；即使能缩短链路，也必须先评估安全隔离和异常扩散风险。
追问 3同一浏览器打开十个业务标签页，其中一个渲染进程因解析异常退出，测试人员据此宣称多进程架构能保证其余页面永不受影响，这个结论成立吗？
多进程划分能降低局部异常拖垮整个浏览器的概率，但不能推出其余页面永远不受影响。浏览器内核、GPU 进程及 IPC 链路仍是协作的一部分，原文也未承诺完全故障隔离，因此结论应限定为稳定性增强而非绝对保证。
追问 4线上页面白屏，但网络面板显示资源已下载，渲染进程也生成了图像；值班同学只准备排查前端绘制代码，你会补查哪段链路？
还应检查渲染进程向浏览器内核提交最终图像的 IPC，以及浏览器内核负责显示图像的环节。资源下载成功和渲染完成都不能证明最终展示成功；若高权限模块或跨进程通信异常，只看页面侧日志可能无法定位。
追问 5浏览器团队讨论回退单进程架构以降低模块通信复杂度，业务方强调页面首屏优先，你会如何说明这项取舍？
单进程可能减少部分跨进程协作，却会让任一功能异常更容易影响整个浏览器，并削弱后续安全隔离的架构基础。现代架构增加 IPC 和模块协调成本，是用工程复杂度换取稳定性与安全边界；是否优化应针对具体链路，而不是整体撤销进程划分。
# 安全沙箱
30 秒速记
- 浏览器默认把网络资源视为不可信输入，因为解析
HTML、解析CSS、执行JavaScript和图片编解码都可能触发实现漏洞。 - 安全沙箱位于渲染进程与操作系统之间，目标是在渲染进程失陷后继续限制其进程外权限。
- 沙箱依赖操作系统提供的安全能力，阻止渲染进程直接访问或修改系统数据。
- 渲染进程需要系统资源时，必须委托浏览器内核处理，再通过
IPC接收结果。 - 沙箱的最小保护单位是进程；单进程浏览器需要直接操作大量系统资源，难以套用这种隔离方式，而多进程架构提供了实施前提。
安全沙箱本质上是在渲染进程和操作系统之间加一道隔离墙，即使渲染进程被攻破，也要把权限限制在进程内。 浏览器默认网络内容不可信，因为解析 HTML、CSS，执行 JavaScript 或进行图片编解码时，都可能触发实现漏洞。渲染进程需要访问系统资源时，必须委托浏览器内核处理，再通过 IPC 获取结果。沙箱最小保护单位是进程，所以频繁直接操作系统资源的单进程浏览器难以使用这种机制，多进程架构是它发挥作用的前提。
不过在解释这些问题之前，我们得先看看什么是安全沙箱。
上面我们分析过了，由于渲染进程需要执行 DOM 解析、CSS 解析、网络图片解码等操作，如果渲染进程中存在系统级别的漏洞，那么以上操作就有可能让恶意的站点获取到渲染进程的控制权限，进而又获取操作系统的控制权限，这对于用户来说是非常危险的。
因为网络资源的内容存在着各种可能性，所以浏览器会默认所有的网络资源都是不可信的，都是不安全的。但谁也不能保证浏览器不存在漏洞，只要出现漏洞，黑客就可以通过网络内容对用户发起攻击。
我们知道，如果你下载了一个恶意程序，但是没有执行它，那么恶意程序是不会生效的。同理，浏览器之于网络内容也是如此，浏览器可以安全地下载各种网络资源，但是如果要执行这些网络资源，比如解析 HTML、解析 CSS、执行 JavaScript、图片编解码等操作，就需要非常谨慎了，因为一不小心，黑客就会利用这些操作对含有漏洞的浏览器发起攻击。
基于以上原因，我们需要在渲染进程和操作系统之间建一道墙，即便渲染进程由于存在漏洞被黑客攻击，但由于这道墙，黑客就获取不到渲染进程之外的任何操作权限。将渲染进程和操作系统隔离的这道墙就是我们要聊的安全沙箱
浏览器中的安全沙箱是利用操作系统提供的安全技术，让渲染进程在执行过程中无法访问或者修改操作系统中的数据，在渲染进程需要访问系统资源的时候，需要通过浏览器内核来实现，然后将访问的结果通过 IPC 转发给渲染进程。
安全沙箱最小的保护单位是进程。因为单进程浏览器需要频繁访问或者修改操作系统的数据，所以单进程浏览器是无法被安全沙箱保护的，而现代浏览器采用的多进程架构使得安全沙箱可以发挥作用。
