尧图网页设计 
文档教程网络安全【免费下载链接】mastgThe 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.项目地址https://gitcode.com/gh_mirrors/ow/mastg点击查看免费下载MASTG-DEMO-0136 是 OWASP MASTG 仓库中一个刻意构造的反面教材一个 Android 应用通过setAction(org.owasp.mastestapp.INTERNAL_ACTION)发送隐式 Intent来启动自己的内部 Activity并把user_id、session_token等敏感数据放进 Intent extras。本文将以该样本为主体完整拆解不安全实现、Android 的 Intent 解析机制、基于 semgrep 规则的静态检测流程、测试判定逻辑MASTG-TEST-0372以及最终改用显式 Intent 的修复方案MASTG-BEST-0056让读者掌握内部通信必须显式指定目标组件/包名这一 Android 安全红线及其可落地的检测手段。一、背景知识显式 Intent 与隐式 Intent 的本质区别要理解这个样本为什么不安全首先要明确 Android 中两种 Intent 的根本差异。仓库中的知识文档 MASTG-KNOW-0025 给出了精确定义显式 IntentExplicit Intent直接指定处理该 Intent 的目标应用包名或完整组件类名。调用方明确知道目标 Activity/Service 是谁因此 Intent 只会被送达这一个组件。典型写法为Intent(context, DownloadActivity::class.java)。隐式 IntentImplicit Intent不指名任何具体组件只声明 action以及可选的 data、category。系统需要把 Intent 与所有已安装应用中声明了intent-filter的组件进行意图解析Intent Resolution匹配结果才决定最终投递给谁。Intent 解析的匹配规则当系统收到一个隐式 Intent 时会按照文档中描述的解析算法逐项比较匹配维度规则Actionintent-filter必须声明与 Intent 完全相同的 action 字符串CategoryIntent 中的全部 category 必须出现在 filter 中filter 可额外声明更多 categoryDataURI 的 scheme、host、path 以及 MIME type 必须满足 filter 中data的约束匹配结果分两种情况若只有一个组件命中系统直接把 Intent 路由过去若命中多个组件系统会弹出 chooser应用选择器/歧义对话框让用户挑选或遵循已设置的默认处理器。这正是隐式 Intent 内部通信的致命漏洞所在——任何第三方应用只要声明一个匹配的intent-filter就会成为候选接收方。此外MASTG-KNOW-0025 还记录了一个重要的平台演进事实当应用以 Android 14API level 34及以上为目标平台时系统保证隐式 Intent永远不会投递给应用的内部组件这迫使开发者必须为内部通信实现显式 Intent否则应用自身功能都无法正常工作。二、样本剖析不安全实现的完整代码全貌MASTG-DEMO-0136 样本位于 demos/android/MASVS-CODE/MASTG-DEMO-0136/由 Kotlin 源码、Manifest、反编译 Java、检测脚本与输出五部分组成。2.1 Kotlin 源码隐式 Intent 发起内部通信MastgTest.kt 是样本的核心。它先构造一个没有任何目标组件信息的空Intent仅通过setAction指定自定义 action再塞入两个敏感 extras最后以context.startActivity(implicitIntent)派发package org.owasp.mastestapp import android.content.Context import android.content.Intent // SUMMARY: This sample demonstrates the insecure use of implicit intents for internal communication. class MastgTest (private val context: Context){ fun mastgTest(): String { val r DemoResults(0x01) // 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: [MASTG-TEST-0372] The app uses an explicit intent for internal communication. val explicitIntent Intent(context, InternalActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) } try { context.startActivity(explicitIntent) r.add(Status.PASS, Launched internal activity via explicit intent) } catch (e: Exception) { r.add(Status.ERROR, e.toString()) } */ return r.toJson() } }代码中有几个值得注意的细节Intent 构造方式Intent()空构造 setAction没有setPackage、setClass、setComponent或Intent(context, Class)构造函数因此从意图解析的角度看它没有任何目标限定。敏感 extrasuser_id与session_token被直接放进 extras。一旦 Intent 被第三方应用接收这些数据将完整泄露给攻击者。FLAG_ACTIVITY_NEW_TASK由于该示例在非 Activity 上下文中启动 Activity需要此 flag对应十进制值268435456即0x10000000来在新任务栈中启动目标。对照修复代码源码中注释保留了一段 PASS 分支展示正确写法——Intent(context, InternalActivity::class.java)显式指定目标类。同一文件末尾还定义了目标组件InternalActivity一个仅显示 Internal Activity 文本的极简 Activityclass InternalActivity : android.app.Activity() { override fun onCreate(savedInstanceState: android.os.Bundle?) { super.onCreate(savedInstanceState) val textView android.widget.TextView(this) textView.text Internal Activity textView.textSize 24f textView.gravity android.view.Gravity.CENTER setContentView(textView) } }2.2 Manifest内部组件对外暴露的关键开关AndroidManifest.xml 揭示了问题成立的第二个条件——InternalActivity被声明为android:exportedtrue且带有匹配自定义 action 的intent-filter?xml version1.0 encodingutf-8? manifest xmlns:androidhttp://schemas.android.com/apk/res/android application activity android:nameorg.owasp.mastestapp.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity !-- Internal activity with an intent-filter, making it a resolver candidate -- activity android:nameorg.owasp.mastestapp.InternalActivity android:exportedtrue intent-filter action android:nameorg.owasp.mastestapp.INTERNAL_ACTION / category android:nameandroid.intent.category.DEFAULT / /intent-filter /activity /application /manifest这里的组合十分微妙InternalActivity本意是内部组件却同时满足了两个使它外部可达的条件——exportedtrue允许其他应用直接启动它而intent-filter使它可以作为隐式 Intent 的解析候选。也就是说它既能接收本应用发出的隐式 Intent也完全能被其他应用发出的同 action 隐式 Intent 命中。整个场景构成了双向的暴露面。2.3 反编译视角恶意分析者眼中的样子AndroidManifest_reversed.xml 是 APK 反编译后的完整 Manifest补充了样本的编译环境信息compileSdkVersion35、minSdkVersion29、targetSdkVersion35并确认InternalActivity的android:exportedtrue与 intent-filter 在打包后原样保留。而 MastgTest_reversed.java 是 Kotlin 反编译回 Java 的产物展示了恶意分析者实际会看到的形态public final String mastgTest() { DemoResults r new DemoResults(0x01); Intent implicitIntent new Intent(); implicitIntent.setAction(org.owasp.mastestapp.INTERNAL_ACTION); implicitIntent.putExtra(user_id, 12345); implicitIntent.putExtra(session_token, abcde-fghij-12345); implicitIntent.addFlags(268435456); try { this.context.startActivity(implicitIntent); r.add(Status.FAIL, Launched internal activity via implicit intent); } catch (Exception e) { r.add(Status.ERROR, e.toString()); } return r.toJson(); }反编译代码把漏洞特征暴露得更加直白new Intent()之后只有setAction与putExtra从头到尾没有任何一次调用把 Intent 绑定到具体目标。addFlags(268435456)即前文提到的FLAG_ACTIVITY_NEW_TASK。这正是静态扫描工具最理想的检测目标——代码模式高度可识别。三、风险机理为什么隐式内部通信是危险的结合 MASTG-TEST-0372 的说明这个样本的危害链条可以总结为三步本应用发出隐式 Intentaction 为org.owasp.mastestapp.INTERNAL_ACTION携带user_id、session_token等敏感 extras未指定目标包名或组件。第三方应用声明匹配intent-filter任何恶意应用都能在自己的 Manifest 中声明同样的 action从而在 Android 意图解析阶段与本应用的InternalActivity一起成为候选。Intent 被劫持或泄露若系统弹出 chooser用户可能误选第三方应用若该 action 仅有恶意应用一个匹配项或已被设为默认处理器Intent 会未经用户明确决策直接送达攻击者extras 中的令牌与凭据随之泄露。需要特别强调的是这个漏洞并不依赖本应用的目标组件是否 exported——即使InternalActivity保持 exported攻击面在于接收方可以换人Intent 是广播式地被解析谁匹配谁接收而 app-specific 的自定义 action 并不具备任何保密性。测试文档明确将startActivity、startActivityForResult、ActivityResultLauncher.launch、startService、bindService、sendBroadcast等全部列为需要排查的派发 API凡是内部或可信组件间通信却未指名接收者的 Intent 都在违规之列。四、静态检测实战semgrep 规则扫描反编译代码样本配套提供了开箱即用的检测链路先反编译拿到 Java 代码再用 semgrep 规则扫描。对应的仓库资源为静态分析技术 MASTG-TECH-0014 与规则工具 MASTG-TOOL-0110。4.1 检测脚本run.sh 只有一行核心命令直接对反编译得到的MastgTest_reversed.java运行规则并捕获输出#!/bin/bash # SUMMARY: This script uses semgrep to detect implicit intents in the source code. NO_COLORtrue semgrep --config ../../../../rules/mastg-android-implicit-intent-internal-communication.yml MastgTest_reversed.java --text output.txt参数含义NO_COLORtrue关闭彩色输出以方便落盘--config指向仓库根目录下的 mastg-android-implicit-intent-internal-communication.yml--text以纯文本格式输出结果重定向到output.txt。实际测试时把MastgTest_reversed.java换成任意待测反编译文件即可复用。4.2 规则解析三个正模式与三个反模式这条 semgrep 规则是整个检测方案的灵魂它用一个命中模式 三个排除模式精确刻画隐式 Intent 内部通信rules: - id: mastg-android-implicit-intent-internal-communication patterns: - pattern: | $INTENT new Intent(...); ... $INTENT.setAction($ACTION); ... $CONTEXT.startActivity($INTENT); - pattern-not: | $INTENT new Intent(...); ... $INTENT.setPackage(...); ... $CONTEXT.startActivity($INTENT); - pattern-not: | $INTENT new Intent(...); ... $INTENT.setComponent(...); ... $CONTEXT.startActivity($INTENT); - pattern-not: | $INTENT new Intent($CONTEXT, $CLASS); ... $CONTEXT.startActivity($INTENT); message: [MASVS-CODE-4] The app uses an implicit intent for internal component communication. Use explicit intents by specifying the package or component. languages: [java] severity: WARNING metadata: summary: Detects implicit intents used for internal component communication without specifying a package or component.规则的设计逻辑非常清晰正模式new Intent(...)创建 →setAction(...)指定 action →startActivity(...)派发构成隐式 Intent 的完整生命周期...表示中间允许任意代码因此putExtra、addFlags等调用不影响匹配。反模式 1setPackage(...)—— 一旦按包名限定目标Intent 只能投递到该包内组件即显式化。反模式 2setComponent(...)—— 按组件名限定目标同样显式化。反模式 3Intent($CONTEXT, $CLASS)构造函数 —— 直接在构造时指定目标类这是最严格的显式形式。也就是说只有当创建 → 设 action → 派发完整出现且没有任何目标限定调用时规则才报出告警有效避免了大量显式 Intent 的误报。告警级别为 WARNING归属于 MASVS-CODE-4代码质量与构建配置类问题声明的语言为 Java——这正是反编译产物的形态。4.3 结果解读output.txt 记录了真实扫描结果共命中1 处代码发现┌────────────────┐ │ 1 Code Finding │ └────────────────┘ MastgTest_reversed.java ❯❱ rules.mastg-android-implicit-intent-internal-communication [MASVS-CODE-4] The app uses an implicit intent for internal component communication. Use explicit intents by specifying the package or component. 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); 29┆ r.add(Status.FAIL, Launched internal activity via implicit intent); 30┆ } catch (Exception e) { 31┆ r.add(Status.ERROR, e.toString()); 32┆ } [hid 1 additional lines, adjust with --max-lines-per-finding]告警精确地锚定在第 22–28 行把隐式 Intent 的完整构造与派发链new Intent()→setAction→ 两个putExtra→startActivity一行不漏地呈现给分析人员报告中的关键要素与样本文档的观察结论完全一致Intent 创建new Intent()Action 赋值implicitIntent.setAction(org.owasp.mastestapp.INTERNAL_ACTION)派发前加入的 extrasuser_id与session_token派发 APIthis.context.startActivity(implicitIntent)缺少目标限定整段代码中没有setPackage、setClass、setClassName、setComponent或显式Intent(context, Class)构造函数。这条检测链路可以无缝移植到真实项目对任意 APK 先做反编译对应技术 MASTG-TECH-0013再对全部反编译 Java 文件运行该规则即可批量发现内部通信误用隐式 Intent 的代码点。五、测试判定MASTG-TEST-0372 为何判 Fail本样本对应测试用例 MASTG-TEST-0372Implicit Intents Used for Internal App Communication元数据标记为type: [static, code, manual]关联弱点枚举MASWE-0032并分别关联最佳实践 MASTG-BEST-0056 与知识条目 MASTG-KNOW-0025。根据测试的判定标准若用于应用内部或可信组件通信的 Intent 是隐式的且其他应用可以声明或注册匹配组件来接收它则测试失败。在本样本中actionorg.owasp.mastestapp.INTERNAL_ACTION虽为应用自定义InternalActivity也在 Manifest 中被声明为预期处理者但报告出的派发点没有命名该组件也没有限定目标包其他应用完全可以通过声明匹配的intent-filter成为 Android 意图解析的候选。因此样本文档 MASTG-DEMO-0136.md 明确判定该用例Fail对应源码注释也标记为FAIL: [MASTG-TEST-0372]。此外测试文档还给出了进一步人工验证的要求配合 MASTG-TECH-0023 逐一检查报告位置检查 Intent 是否已带显式组件或包名检查其他应用是否能为该 action、data、categories 声明或注册匹配的intent-filter对于广播检查发送方是否要求了可阻止不可信接收者的权限确认该 Intent 是面向应用自身组件或可信应用而非有意交给用户选择的外部应用。其中第 2、4 条正是本样本 Fail 的直接依据——它面向自身InternalActivity却给了外部应用插手的余地。六、修复方案改用显式 IntentMASTG-BEST-0056正确的修复方向在源码的 PASS 注释分支里已经给出最佳实践 MASTG-BEST-0056 则提供了完整规范同应用内部组件间通信一律使用显式 Intent——显式指定目标组件后Intent 只能送达预期接收者第三方应用无法通过正常意图解析截获。6.1 Java/Kotlin 侧修复// 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)两种显式写法按限制强度递增setPackage(com.example.app)把投递范围锁死在本应用包内即使其他应用声明了同 action 的 filter 也无法接收Intent(context, TargetActivity::class.java)则直接指名目标类是最严格的形式。回到本样本只需把Intent().apply { action ... }替换为Intent(context, InternalActivity::class.java)即可消除漏洞同时照常携带 extras 与FLAG_ACTIVITY_NEW_TASK。最佳实践还特别强调了一条铁律绝不要把敏感数据令牌、凭据、API Key放进隐式 Intent。Android 通过匹配已安装应用声明intent-filter的方式解析隐式 Intent任何匹配应用都可能成为最终接收者并读到 extras——这正是本样本中user_id、session_token面临的处境。6.2 Manifest 侧加固对于内部组件还需确保它们没有被无意中暴露给其他应用。样本中InternalActivity的exportedtrue加上 intent-filter 属于典型的多余暴露——如果组件只供本应用使用应移除 intent-filter 并将exported设为false关于 Manifest 更系统的加固细节MASTG-BEST-0056 指向了专门条目 MASTG-BEST-0052 进行展开见 best-practices 目录。七、对照攻击样本MASTG-DEMO-0140 的接管演示为完整呈现威胁仓库还配套提供了攻击方视角的对照样本 MASTG-DEMO-0140该演示应用在自己的 Manifest 中声明了与org.owasp.mastestapp.INTERNAL_ACTION匹配的intent-filter从而成为本样本隐式 Intent 的解析候选。二者配套阅读可以直观验证另一个应用如何成为处理者候选的完整过程——这也是本样本文档中的 note 明确指引的实验路径。图 1 展示的就是这一时刻系统弹出的应用选择器界面。八、关联资源索引围绕本主题仓库中可继续深入阅读的材料均以仓库根目录为起点的相对路径样本文档demos/android/MASVS-CODE/MASTG-DEMO-0136/MASTG-DEMO-0136.md源码与反编译产物MastgTest.kt、MastgTest_reversed.java、AndroidManifest.xml、AndroidManifest_reversed.xml检测脚本与结果run.sh、output.txtsemgrep 规则rules/mastg-android-implicit-intent-internal-communication.yml测试用例tests-beta/android/MASVS-CODE/MASTG-TEST-0372.md最佳实践best-practices/MASTG-BEST-0056.md背景知识knowledge/android/MASVS-PLATFORM/MASTG-KNOW-0025.md攻击对照样本demos/android/MASVS-CODE/MASTG-DEMO-0140/MASTG-DEMO-0140.md总结而言MASTG-DEMO-0136 用最小化的代码演示了内部通信隐式化这一常见且高危的 Android 反模式显式 Intent 是内部 IPC 的默认选项setPackage/setComponent/组件构造器是强制约束手段而 semgrep 规则 反编译产物扫描则提供了一条低成本、可自动化的持续检测路径。对照攻击样本、测试用例与最佳实践读者可以在此样本基础上形成完整的发现—判定—修复—验证闭环能力。赞分享文档教程网络安全【免费下载链接】mastgThe 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.项目地址https://gitcode.com/gh_mirrors/ow/mastg点击查看免费下载相关推荐用 semgrep 揪出 Android 隐式 Intent 泄漏OWASP MASTG MASTG-DEMO-0138 实战指南用 semgrep 揪出 Android 隐式 Intent 泄漏OWASP MASTG MASTG DEMO 0138 实战指南 本篇技术指南聚焦 OWAS文档教程网络安全OWASP MASTG 实战Android 内部存储明文敏感数据检测MASTG-DEMO-0010 / MASTG-TEST-0207OWASP MASTG 实战Android 内部存储明文敏感数据检测MASTG DEMO 0010 / MASTG TEST 0207 导读 本文以 OW文档教程网络安全OWASP MASTG 最佳实践Android 内部 IPC 必须使用显式 IntentMASTG-BEST-0056OWASP MASTG 最佳实践Android 内部 IPC 必须使用显式 IntentMASTG BEST 0056 导读 本文是 OWASP Mobi文档教程网络安全创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OWASP MASTG 实战：Android 内部组件通信误用隐式 Intent 的风险检测与修复（MASTG-DEMO-0136 全解析）
文档教程网络安全【免费下载链接】mastgThe 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.项目地址https://gitcode.com/gh_mirrors/ow/mastg点击查看免费下载MASTG-DEMO-0136 是 OWASP MASTG 仓库中一个刻意构造的反面教材一个 Android 应用通过setAction(org.owasp.mastestapp.INTERNAL_ACTION)发送隐式 Intent来启动自己的内部 Activity并把user_id、session_token等敏感数据放进 Intent extras。本文将以该样本为主体完整拆解不安全实现、Android 的 Intent 解析机制、基于 semgrep 规则的静态检测流程、测试判定逻辑MASTG-TEST-0372以及最终改用显式 Intent 的修复方案MASTG-BEST-0056让读者掌握内部通信必须显式指定目标组件/包名这一 Android 安全红线及其可落地的检测手段。一、背景知识显式 Intent 与隐式 Intent 的本质区别要理解这个样本为什么不安全首先要明确 Android 中两种 Intent 的根本差异。仓库中的知识文档 MASTG-KNOW-0025 给出了精确定义显式 IntentExplicit Intent直接指定处理该 Intent 的目标应用包名或完整组件类名。调用方明确知道目标 Activity/Service 是谁因此 Intent 只会被送达这一个组件。典型写法为Intent(context, DownloadActivity::class.java)。隐式 IntentImplicit Intent不指名任何具体组件只声明 action以及可选的 data、category。系统需要把 Intent 与所有已安装应用中声明了intent-filter的组件进行意图解析Intent Resolution匹配结果才决定最终投递给谁。Intent 解析的匹配规则当系统收到一个隐式 Intent 时会按照文档中描述的解析算法逐项比较匹配维度规则Actionintent-filter必须声明与 Intent 完全相同的 action 字符串CategoryIntent 中的全部 category 必须出现在 filter 中filter 可额外声明更多 categoryDataURI 的 scheme、host、path 以及 MIME type 必须满足 filter 中data的约束匹配结果分两种情况若只有一个组件命中系统直接把 Intent 路由过去若命中多个组件系统会弹出 chooser应用选择器/歧义对话框让用户挑选或遵循已设置的默认处理器。这正是隐式 Intent 内部通信的致命漏洞所在——任何第三方应用只要声明一个匹配的intent-filter就会成为候选接收方。此外MASTG-KNOW-0025 还记录了一个重要的平台演进事实当应用以 Android 14API level 34及以上为目标平台时系统保证隐式 Intent永远不会投递给应用的内部组件这迫使开发者必须为内部通信实现显式 Intent否则应用自身功能都无法正常工作。二、样本剖析不安全实现的完整代码全貌MASTG-DEMO-0136 样本位于 demos/android/MASVS-CODE/MASTG-DEMO-0136/由 Kotlin 源码、Manifest、反编译 Java、检测脚本与输出五部分组成。2.1 Kotlin 源码隐式 Intent 发起内部通信MastgTest.kt 是样本的核心。它先构造一个没有任何目标组件信息的空Intent仅通过setAction指定自定义 action再塞入两个敏感 extras最后以context.startActivity(implicitIntent)派发package org.owasp.mastestapp import android.content.Context import android.content.Intent // SUMMARY: This sample demonstrates the insecure use of implicit intents for internal communication. class MastgTest (private val context: Context){ fun mastgTest(): String { val r DemoResults(0x01) // 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: [MASTG-TEST-0372] The app uses an explicit intent for internal communication. val explicitIntent Intent(context, InternalActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) } try { context.startActivity(explicitIntent) r.add(Status.PASS, Launched internal activity via explicit intent) } catch (e: Exception) { r.add(Status.ERROR, e.toString()) } */ return r.toJson() } }代码中有几个值得注意的细节Intent 构造方式Intent()空构造 setAction没有setPackage、setClass、setComponent或Intent(context, Class)构造函数因此从意图解析的角度看它没有任何目标限定。敏感 extrasuser_id与session_token被直接放进 extras。一旦 Intent 被第三方应用接收这些数据将完整泄露给攻击者。FLAG_ACTIVITY_NEW_TASK由于该示例在非 Activity 上下文中启动 Activity需要此 flag对应十进制值268435456即0x10000000来在新任务栈中启动目标。对照修复代码源码中注释保留了一段 PASS 分支展示正确写法——Intent(context, InternalActivity::class.java)显式指定目标类。同一文件末尾还定义了目标组件InternalActivity一个仅显示 Internal Activity 文本的极简 Activityclass InternalActivity : android.app.Activity() { override fun onCreate(savedInstanceState: android.os.Bundle?) { super.onCreate(savedInstanceState) val textView android.widget.TextView(this) textView.text Internal Activity textView.textSize 24f textView.gravity android.view.Gravity.CENTER setContentView(textView) } }2.2 Manifest内部组件对外暴露的关键开关AndroidManifest.xml 揭示了问题成立的第二个条件——InternalActivity被声明为android:exportedtrue且带有匹配自定义 action 的intent-filter?xml version1.0 encodingutf-8? manifest xmlns:androidhttp://schemas.android.com/apk/res/android application activity android:nameorg.owasp.mastestapp.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity !-- Internal activity with an intent-filter, making it a resolver candidate -- activity android:nameorg.owasp.mastestapp.InternalActivity android:exportedtrue intent-filter action android:nameorg.owasp.mastestapp.INTERNAL_ACTION / category android:nameandroid.intent.category.DEFAULT / /intent-filter /activity /application /manifest这里的组合十分微妙InternalActivity本意是内部组件却同时满足了两个使它外部可达的条件——exportedtrue允许其他应用直接启动它而intent-filter使它可以作为隐式 Intent 的解析候选。也就是说它既能接收本应用发出的隐式 Intent也完全能被其他应用发出的同 action 隐式 Intent 命中。整个场景构成了双向的暴露面。2.3 反编译视角恶意分析者眼中的样子AndroidManifest_reversed.xml 是 APK 反编译后的完整 Manifest补充了样本的编译环境信息compileSdkVersion35、minSdkVersion29、targetSdkVersion35并确认InternalActivity的android:exportedtrue与 intent-filter 在打包后原样保留。而 MastgTest_reversed.java 是 Kotlin 反编译回 Java 的产物展示了恶意分析者实际会看到的形态public final String mastgTest() { DemoResults r new DemoResults(0x01); Intent implicitIntent new Intent(); implicitIntent.setAction(org.owasp.mastestapp.INTERNAL_ACTION); implicitIntent.putExtra(user_id, 12345); implicitIntent.putExtra(session_token, abcde-fghij-12345); implicitIntent.addFlags(268435456); try { this.context.startActivity(implicitIntent); r.add(Status.FAIL, Launched internal activity via implicit intent); } catch (Exception e) { r.add(Status.ERROR, e.toString()); } return r.toJson(); }反编译代码把漏洞特征暴露得更加直白new Intent()之后只有setAction与putExtra从头到尾没有任何一次调用把 Intent 绑定到具体目标。addFlags(268435456)即前文提到的FLAG_ACTIVITY_NEW_TASK。这正是静态扫描工具最理想的检测目标——代码模式高度可识别。三、风险机理为什么隐式内部通信是危险的结合 MASTG-TEST-0372 的说明这个样本的危害链条可以总结为三步本应用发出隐式 Intentaction 为org.owasp.mastestapp.INTERNAL_ACTION携带user_id、session_token等敏感 extras未指定目标包名或组件。第三方应用声明匹配intent-filter任何恶意应用都能在自己的 Manifest 中声明同样的 action从而在 Android 意图解析阶段与本应用的InternalActivity一起成为候选。Intent 被劫持或泄露若系统弹出 chooser用户可能误选第三方应用若该 action 仅有恶意应用一个匹配项或已被设为默认处理器Intent 会未经用户明确决策直接送达攻击者extras 中的令牌与凭据随之泄露。需要特别强调的是这个漏洞并不依赖本应用的目标组件是否 exported——即使InternalActivity保持 exported攻击面在于接收方可以换人Intent 是广播式地被解析谁匹配谁接收而 app-specific 的自定义 action 并不具备任何保密性。测试文档明确将startActivity、startActivityForResult、ActivityResultLauncher.launch、startService、bindService、sendBroadcast等全部列为需要排查的派发 API凡是内部或可信组件间通信却未指名接收者的 Intent 都在违规之列。四、静态检测实战semgrep 规则扫描反编译代码样本配套提供了开箱即用的检测链路先反编译拿到 Java 代码再用 semgrep 规则扫描。对应的仓库资源为静态分析技术 MASTG-TECH-0014 与规则工具 MASTG-TOOL-0110。4.1 检测脚本run.sh 只有一行核心命令直接对反编译得到的MastgTest_reversed.java运行规则并捕获输出#!/bin/bash # SUMMARY: This script uses semgrep to detect implicit intents in the source code. NO_COLORtrue semgrep --config ../../../../rules/mastg-android-implicit-intent-internal-communication.yml MastgTest_reversed.java --text output.txt参数含义NO_COLORtrue关闭彩色输出以方便落盘--config指向仓库根目录下的 mastg-android-implicit-intent-internal-communication.yml--text以纯文本格式输出结果重定向到output.txt。实际测试时把MastgTest_reversed.java换成任意待测反编译文件即可复用。4.2 规则解析三个正模式与三个反模式这条 semgrep 规则是整个检测方案的灵魂它用一个命中模式 三个排除模式精确刻画隐式 Intent 内部通信rules: - id: mastg-android-implicit-intent-internal-communication patterns: - pattern: | $INTENT new Intent(...); ... $INTENT.setAction($ACTION); ... $CONTEXT.startActivity($INTENT); - pattern-not: | $INTENT new Intent(...); ... $INTENT.setPackage(...); ... $CONTEXT.startActivity($INTENT); - pattern-not: | $INTENT new Intent(...); ... $INTENT.setComponent(...); ... $CONTEXT.startActivity($INTENT); - pattern-not: | $INTENT new Intent($CONTEXT, $CLASS); ... $CONTEXT.startActivity($INTENT); message: [MASVS-CODE-4] The app uses an implicit intent for internal component communication. Use explicit intents by specifying the package or component. languages: [java] severity: WARNING metadata: summary: Detects implicit intents used for internal component communication without specifying a package or component.规则的设计逻辑非常清晰正模式new Intent(...)创建 →setAction(...)指定 action →startActivity(...)派发构成隐式 Intent 的完整生命周期...表示中间允许任意代码因此putExtra、addFlags等调用不影响匹配。反模式 1setPackage(...)—— 一旦按包名限定目标Intent 只能投递到该包内组件即显式化。反模式 2setComponent(...)—— 按组件名限定目标同样显式化。反模式 3Intent($CONTEXT, $CLASS)构造函数 —— 直接在构造时指定目标类这是最严格的显式形式。也就是说只有当创建 → 设 action → 派发完整出现且没有任何目标限定调用时规则才报出告警有效避免了大量显式 Intent 的误报。告警级别为 WARNING归属于 MASVS-CODE-4代码质量与构建配置类问题声明的语言为 Java——这正是反编译产物的形态。4.3 结果解读output.txt 记录了真实扫描结果共命中1 处代码发现┌────────────────┐ │ 1 Code Finding │ └────────────────┘ MastgTest_reversed.java ❯❱ rules.mastg-android-implicit-intent-internal-communication [MASVS-CODE-4] The app uses an implicit intent for internal component communication. Use explicit intents by specifying the package or component. 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); 29┆ r.add(Status.FAIL, Launched internal activity via implicit intent); 30┆ } catch (Exception e) { 31┆ r.add(Status.ERROR, e.toString()); 32┆ } [hid 1 additional lines, adjust with --max-lines-per-finding]告警精确地锚定在第 22–28 行把隐式 Intent 的完整构造与派发链new Intent()→setAction→ 两个putExtra→startActivity一行不漏地呈现给分析人员报告中的关键要素与样本文档的观察结论完全一致Intent 创建new Intent()Action 赋值implicitIntent.setAction(org.owasp.mastestapp.INTERNAL_ACTION)派发前加入的 extrasuser_id与session_token派发 APIthis.context.startActivity(implicitIntent)缺少目标限定整段代码中没有setPackage、setClass、setClassName、setComponent或显式Intent(context, Class)构造函数。这条检测链路可以无缝移植到真实项目对任意 APK 先做反编译对应技术 MASTG-TECH-0013再对全部反编译 Java 文件运行该规则即可批量发现内部通信误用隐式 Intent 的代码点。五、测试判定MASTG-TEST-0372 为何判 Fail本样本对应测试用例 MASTG-TEST-0372Implicit Intents Used for Internal App Communication元数据标记为type: [static, code, manual]关联弱点枚举MASWE-0032并分别关联最佳实践 MASTG-BEST-0056 与知识条目 MASTG-KNOW-0025。根据测试的判定标准若用于应用内部或可信组件通信的 Intent 是隐式的且其他应用可以声明或注册匹配组件来接收它则测试失败。在本样本中actionorg.owasp.mastestapp.INTERNAL_ACTION虽为应用自定义InternalActivity也在 Manifest 中被声明为预期处理者但报告出的派发点没有命名该组件也没有限定目标包其他应用完全可以通过声明匹配的intent-filter成为 Android 意图解析的候选。因此样本文档 MASTG-DEMO-0136.md 明确判定该用例Fail对应源码注释也标记为FAIL: [MASTG-TEST-0372]。此外测试文档还给出了进一步人工验证的要求配合 MASTG-TECH-0023 逐一检查报告位置检查 Intent 是否已带显式组件或包名检查其他应用是否能为该 action、data、categories 声明或注册匹配的intent-filter对于广播检查发送方是否要求了可阻止不可信接收者的权限确认该 Intent 是面向应用自身组件或可信应用而非有意交给用户选择的外部应用。其中第 2、4 条正是本样本 Fail 的直接依据——它面向自身InternalActivity却给了外部应用插手的余地。六、修复方案改用显式 IntentMASTG-BEST-0056正确的修复方向在源码的 PASS 注释分支里已经给出最佳实践 MASTG-BEST-0056 则提供了完整规范同应用内部组件间通信一律使用显式 Intent——显式指定目标组件后Intent 只能送达预期接收者第三方应用无法通过正常意图解析截获。6.1 Java/Kotlin 侧修复// 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)两种显式写法按限制强度递增setPackage(com.example.app)把投递范围锁死在本应用包内即使其他应用声明了同 action 的 filter 也无法接收Intent(context, TargetActivity::class.java)则直接指名目标类是最严格的形式。回到本样本只需把Intent().apply { action ... }替换为Intent(context, InternalActivity::class.java)即可消除漏洞同时照常携带 extras 与FLAG_ACTIVITY_NEW_TASK。最佳实践还特别强调了一条铁律绝不要把敏感数据令牌、凭据、API Key放进隐式 Intent。Android 通过匹配已安装应用声明intent-filter的方式解析隐式 Intent任何匹配应用都可能成为最终接收者并读到 extras——这正是本样本中user_id、session_token面临的处境。6.2 Manifest 侧加固对于内部组件还需确保它们没有被无意中暴露给其他应用。样本中InternalActivity的exportedtrue加上 intent-filter 属于典型的多余暴露——如果组件只供本应用使用应移除 intent-filter 并将exported设为false关于 Manifest 更系统的加固细节MASTG-BEST-0056 指向了专门条目 MASTG-BEST-0052 进行展开见 best-practices 目录。七、对照攻击样本MASTG-DEMO-0140 的接管演示为完整呈现威胁仓库还配套提供了攻击方视角的对照样本 MASTG-DEMO-0140该演示应用在自己的 Manifest 中声明了与org.owasp.mastestapp.INTERNAL_ACTION匹配的intent-filter从而成为本样本隐式 Intent 的解析候选。二者配套阅读可以直观验证另一个应用如何成为处理者候选的完整过程——这也是本样本文档中的 note 明确指引的实验路径。图 1 展示的就是这一时刻系统弹出的应用选择器界面。八、关联资源索引围绕本主题仓库中可继续深入阅读的材料均以仓库根目录为起点的相对路径样本文档demos/android/MASVS-CODE/MASTG-DEMO-0136/MASTG-DEMO-0136.md源码与反编译产物MastgTest.kt、MastgTest_reversed.java、AndroidManifest.xml、AndroidManifest_reversed.xml检测脚本与结果run.sh、output.txtsemgrep 规则rules/mastg-android-implicit-intent-internal-communication.yml测试用例tests-beta/android/MASVS-CODE/MASTG-TEST-0372.md最佳实践best-practices/MASTG-BEST-0056.md背景知识knowledge/android/MASVS-PLATFORM/MASTG-KNOW-0025.md攻击对照样本demos/android/MASVS-CODE/MASTG-DEMO-0140/MASTG-DEMO-0140.md总结而言MASTG-DEMO-0136 用最小化的代码演示了内部通信隐式化这一常见且高危的 Android 反模式显式 Intent 是内部 IPC 的默认选项setPackage/setComponent/组件构造器是强制约束手段而 semgrep 规则 反编译产物扫描则提供了一条低成本、可自动化的持续检测路径。对照攻击样本、测试用例与最佳实践读者可以在此样本基础上形成完整的发现—判定—修复—验证闭环能力。赞分享文档教程网络安全【免费下载链接】mastgThe 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.项目地址https://gitcode.com/gh_mirrors/ow/mastg点击查看免费下载相关推荐用 semgrep 揪出 Android 隐式 Intent 泄漏OWASP MASTG MASTG-DEMO-0138 实战指南用 semgrep 揪出 Android 隐式 Intent 泄漏OWASP MASTG MASTG DEMO 0138 实战指南 本篇技术指南聚焦 OWAS文档教程网络安全OWASP MASTG 实战Android 内部存储明文敏感数据检测MASTG-DEMO-0010 / MASTG-TEST-0207OWASP MASTG 实战Android 内部存储明文敏感数据检测MASTG DEMO 0010 / MASTG TEST 0207 导读 本文以 OW文档教程网络安全OWASP MASTG 最佳实践Android 内部 IPC 必须使用显式 IntentMASTG-BEST-0056OWASP MASTG 最佳实践Android 内部 IPC 必须使用显式 IntentMASTG BEST 0056 导读 本文是 OWASP Mobi文档教程网络安全创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考