构筑移动应用安全评测体系

陈希，刘颖卿，叶蕴芳

（1 中国移动通信集团福建有限公司，福州 350001； 2 中国移动通信有限公司研究院，北京 100053）

随着移动互联网的快速发展，目前移动智能终端已越来越普及，据相关数据报告，2014年我国移动智能终端用户规模达10.6亿，其中基于Android操作系统的移动终端设备已占据了超过80%的市场份额。Android操作系统的广泛使用也带动了Android应用市场的繁荣发展。

然而Android应用开发者的安全意识并没有跟上应用发展的步伐，导致应用可以被破解篡改，插入恶意广告插件，应用自身存储和处理的用户数据泄露等诸多安全问题。追根究底，一方面原因是Android本身安全机制的不足，另一方面是由于应用开发者疏忽导致的。Android应用本身存在的可被利用的安全问题。因此需要通过对应用进行安全评估，发现移动应用中存在的安全风险，帮助提升应用本身的安全性。

面对Android平台上的威胁，目前发展较成熟的是恶意代码检测。当前国内外Android系统的恶意软件检测方法主要为基于特征码的检测方法和基于静态行为的检测方法。针对Android操作系统的安全监控软件主要分成两类：其中一类是基于特征码检测方法的传统手机安全监控软件，另外一类是基于静态行为检测方法监控软件。目前有人提出过基于应用程序动态行为的检测思想，然而更多的只是一种设计的思路，还没有比较完整全面的基于Android平台的应用程序安全评估系统的整体设计与实现。本文基于现有的移动应用评测技术，从程序安全、数据安全、通信安全和业务安全等方面，给出了整套的安全评测体系方法。

1 移动智能终端安全问题

1.1 终端所面临的安全威胁

近年来移动终端安全事件层出不穷, 病毒传播是目前移动终端所面临的一个最大的安全问题。除了病毒的威胁外，移动终端还面临着空中接口的安全威胁。

这些安全问题的出现，与移动终端智能化的发展趋势有着必然的联系。首先，移动终端的处理能力越来越强大，硬件技术水平的提高为病毒的传播带来便利。其次，开放的操作系统平台更容易开发出新的应用，给用户更好的体验，同时也很容易导致病毒的泛滥。再次，智能移动终端的外部接口越来越丰富，都为病毒的传播提供了多种通道。最后，4G时代的来临，使移动终端接入互联网的带宽大大增加，使用手机进行电子支付等业务都让移动终端面临感染病毒的威胁。

总体来讲，移动终端所面临的安全威胁主要来自以下几个方面：空中接口带来的安全威胁、外部接口带来的安全威胁、高速接入互联网带来的安全威胁、终端本身信息存储面临的安全威胁。各方面的安全威胁可能造成的安全问题有病毒感染、信息泄露、资费损失等。其中病毒感染既可能造成信息泄漏、资费损失，如卧底软件、自动拨打电话发送短信的病毒等。

1.2 终端安全问题的根源分析

在业务应用层面，智能终端的生态链通常包括智能终端、应用商店和应用服务器，其信息安全问题的根源也来自于以上3个环节。

一方面，智能终端存在的安全隐患远大于传统移动终端。任何智能终端操作系统都存在漏洞，使木马、蠕虫等恶意代码的存在成为可能；智能终端采用开放的操作系统及软件平台架构，可能会被不法分子用来开发恶意代码软件。此外，绝大多数操作系统提供商给自己预留了非公开API，由此带来恶意后门的隐患；智能终端很容易被终端厂商、操作系统提供商和软件开放商预置SP代码、SP服务链接或SP客户端进行恶意吸费；智能终端中存储了包括通信录、短消息、通话记录、信息卡信息等大量重要用户信息，任何安全问题都会对用户的工作和生活产生巨大的影响；一些水货手机提供商预先修改手机的ROM，置入自启动程序，改装手机操作系统，以在售出后获得用户信息或者执行恶意操作。

另一方面，由于终端制造与网络服务一体化模式的出现，智能终端与应用商店和应用服务器紧密结合，成为各种应用软件及数字内容的承载平台和传播渠道，可能被不法分子用来传播反动违法内容；智能终端上的微博、即时消息等新应用具有传播速度快、范围广的特点，可能被不法分子利用进行非法群体活动。这些都给国家安全和社会稳定带来了巨大挑战。

