【MS】MiniScope: Automated UI Exploration and Privacy Inconsistency Detection of MiniApps via Two-phas

MiniScope: Automated UI Exploration and Privacy Inconsistency Detection of MiniApps via Two-phase Iterative Hybrid Analysis

会议/期刊： ACM Transactions on Software Engineering and Methodology 2024
作者：

key points

在更大的superapps中运行
隐私问题 敏感数据

引入了MiniScope，这是一种专门为MiniApp环境设计的新型两阶段混合分析方法。
通过结合UI转换状态分析、跨包回调控制流解析和自动迭代UI探索，克服了现有静态分析技术的局限性。
可以全面了解MiniApps的隐私实践，解决子包加载和事件驱动回调的独特挑战。
证明了它在识别隐私不一致方面的有效性。【隐私不一致性】

特别关注同一个目标，即Android的微信MiniApp。

现有的污染分析方法[25,31,41]主要集中在敏感数据流上，而忽略了事件驱动的回调，无法彻底检查MiniApp逻辑的异步入口点。这种忽视会导致大量的污染分析误报，因为获得的一些污染路径可能是潜在无法到达的。

研究

MiniApps采用了一种子打包机制[40]，在冷启动期间只初始化主包，而在运行时根据需要加载子包。
仅依赖于静态分析的方法[25,31,41]无法触发这些子包的加载，从而忽略了可能涉及隐私实践的大量代码。

目标是开发一个包含子包加载和集成回调控制流分析的框架。

在MiniApps环境下，通过UI探索按需加载子包是进行良好静态分析的前提，而高效的UI探索则需要静态先验知识（如UI过渡状态）作为指导。因此，这提出了一个逻辑悖论，这需要为MiniApps设计专门定制的混合分析策略 。【动静态结合分析策略】

二、由于需要对用户交互和事件驱动的回调进行合理的解析，对MiniApps的静态分析存在困难。虽然类似的技术已经在Android/iOS中被广泛探索[27,29,50]，但在MiniApps中构建控制流的独特挑战在于跨文件和跨子包回调解析。【跨文件跨包回调控制流】

【控制流 数据流】
在第一阶段，初始化主包的MiniApp依赖图（MDG），精心设计以提取UI过渡状态、事件驱动的控制流和数据流。
基于初始MDG，定向UI资源管理器随后在WXML组件和UI Widgets Tree之间进行模糊匹配。
通过采用面向子包的宽度优先遍历策略，minicope动态地探索子包页面，从而获得MiniApp的完整包。
在第二阶段，我们的重点转移到对隐私实践的精确识别。
MiniScope将主包与动态加载的子包合并，执行静态分析以获得完整的MDG。在这个阶段，定向UI资源管理器利用一种面向隐私实践的深度优先策略来对敏感行为进行运行时探索。然后，MiniScope根据声明的隐私策略，对从静态和动态分析中提取的隐私实践进行交叉验证，从而能够彻底检测出任何差异或隐私不一致之处。

贡献

• 新技术（§4）。引入一种新的两阶段混合分析方法，包括UI过渡状态建模、详细的跨包回调控制流解析和自动迭代UI探索，弥补了MiniApp生态系统中子包加载和回调分析的研究空白。

• 实际实现和应用（§4.3）实现了这些技术作为一个全自动工件命名为minicope，并展示了其性能和有效性，在MiniApps的隐私不一致的全面检测。

• 实证评估和现实世界的影响（§5）。我们对120K个MiniApps进行了综合评估，发现5.7%和33.4%的MiniApps普遍存在过度收集和过度索取隐私信息的情况。我们向超过2K的开发者报告了我们的发现，并获得了44个确认。

背景

miniapp特征

MiniApps的架构
MiniApp的运行环境（图1）由微信或支付宝等超级应用程序提供，其特点是双线程架构，分为渲染（或视图）层和逻辑层[41]。

呈现层类似于HTML和CSS，涉及WXML（标记语言）和WXSS（样式表），而逻辑层由JavaScript文件组成。MiniApp页面对应于呈现层中的多个WebView线程，而逻辑操作、数据请求和接口调用则通过逻辑层中的JSCore线程发生。这两层通过微信的JSBridge机制进行交互，处理用户交互事件和数据更新。此外，逻辑层引入了像wx这样的子应用程序api。getLocation用于用户位置检索，它被桥接到SuperApp的本地层[30]中。

子包动态加载
MiniApps采用独特的子包机制来保持轻量级和免安装，将每个代码包限制为2MB，特别是微信平台。为了扩展它们的功能，MiniApps使用动态或按需加载子包[39]。在冷启动或初始化期间，只加载主包，在用户访问特定页面时动态加载相应的子包。

MiniApps的页面路由
MiniApps是多功能实体，每个页面促进特定任务，并通过页面路由相互连接。一旦启动，微信客户机建立一个页面堆栈，为MiniApp启用页面操作。有两种方法促进了这个路由过程：呈现层中的小部件和逻辑层中特定于导航的子应用程序api。前者提供miniapp内部和跨miniapp导航，由小部件的target属性控制，并提供基于open-type属性的各种路由方法。

后者在逻辑层实现路由，使用url属性指定目标页面，并使用wx等api。navigateTo和wx。redirecto支持不同的导航结果。

事件驱动的回调

MiniApps是事件驱动的，通过适当的逻辑执行和界面更新来响应UI交互。因此，对MiniApps的静态分析应该考虑影响控制流的UI事件驱动的回调函数。这项工作主要关注以下两种关键类型的回调：

