APP安全测试汇总

一.安装包签名和证书

1.问题说明

检测 APP 移动客户端是否经过了正确签名，通过检测签名，可以检测出安装包在签名后是否被修改过。如 果 APP 使⽤了 debug 进⾏证书签名，那么 APP 中⼀部分 signature 级别的权限控制就会失效，导致攻击 者可以编写安装恶意 APP 直接替换掉原来的客户端。

2.测试

使用jadx工具，可以直接反编译apk包(将apk工具拖入jadx即可)，查看APK signature文件。

主题中显示是Debug签名，则说明该签名不安全。

3.结论

不安全

二.应用完整性校验

1.问题说明

APK 应⽤完整性即移动客户端程序安装后，在每次启动时都会对⾃身⽂件进⾏完整性进⾏校验。防⽌攻击 者通过反编译的⽅法在客户端程序中植⼊⾃⼰的⽊⻢，客户端程序如果没有⾃校验机制的话，攻击者可能 会通过篡改客户端程序窃取⼿机⽤户的隐私信息。

2.测试

使用Android Killer工具可以对apk的完整性进行校验，以更改apk的图标为例，使用Android Killer工具反编译apk之后，打开AndroidMainfest.xml文件，找到android:icon，该项所对应的值就是图标存储的位置。

所有apk的图标都在res目录下，

andriod:icon所对应的值为@mipmap，则res目录下以mipmap开头的目录存放的都是apk图标，该apk下有五个相关目录，故需要将该五个目录的图标都需要更改为要变更的apk图标，名字需要与原来一致。

将原来apk的图标保存，然后涂鸦，

然后将5个目录下的图标都更改为该涂鸦图标，此时已经将五个图标全部替换。(替换方法：右击图片选择打开方式，然后点击打开文件路径，然后直接使用涂鸦图片替换原图片即可，名字需要与原图片一致)

替换完成之后，重新编译apk。

编译完成之后会输出编译路径。

使用手机或者模拟器进行安装该apk，如果可以安装并且图标被更改的话，则说明应用完整性不安全。

可以看到该apk图标已经被更改。

3.结论

不安全

三.组件导出安全

1.Activity组件

1.1问题说明

Android 中的每个程序都是由基本组件如 Activity、Service、content Provider 和 Broadcast Receiver 等所组成，⽽作为实现应⽤程序的主体的 Activity 承担着⼤量的显示和交互⼯作，甚⾄我们可以理解为⼀ 个「界⾯」就是⼀个 Activity。既然 Activity 这么重要，如果 Activity 组件存在问题那么就可能会被系统 或者第三⽅的应⽤程序直接调出并使⽤。⽽组件导出可能导致登录界⾯被绕过、信息泄露、数据库 SQL 注 ⼊、DOS、恶意调⽤等⻛险。

1.2测试

测试组件导出安全使用drozer工具进行测试。

虚拟器安装agent.apk，主机连接drozer命令

adb forward tcp:31415 tcp:31415

drozer.bat console connect

出现下图所示标志代表主机已经连接到drozer客户端。

使用jadx查看apk的包名。

得到包名为jakhar.aseem.diva。
run app.activity.info -a jakhar.aseem.diva(包名) ：查看该apk所有可以导出的组件

run app.activity.start --component jakhar.aseem.diva jakhar.aseem.diva.APICreds2Activity
导出jakhar.aseem.diva.APICreds2Activity组件，可以看到该apk已经自动打开该界面。

run app.activity.info -a jakhar.aseem.diva(包名) 导出组件
run app.activity.start --component jakhar.aseem.diva jakhar.aseem.diva.APICreds2Activity 导出组件中对应的界面

如果Activity中只有第一个主界面可以导出，说明该组件是安全的，因为主界面导不出的话，apk就打不开，主界面就是apk打开时显示的界面。

2.3结论

不安全

2.Service组件

2.1问题说明

Service 是没有界⾯且能⻓时间运⾏于后台的应⽤组件，应⽤的组件可以启动⼀个服务运⾏于后台⽆论⽤ 户是否切换到其他应⽤。⼀个组件还可以绑定到⼀个 Service 来进⾏交互，即使进程间通讯间的交互也是 可以的。例如，⼀个 Service 可能是执⾏⽂件 I/O，处理⽹络事物，或与⼀个内容提供者交互等等，所有 这些服务都在后台进⾏。如果 Service 出现问题，则可能会被系统或者第三⽅的应⽤程序直接调出并使 ⽤。组件导出可能导致登录界⾯被绕过、信息泄露、数据库 SQL 注⼊、DOS、恶意调⽤等⻛险。

