APP应用安全测试
本篇文章摘自《软件测试技术趋势白皮书》章节
随着移动互联网和通信技术的不断发展，移动应用在各行各业得到了井喷式的高速增长。移动应用也成为人们日常生活不可或缺的组成部分。移动应用快速发展的同时，其涉及系统和信息的安全问题越来越突出。根据Check Point发布的《2021年移动安全报告》显示，在过去一年新冠疫情期间，远程办公方式大规模兴起，移动攻击面也急剧扩大，97%的组织面临着来自多个攻击向量的移动威胁。根据国家互联网应急中心（CNCERT）发布《2020年中国互联网网络安全报告》显示，2020年，CNCERT/CC捕获及通过厂商交换获得的移动互联网恶意程序样本数量为3,028,414个。2016-2020年，移动互联网恶意程序样本总量持续高速增长，如下图所示。
图3-5-8 2016-2020年移动互联网恶意程序样本数量对比（来源CNCERT/CC）
企业作为APP的开发运营者，是安全事件发生的责任主体，客观存在的安全漏洞会对企业造成潜在的经济、名誉损失。企业对APP安全的重视程度需要提高，并且需要同时兼顾APP的合规性以及安全性。从国家密切出台个人信息保护相关的政策来看，防范隐私数据泄露和内容风险也是当下监管的重点。
针对移动APP的安全测试，是为了能够检测出潜在的安全漏洞和安全风险，以此来保障APP用户和企业的信息安全。在检测内容上，从数据、程序、代码三个层面出发将APP安全测试主要分为数据安全、组件安全、代码安全三部分。
数据安全
中国信息通信研究院发布的《移动应用数据安全与个人隐私保护白皮书（2019年）》显示，67%的App 存在5个及以上个人信息安全问题，18.5%的App 存在10个及以上个人信息安全问题。超过四成App的问题集中在未公开收集使用规则、未明示收集使用目的、超范围收集个人信息等5类问题上。
APP数据安全的检测，重点在对个人隐私保护上的检测。主要分为：隐私协议合规性、收集及使用个人信息合规性、权限申请及使用合规性、风险行为四部分。
01隐私协议合规性
针对隐私文本逐条审计，主要涉及到是否明示收集个人信息的业务功能，业务功能与所收集个人信息类型是否一一对应，是否显著标识个人敏感信息类型，个人信息的使用规则等情况。
02收集及使用个人信息合规性
依据《常见类型移动互联网应用程序必要个人信息范围规定》对APP收集和使用的信息进行甄别，对其敏感度、是否必要、是否声明、是否弹窗提示等情况进行检测。
03权限申请及使用合规性
依据《移动互联网应用程序（App）系统权限申请使用指南》对APP申请和使用的权限进行甄别。获取APP索取的权限列表，对权限的敏感度、是否必要、是否声明、申请方式进行检测。
04APP风险行为检测
检测未经用户授权的各类应用行为，包括功能调用、数据访问、数据采集、未知网络访问等。常见典型高风险行为如: 后台定位行为，获取系统安装应用列表,扫描WiFi热点等。
在APP应用数据安全的检测上，除了检测个人隐私保护，还需要关注敏感信息本地存储。本地存储通常包含：文件存储数据、SQLite数据库存储数据、ContentProvider存储数据、SharedPreferences存储数据。需要依次检查是否泄露敏感信息。
组件安全
组件安全包括第三方程序调用、Activity劫持、Broadcast的接收和发送安全、禁止恶意的启动或者停止service、Content provider的操作权限、WebView等。调用第三方组件，应该详细检查这些组件的安全性，并需要跟进第三方库的更新。如果是提供给第三方调用，对调用者进行授权控制。
Android四大组件漏洞
Android开发的四大组件分别是：
活动（Activity），呈现可供用户交互的界面，是最常见的组件；
服务（Service），长时间执行后台作业，常见于监控类应用；
广播接受者（Broadcast Receive），注册特定事件，并在其发生时被激活；
内容提供者（Content Provider），在多个APP间共享数据，比如通讯录。
图3-5-9 Android 开发的四大组件相互关系图
四大组件存在的问题主要是组件导出问题。因为权限声明是以组件为单位的，A组件调用B组件的功能来访问操作系统API时，适用于B组件的权限声明。如果B作为导出组件，没有进行严格的访问控制，那么A就可以通过调用B来访问原本没有声明权限的功能，构成本地权限提升。
检测上可以根据AndroidManifest.xml文件或者使用drozer工具进行测试，通过查看对其中声明的各个组件，根据以下规则判断是否可导出：
显式声明了android:exported="true"，则可导出；
显示声明了 android:exported="false"，则不可导出；
未显示声明android:exported：
若组件不是Content Provider：若组件包含
若组件是Content Provider：若SDK版本＜17则可导出，反之不可。
从测试的角度上，只能判断组件是否导出，但是否构成危害需要详细分析源代码后才能得出结论。一般来说，在测试时尽量写清所有的导出组件，由客户开发侧确认相关组件是否确实需要导出即可。由于功能需要，启动Activity和Content Provider大多是导出组件，一般无须理会。因此并不是所有导出的组件都是不安全的，如果要确定，必须看代码，对代码逻辑进行分析。
三方组件问题
在移动应用开发过程中，或多或少都会引入了各种类型的第三方组件来满足使用需要。引入三方组件使得APP的安全风险难以控制。三方组件可能会借助合法APP执行恶意的操作，比如静默安装其他APP、偷传业务数据、获取用户隐私、恶意推送信息等。为防止此类风险，需要进行必要的组件的安全合规检测。
漏洞披露核查
将应用中所使用到三方组件，包括那些间接依赖的第三方组件及其版本号集中收集起来，形成一个组件信息库。每当有第三方组件安全漏洞信息披露出来的时候，将组件、版本号在已知漏洞数据库里进行匹配查询，判断自己的应用是否受此次漏洞披露的影响；
周期性排查
除了第三方组件安全漏洞信息披露后进行识别判断，还需要主动对应用中所使用的组件进行定期检查。细致的匹配排查需要借助工具进行自动化检测，如果仅仅依靠人工匹配，工作量是非常巨大的。例如OWASP Dependency Check，它能自动完成第三方组件识别、漏洞数据库维护，以及漏洞匹配、生成检查报告等一些列活动。除了支持Java和.Net应用外，还支持Ruby、NodeJS以及Python应用，以及部分C/C++应用。
代码安全
在移动应用开发过程中，尤其是Android应用，攻击者很容易通过逆向工程进行反编译，获取应用相关敏感信息和软件处理逻辑的有价值信息并对应用进一步发起攻击，还可能修改软件逻辑，插入恶意代码等，从而给用户带来更大的安全风险。通常为了加固应用程序，需要采用混淆、反编译、反调试、签名、文件检查、资源文件保护等方式。下面介绍常见的4种加固措施的检测方法，反编译、反调试、签名、文件检查。
反编译
如果没有加入混淆或者保护机制，那么攻击者容易反编译篡改/二次打包App应用，通过反编译应用安装包，获取相关敏感信息或分析其运行逻辑，针对代码中的缺陷对APP应用进行攻击。
检测方法
解压APK文件，获取DEX；
然后利用工具（如：apktool）逆向DEX，确定是否能直接获取程序代码信息，判断是否进行了代码混淆以及显而易见的敏感信息如密码、密钥等信息；
反调试
应用程序可以通过使用特定的系统API来防止调试器附加到该进程。通过阻止调试器连接，攻击者干扰底层运行时的能力是有限的。攻击者为了从底层攻击应用程序必须首先绕过调试限制，这进一步增加了攻击复杂性。Android应用程序应该在manifest中设置Android:debuggable=“false”，这样就不会很容易地在运行时被攻击者或者恶意软件操纵。
检测方法
使用aapt list -v -a apk文件名lgrep debuggable命令，得到如下输出：android:debuggable(0x0101000f)=(type 0x12)0x0；
这表示android:debuggable="false"。
使用apktool的-d选项反编译apk文件：
java -jar apktool.jard -d target.apk -o output
检查AndroidManifest.xml中是否设置android:debuggable= "false"。
签名
APP Store会校验签名，可Android没有此类权威检查，需要在发布前校验一下签名使用的Key是否正确，以防apk被第三方应用恶意覆盖安装。在Android的源代码里包含了可以对apk文件进行签名的工具，具体在build\tools\signapk，也可以使用apktool工具进行签名。
检测方法
使用apktool工具解压当前的apk，解压后得到CERT.RSA文件；
通过keytool-printcert -file META-INF/CERT.RSA命令检查是否存在正确的签名信息。
文件检查
APP Store会校验二次打包，可Android没有此类权威检查，MANIFEST.MF文件会详细记录apk包中所有文件的哈希值，通过读取该文件获取到classes.dex文件对应的哈希值，将该值与软件发布时的classes.dex哈希值做比较，就可以判断客户端是否被篡改。
搜索公众号QECon质效前沿回复“ 白皮书 ”获取《软件测试技术趋势白皮书》全部内容~