CN104182686A - 一种Android系统Activity劫持风险检测方法及装置 - Google Patents

Abstract

本申请公开了一种Android系统Activity劫持风险检测方法及装置。所述方法包括：在目标Activity进入激活状态之前，获取当前处于激活状态的Activity的特征信息；根据所获取的特征信息，判断所述当前处于激活状态的Activity是否符合预设的安全特征；如果否，则确定系统存在Activity劫持风险。上述方案可以在不改变Android系统运行机制的前提下，直接通过扩展系统函数的方式实现，不仅实现简单，而且通用性强。

Description

一种Android系统Activity劫持风险检测方法及装置

技术领域

本申请信息安全技术领域，特别是涉及一种Android系统Activity劫持风险检测方法及装置。

背景技术

Android是一种以Linux为基础的开放源码操作系统，主要使用于智能手机、平板电脑等便携设备。该系统采用Java语言开发，包括操作系统、中间件、用户界面和应用软件等组成部分。随着Android系统的不断发展，各大硬件厂商也在不断推出各种基于Android系统的产品。目前，基于Android系统终端已经在市场上占有重要地位。

Activity是Android系统的一种基本组件，负责系统与用户之间的交互操作。在Android系统中，一个Activity相当于一个页面，该页面一方面用于向用户显示各种内容，另一方面还用于监听并响应用户的操作行为。

在Android系统运行过程中，各种系统服务或应用程序可能会创建多个Activity，而在某一时刻，系统仅允许一个Activity在前台运行，该Activity处于激活状态，其他Activity则处于暂停或停止状态。利用Android系统的这一特性，恶意程序可以通过创建Activity来实现以伪造页面替换真实页面，这种手段被称为Activity劫持，利用伪造页面，可以达到骗取点击、甚至盗取用户私有信息等目的。更为严重的是，这种手段利用了Android系统的Activity管理机制，具有很强的隐蔽性，无论是在实施劫持的前后还是过程中，者很难被用户发觉。

发明内容

为解决上述问题，本申请实施例提供一种Android系统Activity劫持风险检测方法及装置，技术方案如下：

本申请实施例提供一种Android系统Activity劫持风险检测方法，该方法包括：

在目标Activity进入激活状态之前，获取当前处于激活状态的Activity的特征信息；

根据所获取的特征信息，判断所述当前处于激活状态的Activity是否符合预设的安全特征；

如果否，则确定系统存在Activity劫持风险。

本申请实施例还提供一种Android系统Activity劫持风险检测装置，该装置包括：

特征获取模块，用于在目标Activity进入激活状态之前，获取当前处于激活状态的Activity的特征信息；

特征比较模块，用于根据所获取的特征信息，判断所述当前处于激活状态的Activity是否符合预设的安全特征；

风险判断模块，用于在所述特征比较模块判断结果为否的情况下，确定系统存在Activity劫持风险。

一般的Activity劫持手段，都会在盗取信息完毕后，将伪造的Activity结束，并且真实Activity会被重新激活，以此达到隐蔽的效果，使得普通用户难以发现异常状况。本申请所提供的技术方案，针对Activity劫持手段的上述特点，在真实Activity进入激活状态之前，加入对当前处于激活状态的Activity的检测步骤，通过判断检测到的Activity是否安全，进一步确定系统是否存在Activity劫持风险。

本申请所提供的技术方案，可以在不改变Android系统运行机制的前提下，直接通过扩展系统函数的方式实现，不仅实现简单，而且通用性强。在实际应用中，既可以对所有的Activity开启检测，也可以仅对个别关键Activity开启检测，从而实现对系统安全和性能的灵活调控。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本申请实施例Android系统Activity劫持原理示意图；

图2为本申请实施例Android系统Activity劫持风险检测方法的流程图；

图3为本申请实施例Android系统Activity劫持风险检测方法的原理示意图；

图4为本申请实施例Android系统Activity劫持风险检测装置的结构图。

具体实施方式

