企业官网建设流程全解析

• 文档
• 教程
• 网络安全

本篇技术指南以 OWASP MASTG 仓库中的演示样例 MASTG-DEMO-0035 为主体，讲解如何在 Android 应用中通过backup_rules.xml将敏感文件从系统备份中排除，并使用adb backup完整验证排除规则是否真正生效。读者读完本文后，将掌握android:fullBackupContent/android:dataExtractionRules的配置方法、backup.ab备份文件的提取与分析流程，以及一套可直接复用的"备份敏感数据泄露"检测与加固实战方案。

为什么应用备份会成为敏感数据泄露的入口

Android 系统为应用提供了多种备份机制：原生 Android 自带的 USB 备份（adb backup）、Google "Back Up My Data" 云备份、Android 6.0（API 23）引入的 Auto Backup for Apps，以及 OEM 厂商的私有备份方案。这些备份通常会把应用的数据与设置全部打包，一旦其中包含明文敏感信息（口令、Token、密钥等），攻击者通过提取并解包备份文件即可直接读取这些数据。相关背景知识详见 MASTG-KNOW-0050（Backups）。

MASTG 仓库针对这一问题定义了动态测试用例 MASTG-TEST-0216（Sensitive Data Not Excluded From Backup）：它通过实际执行一次"备份—卸载—恢复"流程，检查哪些文件会被系统还原，从而验证应用是否正确地将敏感文件排除在备份之外；该用例对应 MASWE-0006 弱点，并取代了旧的 MASTG-TEST-0009（Testing Backups for Sensitive Data）（后者已标记为 deprecated）。演示样例 MASTG-DEMO-0035 正是这一测试的配套实验环境：它用 Kotlin 构造了包含敏感文件的样本应用，并借助backup_rules.xml的<exclude>规则尝试排除其中一个文件，最终用adb backup验证排除是否成功。

演示样例概览：样本复用与目录结构

MASTG-DEMO-0035 本身没有重复编写业务代码，而是直接复用 MASTG-DEMO-0020 的样本文件，仅更换了"提取方式"与"验证手段"：

• MASTG-DEMO-0020 使用Backup Manager（bmgr）走"备份→卸载→恢复"流程，观察恢复后文件是否回归；
• MASTG-DEMO-0035 改用adb backup直接拉取备份包，观察敏感文件是否被包含在备份归档中。

两者的目标一致：验证backup_rules.xml中的<exclude>规则是否真正生效。

样例目录（demos/android/MASVS-STORAGE/MASTG-DEMO-0035/）包含以下关键文件：

样本源码解析：MastgTest.kt 如何构造敏感数据

MastgTest.kt是整条测试链的起点，它在应用内部存储目录（context.filesDir）中写入两个内容相同的文件，模拟"敏感数据未加密落盘"的典型场景：

package org.owasp.mastestapp import android.content.Context import android.util.Log import java.io.File import java.io.FileOutputStream import java.io.IOException class MastgTest (private val context: Context){ fun mastgTest(): String { val internalStorageDir = context.filesDir val fileName = File(internalStorageDir, "secret.txt") val fileNameOfBackupExcludedFile = File(internalStorageDir, "backup_excluded_secret.txt") val fileContent = "secr3tPa\$\$W0rd\n" try { FileOutputStream(fileName).use { output -> output.write(fileContent.toByteArray()) Log.d("WriteInternalStorage", "File written to internal storage successfully.") } FileOutputStream(fileNameOfBackupExcludedFile).use { output -> output.write(fileContent.toByteArray()) Log.d("WriteInternalStorage", "File written to internal storage successfully.") } } catch (e: IOException) { Log.e("WriteInternalStorage", "Error writing file to internal storage", e) return "ERROR!!\n\nError writing file to internal storage" } return "SUCCESS!!\n\nFiles saved to $internalStorageDir" } }

这段代码的关键设计在于对比组：

• secret.txt—— 代表"敏感但未做任何保护"的文件，预期会出现在备份中；
• backup_excluded_secret.txt—— 内容同为敏感口令secr3tPa$$W0rd，但在backup_rules.xml中被标记为<exclude>，预期被排除在备份之外。

filesDir对应设备上的/data/user/0/org.owasp.mastestapp/files/（等价于/data/data/org.owasp.mastestapp/files/），这是应用内部存储的路径，普通用户无法直接访问，但通过备份机制却可以被完整打包带走——这正是本演示要揭示的风险。

配置解析：AndroidManifest.xml 中的备份三要素

AndroidManifest.xml中的<application>节点配置了与备份相关的三个属性：

<application android:allowBackup="true" android:dataExtractionRules="@xml/data_extraction_rules" android:fullBackupContent="@xml/backup_rules" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@style/Theme.MASTestApp" tools:targetApi="31">

逐个说明其含义：

