APP安全测试汇总【网络安全】

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 就容易被反编译破解。