论文总结——真实世界移动应用中Web资源操纵的实证研究

介绍

这是一篇来自27th USENIX Security Symposium的论文《An Empirical Study of Web Resource Manipulation in Real-world Mobile Applications》

研究背景

当前主流移动平台（包括Android和iOS）使用应用内Web浏览器来运行Web内容。浏览器的示例包括用于Android的WebView和用于iOS的UIWebView/WKWebView。
基于Web视图，移动系统进一步为应用程序开发人员提供Web资源操作API，以自定义浏览器行为并丰富Web应用程序功能。
然而，一些Web资源操作API缺乏基于源的访问控制，这意味着应用程序代码可以通过这些API WebView管理的所有源操作Web资源。
例如，如果主机应用程序具有加载“www.facebook.com”的网络视图，则它可以使用evaluateJavascript API在facebook网页中运行JavaScript，并从facebook获取用户数据。

论文贡献

1. 将Web资源操纵中的威胁定义为跨主体操纵（XPM），并对现实世界应用中的此类威胁进行了大规模研究。
2. 设计了一个自动工具，以识别Android应用程序中的跨主体操作。
3. 基于对80694个应用程序的研究，提出了新的结果和发现，并对当前防御机制的发现和评估也为未来的防御设计带来了新的见解。

恶意的XPM行为

安全的资源获取行为是第三方软件先向用户代理进行申请又返回token进行操作，而恶意的XPM行为不通过中间的用户代理而直接和OAuth服务器提供商进行操作。

跨主体操作（XPM）

例子

如图所示，有两个应用程序，其中应用程序A是Facebook的官方应用程序，应用程序B是名为“Chatous”的独立聊天应用程序。应用程序B整合了Facebook登录SDK，以支持用户使用其Facebook账户。这两个应用程序中有三个Java类（C1、C2和C3），它们使用WebView加载www.facebook。并使用CookieManager.getCookieAPI从www.facebook.com获取Cookie。

对于属于官方Facebook应用程序的C1和属于官方Facebook登录SDK的C2，他们从www.Facebook.com访问cookie是很正常的。然而，由于C3属于“Chatous”，不属于Facebook的软件，但是C3也能从www.Facebook.com获取cookie。

当Web资源由应用程序代码操纵时，如果操纵代码和被操纵的Web资源属于同一方，则可以认为是正常的。然而，如果它们不是来自同一方，则可能会对被操纵的Web资源带来威胁。

定义

Web资源操作点

应用程序代码在何处使用Web资源操纵API来操纵Web资源叫做Web资源操纵点。在每个Web资源操纵点，都有两个参与方，即操纵代码和操纵的Web资源。

应用主体和Web主体

将操纵代码的安全主体指定为应用主体（AP），将操纵的Web资源的安全主体命名为Web主体（WP）。

跨主体操作

当应用主体在Web资源操纵点与Web主体不同时，即为跨主体操作。
公式为IS_XPM(mp) := AP(mp)≠ WP(mp)

威胁模型

一般认为主机应用程序不可信，即它可能通过窃取敏感数据、破坏代码/数据完整性等方式攻击Web资源。主机应用程序中有两种攻击者：主机应用程序本身和合并的第三方库/SDK。

测量方法

这篇论文用的测量方法是先去收集并分析Web资源操作中的API，并将其归为四类。然后开发自动化的工具XPMCheker识别该行为。在开发XPMChecker后，先用少量APP计算出该工具的准确率，最后用该工具对真实世界移动应用进行大规模实验。

分析Web资源操作API

首先对WebView的API深入研究，将API分为四种类型

1. 本地存储操作API：WebView可能会在设备的本地存储上保留敏感数据，如HTTP Cookie、Web Storage1和Web SQL数据库。例如，攻击者可以使用CookieManager.getCookie（字符串url）获取“url”指定的任何域的Cookie。
2. Web内容操作API：Web内容包括网站的HTML、JavaScript和CSS。例如，攻击者可以使用evaluateJavascript API将JavaScript代码注入网页，并获得注入域的权限。
3. Web地址操作API：Web地址是包含相当敏感信息的WebView的当前URL。例如，攻击者可以使用shouldOverrideUrlLoading（WebView视图，字符串url）拦截url并提取OAuth隐式流授权的访问令牌。
4. 网络流量操纵API：这些API使攻击者能够监视/修改WebView和远程服务器之间的网络流量。

XPMChecker

XPMChecker关键组件

• 静态分析器：以Android APK文件作为输入，定位所有可能的Web资源操作点，并收集每个操作点的操作信息。操纵信息包括操纵的Web URL和操纵上下文。静态分析器将所有信息记录到数据库中以供进一步分析。

• 主体标识符：使用数据库中的操作信息标识每个操作点的Web主体和应用主体。

• XPM识别器：通过利用自然语言处理技术和搜索引擎搜索Web主体和应用主体的相关度，最终决定Web资源操作点是否为跨主体。

XPMChecker原理

首先输入一个Android APK，然后通过静态分析，分析出URL和上下文内容，并发送至数据库中，然后主体标识符提取应用主体和Web主体，最后由XPM识别器判断Web资源操作点是否跨主体。

测量角度和结果

角度	结果
操作点	49.2%的操作点为跨主体点
存在行为应用	16.9%的应用操作Web资源，4.8%的应用具有XPM行为
来源	63.6%的跨主体操作点来自库
被操作主机	超过70%的XPM点操作顶级流行Web服务
被操作内容	Web内容和Web地址是最常见的被操纵和跨主体操纵的Web资源。
XPM必要行为	大多数XPM行为对于提高移动用户的可用性是必要的。
不安全的XPM行为	一些XPM行为以不安全的方式实现OAuth隐式授权流
恶意XPM行为	确认了具有明显恶意意图的Web资源操纵行为
操作系统	Android和iOS上都存在恶意XPM行为
恶意XPM方向	大多数恶意XPM行为都以OAuth为目标
恶意XPM影响范围	恶意XPM行为影响了大量用户
服务提供商	大多数Web服务提供商不知道Web资源操纵的风险，并且无法有效阻止用户访问WebView中的敏感页面
防御挑战	WebView的完全隔离与大多数应用程序不兼容
防御条件	细粒度访问控制是规范Web资源操作API的必要条件