基于WebView的身份混淆移动应用中的生态系统

一、身份混淆产生原因

超级应用为了更好的服务于现有用户并不断吸引新的用户，使得 “ $A pp - in - a pp$ ”迅速兴起，“ $A pp - in - a pp$ ”不仅像普通应用应用加载第三方资源，还可以访问超级用户提供的特权 $A P I$ 。而超级应用通常依靠“Web域名”、“子应用程序ID”和“能力”来决定是否能对特权的 $A P I$ 访问。但是这三种类型的身份检查并不完善，违背了最小特权原则(例如特权子应用和非特权子应用的嵌套)，导致系统资源的泄露，从而产生严重后果。

Web域名:

$W e b$ 域名是用于标识一个网站的字符串，通常由多个部分组成，以点号分隔。例如， $" g oo g l e . co m "$ 中的 $" g oo g l e "$ 是该网站的名称，而 $". co m "$ 则表示该网站所在的顶级域名。 $W e b$ 域名可以用来定位和访问网站，每个域名都是唯一的，并且与一个或多个 $I P$ 地址关联，这些 $I P$ 地址指向托管该网站的服务器

子应用程序ID：

子应用程序 $I D$ 是指在一个大型软件系统中，由父级应用程序创建的、拥有独立功能和数据的子级应用程序所分配的唯一标识符。在一个大型软件系统中，通常会包含多个子应用程序，这些子应用程序可以相互协作，或者独立运行。子应用程序 $I D$ 可以用于跟踪和管理系统中不同的应用程序，并确保它们都能够正常工作。例如，在一个电商系统中，可能会有多个子应用程序来处理订单、库存管理、支付等功能，每个子应用程序都有自己的 $I D$ ，以便与其他应用程序区分开来。

能力

能力是由超级应用程序或服务器发行并基于精确匹配进行检查的密钥。现有超级应用程序中获得能力的方法有两种。即子应用程序通过隐藏的运行时API在移动端获取能力，或子应用程序在进行双向身份验证后从其云端获取能力。

最小特权原则：

最小特权原则是一种安全性原则，指的是给予用户、程序或进程仅足以完成其工作所需的最低权限。也就是说，在任何情况下都不应该授予用户或程序比他们需要的更高的权限。这个原则可以帮助防止恶意软件利用高权限来访问系统中的敏感信息或执行有害操作。通过实施最小特权原则，可以降低系统被攻击的风险，并且可以使系统管理员更轻松地管理和监视系统上的权限和访问控制。

二、对产生身份混淆的“ $A pp - in - a pp$ ”的研究

1.流行超级应用运行环境

通过抓取分析当前流行安卓应用，发现超级应用范围具有多样性，包含的子应用数也有多有少，进一步分析可知超级应用的生态环境可大致划分为三个部分:一个嵌入式浏览器实例、运行时的特权API、一个网页到移动设备的桥梁。

嵌入式浏览器实例：

将一个完整的浏览器引擎集成到一个应用程序中，以提供浏览器功能的能力。这种浏览器引擎可以是 $W e b K i t$ 、 $C h ro mi u m$ 或其他开源引擎。嵌入式浏览器实例通常用于在应用程序中显示Web内容，例如在桌面应用程序或移动应用程序中嵌入网页视图以展示 $W e b$ 内容。它还可用于创建自定义浏览器体验，例如创建专门的 $W e b$ 浏览器或轻量级的浏览器插件。

运行时的特权API：

指一组可用于操作操作系统和硬件资源的 $A P I$ ，这些API通常只能由特定用户或进程访问，以授予更高的权限执行敏感操作。它们被称为“运行时的”特权 $A P I$ ，因为它们在程序运行时才被调用并使用。

网页到移动设备的桥梁:

$W e b - t o - m o bi l e b r i d g e$ （网页到移动设备的桥梁）是一种软件或技术解决方案，用于连接 $W e b$ 应用程序和移动设备应用程序。它允许开发人员使用通用的 $W e b$ 技术（如 $H TM L$ 、 $CSS$ 和 $J a v a S cr i pt$ ）来构建跨平台的移动设备应用，并与后端服务器进行通信。

2.典型子应用程序编程模型和生命周期

(1) 编程模型:

