App应用常见安全漏洞

1、APP 应用常见安全风险

1.1 客户端 dex 可被反编译(中)

描述：代码无保护，可以被轻松反编译
后果：逆向工程分析程序运行原理、漏洞挖掘
原理：源文件未做加密处理，利用工具进行逆向可获取完整清晰源码
使用 jeb 工具对客户端apk进行反编译，代码没有做保护，可以得到清晰的代码逻辑，反编译结果如下图所示：

修复建议：建议对代码进行混淆，同时使用加固进行处理，增加阅读代码的难度

1.2 客户端 so 库可被反编译(中)

描述：客户端 so 库可被反编译
后果：逆向工程分析程序运行原理、漏洞挖掘
原理：客户端引用的 so 库未做加密处理，可反编译或者解压缩获取文件，利用工具查看实现的完整清晰 C 代码
使用压缩工具解压 apk，使用 IDA 反编译 SO 文件，反编译结果如下图所示：

修复建议：建议对 so 文件加固

1.3 客户端程序可被篡改及二次打包(中)

描述：客户端程序可被篡改及二次打包
后果：逆向工程、代码植入、插入广告 SDK 等
原理：逆向分析源代码，在 apk 中插入广告，并将 apk 重新打包、签名，然后安装在终端中
APK 篡改及二次打包常用工具：

• apktool ：反编译+打包工具
• dex2jar ：将apk反编译成java源码（classes.dex转化成jar文件）
• jd-gui：查看APK中classes.dex转化成出的jar文件，即源码文件

在 apk 中插入广告，并将 apk 重新打包、签名，然后安装在终端中，下图是插入广告后的运行截图：

1.4 动态调试攻击风险(中)

:::info 调试：程序调试是将编制的程序投入实际运行前，用手工或编译程序等方法进行测试，修正语法错误和逻辑错误的过程
动态调试：通常利用程序语言提供的调试功能或专门的调试工具来分析程序的动态行为。调试功能有检查主存和寄存器。设置断点，即当执行到特定语句或改变特定变量的值时，程序停止执行，以便分析程序此时的状态 ::: 描述：App 对调试没有保护
后果：App 可以被攻击者动态调试，分析程序脆弱点，开发利用工具
下图为使用 gbd 对程序进行动态调试截图：

修复建议：使用加固进行处理，防止应用被动态调试

1.5 动态注入攻击(中)

动态注入的本质上是调试技术，通过注入，可以实现以下功能：

• 查看变量值
• 修改变量值
• 跟踪进程跳转
• 查看进程调用堆栈

动态注入与调试的区别：

• 动态注入式自动化调试并达到加载自定义动态链接库的过程
• 所谓自动化其实就是通过代码实现

描述：App 对动态注入没有保护
后果：App 可以被攻击者动态注入恶意代码，窃取用户数据
下图为对app进行动态注入截图：
修复建议：使用更安全加固进行处理，防止应用被动态注入

1.6 应用可被注入加载其他 so 文件(中)

大致的实现思路是：

1. 让目标进程调用其 mmap 函数在其进程内存中申请一段内存空间
2. 将要注入的 so 库的名称字符串和 so 库中要调用的函数名称字符串写入到目标进程的内存中
3. 将编写好的 ShellCode 汇编代码写入到到目标进程的内存中
4. 修改目标进程的 PC 寄存器的值，让其跳到注入的 ShellCode 代码中执行，实现 so 库的注入，然后调用注入的 so 库中的函数

安装 app，使用数据线连接设备，用 so 注入工具注入 so 库，发现应用可被注入加载其他 SO 文件，注入结果，如下图所示：
修复建议：完整性校验，采用相关产品进行加固处理

2、APP 应用常见安全漏洞

2.1 任意备份漏洞(高)

漏洞描述：应用未将 AndroidMannifest.xml 文件 android:allowBackup 属性配置为 false，可被任意备份
漏洞后果：攻击者可以通过备份登录后的应用数据，在其他安装了相同应用的手机上恢复数据
漏洞原理：AndroidMannifest.xml 文件 android:allowBackup 属性未显式声明为 false，其默认值为 true，默认值为 true 将导致通过备份登录后的应用数据，在其他安装了相同应用的手机上恢复数据。如下图所示：

修复建议：在 application 中将 android:backup 属性的值设置为 false

2.1 Activity 未作防止截屏测处理(高)

