Android应用安全问题与对策思考研究

2022-08-29付亚男

现代信息科技 2022年12期

付亚男

（广东邮电职业技术学院，广东广州 510630）

0 引言

近几年全球信息化的发展，移动互联网的生态系统日益庞大，市场上丰富的移动应用也越来越多，手机APP 为我们提供便捷服务的同时，Android 端主要的安全问题如信息泄露、扣费短信、恶意广告、挖矿木马、勒索软件等也一直困扰着我们，若对应用中潜在的安全隐患不能够及时发现和处理，一旦出现问题，无论是对公司或用户，都将造成不可估量的伤害。因此，做好应用技术开发的安全策略、让应用更安全更可靠的运行，是每个开发者义不容辞的责任。

1 Android 应用安全问题及对策

本文从安全开发角度梳理了一个Android APP 需要关注的安全问题，主要从程序安全和数据安全两个方面进行分析，如图1所示。

图1 APP 安全组成

1.1 程序安全

在开发APP 过程中，许多开发者只关注如何实现功能，对Android 的安全机制理解不够，导致发布在应用市场上的很多APP 存在安全漏洞。程序安全主要包括程序漏洞、代码混淆、应用签名、APK 加固这四个方面的安全，下面将对这四方面进行详细分析。

1.1.1 程序漏洞

程序漏洞主要体现在以下几个方面：

（1）AllowBackup 漏洞。Android 2.1 以上的系统可以为APP 提供应用程序数据的备份和恢复功能，当Android Manifest.xml 文件中的allowBackup 被设置为true 时，攻击者可通过adb backup、adb restore 来对应用数据进行备份和恢复，从而获取到用户的敏感信息，如证件号、手机号、身份令牌等，造成用户隐私数据的泄漏和资产损失，在正式发布应用之前，显式设置为false，不能对应用数据备份。

（2）Java 动态调试风险。应用级配置文件build.gradle中的调试标记默认是true，即可以通过JDB 等调试工具进行调试，攻击者可以访问和篡改用户敏感信息，甚至分析并修改相关业务逻辑的代码，从而实现窃取用户密码，绕过验证码保护等违规操作，因此，应该在APP 正式发布之前，设置android：debuggable 属性为false，关闭Java 动态调试功能，不允许被调试。

（3）程序包日志控制。一些开发者习惯在开发过程中打印调试日志，用于排查问题，却没能在调试完毕后及时删除日志。调试函数日志中可能输出重要的调试信息，诸如组件名、通信数据、跟踪变量等，这些信息的打印会导致用户信息、重要代码事件流的泄漏，从而为攻击者提供便利。对应用内Log 统一封装控制基类，并判断测试环境允许打印日志，正式环境关闭日志的输出，或修改编译器配置，对敏感代码进行Inspections 提醒，告知开发者应做到及时删除。

（4）WebView 漏洞攻防。WebView 漏洞包括四种情况，下面将做详细介绍。

第一种JS 注入漏洞。恶意APP 可以注入JavaScript 代码进入WebView 中的网页，网页未作验证。恶意网页可以执行JavaScript 反过来调用APP 中注册过的方法，或者使用资源。这些恶意程序嵌入Web APP，然后窃取用户信息，远程调用APP 代码。更有甚者，通过Java Reflection 调用Runtime 执行任意代码。解决办法主要：对于Android 4.2 及其以上版本，google 已经fix 该漏洞，只需要native interface上增加@addJavaInterface 标示即可；对于Android 4.2 以前的版本，则需要覆写addJavaInterface（）方法。

第二种WebView 钓鱼漏洞。钓鱼是最难使用技术手段解决的最常见攻击，防钓鱼技术层面可以做两件事：一是检查WebView 加载的目标链接是否存在安全风险；二是对WebView 关闭脚本环境。

第三种WebView 跨域漏洞。主要是因为JS 的XmlHttpRequest 可以读取系统存放cookie 的本地文件webviewCookiesChromium.db，等同于提供了对cookie 的读访问权限。针对Android 4.1 以及以上系统，本身不存在这个跨域漏洞，没有针对性修改，其他版本系统可通过设置禁止从本地html 加载页面来防止这个漏洞的出现。