总体来说，智能终端的信息安全问题和计算机面临的安全问题类似。但智能终端时刻与移动网络相连，并且其操作系统并不能像计算机一样随时安装，一旦安全事件爆发，其危害性将远远大于计算机。

2 移动应用安全评测技术

2.1 应用权限安全

应用权限机制虽然为系统和应用程序提供了一定的安全保障，如在manifest文件中为应用程序设定权限、应用程序签名等，尽可能地为应用程序提供安全保障。但是，仍然不可避免地存在滥用权限机制的问题。

如共享用户ID的特性存在安全隐患，一旦应用程序声明了一个共享用户ID，在其运行时，每一个共享这个用户ID的应用程序都会被授予一组相同的权限，它们之间可以互相访问资源。这样一来，攻击者就有可能利用共享用户ID进行恶意攻击。

2.2 应用程序安装安全分析

Android应用程序以.apk文件形式在设备上进行部署。.apk文件是一个包括.dex文件的归档文件，不含有源代码。软件包管理器为安装进程提供服务，检查.apk的正确性。检查方式包括但不局限于验证数字签名、共享用户ID的合法性、权限要求及验证.dex文件。但是由于Android采用对应用程序签名的形式，有开发者自签名，没有经过权威认证机构的鉴定，所以无法对开发者身份进行验证，也无法验证.apk的完整性。

在Android系统上安装设备的方式也直接影响到应用程序的安全性。.apk文件有3种安装方式。第一种方式是通过Android的adb调试桥安装：自动授予应用程序正常级别和危险级别的权限。由于缺乏用户的交互，这种安装方式具有较高安全风险。其余的两种方式分别是从应用商店安装、从SD卡上的.apk文件进行安装，直接与软件包管理器交互。

2.3 数据库安全分析

Android采用了开源的SQLite。为了满足嵌入式系统对数据库本身的轻便型，以及对数据库存储效率、访问速度、内存占用率等性能的要求，数据库没有用户管理、访问控制和授权机制，凡是操作系统的合法用户，只要该用户对文件具有读写权限，就可以直接访问数据库文件。开源SQLite数据库不提供加密机制，因此不提供数据级的保密性。Android系统在使用过程中很有可能遭受到SQL注入攻击。对于数据库查询，如果开发者采用字符串连接方式构造SQL语句，就会产生SQL注入。

3 移动应用安全评测体系的构筑

3.1 移动应用安全评测体系

移动应用安全评测体系主要从程序安全、数据安全、通信安全、业务安全4个方面对移动应用的安全性进行评估，并采用代码静态检测、渗透测试、基于数据生命周期的安全测试等手段，发现移动应用中存在的安全风险。并针对评估结果给出相应的修补方案建议，推动移动应用安全性提升。

3.1.1 程序安全

3.1.1.1 代码篡改风险

客户端软件可以被反编译时，应当具备防篡改措施，如完整性校验等。

3.1.1.2 安装包认证数据泄露

客户端软件的安装包中不应包含认证数据，如密钥、业务校验证书等。

3.1.1.3 代码关键内容应混淆

应对客户端软件的关键部分代码进行深度混淆，即对所有可修改的类名、函数名、变量名进行混淆，使其不具备可读性。

3.1.1.4 组件权限安全性

客户端包含的receiver、service、content provider、activity组件，应进行权限限制。如果组件无须跨进程交互，应设置exported属性为false。若需要将exported属性设置为true，则需要设置android:protectionLevel为signature或signatureOrSystem。

3.1.1.5 日志信息泄漏

需要在设计阶段划分出应用关键信息。程序编码阶段，在进行日志输出、程序调试输出的环节，需严格控制应用关键信息的输出。程序在发布时，需删除所有的应用关键信息的输出代码。

3.1.1.6 程序配置参数安全性

应将AndroidManifest文件的动态调试配置参数、备份配置参数进行安全的配置，防止应用被动态调试，破解业务逻辑流程。备份参数设置不正确，使得用户可通过adb backup来进行对应用数据的备份，在无Root的情况下可以导出应用中存储的所有数据，造成用户数据的严重泄露。

3.1.1.7 硬编码问题

数据库链接字符串、用户名密码等不宜在程序中写死，而应采用配置文件来存储。

3.1.1.8 WebView组件远程代码执行漏洞

