Android应用的安全隐患＊

转自： http://www.cnblogs.com/chi0591/p/3864747.html

Android应用的安全隐患包括三个方面：

• 代码安全
• 数据安全
• 组件安全

代码安全

　　代码安全主要是指Android apk有被篡改、盗版等风险，产生代码安全的主要缘由是apk很容易被反编译、重打包。咱们能够采用如下方法对apk进行保护：

1.代码混淆

　　代码混淆能够在必定程度上增长apk逆向分析的难度。Android SDK从2.3开始就加入了ProGuard代码混淆功能，开发者只需进行简单的配置就能够实现对代码的混淆。

2.Apk签名校验

　　每个软件在发布时都须要开发人员对其进行签名，而签名使用的密钥文件时开发人员所独有的，破解者一般不可能拥有相同的密钥文件，所以可使用签名校验的方法保护apk。Android SDK中PackageManager类的getPackageInfo()方法就能够进行软件签名检测。

3.Dex文件校验

　　重编译apk其实就是重编译了classes.dex文件，重编译后，生成的classes.dex文件的hash值就改变了，所以咱们能够经过检测安装后classes.dex文件的hash值来判断apk是否被重打包过。

　　（1）读取应用安装目录下/data/app/xxx.apk中的classes.dex文件并计算其哈希值，将该值与软件发布时的classes.dex哈希值作比较来判断客户端是否被篡改。

　　（2）读取应用安装目录下/data/app/xxx.apk中的META-INF目录下的MANIFEST.MF文件，该文件详细记录了apk包中全部文件的哈希值，所以能够读取该文件获取到classes.dex文件对应的哈希值，将该值与软件发布时的classes.dex哈希值作比较就能够判断客户端是否被篡改。

　　为了防止被破解，软件发布时的classes.dex哈希值应该存放在服务器端。

　　另外因为逆向c/c++代码要比逆向Java代码困难不少，因此关键代码部位应该使用Native C/C++来编写。

4.逆向工具对抗

　　对apk进行重打包经常使用的工具是apktool，apktool对于后缀为PNG的文件，会按照PNG格式进行处理，若是咱们将一个非PNG格式文件的文件后缀改成PNG，再使用apktool重打包则会报错。

　　以上是使用比较多的几种保护方法，单独使用其中一种效果不大，应该综合运用。

5.调试器检测

　　为了防止apk被动态调试，能够检测是否有调试器链接。在Application类中提供了isDebuggerConnected()方法用于检测是否有调试器链接，若是发现有调试器链接，能够直接退出程序。

6.加壳保护

　　使用加壳程序防止apk逆向是一种很是有效的方式，也是一个趋势。Jack_Jia在《Android APK加壳技术方案》一文中详细阐述了Android apk加壳原理以及几种加壳方案的具体实现。咱们能够利用这几种方案对apk进行加壳。

　　不过这种加壳方式是在Java层实现的，被反编译的风险仍然很大。为了克服这个缺点，从此能够研究采用以下思路来进行保护：

　　将核心业务逻辑代码放入加密的.jar或者.apk文件中，在须要调用时使用Native C/C++代码进行解密，同时完成对解密后文件的完整性校验。若是须要更加安全的保护方法，能够考虑对so文件（Native C/C++代码编译获得的文件）进行加壳。Android so加壳主要须要解决两个问题：

• 对ELF文件加壳；
• 对Android SO的加载、调用机制作特殊处理。

　　这将是之后Android应用安全研究的一个方向。

数据安全

7.存储安全问题

关于数据存储可能出现的问题包括以下几点：

（1）明文存储敏感数据，致使直接被攻击者复制或篡改。

• 将隐私数据明文保存在外部存储
• 将系统数据明文保存在外部存储
• 将软件运行时依赖的数据保存在外部存储
• 将软件安装包或者二进制代码保存在外部存储
• 全局可读写的内部文件存储