第四种WebView 数据漏洞。安卓WebView 组件默认会引导用户把明文形式的密码保存到应用数据目录的databases/webview.db 中，从而攻击者可通过root 的方式访问该文件，从而窃取用户的用户名和密码。为了预防这个漏洞，可以通过设置savePassword（）为false 来显式关闭密码存储功能：WebView.getSettings（）.setSavePassword（false）。

（5）应用组件暴露。Android 系统共有四大组件：活动组件、服务组件、广播组件、内容组件。如果组件暴露，攻击者可以通过外部传入Intent 来越权访问，从而引起数据泄露、DOS 攻击和应用连续崩溃等问题。所以在APP 应用中如果非必要，组件不要进行导出，在AndroidManifest.xml文件中，设置组件的exported 属性为false；如果组件一定要提供给外部进行调用的话，可以对组件的权限进行控制。

（6）第三方sdk 组件。目前，大部分Android 应用都集成了很多的第三方SDK，有些第三方SDK 可能来自开源社区，安全性并没有被验证，如果存在安全问题，会产生用户的隐私和财产安全被损耗等严重的后果。目前发生的第三方SDK 安全事件主要原因在以下两方面：

1）第三方SDK 的开发者只关注实现功能，在安全方面的投入少，并且相关安全技术不高；

2）部分恶意开发者渗入了SDK 开发环节并通过吸引合法APP 的开发者来集成他们的SDK，从而躲避应用市场和安全厂商的检测。因此，为保障第三方sdk 安全，可以采取下面措施：一是培养开发人员的安全意识。在开发过程的各个环节建立安全评估检查点；开发环节严格遵守开发规范，防止类似调试后门等安全威胁的产生；应用发布前交给独立的内部或外部测评组织进行安全性评估。二是防止APP被恶意篡改。规范APP 发布流程；防止应用签名证书泄露；选择正规渠道发布APP；应用升级更新时为防止运行被劫持的安装包，一定要先校验下载安装包。

1.1.2 代码混淆

APP 中的一些关键资源文件没有进行加密保护，攻击者可以从APP 中提取关键的资源文件，进行二次使用或从资源文件中获取本地业务逻辑代码，从而对APP 发起攻击。例如对APP 进行关键逻辑篡改、植入恶意代码、网络协议分析等等。开启代码混淆minifyEnabled=true，有利于增加攻击者反编译获取代码的成本，且打包时移除无用资源，减少APK 体积；引入资源混淆如AndResGuard，将原本冗余的资源路径变短，如“res/drawable/newerIcon”将变为“r/d/i”，可以再次优化减APK 体积，且混淆资源路径后，使用APKTool 工具无法直接回编生成二次APK，也在一定程度上提升了APK 反破解难度。

1.1.3 应用签名

应用签名在保障设备安全方面发挥着重要作用，可用于进行权限检查以及软件更新。签名一是保证消息来源的真实性，二是确保消息不会被第三方篡改，早期的V1 签名会将APK 内文件进行逐一签名并将签名结果保存在ETA-INF 目录下，V1 签名的缺点一是签名校验速度较慢，在APK 安装校验过程中需要对所有文件进行摘要计算，在APK 资源较多、性能较差的机器上签名校验将花费较长时间，导致安装速度慢，影响用户体验，且META-INF 目录用来存放签名，自然此目录本身是不计入签名校验过程的，可以随意在这个目录中添加文件。升级到V2 版本签名，V2 签名将验证归档中的所有字节，而不是单个ZIP 条目，因此在签署后无法再运行重压ZIP 包等，能够及时发现对APK 的受保护部分进行的所有更改，从而有助于加快验证速度并增强完整性保证。后续Android 9.0 引入了V3 版本签名，在V2 插入的签名块中又插入了一个新块，以秘钥轮转的方案，来做签名的替换和升级，图2为是推荐使用的APK 签名流程图。

图2 APK 签名流程图

1.1.4 APK 加固

普通的APK 文件对攻击者来说属于裸奔状态，被反编译后能够轻易得到明文资源和DEX 原代码文件，因为常规的Android 程序代码都将打包在DEX 和so 文件中，这些文件经过反编译工具可以得到对应的源代码阅读。图3为APK 加固图，应用加固技术首先将原DEX 文件加密或者隐藏起来，然后放入一个新的壳DEX 到APK 中，最后程序启动时先运行这个壳DEX，然后壳DEX 在运行时再加载原DEX，使得攻击者不能直接通过APK 解压轻易获取到原代码资料。