• android:allowBackup="true"：允许系统备份应用数据。这是备份功能的总开关——当该属性为true时，设备允许用户通过adb backup等方式备份应用数据（相关机制见 MASTG-KNOW-0050）。若该属性缺省，allowBackup默认即为开启，必须显式关闭；
• android:fullBackupContent="@xml/backup_rules"：指向backup_rules.xml，用于Android 11（API 30）及更低版本的 Auto Backup 包含/排除配置（元素类型为<full-backup-content>）；
• android:dataExtractionRules="@xml/data_extraction_rules"：指向data_extraction_rules.xml，用于Android 12（API 31）及以上版本的备份配置（元素类型为<data-extraction-rules>），涵盖云备份（cloud-backup）与设备迁移（device-transfer）两种场景；
• tools:targetApi="31"：标注该清单按 API 31 解析，允许 IDE 正确识别dataExtractionRules等新属性。

backup_rules.xml：旧版系统的排除规则

backup_rules.xml内容如下：

<?xml version="1.0" encoding="utf-8"?> <full-backup-content> <include domain="file" path="." requireFlags="clientSideEncryption" /> <exclude domain="file" path="backup_excluded_secret.txt" /> </full-backup-content>

配置要点：

• <include domain="file" path="." requireFlags="clientSideEncryption" />：默认包含file域（即filesDir）下的全部内容。requireFlags="clientSideEncryption"表示该包含规则仅在设备支持"客户端侧加密"能力时才生效，属于条件性包含；
• <exclude domain="file" path="backup_excluded_secret.txt" />：在file域中按相对路径精确排除backup_excluded_secret.txt，这就是演示中该文件不出现在备份里的直接原因。

data_extraction_rules.xml：Android 12+ 的双通道规则

data_extraction_rules.xml针对新版系统把备份拆分为两条独立通道分别配置：

<?xml version="1.0" encoding="utf-8"?> <data-extraction-rules> <cloud-backup disableIfNoEncryptionCapabilities="true"> <exclude domain="file" path="backup_excluded_secret.txt" /> </cloud-backup> <device-transfer disableIfNoEncryptionCapabilities="true"> <exclude domain="file" path="backup_excluded_secret.txt" /> </device-transfer> </data-extraction-rules>

规则要点：

• cloud-backup：控制备份到云端（如 Google Drive）时的文件范围；
• device-transfer：控制设备到设备迁移（换机克隆）时的文件范围；
• 两处均排除backup_excluded_secret.txt，并设置disableIfNoEncryptionCapabilities="true"（当设备不具备加密能力时禁用备份）。正如 MASTG-BEST-0004（Exclude Sensitive Data from Backups） 所强调的：云备份与设备迁移两条通道都必须同时配置排除规则，只配其一属于常见疏漏。

实战步骤：从安装应用到拉取备份

演示文档给出的操作流程只有三步，但每一步都对应明确的验证意图：

1. 安装目标应用到设备（可通过 MASTG-TECH-0005 介绍的方式安装）；
2. 打开应用并交互操作，触发mastgTest()执行文件写入，确保secret.txt与backup_excluded_secret.txt都已落盘；
3. 执行run.sh，自动完成adb backup拉取、解包与结果整理。

run.sh：一键化执行脚本

run.sh内容如下：

#!/bin/bash package_name="org.owasp.mastestapp" ../../../../utils/mastg-android-backup-adb.sh $package_name ls -l1 apps/org.owasp.mastestapp/f > output.txt # Cleanup rm backup.ab backup.tar find apps/org.owasp.mastestapp/ -mindepth 1 -maxdepth 1 ! -name 'f*' -exec rm -rf {} +

脚本逻辑拆解：

• 首先调用 MASTG 仓库的通用备份脚本 utils/mastg-android-backup-adb.sh，对包名org.owasp.mastestapp执行adb backup并解包；
• 随后执行ls -l1 apps/org.owasp.mastestapp/f > output.txt，只列出解包结果中f/目录（即filesDir）下的文件名，写入output.txt——这是整个演示"观察"环节的核心产物；
• 最后清理backup.ab、backup.tar等中间文件，并删除apps/中除f*外的目录，保持工作目录整洁。

需要说明的是，adb backup自Android 12 起受到限制，且要求应用的android:debuggable=true（见 MASTG-KNOW-0050 与 MASTG-TECH-0128），因此本演示适用于可调试应用或 Android 12 之前的环境；模拟器与真机的行为也可能存在差异。

底层原理：mastg-android-backup-adb.sh 如何解包 backup.ab

utils/mastg-android-backup-adb.sh是 MASTG 仓库中与adb backup相关的通用工具脚本，完整内容如下：

#!/bin/bash # Default package name if [ -z "$1" ]; then echo "No package name provided. Usage: $0 <package_name>" exit 1 else package_name="$1" fi adb backup -apk -nosystem $package_name tail -c +25 backup.ab | python3 -c "import zlib,sys;sys.stdout.buffer.write(zlib.decompress(sys.stdin.buffer.read()))" > backup.tar tar xvf backup.tar echo "Done, extracted as apps/ to current directory"

其内部对应了 MASTG-TEST-0009 中描述的经典三步解包流程：