（2）不恰当存储登录凭证，致使攻击者利用此数据窃取网络帐户隐私数据。

解决方案：

• 对这些数据进行加密，密码保存在内部存储，由系统托管或者由用户使用时输入。
• 对应用配置文件，较安全的方法是保存到内部存储；若是必须存储到SD卡，则应该在每次使用前检验它是否被篡改，与预先保存在内部的文件哈希值进行比较。
• 应用若是须要安装或加载位于SD卡的任何文件，应该先对其完整性作验证，判断其与实现保存在内部存储中的（或从服务器下载来的）哈希值是否一致。
• 若是要跨应用进行数据共享，有种较好的方法是实现一个Content Provider 组件，提供数据的读写接口并为读写操做分别设置一个自定义的权限。
• 对于登陆凭证的存储，使用基于凭据而不是密码的协议知足这种资源持久访问的需求，例如OAuth。

8.传输安全问题

• 不使用加密传输

• 使用加密传输但忽略证书验证环节

　　如开发者在代码中不检查服务器证书的有效性，或选择接受全部的证书时，这种作法可能会致使中间人攻击。

　　咱们在对敏感数据进行传输时应该采用基于SSL/TLS的HTTPS进行传输。因为移动软件大多只和固定的服务器通讯，咱们能够采用“证书锁定”（certificate pinning）方式在代码更精确地直接验证服务器是否拥有某张特定的证书。

组件安全

　　android应用内部的Activity、Service、Broadcast Receiver等组件是经过Intent通讯的，组件间须要通讯就须要在Androidmanifest.xml文件中配置，不恰当的组件配置则会带来风险。

9.可能产生的风险

• 恶意调用
• 恶意接受数据
• 仿冒应用，例如（恶意钓鱼，启动登陆界面）
• 恶意发送广播、启动应用服务。
• 调用组件，接受组件返回的数据
• 拦截有序广播

10.解决办法

• 最小化组件暴露

 不参与跨应用调用的组件添加android:exported="false"属性，这个属性说明它是私有的，只有同一个应用程序的组件或带有相同用户ID的应用程序才能启动或绑定该服务。

• 设置组件访问权限

 对参与跨应用调用的组件或者公开的广播、服务设置权限。只有具备该权限的组件才能调用这个组件。

• 暴露组件的代码检查

　　Android 提供各类API来在运行时检查、执行、授予和撤销权限。这些 API 是 android.content.Context 类的一部分，这个类提供有关应用程序环境的全局信息。

　　另外，Android应用也会存在不少传统web漏洞，好比SQL注入，xss漏洞等，代码级防止出现这些漏洞的方法与web应用防护方法相同。

Android系统安全防护

11.操做系统安全问题

• Android root问题
• 系统漏洞，补丁更新不及时
• 认证机制问题

12.系统安全解决方案

12.1 权限管理与隔离

　　对运行在Android系统上的应用程序进行权限的细粒度管理和隔离，防止越权行为的发生和滥用权限获取敏感数据。

　　能够采用MAC（Mandatory Access Control）强制访问控制模型实现。它是一个针对Linux的安全增强系统SELinux中使用的安全模型，即任何进程想在SELinux系统中干任何事情，都必须先在安全策略配置文件中赋予权限。凡是没有出如今安全策略配置文件中的权限，进程就没有该权限。Google在Android 4.4上正式推出了一套以SELinux为基础的系统安全机制SEAndroid。因此若是咱们要定制一个Android系统，能够采用具备SEAndroid安全机制的Android 4.4版本。

12.2 内核与应用层漏洞防御

　　增长补丁更新功能，若是发现漏洞，及时提醒用户进行系统补丁更新。

12.3 恶意程序检测与防御

　　创建一套恶意代码防御模型，对运行在Android系统上的恶意程序进行检测，抵御恶意代码的入侵。

12.4 数据安全存储与传输

　　对Android系统上的数据存储和数据传输进行加密保护，保证终端上数据可以安全地使用。