• 生命周期回调 包括两个分支的MiniApp生命周期——app实例和Page实例生命周期。例如，一个冷启动的MiniApp首先触发应用实例的onLaunch回调，当MiniApp启动时表面，它触发onShow回调。页面的第一次加载激活page实例的onLoad回调，该回调在显示和堆叠时触发onShow回调。
• GUI事件处理程序回调 进了MiniApp的渲染层和逻辑层之间的通信。与UI组件/小部件绑定的事件在用户交互时触发这些回调，从而支持GUI反馈处理。

与原生/Web应用的比较

在当代应用程序开发中，MiniApps、Native Apps和Web Apps代表了三种不同的范例。
虽然它们之间有相似之处，但每一个都有其独特的特点和功能。在下面，我们将阐述这些平台的不同特征，特别关注两个主要方面：

打包和构建机制
与缺乏特定打包格式的web应用不同，MiniApps和本地应用需要特定的文件格式来分发和安装。MiniApps通常打包为WXAPKG，与原生应用（分别针对Android和iOS平台使用APK或IPA格式）存在显著差异。这些应用程序的构建过程也呈现出显著的差异。与原生应用不同的是，原生应用的捆绑过程通常允许一次访问所有源代码，而MiniApps中的子打包机制本质上限制了静态获取代码只能获取主包。MiniApps中的子包代码不能立即可用；它需要动态遍历，并根据需要加载，这与原生应用捆绑中全面的代码可用性有明显区别。

渲染机制
MiniApps利用了专为微信生态系统设计的混合渲染方法，结合了WebView和Native组件。它的独特组件，如，类似于HTML的<a>标签和本地应用程序导航功能的混合体，体现了与微信用户体验的集成。WXML中的媒体组件，如、和，虽然在功能上与本机和Web应用中的对应组件相似，但它们经过了性能微调，并直接与微信平台集成。

动机示例

在图2中提供了一个运行的示例，展示了MiniApp如何收集和使用隐私，它由三个关键阶段组成：
(1)跨包页面路由。用户通过pages/myInfo（主包）中的<navigator>（）和< button >（）触发跨包页面路由，分别导航到pages/ takepphoto（主包）和pages/checkID（动态加载的子包）；
(2)事件驱动回调执行。用户通过UI交互触发pages/ takepphoto(9)和pages/checkID(6)中的绑定事件，逻辑层（JavaScript）分别执行事件驱动的回调函数takepphoto和onInput；
(3)敏感数据流传播。在异步函数回调过程中，敏感数据流进一步完成传播（粉状链接）。

在这个例子中，由于缺乏足够的页面路由和绑定事件，子包中的页面/demo和其中的startRecord函数被认为是不可达的，这可能会在以前的dfa方法中导致FPs[25,31,41]。

miniapps混合分析的挑战

考虑到MiniApps的独特性，它依赖于Web技术并整合了原生应用的功能，对MiniApps的混合分析主要面临两个关键挑战：

挑战#1：跨文件/包回调控制流解析的复杂性
在MiniApps中，一个突出的挑战来自于分析控制流的复杂性，特别是由于跨不同文件和子包重用回调函数的广泛实践。MiniApp开发的这一方面呈现了一个独特的场景，这与Android/iOS环境中的现有技术并不直接相似。开发人员经常定义回调函数逻辑，然后将这些回调函数导入到MiniApp的各个页面和子包中。这将导致跨文件和跨（子）包回调的复杂、纠缠的控制流图，极大地使跟踪用户交互和理解事件驱动行为的过程复杂化。

挑战#2：在UI小部件中定位微信特定组件的不足
WXML中独特的组件给UI探索领域带来了独特的挑战。这些挑战主要源于传统测试工具的局限性。WXML组件是专门为与微信生态系统保持一致而设计的，它与典型的文档对象模型（DOM）结构或传统工具所熟悉的本地UI框架有很大的不同。这种分歧使得像UIAutomator这样的工具无法直接从GUI小部件树中识别和定位这些组件。这种限制要求开发或调整专门的测试工具和方法，以满足WXML组件的独特结构和行为，确保对MiniApps进行有效和高效的测试。

对潜在解决方案的见解

提炼出了两个潜在解决方案的精细化见解：
见解1：为MiniApps构建细粒度和全面的拓扑结构
为了解决挑战#1，主要重点是构建一个详细而全面的MiniApps拓扑结构。

这种结构有助于在文件和子包之间进行更细致的分析，支持深入的控制（1、2）和数据流（3）分析。值得注意的是，在此框架中集成回调控制流分析对于动态UI探索至关重要。它还可能成为静态数据流分析的起点，从而减少静态分析中的误报。这种见解强调了对多方面方法的需求，将细粒度结构映射与高级流分析相结合，为页面转换分析和自动化UI探索提供坚实的基础。

见解#2：使用针对特定平台组件的模糊匹配来增强现有的动态测试工具
该策略包括增强现有的动态测试工具，以更好地处理特定于平台的MiniApp小部件。这种增强可以通过实现基于关键组件属性（如名称、类型和文本）的模糊匹配机制来实现。通过在静态WXML组件和动态UI Widget Tree元素之间建立精确的相关性，我们可以在动态运行时显著改进对特定于miniapp的小部件的识别。这种方法既保证了对MiniApp独特组件的正确识别，又提高了动态测试工具的整体有效性。这种见解强调了根据MiniApp平台的特殊性调整测试方法的重要性，利用静态和动态分析属性来实现全面的测试覆盖。

方法

提出了MiniScope，一个基于两阶段迭代混合程序分析的自动化UI探索和隐私不一致分析框架，如图3所示。该框架由三个关键模块组成：MiniApp依赖图生成器（§4.1），定向UI浏览器（§4.2）和隐私不一致检测器（§4.3），其中进一步包括策略分析器和隐私实践监视器，从而促进流到策略的交叉验证。我们的方法分为两个不同的阶段，每个阶段都包括一轮静态分析，然后是一轮UI探索。整个工作流程的结构如下：