应用应避免使用WebView组件的addjavascript Interface函数，因为如果没有对注册JAVA类的方法调用进行限制，导致攻击者可以利用反射机制调用未注册的其它任何JAVA类，最终导致javascript代码对设备进行任意攻击。若使用了addjavascriptInterface函数，需要添加如下安全措施。

（1）通过在Java的远程方法上面声明一个@JavascriptInterface 来代替addjavascriptInterface。

（2）在使用js2java的bridge时候，需要对每个传入的参数进行验证，屏蔽攻击代码。如果使用HTTPS协议加载URL，应进行证书校验防止访问的页面被篡改挂马；如果使用HTTP协议加载URL，应进行白名单过滤、完整性校验等防止访问的页面被篡改；如果加载本地html，应将html文件内置在APK中，以及进行对html页面完整性的校验。

（3)移除Android系统内部的默认内置接口：remo veJavascriptInterface（"searchBoxJavaBridge_")； re moveJavascriptInterface（"accessibility")；removeJava scriptInterface（"accessibilityTraversal")。

3.1.1.9 Webview明文存储密码漏洞

使用Webview时需要关闭Webview的自动保存密码功能，防止用户密码被Webview明文存储。

3.1.1.10 Activity钓鱼劫持风险

应用程序应当具备防钓鱼劫持措施。应用程序自身通过获取栈顶activity，判断系统当前运行的程序，一旦发现应用切换（可能被劫持），给予用户提示以防范钓鱼程序的欺诈。获取栈顶activity（如图1所示），当涉及敏感activity（登录、交易等）切换时，判断当前是否仍留在原程序，若不是则通过Toast给予用户提示。

或者使用HTML5架构或Android+HTML5混合开发，实现登陆、支付等关键页面，降低被劫持的风险。

3.1.1.11 证书合规性

应用程序应使用正规的私有证书进行签名，不能使用调试证书进行签名。

3.1.2 数据安全

3.1.2.1 应用关键数据录入显示

输入用户口令等应用关键信息时，客户端软件界面应为非明文显示。

3.1.2.2 应用关键数据截获

客户端软件应具备防护措施，保护用户输入的数据应不被移动终端的其它设备或程序非授权获取。即用户输入的数据不应在明文在内存进行处理。

3.1.2.3 应用关键数据存储安全

客户端软件在进行终端本地的文件或数据库数据存储时，应保留最少的应用关键数据，并限制数据存储时间。

3.1.2.4 用户身份认证信息存储安全

图1 获取栈顶activity

客户端程序如果必要身份认证信息进行存储，则必须加密存储，不可明文存储或使用可逆向的处理方式（如Base64处理）。

3.1.2.5 应用关键信息的显示安全

客户端软件对在运行中必须要显示的应用关键信息，应当进行部分隐藏处理，如身份证号可显示为110***********1234等。

3.1.2.6 界面切换后输入的应用关键数据需清空

客户端软件不应对界面应用关键数据进行缓存。如在界面A输入应用关键信息（如注册页面输入姓名、银行卡号等）后，进入其它页面B后，再次返回界面A时，应用关键信息应当清空，不能留存。

3.1.2.7 卸载后是否清除全部应用关键数据

客户端软件应当将加密后的应用关键数据存储在应用卸载后系统会自动清空的目录下。如系统data/data/程序包名目录下。

3.1.3 通信安全

3.1.3.1 网络通信协议安全性

客户端软件若存在支付功能，进行支付相关操作时，应采用端到端的加密手段保护通信过程中数据传输的安全。和服务器间的通信应使用SSL/TLS或IPSec等安全协议，或采用WAP模式，并支持WTLS。客户端与服务器之间所有经过认证的连接都需要使用不低于SSL安全级别的加密通信方式。使用SSL协议时，其版本应3.0及更高以上版本，应取消对低版本SSL协议的支持，确保SSL证书使用正确的domain name，且证书时间没有过期。加密的数据包括身份鉴别信息，银行卡账户密码等应用关键信息。

3.1.3.2 网络通信内容应用关键数据检查

客户端软件和服务器间的通信内容，不应包含明文的应用关键数据和配置信息等。

3.1.3.3 中间人攻击漏洞

使用HTTPS时应禁止使用ALLOW_ALL_HOSTNAME_VERIFIER，因为这样会存在中间人攻击的风险。必须使用STRIC_HOSTNAME_VERIFIER，并校验证书。

3.1.4 业务安全

3.1.4.1 鉴别失败处理机制安全