Android系统通过一种称为Activity栈的方式来管理Activity，一个Activity实例的状态决定它在栈中的位置，在Android系统中，Activity拥有四种基本状态：

1)Active(激活)/Runing(运行)：

一个新Activity启动入栈后，在屏幕最前端显示，处于栈的最顶端，此时它处于可见并可和用户交互的激活状态。

2)Paused(暂停)：

当Activity被另一个透明或者Dialog样式的Activity覆盖时的状态。此时它依然与窗口管理器保持连接，系统继续维护其内部状态，所以它仍然可见，但它已经失去了焦点故不可与用户交互，这种状态称为暂停状态。

3)Stoped(停止)：

当Activity被另外一个Activity完全覆盖、失去焦点并不可见时处于Stoped状态，也称为停止状态。

4)Killed(回收)：

当Activity被系统回收或者没有被启动时处于Killed状态。

当一个Activity实例被创建、销毁或者启动另外一个Activity时，Activity在这四种状态之间进行转换，这种转换的发生依赖于用户程序的动作。一个Activity的实例的状态决定它在栈中的位置：

处于前台的Activity总是在栈的顶端，当前台的Activity被销毁或者用户执行“回退”等操作时，处于栈第二层的Activity将被激活，上浮到栈顶；当新的Activity启动入栈时，原Activity会被压入到栈的第二层，变为“暂停”或“停止”状态。除了最顶层即处在Active状态的Activity外，其它的Activity都有可能在系统内存不足时被回收，即变为killed状态；一个Activity的实例越是处在栈的底层，它被系统回收的可能性越大。

可见，一个Activity在栈中的位置变化反映了它在不同状态间的转换。Android系统负责管理栈中Activity的实例，根据Activity所处的状态来改变其在栈中的位置。

通过研究发现，Activity劫持正是利用了Activity栈运行机制来实现攻击，同时还可以很好地隐藏自己，使用户难以发觉，Activity劫持的实现原理如下：

恶意程序在系统运行期间在后台启动一个服务(Service)，该服务的作用是对系统中运行的所有进程进行监听，或者对系统当前栈顶的Activity进行监听，将监听到目标程序或目标Activity后，则启动恶意Activity来伪造页面。

参见图1所示，假设恶意程序的目的是盗取某应用程序的账号和密码，那么当监听服务检测到该应用程序进程处于运行状态、或者检测到登录页面对应的Activity处于栈顶时，则立即启动一个Activity，根据Android系统的栈运行机制，新启动的Activity将被放到栈顶，也就是说，原有的真实Activity将被该伪造Activity挤到第二位，此时用户实际看到是伪造的登录页面，用户在该伪造登录页面输入账号和密码，并且确认点击后，信息就可能被发送到了攻击者处，造成用户信息泄露。

另一方面，在用户确认点击的同时，伪造Activity会触发“回退”操作，将伪造Activity从栈中移除，此时栈中第二位的真实Activity被激活，用户将看到真实的页面，尽管可能需要重新输入账号和密码等信息，但用户可能认为是网络问题、程序bug，一般很难意识到自己已经被攻击了。

针对上述问题，本申请提供一种Activity劫持风险检测方法如下：

在目标Activity进入激活状态之前，获取当前处于激活状态的Activity的特征信息；

根据所获取的特征信息，判断所述当前处于激活状态的Activity是否符合预设的安全特征；

如果否，则确定系统存在Activity劫持风险。

Activity劫持是利用了Android系统的自有运行机制实现攻击目的，因此隐蔽性好，难以被发觉。但是，从另一个方面看，由于无法摆脱Android自有机制的限制，也使得Activity劫持有规律可循。一般的Activity劫持手段，都会在盗取信息完毕后，将伪造Activity结束，并且真实Activity会被重新激活，以此达到隐蔽的效果，使得普通用户难以发现异常状况。本申请方案则针对上述规律，在真实Activity进入激活状态之前，加入对当前处于激活状态的Activity的检测步骤，通过判断检测到的Activity是否安全，进一步确定系统是否存在Activity劫持风险。

为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

