下载本文 PDF 版本 PDF

浏览器安全：来自 Google Chrome 的经验教训

Google Chrome 开发者专注于三个关键问题，以保护浏览器免受攻击。

Charles Reis，Google

Adam Barth，加州大学伯克利分校

Carlos Pizano，Google

Web 已成为人们与计算机交互的主要方式之一，将人们与各种各样的内容、服务和应用程序连接起来。用户可以轻松地在 Web 上找到新的和有趣的内容，但这带来了一个安全挑战：恶意网站运营者可以通过用户的 Web 浏览器攻击用户。浏览器面临着在为 Web 应用程序提供丰富平台的同时，保障用户安全的挑战。

浏览器是攻击者极具吸引力的目标，因为它们拥有庞大而复杂的受信任计算基础，并具有广泛的网络可见接口。从历史上看，每个浏览器在某个时候都包含一个漏洞，该漏洞允许恶意网站运营者绕过浏览器的安全策略并危害用户的计算机。即使在这些漏洞被修补之后，许多用户仍然继续运行较旧、易受攻击的版本。5 当这些用户访问恶意网站时，他们面临着计算机被入侵的风险。

一般来说，用户面临的危险来自三个因素，浏览器供应商可以通过解决这些因素来帮助保障用户的安全

这些缓解措施中的每一项，单独来看，都能提高安全性。综合起来，这些好处成倍增加，并有助于保障用户在当今 Web 上的安全。

在本文中，我们将讨论我们的团队如何使用这些技术来提高 Google Chrome 的安全性。我们希望我们的第一手经验能够阐明与所有浏览器开发者相关的关键安全问题。

降低漏洞严重性

在理想的世界中，包括浏览器在内的所有软件都将没有错误并且缺乏可利用的漏洞。不幸的是，每个大型软件都包含错误。鉴于这一现实，我们可以希望通过隔离浏览器的复杂组件并降低其权限来降低漏洞的严重性。

如图 1 所示，Google Chrome 结合了多层防御来保护用户免受错误的影响。Web 内容本身在 JavaScript 虚拟机中运行，该虚拟机充当沙盒的一种形式，并保护不同的网站免受彼此的影响。我们使用利用屏障，例如地址空间布局随机化，以使利用 JavaScript 沙箱中的漏洞更加困难。然后，我们在操作系统级别使用沙箱来限制进程本身造成损害，即使漏洞利用逃脱了早期的安全机制。在本节中，我们将更详细地讨论如何使用这些防御层。

Google Chrome incorporates several layers of defenses to protect the user from bugs.

安全架构

Google Chrome 使用模块化架构，将复杂的渲染引擎放置在低权限沙箱中，我们在另一份报告中对此进行了深入讨论。1 Google Chrome 有两个主要组件在不同的操作系统进程中运行：高权限浏览器内核和低权限渲染引擎。浏览器内核以用户的权限运行，负责绘制用户界面、存储 cookie 和历史记录数据库以及提供网络访问。渲染引擎代表 Web 主体运行，并且不被信任与用户的文件系统交互。渲染引擎解析 HTML、执行 JavaScript、解码图像、绘制到屏幕外缓冲区，并执行渲染网页所需的其他任务。

为了缓解渲染引擎中的漏洞，Google Chrome 在限制性操作系统级别的沙箱内运行渲染引擎进程（参见图 1）。沙箱旨在防止渲染引擎与其他进程和用户的操作系统进行交互，除非通过 IPC 通道与浏览器内核交换消息。所有 HTTP 流量、渲染页面和用户输入事件都通过此类消息交换。

为了防止渲染引擎直接与操作系统交互，我们在 Windows 上实现的沙箱使用受限制的 Windows 安全令牌、一个单独且不可见的 Windows 桌面和一个受限制的 Windows 作业 12对象运行。这些安全机制阻止访问用户计算机上的任何文件、设备和其他资源。即使攻击者能够利用漏洞并在渲染引擎中运行任意代码，沙箱也会阻止攻击者尝试在用户计算机上安装恶意软件或从用户的硬盘驱动器读取敏感文件。攻击者的代码可以通过 IPC 通道向浏览器内核发送消息，但我们的目标是保持此接口简单且受限。