1. adb backup -apk -nosystem <package_name>：请求系统生成备份文件backup.ab。执行时设备端会弹出"备份我的数据"确认提示，密码为可选项（不填亦可）；-apk将 APK 一并打入归档，-nosystem排除系统应用。若 adb 版本低于 1.0.31，可能需将参数整体加引号传递；
2. 剥离 24 字节文件头并解压：Android 备份文件（backup.ab）以约 24 字节的 ASCII 头开始，tail -c +25跳过该头部后，剩余数据为 zlib 压缩流，通过python3调用zlib.decompress还原为 tar 归档（backup.tar）。这也是 MASTG-TEST-0009 中openssl zlib -d与 Android Backup Extractor（abe.jar unpack）等替代方案的等价实现；
3. tar xvf backup.tar：解包得到apps/目录，其结构为apps/<package_name>/，其中f子目录即应用的filesDir，另有db、sp、r等子目录对应数据库、SharedPreferences 与 raw 文件。

补充：若走 Backup Manager 路线，可改用仓库中的 utils/mastg-android-backup-bmgr.sh，它通过adb shell bmgr配合本地传输器（LocalTransport）执行backupnow，再卸载重装触发恢复，从而验证"恢复后"的数据状态；两种工具脚本的完整用法见 MASTG-TECH-0128。

观察结果：备份归档里到底有什么

执行run.sh后，工作目录下会出现两类产物：

• output.txt：备份中实际包含的文件清单；
• apps/org.owasp.mastestapp/f/：备份文件解包后的filesDir目录副本。

本演示生成的output.txt内容如下：

profileInstalled secret.txt

对应的目录副本apps/org.owasp.mastestapp/f/中同样只含profileInstalled与secret.txt两个文件。将这份清单与源码中写入的两个文件（secret.txt、backup_excluded_secret.txt）对比，结论一目了然：

• secret.txt出现在备份中；
• backup_excluded_secret.txt没有出现在备份中，<exclude>规则成功生效。

评估：测试为什么失败

查看备份中保留下来的secret.txt，其内容为明文口令：

secr3tPa$$W0rd

依据 MASTG-TEST-0216 的评估标准：只要备份/恢复出的文件中存在任何敏感内容，测试即判定失败（FAIL）。本演示中secret.txt未在backup_rules.xml中标记排除，明文口令随之进入备份包，因此测试失败；而backup_excluded_secret.txt因被<exclude>标记而未进入备份，属于符合预期的对照表现。

这一结果精准复现了 MASWE-0006 所描述的弱点：开发者可能只保护了部分文件，却遗漏了其他同样敏感的数据——防御必须做到"完整覆盖"，而不能只针对已知文件逐个打补丁。

与 MASTG-DEMO-0020 的对比：两种验证路径的取舍

MASTG-DEMO-0035 与源样本 MASTG-DEMO-0020 共享同一套MastgTest.kt、AndroidManifest.xml与backup_rules.xml，但验证路径不同：

MASTG-DEMO-0020 的run.sh会先快照备份前文件（output_before.txt），恢复后再快照（output_after.txt），并断言backup_excluded_secret.txt不会在恢复后回归。相比之下，MASTG-DEMO-0035 更直接：解包即见分晓，适合快速核查"备份包是否干净"。两者共同构成对同一配置（backup_rules.xml）的双角度验证。

加固建议：如何让备份彻底告别敏感数据

结合 MASTG-BEST-0004（Exclude Sensitive Data from Backups），修复本演示暴露的问题可遵循以下步骤：

1. 盘点敏感文件：对照应用内所有写入内部存储、SharedPreferences、数据库的数据，标记其中属于口令、Token、密钥、个人信息等敏感类别者；
2. 配置排除规则：
   • 使用 Auto Backup 的应用，在backup_rules.xml（Android 11 及以下，通过android:fullBackupContent声明）中对每个敏感文件/目录添加<exclude domain="file" path="..." />；
   • 面向 Android 12 及以上的应用，同时在data_extraction_rules.xml（通过android:dataExtractionRules声明）的cloud-backup与device-transfer两个通道中各自排除，二者缺一不可；
3. 从根上减少明文落盘：备份排除属于缓解措施而非根治——敏感数据在落盘前就应加密存储，使即使被备份也不会直接泄露；
4. 回归验证：每次改动配置后，重复本演示的adb backup解包流程（或 MASTG-TECH-0128 的bmgr恢复流程），确认备份归档中不再出现任何敏感文件。

小结

MASTG-DEMO-0035 用最小的样本规模完整展示了"备份敏感数据泄露"从构造、触发、观察到评估的闭环：MastgTest.kt负责制造明文敏感文件，backup_rules.xml/data_extraction_rules.xml负责演示排除机制，run.sh与 utils/mastg-android-backup-adb.sh 则提供了可复用的adb backup解包提取手段。最终结论验证了 MASTG-TEST-0216 的判定逻辑：只要secret.txt这类敏感文件仍在备份归档中，测试即失败；同时<exclude>规则确实能让backup_excluded_secret.txt从备份中消失——这也提示开发者，排除规则必须逐一覆盖所有敏感路径，并且新旧系统版本（fullBackupContent与dataExtractionRules）需要同时配置，才能真正堵住备份这条数据泄露通道。

• 文档
• 教程
• 网络安全