客户端软件具备登录功能时，应提供连续鉴别失败处理功能。运行程序时，连接多次输入错误的用户鉴别数据，应采取锁定或需要输入验证码等防护措施。

3.1.4.2 登录超时后是否重鉴别

客户端软件具备登录功能时，软件保护内若涉及用户利益（资费、银行卡等金融信息、公司内部机密信息等待）时，应当具备会话超时处理机制，会话超时后应重鉴别。

3.1.4.3 登录错误时密码或账户提示混淆

客户端软件具备登录功能时，在登录失败时，应当混淆提示密码和账户，如“用户名或密码错误”，而不是分别进行不同的提示。

3.1.4.4 支付过程是否输入支付密码

客户端软件存在支付功能时，应当设置在使用支付功能时，需要输入不同于登录密码的支付密码。

3.1.4.5 认证方式的安全性

客户端软件在大额支付、重要信息修改等关键业务操作时，应采用除密码以外的安全认证机制。如短信验证码、动态口令卡、移动口令牌、移动数字证书等认证机制。

3.1.4.6 认证信息输入验证风险

应用应对所有的输入信息的长度和类型进行验证，防止输入不合规信息。

3.1.4.7 SQL注入

应对应用程序的输入信息进行过滤，防止被SQL注入，如使用正则表达式验证输入的格式。

3.2 移动应用安全评测平台的框架

移动应用安全评测平台软件架构按照逻辑分层、功能模块化思想进行设计，整个系统逻辑上分为展示层、服务层、数据层。使用具有高度的内聚性和透明性的分布式数据存储，服务与功能采用组件模型，以达到高可扩展/可伸缩的目的，模块之间数据交换采用协同化的工作流构建实现，从而保证了系统结构的合理划分和在系统扩展情况下的稳定性。系统架构图如图2所示。

系统采用分层构架设计思想，从下至上分别如下。

（1）展示层：向系统管理员、评估专家提供系统可操作功能、系统评估报告、监测结果、风险分析等功能；同时向管理员提供基础数据、应用等录入、维护的操作界面。

（2）服务层：平台提供系统运行基础服务与业务支撑相关服务，是整个系统的核心业务功能体现。

（3）数据层：提供平台运行的各种数据，基于分布式架构设计，完成系统各类业务数据的统一存储管理，包括安全特征信息、应用程序分组、业务数据等3类数据，为系统业务层、展示层提供数据存取访问服务。针对不同业务数据的访问要求进行数据存储层的设计，采用基于SQL查询的关系型数据库、方便文件存储访问的文件服务器等不同的数据存储技术和产品。

系统的功能图如图3所示。

平台整体功能架构根据功能分类的不同，结合对总技术规范的要求和理解，对平台的整体功能进行了功能域的划分，分为展示层、服务层和数据层。

（1）展示域：实现系统用户的交互操作门户，为系统管理人员、安全管理员、评估专家等不同角色提供统一的系统访问门户。

（2）服务层：服务层是系统所有业务流程逻辑的集中体现，涵盖系统提供的所有管理功能，包括基础数据管理、安全评估、安全监测管理、统计分析、爬虫任务调度、病毒查杀引擎、静态扫描引擎、代码审计引擎、代码分析引擎、动态监控引擎等业务模块以及系统对外提供的服务接口等。

（3）数据层：提供支持系统正常运行的各类数据库，是连接展示层和服务层的关键节点，包括评估标准库、专家库、应用库、系统管理库、开发者等。

3.3 移动应用安全评测体系的应用效果

根据研究成果和项目实现，从2013年起开始对某电信运营商的应用进行安全评测和风险修复。共计对近70款APP进行评测，发现近400个安全风险并进行修复和修复结果复核。通过移动应用的安全评测，可以提高APP的整体安全性，提高用户对企业品牌信誉的信赖。

图2 系统架构图

图3 系统功能图

4 下一步研究方向

随着在电信运营商内部应用评测服务的推广，APP评测的工作量在逐步增长，同时随着对APP安全关注度的提升，目前对APP评估的研究开始增加，市场上出现更多的评测技术。需要跟进新技术的发展，提升评估体系的全面性。

研究安全评估自动化方面的技术，人工工作的自动化一直是难点，现有系统只能支撑少部分评估项的自动化，其余项仍需大量人工参与，因此需要研究相关的自动化评估技术方案,缓解人工压力。