迈向2023：浏览器与操作系统安全特性

引言

2022年已悄然结束。与任何行业或生活方面一样，我们不禁展望2023年，思考信息安全格局将如何演变。在传统安全边界栈发生巨变的今天，从云迁移到直接在浏览器中交付的高功能应用，再到终端用户启用的影子IT和零信任安全模型，边界的概念被彻底重新思考，同时也给安全专业人员带来了大量焦虑。

我们必须通过变革来适应这些挑战。坚持城堡和护城河模型的控制幻觉是徒劳的。虽然我可以就这一快速演变的模型带来的众多信息安全影响进行阐述，但我希望暂时聚焦于常用的Windows工作站终端。

终端安全技术的显著进步

在终端方面，我们看到保护操作系统本身的部署安全技术取得了显著进步。终端/扩展检测与响应（EDR/XDR）软件能力已显著成熟，假设部署和调优成熟，使得在Windows终端上的初始入侵和后利用活动都变得极具挑战性。

虽然我们都认为这对行业来说是个好消息，但我们应该问自己，最大化桌面操作系统保护是否仍然像过去那样重要。换句话说，我们必须承认，Web浏览器是日益管理关键业务数据的地方。

自然推论的问题是：浏览器中是否部署了足够的安全技术？这些保护措施能否与操作系统部署的保护相媲美？这些保护措施是否与操作系统级别的防御部署集成？

Google Chrome与Chromium项目

从Web浏览器市场份额来看，Google Chrome显然在采用率方面领先。此外还有基于Google Chromium项目的浏览器，如Opera和Microsoft Edge，后者显著地位居Chrome之后。从这些数据中，我们可以得出结论：Chromium开源项目中的任何安全漏洞都将非常重要，而Chrome和Edge浏览器中的专有安全相关代码也至关重要。

Chrome安全架构

Google团队创建了一个安全架构图，从进程级别角度很好地识别了攻击面。主要关注的目标区域是浏览器进程和渲染器进程。

考虑到上述浏览器架构景观和进程级别关注点，让我们分解一些为应对浏览器安全问题而编写的保护技术。请注意，以下大部分信息都是从Google博客和在线设计文档中研究并稍作改写的。Chrome/Chromium浏览器工作中有几个关键的架构基础和特性是相关的：

• 渲染器沙箱
• 站点隔离（Spectre缓解）
• V8（JavaScript）沙箱（堆利用缓解）
• 改进内存安全
• 面向用户的安全控制

渲染器沙箱

Chromium项目渲染器沙箱遵循健全的基础安全原则。这些原则包括：

• 不重新发明轮子。让操作系统对其控制的对象应用安全措施
• 对沙箱化代码和运行沙箱本身的代码应用最小权限原则
• 始终假设沙箱化代码是恶意的
• 最小化性能影响
• 不使用模拟、代码转换或修补来提供安全

Windows架构是一个用户模式实现。迄今为止没有支持的内核驱动程序。沙箱架构分为两个进程：代理进程和目标进程。代理是执行实际工作的目标进程的监督者。

沙箱限制

渲染器沙箱依赖于Windows操作系统提供的保护，包括使用：

• 高度受限的安全令牌，实现组限制，没有特定权限，并使用"不受信任的完整性级别"
• 用于目标进程的Windows作业对象，实现众多限制
• Windows桌面对象：沙箱创建一个与所有目标进程关联的额外桌面

站点隔离

站点隔离是为了完全重新架构浏览器安全模型，使其更紧密地与操作系统进程安全边界对齐。站点隔离项目既是对渲染引擎成功攻击的第二道防线，也是缓解CPU推测执行内存泄漏攻击（Spectre）的响应。

“站点"概念不像"源"概念那样细粒度。源由协议方案、主机名和端口组成。而站点由有效顶级域（eTLD）加上其前面的域部分定义，也称为eTLD+1。

V8（JavaScript/WASM）沙箱

自2020年中以来，Google的开源JavaScript/Web Assembly引擎（V8）实现了堆管理的指针压缩。这意味着从V8堆中的一个对象到V8堆中另一个对象的每个引用都成为从堆基址的32位偏移量。

压缩指针因此仅在4GB内存范围内有效，这称为指针压缩笼。大多数可利用来破坏内存的漏洞因此只能在这个压缩笼内进行破坏。