运行在超级应用之上的子应用通常被编程为带有 $J a v a S cr i pt$ 、 $H TM L$ 和 $CSS$ 的迷你 $W e b$ 应用程序，并可以通过 $W e b - t o - M o bi l e$ 桥接访问特权 $A P I$ ,

(2)生命周期：

<1>单击或扫描带有深度链接的二维码

<2>超级应用程序将根据嵌入在深度链接中的应用程序 $I D$ 找到子应用程序并下载

<3>子应用程序将进一步从自己的或第三方服务器获取内容并在 $W e bVi e w$ 实例中呈现它们

<4>子应用程序的代码可以通过 $W e b$ 到移动桥接访问特权API

3.现有的身份检查

(1)域名

基于域名身份验证有两种主要类型：严格的白名单和模糊匹配

(2)应用程序ID

通常基于白名单进行 $A pp I D$ 的检查。

(3)能力

能力是由超级应用程序或服务器发行，并基于精确匹配将其作为密钥进行检查。

4.运行时API分析

(1)静态分析:

通过标准的 $W e bVi e w$ 接口或事件处理程序对超级应用进行静态分析，以查找直接隐藏的 $A P I$ 调用.

(2)动态分析

关联静态识别的容器对象（例如通过Xposed），生成测试用例来触发文档化的公共运行时 $A P I$ 。如果在公共 $A P I$ 调用期间访问这些容器对象，则将它们视为API池并从池中读取所有存储的API。如果隐藏的API受到手动验证身份检查的保护，则将其视为隐藏特权 $A P I$ 。

三、什么是身份混淆

1.身份混淆介绍

身份混淆是一种漏洞，是由于超级应用依靠“Web域名”、“子应用程序ID”和“能力”来决定是否能对特权的 $A P I$ 访问，但是这三种类型的身份检查并不完善，违背了最小特权原则而产生的，可能导致拥有非特权身份的恶意程序可以调用有特权的运行时 $A P I$ 。

2.攻击模型搭建

考虑以下两种情况分别搭建不同攻击模型。

(1)存在漏洞的子应用程序

存在漏洞的子应用程序是运行在具有身份混淆漏洞的超级应用程序之上的良性代码。在这种情况下，攻击者是一个恶意的 $W e b$ 域，它有能力向受害用户发送指向超级应用程序内易受攻击的子应用程序的恶意网络链接。

(2)恶意的子应用程序

恶意的子应用程序是由攻击者制作并具有恶意意图的代码。在这种情况下，攻击者是一个恶意的子应用程序开发者，他有能力将恶意内容上传到超级应用程序的市场，并触发超级应用程序的身份混淆漏洞（例如域名混淆）。

四、身份混淆的深入研究

根据三种并不完善的身份检查类型，进一步将"身份混淆"细分为三大类。

1.域名混淆

从 $W e bVi e w$ 调用特权 $A P I$ 的 $W e b$ 域名与超级应用获取和检查身份的域名不同,具体可划分为：基于时间的（由于竞态条件而引起）和基于框架的（由于存在多个域）。

(1)基于时间的混淆

由于WebView线程和超级应用线程从高层次上出现了竞争条件，例如当一个 $W e bVi e w$ 线程调用一个特权 $A P I$ 并将控制权传递给超级应用程序线程时，其身份标识来自于例如 $ma l i c i o u s . co m$ ，但当另一个超级应用程序线程检查身份标识时，由于重定向，身份标识更改为例如 $p r i v i l e g e d . co m$ ，导致混淆。而这种竞争又分两种情况：WebView的渲染和加载线程之间的竞争、超级应用程序的调度和检查线程之间的竞争。

WebView 线程：

WebView 实例通常具有两种类型的线程，一种用于渲染 Web 内容（称为渲染线程），另一种用于加载 Web 内容（称为浏览器线程）。

超级应用程序线程：

超级应用程序可能有三种类型的线程：（i）一个获取 $W e bVi e w$ 的域名作为身份标识的线程，（ii）一个检查获得的身份标识并决定是否允许执行的线程，以及（iii）一个在异步队列中分派特权 $A P I$ 调用的线程。请注意，这三种类型线程的存在取决于超级应用程序的设计和实现。

WebView的渲染和加载线程之间的竞争：