图1所示，其为本申请所提供的一种Activity劫持风险检测方法的流程图，其中，“目标Activity”指代的是需要保护的真实Activity，“伪造Activity”指代的是恶意程序所创建的恶意Activity。

S101，在目标Activity进入激活状态之前，获取当前处于激活状态的Activity的特征信息；

根据Activity劫持原理，伪造的Activity会在完成欺骗或盗取目的后执行“回退”操作moveTaskToBack(true)，将伪造Activity从栈中移除，然后位于栈中第二位的真实Activity将被移至栈顶激活。也就是说，在真实Activity尚未被激活之前，如果查看当前处于激活状态的Activity，结果将是伪造Activity。那么，只要能够在Activity进入激活状态之前，获取当前处于激活状态的Activity的特征信息，就可以进一步根据所获取的特征信息进行是否安全的判断。

在Android系统的android.app.Activity类中，定义了一系列与Activity生命周期相关的函数，这些函数包括：

onCreate()：是一个Activity的实例被启动时调用的第一个方法；

onStart()：在onCreate()函数之后被调用，或者在Activity从Stop状态转换为Active状态时被调用；

onResume()：在Activity从Pause状态转换到Active状态时被调用；

onPause()：在Activity从Active状态转换到Pause状态时被调用；

onStop()：在Activity从Active状态转换到Stop状态时被调用；

onDestroy()：在Active被结束时调用；

根据Android生命周期描述，一个Activity A如果被另外一个Activity B完全覆盖，A会顺序调用onPause、onStop函数，在重新展示的时候会顺序调用onRestart、onStart、onResume函数。

而B实际要在A调用完onResume函数后才会真正从Activity栈中撤销，因此，如果在B完全覆盖了A，然后退出的过程中，A在onRestart或onStrart或onResume方法中查看当前栈顶的Activity，那么会是B的名称。

如果存在Activity劫持的情况，那么在真实Activity被激活之前，需要调用onRestart、onStart、onResume函数，而在这个阶段，伪造的Activity一直位于栈顶，因此，可以在真实Activity调用onRestart/onStart/onResume函数的任一个阶段，获取当前处于激活状态的Activity的特征信息并进行判断，以确定这个处于栈顶的Activity是否安全。

在实际应用中，除了上述“完全覆盖”情况之外，还可能存在一种“不完全覆盖”情况，即Activity B激活后，所对应的页面并没有把Activity A所对应的整个页面都覆盖住(但是仍然能达到伪装的效果)，这种情况下，A仅会调用onPause函数，在重新展示的时候仅调用onResume函数，因此，上述“获取当前处于激活状态的Activity的特征信息”的操作，应在onResume函数的调用阶段执行。

可见，如果考虑通用性和方便性，将“获取当前处于激活状态的Activity的特征信息”的操作，都放在onResume函数的调用阶段执行即可。

本申请实施例直接通过对系统函数onRestart/onStart/onResume进行扩展来实现Activity的特征信息获取，不仅实现简单，而且通用性强。当然，可以理解的是，这仅是本申请方案的一种优选实施方案，基于本申请方案的基本原理，本领域技术人员可以采用其他手段在“目标Activity进入激活状态之前”实现对可疑Activity的特征信息的获取。事实上，onRestart/onStart/onResume也仅是Android系统现阶段的函数名称而已，即便函数名称发生改变，相应的方案显然也应视为本申请的保护范围之内。

S102，根据所获取的特征信息，判断所述当前处于激活状态的Activity是否符合预设的安全特征；

Activity的特征信息是能够用于表征或识别一个Activity的特征的信息的统称，具体可以是Activity名称、创建该Activity进程的名称、Activity的内存占用大小等等，本申请对此并不需要进行限定。

本实施例中以Activity名称为例进行说明，对Activity是否安全的具体判断策略可以包括很多，一般可以从以下几个方面考虑：

Android系统级的应用程序(名称形式如com.android.xxx)所创建的Activity，认为是安全的；

目标Activity对应的应用程序所创建的Activity，认为是安全的；