主包分析（第一阶段）
MiniScope的初始阶段致力于通过UI探索动态加载子包，以获得完整的包。首先，MiniScope初始化主包的MiniApp依赖图（MDG）。随后，在MDG的指导下，定向UI资源管理器采用子包定向的宽度优先遍历策略来探索子包页面，从而获得MiniApp的完整包。

全包分析（第二阶段）
在第二阶段，MiniScope基于对合并完整包的分析来处理隐私实践的精确识别。参照前一阶段的方法，我们开始通过静态分析构建完整的千年发展目标。在UI探索阶段，minicope采用隐私实践导向的深度优先策略，这有助于对敏感行为进行运行时探索，从而对MiniApp的隐私实践进行细致入微的理解。

MiniApp依赖图生成器

为了便于自动化UI探索和更精确的隐私实践检测，MiniScope分析了UI状态转换、回调控制流和通用数据流。通过结合它们，minicope能够获得MiniApp的全面而准确的拓扑视图。

分析UI状态转换

MiniApp包含许多页面，每个页面执行不同的功能。

这些模块之间的交互和切换是通过页面路由实现的。为了精确地捕获页面路由信息，MiniScope构造了一个UI状态转换图（UI State Transition Graph， UTG）来对这个页面路由逻辑建模。

定义1 (UTG)
UI状态转换图（UTG）表示静态GUI模型[19,27,49]，它描述了MiniApp中的页面转换序列。形式上，UTG可以表示为一个有向图𝐺𝑈=（V𝑈，E𝑈，λ𝑈），其中V𝑈是一组具有属性（包括类型、资源ID、文本、边界、GUI事件和回调方法）的页面GUI状态；E𝑈是触发页面路由的一组GUI事件，作为过渡条件边；λ𝑈是解析页面路由条件的函数。

UTG建设
在构建UTG时，MiniScope分别分析呈现层和逻辑层：(1)对于呈现层，MiniScope关注WXML文件中负责页面导航的<navigator>小部件，open-type属性表示路由方法。(2)对于逻辑层，MiniScope主要评估与页面路由api相关的JavaScript代码。例如，wx。navigateTo将当前页面添加到页面堆栈并进行导航到新的一页。通过检查<navigator>小部件中的五种方法和逻辑层中的五种页面路由api，如表2所示，MiniScope可以描述解析函数λ𝑈中所有可能的页面转换，并静态地构造UI状态转换图𝐺𝑈。

一个UTG例子
图4展示了Express MiniApp的简化UTG示例。在这个例子中，集合𝑈包含三个页面：“pages/myInfo/index”(A)、“pages/ takepphoto /index”(B)和“pages/checkID/index”©。

在MiniApp框架中，所有页面小部件都必须在WXML文件中注册。我们通过遍历这些小部件来确定页面状态∑𝑈。例如，PageA由6个<navigator>小部件组成，当我们点击<navigator url= " /pages/ takepphoto /index " >时，它将导航到相应的页面，使小部件成为集合E𝑈从PageA到PageB的过渡条件。

分析回调控制流

在MiniApps中，渲染层小部件绑定到特定的UI事件。当发生这些事件时，逻辑层通过执行相应的事件处理程序回调函数进行响应。

因此，我们构建回调控制流图（CCFG）来进行回调函数级别的控制流分析。

