m开头的可以做网站的软件/竞价账户托管

在安全审查中关于组件导出风险是一种常见问题，不同组件都有可能遇到这种问题，而且从一定角度来看的话，如果涉及到三方业务，基本处于无法解决的场景，所以我们需要说明为何无法避免这种风险

组件导出风险能不能规避？能不能解决？

如果你的组件风险是由 exported 属性所引起，那么可以规避，也可以解决，只要将 exported 设置为 false 即可； 这样外部就无法调用项目内组件了，自然就避免了风险的产生，同时带来了一些不太好的结果，例如业务出错、功能缺失等等，毕竟 很多项目内集成的三方平台SDK都是需要 exported 所附带的权限的！

最终结果：当 组件导出风险 遇到三方业务时，很多时候我们可能无法规避这类型风险！

基础分析

组件导出风险一般都是由 android:exported 属性引起的，如果我们在 AndroidManifest 对应组件内声明了 android:exported=true，意味着允许让外部组件启动这个组件；反之，则不允许让外部组件启动这个组件；

初步搜索后，AI已经给出了部分参考答案，简单看一下就好（解决方式未尝试，不确定是否可用）

其实当你已经将 android:exported 设置为 true 时，已经证明该组件因业务需要确实需要被外部调用，这种场景如果是项目内我方业务的话，可以参考 权限过滤、intent-filter 过滤方式（个人感觉这种方式只是在内部做了限制保护，从安全检查的角度来看可能当你android:exported 设置为 true 时就已经存在风险了，并不关注你内部做了何限制…）

如果android:exported设置了false，又在外部试图启动这个Activity，则会发生程序崩溃，报异常，例如：

 java.lang.SecurityException: Permission Denial: starting Intent

常见组件可以参考Android四大组件

• 活动（Activity）：用于表现功能，是用户操作的可视化界面，它为用户提供了一个完成操作指令的窗口；
• 服务（Service）：后台运行服务，不提供界面呈现；
• 广播接受者（Broadcast Receive）：用于接收广播；
• 内容提供者（Content Provider）：支持多个应用中存储和读取数据，相当于数据库。

exported 在不同场景下默认值也有所不同

关于exported属性还是挺关键的，参考自 Android 组件导出风险及防范

Activity、Service、Broadcast Receive 中 exported 默认值

• 没有 intent filter 时，默认为 false
• 有 intent filter 时，默认为 true

Content Provider 中 exported 默认值

• 当 minSdkVersion 或者 targetSdkVersion 小于16时，默认为 true
• 大于17时，默认为 false

那么组件导出的风险到底有哪些？

• Activity ：可能导致登录界面被绕过、拒绝服务攻击、程序界面被第三方恶意调用等风险
• Service ：能被系统或者第三方的App直接调出并使用，可能导致拒绝服务攻击，程序功能被第三方恶意调用等风险
• Broadcast Receiver ：对外部事件进行过滤接收,并根据消息内容执行响应，如果设置了导出权限，可能被系统或者第三方的App直接调出并使用。同时可能导致敏感信息泄露、登录界面被绕过等风险。
• Content Provider ：可能导致程序内部的敏感信息泄露，数据库SQL注入等风险

---

那些无法解决的风险场景

像以下这些场景的导出风险从一定角度来说是无法解决的，我们只需反馈给安全人员因为什么业务原因，无法避免此项风险

Activity 组件导出风险

检测方式

1. 反编译提取应用的 AndroidManifest 文件并解析获取所有注册的Activity组件
2. 查看是否显式的设置可导出信息或者配置了意图过滤器

微博分享SDK（配置）

解决方式：像这种三方平台组件，一般都无法解决，主要是因为涉及到已有业务，除非剥离业务，但这也不现实~ 所以只需要反馈到安全机构因XX业务原因，无法规避这类型风险

Service 组件导出风险

检测方式

1. 反编译提取应用的 AndroidManifest 文件并解析
2. 获取所有注册的 Service 组件，查看是否显式的设置了可导出信息或者配置了意图过滤器

魅族推送、通知服务（配置）

解决方式：像这种三方平台组件，一般都无法解决，主要是因为涉及到已有业务，除非剥离业务，但这也不现实~ 所以只需要反馈到安全机构因XX业务原因，无法规避这类型风险（图中的就是微博分享的业务功能）

Broadcast Receiver组件导出风险

检测方式

1. 反编译提取应用的 AndroidManifest 文件并解析
2. 获取所有注册的 Receiver 组件，查看是否显式的设置了可导出信息或者配置了意图过滤器

极光推送-小米推送相关业务（配置）

---

定义权限、保护组件

权限过滤中涉及到了权限定义，参考 Android 组件导出风险及防范 做个笔记

Android提供了自定义权限的能力，应用可以定义自己的权限，如在清单文件中自定义一个 permission

 <permissionandroid:label="允许打开WebActivity页面权限"android:name="com.littlejerk.sample.permission.WEB"android:protectionLevel="signature" />

• label：权限的描述
• name：该权限的名称，使用该权限时通过名称来指定使用的权限
• protectionLevel：该权限受保护的等级，这很重要，它有三个等级
  • signature：签名级别权限，即权限的定义方和注册方必须具有相同的签名才有效
  • system：系统级别权限，即权限的定义方和注册方必须为系统应用
  • signatureOrSystem ：同签名或系统应用，上述二者具备其一即可

用刚定义的权限来保护暴露的组件（activity）

  <!--调用方必须申请此权限--><uses-permission android:name="com.littlejerk.sample.permission.WEB"/><activityandroid:permission="com.littlejerk.sample.permission.WEB"android:name=".other.WebActivity"><intent-filter><action android:name="com.littlejerk.sample.action.VIEW_URL" /><category android:name="android.intent.category.DEFAULT" /></intent-filter></activity>

个人思考：在项目中看到了 push模块 的权限声明、授权，有可能是集成三方平台时平台自己做的权限定义，如果从这方面来看平台可能已经尽可能降低了组件导出风险，至少不会造成二次导出风险