根据经验，排除其他可以确认安全的Activity；

判断是否为已经确认不安全的Activity。

上述判断策略，可以通过白名单/黑名单的形式实现，其中，白名单对应安全Activity的特征集合，黑名单则对应不安全Activity的特征集合。

如果获取到的Activity特征信息与白名单匹配成功，则认为该Activity是安全的，如果获取到的Activity特征信息与黑名单匹配成功，则认为该Activity是不安全的。

可以理解的是，在实际应用中，白名单/黑名单可以分别使用，也可以结合使用，本申请对此并不需要进行限制。

白名单/黑名单可以保存为一个单独的文件放置在应用程序的APK中(例如保存XML格式或普通文本格式)，或者作为maplist/String字符串写在java中，允许用户自定义修改；也可以直接存放在服务器中，以便于统一配置和更新。

S103，确定系统是否存在Activity劫持风险。

如果所获取的特征信息不符合预设的安全特征，则认为系统存在Activity劫持风险，其中，“确定存在Activity劫持风险”又包括以下几方面内容：

确定目标Activity存在被劫持风险；

确定当前处于激活状态的Activity为恶意Activity；

确定启动该恶意Activity的程序，找出不安全因素的根源。

确定系统存在Activity劫持风险后，可以以告警的方式通知用户，提高用户的警惕性，以便采取进一步措施；也可以将检测到的风险信息上传到服务器端，供开发人员进一步排查或制定相应的解决方案。

在本申请方案的实际应用过程中，并不是对应用程序的每个Activity都要在激活之前进行判断。事实上，Android系统的Activity状态切换非常频繁，如果对每个Activity都加入激活之前的判断，那么不仅会影响系统性能，而且误报的可能性也大大提升。

基于上述情况，本申请实施例建议仅对存在被劫持风险的Activity加入激活之前的判断，例如，用户登陆页面、支付页面、隐私信息输入页面等等，将这些存在被劫持风险的页面所对应的Activity定义为“目标Activity”，能够较好地防止Activity劫持带来的风险，同时又不至于严重影响系统性能或产生大量告警信息。此外，在实际应用中，也可以向用户提供自定义功能，既可以对所有的Activity开启检测，也可以仅对个别关键Activity开启检测，从而实现对系统安全和性能的灵活调控。

下面结合一个具体的实例，对本申请所提供的Activity劫持风险检测方法进行说明：

假设Activity B是恶意Activity，其攻击目标为Activity A。Activity B的监听程序发现Activity A处于栈顶后，立即启动Activity B，如图3a所示；

Activity B将Activity A挤到了第二位，同时Activity B模仿Activity A样式，诱骗用户将信息输入到Activity B中，如图3b所示；

Activity B在完成信息收集后将自动销毁，Activity A重新回到栈顶，如图3c所示；

其中，Activity B自动销毁过程对应的系统函数调用顺序为：onPause、onStop、onDestroy；Activity A重新回到栈顶过程对应的系统函数调用顺序为：onRestart、onStart、onResume。整个过程的函数调用执行顺序如下：

Activity B onPause；

Activity B onStop；

Activity A onRestart；

Activity A onStart；

Activity A onResume；

Activity B onDestroy。

可见，Activity B在完全销毁前，需要Activity A先执行完resume函数，在此期间，位于栈顶的一直是Activity B。根据该执行顺序，在Activity A的onRestart/onStart/onResume三个函数的任意一个中，判断当前栈顶Activity是否安全即可。

本实施例通过复写onResume函数、根据白名单进行Activity劫持风险检测，代码示例如下：

上述代码的含义是：在目标Activity的onResume阶段，获取获取栈顶的Activity名称(TopActivityName)，如果该Activity非Android系统原生Activity(AndroidActivity)、非应用程序自身的Activity(applicationActivity)、且不在白名单中Activity(WhiteListActivity)，则提示存在劫持风险。

这样，在目标Activity执行onResume函数的过程中，就可以实现对Activity劫持风险的自动检测。