2.2测试

run app.service.info -a com.package 导出所有组件，

可以看到该apk没有service组件可以导出。

如果有service组件可以到处，则使用下面命令导出组件对应的界面

run app.service.start --component com.package xxx.xxx.xxx

run app.service.info -a com.package

run app.service.start --component com.package xxx.xxx.xxx

2.3结论

安全

3.Content Provider组件

3.1问题说明

Android 中 Content Provider 可能存在⽂件⽬录遍历安全漏洞，该漏洞源于对外暴露 Content Provider 组件的应⽤没有对 Content Provider 组件的访问进⾏权限控制和对访问的⽬标⽂件的 Content Query Uri 进⾏有效判断，攻击者利⽤该应⽤暴露的 Content Provider 的 openFile() 接⼝进⾏⽂件⽬录遍历以达到访问任意可读⽂件的⽬的。在使⽤ Content Provider 时，将组件导出提供了 query 接⼝，由于 query 接⼝传⼊的参数直接或间接由接⼝调⽤者传⼊，攻击者构造 SQL Injection 语句，造成信息的泄漏甚⾄是应⽤私有数据的恶意改写和删除。攻击者利⽤⽂件⽬录遍历访问任意可读⽂件、查看本地数据库内容等。

3.2测试

run scanner.provider.finduris -a jakhar.aseem.diva

run scanner.provider.injection -a jakhar.aseem.diva 检测是否存在sql注入

run scanner.provider.traversal -a jakhar.aseem.diva 检测是否存在目录遍历

run scanner.provider.finduris -a app包名

run scanner.provider.injection -a APP包名 检测是否存在sql注入

run scanner.provider.traversal -a APP包名 检测是否存在目录遍历

3.3结论

不安全

4.Broadcast Reeciever组件

4.1问题说明

⼴播接收器 (Broadcast Recevier) 是⼀个专注于接收⼴播通知信息，并做出对应处理的组件。很多⼴播都 是源⾃于系统代码，例如：电池电量低、通知时区改变、拍摄了⼀张照⽚或者⽤户改变了语⾔选项等等。 当然应⽤程序也可以进⾏⼴播，例如，应⽤程序通知其它应⽤程序下载完成⼀些数据并处于可⽤状态。应 ⽤程序可以拥有任意数量的⼴播接收器以对所有它感兴趣的通知信息予以响应，所有的接收器均继承⾃ BroadcastReceiver 基类。⼴播接收器是没有⽤户界⾯的，但是它们可以启动⼀个 activity 来响应它们收 到的信息，或者⽤ NotificationManager 来通知⽤户。如果 Broadcast Recevier 存在问题则可能被系统 或者第三⽅的应⽤程序直接调出并使⽤。组件导出可能导致登录界⾯被绕过、信息泄露、数据库 SQL 注 ⼊、DOS、恶意调⽤等⻛险。

4.2测试

run app.broadcast.info -a jakhar.aseem.diva

run app.broadcast.info -a com.packagename

run app.broadcast.send --component com.packagename --action xxx.xxx.xxx 存在拒绝服务⻛险

run app.broadcast.send --action xxx.xxx.push.PenddingIntent 数字签名校验

4.3结论

安全

四.应用程序数据可备份

1.问题说明

在 Android 2.1 以上的系统中可以为 App 提供应⽤程序数据的备份和恢复功能，这些功能由 AndroidMainfest.xml ⽂件中的 allowBackup 属性值进⾏控制，其默认的值为 true。当 allowBackup 的 值设置为 true 时，就可通过 adb backup 和 adb restore 来进⾏备份和恢复应⽤程序数据，这样是可能获取到明⽂存储的⽤户敏感信息。

2.测试

使用jadx查看allowBackup对应的值。值为true，故可备份。

adb backup -nosystem -noshared -apk -f com.xingming.test.ab jakhar.aseem.diva.MainActivity 备份为com.xingming.test.ab

输入锁屏密码，即可备份该apk数据，并且备份的包命名为com.xingming.test.ab

最后即可在该目录下生成备份文件。

adb backup -nosystem -noshared -apk -f com.xingming.test.ab jakhar.aseem.diva.MainActivity 备份为com.xingming.test.ab