漏洞描述：由于没有对敏感的 Activity 采取防止截屏的措施，导致在输入敏感信息的时候，第三方程序或者 adb 可以对当前 Activity 进行截屏，从而获取输入或者展示的敏感信息
漏洞后果：在不安全的手机环境下，输入的内容以及 App 展示的敏感信息能够被第三方程序获取
修复建议：对敏感的Activity进行防止截屏处理

2.3 应用界面可被劫持(中)

漏洞描述：客户端程序界面可被恶意劫持
漏洞后果：恶意程序可在后台监听并劫持客户端界面，弹出恶意程序仿冒界面骗取用户输入，盗取用户敏感信息
漏洞原理：未对顶层的 activity 进行判断，判断是否为自身的 activity
修复建议：建议在应用被打开时，监听顶层窗体，当顶层窗体不是自己的activity时，提示用户客户端再后台运行

2.4 导出组件处理参数不当导致应用崩溃(低)

漏洞描述：App 的导出组件在处理外部传递的参数时，没有对参数的合法性以及有效性进行判断，导致App处理畸形参数的时候崩溃
漏洞后果：该漏洞可用于第三方程序对其进行拒绝服务攻击，影响正常使用
漏洞原理：利用 Intent 进行参数传输，却没对参数进行合法性判断就直接使用，会触发空指针异常，导致应用崩溃

Android App 在和其他 App 进行跨进程通信、调用的时候，通常会使用 Intent 进行参数传递。在传递的内容中包含对象的时候，如果模板 App 在通过 Intent 获取参数后没有对获取到的结果进行合法性判断就直接使用，会触发空指针异常，导致 Android App 崩溃：

修复建议：在处理外部传递的参数时，对参数的合法性以及有效性进行判断。同时，Service、Receiver 等组件也会存在类似的问题。所以，在接受外部参数的时候，必须对 Intent 中的参数小心判断

2.5 未使用 https 加密流量(高)

漏洞描述：与服务器交互的请求未使用 HTTPS 对流量进行保护
漏洞后果：在不安全的网络环境下，导致流量可以被劫持、篡改、监听
漏洞原理：利用 http 协议传输数据，没有严格的校验，数据信息可以被中间人攻击轻易获取
在登陆过程中抓取到的获取用户信息的请求未使用 HTTPS 加密：

修复建议：关键流量使用 HTTPS 进行保护，并严格校验证书

2.6 https 校验不严格(高)

漏洞描述：App 使用了 HTTPS 对网络请求进行加密，但没有对 HTTPS 证书的根证书进行校验，或者忽略 HTTPS 域名检查
漏洞后果：导致在不可信的网络环境下，网络请求可以被第三方程序监听、截获、篡改、重放等
漏洞原理：使用了 https 对网络请求进行加密，但没有对 https 证书的根证书进行校验，或者忽略 https 域名检查
客户端程序覆盖谷歌默认的证书检查机制，之后没有对证书进行应有的安全性检查：

修复建议：在使用 https 加密数据传输时，对根证书进行校验，对证书来源主机名进行校验

2.7 调试日志泄露敏感信息(中)

漏洞描述：日志输出包含敏感信息
漏洞后果：攻击者可以窃取用户敏感信息，可能发生重要日志信息泄露的风险
漏洞原理：研发测试开启 log 调试，以便进行代码整改，但是 APP 上线时未完全关闭调试日志功能
修复建议：关闭调试日志函数调用，或者确保日志的输出使用了正确的级别，涉及敏感数据的日志信息在发布版本中被关闭

2.8 明文传输用户名、密码和验证码等敏感信息(高)

漏洞描述：App 在登陆的请求中，没有对用户输入的密码进行加密处理
漏洞后果：导致在不可信的网络环境下，网络请求可以被第三方程序监听，并截获账号和密码
漏洞原理：信息在传输的途中未进行加密，直接采用明文进行传输
由于 App 没有使用 HTTPS 对请求数据进行加密，在不安全的网络环境下(如公共 WIFI、机场、酒店等)，请求的流量会被监听，加上没有对登陆密码进行加密处理，可以直接获取到用户的账号和密码
修复建议：使用 HTTPS 对网络请求进行加密处理，同时对密码进行二次加密

2.9 本地明文存储敏感信息(中)

漏洞描述：App 在存储敏感信息的时候，没有对敏感信息进行加密处理
漏洞后果：导致第三方程序可以读取该敏感信息，或通过 adb 备份还原
漏洞原理：对存储在本地的信息未进行加密，直接明文存储。使用 adb 工具查看客户端的 EBANK.xml 文件中不仅保存了明文的 token，甚至还保存了明文的登陆账号及密码
修复建议：App 在存储敏感信息时，对敏感信息进行加密处理