使渲染引擎等现有代码库在这种类型的沙箱中完全工作有时会带来工程挑战。例如，渲染引擎通常直接从系统的字体目录加载字体文件，但我们的沙箱不允许此类文件访问。幸运的是，Windows 维护着已加载字体的系统级内存缓存。因此，我们可以在沙箱外部的浏览器内核进程中加载任何所需的字体，然后渲染引擎进程就可以从缓存中访问它们。

我们本可以使用许多其他技术来沙盒化操作系统进程，以替代我们当前的沙箱。例如，Internet Explorer 7 使用“低权限”模式，旨在阻止对文件系统的不必要写入。4 其他技术包括系统调用拦截（最近在 Xax2 中看到）或二进制重写（在 Native Client14 中看到）。Mac OS X 具有操作系统提供的沙箱，Linux 进程可以使用 AppArmor 和其他技术进行沙盒化。对于 Windows，我们选择了当前的沙箱，因为它是一种成熟的技术，旨在为用户的资源提供保密性和完整性。随着我们将 Google Chrome 移植到 Mac 和 Linux 等其他平台，我们希望使用许多不同的沙箱技术，但保持相同的安全架构。

漏洞利用缓解

Google Chrome 还通过使用 Windows 程序推荐的多种屏障，使漏洞更难被利用。8 这些屏障包括 DEP（数据执行保护）、ASLR（地址空间布局随机化）、SafeSEH（安全异常处理程序）、堆损坏检测和堆栈溢出检测 (GS)。这些在最新版本的 Windows 中可用，并且一些浏览器已采用它们来阻止漏洞利用。

这些屏障使攻击者在尝试利用漏洞时更难以跳转到他们期望的恶意代码。例如，DEP 使用硬件和操作系统支持将内存页标记为 NX（不可执行）。CPU 在获取的每个指令上强制执行此操作，如果指令属于 NX 页，则生成陷阱。堆栈页可以标记为 NX，这可以防止堆栈溢出攻击运行放置在受损堆栈区域中的恶意指令。DEP 也可用于其他区域，例如堆和环境块。

堆栈溢出检测 (GS) 是一种编译器选项，它在当前堆栈顶部和最后一个返回地址之间的每个堆栈调用中插入一个特殊的金丝雀值。在每个返回指令之前，编译器都会插入对正确金丝雀值的检查。由于许多堆栈溢出攻击都试图覆盖返回地址，因此它们也很可能覆盖金丝雀值。攻击者无法轻易猜测金丝雀值，因此插入的检查通常会捕获攻击并终止进程。

复杂的攻击可能会尝试使用所有进程内存空间中可预测地址的已知值来绕过 DEP 和 GS 屏障。ASLR 在 Windows Vista 和 Windows 7 中可用，它通过随机化映射到几乎每个进程中的关键系统组件的位置来对抗这种情况。

如果使用得当，即使攻击者可以利用漏洞，这些机制也可以帮助阻止攻击者运行任意代码。我们建议所有浏览器（实际上，所有程序）都采用这些缓解措施，因为它们可以在不进行重大架构更改的情况下应用。

兼容性挑战

使用深度防御的安全架构的主要挑战之一是保持与现有 Web 内容的兼容性。人们不太可能使用与其喜爱的网站不兼容的浏览器，从而否定了通过破坏兼容性可能获得的任何安全优势。例如，Google Chrome 必须支持 Flash Player 和 Silverlight 等插件，以便用户可以访问 YouTube 等热门网站。但是，这些插件并非设计为在沙箱中运行，并且它们期望直接访问底层操作系统。这使他们能够实现全屏视频聊天等功能，并可以访问整个屏幕、用户的网络摄像头和麦克风。Google Chrome 目前不在沙箱中运行这些插件，而是依靠其各自的供应商来维护其自身的安全性。

在使用浏览器架构来强制执行同源策略（将网站彼此隔离）时，也存在兼容性挑战。Google Chrome 通常将来自不同网站的页面放入不同的渲染引擎进程中，11 但在所有情况下都这样做可能很困难，而这对于安全性是必要的。例如，某些框架可能需要从其父页面在不同的进程中渲染，并且需要在来自不同来源的页面之间进行一些 JavaScript 调用。目前，Google Chrome 有时会将来自不同来源的页面放在同一进程中。此外，每个渲染引擎进程都可以访问用户的所有 cookie，因为来自一个来源的页面可以从不同的来源请求图像、脚本和其他对象，每个来源都可能具有关联的 cookie。因此，我们尚未依赖 Google Chrome 的架构来强制执行同源策略。