图3 APK 加固图

建议通过引入第三方加固平台对混淆签名后的APK 进行安全加固，从而进一步保证DEX、so、资源文件、数据文件等重要的APK 文件信息的安全性，加固后的APK 通过代码插花、虚假控制流、字符串加密等手段提高了程序被破解的难度，能够一定程度上防止静态逆向、防篡改和二次打包，有效保护APP 的安全性。

1.2 数据安全

数据安全包括网络数据和本地数据两个方面。早期的Http 协议是明文传输攻击者可以轻易地通过Charles 或Fiddler 等抓包工具来拦截和篡改请求数据，虽然Android 9.0以后谷歌官方限制了默认不允许非加密的链接来改进对设备和数据安全的保护，但是Https 并不能直接阻挡攻击者分析请求接口并发起恶意请求攻击，数据之间的传递仍可被攻击者轻易抓取到并进行篡改。

1.2.1 网络数据

对于终端之间的通讯的数据安全，主要存在三个问题：

（1）传输内容可能被窃听。

（2）传输内容可能被篡改。

（3）无法验证双方的身份。

为了保证数据的真实性和可靠性，一般通过加签和加密两种方式来提高数据交互的安全性。签名校验是对请求数据、请求头参数进行一定规则的拼接和运算并进行结果签名，生成唯一的结果sign 作为校验字段，服务端接收到请求后进行唯一性验签校验，至于签名规则可双方约定，这里的签名规则相当于秘钥的作用，可将签名代码Native 化，或增加花指令来进一步提高破解难度。数据加密是对提交到服务器和从服务器接收到的数据都进行加密后再传输。加密类型有多种手段，一般使用对称加密和非对称加密的混合方式进行，对称加密的耗时较大，对大数据加密时存在一定的性能问题，Https 本身的加密处理也是类似，另外可以由后端控制公钥的过期时间和刷新来保持秘钥的动态性，进一步提高安全等级。

1.2.2 本地数据

本地数据包括三种情况：代码中敏感URL、APP 中敏感数据、通用加密算法参数，如图4所示。

图4 本地数据情况组成

（1）代码中敏感URL。直接将访问的网址或访问的IP地址硬编码写到代码中，那么攻击者通过反编译APP 进行静态分析，搜索URL 或IP 相关的信息，那么这些URL 或IP 信息就会成为攻击者的一个利用目标。

（2）APP 中敏感数据。Android 主要有五种数据存储方式：文件存储、SharedPreferences 轻量级存储、SQLite 数据库存储、ContentProvider 数据共享、网络存储。APP 运行时候会进行记录或存储一些敏感信息：个人隐私、登录信息、本地验证码、聊天记录，等等。SharedPreferences 存储数据主要记录存储一些数据量较小的信息。存储的信息直接可以用MT 管理工具或者直接用adb 复制传输到外部电脑主机上，再通过可视化工具进行打开查看文件，会造成配置信息或敏感的账号信息泄露。攻击方式有两种方式：一是利用apktool 反编译APP 应用，并进行查看二进制代码数据就能直观地看到敏感的操作调用敏感数据。二是通过代理模式进行抓包就可以直接抓到APP 运行中的操作的敏感数据。

（3）通用加密算法参数。代码中往往会出现一些保护敏感信息的常量字符串，例如在代码中硬编码AES 加密的key、iv 等，或者用户的VPN 密码等等。因此，本地数据同样需要进行加密存储，如Sqlite 数据库、SP 文件、SD 卡缓存、程序运行日志、本地资源文件等，加密过程可根据数据重要程度进行对称加密或非对称加密，且同样建议将加密过程Native 化，相对于Java 代码容易被反编译，C++代码编译后生成的库是一个二进制文件，能够初步阻挡住一些逆向者。一些重要数据（用户账号密码等），或者标记存储本地的时候也应该进行加密，或者直接存储hash 码，而不能直接存储明文。有些存储本地的数据，比如令牌，就需要进行加密处理。登录成功后的重要信息，如需要存储本地，也需要加密。