这个竞争条件是因为 $W e bVi e w$ 的渲染和加载线程可能处理来自不同 $W e b 域$ 的内容。具体来说，在 $W e bVi e w$ 端，当加载线程在重定向后开始从新 $U R L$ 加载内容时，渲染线程仍然可能执行旧 $U R L$ 的内容。而在超级应用程序端，有两个线程，一个在线程 $W e bVi e w$ 的加载线程被重定向后获得一个新的 $W e b$ 域作为身份，另一个检查新域名但允许来自旧域的特权 $A P I$ 调用。根据 $U R L$ 加载的启动方式，该竞争条件又分两种变化:
(i)首先，运行在 $W e bVi e w$ 的渲染线程上的恶意 $. co m$ 的 $J a v a S cr i pt$ 开始将网页重定向到 $p r i v i l e g e d . co m$ 。其次，重定向被发送到加载线程，加载线程开始加载 $p r i v i l e g e d . co m$ 并触发超级应用程序注册的回调（例如 $o n P a g e St a r t e d （）$ ）。第三，由回调触发的相应的超级应用程序线程将新域名作为标识符获取。最后，来自 $ma l i c i o u s . co m$ 的同一 $J a v a S cr i pt$ 调用特权 $A P I$ ，但身份已经成为 $p r i v i l e g e d . co m$ 。
(ii)首先，超级应用程序的一个线程调用 $l o a d U r l ()$ ，指示浏览器线程加载一个 $U R L （ p r i v i l e g e d . co m ）$ 并返回新的域名作为标识符。其次，旧URL（恶意 $. co m$ ）的 $J a v a S cr i pt$ 代码调用特权 $A P I$ ，这是由超级应用程序的一个线程检查的，但被认为来自 $p r i v i l e g e d . co m$ ,导致了域名混淆。
通过测量：旧网页仍然可以执行JavaScript代码，但URL已更新为新的URL、新网页可以执行JavaScript代码，但URL仍然是旧的URL。这两种情况发现许多 $W e bVi e w A P I$ 和回调都与浏览器线程而不是渲染线程交互或被触发，即竞争条件在许多 $W e bVi e w$ $A P I$ 中非常普遍。

超级应用程序的调度和检查线程之间的竞争：

当超级应用程序的调度线程接收到一个特权API调用时，它不检查身份，而是将其分派到异步队列中。当检查线程从队列中获取API调用并检查身份时，从 $W e bVi e w$ 获取的身份已经过时了。

具体来说，在 $W e bVi e w$ 渲染线程中，来自 $ma l i c i o u s . co m$ 的 $J a v a S cr i pt$ 调用了一个运行时特权 $A P I$ 。接下来， $W e bVi e w$ 线程将调用传递给超级应用程序线程。然后，超级应用程序线程将 $A P I$ 调用分派到一个队列中，而没有检查其身份。此时 $W e bVi e w$ 渲染线程中的 $J a v a S cr i pt$ 将网页重定向到 $p r i v i l e g e d . co m$ 。当另一个超级应用程序线程从队列中获取 $A P I$ 调用并执行带有身份检查时，从中获取的身份是 $p r i v i l e g e d . co m$ 而不是 $ma l i c i o u s . co m$ 。

虽然当超级应用程序完成调用的 $A P I$ 执行时，旧网页（即 $ma l i c i o u s . co m$ ）无法获取返回值，因为网页现在是 $p r i v i l e g e d . co m$ ，但是攻击仍会成功，因为旧网页发起的特权API已经完成了其执行。

(2)基于框架的混淆

即使用 iframe 代表顶层框架的身份。许多 $W e bVi e w$ 的 $A P I$ 和回调函数仅在顶部框架嵌入多个子框架作为其一部分时返回顶部框架的 $U R L$ 。因此，无论一个超级应用程序采用何种身份验证检查以及如何执行此类检查，如果使用此类 $A P I$ 和回调，则超级应用程序只能获取顶部框架的身份。也就是说，来自 $ma l i c i o u s . co m$ 的广告作为 $p r i v i l e g e d . co m$ 的 $i f r am e$ 嵌入其中时可以代表后者。

iframe:

