在Fenix中寻找安全漏洞的实用技巧（第二部分）——私有浏览模式绕过分析

作者：Muneaki Nishimura
日期：2021年2月9日

本文是漏洞赏金计划参与者撰写的系列客座博客文章之一，旨在分享他们向Mozilla报告的安全漏洞。继第一部分之后，本文介绍了在Fenix中发现安全漏洞的一些实践方法。

Fenix的架构独特。许多浏览器功能并非在Fenix本身实现，而是来自独立且可重用的库，如GeckoView和Mozilla Android Components（简称Mozac）。Fenix作为浏览器应用程序，将这些库组合为内部构建块，而fenix项目本身主要是一个用户界面。Mozac值得注意，因为它将在GeckoView中渲染的Web内容连接到原生Android世界。

在Web内容与原生应用之间的连接中，存在一些常见的陷阱会导致安全漏洞。在本文中，我们将探讨其中一个陷阱：私有浏览模式绕过。在寻找此类漏洞时，我发现了三个独立但相似的问题（Bug 1657251、1658231和1663261）。

私有浏览模式中的陷阱

请看以下两行HTML代码：

1
2


<img src="test1.png">
<link rel="icon" type="image/png" href="test2.png">

尽管这两个HTML标签看起来相似，都从服务器获取并渲染PNG图像，但它们的内部处理方式非常不同。在前者的<img>标签中，GeckoView从服务器获取图像并在HTML文档中渲染；而在后者的<link rel="icon">标签中，它标识页面的favicon，Mozac中的代码获取图像并将其渲染为Android视图的一部分。当我在2020年秋季发现这些漏洞时，从<img>标签发送的HTTP请求在User-Agent头中显示字符串“Firefox”，而从<link rel="icon">发送的请求显示字符串“MozacFetch”。

与其他浏览器一样，GeckoView为普通模式和私有浏览模式提供了分离的上下文。因此，私有浏览模式中的Cookie和本地存储区域与普通模式完全分离，这些值不共享。另一方面，Mozac中的URL获取类（用Kotlin编写）只有一个Cookie存储。如果favicon请求响应中包含Set-Cookie头，它将被存储在该Cookie存储中，随后在私有浏览模式中获取favicon时会使用相同的Cookie，反之亦然（Bug 1657251）。

这种类型的漏洞不仅出现在Favicon中，还出现在其他具有类似机制的功能中。一个例子是Web Notification API。Web Notifications是一个通过JavaScript显示操作系统级通知的功能。与favicon类似，图标图像可以出现在通知对话框中，并且存在一个漏洞，以完全相同的方式共享私有浏览模式Cookie与普通模式（Bug 1658231）。

这些漏洞不仅发生在加载图标图像时。Bug 1663261指出，在通过<a download>下载链接文件时，也会发生类似的绕过。文件下载也由Mozac的Downloads功能处理，这满足了导致类似缺陷的相同条件。

如您所见，Mozac的URL获取是造成与Web内容不一致的地方之一。除了私有浏览模式，Web世界中还有各种其他安全保护机制，如端口阻塞、HSTS、CSP、混合内容阻塞等。当从另一个组件发出HTTP请求时，这些保护有时会被忽略。通过关注这些常见的陷阱，您很可能能够在未来持续发现新的安全漏洞。

使用User-Agent的差异来区分请求的发起者是发现此类漏洞的有用技术，但在今天的Fenix中不再可用。如果您可以自己构建Fenix，您仍然可以通过设置自定义请求头来使用此技术，如下所示：

GeckoViewFetchClient.kt

1
2
3
4
5
6
7
8
9


private fun WebRequest.Builder.addHeadersFrom(request: Request): WebRequest.Builder {
  request.headers?.forEach { header ->
    addHeader(header.name, header.value)
  }

+ addHeader("X-REQUESTED-BY", "MozacFetch") // 添加

  return this
}

对于监控HTTP请求，远程调试非常有用。从MozacFetch发送的请求将输出到远程调试窗口中的Multiprocess Toolbox进程的Network选项卡。您可以通过过滤字符串“MozacFetch”来找到来自Mozac的请求。

祝您漏洞狩猎愉快！