V8沙箱项目目标是以防止攻击者滥用的方式保护这些剩余的少数对象。

改进内存安全

2020年期间，Chromium项目研究并发布称，超过70%的高严重性安全缺陷与内存安全相关，其中超过一半是"释放后使用"类型。这具体转化为C/C++语言中指针的错误，导致内存被误解。几乎不用说，这个问题是几十年来普遍影响软件行业的瘟疫。

Chrome一直在探索解决这个问题的途径，包括：

• 通过编译时指针正确性检查使C/C++更安全
• 通过运行时指针正确性检查使C/C++更安全
• 研究对部分Chromium代码库使用内存安全语言

在C/C++安全方面，该项目探索了使用"Miracle Pointers”，这实际上只是一类算法的术语，这些算法将指针使用包装在模板化内存安全C/C++类中。

在内存安全语言实现方面，团队一直在探索Rust作为代码库部分的潜在替代方案。

面向用户的安全控制

Chrome附带了许多面向用户的安全功能，可以帮助减轻初始浏览器利用尝试的风险。这些包括：

• 安全浏览：阻止列表，警告您潜在恶意站点
• 预测性网络钓鱼保护：扫描页面以查看是否匹配已知的虚假或恶意站点
• 隐身模式：也称为隐私浏览模式
• 安全检查：用户驱动的浏览器"安全检查"审计
• 自动更新：Chrome会在有软件更新可用时通知

Chrome扩展

Chrome扩展用于向浏览器添加额外特性和功能。扩展使用与网站相同的技术编写，这些技术是：

• 用于内容标记的HTML
• 用于内容样式的CSS
• 用于脚本逻辑的JavaScript

扩展可以分解为两个组件：内容呈现组件和服务工作器组件。服务工作器作为某种后台任务运行，可以通过消息传递或浏览器本地存储与呈现组件交互。

Chrome扩展正式发布在Chrome网上应用店中。安装时，它们允许开发人员请求（通过MANIFEST）对您的Web浏览器拥有大量权力和控制。

Chrome命令行开关

我们可能都习惯于只是点击Chrome图标并假设Chrome会正常启动，相信一切都按应有的顺序进行。话虽如此，有几个命令行开关可用于在启动时更改Chrome的行为。其中一些开关专门禁用或削弱浏览器的安全功能，通常用于测试/开发目的。

我已经确定了以下开关列表，这些开关要么我已经实验性使用过，要么在恶意软件报告中读到过，或者我怀疑可能带来安全问题。恶意软件杀死Chrome进程然后重新启动Chrome，添加一些命令行开关来更改浏览器的行为（例如加载恶意扩展）并不罕见。

结论思考

很明显，Google非常重视对渲染器和JavaScript引擎的攻击，以及推测执行内存泄漏带来的威胁。因此，他们实施了一个强大的防御架构，尽力减轻带来的风险。

话虽如此，Chrome浏览器终端是一个非常复杂的软件架构。在JavaScript和现在的WebAssembly领域拥有动态编译环境（即时编译器）总是会遭受逻辑缺陷的潜在风险，攻击者可以强制编译器/汇编器引擎发出恶意代码。在V8 JavaScript/WebAssembly空间继续进行的堆保护工作在这里充当了一道防线。

除非整个架构用内存安全语言重写，否则很可能继续发现内存释放后使用缺陷，这 frankly 将是一项巨大的努力。我赞赏在边缘工作的努力，通过提议对最有意义的暴露组件重写到内存安全语言来逐步解决问题。

我还认为我们可能会看到Chrome/Chromium团队在控制流防护和控制流执行技术领域有更多兴趣，这进一步使浏览器不仅与Windows操作系统安全防御对齐，还与CPU硬件对齐。

最后，与过去十年信息安全的大部分情况一样，您无法预测终端用户会做什么。如果终端用户下载恶意软件，进而丢弃恶意扩展和脚本以静默重新启动浏览器，扩展授予的对浏览器的权力暴露了重大的攻击面。我质疑这些命令行开关在Chrome发布版本中是否存在合法的操作用例，并建议发布版本消除大部分此功能以进一步减少攻击面。

祝新年快乐，2023年浏览更安全。