MASTG 敏感数据识别指南：定义数据分类边界，为移动应用安全测试奠定基线

• 文档
• 教程
• 网络安全

本文基于 OWASP MASTG 前置知识章节《Identifying Sensitive Data》identify-sensitive-data.md，讲解在移动应用安全测试开始前如何定义"敏感数据"。文中将三种数据状态（静态存储、使用中、传输中）与 MASTG 测试体系中的存储、内存与网络测试一一对应，并结合仓库中的测试用例与知识条目，展示如何把数据分类定义落到具体的测试执行与结果判定上。读者读完将能够建立一套可复用的敏感数据识别工作流，并据此判断哪些测试发现属于真实漏洞。

为什么必须在测试前定义"敏感数据"

敏感信息的分类标准因行业和国家而异：金融、医疗、政务等行业对个人数据的界定与合规要求各不相同，不同司法管辖区的法律对"个人可识别信息（PII）"的覆盖范围也存在差异。与此同时，许多组织会采取比法规更严格的数据分类策略（data classification policy），由内部制度明确哪些信息属于敏感信息。

MASTG 明确指出，"敏感数据"的定义必须在测试开始之前确定，因为"在缺乏定义的情况下，检测敏感数据泄漏可能是不可能的"（detecting sensitive data leakage without a definition may be impossible）。这条结论是整份文档的方法论基石：没有事先明确"什么算敏感"，后续的静态分析、动态抓取、内存转储、文件系统审计都会失去判定基准，测试人员既无法确认发现，也无法向开发团队解释为什么某个数据项需要保护。

在 MASTG 的仓库结构中，这条前置知识与其他两个前置条目构成一组配套方法论，均位于 prerequisites 目录下：

• identify-sensitive-data.md：界定"什么数据敏感"，即本文主题；
• identify-first-party-domains.md：界定"哪些服务端域名属于一方（first-party）"，用于证书固定等网络测试的范围判定；
• identify-security-relevant-contexts.md：界定"代码中哪些上下文是安全相关的"，用于减少测试中的误报。

三者共同回答了移动应用安全测试的"范围与基线"问题：先知道哪些数据敏感、哪些端点归自己管、哪些代码上下文涉密，才能知道该测什么、不该报告什么。

数据的三种存在状态

识别敏感数据的第二步，是理解数据在移动应用生命周期中可能被访问的三种一般状态：

该状态划分在 Document/0x04b-Mobile-App-Security-Testing.md 的 "Identifying Sensitive Data" 小节中被完整收录，是 MASTG 全书共用的数据分类框架。理解三种状态的价值在于：每种状态的攻击面不同，因此需要不同的测试方法与保护强度。

At rest：文件与数据存储中的敏感数据

静态存储是最直观的敏感数据载体。MASTG 存储类测试正是围绕"应用是否把敏感数据未加密地落盘"展开。例如测试用例 MASTG-TEST-0287（Runtime Storage of Unencrypted Data via the SharedPreferences API）以identify-sensitive-data为前置条件，其判定标准是："如果敏感数据在未加密的情况下被写入 SharedPreferences，测试失败"。该用例关注的关键 API 包括：

• SharedPreferences.Editor.putString(...)与putStringSet(...)——字符串是最常见的敏感数据载体（API 密钥、令牌、口令、私钥）；
• 加密侧则关注javax.crypto.Cipher、java.security.KeyStore、javax.crypto.KeyGenerator——用于确认写入前是否发生了加密操作。

另一个动态文件系统用例 MASTG-TEST-0207 采用更朴素的方法：在操作应用前后两次拷贝其私有数据目录并做 diff，找出会话期间新建或修改的文件，再检查其中是否包含测试者输入的敏感数据（如用户名、口令、信用卡号）。其评估部分特别提醒：编码不是保护——测试者应当尝试识别并解码 Base64、十六进制表示、URL 编码、转义序列、宽字符，以及 XOR 等常见混淆手段，同时识别并解压 tar/zip 等压缩文件，因为这些手段"模糊了数据但并未保护数据"。

In use：进程地址空间中的敏感数据

数据一旦被应用加载进内存，就进入"使用中"状态。MASTG 指出，内存中的数据可能比 web 服务器上的数据更容易通过 core dump（核心转储）被访问，因为攻击者更可能获得移动设备的物理访问权，而非 web 服务器的物理访问权。

