Hindsight: Understanding the Evolution of UI Vulnerabilities in Mobile Browsers
作者：刘保证（清华大学）
本文发表于 NDSS 2018，原文作者：Meng Luo, Oleksii Starov, Nima Honarmand, Nick Nikiforakis
摘要
大部分移动安全研究都专注于恶意应用，但对广泛被使用的浏览器的安全研究却很少，而移动端的浏览器和桌面端的浏览器一样容易受到攻击。论文作者表示这篇文章则是首次从事移动端浏览器的安全研究，专注于手机浏览器的 UI 漏洞。论文作者根据前人的工作以及自己的调查，量化了 27 个 UI 相关的攻击，针对于超过 128 个浏览器家族以及 2324 个独立的浏览器版本（跨度超过 5 年）进行了浏览器 UI 的安全性研究，基本的步骤如下：
- 从不同的源中收集了不同时期的浏览器样本。
- 设计并实现了与浏览器无关的测试框架， Hindsight，自动化测试浏览器 UI 的漏洞。
最后，论文作者发现，98.6% 的浏览器至少受到一种攻击的影响，而且随着时间的变化，移动端浏览器的平均安全性变得越来越差。因此，论文作者认为目前手机浏览器的安全性被严重忽视，也表示手机浏览器的安全应该受到重视。
基本攻击块
为了评估移动端手机浏览器的 UI 安全性，论文作者首先调研了之前相关的研究，以便于找到一些已有的攻击方法。基于这样的发现，他们猜测浏览器和网站交互的方式，并指出浏览器尝试为要渲染的网站提供最大化的空间。通过不断地尝试，作者发现了已有攻击的一些变种。此外，为了说明这些漏洞既可以被单独使用也可以被联合使用，作者将每种攻击都命名为 ABB（Attack Building Block）。更加具体的，如下表所示，作者将收集到攻击方法分为以下类。
表1 已知攻击方法的分类
从表中分类可以发现，这里很多的攻击都是钓鱼攻击。
数据收集
由于论文作者希望测量近些年来手机浏览器 UI 漏洞的演变过程，所以收集了来自于不同时期的不同家族的浏览器，具体步骤如下
1. 使用 Selenium 来自动化地收集 Google Play 中包含 browser 关键字的apk，并过滤一些不是 web 的浏览器，比如文件浏览器。
2. 收集不同版本的浏览器。为了获取旧版本的浏览器，作者从不同的网站（Androidapps, Apkhere, Apkmirror, Apkpure, Uptodown, 以及 Aptoide）中，爬取了尽可能多的 APKs。
3. 过滤一些 APKs，比如过滤相同的浏览器。
最后，作者获取的 APK 的统计结果如下
表3 过滤和处理浏览器的APKs
表4 每年APK和浏览器系列的数量
可以发现，在进行了过滤之后，最后一共有 2324 个 APK。而且，随着时间的增加，每年发现的浏览器的 APK 数量不断增加。
基本测试框架
论文作者设计并实现了一个自动化的漏洞测试框架，Hindsight，基本步骤如下：
1. SDK 分配。由于每个 APK 都会有 targetSdkVersion 以及 min sdkVersion，所以该框架需要为对应的 APK 分配一个合适的手机，使得其可以正常运行。
2. 安装以及启动屏幕绕过。使用 ADB 安装对应 APK，并绕过 APK 启动时的一些欢迎界面，以及一些提示信息。
3. ABB 测试。使用预先编写好的 ABB 的测试逻辑对安装好的 APK 进行测试，并输出相关的信息。
4. 结果评估。对输出的信息进行分析，说明这个浏览器是否会受到相应的 ABB 的攻击。
框图如下：
图1 Hindsight 框架的架构
这里主要关注于框架中的以下两部分：
浏览器无关的 UI 分析的实现
由于作者想要自动化地对这个程序进行分析，所以需要自动化识别如地址栏一些的信息，也就需要打造一个浏览器无关的 UI 测试框架。论文作者认为，在 2~4 步中主要需要解决的问题是：分析给定应用的 UI 来决定某些元素是否存在，如果存在的话，需要确定在屏幕的具体位置。更具体一点，这些 UI 元素主要包括应用级别的 UI 元素，比如地址栏、挂锁、图标以及标签页webpage 的内容。作者针对于这两种元素，分别提出了相应的解决办法：
- 应用级别的 UI 元素。大部分浏览器都会使用标准的 Android UI 库。这使得 Hindsight 可以使用 UI Automator 来获取应用 UI 的 DOM 的 XML dump，包括网站中的文字，图片，甚至坐标。
- Webpage 的元素。不能够依赖于上述的 dump 方法，因为很多浏览器渲染的网站内容并不是 DOM 中的一部分，测试者需要定位屏幕上某个按钮的位置。最后论文作者选择采用 OCR 识别来解决这个问题。
在使用 OCR 时，发现 OCR 方法存在局限性，并提出相应解决办法：
- 不同浏览器渲染同一个网页的方法可能是不一样的。比如对于同样一个网页，不同的浏览器可能会使用不同的字体来进行渲染。通过不断尝试多次，发现对于 ABB 中重要的文本元素，需要使用不同的字体大小和家族以及重复多次，以便于提高被 OCR 识别的效率。
- 渲染的网页可能并不是网页中唯一出现的内容，比如一些其他的信息，如提示信息、更新信息。
作者通过两种方法来解决了这种问题：
1. 作者通过自动化识别的方法来点击这些提示信息，消除这些提示信息。
2. 作者在设计 ABB 测试网页的时候尽可能地使得网页的内容靠近屏幕中间。
通过这样的 UI 分析，为自动点击相关按钮，填写文字内容等需要在 2-4 步骤中操作的问题提供了一种解决办法。
结果验证
论文作者指出，由于这样的框架是首个被提出来的，所以目前没有可以验证他们的方法，所以只能使用手工验证。因此，在使用上述方法的时候，确保
- 测试结果尽可能是用户友好的，即尽可能可读。
- 所有设备相关的截图都会被保存
对于目前的数据集，论文作者指出这大概会花费一个人 60 个小时的时间来完成，而且，自动化测试逻辑的错误概率是 1.5%，其实还是很低的。
评估
在收集到的 2324 个 APK 中，作者分别都进行了 27 种 ABB 的测试，结果发现错误的概率大约有 3.6%，其中1.5 由检查的人发现，2.1% 由 Hindsight 框架发现。作者进一步分别将所有的错误分别分为有漏洞和安全，考虑了有漏洞的 APK 的上界和下界。
近几年手机端浏览器的 UI 漏洞的总体发展趋势如下
图2 手机端浏览器的 UI 漏洞的总体发展趋势
更具体的，作者考虑浏览器容易受到多少个相关漏洞的影响呢？
图3 影响手机浏览器的漏洞数
论文作者发现，98% 的浏览器至少受到 1 种 ABB 的影响，50% 的浏览器至少受到 12 种 ABB 的影响。针对于不同种类的漏洞，还发现浏览器更容易受到 URL 方面的漏洞影响。
图4 至少受一个漏洞影响的浏览器系列的部分
而且，新版本的浏览器不见得比旧版本的浏览器的漏洞更少，比如 Chrome 浏览器。
图5 最流行浏览器每年的平均漏洞数
此外，浏览器的安装程度与其受欢迎的程度有时候并没有什么必然的联系，比如排名第 13 的 Shark 浏览器受到的 Event Routing 和 Address bar 相关种类的漏洞影响的个数就比排名的 1 的 Chrome 浏览器少很多。
图6 至少受一个 ABB 漏洞影响的 APK 占比
更进一步，论文作者分析了随着时间的推进，每种浏览器针对于某种漏洞的变化确实，首先给出了如下的定义
- 总是有漏洞的标记为 YES
- 从安全的变为不安全的标记为 noYES
- 临时有漏洞即为 noYESno
- 在有漏洞和没有漏洞之间回归记为 yesNOyes
论文作者给出了一个 yesNOyes 的例子，如 Dolphin browser 的如下版本，在面对长 URL 的时候可能会表现出不同的现象。
图7 手机浏览器处理长 URL 的不同现象
并且，给出了整体的效果，如下
图8 受影响的浏览器家族数量
整体来说
- 有漏洞的几乎总是漏洞。
- 没有漏洞的在新版本中会有一定概率出现漏洞。
- 对于 noYESno 以及 YESnoYES 则出现的情况较少。
个人思考
优点
- 收集了足够多的手机端的浏览器。
- 测试方法是自动化的，而且还可以不断集成新的漏洞种类。
- 从不同角度分析了近些年来浏览器 UI 漏洞发展的历史。
缺点
- 虽然分析了这么多浏览器，但是其实很多用户都不使用，并没有反映到这些漏洞对于现实用户的影响。
- hindsight 在绕过一些开始安装 APK 时，仍然存在一些不足。
- 由于物理资源的限制，作者只是用了 4 个SDK 版本的手机。如果使用更多版本的话，获取曾经安装失败的浏览器可能就可以安装成功了。
- 在最后仍然对结果进行了手工分析，难以做到全自动化。
论文与 ppt 链接
http://securitee.org/files/hindsight_ccs2017.pdf
https://www.cs.auckland.ac.nz/courses/compsci702s1c/seminar/presentations-2018/COMPSCI-702-Lecture-23a-Sejal-Patel.pptx
