Android应用开发安全指南：防网络攻击与信息泄露要点

总结了Android应用开发的安全对策。

目次

1. 1. 前言
2. 2. Android安全的基础知识
3. 3. 文件的存储位置与访问权限
4. 3-1. 主要存储位置
5. 3-2. 文件的公开范围
6. 4. Google的备份、同步与共享
7. 4-1. 主要机制
8. 4-2. 控制备份对象
9. 4-3. 云访问控制与加密
10. 5. 机密信息的保存与加密

1. 引言

Android 具备操作系统级别的安全功能，如应用沙箱、应用签名和数据加密。

然而，如果应用的实现存在问题，可能会导致个人信息或认证信息泄露，或者服务器遭受非法访问。此外，还需要注意 Google 的备份功能、应用间的数据共享、外部库以及开发环境的管理。

本次将从数据保存、通信、认证、信息共享和开发环境等角度，介绍确保 Android 应用安全开发与运营的安全措施。

2. Android 安全基础

Android 提供了多种机制来保护应用和用户数据。

主要的安全功能如下。

通过这些机制，限制了对其他应用数据的非法访问。

然而，这并不能自动防止以下问题。

区分Android的保护范围与开发者自身需采取对策的范围至关重要。

3. 文件的保存位置与权限

Android应用的数据根据其存储位置，对其他应用的访问范围以及备份处理方式有所不同。

3-1. 主要存储位置

高机密性数据原则上使用应用专用的内部存储。

由于外部存储可能会根据用途被其他应用或用户访问，因此需注意公开范围。

3-2. 文件的公开范围

在Android中，内部存储的文件原则上无法被其他应用直接访问。

但是，使用ContentProvider或FileProvider等组件时，可以与其他应用共享数据。

请特别注意以下几点：

例如，对内部文件的访问方式如下。

context.openFileOutput(
    "data.txt",
    Context.MODE_PRIVATE
).use {
    it.write(data)
}

MODE_PRIVATE 用于创建仅限本应用使用的文件。但仅靠此指定并不会对文件内容进行应用专属的加密。

4. Google 的备份、同步与共享

在 Android 中，您可以使用 Google 的备份功能保存应用数据，或通过云服务进行同步和共享。

然而，备份、同步和共享是三种不同的功能。

4-1. 主要机制

例如，即使保存在 filesDir 中的数据包含在 Auto Backup 中，这并不意味着它会自动成为 Google Drive 上的共享文件。

4-2. 备份目标的控制

在Android中，可以通过配置文件来控制备份目标。

特别注意以下设置：

根据需要对机密信息和设备特定信息进行排除，不将其纳入备份范围。

此外，仅设置 allowBackup="false" 并不能完全控制所有设备间传输，因此还需要针对操作系统版本和设备制造商进行相应的行为确认。

4-3. 云端的访问控制与加密

Google的备份功能包含加密机制，但并非所有数据都以相同条件进行端到端加密。

此外，在使用Firebase等服务共享数据时，需要在应用侧设置访问控制。

特别是使用Android Keystore生成的密钥，通常无法恢复到备份目标的其他设备上。

还需注意仅加密文件被恢复但无法解密的问题。

5. 机密信息的保存与加密

在应用内处理的信息，根据其机密性选择相应的保存方法。

5-1. 基于 Android Keystore 的密钥管理

Android 提供了用于管理加密密钥的“Android Keystore”。

Android Keystore 是用于管理加密密钥的机制，并非用于直接保存任意密码或文件的通用存储。

例如，应用专属的认证令牌使用由 Keystore 保护的密钥进行加密，并将密文保存至 DataStore 等位置。

此外，传统的 EncryptedSharedPreferences 和 MasterKey 已被标记为不推荐。在新开发中，建议使用 Android Keystore 和标准加密 API 等，并根据需要考虑采用 Google Tink。

5-2. 加密与硬件保护

Android 支持使用 AES-GCM 等标准加密方式。

此外，在支持的终端设备上，可以将加密密钥保护在 TEE（可信执行环境）或 StrongBox 中。

硬件保护的对应情况因设备而异。

基本做法是不创建自定义加密算法，而是使用标准的安全方式。

6. 网络通信与API的保护

在应用与服务器之间的通信中，必须防止窃听、篡改和认证信息泄露。

6-1. HTTPS 与 Network Security Configuration

在 Android 中，可以利用“Network Security Configuration”来管理网络通信的安全设置。

例如，禁止明文HTTP通信的配置如下所示。

<network-security-config>
    <base-config
        cleartextTrafficPermitted="false" />
</network-security-config>

针对Android 9（API级别28）及以上版本的应用，标准网络API的明文HTTP通信默认受到限制。不过，对于自定义通信实现等场景，仍需另行确认。

此外，HTTPS是一种保护通信路径的机制，并不能防止对API本身的非法访问。

6-2. API密钥的管理

包含在APK或AAB中的代码和资源有可能通过解析被读取。

即使进行混淆处理，也无法完全隐藏包含在应用中的秘密信息。

6-3. 服务器端的对策

在服务器端，还需要采取以下措施。

Play Integrity API提供用于判断应用或终端完整性的信息。

不过，这并不能完全检测出不正利用，也不能替代用户认证或服务器端的访问控制。

7. 认证与访问控制

即使具备登录功能，如果认证或访问权限的验证存在问题，他人的信息也可能被获取。

7-1. 安全的认证方式

Android 的 Credential Manager 是一种统一处理密码、通行密钥等认证方法的机制。

此外，BiometricPrompt 可用于利用指纹或面部等进行的设备端身份验证，但这并不能保证服务器端的访问权限。

