- 文档
- 教程
- 网络安全
【免费下载链接】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)的 Android 测试体系中,MASTG-TEST-0374 对应 MASWE-0032(隐式 Intent 携带敏感 Extras),覆盖 MASVS-CODE 类别:它要求审查 App 是否存在“创建隐式 Intent、附加敏感 extra、再不加限制地分发”的代码路径。读完本篇,你将掌握该测试的风险模型、完整的静态检测流程(含 semgrep 规则与命令)、对检测输出的逐字段观察方法、判定标准,以及配套的最佳实践修复方案。
1. 背景知识:显式 Intent 与隐式 Intent
本测试的理论基础是 MASTG-KNOW-0025(Explicit vs Implicit Intents)。Intent是 Android 的 IPC 消息对象,支持启动 Activity、启动 Service、发送广播三类场景。Android 提供两种 Intent:
- 显式 Intent:直接指定目标组件的包名或完整类名,只能投递给目标组件,无法被第三方 App 通过意图解析拦截:
Intent downloadIntent = new Intent(this, DownloadActivity.class); downloadIntent.setAction("android.intent.action.GET_CONTENT"); startActivityForResult(downloadIntent);- 隐式 Intent:不命名具体组件,只声明 action(以及可选的 data、categories),由系统通过意图解析机制匹配已安装的、声明了相应
<intent-filter>的组件。
意图解析(Intent Resolution)的核心匹配条件是:
- Action:filter 必须声明与 Intent 相同的 action 字符串;
- Category:Intent 中的所有 category 必须都出现在 filter 中(filter 可额外声明);
- Data:URI 的 scheme、host、path 与 MIME type 必须满足 filter 中
<data>的约束。
解析结果多于一个组件时,Android 弹出 chooser/消歧对话框由用户选择;仅一个匹配时直接路由。
注意(来自 MASTG-KNOW-0025):如果 App 将 targetSdk 提升到 Android 14(API 34)及以上,隐式 Intent 将永远不会被路由到应用内部组件,系统强制内部通信改用显式 Intent。这降低了 App 内部组件被隐式 Intent 触发/窃取的窗口,但不改变隐式 Intent 可被任意第三方组件接收 extras 的事实——只要对方声明了匹配的
<intent-filter>。
2. 风险模型:敏感数据如何随 extras 流向不受信应用
App 在业务中经常用隐式 Intent 携带 extras 向其他应用委托数据:ACTION_SEND分享用户选定内容、为外部查看器附加元数据、或弹出 chooser 让用户选择接收方,这些都是合理用法。
问题出现在附加了敏感或安全相关的 extras 却没有约束接收方时。意图解析阶段,任何已安装且声明了匹配<intent-filter>的 App 都可能成为选中接收方,并拿到完整的 extrasBundle。可能泄漏的数据包括:
- 凭据、会话令牌(session token)
- 一次性验证码(OTP)
- 个人信息、账户标识符
- 内部状态或内部命令
其影响可以是隐私泄漏、会话劫持、账户接管,或对后端 API 的未授权使用。
3. 测试执行步骤(Steps)
MASTG-TEST-0374 的类型为static、code、manual,执行分三步:
- 逆向工程:使用 MASTG-TECH-0013(Reverse Engineering Android Apps)将 APK 反编译。该技术指出需要同时处理 Java 字节码与 native 代码(JNI 常被用于混淆),并给出后续工具链(如 jadx)方向。
- 静态分析定位相关 API:使用 MASTG-TECH-0014(Static Analysis on Android)查找以下相关代码模式:
- 用 action 构造
Intent(即隐式 Intent 特征:无Class参数、无setPackage/setComponent); - 通过
putExtra、putExtras、replaceExtras或Bundle添加 extras; - 通过
startActivity、startActivityForResult、ActivityResultLauncher.launch、startService、bindService、sendBroadcast等 API 分发。
- 用 action 构造
- 人工复核:对每个命中点使用 MASTG-TECH-0023(Reviewing Decompiled Java Code)在反编译代码中逐处检查。
4. 实战演示:semgrep 规则 + 示例代码
仓库提供了直接对应本测试的可运行演示 MASTG-DEMO-0138(Leaking Sensitive Information via Implicit Intents,判定为 fail),它复用 MASTG-DEMO-0136 的示例 App。
4.1 示例代码(Kotlin 原文)
示例代码 MastgTest.kt 构造了一个隐式 Intent,action 为自定义的org.owasp.mastestapp.INTERNAL_ACTION,并附加user_id与session_token两个敏感 extra:
// FAIL: [MASTG-TEST-0372] The app uses an implicit intent to start an internal activity. val implicitIntent = Intent().apply { action = "org.owasp.mastestapp.INTERNAL_ACTION" putExtra("user_id", "12345") putExtra("session_token", "abcde-fghij-12345") addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) } try { context.startActivity(implicitIntent) r.add(Status.FAIL, "Launched internal activity via implicit intent") } catch (e: Exception) { r.add(Status.ERROR, e.toString()) }同文件还保留了被注释掉的 PASS 写法(显式 Intent),可作为修复参照:
val explicitIntent = Intent(context, InternalActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) } context.startActivity(explicitIntent)4.2 静态检测规则
仓库内置的 semgrep 规则 rules/mastg-android-implicit-intent-leaking-extras.yml 完整内容如下:
rules: - id: mastg-android-implicit-intent-leaking-extras patterns: - pattern: | $I = new Intent(...); ... $I.putExtra($KEY, $VAL); ... $CTX.startActivity($I); - pattern-not: | $I = new Intent($C, $CLASS); ... - pattern-not: | $I = new Intent(...); ... $I.setPackage(...); ... $CTX.startActivity($I); - pattern-not: | $I = new Intent(...); ... $I.setComponent(...); ... $CTX.startActivity($I); message: "[MASVS-CODE-4] The app sends an implicit intent with extras. Any app that registers for this action can receive the data. Use explicit intents for internal communication." languages: [java] severity: WARNING metadata: summary: Detects implicit intents that carry extras without specifying a target package or component.从规则结构看,它的匹配逻辑是:命中“new Intent(...)+putExtra+startActivity”的序列,同时用三个pattern-not排除三类安全写法——显式Intent(context, Class)构造、setPackage限定包名、setComponent限定组件。severity 为WARNING,消息标注[MASVS-CODE-4]。需要注意该规则只覆盖java语言的静态模式且只匹配startActivity分发路径,putExtras/Bundle/sendBroadcast等其余模式需结合人工审查补齐(这也正是测试类型包含manual的原因)。
4.3 运行命令与输出
演示脚本 run.sh 对 DEMO-0136 的反编译 Java 代码执行 semgrep:
NO_COLOR=true semgrep --config ../../../../rules/mastg-android-implicit-intent-leaking-extras.yml ../MASTG-DEMO-0136/MastgTest_reversed.java --text > output.txt实际输出(output.txt):
┌────────────────┐ │ 1 Code Finding │ └────────────────┘ MastgTest_reversed.java ❯❱ rules.mastg-android-implicit-intent-leaking-extras [MASVS-CODE-4] The app sends an implicit intent with extras. Any app that registers for this action can receive the data. Use explicit intents for internal communication. 22┆ Intent implicitIntent = new Intent(); 23┆ implicitIntent.setAction("org.owasp.mastestapp.INTERNAL_ACTION"); 24┆ implicitIntent.putExtra("user_id", "12345"); 25┆ implicitIntent.putExtra("session_token", "abcde-fghij-12345"); 26┆ implicitIntent.addFlags(268435456); 27┆ try { 28┆ this.context.startActivity(implicitIntent);5. 观察(Observation):检测输出应包含的字段
测试文档要求静态分析的输出覆盖每个“创建 Intent + 附加 extras + 分发”的位置,且尽可能包含以下信息:
- 代码位置/调用方(code location or caller);
- Intent 创建模式(
new Intent(...)的构造形式); - action、data、type、categories的取值;
- extra 的键值对;若值在静态视角下不可见,则给出 extras 的来源(数据流上游);
- 分发 API(
startActivity、startActivityForResult、ActivityResultLauncher.launch、startService、bindService、sendBroadcast等); - 分发前可见的目标限定调用,例如
setPackage、setClass、setClassName、setComponent、显式Intent(context, Class)构造器,或广播接收方的权限声明。
上节 DEMO-0138 的输出即满足该结构:创建为new Intent(),action 为org.owasp.mastestapp.INTERNAL_ACTION,extra 键值user_id=12345、session_token=abcde-fghij-12345,分发 API 为startActivity,且无任何目标限定调用。
6. 评估(Evaluation)与进一步验证清单
判定标准:当隐式 Intent 携带敏感或安全相关的 extras,且其他 App 可以声明或注册匹配的组件来接收它们时,该测试用例失败。
对每个命中点需按以下清单人工验证(MASTG-TEST-0374 原文):
- 检查该 Intent 是否具有显式组件或包名限定;
- 检查其他 App 能否为相同的 action/data/categories 声明或注册匹配的
<intent-filter>; - 对广播(broadcast)场景,检查发送方是否要求了可阻止不受信接收者接收的发送方权限;
- 检查 extras 是否包含凭据、令牌、会话标识符、一次性验证码、个人信息、账户标识符、内部命令或其他安全相关数据;
- 检查该分发是否属于用户主动选择的分享/打开流程(如
ACTION_SEND或 chooser)——若是,风险定性需结合用户知情同意重新评估。
仓库中 MASTG-DEMO-0140 提供了一个攻击者 App 示例:它声明匹配org.owasp.mastestapp.INTERNAL_ACTION的<intent-filter>,演示了第三方组件如何在意图解析阶段成为候选接收方并拿走 extras,可直接用于验证清单第 2 条。
7. 修复与加固建议
7.1 内部通信改用显式 Intent(MASTG-BEST-0056)
本测试关联的最佳实践 MASTG-BEST-0056(Use Explicit Intents for Internal IPC)给出两种显式化写法:
// Explicit by package - restricts delivery to your own app val intent = Intent("com.example.app.PROCESS_DATA").apply { setPackage("com.example.app") putExtra("key", "value") } startActivity(intent) // Explicit by component - the most restrictive form val intent = Intent(context, TargetActivity::class.java).apply { putExtra("key", "value") } startActivity(intent)该最佳实践还给出两条硬性规则:绝不在隐式 Intent 中传输敏感数据(令牌、凭据、API 密钥);内部组件在 AndroidManifest.xml 中不应被意外暴露给其他应用(详见 MASTG-BEST-0052 关于 Manifest 加固的说明)。
7.2 组合性防护要点
结合 MASTG-KNOW-0025 的组件可见性说明,可形成如下加固组合:
- 用
setPackage/setComponent/Intent(context, Class)收敛分发范围(最彻底的是显式组件构造); - 内部组件的
<intent-filter>避免exported="true";必须导出时以android:permission加锁; - 广播场景为
sendBroadcast传入发送方自定义权限; - 将 targetSdk 提升至 34+,借助 Android 14 的“隐式 Intent 不路由到内部组件”行为强制内部通信显式化(注意:这是行为变化,App 内部若仍依赖隐式 Intent 启动自身组件,功能会失效,需同步修改代码);
- 将
rules/mastg-android-implicit-intent-leaking-extras.yml这类 semgrep 规则纳入 CI 静态检查,对putExtra+ 无目标限定的分发路径持续告警。
8. 小结
MASTG-TEST-0374 的检测链条是:逆向(TECH-0013)→ 静态分析定位“隐式 Intent + extras + 分发 API”代码位点(TECH-0014,可用仓库内置 semgrep 规则)→ 按 Observation 六要素逐条核对 → 按 Evaluation 五项清单人工验证 → 依据 MASWE-0032 判定。核心结论只有一条:隐式 Intent 的 extras 属于“广播给所有匹配组件”的数据,凡携带敏感内容就必须用setPackage/setComponent/显式构造收敛接收方,或彻底避免在 extras 中放置安全敏感数据。
仓库内相关资源索引:
| 资源 | 路径 |
|---|---|
| 测试用例 | tests-beta/android/MASVS-CODE/MASTG-TEST-0374.md |
| 背景知识 | knowledge/android/MASVS-PLATFORM/MASTG-KNOW-0025.md |
| semgrep 规则 | rules/mastg-android-implicit-intent-leaking-extras.yml |
| 失败示例演示 | demos/android/MASVS-CODE/MASTG-DEMO-0138/MASTG-DEMO-0138.md |
| 示例源码 | demos/android/MASVS-CODE/MASTG-DEMO-0136/MastgTest.kt |
| 攻击者 App 演示 | demos/android/MASVS-CODE/MASTG-DEMO-0140 |
| 修复最佳实践 | best-practices/MASTG-BEST-0056.md |
- 文档
- 教程
- 网络安全
【免费下载链接】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.
相关推荐
Eclipse Mosquitto 2.0.9 版本解析:CA 证书校验漏洞修复与 Broker 行为修正详解
Eclipse Mosquitto 2.0.9 版本解析:CA 证书校验漏洞修复与 Broker 行为修正详解 2021 年 3 月 11 日,Eclipse
文档教程网络安全用 semgrep 揪出 Android 隐式 Intent 泄漏:OWASP MASTG MASTG-DEMO-0138 实战指南
用 semgrep 揪出 Android 隐式 Intent 泄漏:OWASP MASTG MASTG DEMO 0138 实战指南 本篇技术指南聚焦 OWAS
文档教程网络安全用 OWASP MASTG 检测 Android 通知中的敏感数据泄露:MASTG-DEMO-0078 静态分析实战
用 OWASP MASTG 检测 Android 通知中的敏感数据泄露:MASTG DEMO 0078 静态分析实战 导读 通知(Notification)是
文档教程网络安全
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考