最近，一些研究人员已经试验了浏览器（例如 OP7 和 Gazelle13），这些浏览器试图通过将不同的来源分隔到不同的进程中并调解它们的交互来强制执行同源策略。这是一个令人兴奋的研究领域，但在这些设计与 Web 充分兼容之前，仍然存在需要克服的挑战。例如，在这些提议中，支持现有插件以及页面之间的通信并不总是很简单。随着这些隔离技术的改进，所有浏览器都将受益。

缩短漏洞窗口期

即使在我们降低了漏洞的严重性之后，漏洞利用仍然可能对用户造成损害。例如，一个错误可能允许恶意网站运营者绕过同源策略并从其他网站（例如电子邮件）读取信息。为了降低用户的危险，Google Chrome 旨在最大限度地缩短用户运行未修补浏览器版本的时间。我们通过自动化我们的质量保证流程并在最大程度地减少对用户体验的干扰的情况下更新用户来实现此目标。

自动化测试

在发现漏洞后，Google Chrome 团队在向用户发布安全补丁之前，会经历一个三步过程

  1. 值班安全主管会评估漏洞的严重性，并分配一名工程师来解决该问题。
  2. 工程师诊断漏洞的根本原因，并编写补丁来修复该错误。通常，安全补丁就像添加一个缺失的边界检查一样简单，但其他补丁可能需要更广泛的手术。
  3. 修补后的二进制文件将通过质量保证流程，以确保 (a) 问题确实已修复；以及 (b) 补丁没有破坏其他功能。

对于像 Web 浏览器这样复杂的软件系统，步骤 3 通常是响应安全问题的瓶颈，因为回归测试需要确保每个浏览器功能都正常运行。

Google Chrome 团队已投入大量精力来尽可能多地自动化步骤 3。该团队继承了来自 WebKit 项目的 10,000 多个测试，这些测试确保 Web 平台功能正常运行。这些测试以及针对浏览器级功能的数千个其他测试在每次更改浏览器源代码后都会运行。

除了这些回归测试之外，浏览器构建还在一个名为 ChromeBot 的虚拟机场中的 100 万个网站上进行测试。ChromeBot 监控这些站点的渲染，以查找内存错误、崩溃和挂起。在将浏览器构建发布给用户之前，通过 ChromeBot 运行浏览器构建通常会暴露细微的竞争条件和其他低概率事件。

安全更新

一旦构建符合发布给用户的条件，团队仍然面临更新旧版本用户的挑战。除了将更新后的位发布给每个用户的技术挑战之外，有效更新过程中的主要挑战是最终用户体验。如果更新过程过于具有破坏性，用户将推迟安装更新并继续使用不安全的版本。5

Google Chrome 使用最近开源的名为 Omaha 的系统来分发更新。6 Omaha 每五个小时自动检查软件更新。当有新更新可用时，会根据团队设置的概率告知一部分客户端。此概率使团队可以在通知所有客户端之前验证发布的质量。当客户端被告知有更新时，它会在与当前二进制文件平行的目录中下载并安装更新后的二进制文件。下次用户运行浏览器时，旧版本会服从新版本。

此更新过程与 Web 应用程序的更新过程类似。用户的体验永远不会中断，并且用户永远不必等待进度条才能使用浏览器。在实践中，这种方法已被证明对于保持用户更新有效。最近对 Google 匿名日志中的 HTTP User-Agent 标头的研究揭示了用户采用各种浏览器修补版本的速度有多快。3 我们在图 2 中重现了他们的结果。在这些测量中，与其他浏览器相比，Google Chrome 的自动更新机制在最短的时间内更新了绝大多数用户。（Internet Explorer 未包含在这些结果中，因为其次要版本号未在 User-Agent 标头中报告。）

A recent study of HTTP User-Agent headers reveals how quickly users adopt patched versions of various browsers.

降低暴露频率

即使具有强化的安全架构和较小的漏洞窗口期，用户仍面临来自恶意网站运营者的风险。在某些情况下，浏览器通过在渲染恶意内容之前警告用户来阻止用户访问已知恶意网站。Google Chrome 和其他浏览器已采用此方法，如果用户尝试访问已报告包含恶意软件或网络钓鱼尝试的内容，则会显示警告页面。Google 与 StopBadware.org 合作维护此类站点的最新数据库，所有浏览器都可以使用该数据库。