定义2 (CCFG)
回调控制流图（CCFG）为GUI事件回调或生命周期回调的序列建模[50]。在形式上，CCFG可以表示为一个有向图𝐺(=(,)，其中是MiniApps页面中的一组函数，是一组触发回调函数并充当触发条件边的GUI事件或生命周期事件，是解析回调函数触发条件的函数。

确定CCFG入口点
在构造之前，有必要确定CCFG入口点，它们是事件驱动的回调函数。这是通过对呈现层小部件及其关联的事件处理程序回调函数执行跨语言分析来完成的。用户与这些小部件的交互会触发相应的事件处理逻辑，激活MiniApp中相关的控制流。如图2(9)所示，带有“ bindtap = takePhoto ”属性的小部件将绑定到Tap事件，并在触发Tap事件时执行takePhoto函数。此外，页面生命周期回调还可以作为CCFG入口点，因为它们与特定的生命周期事件相关联，并在这些事件发生时执行相关逻辑。

CCFG建设
从确定的入口点开始，MiniScope在JavaScript语言中构造函数调用链的其余部分，以获得完整的CCFG。考虑到MiniApps的高度可定制性和基于框架的特性，一个定制的跨文件/包回调控制流分析方法是必要的。MiniApp页面中的函数定义类似于类方法定义，因为它们都是在Page（）对象实例中定义的。

在初始化期间，开发人员将所有生命周期回调函数、事件处理函数和自定义函数作为属性方法提供给Page对象。方法间通信需要“this”关键字，它引用当前的Page对象。值得注意的是，一些常用的回调函数可以在共享的JavaScript文件中定义，然后跨各个页面导入。利用这些观察，我们设计了一个基于JavaScript抽象语法树（AST）的跨文件回调控制流分析算法。该算法考虑了MiniApps中函数使用和调用的独特模式，包括跨不同文件和子包共享使用回调函数。

定义3 (AST)
摘要语法树（AST）[48]可以详细地表示源代码的语言结构。

在形式上，AST可以表示为一个无向属性图𝐺A=（VA，EA，λA，μA），其中，VA是AST节点的集合，EA是用函数λA定义的AST边的集合。另外，我们给每个节点分配了一个属性μA，它表示该节点是操作符还是操作数。

构造算法
算法1描述了跨文件CCFG构建的主要步骤。该算法需要输入包括AST𝐺𝐴当前页面,一组𝑝𝑎𝑔𝑒𝑀𝑒𝑡ℎ𝑜𝑑𝑠,一组𝑒𝑛𝑡𝑟𝑦𝑃𝑜𝑖𝑛𝑡𝑠,和一组𝑠𝑒𝑛𝑠𝑖𝐴𝑃𝐼𝑠。

该算法的输出是完整的CCFG𝐺.；具体来说，该算法由以下三个关键部分组成：

• getImportedMethods()函数:遍历所有节点在AST。如果一个节点是一个𝐼𝑚𝑝𝑜𝑟𝑡𝐷𝑒𝑐𝑙𝑎𝑟𝑎𝑡𝑖𝑜𝑛,的𝑠𝑝𝑒𝑐𝑖𝑓𝑖𝑒𝑟的节点附加到𝑝𝑎𝑔𝑒𝑀𝑒𝑡ℎ𝑜𝑑𝑠列表(3 - 5行)。

• 函数getCCFG()：遍历𝑓𝑢𝑛𝑐的子节点。如果一个孩子节点是一个𝐶𝑎𝑙𝑙𝐸𝑥𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛,它的被检索节点(11 - 12行)。如果被调用的函数是一个𝑀𝑒𝑚𝑏𝑒𝑟𝐸𝑥𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛和它的左子是一个𝑇ℎ𝑖𝑠𝐸𝑥𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛及其正确的孩子在𝑝𝑎𝑔𝑒𝑀𝑒𝑡ℎ𝑜𝑑𝑠,它添加了一个边缘𝐺𝐶和递归地调用𝑔𝑒𝑡𝐶𝐶𝐹𝐺节点(十三至十八线)。如果被调用的函数在𝑠𝑒𝑛𝑠𝑖𝐴𝑃𝐼𝑠,它还增加了一个边缘𝐺𝐶(20 - 22行)。

• 主要过程:初始化𝑝𝑎𝑔𝑒𝑀𝑒𝑡ℎ𝑜𝑑𝑠通过调用𝑔𝑒𝑡𝐼𝑚𝑝𝑜𝑟𝑡𝑒𝑑𝑀𝑒𝑡ℎ𝑜𝑑𝑠与AST𝐺𝐴和初始列表𝑝𝑎𝑔𝑒𝑀𝑒𝑡ℎ𝑜𝑑𝑠(26行)。然后遍历AST𝐺的子节点。如果一个孩子是一个𝐶𝑎𝑙𝑙𝐸𝑥𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛,得到节点的被(28 - 29日行)。如果该节点在𝑒𝑛𝑡𝑟𝑦𝑃𝑜𝑖𝑛𝑡𝑠,它调用𝑔𝑒𝑡𝐶𝐶𝐹𝐺节点,𝑝𝑎𝑔𝑒𝑀𝑒𝑡ℎ𝑜𝑑𝑠,和一个初始CCFG𝐺𝐶(30 -行)。最后，它返回构建的CCFGC。

为了精确建模MiniApps， MiniScope将UTG和CCFG与TaintMini[41]中提出的UDFG结合起来，创建了一个统一的MiniApps拓扑结构，称为MiniApp Dependency Graph （MDG）。例如，MiniScope可以通过查询图来分析敏感api的分布和触发路径。特别是，我们首先按照其原始定义正式描述UDFG，然后相应地定义MDG。

合并到MinApp依赖图

为了精确建模MiniApps， MiniScope将UTG和CCFG与TaintMini[41]中提出的UDFG结合起来，创建了一个统一的MiniApps拓扑结构，称为MiniApp Dependency Graph （MDG）。例如，MiniScope可以通过查询图来分析敏感api的分布和触发路径。特别是，我们首先按照其原始定义正式描述UDFG，然后相应地定义MDG。

定义4 (UDFG)
通用数据流图（UDFG）可用于捕获MiniApp[41]中的跨语言和跨页面数据流。形式上，UDFG可以表示为一个有向图𝐺𝐷=（VD，ED，λD），其中，VD是数据对象的集合，ED是表示敏感数据流依赖关系和传播方向的边的集合。相应的，λD是跟踪数据流传播的函数。

定义5 (MDG)
MiniApp Dependency Graph （MDG）是由以上四个有向图组合而成的联合拓扑结构。构建MDG的关键在于，在每个页面的CCFG和UDFG中，源代码中的每个语句和谓词都存在一个节点。将UTG的页面节点与每个页面AST对应的根节点合并是很自然的，因此MDG的形式表示为𝐺𝑀= （V𝑀，E𝑀，λ𝑀），其中：

MDG代码片段的动机案例
如图5所示，为了分析相机资源的访问，MiniScope首先定位到页面“pages/ takepphoto”（绿线），该页面通过“pages/index”中的<navigator>小部件进行导航。然后，MiniScope确定CCFG的入口点为“takepphoto”，该入口点由绑定到WXML中的<按钮>（紫色线）的Tap事件触发。通过对控制流和数据流的结合分析，MiniScope可以确定takepphoto函数进一步调用wx。createCameraContext创建上下文，然后将其赋值给变量“ctx”。随后，通过“ctx”触发相机拍照。takepphoto”方法（粉线）。

定向UI资源管理器

动态分析组件利用构建目标来指导任务导向的UI探索。
在两阶段分析中，我们分别遵循子包导向的宽度优先探索策略和隐私实践导向的深度优先探索策略，从而在最大化UI状态空间和最小化探索时间之间取得平衡。

WXML组件与UI小部件树的模糊匹配

正如挑战#2中所描述的，由于在WXML中定义了特定于平台的小部件（例如，<navigator b>）和对可编程属性的支持（例如，使用wx:for进行循环呈现），WXML组件在呈现的UI屏幕中缺乏惟一的resourceID和确定性XPATH，因此很难惟一地定位它们。因此，要利用静态发展目标来指导动态UI探测，我们提出了一种模糊匹配的方法来建立WXML组件和UI小部件树之间的鲁棒映射。如下所述，模糊匹配包含两个主要策略，用于在呈现的UI屏幕上精确定位小部件。

关键属性匹配
第一种策略涉及识别每个特定于平台的WXML组件的一组关键属性，如名称、类型和文本等。然后，MiniScope使用Union （IoU）度量来将这些关键属性与UI屏幕上的小部件的属性匹配起来。IoU的计算方式为𝐼𝑜𝑈=𝑊∩𝑈/𝑊∪𝑈，其中𝑊表示WXML组件中的一组关键属性，𝑈表示当前UI屏幕小部件中的一组关键属性。

XPATH匹配
在UI小部件不具备足够属性信息的场景中，或者当UI屏幕上所有小部件与目标WXML组件之间的最大IoU值低于50%阈值[51]时，MiniScope会计算WXML中目标小部件的XPATH与UI屏幕上的小部件之间的Levenshtein距离。然后选择Levenshtein距离最短的小部件作为候选部件，然后验证目标页面的UI状态。

通过这种模糊匹配方法，MiniScope有效地弥合了静态MDG和动态UI探索之间的差距。通过利用关键属性和Levenshtein距离，MiniScope能够准确地将WXML组件映射到UI Widget Tree中相应的小部件，从而克服了在WXML中定位特定于平台的小部件的固有挑战。

任务导向的UI探索策略

minicope在两个阶段采用不同的探索策略，精心设计通过动态加载子包和调查隐私实践来全面分析MiniApps。

子包导向的BFS探索
在第一阶段，为了有效地加载子包并最大限度地探索页面状态空间，MiniScope利用主包的MDG进行BFS探索。此过程首先从MDG中提取所有子包页面转换路径，并在队列中维护它们。利用Appium [14]， MiniScope获得当前UI屏幕的小部件，并计算IoU和Levenshtein距离，以准确定位过渡路径内的目标小部件。执行导航后，MiniScope将验证当前页面路径是否与预期页面路径一致。到达目标子包页面后，所有相关的页面转换路径都将从队列中删除，从而简化了探索过程。

隐私实践导向的DFS探索
完成BFS后，MiniScope解包并将动态加载的子包合并到主包中。随后的一轮静态分析将更新MDG。在第二阶段，在完整的MDG的指导下，minicope深入研究了专注于MiniApp中与隐私相关的实践的DFS探索。与BFS类似，这个探索过程涉及计算特定页面上的GUI事件，以触发相关的回调。然而，与BFS相比，DFS探索优先完成队列中先入先出的每个潜在隐私实践路径，确保对隐私实践的彻底检查。

通过上述两阶段任务导向的UI探索策略，MiniScope实现了对MiniApp的全面和系统的分析，确保对MiniApp隐私实践的强大和详细的了解，解决了其独特功能带来的挑战。

隐私不一致检测器

MiniScope可以无缝地实现许多安全和软件工程任务。在本文中，我们的主要焦点集中在微型应用程序中使用MiniScope来检测隐私不一致。因此，我们采用了一种创新通过检测敏感api和与隐私策略中的语句交叉验证来检测不一致，从而监视MiniApps中的隐私实践。

私隐实务监察员

在这个组件中，MiniScope利用Frida框架[21]来挂钩敏感api。这使我们能够在动态UI探索期间监视MiniApp发出的API调用。当这些API调用被触发时，我们的监视器捕获关键的上下文信息和堆栈跟踪，记录任何检测到的语句。然而，MiniApps主要通过api来执行它们的逻辑层，这些api是通过JSBridge机制[30]从本地库函数封装而来的。因此，我们面临的主要挑战在于每个子应用API与Java层对应的系统API之间的映射。通过对微信进行逆向工程，我们发现从JavaScript调用MiniApp API会触发主机平台提供的一个本地桥接函数，该函数管理实际系统API的执行。在微信MiniApps的上下文中，这个桥接函数位于commonjni中。AppBrandJSBridgeBinding类，特别是在invokeCallbackHandlerI（int, java.lang.String）方法中。

利用object[36]（一个由Frida[21]提供支持的运行时移动探索工具包），MiniScope钩住这个桥接函数，检查它的参数和运行时调用堆栈。这允许我们建立从每个子应用API到相应的Java层系统API的映射（详细信息请参见我们的在线文档[13]）。请注意，构建微信到android API映射的过程是离线的，一旦构建完成，可以在整个分析过程中重用。

基于LLM的隐私政策分析

为了确定个人数据收集和使用的披露，我们借鉴了Polisis[23]和PolicyLint[10]之前的工作，然后构建了三个本体来描述隐私声明。

私隐声明的定义
如表3所示，我们将隐私策略表示为一系列三元组，即（DC, SSoC， DE）。DC数据控制者是负责确定个人数据处理目的和方式的一方，可以是应用程序本身（第一方）或第三方。SSoC动词指的是描述数据的存储-共享或收集的动词列表。DE数据实体代表可以识别或反映自然人活动的任何隐私信息。

提示设计
以前的工作[10,23,26]依赖于手动注释的语料库来训练命名实体识别模型（如CRF， BiLSTM， BERT等）来预测实体标签，或者通过构建数据和实体依赖（DED）树来提取隐私策略声明的元组表示。随着最近大型语言模型（llm）的出现，我们的目标是通过使用少量上下文学习对llm进行微调来完成隐私策略提取。提示符由三个部分组成：(1)任务描述，(2)少量演示，(3)查询。为了更好地理解，我们提供以下提示示例。

隐私不一致分析

API-to-Privacy映射
为了弥合API调用和隐私策略之间的语义差距，特别是在数据实体方面，我们从官方微信文档[8]中收集了29个敏感API的详细描述，包括API函数、参数等。我们根据语义将API的使用与特定的隐私数据访问/收集关联起来。

也就是说，隐私策略中的数据实体分为13个类别，详见我们的在线文档[13]。

Flow-to-Policy交叉验证
如果敏感数据流（如收集、存储或共享）在隐私策略中明确披露，我们认为它们符合策略。否则会产生不一致。根据PoliCheck b[11]中的一致性模型，我们将不一致的隐私披露分为两类：1)冗余披露（RD），其中策略提到的隐私相关实践多于实际。这可能意味着开发者会公开所有可能的敏感行为，从而降低潜在风险。2)遗漏的披露（OD），与隐私相关的做法发生，但没有在政策中提及。

