本发明涉及Android查漏的技术领域，尤其涉及到一种Android应用隐私泄露漏洞检测方法。

背景技术：

在目前的Android隐私泄露漏洞检测方法中，静态污点分析是最常用且最有效的方法。首先对android应用进行反编译，获取其源代码或是中间代码，并通过识别代码中存在的源点(source)与锚点(sink)来判断是否进行下一步的检测操作，这里的源点与锚点的确定因检测问题而异。如检测应用中的隐私泄露问题，则这里设置源点为获取敏感数据的API，如getDeviceId()函数；而锚点则为将敏感数据发送到该应用之外的操作，如发送短信sendtextmessage()函数。在确定源锚点之后，即可使用静态污点分析检测是否存在一条从源点到锚点的路径，若存在则可判定该应用有隐私泄露问题。

Android应用由4类基本组件构成，包括Activity(活动),Service(服务),Broadcast receiver(广播接收器),content provider(内容提供器)。Intent是Android应用组件间通信(ICC)的主要媒介，通过startactivity(intent),startservice(intent)等ICC方法可以启动Activity、Service，或者可以向Broadcastreceiver发送广播消息。

Intent包含显式和隐式两种。显式Intent指定了接收组件，因此Intent会发送到某个指定的组件；而隐式Intent的接收组件是满足条件的所有组件，即可以有多个接收组件，由android系统确定哪个应用可以接收该Intent。

通常对Android应用隐私泄露漏洞的检测，一般在同一个组件内进行(源点和锚点在同一组件之内)；而对于组件间通信造成的隐私泄露问题(源锚点在不同组件当中)，目前也局限于同一个应用内组件间检测[1]，且是对使用显式Intent所确定的目标接收组件检测，对跨应用间的隐私泄露问题与使用隐式intent造成的隐私泄露问题研究较少。

[1]L Li,P Mcdaniel,A Bartel,TF Bissyande,J Klein,et al.IccTA:Detecting Inter-Component Privacy Leaks in Android Apps.IEEE/ACM IEEE International Conference on Software Engineering.2015,1:280-291

技术实现要素：

本发明的目的在于克服现有技术的不足，提出一种Android应用隐私泄露漏洞检测方法。本方法使用显式intent调用以及使用隐式intent设置的action、data、category属性查找并匹配所有目标接收组件，从而不仅能检测出同一个应用内组件间显式intent通信造成的隐私泄露问题，还能检测出不同应用间组件通信造成的，尤其是使用了隐式intent导致的隐私泄露问题。

为实现上述目的，本发明所提供的技术方案为：

一种Android应用隐私泄露漏洞检测方法，包括以下步骤：

S1：对APK进行逆向分析获取信息；

S2：对逆向分析获取的信息判断应用的组件是否存在源函数和ICC方法，若存在，则进行步骤S3，否则不存在隐私泄露风险，处理下一个应用；

S3：构建CCP、CCLink以及CFG；

S4：进行污点标记与传播；

S5：判断锚函数中的参数是否包含了污点数据，若是，则判断包含源函数的组件到包含锚函数的组件之间存在一条隐私数据泄露的路径，即可断定从源函数到锚函数之间所涉及的所有组件存在数据泄露的漏洞。

进一步地，所述步骤S1包括解析配置文件、代码反编译分析两个部分；具体过程如下：

S1-1：将apk解压后获取其中的manifest.xml文件并通过使用AXMLprint2.jar提取内容；

S1-2：将APK文件进行反编译，获取应用中的dex文件，然后将android应用反编译为java源代码，并在该代码基础上提取应用组件中有关数据，包括ICC方法、入口点、getintent()方法与接收intent并提取其中数据以及动态注册broadcast receiver的相关信息。

进一步地，所述步骤S1-1中，除了获取清单文件里应用的包名及其组件的基本信息外，还包括应用安全相关的属性，包括应用的权限属性permission与use-permission、组件的exported属性与意图过滤器intent-filter属性。

进一步地，所述步骤S3中，构建CCP的具体过程如下：

首先查找应用组件所有的icc方法，若查找到，则将根据该方法参数输入CCP构造器，使其自动生成匹配目标组件的结果，把发送组件、调用的ICC方法及其参数和匹配到的目标组件存入到CCP表中；

对于动态注册广播，CCP构造器不能有效匹配其结果的情况下，查找应用源代码并解析registerreciver()方法中的第一参数获取接收组件将其添加到与发送组件、ICC方法及其参数相同的对应CCP表中；

若应用没有使用ICC方法，则该应用没有组件间通信安全问题。

进一步地，所述步骤S3中，构建CCLink的具体过程如下：

首先遍历CCP表，并按照以下规则构建CCLink：

如果找到两组CCP均来自同一应用，且存在该两组CCP中其中一组的目标组件与另一组中的发送组件为同一组件，则通过它们的共同组件连接起来；

如果CCP的目标组件与发送组件不是来自同一应用，但其目标组件与另一组CCP的发送组件为同一组件，也通过它们的共同组件连接起来；

对发送组件与目标组件不在同一应用内的CCP直接生成CCLink；

考虑到组件调用的无穷性，规定一条CCLink包含的组件若来自不同的应用，则应用个数不超过三个。

进一步地，所述步骤S3中，构建CFG(控制流图)的具体过程如下：

