做网站一般注意些什么,做药的常用网站有哪些,erp系统软件有哪些,医院网站建设方案计划在安全审查中关于组件导出风险是一种常见问题#xff0c;不同组件都有可能遇到这种问题#xff0c;而且从一定角度来看的话#xff0c;如果涉及到三方业务#xff0c;基本处于无法解决的场景#xff0c;所以我们需要说明为何无法避免这种风险 组件导出风险能不能规避… 在安全审查中关于组件导出风险是一种常见问题不同组件都有可能遇到这种问题而且从一定角度来看的话如果涉及到三方业务基本处于无法解决的场景所以我们需要说明为何无法避免这种风险 组件导出风险能不能规避能不能解决
如果你的组件风险是由 exported 属性所引起那么可以规避也可以解决只要将 exported 设置为 false 即可 这样外部就无法调用项目内组件了自然就避免了风险的产生同时带来了一些不太好的结果例如业务出错、功能缺失等等毕竟 很多项目内集成的三方平台SDK都是需要 exported 所附带的权限的
最终结果当 组件导出风险 遇到三方业务时很多时候我们可能无法规避这类型风险 雨 基础分析那些无法解决的风险场景Activity 组件导出风险Service 组件导出风险Broadcast Receiver组件导出风险 定义权限、保护组件 基础分析 组件导出风险一般都是由 android:exported 属性引起的如果我们在 AndroidManifest 对应组件内声明了 android:exportedtrue意味着允许让外部组件启动这个组件反之则不允许让外部组件启动这个组件 初步搜索后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 组件导出风险
检测方式
反编译提取应用的 AndroidManifest 文件并解析获取所有注册的Activity组件查看是否显式的设置可导出信息或者配置了意图过滤器
微博分享SDK配置 解决方式像这种三方平台组件一般都无法解决主要是因为涉及到已有业务除非剥离业务但这也不现实~ 所以只需要反馈到安全机构因XX业务原因无法规避这类型风险
Service 组件导出风险
检测方式
反编译提取应用的 AndroidManifest 文件并解析获取所有注册的 Service 组件查看是否显式的设置了可导出信息或者配置了意图过滤器
魅族推送、通知服务配置 解决方式像这种三方平台组件一般都无法解决主要是因为涉及到已有业务除非剥离业务但这也不现实~ 所以只需要反馈到安全机构因XX业务原因无法规避这类型风险图中的就是微博分享的业务功能
Broadcast Receiver组件导出风险
检测方式
反编译提取应用的 AndroidManifest 文件并解析获取所有注册的 Receiver 组件查看是否显式的设置了可导出信息或者配置了意图过滤器
极光推送-小米推送相关业务配置 定义权限、保护组件 权限过滤中涉及到了权限定义参考 Android 组件导出风险及防范 做个笔记 Android提供了自定义权限的能力应用可以定义自己的权限如在清单文件中自定义一个 permission permissionandroid:label允许打开WebActivity页面权限android:namecom.littlejerk.sample.permission.WEBandroid:protectionLevelsignature /label权限的描述name该权限的名称使用该权限时通过名称来指定使用的权限protectionLevel该权限受保护的等级这很重要它有三个等级 signature签名级别权限即权限的定义方和注册方必须具有相同的签名才有效system系统级别权限即权限的定义方和注册方必须为系统应用signatureOrSystem 同签名或系统应用上述二者具备其一即可
用刚定义的权限来保护暴露的组件activity !--调用方必须申请此权限--uses-permission android:namecom.littlejerk.sample.permission.WEB/activityandroid:permissioncom.littlejerk.sample.permission.WEBandroid:name.other.WebActivityintent-filteraction android:namecom.littlejerk.sample.action.VIEW_URL /category android:nameandroid.intent.category.DEFAULT //intent-filter/activity个人思考在项目中看到了 push模块 的权限声明、授权有可能是集成三方平台时平台自己做的权限定义如果从这方面来看平台可能已经尽可能降低了组件导出风险至少不会造成二次导出风险