评估

我们已经用Python用9466行代码（LoC）实现了一个MiniScope的原型，不包括任何第三方库或开源工具。然后，我们对MiniScope进行了评估，旨在回答以下研究问题（rq）：
•RQ1（有效性）：MiniScope在检测隐私相关实践和分析隐私政策方面的有效性如何？
•RQ2（消融研究）：MiniScope的每个组成部分分别如何影响性能？
•RQ3（现实世界中的大规模研究）：MiniApps生态系统中侵犯隐私的情况有多普遍？

实验设置

数据
为了收集MiniApps，我们利用开源工具MiniCrawler[57]从微信App Market下载MiniApp包。我们总共收集了127,460个MiniApps，总大小为289 GB。为了从我们的MiniApps列表中收集隐私政策，我们设计并部署了一个隐私政策爬虫。根据AppID向微信服务器请求隐私策略，在8小时内完成收集过程。由于普遍缺乏隐私政策，我们发现只有10786个（8.4%）小应用程序有有效的隐私政策。

基线基准
为了确保对RQ1和RQ2进行可靠的评估，我们通过从数据集中随机抽样150个MiniApps来形成基准。它们被动态执行以加载子包，并由三位经验丰富的研究人员分别手动检查，这构成了他们与隐私相关的实践的基本事实。为了确保彻底的动态交互，每个研究人员与MiniApp交互5分钟，或者直到所有可访问的页面/功能被完全触发，以先发生者为准。