首先找到CClink涉及的每个组件的入口方法，即activity的oncreate()、onstart(),service的onstartcommand()，broadcastreceiver的onreceiver()，从这些入口方法开始处构建组件内控制流图；在遇到ICC方法时，根据得到的CCP结果找到对应接收组件的入口方法并连接起来生成组件间控制流图,最后将组件内CFG和组件间CFG合并形成完整的控制流图。

进一步地，所述步骤S4中污点标记与传播的具体过程为：在步骤S3构建的CFG基础上，扫描所有语句，找到锚函数，若找到，则把步骤S2找到的源函数产生的对应数据标记为污点,然后进行污点数据传播过程。

进一步地，所述传播过程包括组件内与组件间污点传播；

组件内污点传播根据污点跟踪规则对污点进行传播；

组件间污点传播首先确定接收组件的入口方法，如果为oncreate()或者为onstart()，则将intent数据的污点信息传递给getintent()；如果是onreceive()、Onbind()、onstartcommand()则传递给相应的方法参数。

与现有技术相比，本方案原理和优点如下：

本方案使用显式intent调用以及使用隐式intent设置的action、data、category属性查找并匹配所有目标接收组件，不仅能检测出同一个应用内组件间显式intent通信造成的隐私泄露问题，还能检测出不同应用间组件通信造成的，尤其是使用了隐式intent导致的隐私泄露问题。

附图说明

图1为本发明一种Android应用隐私泄露漏洞检测方法的整体流程图；

图2为本发明一种Android应用隐私泄露漏洞检测方法的原理图。

具体实施方式

下面结合具体实施例对本发明作进一步说明：

参见图1和2所示，本实施例所述的一种Android应用隐私泄露漏洞检测方法，包括以下步骤：

S1：对APK进行逆向分析获取信息，包括解析配置文件、代码反编译分析两个部分；具体为：

S1-1：将apk解压后获取其中的manifest.xml文件并通过使用AXMLprint2.jar提取内容；

除了获取清单文件里应用的包名及其组件的基本信息外，还包括应用安全相关的属性，包括应用的权限属性permission与use-permission、组件的exported属性与意图过滤器intent-filter属性。

S1-2：将APK文件进行反编译，获取应用中的dex文件，然后将android应用反编译为java源代码，并在该代码基础上提取应用组件中有关数据，包括ICC方法、入口点、getintent()方法与接收intent并提取其中数据以及动态注册broadcast receiver的相关信息。

S2：对逆向分析获取的信息判断应用的组件是否存在源函数和ICC方法，若存在，则进行步骤S3，否则不存在隐私泄露风险，处理下一个应用；

S3：构建CCP、CCLink以及CFG；

其中，构建CCP的具体过程如下：

首先查找应用组件所有的icc方法，若查找到，则将根据该方法参数输入CCP构造器，使其自动生成匹配目标组件的结果，把发送组件、调用的ICC方法及其参数和匹配到的目标组件存入到CCP表中；

对于动态注册广播，CCP构造器不能有效匹配其结果的情况下，查找应用源代码并解析registerreciver()方法中的第一参数获取接收组件将其添加到与发送组件、ICC方法及其参数相同的对应CCP表中；

若应用没有使用ICC方法，则该应用没有组件间通信安全问题。

构建CCLink的具体过程如下：

首先遍历CCP表，并按照以下规则构建CCLink：

如果找到两组CCP均来自同一应用，且存在该两组CCP中其中一组的目标组件与另一组中的发送组件为同一组件，则通过它们的共同组件连接起来；

如果CCP的目标组件与发送组件不是来自同一应用，但其目标组件与另一组CCP的发送组件为同一组件，也通过它们的共同组件连接起来；

对发送组件与目标组件不在同一应用内的CCP直接生成CCLink；

考虑到组件调用的无穷性，规定一条CCLink包含的组件若来自不同的应用，则应用个数不超过三个。

构建CFG的具体过程如下：

首先找到CClink涉及的每个组件的入口方法，即activity的oncreate()、onstart(),service的onstartcommand()，broadcastreceiver的onreceiver()，从这些入口方法开始处构建组件内控制流图；在遇到ICC方法时，根据得到的CCP结果找到对应接收组件的入口方法并连接起来生成组件间控制流图,最后将组件内CFG和组件间CFG合并形成完整的控制流图。

S4：在步骤S3构建的CFG基础上，扫描所有语句，找到锚函数，若找到，则把步骤S2找到的源函数产生的对应数据标记为污点,然后进行污点数据传播过程；

其中，传播过程包括组件内与组件间污点传播；

组件内污点传播根据污点跟踪规则对污点进行传播；

组件间污点传播首先确定接收组件的入口方法，如果为oncreate()或者为onstart()，则将intent数据的污点信息传递给getintent()；如果是onreceive()、Onbind()、onstartcommand()则传递给相应的方法参数。

S5：最后进行漏洞检测，即判断锚函数中的参数是否包含了污点数据，若是，则判断包含源函数的组件到包含锚函数的组件之间存在一条隐私数据泄露的路径，即可断定从源函数到锚函数之间所涉及的所有组件存在数据泄露的漏洞。

以上所述之实施例子只为本发明之较佳实施例，并非以此限制本发明的实施范围，故凡依本发明之形状、原理所作的变化，均应涵盖在本发明的保护范围内。