测试用例 MASTG-TEST-0011（Testing Memory for Sensitive Data）对此给出完整方法论：首先识别哪些敏感资产会被加载进内存，然后验证"这些信息暴露的时间尽可能短"。该用例还给出了内存数据管理的实践准则：

• 识别应用组件并绘制数据的使用映射，让敏感数据尽可能少地被组件处理；
• 对象不再需要时及时移除引用，并在移除后请求垃圾回收；
• 敏感数据一旦不再需要就立即覆盖（overwrite）；
• 不要用不可变类型（如String、BigInteger）承载敏感数据，避免使用StringBuilder等非原始类型；
• 在finalize方法之外覆盖引用；
• 关注第三方组件（库和框架）的公共 API 是否按同样的原则处理敏感数据。

该用例还提供了一个值得注意的工程细节：覆盖时应"用随机数据或来自非关键对象的内容覆盖关键对象"，因为仅用全零覆盖会让攻击者轻易构造出"能基于数据管理方式识别敏感数据"的扫描器。

In transit：传输中的敏感数据

数据在移动应用与端点之间、或设备内部进程（IPC）之间交换时处于传输状态。对这一状态的测试重点在于传输通道本身的安全性——是否使用 TLS、是否验证主机名、是否校验证书信任链、是否实现证书固定。需要注意的是，网络测试的范围判定与本文的主题存在联动：证书固定等控制措施只应对"一方（first-party）域名"评估，而分析、崩溃上报、广告、社交 SDK 等第三方端点不在其列，详见 identify-first-party-domains.md。

各状态应有的审查强度

文档强调，每种状态"适当的审查强度（degree of scrutiny）可能取决于数据的重要性和被访问的可能性"。换言之，并非所有状态、所有数据都需要同等级别的保护：

• 数据越重要、越容易被访问，越需要高强度的审查与保护；
• 例如，驻留于移动应用内存中的数据，其暴露面（物理设备可达、可被转储）比 web 服务器上的数据更大，因此对内存中敏感数据的处理需要更严格的规则（立即覆盖、避免不可变类型、最小化组件接触面）；
• 而静态存储中的数据，若已通过系统安全容器（如 Android 应用私有目录、iOS 沙盒）隔离，且无备份外泄路径，其审查重点则落在"是否明文落盘""是否被备份/日志带走"等具体风险点上。

这一"按状态评估强度"的思想贯穿 MASTG 的测试用例设计：例如 Android 内部存储知识条目 MASTG-KNOW-0041 说明内部存储文件默认容器化、其他应用无法访问，但并未因此免除加密义务——外部存储（可被第三方应用读取的共享存储）则是另一类风险更高的场景。

通用敏感数据清单

当组织没有现成的数据分类策略时，MASTG 提供了以下通常被认为敏感的信息清单（原文档完整六条，全部继承）：

1. 用户认证信息——凭证（credentials）、PIN 码等；
2. 可被用于身份盗窃的 PII——社会安全号码、信用卡号、银行账号、健康信息；
3. 可能识别出个人的设备标识符——device identifiers that may identify a person；
4. 高度敏感数据——一旦泄露将导致声誉损害和/或财务成本的数据；
5. 法律要求保护的数据——保护这些数据是法律义务；
6. 由应用（或其关联系统）生成、用于保护其他数据或系统自身的技术数据——例如加密密钥。

这六条清单覆盖了"身份凭证、个人隐私、设备指纹、商业机密、合规义务、技术防护材料"六个维度，恰好与 MASVS-STORAGE（数据存储）、MASVS-CRYPTO（密码学）、MASVS-PRIVACY（隐私）等控制领域的关注点一一呼应。在仓库中，该清单是诸多测试用例的判定依据——例如 iOS 存储测试 MASTG-TEST-0052 在静态分析阶段要求识别应用"保存和处理的全过程敏感数据，包括口令、密钥和 PII，也可能包括行业法规、法律和公司政策认定的其他敏感数据"。

从定义到判定：敏感数据在测试中的落地路径

前置条件引用：测试如何依赖数据定义

在 MASTG 仓库的测试用例元数据中，prerequisites: [identify-sensitive-data]是一条被高频引用的前置声明。仅tests-beta目录下就有大量用例依赖它，覆盖 Android 与 iOS 的存储、平台交互、密码学、隐私等领域，例如：