java -jar abe.jar unpack com.xingming.test.ab xm.tar 解密备份文件

adb devices //显示已连接的设备列表，测试手机是否正常连接

adb backup -nosystem -noshared -apk -f com.sina.weibo.ab com.sina.weibo

//-nosystem表示不备份系统应用 -noshared表示不备份应用存储在SD中的数据 -apk表示备份应用APK安装包 -f 表示备份的.ab文件路径和文件名 最后是要备份应用的packageName

adb kill-server //关闭ADB

adb devices //重新启动ADB，检测手机2是否成功连接

adb restore com.sina.weibo.ab 将备份数据恢复到另一个手机

3.结论

不安全

五.Debug 模式

1.问题说明

APP 软件 AndroidManifest.xml 中的属性值 android:debuggable 如果为 true，那么 APP 可以被 Java 调试⼯具例如 JDB 等进⾏调试。当 APP 被调试⼯具进⾏调试后可以获取和篡改⽤户敏感信息，甚⾄可以 分析然后修改代码以实现恶意的业务逻辑，我们经常使⽤ android.util.Log 来打印⽇志，⽽ APP 发布后调 试⽇志能被其他开发者看到，APP 就容易被反编译破解。

2.测试

检查 AndroidManifest.xml ⽂件中的 debuggable 属性 (MobSF)，检查其是否能被调试。如果没有设置 debuggable 属性，该属性默认为 false。该apk被设置为true，故可调式，不安全。

3.结论

不安全

六.不安全的数据存储

1.问题说明

检查移动客户端 APP 私有⽬录下的⽂件及 APP ⾃身代码中是否存在敏感信息泄露的情况，如果有该类情况，则可能泄露 APP ⾃身中的服务端接⼝信息以及⽤户信息（如密码、私钥）等。

2.测试

查看路径/data/data/包名/下是否有敏感文件存放。

可以看到databases下存放着数据库文件。

3.结论

不安全

七.日志

1.问题说明

如果 APP 中有调试⽇志函数，那么可能输出重要的⽇志⽂件，其中包含的信息可能导致客户端⽤户信息泄 露，暴露客户端代码逻辑等。

2.测试

先查看apk运行的pid，最后进行日志筛选，不然的话日志太多不好查看。

ps | grep jakhar.aseem.diva 查看到该apk的运行pid为3953。


adb logcat | findstr 3953 筛选出该apk的日志文件，在该日志文件中查看到登陆的账户与密码值。

3.结论

不安全

八.移动客户端程序保护

1.问题说明

如果移动客户端的代码没有被相应加固保护，则很容易被攻击者破解进⾏反编译，通过反编译攻击者可以 获取到移动客户端的源代码。

2.测试

使用查壳工具查看该apk是否被加壳。

未查到壳，然后使用jadx查看该apk是否可以被反编译，是否可以看到明文代码。可以看到代码没有被既没混淆，也没加壳。

3.结论

不安全

九.键盘劫持测试

1.问题说明

检查移动客户端 APP 在输⼊密码等敏感信息时是否使⽤了⾃定义软键盘。Android 应⽤中的输⼊框默认使 ⽤系统软键盘，如果⽬标⼿机被安装了⽊⻢，⽊⻢可以通过替换系统软键盘，记录应⽤的敏感信息输⼊。

2.测试

⾸先我们需要进⼊ adb 使⽤ logcat 调出⽇志。

然后安装键盘记录工具ns_keylogger.apk，该 APK ⽂件安装后桌⾯不会有显示，需要我们到「设置」->「语⾔和输⼊法」-> 选择「NSFOCUS test Keyboard」

adb logcat -s Keylogger 指定查看键盘输入的日志，打开测试的apk随机输入字符，可以看到日志中已经输出了用户输入的字符串。

3.结论

不安全

十.屏幕录像保护

1.问题说明

攻击者可能在用户输入密码的时候去截屏，如果输入密码没有做截屏保护，就可能被攻击者截图到输入的密码。

2.测试

adb shell /system/bin/screencap -p 输入png路径(安卓设备中) /data/local/tmp 普通用户可写

将该图片导入到电脑，然后查看。

adb pull /data/local/tmp/1.png .\ 将虚拟机的图片导入到电脑的当前目录。

查看该图片。可以看到泄露了输入的账户。

3.结论

不安全