$i f r am e$ 是 $H TM L$ 中的一个标记，它可以将另一个 $H TM L$ 页面嵌入到当前页面中。通过使用 $i f r am e$ ，网页设计师可以在一个页面上显示其他页面的内容，而无需让用户离开当前页面。把Web页面比作盒子，那么 $i f r am e$ 就像一个小盒子，可以容纳其他页面。使得网站设计更加灵活，可以在同一页上展示多个相关内容，同时保持所有内容的独立性和安全性。

2.应用 $I D$ 混淆

恶意域具有一个拥有特权的应用ID，从而调用特权运行时API，导致混淆超级应用程序的身份检查。我们称之为应用 $I D$ 混淆。应用 $I D$ 混淆的关键步骤是在特权子应用程序中加载恶意域，这样的应用 $I D$ 混淆情况又分为以下三类:

(1)URL白名单匹配缺陷

指用于加载的 $U R L$ 白名单有缺陷，从而可能允许潜在的恶意 $U R L$ 进行加载。其深层原因是超级应用程序和子应用程序之间缺乏协调和适当的文档,即 $U R L$ 白名单检查算法由超级应用程序提供，但白名单由子应用程序提供,因此，对检查算法的误解经常导致错误。

(2)URL解析缺陷

指超级应用程序在解析URL和提取网域时存在逻辑错误。

(3)URL检查缺失

指当子应用程序将第三方 $U R L$ 加载到 $i f r am e$ 或顶部框架中时，超级应用程序没有检查网域。因此，对手可以将恶意 $U R L$ 嵌入广告中，或欺骗顶部框架访问恶意 $U R L$ ，然后访问特权 $A P I$ 。

3.能力混淆

指用于保护运行时 $A P I$ 的特权能力被泄露给恶意实体，在文章研究中发现了两种情况:

(1)未受保护的客户端API

这种缺陷是指超级应用程序使用一个隐藏的、未受保护的API来传输功能。超级应用程序假定该API未被记录，并且不会被对手使用，但该API可以从特权子应用程序中进行反向工程，然后被对手使用。

(2)未受保护的服务器端API

这个缺陷是指特权子应用程序服务器向超级应用程序公开未经保护的 $A P I$ 以签署调用请求。攻击的工作方式如下，恶意网站首先向子应用程序的后端服务器发送请求以签署调用请求，然后将请求转发给超级应用程序，由于请求是由特权子应用程序服务器签署的，因此超级应用程序将允许API调用。

五、检测现存的身份混淆问题

1.检测方法

(1)查找超级应用

使用半自动方法来发现更多超级应用,具体可分为三个子步骤:
<1>使用静态分析，利用Soot，识别具有 $W e b$ 视图和 $J a v a S cr i pt$ 桥接的应用程序。
<2>进行类名相似性分析，以找到超级应用运行时。具体为:收集包含 $W e bVi e w$ 实例的活动的类名，并保留那些包含至少五个类或进程名称相似（即共享关键字）的应用程序作为潜在的超级应用程序，然后，使用基于关键字的包名匹配来过滤广告相关的 $W e bVi e w$ 实例，这些实例可能具有桥接实现但不是子应用程序运行时。
<3>最后手动验证是否真正是具有应用程序内应用程序生态系统的超级应用程序。

Soot:

$S oo t$ 是一个开源的 $J a v a$ 字节码分析和优化框架，它可以用于静态分析、程序转换和优化等领域。 $S oo t$ 支持多种前端语言（如 $J a v a$ 、 $J im pl e$ 、 $D EX$ 等）和多种后端目标平台（如 $J V M$ 、 $A n d ro i d$ 、 $LL V M$ 等），可以方便地扩展和定制。 $S oo t$ 提供了丰富的 $A P I$ 和工具，包括字节码解析、类型推断、控制流图构建、数据流分析、程序切片、指针分析、过程间分析等功能。

在移动安全领域， $S oo t$ 被广泛用于Android应用程序静态分析和漏洞检测等任务。例如， $S oo t$ 可以用于检测 $A n d ro i d$ 应用程序中的权限验证缺陷、组件导出漏洞、代码注入漏洞等。此外， $S oo t$ 还可以用于优化 $A n d ro i d$ 应用程序的性能和资源消耗，例如使用 $S oo t$ 进行混淆、压缩和优化等。