需要说明的是，与前面的实施例介绍相比，本代码中的“WhiteList”是一种狭义的白名单，其中并未包括AndroidActivity和applicationActivity的情况。

相应于上面的方法实施例，本申请还提供一种Android系统Activity劫持风险检测装置，参见图4所示，该装置包括：

特征获取模块110，用于在目标Activity进入激活状态之前，获取当前处于激活状态的Activity的特征信息；

特征比较模块120，用于根据所获取的特征信息，判断所述当前处于激活状态的Activity是否符合预设的安全特征；

风险判断模块130，用于在所述特征比较模块判断结果为否的情况下，确定系统存在Activity劫持风险。

在本申请的一种具体实施方式中，特征获取模块110具体可以用于：

在针对目标Activity调用系统函数onRestart、onStart和/或onResume的阶段，获取当前处于激活状态的Activity的特征信息。

在本申请的一种具体实施方式中，所述目标Activity可以设置为：存在被劫持风险的Activity。

在本申请的一种具体实施方式中，特征比较模块120具体可以用于：

根据预设的黑名单和/或白名单，判断所述当前处于激活状态的Activity是否符合预设的安全特征。

在本申请的一种具体实施方式中，风险判断模块130具体可以用于实现以下几方面内容：

确定目标Activity存在被劫持风险；

确定当前处于激活状态的Activity为恶意Activity；

确定启动该恶意Activity的程序，找出不安全因素的根源。

确定系统存在Activity劫持风险后，可以以告警的方式通知用户，提高用户的警惕性，以便采取进一步措施；也可以将检测到的风险信息上传到服务器端，供开发人员进一步排查或制订相应的解决方案。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种Android系统Activity劫持风险检测方法，其特征在于，该方法包括：

在目标Activity进入激活状态之前，获取当前处于激活状态的Activity的特征信息；

根据所获取的特征信息，判断所述当前处于激活状态的Activity是否符合预设的安全特征；

如果否，则确定系统存在Activity劫持风险。

2.根据权利要求1所述的方法，其特征在于，所述在目标Activity进入激活状态之前，获取当前处于激活状态的Activity的特征信息，包括：

在针对目标Activity调用任一系统函数onRestart、onStart、onResume的阶段，获取当前处于激活状态的Activity的特征信息。

3.根据权利要求1所述的方法，其特征在于，所述目标Activity为：

存在被劫持风险的Activity。

4.根据权利要求1所述的方法，其特征在于，所述判断当前处于激活状态的Activity是否符合预设的安全特征，包括：

根据预设的黑名单和/或白名单，判断所述当前处于激活状态的Activity是否符合预设的安全特征。

5.根据权利要求1所述的方法，其特征在于，所述确定系统存在Activity劫持风险，包括：

确定所述目标Activity存在被劫持风险；

和/或

确定所述当前处于激活状态的Activity为恶意Activity。

6.根据权利要求1所述的方法，其特征在于，还包括：

确定系统存在Activity劫持风险后，根据所述当前处于激活状态的Activity，确定启动该Activity的恶意程序。

7.一种Android系统Activity劫持风险检测装置，其特征在于，该装置包括：

特征获取模块，用于在目标Activity进入激活状态之前，获取当前处于激活状态的Activity的特征信息；

特征比较模块，用于根据所获取的特征信息，判断所述当前处于激活状态的Activity是否符合预设的安全特征；

风险判断模块，用于在所述特征比较模块判断结果为否的情况下，确定系统存在Activity劫持风险。

8.根据权利要求1所述的装置，其特征在于，所述特征获取模块，具体用于：

在针对目标Activity调用任一系统函数onRestart、onStart、onResume的阶段，获取当前处于激活状态的Activity的特征信息。

9.根据权利要求1所述的装置，其特征在于，所述目标Activity为：

存在被劫持风险的Activity。

10.根据权利要求1所述的装置，其特征在于，所述特征比较模块，具体用于：

根据预设的黑名单和/或白名单，判断所述当前处于激活状态的Activity是否符合预设的安全特征。