运行环境
实验是在一台运行Ubuntu Linux 22.04版本的服务器上进行的，该服务器使用了两台64核AMD EPYC 7713和256 GB RAM。动态测试在Android虚拟设备（AVD）上进行，系统版本为Android 8.1.0， API版本Level 27。使用的微信版本为8.0.37，WebView内核版本为107.0.5304.141。

MiniScope的有效性（RQ1）

MiniScope的疗效取决于两个关键因素：
1)混合分析的准确性；
2)隐私政策的有效性分析。

混合分析的有效性
在我们的地面真实数据集上，我们比较了MiniScope和TaintMini[41]的性能。为了进行综合评估，我们使用以下指标：真阳性（TPs），假阳性（FPs），假阴性（FNs），精度，召回率和F1分数。

评价结果列于表4。在检测20个敏感api中的19个方面，MiniScope显着超过TaintMini，提供最高的精度，召回率和F1分数。TaintMini的低精度源于在不可达代码中发现的误报，而其召回率的降低是由于它省略了子包和使用了单个数据流分析。这导致TaintMini忽略了许多特定于设备的API调用，比如wx。openBluetoothAdapter，它可能只被调用一次，不涉及数据流传播。通过结合页面状态转换分析、回调控制流分析和通用数据流分析，MiniScope提供了最佳的整体性能。

基于LLM的隐私政策分析的有效性
我们将基于llm的方法与五个基线NER模型进行比较。特别是，我们使用GPT-3.5-Turbo来执行查询。在这个过程中,我们不断的默认配置gpt - 3.5涡轮增压与𝑡𝑒𝑚𝑝𝑒𝑟𝑎𝑡𝑢𝑟𝑒= 1,𝑡𝑜𝑝_𝑛= 1。为了完成实验，我们利用了估计总共需要6.2万个tokens来分析100个隐私政策。对于其他五个基线模型，我们使用CA4P-483[59]语料库中的注释来训练它们。为了确保无偏评估，我们对模型进行了10次交叉验证，其中8次用于训练，1次用于参数调整和优化，1次用于测试。表5给出了这些模型的详细性能。我们观察到GPT-3.5-Turbo显著优于其他基准模型，表明其具有较高的鲁棒性和有效性。

消融实验（RQ2）

我们进行了消融研究，以了解UTG和CCFG如何改善MiniScope的性能。为此开发了三种MiniScope变体：

1. MiniScope- udfg - only，它禁用UTG和CCFG来模拟TaintMini方法；
2. minicope - static - only，启用UTG和CCFG；
3. scope - dynamic - only，它删除了静态引导。

由minicope变体检测到的与隐私相关的实践的数量
图6显示了由MiniScope检测到的与隐私相关的实践的数量，以及地面真实数据集上的三个不同基线。可以观察到，MiniScope是每个变体基线的超集。此外，通过结合静态和动态方法，MiniScope确定了13种无法被每个单独组件检测到的与隐私相关的实践。这表明，MiniScope采用的方法提高了隐私相关实践识别的性能，也证明了它的鲁棒性。