使用此类数据库的一个挑战是保护隐私。用户不希望他们访问的每个 URL 都报告给集中式服务。相反，浏览器定期下载 URL 哈希的有效列表，而无需直接查询服务。为了减少所需的空间，仅下载 256 位 URL 哈希的 32 位前缀。此列表将与恶意站点列表进行比较。如果找到前缀的匹配项，浏览器将查询服务以获取该前缀的完整 256 位哈希以执行完整比较。

另一个挑战是最大限度地减少误报。Google 和 StopBadware.org 拥有工具来帮助发布商从数据库中删除其页面（如果在托管恶意软件后已清理）。人为错误也可能错误地标记站点，正如 2009 年 1 月发生的事件一样，该事件将所有 URL 标记为危险。9 但是，此类错误通常会很快得到修复，并且可以添加安全措施以防止它们再次发生。

这些服务也存在漏报，因为并非 Web 上的每个恶意页面都可以在每个时间点编入目录。尽管 Google 和 StopBadware.org 试图识别尽可能多的恶意页面，10 但它不太可能是一个完整的列表。尽管如此，这些黑名单有助于保护用户免受攻击。

结论

没有提供完美安全浏览器的灵丹妙药，但浏览器开发者可以使用多种技术来帮助保护用户。这些技术中的每一种都有其自身的一系列挑战。

特别是，浏览器应使用三种技术最大限度地减少用户面临的危险

Google Chrome 团队已专注于这些因素中的每一个，以帮助提供安全的浏览器，同时保持与现有 Web 内容的兼容性。为了使 Google Chrome 更加安全，我们正在调查对浏览器安全架构的进一步改进，例如减轻插件漏洞利用可能造成的损害，以及使用单独的沙盒进程更彻底地隔离不同的网站。最终，我们的目标是将门槛提高到足以阻止攻击者将浏览器作为目标。问

参考文献
  1. Barth, A., Jackson, C., Reis, C., 和 Google Chrome 团队. 2008. Chromium 浏览器的安全架构；http://crypto.stanford.edu/websec/chromium/chromium-security-architecture.pdf.
  2. Douceur, J.R., Elson, J., Howell, J., Lorch, J.R. 2008. 利用遗留代码在 Web 上部署桌面应用程序。在操作系统设计与实现 (OSDI) 会议论文集中。
  3. Duebendorfer, T., Frei, S. 2009. 为什么静默更新可以提高安全性。ETH 技术报告 TIK 302；http://www.techzoom.net/silent-updates.
  4. Franco, R. 2005. 澄清低权限 IE。IEBlog（六月）；http://blogs.msdn.com/ie/archive/2005/06/09/427410.aspx.
  5. Frei, S., Duebendorfer, T., Plattner, B. 2009. Firefox (不)安全更新动态曝光。 SIGCOMM 计算机通信评论 39(1).
  6. Google. Omaha：Windows 的软件安装程序和自动更新程序。Google 代码；http://code.google.com/p/omaha/.
  7. Grier, C., Tang, S., King, S.T. 2008. 使用 OP Web 浏览器进行安全 Web 浏览。在IEEE 安全与隐私研讨会论文集中。
  8. Howard, M., Thomlinson, M. 2007. Windows Vista ISV 安全性；http://msdn.microsoft.com/en-us/library/bb430720.aspx.
  9. Mayer, M. 2009. 每个搜索结果上都显示“此网站可能会损害您的计算机”。官方 Google 博客（一月）；http://googleblog.blogspot.com/2009/01/this-site-may-harm-your-computer-on.html.
  10. Provos, N., McNamee, D., Mavrommatis, P., Wang, K., Modadugu, N. 2007. 浏览器中的幽灵：基于 Web 的恶意软件分析。在第一届 Usenix Botnet 热点主题研讨会论文集（四月）中。
  11. Reis, C. Gribble, S.D. 2009. 现代浏览器架构中隔离 Web 程序。在欧洲计算机系统会议 (Eurosys) 论文集（四月）中。
  12. 沙箱。Chromium 开发者文档。2008；http://dev.chromium.org/developers/design-documents/sandbox.
  13. Wang, H. J., Grier, C., Moshchuk, A.,King, S. T., Choudhury, P.,Venter, H. 2009. Gazelle Web 浏览器的多主体操作系统构建。Microsoft Research 技术报告 (MSR-TR-2009-16)；http://research.microsoft.com/pubs/79655/gazelle.pdf.
  14. Yee, B., Sehr, D., Dardyk, G., Chen, J. B., Muth, R., Ormandy, T., Okasaka, S., Narul, N., Fullagar, N. 2009. Native Client：用于可移植、不受信任的 x86 本机代码的沙箱。在IEEE 安全与隐私研讨会论文集中。