子应用程序运行时:

超级应用程序通常具有一个运行时环境，以便在主应用程序中加载和运行子应用程序。这个运行时环境可能包括许多组件，例如 $W e bVi e w$ 实例、 $J a v a S cr i pt$ 桥接、 $U R L$ 路由、权限管理、数据管理等。在这种情况下，我们称之为“子应用程序运行时”。子应用程序运行时的设计可以根据需要而变化，但其主要目的是提供一个安全、可靠和高效的方式来加载子应用程序，并且允许子应用程序与宿主应用程序进行通信和交互。例如，在微信中，子应用程序运行时通过提供标准 $A P I$ （例如 $“ w x .”$ ）和隐藏 $A P I$ （例如 $“ mini P ro g r am .”$ ）来与主应用程序进行通信，并使用原生功能（例如打电话、扫码、支付等）来扩展功能集。

(2)漏洞分析

通过身份混淆分类手动编写测试用例和攻击代码，并检查每个漏洞是否存在。通过使用 $A n d ro i d$ 版本的漏洞证明可以用例来验证其 $i OS$ 版本是否也存在漏洞。

<1>域名混淆分析

(i）确定是否使用了表 $3$ 中的易受攻击的 $A P I$ 或回调函数 .
(ii）手动生成触发漏洞的攻击代码。

<2>应用ID混淆分析

通过检查对手是否可以要求超级应用程序在子应用程序中加载任何恶意域判断，若可以则认为存在，否则不存在。

<3>能力混淆分析

通过检查传输秘密的API是否已公开即可。

(3)危害分析

从以下三个方面测试了易受攻击的超级应用程序的可能产生的安全后果。

<1>特权提升

<2>钓鱼网站

<3>隐私泄漏

2.测试结果

通过对查找的超级应用进行实验测试发现，尽管这些“超级应用”在身份验证方面采用了多种方法，但它们都是易受攻击的(存在至少一种身份混淆攻击漏洞)，而这些身份混淆攻击漏洞可能导致网络钓鱼、隐私泄露和特权升级，除此之外还可能产生一些独立于身份混乱之外的安全后果，例如权限再授权、数据过度收集、数据泄露等问题。

3.结果分析

收集到的 $47$ 个超级应用程序的统计数据中，包括漏洞类型和安全后果。九个超级应用程序没有采用任何身份验证，因此所有这些应用都容易受到我们的攻击。几个超级应用程序有特权的隐藏API（例如 $S na p c ha t$ 中的“ $f e t c h A u t h T o k e n$ ”），没有任何身份验证，因此易受特权升级或隐私泄漏的攻击。

六、经验教训

研究所得到的最重要教训是，子应用程序的身份检查（例如允许敏感 $A P I$ 调用）应该遵循最小特权原则。也就是说，在应用内嵌生态系统中，身份的定义需要是原子性的，并提供超级应用程序、子应用程序和 $W e bVi e w$ 开发人员之间的明确协调。当子应用程序尝试调用超级应用程序的特权 $A P I$ 时，子应用程序将提供一个由其服务器私钥签名的秘密，就像数字签名一样。然后，超级应用程序使用公钥获取该秘密，然后在允许调用之前验证该秘密、域名和子应用程序 $I D$ 。

除了原子身份定义之外，消除身份混淆还将受益于移动和 $W e bVi e w$ $W e b$ 层之间的域同步。移动代码应该有权透明地获取 $W e bVi e w$ 中任何帧的正确、同步、最新的域，例如 $Dr a co$ 。

最后，子应用程序开发人员也应该更加关注其安全性，特别是在类似启动网页这样的敏感但暴露的接口上。他们还应该仔细阅读超级应用程序的文档，以了解安全检查，例如 $U R L$ 白名单匹配等。

个人总结

总述

本文从超级应用对特权API的三种访问检查方式不符合“最小特权原则”从而引入身份混淆问题，为了更好的研究身份混淆问题，文章首先研究了产生身份混淆的子应用的生态系统，研究了流行超级应用运行环境、典型子应用程序编程模型和生命周期、现有的身份检查方式，并以静态分析和动态分析两种方式进行了运行时API分析以查找隐藏特权API，从而阐述清楚了问题产生的平台架构和运行机制。此时再从之前查找的现有超级应用的身份检查方式下手，搭建了两种类型的攻击模型：存在漏洞的子应用程序、恶意的子应用程序，来检查三种身份验证方式中可能存在的漏洞。为了更好的测试身份混淆问题，本文将身份混淆问题由三大类再次细分为不同小类以方便攻击模型对症下药，同时为了更好的研究，从底层讲述了身份混淆漏洞产生的底层机制。纸上得来终觉浅，于是本文通过之前搭建的攻击模型对现存的超级应用进行了身份漏洞测试，以实际测试结果来更好的阐述身份混淆问题的普遍和危害。最后基于本文查找出的巨量漏洞阐述了身份混淆问题的严重以及根本原因，并对未来提出了可能的解决方式。

实验思路

本文通过研究超级应用的身份检查方式，以及底层代码的具体实现方式，因此对症下药搭建了两种不同的攻击模型以全面测试可产生的身份混淆问题，为了测试的更加精准可靠，将身份混淆问题由三大类进一步细分为更多不同类型的小类以精确测试。

个人构思

文章中的实验模拟都是基于超级有用的三种身份检查方式而实现的，可能导致本身存在局限性，即实验攻击模型和测试都已经受限于三种类型的身份检查方式，不断的细分虽然使得实验测试能够更加具有针对性，但是这样也就导致在测试时没有考虑三种类型身份检查之间相互作用可能带来的影响，以及超级应用在进行身份检查时，是否能够打破常规以多种省份检查方式相结合的方式进行，从而减轻身份混淆可能带来的危害？

【论文总结】Identity Confusion in WebView-based Mobile App-in-app Ecosystems相关推荐

【论文笔记】Multi-task deep learning based CT imaging analysis for COVID-19 pneumonia: Classification and
声明不定期更新自己精度论文,通俗易懂,初级小白也可以理解涉及范围:深度学习方向,包括 CV.NLP.Data Fusion.Digital Twin 论文标题:Multi-task deep le ...
实践：uniapp中webview内置网页与app实时通讯
目录 1.uniapp官网webview地址 2.uniapp中vue文件代码 3.webview链接的远程网页代码 4.vue引入uniapp的JS 5.到此uniapp使用webview内置网页与 ...
论文阅读：Semantic Aware Attention Based Deep Object Co-segmentation（ACCV2018）
协同分割论文:Semantic Aware Attention Based Deep Object Co-segmentation(ACCV2018) 论文原文 code 目录 1.简介 2. ...
论文阅读：A Novel Graph based Trajectory Predictor with Pseudo Oracle
A Novel Graph based Trajectory Predictor with Pseudo Oracle 摘要 1 引言 2 相关工作 3 PROPOSED METHOD IV. EXP ...
阅读论文Formal verification of smart contracts based on users and blockchain behaviors models
1 题目(Formal verification of smart contracts based on users and blockchain behaviors models) 1.1 作者.出 ...
活体识别3：论文笔记之《FACE ANTI-SPOOFING BASED ON COLOR TEXTURE ANALYSIS》
说明本文是我对论文<FACE ANTI-SPOOFING BASED ON COLOR TEXTURE ANALYSIS>做的一个简单笔记. 这个论文是芬兰奥卢大学(Oulu)课题组的一 ...
显著性检测论文解析2——Visual Saliency Detection Based on Bayesian Model, Yulin Xie, ICIP2011
最近感觉玩的差不多了,现在准备好好学习了,所以就又开始随便写点,就当是自己学习的笔记.这次要说的的是卢湖川的Visual Saliency Detection Based on Bayesian Mo ...
【论文精读】Local-Adaptive Image Alignment Based on Triangular Facet Approximation
图像拼接系列相关论文精读 Seam Carving for Content-Aware Image Resizing As-Rigid-As-Possible Shape Manipulation A ...
论文阅读：Visual Semantic Localization based on HD Map for AutonomousVehicles in Urban Scenarios
题目:Visual Semantic Localization based on HD Map for Autonomous Vehicles in Urban Scenarios 中文:基于高清地图 ...

【论文总结】Identity Confusion in WebView-based Mobile App-in-app Ecosystems