通过minicope变体实现与隐私相关的规范化实践检测
为了更好地可视化和理解，我们在图7中展示了由MiniScope和其他三个变体基线检测到的规范化隐私相关实践。

归一化后的值计算如下：


从UDFG-ONLY和static - only之间的比较中，我们注意到由于UTG和CCFG的集成，特别是在设备和专辑类别中，与静态隐私相关的实践识别方面的性能显著提高。这加强了我们的RQ1发现，TaintMini对单一数据流分析的依赖导致这些API类别的假阴性增加。STATIC-ONLY通常优于DYNAMIC-ONLY。这是受MiniApps特性影响的结果，例如需要用户登录或特定的购买完成，这影响动态分析召回。通过使用混合分析，MiniScope优于STATIC-ONLY和DYNAMIC-ONLY，有效地结合了它们的优势，以实现更有效的隐私实践识别。

现实世界中的大规模研究（RQ3）

测量
我们利用MiniScope对现实世界中的127460个MiniApps进行了大规模的合规违规检测。初步结果表明，在这些MiniApps中，有33,570个（26.37%）收集和使用隐私信息。然而，只有10786个（8.46%）的小应用程序有有效的隐私政策。这凸显了MiniApp生态系统中普遍存在的严重隐私风险。此外，我们根据隐私政策评估隐私相关实践的一致性，以检测隐私合规违规行为。

表6给出了符合性检测的详细统计结果。冗余披露是指隐私政策中超过隐私相关实践的披露，遗漏披露是指隐私政策中少于隐私相关实践的披露。前者被认为是弱违反，后者被认为是强违反。由于MiniApp中可能存在多个RD或OD实例，我们对每种类型的隐私相关实践的披露分布进行分类和记录。总的来说，我们总结了我们的发现如下。

发现
在我们对MiniApps违规行为的研究中，我们发现冗余披露（占所有案例的13.1%）明显超过遗漏披露（1.1%）。MiniApps更倾向于过度披露与PhoneCalendar相关的隐私相关做法（49.7%），这可能是由于即使在限时事件结束后删除相关隐私做法后，开发者仍保留政策披露。相比之下，省略披露在媒体、地址、用户信息和相册等类别中更为普遍，可能是因为开发人员没有意识到这些类别需要根据微信的策略[8]获得许可。我们的大规模研究表明，5.7%（614/10786）的MiniApps秘密地过度收集私人数据，而33.4%（3599/10786）夸大了他们的实际数据收集。

对开发者负责任的披露
根据我们的调查结果，我们已经通过从隐私政策中获得的电子邮件向他们的开发者披露了这些违规行为。特别是，我们与开发人员分享了我们的方法和minicope检测到的潜在隐私遵从性违规的触发路径，并询问他们对这些发现的反馈。总的来说，我们总共通知了2282名开发者，其中1727封邮件被成功发送，396封邮件被服务器的过滤策略拦截，其中159封邮件被报告为无法发送的邮件地址。

如表7所示，截至撰写本文时，我们已经收到了来自MiniApp开发者的46个回复。我们将他们的回答总结如下：

• 42名开发者完全接受我们的调查结果，并承诺更新他们的隐私政策。大多数公司都承认，他们的隐私政策已经过时，过去的版本包含了相关的隐私信息，而这些信息的披露是多余的实践（这进一步证实了我们之前的发现）。开发人员表示希望MiniApp平台能够提供自动代码审核并保持一致的隐私遵从性。

• 2名开发者部分接受我们的发现并提供有价值的建议。他们将一些冗余的披露归因于通过MiniApps中的表单收集用户输入数据。因此，他们认为我们的发现部分准确，打算根据我们的结果有选择地更新。这些见解强调了我们方法的潜在改进领域，特别是在处理MiniApps中的用户输入隐私方面。

• 2名开发者不同意我们的发现。这些开发人员强调，在我们的研究中，部分检测到的隐私过度索赔源于选择性功能可访问性，这是专门为某些目标用户或限时促销量身定制的。这种选择性的可访问性可以基于特殊的入口点实现，例如QR码扫描，导致我们的分析工具无法访问MiniApps中的受限页面，从而省略了相应的隐私实践分析。我们将在§6.1中进一步讨论这类检测的边缘情况。

案例研究
我们对检测到的侵犯隐私的MiniApps进行案例研究，以了解这些侵犯行为的具体影响。在这里，我们提出两个典型的案例。

•冗余披露。一个极端冗余披露的例子是一款名为“万餐堂”（AppID: wx5e4dc66b2f***）的在线订餐小应用，它的评分为4.2星，近期用户超过1000人。虽然它的隐私政策公开了几乎所有的隐私类型（总共19种），但MiniApp实际上只使用了3种类型：用户信息、位置和相册。这种过度披露可能会加剧隐私风险，因为任何隐私实践似乎都可以与过于全面的隐私政策相抗衡。

•省略披露。微应用程序“海回手”（AppID: wxded0379a82***）中省略披露的一个例子，该应用程序的平均评分为4.0，评论约为200条。尽管它在其政策中披露了4种隐私类型，但我们的分析发现了其页面/演示/演示源代码中未披露的实践。onLoad函数创建Camera上下文，请求WeRun数据，并收集Address信息。这些未披露的做法构成违反隐私合规的行为。

讨论

对有效性的威胁

局限性
解包对MiniApps的影响
尽管我们尝试使用最先进的开源工具，如wxappUnpacker[47]和decrypr[34]，但我们数据集中的235个（0.2%）MiniApps无法成功解压缩。