喜欢它，讨厌它？请告诉我们

[email protected]

Charles Reis 是 Google 的一名软件工程师，致力于 Google Chrome Web 浏览器。他最近在华盛顿大学计算机科学与工程系完成了博士学位。他的研究重点是提高 Web 浏览器和 Web 内容的可靠性和安全性。他获得了莱斯大学计算机科学学士和硕士学位。在莱斯大学，他是 DrJava 的第二位首席开发人员，DrJava 是一种广泛使用的教育编程环境。

Adam Barth 是加州大学伯克利分校的博士后研究员。他的研究重点是现代 Web 浏览器的安全性，包括其安全策略、强制执行机制和安全用户界面。他是 Chromium、WebKit 和 Firefox 开源项目的贡献者，并且是 W3C HTML 和 Web 应用程序工作组的特邀专家。他拥有斯坦福大学计算机科学博士和硕士学位，以及康奈尔大学计算机科学和数学学士学位。

Carlos Pizano 是 Google 的一名高级软件工程师，致力于 Google Chrome Web 浏览器。他拥有新墨西哥大学计算机工程硕士学位和哈维里亚纳大学电气工程学士学位。他的工作重点是面向 Internet 的应用程序的安全性和沙箱化。

© 2009 1542-7730/09/0600 $10.00

acmqueue

最初发表于 Queue 第 7 卷，第 5 期—
在 数字图书馆 中评论本文




更多相关文章

Paul Vixie - 走向静态或回家
当前和历史上计算机和网络安全中的大多数问题都归结为一个简单的观察：让其他人控制我们的设备对我们不利。在另一篇文章中，我将解释我所说的“其他人”和“不利”是什么意思。就本文而言，我将完全关注我所说的控制是什么意思。我们失去对设备控制的一种方式是外部分布式拒绝服务 (DDoS) 攻击，这种攻击用不需要的流量填充网络，从而没有空间容纳真实的（“需要的”）流量。其他形式的 DDoS 类似：例如，低轨道离子炮 (LOIC) 的攻击可能不会完全填满网络，但它可以使 Web 服务器忙于响应无用的攻击请求，以至于服务器无法响应任何有用的客户请求。


Axel Arnbak, Hadi Asghari, Michel Van Eeten, Nico Van Eijk - HTTPS 市场中的安全崩溃
HTTPS（超文本传输协议安全）已发展成为安全 Web 浏览的事实标准。通过基于证书的身份验证协议，Web 服务和 Internet 用户首先使用 TLS/SSL 证书相互验证身份（“握手”），端到端加密 Web 通信，并在浏览器中显示挂锁以指示通信是安全的。近年来，HTTPS 已成为保护在线社交、政治和经济活动的重要技术。


Sharon Goldberg - 为什么保护 Internet 路由需要这么长时间？
BGP（边界网关协议）是将 Internet 粘合在一起的粘合剂，使不同组织运营的大型网络之间能够进行数据通信。BGP 通过为组织之间的流量设置路由来使 Internet 通信全球化 - 例如，从波士顿大学的网络，通过更大的 ISP（Internet 服务提供商），例如 Level3、巴基斯坦电信和中国电信，然后到住宅网络，例如 Comcast 或企业网络，例如美国银行。


Ben Laurie - 证书透明度
2011 年 8 月 28 日，一个为 google.com 错误颁发的通配符 HTTPS 证书被用于对伊朗的多个用户进行中间人攻击。该证书由一家名为 DigiNotar 的荷兰 CA（证书颁发机构）颁发，DigiNotar 是 VASCO Data Security International 的子公司。后来的分析表明，DigiNotar 早在一个多月前（至少自 7 月 19 日起）就已意识到其系统中的漏洞。它还表明，至少颁发了 531 个欺诈性证书。最终计数可能永远不会为人所知，因为 DigiNotar 没有所有错误颁发的证书的记录。



© 保留所有权利。

© . All rights reserved.