1. 项目概述从InsecureBankv2看移动应用的数据安全“命门”最近在复盘一些经典的Android安全靶场应用InsecureBankv2又一次进入了我的视野。这个应用被设计得“千疮百孔”几乎涵盖了移动应用开发中所有常见的安全漏洞是安全测试人员和开发者进行自检的绝佳教材。而其中关于“不安全数据存储”的部分尤其是对SharedPreferences和SQLite的滥用可以说是最普遍、也最容易被开发者忽视的“重灾区”。我见过太多上线的App其用户敏感信息就像放在透明的玻璃柜里Root后的设备或者一个简单的文件浏览器就能让所有数据“裸奔”。今天我们就以InsecureBankv2为案例深入解剖这两种数据存储方式背后潜藏的风险。这不仅仅是给安全工程师看的更是每一位Android开发者都应该警惕的必修课。无论你是正在学习Android开发的新手还是已经有一定经验的从业者理解这些风险并掌握正确的防护姿势都能让你开发的App在安全层面提升一个等级避免因为低级的数据存储漏洞导致用户信息泄露甚至法律风险。2. 靶场环境与风险场景还原2.1 InsecureBankv2一个故意“不安全”的银行应用InsecureBankv2并非一个真实的银行应用而是一个由安全研究人员故意开发的存在大量漏洞的Android应用。它的核心价值在于教育。应用模拟了一个银行App的基本功能用户登录、查看账户余额、转账等。开发者故意在代码中留下了多种类型的安全漏洞包括但不限于不安全的通信、弱加密、逻辑缺陷以及我们重点要讨论的不安全数据存储。通过分析和攻击这个应用安全人员可以熟悉常见的攻击向量而开发者则可以直观地看到哪些编码习惯是危险的。把它当作一个“反面教材”来学习效果往往比看正面的安全规范要深刻得多。2.2 不安全数据存储的典型风险场景在InsecureBankv2中不安全的数据存储主要体现在它将敏感信息以明文或弱保护的形式保存到了设备的本地存储中。设想一下真实场景用户的手机可能丢失、被盗或者被安装恶意软件。攻击者一旦获取设备的物理访问权限或通过其他漏洞提升权限如Root本地存储的文件就成了唾手可得的“宝藏”。具体风险包括凭证泄露登录令牌Session Token、用户名、密码尽管不应明文存储密码但弱哈希存储同样危险被窃取导致攻击者可以冒充用户身份。隐私数据泄露账户余额、交易记录、手机号、身份证号等个人敏感信息暴露。敏感配置泄露后端服务器地址、API密钥、加密盐值等本应保密的信息被获取可能被用于发起对服务器更复杂的攻击。 这些泄露的后果轻则是单个用户账户被盗重则可能引发大规模的数据泄露事件对应用厂商的信誉和法律责任造成毁灭性打击。3. SharedPreferences 风险深度剖析3.1 SharedPreferences 的工作机制与“透明”本质SharedPreferences是Android提供的一种轻量级键值对数据存储方式通常用于保存应用的配置信息、用户偏好设置等。它使用XML文件格式默认存储在应用沙盒内的/data/data/package_name/shared_prefs/目录下。其API非常简单易用通过getSharedPreferences()获取实例然后使用Editor进行put和commit/apply操作。 然而其风险正源于这种“简单”。在非Root的普通设备上这些文件受系统沙盒保护其他应用无法访问。但这层保护非常脆弱。一旦设备被Root或者应用自身存在漏洞导致文件权限设置不当如使用MODE_WORLD_READABLE该模式已在较高API级别被废弃这些XML文件就可以被任意读取。更关键的是SharedPreferences设计之初并非用于存储敏感数据它默认不提供任何加密。保存进去的字符串、整数、布尔值在XML文件中都以明文形式存在。3.2 InsecureBankv2中的SharedPreferences漏洞实例在InsecureBankv2的代码中我们可以找到类似这样的危险代码片段为说明问题以下为模拟代码// 危险示例将登录令牌明文存入SharedPreferences SharedPreferences prefs getSharedPreferences(“user_session”, MODE_PRIVATE); SharedPreferences.Editor editor prefs.edit(); editor.putString(“auth_token”, “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...” // 一个JWT令牌 editor.apply();这段代码看起来使用了MODE_PRIVATE在正常情况下是安全的。但是如果攻击者能够通过ADB连接到已Root的设备只需几条命令就能将整个shared_prefs目录拉取到电脑上adb shell su cp /data/data/com.android.insecurebankv2/shared_prefs/user_session.xml /sdcard/ exit adb pull /sdcard/user_session.xml .打开这个XML文件里面的auth_token等内容一览无余。攻击者拿到这个令牌很可能就能直接在别的设备或通过API直接访问该用户的账户。3.3 安全使用SharedPreferences的实践指南绝对不要用SharedPreferences存储密码、令牌、密钥等高度敏感信息。如果非要存储一些需要持久化的配置请遵循以下原则仅存储非敏感信息如用户界面主题选择、通知开关、上次阅读的新闻ID等。使用AndroidX Security Crypto库进行加密对于需要存储的敏感信息应该使用Android系统提供的安全加密组件。推荐使用EncryptedSharedPreferences它是Jetpack Security库的一部分。// 正确示例使用EncryptedSharedPreferences val masterKeyAlias MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC) val sharedPrefs EncryptedSharedPreferences.create( “secure_prefs” masterKeyAlias, context, EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV, EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM ) sharedPrefs.edit().putString(“highly_sensitive_key” “encrypted_value_here”).apply()EncryptedSharedPreferences会在读写时自动对键和值进行加密和解密密钥由Android KeyStore系统管理安全性大大提升。彻底废弃MODE_WORLD_READABLE/WRITABLE在如今的开发中绝对不要使用这些标志位。它们会创建全局可读/写的文件是严重的安全漏洞。实操心得很多老项目或从网上抄的代码中可能还残留着不安全的SharedPreferences用法。代码审计时全局搜索getSharedPreferences和MODE_关键字是一个快速发现此类漏洞的好方法。对于新项目从一开始就建立规范禁止向普通SharedPreferences写入任何敏感信息。4. SQLite 数据库安全风险详解4.1 SQLite的便捷性与安全盲区SQLite是Android系统内置的轻量级关系型数据库因其无需单独部署服务、零配置、单文件存储的特性非常适合在移动设备上存储结构化数据比如聊天记录、离线文章、交易日志等。开发者通过SQLiteOpenHelper可以轻松地创建和管理数据库文件该文件通常位于/data/data/package_name/databases/目录下。 和SharedPreferences类似SQLite数据库文件在非Root设备上受沙盒保护。但其风险维度更多明文存储默认情况下数据库表中的数据以明文形式存储。即使你将密码通过MD5或SHA-1哈希后存入在彩虹表攻击下也极其脆弱。文件可拷贝Root后整个.db文件可以被轻松复制出来。使用诸如“DB Browser for SQLite”这样的图形化工具任何人都能像打开Excel表格一样浏览、修改所有数据。日志文件WAL/JournalSQLite支持WALWrite-Ahead Logging模式以提高性能但这会产生-wal和-shm文件。这些文件可能包含已提交或未提交的数据片段如果处理不当如应用崩溃可能留下敏感数据的残余信息。你提供的热词中有一条关于处理日志文件增长的问题这虽然是性能问题但从安全角度看异常的文件增长也可能暗示着异常的数据操作需要警惕。注入风险如果使用原始的、未经参数化查询的SQL语句拼接会引入SQL注入漏洞攻击者可能通过输入恶意数据来窃取或破坏数据库内容。4.2 InsecureBankv2中的SQLite漏洞实例在InsecureBankv2中可能会发现如下模式的代码// 危险示例1明文存储用户PIN码 String insertSQL “INSERT INTO users (username, pin) VALUES (‘” username “‘ ‘” pin “‘)” db.execSQL(insertSQL); // 典型的SQL注入明文存储双重漏洞 // 危险示例2查询时直接拼接 String query “SELECT * FROM transactions WHERE account_id ‘” accountId “‘” Cursor cursor db.rawQuery(query, null);第一种情况用户的PIN码以明文形式存入数据库。第二种情况accountId如果是用户可控的输入攻击者可以输入‘ OR ‘1’‘1之类的字符串导致查询条件永远为真泄露所有交易记录。 即使没有SQL注入当数据库文件被拷贝后用SQLite工具打开所有数据暴露无遗。4.3 加固SQLite存储的层级化策略保护SQLite中的数据需要一套组合拳不能依赖单一措施。4.3.1 第一层输入验证与参数化查询这是防御SQL注入的根本也是任何数据库操作的前提。务必使用参数化查询Parameterized Queries或SQLiteStatement。// 正确示例使用参数化查询 val db writableDatabase val sql “INSERT INTO users (username, pin_hash) VALUES (?, ?)” val statement db.compileStatement(sql) statement.bindString(1, username) statement.bindString(2, hashedPin) // 注意这里存储的应该是哈希值而非明文 statement.executeInsert()对于查询使用query()方法或rawQuery()的带参数版本。4.3.2 第二层敏感数据加密存储对于必须存储的敏感信息如身份证号、银行卡号中间段、某些密钥应在存入数据库前就进行加密。列级加密只对特定的敏感列进行加密。可以使用Android KeyStore系统生成的密钥通过AES等算法在数据写入前加密读取后解密。这样做的好处是查询非加密列时性能不受影响但加密列无法被直接用于查询如WHERE条件。// 伪代码列加密示例 String sensitiveData “410***********123X” String encryptedData AesCrypto.encrypt(keyAlias, sensitiveData); // 将encryptedData存入数据库 // 读取时 String cipherText cursor.getString(cursor.getColumnIndex(“id_card”)); String plainText AesCrypto.decrypt(keyAlias, cipherText);全库加密使用支持加密的SQLite版本如SQLCipher。SQLCipher是一个开源的SQLite扩展它对整个数据库文件进行透明的256位AES加密。应用在打开数据库时需要提供密码之后所有的读写操作都由SQLCipher自动加解密。这是目前最彻底、最推荐的对SQLite数据库进行安全保护的方式。集成后即使数据库文件被窃取没有密码也无法解密。// 在build.gradle中添加依赖 implementation ‘net.zetetic:android-database-sqlcipher:4.5.3’// 使用SQLCipher打开数据库 SQLiteDatabase.loadLibs(context); SQLiteDatabase db SQLiteDatabase.openOrCreateDatabase(databaseFile, “yourStrongPassword!” null, null);4.3.3 第三层文件系统与运行时防护避免存储在外部存储绝对不要将数据库文件创建在外部存储如SD卡或/sdcard/目录下因为这些位置对所有应用都可读。你的热词中有一条“android sqlite 数据库文件保存在外部存储空间”这本身就是一个高危操作。及时清理临时文件关闭数据库连接确保WAL日志被正确合并和清理。对于异常增长的WAL文件如你热词中提到的日志写盘问题需要检查应用逻辑确保事务被正确提交或回滚避免长期持有写锁导致日志膨胀。可以定期执行PRAGMA wal_checkpoint(TRUNCATE)来整理WAL文件但这更多是维护和性能考量从安全角度看确保日志文件不长期残留敏感数据即可。最小化数据留存遵循数据最小化原则。不收集、不存储非必要的用户数据。对于缓存或临时数据设置合理的过期时间并及时清除。注意事项使用SQLCipher会带来一定的性能开销约5%-15%并且会增加APK体积。但对于存储金融、医疗、隐私通讯等敏感数据的应用这点开销是必须付出的安全成本。在决策时需要进行安全与性能的权衡。5. 综合防护与安全开发实践5.1 安全数据存储的决策流程图面对一项数据该如何选择存储方式我总结了一个简单的决策流程是否需要持久化如果否使用内存变量即可。数据是否敏感如凭证、隐私信息、财务数据。不敏感根据数据结构选择。简单配置用SharedPreferences复杂关系数据用SQLite无需加密。敏感进入下一步。数据量大小和结构如何小量、非结构化/键值对使用EncryptedSharedPreferences。大量、结构化使用SQLCipher加密的SQLite数据库并对库内极度敏感的字段进行列级二次加密。是否涉及与服务器同步如果是考虑仅在本地缓存加密后的数据或哈希值完整数据存储在服务端。5.2 开发中的安全编码习惯代码审查将“数据存储安全”作为代码审查的必检项。重点关注所有SharedPreferences写入、SQLiteDatabase的execSQL和rawQuery调用。使用安全库积极采用Google推荐的Jetpack Security库 (androidx.security:security-crypto) 来处理加密需求而不是自己实现加密算法。依赖项检查确保使用的第三方库尤其是涉及网络和存储的没有已知的安全漏洞。可以使用./gradlew dependencyCheckAnalyze配合OWASP Dependency-Check等工具。混淆与加固发布前对APK进行代码混淆ProGuard/R8并考虑使用商业加固方案增加逆向工程和动态调试的难度保护加密密钥和逻辑不被轻易分析。5.3 测试与验证如何检查自己的应用静态分析 (SAST)使用Android Studio自带的Lint工具、SonarQube或Coverity等可以扫描出部分不安全的数据存储模式。动态分析 (DAST)Root设备测试将应用安装在已Root的设备或模拟器上使用adb shell和su命令尝试访问/data/data/your.package.name/下的shared_prefs和databases目录看能否轻易拉取文件。文件监控运行应用时使用strace或frida等工具监控其创建和访问了哪些文件是否有意料之外的敏感信息写入。备份测试通过adb backup命令备份应用检查备份包中是否包含了本应加密的敏感数据。Android的备份机制默认会排除getNoBackupFilesDir()目录下的文件敏感数据应放在这里。使用自动化安全测试工具MobSF (Mobile Security Framework)、QARK等工具可以自动化地扫描APK并报告不安全的数据存储问题。6. 常见问题与排查技巧实录在实际开发和渗透测试中会遇到一些典型问题和困惑。这里记录几个常见的场景和解决思路。问题1我已经用了MODE_PRIVATE为什么安全扫描工具还说我的SharedPreferences不安全排查扫描工具报警的很可能不是你用了MODE_PRIVATE而是你向SharedPreferences里写入了敏感内容。工具通过静态分析发现你将“token”、“password”、“key”等字符串作为键名或者写入了看似加密的字符串如Base64编码的密文但Base64不是加密。MODE_PRIVATE只解决文件权限问题不解决内容明文问题。解决方案将敏感数据迁移到EncryptedSharedPreferences或Android KeyStore中。问题2集成SQLCipher后数据库操作变慢偶尔出现“database is locked”错误。排查这是性能和多线程问题。SQLCipher的加解密操作会增加CPU开销。database is locked通常是因为多个线程同时尝试写数据库而SQLite/SQLCipher的写锁是数据库级别的。解决技巧使用单例模式确保整个应用只有一个SQLiteOpenHelper实例。优化事务将大批量的写操作放入一个事务中可以显著提升速度并减少锁冲突。db.beginTransaction(); try { // 批量插入/更新操作 for (Data item : dataList) { // ... 执行插入 } db.setTransactionSuccessful(); // 标记事务成功 } finally { db.endTransaction(); // 结束事务如果未setSuccessful则会回滚 }考虑读写分离对于读多写少的场景可以维护一个只读的数据库连接用于查询。但注意SQLCipher的密码验证在每次打开连接时都会发生。检查日志模式确认是否使用了WAL模式PRAGMA journal_modeWAL它在读多写少的场景下能减少锁竞争。问题3热词中提到“帮我检查 ~1.codex/logs_2.sglite 是否因 trace 日志持续高频写盘...”这和安全有关吗分析与技巧这个问题表面上是性能问题日志高频写导致I/O瓶颈和存储空间占用但深层次看有安全隐忧。如果这个sglite疑似sqlite笔误数据库里记录的是trace日志而日志中可能包含敏感信息如请求参数、内部错误信息、部分用户数据那么数据泄露风险持续增长的日志文件可能成为敏感信息的“沉淀池”。存储寿命高频写会加速存储芯片磨损但这不是主要安全点。解决方案采样记录不要全量记录trace改为错误时记录或抽样记录。日志脱敏在写入日志前对手机号、身份证、令牌等敏感字段进行掩码如138****1234或哈希处理。使用Trigger拦截并清理正如热词中提到的可以创建一个SQLite的BEFORE INSERT触发器在日志插入时进行检查和拦截或者将日志重定向到另一个可循环覆盖的文件中。定期清理实现一个机制定期执行DELETE FROM logs WHERE id (SELECT max(id) FROM logs) - 10000来只保留最新的一万条或者按时间删除旧日志。同时配合VACUUM命令需谨慎会锁库或PRAGMA wal_checkpoint(TRUNCATE)来清理空间。问题4在Android 10 (API 29) 及以上版本无法直接访问/data/data/目录如何测试数据存储安全性技巧这确实是测试环境搭建的一个变化。有以下几种方法使用可调试Debuggable的构建变体在build.gradle中为测试构建类型设置debuggable true。对于非Root设备只有debuggable的应用才能通过run-as命令访问其私有目录。adb shell run-as com.your.package.name cd /data/data/com.your.package.name ls -la使用Root的模拟器或真机这是最直接的方法。Android Studio提供的模拟器镜像可以轻松Root。将文件复制到外部存储在应用代码中临时添加逻辑在测试时将数据库或prefs文件复制到/sdcard/或Download目录然后通过ADB拉取。切记此代码仅用于测试绝不能出现在发布版本中利用备份通过adb backup -f backup.ab com.your.package.name备份应用然后使用abeAndroid Backup Extractor等工具解压备份文件从中提取数据库文件进行检查。问题5加密密钥本身该如何安全存储核心原则密钥绝不能硬编码在代码或资源文件中。Android系统提供了最安全的解决方案——Android KeyStore系统。它是一个专门用于在设备上安全存储加密密钥的硬件或软件隔离容器。KeyStore中的密钥难以从设备中提取甚至在某些具备安全硬件如Titan M芯片的设备上私钥操作完全在安全环境中进行操作系统都无法直接访问私钥材料。对于EncryptedSharedPreferences它内部已经使用KeyStore来管理主密钥。对于自定义的AES加密你应该使用KeyGenParameterSpec来在KeyStore中生成或导入密钥并在使用时通过KeyStoreAPI获取而不是将密钥的字节数组保存在内存或文件中。val keyStore KeyStore.getInstance(“AndroidKeyStore”) keyStore.load(null) val key keyStore.getKey(“my_key_alias” null) as SecretKey val cipher Cipher.getInstance(“AES/GCM/NoPadding”) cipher.init(Cipher.ENCRYPT_MODE, key)这样即使应用被逆向攻击者也无法直接拿到密钥明文。