某些使用统一编程风格的第三方多端框架开发的MiniApps，在解包后可能没有标准的页面结构。这种情况影响了1.3%的地面真实数据集，在静态分析中导致了大约11.0%的假阴性率。

动态分析中遇到的极端情况
动态分析的有效性可能会受到意想不到的极端情况的影响。在像在线购物MiniApps这样的情况下，我们无法实际完成订单或访问评论页面，我们依赖于静态分析来检测潜在的隐私不一致。同时，正如一些开发人员所反映的，某些页面或功能是根据特定的标准动态提供给用户的，或者是通过特殊的入口点（如二维码扫描）提供的，这使得我们的静态分析无法确定回调条目，相应地动态分析也无法执行。

可能对事实有偏见
在我们的评估中使用的基本事实（RQ1和RQ2）可能会受到人工确认偏差的影响。尽管我们努力让三位经验丰富的安全研究人员进行细致的检查并达成共识，但仍然可能存在潜在的偏差，这可能会在子包动态加载或与隐私相关的实践识别中出现。

可扩展性和可转移性

研究中，虽然主要关注微信MiniApp生态系统，类似于其他作品[25,31,41]，但重要的是要强调我们提出的方法在其他平台上的可扩展性和可移植性。正如W3C MiniApp标准化白皮书[39]所强调的那样，跨大多数平台的MiniApps共享类似的底层架构，使用JavaScript进行逻辑编程和类似的布局文件（微信中的WXML，支付宝中的AXML，百度中的SWAN和TikTok中的TTML）。这种体系结构的一致性表明，最初为微信量身定制的MiniScope具有通过最小调整实现更广泛适用性的巨大潜力。通过对其进行微调以适应每个平台特定组件和api的细微差别，MiniScope可以毫不费力地迁移并应用于微信以外的其他生态系统。这种可移植性不仅增强了我们研究的实用性和范围，而且为跨不同MiniApp平台的全面隐私和安全分析开辟了途径。

相关研究

MiniApps作为一种新颖的应用范式，近年来开始引起学术界的关注。这一领域的前期研究主要分为三个方面。

MiniApps的安全性和隐私性。一些调查已经深入研究了Miniapps的安全方面[28,30,42,44,53 - 55]。值得注意的是，现有的研究[44]从现实场景中收集了83个MiniApp bug，并开发了WeDetector来识别以下三种bug模式。另一个项目[30]则探讨了小程序生态系统中的系统资源暴露、子窗口欺骗和子应用生命周期劫持等问题。他们对11个流行的平台进行了评估，以确定这些安全问题的普遍性。此外，还研究了MiniApp中一个新的隐私泄露问题，该问题可能导致MiniApp平台窃取私人数据。他们阐明了利用这个漏洞的攻击过程。最后，分析了小程序通信中存在的跨小程序请求伪造漏洞（CMRF）[53]。他们揭示了根本原因，并设计了CMRFScanner工具来检测它。此外，一系列研究都强调了隐私在MiniApp生态系统中的重要性[16,25,31,41,43,46,52,56,58]。TaintMini[41]引入了一个框架，用于使用静态污染分析检测小程序内部和跨小程序的敏感数据流。另一个作品MiniTracker b[25]构建分配流程图作为不同主机应用程序的共同表示，并对150k个MiniApps进行了大规模研究，揭示了常见的隐私泄露模式。此外，一些研究[16,31,58]已经将重点放在了检测AppSecret泄漏的污染分析技术上。特别是，另一项工作[46]专注于MiniApps中数据收集和使用的一致性。他们抓取了2998个MiniApps，发现其中89.4%违反了他们的隐私政策。最近，Zhang等人引入了SPOChecker，并对MiniApps中的隐私过度收集进行了首次系统研究。如表8所示，尽管这些方法对理解隐私维度做出了重大贡献，但这些仅静态和仅dfa的方法在准确的隐私行为识别方面存在不足，这表明了一个需要进一步探索和研究的关键领域。

各种平台的隐私分析【持续关注中…】
近年来，对各种平台的隐私分析的探索，特别是实际应用行为与声明隐私政策之间的一致性，变得越来越重要。

在评估移动应用中的隐私政策依从性方面已经付出了相当大的努力，这通常是通过分析敏感API调用[37,60]或用户输入[32,45]来自动执行的。像PoliCheck[11]这样的工具已经考虑到个人数据的接收者，从而提高了合规性分析的准确性。此外，purplance[18]检测隐私政策与Android应用程序实际行为之间的数据使用目的不一致。除了移动应用程序，研究人员还深入研究了其他平台。例如，ExtPrivA[17]和Ling等[26]专注于检测浏览器扩展中隐私披露和数据收集行为之间的不一致。overseen[38]比较网络流量和隐私政策，以分析OVR应用程序暴露的个人数据。虽然以前的工作提供了跨各种平台的隐私合规性有价值的见解，我们的研究将这些努力扩展到MiniApps的新兴领域。

总结

本文介绍了一种使用混合分析来检测隐私不一致的工具。MiniScope利用静态分析为动态测试提供高级指导，并使用隐私策略交叉验证运行时行为。

评估显示，MiniScope识别隐私实践的平均准确率、召回率和F1得分分别为99.2%、95.6%和97.4%。我们的大规模研究揭示了MiniApp生态系统中的隐私不一致问题，在127,460微信个MiniApp中，只有10,786个提供了有效的隐私政策，而2,282个（21.2%）显示了各种隐私侵犯。我们已经向2282名开发者公开了我们的发现，其中有44人表示感谢。我们相信，minicope将帮助研究人员和开发人员识别和减轻MiniApps中的隐私风险。

注：仅供学习交流