2.10 暴力破解登录账号(高)

漏洞描述：使用用户名密码进行登陆的功能，没有做失败次数控制
漏洞后果：攻击者可以对指定账号的密码进行暴力破解，使用社工库进行撞库等方式，获取有效的账号信息
漏洞原理：没有对失败次数，校验时间等因素进行严格控制，导致攻击者可以利用枚举法进行账号破解
使用 fiddler 重放多次登陆请求，并没有被服务器阻止：

短期修复建议：几次登陆失败后，加入图形验证码校验以阻止脚本遍历；同时对其他数据进行采集，在同一账号、单一设备、IP 等尝试登陆失败多次后，进行 IP 封锁、设备锁定等，以防止攻击者利用打码平台进行验证码绕过。
长期修复建议：提升密码复杂度策略，定期建议用户修改密码；收集泄漏社工库，筛选出异常的账号，防止撞库

2.11 客户端注销登录时未注销 cookie(中)

漏洞描述：在客户端点击注销按钮时，仅从客户端本地清除了 Token，并没有请求服务端注销该 Token
漏洞后果：违背用户意愿，Token 在用户注销后依然可用
漏洞原理：服务器未注销登录的 cookie，表明服务器承认此 cookies 仍然有效，一旦这个有效的 cookies 被攻击获取，就可以进行利用了
通过反编译，可以看到注销的代码并没有发送网络请求，仅清除了本地的 Token 信息：

修复建议：添加注销 Token 的接口，在用户从客户端注销的时候，同时也从服务端让该 Token 失效

2.12 任意用户登录(高)

漏洞描述：App 登录时将短信验证码返回到客户端进行校验，通过解密可还原6位短信验证码，从而登陆任意移动手机号
漏洞后果：攻击者使用受害者的手机号登陆账户
漏洞原理：APP 逻辑采用手机+验证码进行用户注册，可是在进行校验的时候，服务器将手机验证码返回到本地，这里攻击者获取服务器返回的信息就可以进行任意用户注册登录
通过解密返回的数据包，可以看到验证码就是815034

修复建议：发送及验证短信验证码的流程中，在请求发送短信验证码的时候，不要抢验证码返回到客户端进行验证

2.13 越权访问(高)

漏洞描述：客户端程序在用户登陆后可越权查看其他用户的信息
漏洞后果：泄露他人敏感信息
漏洞原理：服务器没有对用户的信息进行严格的校验，相信用户提交的所有信息，导致用户可以横向查询相同权限等级用户的一些信息
修复建议：建议服务器在用户登录后生成唯一标识码，通过唯一标识码进行后续的信息查询

2.14 短信轰炸(中)

漏洞描述：发送短信接口对同一号码短时间多次发送未做限制
漏洞后果：恶意消耗后端短信资源，可对手机号定向、恶意不断地发送短信
漏洞原理：服务器发送短信验证未做限制，这样攻击者不断重复提交请求就可以实现让服务器不断向请求手机发送验证短信
App 在登录时服务端会向手机发送登录验证码，数据包如下，通过工具对数据包进行重放，例如短时间重放100次可发送100条短信：

修复建议：服务端限制同一手机号在短时间内多次发送短信验证码

2.15 接口存在 sql 注入(高)

漏洞描述：数据库注入
漏洞后果：数据库信息泄露
漏洞原理：通过把 SQL 命令插入到 Web 表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的 SQL 命令
修复建议：过滤参数

2.16 自动更新可被劫持(中)

漏洞描述：App 没有对升级配置中的下载地址进行合法校验，由于升级请求使用的 HTTP 协议，存在极高的被篡改的风险
漏洞后果：通过篡改升级请求，可以使得App下载其他病毒、木马，或者二次打包后的应用，并安装到用户的手机上
漏洞原理：采用 http 协议进行数据传输，数据被攻击者截取篡改下载地址回复给使用者，导致使用者下载恶意的 APP 应用
由于 App 没有使用HTTPS协议，并且没有校验该配置文件中的地址，因此可以通过劫持该链接，并篡改里面的下载地址，达到让App下载、安装任意 Apk 的目的：

修复建议：使用 HTTPS 查询升级链接，并严格校验配置文件的正确性，以及下载地址的是否为官方网站