拓冰网站定制 
文档教程网络安全【免费下载链接】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点击查看免费下载Android 的每个进程都运行在独立沙箱地址空间中跨进程通信IPC是应用与系统交换数据、调用功能的唯一桥梁。本篇基于 OWASP Mobile Application Security Testing GuideMASTG仓库中 MASTG-KNOW-0020 知识条目系统梳理 Binder 内核机制、Intent 消息框架、四大应用组件 IPC 入口及其权限控制模型帮助安全测试人员与开发者掌握 Android IPC 的攻击面识别与安全配置方法。读完本文你将能够理解 Binder 的客户端-服务器模型、正确区分显式/隐式 Intent 与 PendingIntent、并借助android:exported与权限属性评估每个组件入口的暴露风险。BinderAndroid IPC 的基石Android 的 IPC 全部建立在Binder之上——一个源自 OpenBinder 的自定义内核驱动与框架。绝大多数系统服务以及所有高层 IPC 机制都依赖它。Binder 一词实际上指代多个相互关联的概念理解这四层区分是深入 IPC 的第一步Binder 驱动Binder driver内核级驱动以/dev/binder字符设备的形式暴露给用户空间负责传输与对象引用管理。Binder 协议Binder protocol与驱动通信的低层ioctl协议所有事务最终都归结为对这些 ioctl 调用的封装。IBinder接口Binder 对象必须实现的、行为定义良好的接口是客户端与服务端交互的契约。Binder 对象、服务与客户端Binder object, service, and client对外暴露功能的服务实现以及消费这些功能的对象。客户端-服务器模型与 Parcel 编组Binder 框架遵循经典的客户端-服务器模型。一次 IPC 调用的完整路径如下应用客户端在一个**代理对象proxy object**上调用方法代理将参数**编组marshal**进一个Parcel数据容器代理通过 Binder 驱动向持有线程池的Binder 服务器发送一个事务transaction服务器线程池中的线程接收请求将调用**分发dispatch**到目标对象结果沿相同路径返回。从调用方视角看这就像一次普通的方法调用——编组与传输全部由框架透明完成。Binder 驱动还会为每个进程维护唯一标识UID/PID服务端可据此校验调用方身份这也是 MASTG-KNOW-0133 中提到的Context.checkCallingPermission等运行时校验能够成立的基础。绑定服务与 AIDL允许其他应用绑定自己的服务称为绑定服务bound services它们向客户端暴露一个IBinder接口。开发者通常使用 **Android 接口定义语言AIDL**来定义远程接口——AIDL 编译器会为远程接口自动生成编组marshalling代码支持跨进程并发调用。对于仅在同进程内使用的场景则可以直接继承Binder子类而最简单的跨进程接口是 Messenger把请求序列化为Message对象投递给Handler。ServiceManager 与 service listServiceManager系统守护进程负责注册系统服务并按名称解析它们。在测试与逆向分析中最常用的枚举手段是列出全部已注册的系统服务adb shell service list该命令输出系统中所有注册服务的名称与 Binder 句柄是安全测试人员观察系统服务分布、定位可疑服务的第一步。Intents构建在 Binder 之上的异步消息框架Intent 消息传递是构建在 Binder 之上的异步通信框架。Intent是一个消息对象用于向另一个应用组件请求动作。Intent 支持三个基本用例每个都对应独立的 MASTG 知识条目启动 Activity将 Intent 传给startActivity详见 MASTG-KNOW-0132Android Activities启动或绑定服务将 Intent 传给startService或bindService详见 MASTG-KNOW-0133Android Services发送广播将 Intent 传给sendBroadcast或sendOrderedBroadcast详见 MASTG-KNOW-0134Android Broadcast Receivers。显式与隐式 IntentIntent 分为两种类型详见 MASTG-KNOW-0025显式 Intent通过指定目标包名或完整组件类名明确指明由哪个应用处理通常用于启动同应用内的组件Intent downloadIntent new Intent(this, DownloadActivity.class); downloadIntent.setAction(android.intent.action.GET_CONTENT) startActivityForResult(downloadIntent);隐式 Intent不指明具体组件只声明 action以及可选的 data 和 category由系统根据已安装组件声明的intent-filter解析目标。例如不指定具体地图应用仅要求在地图上显示某个位置Intent downloadIntent new Intent(); downloadIntent.setAction(android.intent.action.GET_CONTENT) startActivityForResult(downloadIntent);Intent 解析算法按三个维度匹配action 必须与过滤器声明的动作一致Intent 中的全部 category 必须出现在过滤器中过滤器可声明额外 category数据 URI 的 scheme、host、path 与 MIME 类型必须满足data约束。当解析出多个匹配组件时系统会弹出选择器chooser或消歧对话框让用户选择仅一个匹配时则直接路由。需要特别注意的安全细节若应用 targetSdk 为 Android 14API level 34及以上隐式 Intent 将永远不会发送给内部组件internal components这强制开发者对内部通信使用显式 Intent。另外Intent.setPackage可以在仍按 action 匹配的同时将解析范围限制在指定包内val intent Intent(com.example.app.INTERNAL_ACTION).apply { setPackage(com.example.app) } startActivity(intent)PendingIntent安全委托的关键陷阱MASTG-KNOW-0024 详细阐述了 PendingIntent——它包装一个普通 Intent称为基础 Intent允许应用 A 委托应用 B 在未来代表 A 执行动作而无需为此创建多个导出组件。典型实现如下Intent intent new Intent(applicationContext, SomeActivity.class); // base intent // create a pending intent PendingIntent pendingIntent PendingIntent.getActivity(applicationContext, 0, intent, PendingIntent.FLAG_IMMUTABLE); // send the pending intent to another app Intent anotherIntent new Intent(); anotherIntent.setClassName(other.app, other.app.MainActivity); anotherIntent.putExtra(pendingIntent, pendingIntent); startActivity(anotherIntent);其安全性来源在于与普通 Intent 不同PendingIntent 授予外部应用以你应用进程的身份执行其中基础 Intent 的权限。但它也是常见攻击面可变字段Mutable fields恶意应用可填充可变/空字段进而访问非导出组件。使用PendingIntent.FLAG_IMMUTABLE可锁定字段。注意Android 12API level 31之前 PendingIntent 默认可变自 API level 31 起必须显式声明FLAG_MUTABLE或FLAG_IMMUTABLE否则系统抛出IllegalArgumentException导致崩溃。隐式 Intent 滥用恶意应用收到 PendingIntent 后可改写基础 Intent 指向自身组件。缓解办法是显式指定接收基础 Intent 的确切包名、action 与组件。最常见的攻击形态是恶意应用拦截 PendingIntent例如持有BIND_NOTIFICATION_LISTENER_SERVICE权限的应用从通知监听服务中窃取它。仓库中的规则 mastg-android-pendingintent-mutable.yml 正是针对该问题设计的静态检测项。Deep Links特殊的 Intent 过滤器MASTG-KNOW-0019 说明 Deep Link 是任何 scheme 的 URI通过 Manifest 中的intent-filter将用户直接带入应用特定内容。两类 Deep Link自定义 URL Scheme如myapp://不受操作系统验证任意应用都可声明相同链接引发Deep Link 碰撞用户可能在消歧对话框中误选恶意应用Android App LinksAndroid 6.0/API 23 起仅使用http://与https://scheme通过android:autoVerifytrue触发系统向https://host/.well-known/assetlinks.json的 Digital Asset Links 文件验证。验证通过前不会被当作 App Link 处理且http→https或子域跳转等服务器端重定向会中止验证。声明方式是在activity上添加android.intent.action.VIEW动作、DEFAULT与BROWSABLE类别以及一个或多个定义scheme/host/path的data元素。同一intent-filter内的data会按属性笛卡尔积合并。四大应用组件作为 IPC 入口四种应用组件类型构成 IPC 入口均须在AndroidManifest.xml中声明且其对外可见性由android:exported属性与可选的权限属性控制。组件可见性直接决定应用的攻击面——这也是 MASTG-KNOW-0132、MASTG-KNOW-0133、MASTG-KNOW-0134 反复强调的核心观点。android:exported 与权限控制模型每个组件入口的访问控制由两把锁组成android:exported为true时其他应用组件可启动/绑定/投递除非android:permission拦截为false 时仅同应用、同 UID 应用或特权系统组件可访问。历史默认值存在陷阱——声明曾使该属性隐式默认为true自 Android 12API level 31起凡带 intent-filter 的组件必须显式声明该属性否则应用无法安装。权限属性为true的组件配上android:permission或android:readPermission/android:writePermission可要求调用方持有特定权限。与自定义权限及合适的android:protectionLevel如signature组合能精确限制可交互的应用集合。权限体系的完整模型见 MASTG-KNOW-0017App Permissions按保护级别分为安装时权限normal/signature/signatureOrSystem、运行时权限dangerous、特殊权限appop与自定义权限且各组件类型的权限强制时机不同——Activity 与 Service 在调用startActivity/startService/bindService时校验并抛出SecurityExceptionBroadcast Receiver 在投递时校验、不抛出异常而是静默丢弃广播Content Provider 则区分android:readPermission与android:writePermission两种属性仅持有写权限并不自动获得读权限。此外还有按 URI 授权的机制FLAG_GRANT_READ_URI_PERMISSION/FLAG_GRANT_WRITE_URI_PERMISSION用于细粒度的临时授权。ActivitiesActivity 是带用户界面的单屏组件也是最常用的 IPC 入口。除启动方式外还需注意生命周期回调onCreate、onStart/onResume、onPause/onStop、onDestroy、onSaveInstanceState/onRestoreInstanceState带intent-filter的隐式启动通常需要CATEGORY_DEFAULT类别startActivity视隐式 Intent 隐含包含它intent-filter 本身不是访问控制机制对外可见性必须靠android:exported与权限。ServicesService 是后台长期运行组件按使用方式分为 started、bound 与 foreground 三种。与 IPC 最相关的是 bound service——它必须从onBind返回IBinder客户端通过 Messenger、AIDL 或本地 Binder 子类交互。android:process:remote可将服务放入独立进程是暴露远程接口的常见做法。在服务内部可用Context.checkCallingPermission等运行时校验调用方权限。对无需立即执行的延迟后台任务现代 Android 更推荐 WorkManager 与 JobScheduler。Broadcast Receivers广播是发布-订阅式消息机制。两种注册方式的安全配置不同Manifest 声明式receiver元素加intent-filter用android:exported与android:permission控制Android 8.0API 26起targetSdk 26 的应用无法在 manifest 中注册大多数隐式广播少数例外已废弃的 sticky broadcast 持久留存且无访问控制属于风险项见仓库规则 mastg-android-sensitive-data-in-notifications.yml 系列。Context 注册式registerReceiver()运行时注册关键安全参数是flagsRECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED与broadcastPermission。Android 14API 34起targetSdk 34 的应用注册非系统专属广播时必须显式指定导出标志否则运行时报错AndroidX 的ContextCompat.registerReceiver()是跨版本一致的封装。有序广播sendOrderedBroadcast按android:priority依次投递接收者可中止广播或向下一接收者传递数据。Content ProvidersContent Provider 通过 URI 化接口暴露结构化数据完整条目对应知识文章 MASTG-KNOW-0117 的组件清单仓库中的对应安全规则包括 mastg-android-content-provider-exported.yml 与 mastg-android-sql-injection-contentprovider.yml。它是唯一区分读写权限的组件ContentResolver.query需要读权限insert/update/delete需要写权限缺失时抛出SecurityException。其他 IPC 机制除组件绑定机制外应用还可通过以下不绑定具体组件类型的方式交换数据剪贴板Clipboard系统级共享缓冲跨应用粘贴数据Messenger 对象基于Message/Handler的轻量跨进程消息传递FileProvider 暴露的共享文件AndroidX 提供的文件共享方案配合 URI 授权控制访问范围仓库规则 mastg-android-fileprovider-broad-scope.yml 检测其暴露范围过宽的问题本地 Socketlocal sockets基于 Unix domain socket 的进程间通道。其中组件化机制Activity/Service/Receiver/Provider是暴露给其他应用的最常见入口因此也是安全评估的优先关注点。从安全测试视角看 IPC攻面识别与检测支撑在 OWASP MASTG 的测试框架中IPC 主题横跨 MASVS-PLATFORM 类别的多项测试。仓库 tests/android/MASVS-PLATFORM 目录下的用例如涉及 IPC/Binder 检查的 MASTG-TEST-0007.md 与 MASTG-TEST-0029.md与 rules 目录的静态检测规则如 mastg-android-pendingintent-mutable.yml、mastg-android-content-provider-exported.yml、mastg-android-custom-deeplink-scheme.yml共同构成知识理解 → 测试验证 → 自动检测的闭环。安全评估时的核心检查清单枚举组件入口检查 Manifest 中所有 Activity/Service/Receiver/Provider 的android:exported显式取值重点关注带 intent-filter 却未显式声明的组件Android 12 会直接安装失败低版本仍存在默认暴露风险评估权限组合对导出的组件核对android:permission及保护级别确认signature级别权限未被降级为normal或dangerous审查 PendingIntent 可变性确认所有 PendingIntent 使用FLAG_IMMUTABLE基础 Intent 显式指定组件与包名检查隐式 Intent 与 Deep Link验证自定义 scheme 是否可能被其他应用碰撞App Links 的 Digital Asset Links 文件是否配置正确验证广播与 Provider 边界运行时注册的接收者是否正确使用RECEIVER_NOT_EXPORTEDProvider 是否区分读写权限、是否启用 URI 授权。从源码结构看MASTG 将 知识条目knowledge、测试用例tests 与 静态规则rules 按 MASVS 类别一一对应使得本文介绍的每一项 IPC 机制都能在仓库中找到可操作的验证方法与检测规则便于测试人员将其直接落地到真实应用的评估流程中。赞分享文档教程网络安全【免费下载链接】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点击查看免费下载相关推荐OWASP MASTG 最佳实践Android 内部 IPC 必须使用显式 IntentMASTG-BEST-0056OWASP MASTG 最佳实践Android 内部 IPC 必须使用显式 IntentMASTG BEST 0056 导读 本文是 OWASP Mobi文档教程网络安全OWASP MASTG 深度解析Android 显式与隐式 IntentExplicit vs Implicit Intents原理、解析机制与安全实践OWASP MASTG 深度解析Android 显式与隐式 IntentExplicit vs Implicit Intents原理、解析机制与安全实践文档教程网络安全OWASP MASTG 最佳实践使用显式 Intent 的不可变 PendingIntentMASTG-BEST-0063保障 Android 组件安全OWASP MASTG 最佳实践使用显式 Intent 的不可变 PendingIntentMASTG BEST 0063保障 Android 组件安全文档教程网络安全上一篇Atlas OS 中 Xbox 登录报错 0x89235107 的 3 步完整修复指南下一篇Namviek任务管理系统深度教程从创建到完成的完整工作流创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Android IPC 机制全面解析：Binder、Intent 与四大组件入口（基于 OWASP MASTG）
文档教程网络安全【免费下载链接】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点击查看免费下载Android 的每个进程都运行在独立沙箱地址空间中跨进程通信IPC是应用与系统交换数据、调用功能的唯一桥梁。本篇基于 OWASP Mobile Application Security Testing GuideMASTG仓库中 MASTG-KNOW-0020 知识条目系统梳理 Binder 内核机制、Intent 消息框架、四大应用组件 IPC 入口及其权限控制模型帮助安全测试人员与开发者掌握 Android IPC 的攻击面识别与安全配置方法。读完本文你将能够理解 Binder 的客户端-服务器模型、正确区分显式/隐式 Intent 与 PendingIntent、并借助android:exported与权限属性评估每个组件入口的暴露风险。BinderAndroid IPC 的基石Android 的 IPC 全部建立在Binder之上——一个源自 OpenBinder 的自定义内核驱动与框架。绝大多数系统服务以及所有高层 IPC 机制都依赖它。Binder 一词实际上指代多个相互关联的概念理解这四层区分是深入 IPC 的第一步Binder 驱动Binder driver内核级驱动以/dev/binder字符设备的形式暴露给用户空间负责传输与对象引用管理。Binder 协议Binder protocol与驱动通信的低层ioctl协议所有事务最终都归结为对这些 ioctl 调用的封装。IBinder接口Binder 对象必须实现的、行为定义良好的接口是客户端与服务端交互的契约。Binder 对象、服务与客户端Binder object, service, and client对外暴露功能的服务实现以及消费这些功能的对象。客户端-服务器模型与 Parcel 编组Binder 框架遵循经典的客户端-服务器模型。一次 IPC 调用的完整路径如下应用客户端在一个**代理对象proxy object**上调用方法代理将参数**编组marshal**进一个Parcel数据容器代理通过 Binder 驱动向持有线程池的Binder 服务器发送一个事务transaction服务器线程池中的线程接收请求将调用**分发dispatch**到目标对象结果沿相同路径返回。从调用方视角看这就像一次普通的方法调用——编组与传输全部由框架透明完成。Binder 驱动还会为每个进程维护唯一标识UID/PID服务端可据此校验调用方身份这也是 MASTG-KNOW-0133 中提到的Context.checkCallingPermission等运行时校验能够成立的基础。绑定服务与 AIDL允许其他应用绑定自己的服务称为绑定服务bound services它们向客户端暴露一个IBinder接口。开发者通常使用 **Android 接口定义语言AIDL**来定义远程接口——AIDL 编译器会为远程接口自动生成编组marshalling代码支持跨进程并发调用。对于仅在同进程内使用的场景则可以直接继承Binder子类而最简单的跨进程接口是 Messenger把请求序列化为Message对象投递给Handler。ServiceManager 与 service listServiceManager系统守护进程负责注册系统服务并按名称解析它们。在测试与逆向分析中最常用的枚举手段是列出全部已注册的系统服务adb shell service list该命令输出系统中所有注册服务的名称与 Binder 句柄是安全测试人员观察系统服务分布、定位可疑服务的第一步。Intents构建在 Binder 之上的异步消息框架Intent 消息传递是构建在 Binder 之上的异步通信框架。Intent是一个消息对象用于向另一个应用组件请求动作。Intent 支持三个基本用例每个都对应独立的 MASTG 知识条目启动 Activity将 Intent 传给startActivity详见 MASTG-KNOW-0132Android Activities启动或绑定服务将 Intent 传给startService或bindService详见 MASTG-KNOW-0133Android Services发送广播将 Intent 传给sendBroadcast或sendOrderedBroadcast详见 MASTG-KNOW-0134Android Broadcast Receivers。显式与隐式 IntentIntent 分为两种类型详见 MASTG-KNOW-0025显式 Intent通过指定目标包名或完整组件类名明确指明由哪个应用处理通常用于启动同应用内的组件Intent downloadIntent new Intent(this, DownloadActivity.class); downloadIntent.setAction(android.intent.action.GET_CONTENT) startActivityForResult(downloadIntent);隐式 Intent不指明具体组件只声明 action以及可选的 data 和 category由系统根据已安装组件声明的intent-filter解析目标。例如不指定具体地图应用仅要求在地图上显示某个位置Intent downloadIntent new Intent(); downloadIntent.setAction(android.intent.action.GET_CONTENT) startActivityForResult(downloadIntent);Intent 解析算法按三个维度匹配action 必须与过滤器声明的动作一致Intent 中的全部 category 必须出现在过滤器中过滤器可声明额外 category数据 URI 的 scheme、host、path 与 MIME 类型必须满足data约束。当解析出多个匹配组件时系统会弹出选择器chooser或消歧对话框让用户选择仅一个匹配时则直接路由。需要特别注意的安全细节若应用 targetSdk 为 Android 14API level 34及以上隐式 Intent 将永远不会发送给内部组件internal components这强制开发者对内部通信使用显式 Intent。另外Intent.setPackage可以在仍按 action 匹配的同时将解析范围限制在指定包内val intent Intent(com.example.app.INTERNAL_ACTION).apply { setPackage(com.example.app) } startActivity(intent)PendingIntent安全委托的关键陷阱MASTG-KNOW-0024 详细阐述了 PendingIntent——它包装一个普通 Intent称为基础 Intent允许应用 A 委托应用 B 在未来代表 A 执行动作而无需为此创建多个导出组件。典型实现如下Intent intent new Intent(applicationContext, SomeActivity.class); // base intent // create a pending intent PendingIntent pendingIntent PendingIntent.getActivity(applicationContext, 0, intent, PendingIntent.FLAG_IMMUTABLE); // send the pending intent to another app Intent anotherIntent new Intent(); anotherIntent.setClassName(other.app, other.app.MainActivity); anotherIntent.putExtra(pendingIntent, pendingIntent); startActivity(anotherIntent);其安全性来源在于与普通 Intent 不同PendingIntent 授予外部应用以你应用进程的身份执行其中基础 Intent 的权限。但它也是常见攻击面可变字段Mutable fields恶意应用可填充可变/空字段进而访问非导出组件。使用PendingIntent.FLAG_IMMUTABLE可锁定字段。注意Android 12API level 31之前 PendingIntent 默认可变自 API level 31 起必须显式声明FLAG_MUTABLE或FLAG_IMMUTABLE否则系统抛出IllegalArgumentException导致崩溃。隐式 Intent 滥用恶意应用收到 PendingIntent 后可改写基础 Intent 指向自身组件。缓解办法是显式指定接收基础 Intent 的确切包名、action 与组件。最常见的攻击形态是恶意应用拦截 PendingIntent例如持有BIND_NOTIFICATION_LISTENER_SERVICE权限的应用从通知监听服务中窃取它。仓库中的规则 mastg-android-pendingintent-mutable.yml 正是针对该问题设计的静态检测项。Deep Links特殊的 Intent 过滤器MASTG-KNOW-0019 说明 Deep Link 是任何 scheme 的 URI通过 Manifest 中的intent-filter将用户直接带入应用特定内容。两类 Deep Link自定义 URL Scheme如myapp://不受操作系统验证任意应用都可声明相同链接引发Deep Link 碰撞用户可能在消歧对话框中误选恶意应用Android App LinksAndroid 6.0/API 23 起仅使用http://与https://scheme通过android:autoVerifytrue触发系统向https://host/.well-known/assetlinks.json的 Digital Asset Links 文件验证。验证通过前不会被当作 App Link 处理且http→https或子域跳转等服务器端重定向会中止验证。声明方式是在activity上添加android.intent.action.VIEW动作、DEFAULT与BROWSABLE类别以及一个或多个定义scheme/host/path的data元素。同一intent-filter内的data会按属性笛卡尔积合并。四大应用组件作为 IPC 入口四种应用组件类型构成 IPC 入口均须在AndroidManifest.xml中声明且其对外可见性由android:exported属性与可选的权限属性控制。组件可见性直接决定应用的攻击面——这也是 MASTG-KNOW-0132、MASTG-KNOW-0133、MASTG-KNOW-0134 反复强调的核心观点。android:exported 与权限控制模型每个组件入口的访问控制由两把锁组成android:exported为true时其他应用组件可启动/绑定/投递除非android:permission拦截为false 时仅同应用、同 UID 应用或特权系统组件可访问。历史默认值存在陷阱——声明曾使该属性隐式默认为true自 Android 12API level 31起凡带 intent-filter 的组件必须显式声明该属性否则应用无法安装。权限属性为true的组件配上android:permission或android:readPermission/android:writePermission可要求调用方持有特定权限。与自定义权限及合适的android:protectionLevel如signature组合能精确限制可交互的应用集合。权限体系的完整模型见 MASTG-KNOW-0017App Permissions按保护级别分为安装时权限normal/signature/signatureOrSystem、运行时权限dangerous、特殊权限appop与自定义权限且各组件类型的权限强制时机不同——Activity 与 Service 在调用startActivity/startService/bindService时校验并抛出SecurityExceptionBroadcast Receiver 在投递时校验、不抛出异常而是静默丢弃广播Content Provider 则区分android:readPermission与android:writePermission两种属性仅持有写权限并不自动获得读权限。此外还有按 URI 授权的机制FLAG_GRANT_READ_URI_PERMISSION/FLAG_GRANT_WRITE_URI_PERMISSION用于细粒度的临时授权。ActivitiesActivity 是带用户界面的单屏组件也是最常用的 IPC 入口。除启动方式外还需注意生命周期回调onCreate、onStart/onResume、onPause/onStop、onDestroy、onSaveInstanceState/onRestoreInstanceState带intent-filter的隐式启动通常需要CATEGORY_DEFAULT类别startActivity视隐式 Intent 隐含包含它intent-filter 本身不是访问控制机制对外可见性必须靠android:exported与权限。ServicesService 是后台长期运行组件按使用方式分为 started、bound 与 foreground 三种。与 IPC 最相关的是 bound service——它必须从onBind返回IBinder客户端通过 Messenger、AIDL 或本地 Binder 子类交互。android:process:remote可将服务放入独立进程是暴露远程接口的常见做法。在服务内部可用Context.checkCallingPermission等运行时校验调用方权限。对无需立即执行的延迟后台任务现代 Android 更推荐 WorkManager 与 JobScheduler。Broadcast Receivers广播是发布-订阅式消息机制。两种注册方式的安全配置不同Manifest 声明式receiver元素加intent-filter用android:exported与android:permission控制Android 8.0API 26起targetSdk 26 的应用无法在 manifest 中注册大多数隐式广播少数例外已废弃的 sticky broadcast 持久留存且无访问控制属于风险项见仓库规则 mastg-android-sensitive-data-in-notifications.yml 系列。Context 注册式registerReceiver()运行时注册关键安全参数是flagsRECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED与broadcastPermission。Android 14API 34起targetSdk 34 的应用注册非系统专属广播时必须显式指定导出标志否则运行时报错AndroidX 的ContextCompat.registerReceiver()是跨版本一致的封装。有序广播sendOrderedBroadcast按android:priority依次投递接收者可中止广播或向下一接收者传递数据。Content ProvidersContent Provider 通过 URI 化接口暴露结构化数据完整条目对应知识文章 MASTG-KNOW-0117 的组件清单仓库中的对应安全规则包括 mastg-android-content-provider-exported.yml 与 mastg-android-sql-injection-contentprovider.yml。它是唯一区分读写权限的组件ContentResolver.query需要读权限insert/update/delete需要写权限缺失时抛出SecurityException。其他 IPC 机制除组件绑定机制外应用还可通过以下不绑定具体组件类型的方式交换数据剪贴板Clipboard系统级共享缓冲跨应用粘贴数据Messenger 对象基于Message/Handler的轻量跨进程消息传递FileProvider 暴露的共享文件AndroidX 提供的文件共享方案配合 URI 授权控制访问范围仓库规则 mastg-android-fileprovider-broad-scope.yml 检测其暴露范围过宽的问题本地 Socketlocal sockets基于 Unix domain socket 的进程间通道。其中组件化机制Activity/Service/Receiver/Provider是暴露给其他应用的最常见入口因此也是安全评估的优先关注点。从安全测试视角看 IPC攻面识别与检测支撑在 OWASP MASTG 的测试框架中IPC 主题横跨 MASVS-PLATFORM 类别的多项测试。仓库 tests/android/MASVS-PLATFORM 目录下的用例如涉及 IPC/Binder 检查的 MASTG-TEST-0007.md 与 MASTG-TEST-0029.md与 rules 目录的静态检测规则如 mastg-android-pendingintent-mutable.yml、mastg-android-content-provider-exported.yml、mastg-android-custom-deeplink-scheme.yml共同构成知识理解 → 测试验证 → 自动检测的闭环。安全评估时的核心检查清单枚举组件入口检查 Manifest 中所有 Activity/Service/Receiver/Provider 的android:exported显式取值重点关注带 intent-filter 却未显式声明的组件Android 12 会直接安装失败低版本仍存在默认暴露风险评估权限组合对导出的组件核对android:permission及保护级别确认signature级别权限未被降级为normal或dangerous审查 PendingIntent 可变性确认所有 PendingIntent 使用FLAG_IMMUTABLE基础 Intent 显式指定组件与包名检查隐式 Intent 与 Deep Link验证自定义 scheme 是否可能被其他应用碰撞App Links 的 Digital Asset Links 文件是否配置正确验证广播与 Provider 边界运行时注册的接收者是否正确使用RECEIVER_NOT_EXPORTEDProvider 是否区分读写权限、是否启用 URI 授权。从源码结构看MASTG 将 知识条目knowledge、测试用例tests 与 静态规则rules 按 MASVS 类别一一对应使得本文介绍的每一项 IPC 机制都能在仓库中找到可操作的验证方法与检测规则便于测试人员将其直接落地到真实应用的评估流程中。赞分享文档教程网络安全【免费下载链接】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点击查看免费下载相关推荐OWASP MASTG 最佳实践Android 内部 IPC 必须使用显式 IntentMASTG-BEST-0056OWASP MASTG 最佳实践Android 内部 IPC 必须使用显式 IntentMASTG BEST 0056 导读 本文是 OWASP Mobi文档教程网络安全OWASP MASTG 深度解析Android 显式与隐式 IntentExplicit vs Implicit Intents原理、解析机制与安全实践OWASP MASTG 深度解析Android 显式与隐式 IntentExplicit vs Implicit Intents原理、解析机制与安全实践文档教程网络安全OWASP MASTG 最佳实践使用显式 Intent 的不可变 PendingIntentMASTG-BEST-0063保障 Android 组件安全OWASP MASTG 最佳实践使用显式 Intent 的不可变 PendingIntentMASTG BEST 0063保障 Android 组件安全文档教程网络安全上一篇Atlas OS 中 Xbox 登录报错 0x89235107 的 3 步完整修复指南下一篇Namviek任务管理系统深度教程从创建到完成的完整工作流创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考