Android权限机制带来的一些安全问题介绍

Android引入了权限机制最初的出发点是为了通过权限策略来严格控制和处理安全问题，可参见：下面两篇文章，但关于这个Android权限的机制仍然存在一些很小但不容忽略的问题，另外正所谓道高一尺魔高一丈，仍然存在一些可以绕过权限的方法。本文旨在分析权限机制的一些缺点和不足，并不能以此文章作为非法应用的参考书。
Android Permission权限机制引子

Android Permission权限机制的具体使用

权限机制的缺陷和不足

(1) 应用程序可以自由地命名一个新的权限，无须遵循一定的命名规则和限制，期盼用户对不同应用程序(包括未曾安装过的程序)所使用的任意给定的权限名称保持警觉是不够明智的。
这句说的比较费劲，其实就是android对一个新的应用程序(Custom Permission App)声明权限时，并未规定权限的名称的命名规则和限制，无规则不成方圆，这不规则的名称多少会引起一些问题的。

(2) 权限一经被授权给应用程序后，在应用程序的生命期间，它将不会被移除，即使声明此权限的源程序被删除。
一个声明权限的应用程序(Custom Permission App)被删除之后，并没有一些机制去通知哪些使用该权限的应用(Custom Permission Client)，而是在使用该权限的应用(Custom Permission Client)运行到指定位置时需要使用权限是才报错。

(3) 一个系统内两个不同的权限可以声明相同的名字。

(4)权限不足时，Log会报，比如：

代码如下:

03-01 15:02:31.488: E/AndroidRuntime(565): java.lang.SecurityException: Permission Denial: starting Intent { cmp=com.example.custompermission/.MainActivity } from ProcessRecord{44ffc5e0 565:com.example.customtest/10043} (pid=565, uid=10043) requires custom.permission.STARTACTIVITY
03-01 15:02:31.488: E/AndroidRuntime(565): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)

所以别有用心的开发者会想通过这个途径去增加一定的权限(其他App声明的权限)，然后去call这个声明权限的App。

树立权限意识

劈开上面的缺陷不谈，我们仍然应该需要重视一款应用的权限，毕竟谷歌在Android权限方面已经做了很大的努力。

(1)用户初判断

用户可以通过下载的软件来判断权限是否过分，比如一款输入法就不应有发送短信的权限，一些记单词的程序就不应该有发送短信，查看联系人和短消息的权限。用户需要在安装应用程序前，需要有意识的注意每一个app的权限请求，Android会把一些high risk权限明显列出来而忽略一些比较low risk的权限，所以用户可以只看这些列出来的权限，并做到能去甄别它。

(2)第三方软件/ROM

可以通过第三方软件来限制权限，比如App Shield，这是是一个需要付费的Android应用，其原理是修改应用程序的apk安装包，删除其中AndroidManifest.xml文件内，用于声明权限的对应”Android.Permission.*”条目，然后再用一个公开的证书对安装包重新签名(需要允许”未知源”)，这样一来，应用程序就不会向系统申请原先所需的权限。当应用运行至相应的流程时，系统将直接拒绝，从而达到用户控制权限的目的。对于已安装的应用，AppShield也会按照同样方法制作好apk安装包，然后让用户先卸载原始的应用，再安装调整过的应用。除了该应用数字签名外，用户可以随时通过执行同样的流程，将吊销的权限恢复。当然第三方ROM也可以做到，比如MIUI在软件用到某一个权限时就会主动拦截并询问用户是否授予权限。

越过权限机制

可是–目前仍有几种方式可以越过权限机制，从而拥有不需申请权限的方式下使用需要申请权限的权限。

(1) root过的设备静默安装

如果你的手机已经被root过了，那么某些App就可以静默安装在你的手机里。
静默安装是指App在安装时不会有安装界面提示用户该App的权限等，而是直接将其安装在你的手机中，这样用户就会失去了最起码的通过权限去鉴别的机会；这其实不算越过权限机制，但是这些被静默安装的程序，不会展示权限就相当于没有任何权限了。

(2) 使用相同sharedUserId的应用程序

首先简单介绍下：sharedUserId
默认Android会给每个APK都分配一个单独的用户空间，即每个应用程序都有个UID，只有带着此UID，才能存取该UID所涵盖的有关资料。
所以如果AP-1与AP-2的UID不同，则在预设(Default)情况下，双方都无法读取对方的数据。这种分而治之的方式，可以减轻黑客软件的恶意伤害数据，提升手机的安全性。
但是如果两个应用程序都被签上了相同的UID即使用sharedUserId关键字。这个例子需要使用两个程序来配合使用，这两个程序在AndroidManifest.xml文件中都会声明一个相同的sharedUserId，比如下面：

再回到AP-1和AP-2上来，假设AP-1是一个看上去比较正规的程序，只有read contacts的权限，由于比较正规的外表，用户可能信任并安装了，后来用户一段时间后安装了AP-2，这个AP-2只有连接Internet的权限，但却可以轻松的将AP-1存储到数据库里面的联系人信息轻松到上传到Internet上了。

(3) 破解接受广播接收器(receiver)的程序

这个是用的比较多的一种方式，同样需要2个或者多个应用程序来配合。比如病毒开发者会分析到目前市面上比较流行的一些短信应用，并通过一定的技术反编译代码、JAVA反射等技术，总之能找到一个能让正常应用发送短信的receiver，然后通过自己的病毒应用去发送广播，以达到移花接木之目的。