- 文档
- 教程
- 网络安全
【免费下载链接】mastg
The OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the OWASP Mobile Security Weakness Enumeration (MASWE) weaknesses, which are in alignment with the OWASP MASVS.
本文基于 OWASP MASTG（Mobile Application Security Testing Guide）的测试用例 MASTG-TEST-0226，讲解如何在 Android 应用静态分析中检查AndroidManifest.xml的android:debuggable标志：如何提取并解码清单文件、用什么命令读取该标志、如何判定true/false/缺省三种状态，以及命中后的修复建议和加固边界。读完本文，你可以独立对任意 APK 完成这项 RESILIENCE 类别（MASWE-0063）的合规检查。
为什么检查debuggable标志
测试用例 MASTG-TEST-0226 的目标是：检查应用是否将android:debuggable标志设为true。当该标志开启时，应用允许被附加调试器，攻击者因此可以：
- 检查应用内部状态（变量、内存、运行时行为）；
- 绕过安全控制（如断点绕过反调试逻辑）；
- 操纵运行时行为（如改写关键返回值）。
需要强调的是，按用例原文的界定：debuggable为true本身不被视为直接漏洞，但它显著扩大了攻击面——它让攻击者获得了对应用数据与资源的非授权访问，在生产环境中尤其危险。
从 MASTG-KNOW-0007 的知识条目看，调试机制的底层依据是：每个开启了调试的进程都会额外运行一个处理JDWP（Java Debug Wire Protocol）协议报文的线程，而该线程只在 Android Manifest 的Application元素带有android:debuggable="true"属性的应用中启动。也就是说，这个标志直接决定了进程是否向 JDWP 调试器敞开大门。
前置步骤一：提取并解码 AndroidManifest.xml
测试步骤第 1 条要求使用技术 MASTG-TECH-0117（从 AndroidManifest 获取信息）。由于AndroidManifest.xml在 APK 中以二进制 XML格式存储，直接解压 APK 拿不到可读内容，必须先解码。该技术文档给出了三种主流工具的做法：
1. 使用 jadx
用--no-src参数只提取资源而不反编译全部源码：
jadx --no-src -d out_dir MASTG-DEMO-0001.apkjadx 会将完整的清单输出到out_dir/resources/AndroidManifest.xml，并且包含<uses-sdk>元素（这是它区别于 apktool 的特点）：
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" ...> <uses-sdk android:minSdkVersion="29" android:targetSdkVersion="35" />2. 使用 apktool
apktool d -s -f -o output_dir MASTG-DEMO-0001.apk-s跳过 dex 文件的 baksmali 反汇编，速度更快。解码后的清单位于output_dir/AndroidManifest.xml。
一个容易困惑的细节：用 apktool 解码后，解码出的AndroidManifest.xml中可能看不到<uses-sdk>元素。这是预期行为——apktool 会把minSdkVersion、targetSdkVersion移到单独的apktool.yml文件中：
sdkInfo: minSdkVersion: 29 targetSdkVersion: 353. 使用 aapt2（只关心个别取值时）
aapt2 d badging MASTG-DEMO-0001.apk注意aapt2 的输出不是 XML 文件，而是自定义的解码格式，例如：
package: name='org.owasp.mastestapp' versionCode='1' versionName='1.0' ... sdkVersion:'29' targetSdkVersion:'35' uses-permission: name='android.permission.INTERNET'前置步骤二：读取debuggable标志
测试步骤第 2 条要求使用技术 MASTG-TECH-0150（分析 AndroidManifest）来定位该标志。这里有一个关键点：不同提取工具的输出格式不同，直接影响检索写法：
- jadx、apktool 输出标准 XML，属性带
android:命名空间前缀（如android:debuggable="true"）； - aapt2 输出自定义解码格式（非 XML），命名约定不同（如
application-debuggable）。
方法 1：grep 检索 XML 输出
对 jadx/apktool 解码出的 XML 清单执行：
grep -i "android:debuggable" output_dir/AndroidManifest.xml当标志被显式设置时，输出形如：
android:debuggable="true"如果该属性不存在，则标志在 release 构建中默认为false。
方法 2：aapt2 直接查询
无需先解包清单：
aapt2 d badging app.apk | grep -i debuggable标志被设置时的示例输出：
application-debuggable如果该行为空（缺失），说明标志未设置（默认为false）。
方法 3：xmlstarlet / xmllint 做结构化查询
对提取出的 XML 清单进行结构化属性查询：
xmlstarlet sel -t -v "//application/@android:debuggable" -n output_dir/AndroidManifest.xml观察与判定准则（Observation / Evaluation）
用例对结果的观察与判定标准如下，务必逐条对照：
观察（Observation）：输出应明确显示debuggable标志是否被设置（true或false）。如果标志未指定，release 构建下按false处理。
判定（Evaluation）：当且仅当debuggable标志被显式设置为true时，该测试用例失败——这表明应用被配置为允许调试，在生产环境中是不合适的。
整理成决策表：
| 清单中的状态 | aapt2 输出 | 判定 |
|---|---|---|
android:debuggable="true" | application-debuggable | 失败（生产环境不应可调试） |
android:debuggable="false" | 无该行 | 通过 |
| 属性缺省 | 无该行 | 通过（release 构建默认false） |
规则化的自动化检测
仓库中的 Semgrep 规则 mastg-android-debuggable-flag.yml 将上述检查固化为可重复执行的静态检测，它针对 XML 语言匹配如下模式，命中即报 WARNING 级别告警：
rules: - id: mastg-android-debuggable-flag severity: WARNING languages: - xml metadata: summary: This rule inspects the AndroidManifest.xml for the debuggable flag. message: "[MASVS-RESILIENCE-4] debuggable detected as $ARG." patterns: - pattern: 'android:debuggable="$ARG"'该规则会把实际取值（$ARG）带入告警信息，正好对应用例中"输出应明确显示标志取值"的观察要求，可以在 CI 流水线中对清单文件做回归检测。
修复建议与加固边界
直接修复：release 构建必须禁用
对应最佳实践 MASTG-BEST-0007（alias:debuggable-flag-disabled）：所有 release 构建必须将AndroidManifest.xml中的debuggable标志设为false。常规做法是在 Gradle 构建类型中显式关闭（release类型不继承debug的debuggable true），并确保 CI 不会误用 debug 构建产物发布。
加固边界：标志不是终局防线
MASTG-BEST-0007 特别指出一个容易被忽视的边界：
通过
debuggable标志禁用调试是重要的第一步，但不能完全保护应用免受高级攻击。有经验的攻击者可以通过多种手段实现调试能力，例如：
- 二进制补丁（binary patching）（参见 MASTG-TECH-0038）来允许附加调试器；
- 使用二进制插桩工具（如 Frida）达到类似能力。
对安全等级要求更高的应用，应考虑把反调试技术作为额外的防御层，并参考 MASWE-0064 获取详细指导。
换句话说，debuggable=false消除的是"最低成本"的调试入口，但进程级的 JDWP 附加能力仍可能被离线补丁等手段恢复，因此它应视为纵深防御的第一层，而非唯一一层。
与相邻测试用例的区分
检查调试面时容易把两个独立的机制混淆，MASTG 将其拆分为相邻用例：
- 本用例（MASTG-TEST-0226）：Manifest 中的
android:debuggable（对应ApplicationInfo.FLAG_DEBUGGABLE），控制整个进程是否可被附加调试器； - MASTG-TEST-0227：代码中的
WebView.setWebContentsDebuggingEnabled(true)，控制 WebView 的远程调试。该 API独立于debuggable属性生效——即使应用未标记为可调试，只要代码调用了该 API，WebView 仍可被 PC 端调试、抓包与修改通信内容，因此需要单独做代码层检索。
两者的关联文档同属 tests-beta/android/MASVS-RESILIENCE 目录，且都映射到 MASWE-0063，建议在评估中一起执行，避免只查 Manifest 而漏掉 WebView 调试入口。
小结
MASTG-TEST-0226 是一条典型的静态清单检查：用 jadx/apktool/aapt2 任一工具取得可读的AndroidManifest.xml（MASTG-TECH-0117），用 grep/aapt2/xmlstarlet 提取debuggable取值（MASTG-TECH-0150），按"显式true即失败、缺省视为false"判定；命中后按 MASTG-BEST-0007 在 release 构建中禁用调试，并理解这只是纵深防御的第一层——补丁与插桩仍可恢复调试能力，更高安全等级需要叠加反调试措施。
- 文档
- 教程
- 网络安全
【免费下载链接】mastg
The OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the OWASP Mobile Security Weakness Enumeration (MASWE) weaknesses, which are in alignment with the OWASP MASVS.
相关推荐
MASTG Android 静态测试详解：检测 WebView 中 Content Provider 访问风险（MASTG-TEST-0250）
MASTG Android 静态测试详解：检测 WebView 中 Content Provider 访问风险（MASTG TEST 0250） 本篇指南基于
文档教程网络安全使用 semgrep 检测 AndroidManifest 中的 debuggable 标志：MASTG-DEMO-0040 实战解析
使用 semgrep 检测 AndroidManifest 中的 debuggable 标志：MASTG DEMO 0040 实战解析 本篇文章以 OWASP
文档教程网络安全OWASP MASTG 实战：使用 semgrep 静态检测 AndroidManifest 中的危险权限（MASTG-DEMO-0033）
OWASP MASTG 实战：使用 semgrep 静态检测 AndroidManifest 中的危险权限（MASTG DEMO 0033） 本文围绕 OWAS
文档教程网络安全
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