7-2. 服务器端的授权

例如，假设存在以下 API。

GET /api/users/123/profile

如果仅将用户 ID 更改为 124 就能获取他人的信息，则访问控制存在问题。

在 API 中，不仅需要验证认证状态，还需要在服务器端验证是否有权访问操作对象的数据。

仅在屏幕上隐藏按钮无法防止非法操作。

8. 应用间信息共享与WebView

在Android中，通过沙箱机制限制了应用间的相互访问，但可以通过Intent等方式传递数据。

8-1. 应用间信息共享

主要的共享功能包括以下几项：

需要特别注意 AndroidManifest.xml 中的配置。

如果 Activity、Service、BroadcastReceiver、ContentProvider 的公开范围存在问题，其他应用可能会执行非预期的处理。

8-2. WebView 的安全性

在使用 WebView 显示 Web 内容时也需要多加注意。

特别是在 addJavascriptInterface 中，可以从 JavaScript 调用 Android 侧的方法。

必须进行设计，使不可信的网页无法执行重要的终端功能。

9. 个人信息、日志与通知的处理

机密信息也可能从日志或画面中泄露。

9-1. 个人信息的访问权限

相机、麦克风、照片、通讯录、位置信息等，将在必要范围内访问。

在Android中，由于权限类型和行为会随操作系统版本而变化，因此需要针对每个支持的版本进行确认。

9-2. 日志中的信息泄露

应避免如下代码：

Log.d("Auth", "Token: $accessToken")

重要的是不要将密码、认证令牌、个人信息等输出到Logcat中。

此外，还需检查崩溃分析和访问分析的SDK是否意外发送了不应传输的信息。

9-3. 来自屏幕和通知的泄露

在Android中，可以通过为高敏感性的屏幕设置FLAG_SECURE来限制普通的截图和部分屏幕共享功能。

window.addFlags(
    WindowManager.LayoutParams.FLAG_SECURE
)

然而，这并不能防止所有形式的信息泄露，例如通过其他设备拍摄等方式。

10. 保护外部库和开发环境

在Android应用开发中，外部库、GitHub、CI/CD以及AI开发工具等也可能成为攻击目标。

10-1. 外部库与SDK

特别是广告SDK和访问分析SDK，会影响应用所收集信息的范围。

10-2. Git与CI/CD

特别注意防止keystore.jks等签名密钥和密码泄露。

即使使用Google Play App Signing，也需要妥善管理上传密钥和对Play Console的访问权限。

如果不慎提交了机密信息，不仅要将其从 Git 历史记录中删除，还要使相应的密钥或令牌失效并重新签发。

10-3. AI开发工具的安全性

使用 Codex 或 Claude Code 等 AI 代理时也需要注意。

AI 生成的代码未必安全。尤其是在认证、加密、访问控制等关键处理环节，需要由人工进行审查。

11. 数据删除与应用运维

在个人信息保护中，不仅保存方式重要，删除方法也同样重要。

11-1. 数据删除

在注销、退会或卸载时，请确认以下数据的处理方式：

通常，在卸载应用时会删除应用专用数据和Keystore中的密钥。

但是，备份的数据可能会在重新安装时被恢复。

此外，在退会时，还需确认服务器和云端数据以及备份中数据的保存期限和删除方针。

11-2. 应用的持续运营

应用发布后，仍需应对漏洞问题。

由于Android因终端制造商和OS版本不同而更新情况各异，因此确定支持对象也很重要。

12. 安全测试与发布前检查

可以使用OWASP发布的“MASVS”（Mobile Application Security Verification Standard，移动应用安全验证标准）来评估移动应用的安全性。

MASVS是定义了移动应用应满足的安全要求的标准，而非检查工具。

12-1. MASVS的8个领域

MASVS由以下8个领域组成：

具体的验证方法总结在“MASTG”（Mobile Application Security Testing Guide，移动应用安全测试指南）中。此外，“MASWE”（Mobile Application Security Weakness Enumeration，移动应用安全弱点枚举）对移动应用的安全弱点进行了系统化整理。

MASVS中定义了“需要确认什么”，MASTG中研究了“如何确认”，并通过分析工具和手动测试进行验证，这就是它们之间的关系。

12-2. 基于AI代理的安全审查

委托Codex或Claude Code等AI代理，按照MASVS的安全要求进行审查也是一种有效的方法。

借助AI代理，可以跨领域调查Kotlin代码、AndroidManifest.xml、Gradle配置以及依赖库等，从而梳理出潜在问题。

例如，可以这样下达指令：

然而，仅靠AI代码审查无法保证符合MASVS。

在设备上的运行行为、通信内容、服务器端的访问控制以及Google备份的设置等，需要另行验证。

此外，还需提前确认向AI发送源代码或使用工具的安全性。

12-3. 发布前的检查清单

AIエージェントによる初期レビュー → 指摘事項の修正 → 実機・APIのセキュリティテストという流れで確認するとよいでしょう。

13. まとめ

Androidは強力なセキュリティ機能を備えていますが、アプリやサーバーの実装に問題があれば、サイバー攻撃や情報漏洩は発生します。

特に重要なのは、機密情報の安全な保存、Googleバックアップや外部アプリとの共有範囲、通信の保護、サーバー側でのアクセス制御です。

また、外部ライブラリやAI開発ツール、開発環境の管理も含め、設計から公開後の運用まで継続的に安全性を確認する必要があります。

MASVSのような標準やAIエージェントを活用しながら、セキュリティ対策を開発プロセスに組み込むことが、安全なAndroidアプリの提供につながります。

関連