Android开发中如何防范组件导出的风险

这篇文章将为大家详细讲解有关Android开发中如何防范组件导出的风险，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

前言

近年来，移动APP存在一个非常的重要的问题就是安全问题，造成的后果有可能是用户的隐私泄露和财产损失等，对于一款成熟的APP或者是金融银行类APP，这无疑是最致命的，所以对APP进行有效的防范也是很有必要。
近段时间，公司安排了某安全公司对我们的APP进行了全方面的安全测试，根据文档检测结果看，整体上看还是很安全的，其中有一项就是组件导出风险，接下来我们说说四大组件、组件导出必要性、风险以及如何防范。

一、四大组件

从事Android开发，我们都知道Android有四大组件， 分别是：

• 活动（Activity），用于表现功能，是用户操作的可视化界面，它为用户提供了一个完成操作指令的窗口；

• 服务（Service），后台运行服务，不提供界面呈现；

• 广播接受者（Broadcast Receive），用于接收广播；

• 内容提供者（Content Provider），支持多个应用中存储和读取数据，相当于数据库。

从这些组件简单的介绍，我们知道它们的重要性，赋予了app更加丰富的功能，所以这四大组件的安全性对我们app和用户来说就显得更加地重要。

二、组件导出必要性

什么是组件导出呢？组件导出的意思就是组件可以被外部应用调用，我们可以在这四大组件声明的清单文件设置组件是否导出，如下：

或者：

上面两种方式都是Activity组件导出的方式，主要是exported的值"，为true时表示导出，Activity中exported的默认值：

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

• 有intent filter时，默认为true

Broadcast Receive和Service的默认值都跟Activity的一样。
Content Provider中exported的默认值：

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

• 大于17时，默认为false

开发过程中，app会有一些特定需求会使用到三方SDK，如微信分享、支付、推送等功能，我们发现这里都有一个共同点，都会涉及到组件导出的问题，如微信的

WXEntryActivity：

这样就会被安全机构检测出来的，如果不设置WXEntryActivity为组件导出，微信分享等功能根本就调不起来，这是官方的写法，我们认为这是必须要设置为组件导出，除非你把微信分享需求干掉，那业务不把你骂死；又或者是监听网络变化的广播接收器（7.0版本以上只能代码中动态注册才能接收该广播）、推送功能，集成过一些推送SDK都有印象，一些Service也会声明android:exported="true"等等。

这些无可避免的组件导出，我们可以回复安全机构：微信分享、推送等功能必须设置组件导出，所以我们只有保证自己的四大组件的设置，确保其是安全的，这样才能确保app处于比较安全的状态，应付安全检测，给你的领导一个交代。

三、组件导出风险

前面说明了组件的重要性、组件导出，那么组件导出的风险是什么呢？

• Activity作为组成Apk的四个组件之一，是Android程序与用户交互的界面，如果Activity打开了导出权限，可能被系统或者第三方的App直接调出并使用。Activity导出可能导致登录界面被绕过、拒绝服务攻击、程序界面被第三方恶意调用等风险。

• Broadcast Receiver作为组成Apk的四个组件之一，对外部事件进行过滤接收,并根据消息内容执行响应，如果设置了导出权限，可能被系统或者第三方的App直接调出并使用。Broadcast Receiver导出可能导致敏感信息泄露、登录界面被绕过等风险。S

• ervice作为组成Apk的四个组件之一，一般作为后台运行的服务进程，如果设置了导出权限，可能被系统或者第三方的App直接调出并使用。Service导出可能导致拒绝服务攻击，程序功能被第三方恶意调用等风险。

• Content Provider组成Apk的四个组件之一，是应用程序之间共享数据的容器，可以将应用程序的指定数据集提供给第三方的App，如果设置了导出权限，可能被系统或者第三方的App直接调出并使用。Content Provider导出可能导致程序内部的敏感信息泄露，数据库SQL注入等风险。

接下来以Activity导出为示例，说明下其风险，其它组件类比就好。首先Activity要在清单文件AndroidManifest.xml注册：

Activity的启动通常有两种方法

• 显式启动，需要指定启动的Activity：

Intent intent = new Intent(getContext(),WebActivity.class);        intent.putExtra("URL","https://blog.csdn.net");        startActivity(intent);

• 隐式启动，Intent中不再包含需要启动的具体的Activity类，而是通过Intent提供某些信息，系统去检索符合启动意图的Activity，这里是通过意图过滤器声明Intent信息：动作（action）、数据（data）、分类（Category）、类型（Type），组件（Component）、和扩展信息（Extra）。

                                                                                //调用方式启动WebActivity        Intent intent = new Intent();        intent.setAction("com.littlejerk.sample.action.VIEW_URL");        intent.putExtra("URL","https://blog.csdn.net");        startActivity(intent);

使用Action跳转，如果有一个程序的AndroidManifest.xml中的某一个 Activity的IntentFilter段中 定义了包含了相同的Action，那么这个Intent就与这个目标Action匹配。如果这个IntentFilter段中没有定义 Type、Category，那么这个 Activity就匹配了。但是如果手机中有两个以上的程序匹配，那么就会弹出一个对话框来提示说明。

上面说过有IntentFilter，如果不指定android:exported，那么该值默认为true，外部的应用通过隐式意图的方式也能将对应的组件启动起来。这种情况我们就是我们说的组件导出，而导出则意味着很有可能存在安全问题，接下来看下WebActivity页面：

