公开/封闭属性android:exported引出的Android系统安全技术

公开/封闭属性android:exported引出的Android系统安全技术

android:exported是Android在AndroidManifest.xml里面配置Activity或其他组件如Service或广播等的基础属性，之所以在这里挑出来单独说，是因为该属性现在经常被一些粗糙的安全漏洞扫描系统错误的理解和使用，形成不正确的分析结论。
android:exported属性常用以配置一个Android的Activity之间共享数据或互相唤起，以便作为对外共享数据的基础配置之一（之所以说之一，后面还要再说其他共享属性配置），其默认值是false（封闭）。注意！这里所说的默认值是false，是说如果当前Activity没有配置任何<intent-filter>过滤器时候，android:exported才为false，如果当前Activity配置了过滤器<intent-filter>，那么android:exported的默认值是true。这里面还有一个细节问题，是关于不同Android SDK版本也有所不同，在低于SDK 16时候，默认是true，高于SDK 16则默认是false。
android:exported的属性值true或false决定当前App是否对外暴露供其他App程序分享数据，是否可以被手机上安装的其他App唤起。假设手机上安装两个App：A和B。A如果想启动B中的一个ActivityB，那么ActivityB必须配置成android:exported为true才可以。当配置android:exported为true时候，意味着自身App接收来自于手机上的其他App的消息事件，开放状态。
android:exported的属性需要考虑到具体的场景，该属性常被一些大厂使用，比如像腾讯旗下有不少在行业具有极高市场占有率的App，通常用户在安装QQ时候，也会安装微信，也许还会安装腾讯视频，像这样的情况，腾讯可以配置自己App中某些公共Service或者Activity的android:exported为true，然后若干Activity被自家其他App识别并唤起。更何况，要想使用腾讯的一些社交分享组件如分享到微信，分享到朋友圈，分享到QQ这些，就必须配置android:exported为true了。
还是回到两个App：A与B，事实上即便B中ActivityB配置了android:exported为true。A仍然达不到与B共享数据的目的（或A唤起B中ActivityB的目的）。就像前面说的android:exported=”true”只是开始，若想真正实现A与B共享数据，还必须同时设置android:sharedUserId。
当一个App安装到手机上，它就有一个唯一的android:sharedUserId，这个android:sharedUserId伴随App从安装到卸载整个周期。同样的一个App安装到不同的手机上，会具有不同的android:sharedUserId。android:sharedUserId对应的是底层Linux的一个用户。具有相同android:sharedUserId的App可以配置成运行在Linux相同的进程空间中（配置相同android:process）。反之，不具备相同android:sharedUserId的App们，Linux禁止它们互相访问数据。
android:sharedUserId像一个人的身份证一样标识不同的App，如果不同的App像共享数据，在Linux里面，就必须具备android:sharedUserId才可以，做到这一点儿需要两个App在各自的AndroidManifest.xml配置相同的android:sharedUserId。但是一旦两个App设置相同的android:sharedUserId，那么android:exported的属性配置全部失效变得没有意义，从这里可以看到，决定是否共享的重要属性是android:sharedUserId。
而现在一些安全漏洞扫描软件，通过简陋的读取AndroidManifest.xml中定义的Android组件，错误的分析认为没有配置android:exported就是漏洞，殊不知首先需要分析该组件是否配置了过滤器<intent-filter>，如果没有配置<intent-filter>，那么android:exported本身就是false。真正需要配置的当组件配置了<intent-filter>过滤器，此时就要认真配置android:exported这儿，如果打算公开出去，那么就配置为true（其实也不必，因为有了过滤器后，默认就是true），否则false。