• MASTG-TEST-0287：SharedPreferences 明文存储检测；
• MASTG-TEST-0207：内部存储文件动态审计；
• MASTG-TEST-0319：隐私相关的数据收集审计。

这套引用机制说明：敏感数据定义不是孤立的理论章节，而是测试执行链的第一个环节。测试人员在运行任何存储、内存或隐私类用例之前，都应先完成本文的识别工作，否则后续的"观察"与"评估"步骤将缺乏可判定的输入。

可复用的识别工作流

综合原文档与仓库中的配套实践，可以提炼出如下可操作的五步工作流：

1. 确认组织级定义：向客户或开发团队索取数据分类策略；若存在，以其为唯一定义来源；
2. 建立默认清单：无策略时，直接采用上文六条通用敏感数据清单作为基线；
3. 映射三种状态：将清单中的每个数据项映射到"静态存储 / 使用中 / 传输中"三种状态，逐一确认其落点（哪个文件、哪个 API、哪条网络链路）；
4. 评估暴露面与审查强度：按数据重要性与被访问可能性分配测试资源，优先覆盖内存（物理可达、易转储）与明文落盘等高暴露场景；
5. 形成测试基线：将定义写入测试计划，作为所有存储、内存、隐私类用例的判定输入，并同步给开发团队，保证双方对"什么算敏感"认知一致。

判定示例：一个明确的测试结论

以 MASTG-TEST-0287 的评估逻辑为例，可以直观看到定义如何转化为结论：

1. 高层调用链检查：审查 hook 输出，判断SharedPreferences.Editor.putString/putStringSet调用之前是否有Cipher操作——未加密的写入意味着明文存储；
2. 模式匹配：使用密钥/机密检测工具（如 MASTG-TOOL-0144）扫描输出中的已知机密模式（API 密钥、令牌、口令、私钥）；
3. 人工核验：借助堆栈跟踪定位到逆向出的代码位置，追溯被写入值的来源，确认其是否属于测试前定义的敏感数据类别。

只有"值属于敏感数据"且"写入前未加密"两个条件同时成立，用例才判定为失败。这正是"先定义、后判定"的直接体现——没有第一步的数据定义，第三步的人工核验将无从谈起。

常见误区的边界提示

在界定敏感数据时，还应注意与安全相关上下文识别的配合，避免两个方向的偏差，详见 identify-security-relevant-contexts.md：

• 过度泛化：并非所有随机数、所有哈希、所有编码都涉及敏感数据。游戏中的洗牌随机数、用于统计分析的屏幕分辨率哈希、可逆的 Base64 编码本身都不是安全缺陷；只有当它们服务于认证、加密密钥生成、敏感数据保护等安全相关上下文时才是问题。
• 漏判：把编码（encoding）误当成加密（encryption），从而放过真正需要机密性保护的数据，是测试中常见的方向性错误。
• 存储与用途结合判断：API 令牌明文存储是否构成风险，取决于令牌的权限——只读公共 API 的令牌风险较低，而敏感或可写 API 的令牌明文存储则是严重问题。

这些边界提示与本文的数据分类框架互为补充：数据敏感性的判定，既要看数据本身，也要看它所处的上下文与用途。

小结

敏感数据识别是 OWASP MASTG 测试方法论的第一环，其核心结论可以概括为三点：

1. 定义先行：由于行业、国家与组织策略的差异，"敏感数据"没有放之四海而皆准的定义，必须在测试开始前由组织策略或通用清单确定；
2. 按状态审查：数据在静态存储、使用中、传输中三种状态下的暴露面不同，审查强度应与数据重要性和被访问可能性匹配，内存场景尤需严格；
3. 清单兜底：在没有分类策略时，六类通用敏感数据（认证信息、可被滥用身份盗窃的 PII、设备标识符、高敏感数据、法定保护数据、加密密钥等技术防护材料）提供了可直接采用的基线。

在 MASTG 仓库中，这条前置知识与 identify-first-party-domains.md、identify-security-relevant-contexts.md 共同构成测试范围判定的三件套，并通过prerequisites元数据被大量存储、隐私、密码学测试用例引用。建议测试人员在每个测试项目启动时，先将本文的识别工作流固化为项目基线文档，再进入 Document/0x04b-Mobile-App-Security-Testing.md 所描述的"情报收集—应用映射—利用—报告"完整测试流程。

• 文档
• 教程
• 网络安全