Intent intent = getIntent();        String url = intent.getStringExtra("URL");        UILog.e(TAG, url.charAt(0));        mTvContent.setText(url);

我们注意到WebActivity只是接收一个URL并且显示出来（没有加载这个URL），从这里我们可以看出URL并没有做参数检验，应用可能会崩溃；因为该页面又是可被三方应用调用的，这时候如果别人恶意传递一些不良的网页信息，那你这个应用不拦截就直接加载了，则这个应用有可能就要下架了。

四、如何防范

我们以最常见的Activity为例说明了组件导出的风险，因为这个URL参数是我们处理的，我们可以防止应用空指针异常，这没问题，但是上面也说如果加载了不良URL呢？其实组件导出的风险最根本原因是被别人调用了，那这样有没有办法控制这个别人的范围，只允许我们信赖的人去调用。
在这里不得不提Android的权限机制，Android的Permission检查机制是用来控制一个应用拥有哪些执行权利。例如应用拥有拍照权限才能拥有拍照权利，那么我们是否可以通过权限来控制一个应用是否有启动WebActivity的权利呢？
Android提供了自定义权限的能力，应用可以定义自己的权限，如在清单文件中自定义一个permission：

label：权限的描述

name：该权限的名称，使用该权限时通过名称来指定使用的权限

protectionLevel：该权限受保护的等级，这很重要，它有三个等级

• signature：签名级别权限，即权限的定义方和注册方必须具有相同的签名才有效

• system：系统级别权限，即权限的定义方和注册方必须为系统应用

• signatureOrSystem ：同签名或系统应用，上述二者具备其一即可

权限定义完成，如何用它来保护暴露的组件呢，看下面代码：

在activity声明时，activity标签下有一个permission，通过permission就能指定保护该activity的权限名称了，这样，只有具有了该权限的activity才能启动它（注意在定义方和使用方都要在清单文件中定义和声明自定义的权限），在调用方的清单文件中声明和使用该权限：

有了权限的控制，activity组件导出的范围就可控了，当我们公司应用间存在相互的组件调用时，就可以使用同签名的权限来做限制，至于其它应用因为不是相同的签名，所以它们无法调用我们暴露出去的组件，这很有效地规避了风险。

Activity是我们最常见的一个组件了，但是BroadcastReceiver用的地方也不少，一般安全评测都有提到这个组件的，我们有必要提一提它，其实各个组件的安全控制也可通过permission来控制的。
BroadcastReceiver的注册有两种方式

• 静态注册，在Manifest中声明注册

• 动态注册，在代码中依赖其他组件，通过registerReceiver注册

BroadcastReceiver有广播的发送方和接收方，所以当使用permission来校验通信的时候一般都需要双向校验，即广播的方送方和接收方都需要添加权限检验，保证发送方只将广播发送给信赖的接收方，同样的接收方也只接受来自信赖方的广播。

广播发送方

发送方需要在清单文件AndroidManifest.xml中声明权限：

然后使用sendBroadcast(Intent intent, String receiverPermission)方法发送广播：

//发送广播        Intent intent = new Intent();        intent.setAction("com.littlejerk.sample.broadcast.action.TEST");        sendBroadcast(intent, "com.littlejerk.sample.permission.BROADCAST_SEND");

从receiverPermission字面意思就知道，接收广播方必须要申请com.littlejerk.sample.permission.BROADCAST_SEND这个自定义权限，不然，无法接收到action通知，如接收方的清单文件AndroidManifest.xml：

如果接收方的广播接收器不控制自己的权限，则同开发者应用只监听com.littlejerk.sample.broadcast.action.TEST这个action就行了，但是为了双重检验，我们也需要给接收方声明自己的权限。

广播接收方

我们定义一个广播接收器TestReceiver：

public class TestReceiver extends BroadcastReceiver {    private static final String TAG = "TestReceiver";    //接收到广播信息的回调    @Override    public void onReceive(Context context, Intent intent) {        //对外来的参数应该做些合法的检查        String action = intent.getAction();        if (TextUtils.isEmpty(action)) {            return;        }        UILog.e(TAG, "action：" + action);    }}

接着在清单文件AndroidManifest.xml中声明控制权限：

然后把这个控制权限给广播接收器，接收器有两种注册方式
静态注册方式，在清单文件AndroidManifest.xml中：

然后是动态注册方式，在你需要注册的地方声明：

Receiver receiver = new Receiver();IntentFilter intentFilter = new IntentFilter();intentFilter.addAction("com.littlejerk.sample.broadcast.action.TEST");registerReceiver(receiver, intentFilter, "com.littlejerk.sample.permission.BROADCAST_RECEIVER", null);

这两种注册方式都可以，但是推荐使用动态注册广播的方式，因为Android O上为了App性能和功耗的考虑，对静态注册的广播做了很大的限制，至于是什么限制，这里就不说了。
我们对接收器也做了权限限制，那么发送方也必须要申请这个权限才能发送action给它呀，所以发送方的清单文件AndroidManifest.xml中在原有的基础上需要添加：

至此，广播的双向检验就完成了，以上所有代码都测试过了，没有任何问题，很好地过滤了无关广播，保护了组件的安全。

关于Android开发中如何防范组件导出的风险就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。