1、Android安全问题产生的根源
【51CTO专稿】研究人员已发现Android上的流行软件广泛存在安全陷阱与安全漏洞，漏洞频发的缘由可能有不少，主要有以下几种：
- 与一切都是集中管理的IOS相比，Android提供了一种开放的环境，在得到了灵活性、能够知足各类定制需求的同时，也损失了部分安全性。
- 开发团队一般将精力集中在产品设计、功能实现、用户体验和系统等方面，而不多考虑安全问题
- Android提供的安全机制比较复杂，开发者须要理解它们，并对相应的***思路和***方法有所了解，才能有效地保护软件。
- 一方面，目前不多出现对特定移动软件安全漏洞的大规模针对性***，在真实的***出现以前，许多人对此并不重视，另外一方面，利用这些漏洞展开***并不太难，许多***方法和工具都已经成熟，一旦出现这种***，用户的我的隐私数据可能发生泄漏，帐户信息可能被收集，若是与钓鱼等***结合，甚至可能产生经济损失。产品开始团队则可能由此面临信任危机和法律风险。
下面简单的例举几个不注重安全的现象，这些也是咱们Android开发团队容易忽略的地方。
2、数据存储安全问题
Android软件可使用的存储区域分外部（SD卡）和内部（NAND闪存）二种，除了大小和位置不一样以外，二者在安全权限上也有很大的区别。外部存储的文件没有读写权限的管理，全部应用软件均可以随意建立、读取、修改、删除位于外部存储中的任何文件，而Android的应用则只须要申明READ_EXTERNAL_STORAGE和WRITE_EXTERNAL_STORAGE权限。
内部存储则为每一个软件分配了私有区域，并有基本Linux的文件权限控制，其中每一个文件的全部者ID均为该软件设立的一个用户ID，其余软件无权读写这些文件。
关于数据存储可能出现的问题包括以下几点：
将隐私数据明文保存在外部存储
例如，聊天软件或社交软件将聊天记录、好友信息、社交信息等存储在SD卡上；备份软件将通讯录、短信等备份到SD卡上等，若是这些数据是直接明文保存（包括文本格式、XML格式、SQLite数据库格式等）的，那么***者写的软件能够将其读取出来，并加传到指定的服务器，形成隐私信息泄露。较好的作法是对这些数据进行加密，密码保存在内部存储，由系统托管或者由用户使用时输入。
将系统数据明文保存在外部存储
例如，备份软件和系统辅助将用户数据备份到安装的其余的SD卡，以便刷机或升级后进行恢复等；或者将一些系统数据缓存在SD卡上供后续使用，一样的，这些数据是明文保存的，恶意软件能够读取它们，有可能用于展开进一步的***。
将软件运行时依赖的数据保存在外部存储
若是软件将配置文件存储在SD卡上，而后在运行期间读取这些配置文件，并其中的数据决定如何工做，也可能产生问题。***者编写的软件能够修改这些配置文件，从而控制这些软件的运行。例如将登陆使用的服务器列表存储在SD卡中，修改后，登陆链接就会被发往***者指定的服务器，可能致使帐户泄露或会话劫持(中间人***)。
对这种配置文件，较安全的方法是保存到内部存储；若是必须存储到SD卡，则应该在每次使用前检验它是否被篡改，与预先保存在内部的文件哈希值进行比较。
将软件安装包或者二进制代码保存在外部存储
如今不少软件都推荐用户下载并安装其余软件；用户点击后，会联网下载另外一个软件的APK文件，保存到SD卡而后安装。
也有一些软件为了实现功能扩展，选择动态加载并执行二进制代码。例如，下载包含了扩展功能的DEX文件或JRA文件，保存到SD卡，而后在软件运行时，使用dalvik.system.DexClassLoader类或者java.lang.ClassLoader类加载这些文件，再经过Java反射，执行其中的代码。
若是安装或者加载前，软件没有对SD卡 的文件进行完整性验证，判断其是否可能被篡改和伪造，就可能出现安全问题。
在这里，***者可使用称为“重打包”（re-packaging）的方法，目前大量Android恶意代码已经采用这一技术，重打包的基本原理是，将APK文件反汇编，获得 Dalivik指令的smali语法表示 ；而后在其中添加、修改、删除等一些指令序列，并适当改动Manifest文件；最后，将这些指令从新汇编并打包成新的APK文件，再次签名，就能够给其余手机安装了，经过重打包，***者能够加入恶意代码、改变数据或指令，而软件原有功能和界面基本不会受到影响，用户难以察觉。
若是***者对软件要安装的APK文件或要加载DEX、JAR文件重打包，植入恶意代码，或修改其代码；而后在SD卡上，用其替换原来的文件，或者拷贝到要执行或加载 的路径，当软件没有验证这些文件的有效性时，就会运行***者的代码***。结果有不少可能，例如直接发送扣费短信，或者将用户输入的帐户密码发送给指定的服务器，或者弹出钓鱼界面等。
所以，软件应该在安装或加载位于SD卡的任何文件以前，对其完整性作验证，判断其与实现保存在内部存储中的（或从服务器下载来的）哈希值是否一致。
全局可读写的内部文件
若是开发者使用openFileOutPut(String name,int mode)方法建立内部文件时，将第二个参数设置为Context.MODE_WORLD_READABLE或者Context.MODE_WORLD_WRITEABLE，就会让这个文件变为全局可读或全局可写的。
开发者这样作是为了实现不一样软件之间的数据共享，但这种问题在于没法控制哪一个软件能够读写，因此***者的恶意软件也拥有这一权限。
若是要跨应用有种较好的方法是实现一个Content Provider 组件，提供数据的读写接口并为读写操做分别设置一个自定义的权限。
内部敏感文件被root权限软件读写
若是***者的软件已得到root权限，天然能够随意读写其余软件的内部文件，这种状况 并很多见。
1)大量的第三方定制ROM提供了root 权限管理工具，若是***者构造的软件伪形成一些功能强大的工具。能够欺骗用户授予它root权限。
2)即使手机预装的官方系统，国内用户也大多乐于解锁，即recovery并刷入toot管理工具。
3)在Android2.2和2.3中，存在一些可用于获取root权限的漏洞，而且对这种漏洞的利用不须要用户的确认。
4)所以，咱们并不能假设其余软件没法获取root权限。即便是存在内部数据，依然有被读取或修改的可能。
5)前面提到，重要、敏感、隐私的数据应使用内部存储，如今又遇到root后这些数据依然可能被读取的问题。我对这个问题的观点是，若是***者铤而走险获取root权限（被用户或者被安全软件发现的风险），那理论上他已经拥有了系统的完整控制权，能够直接得到联系人信息、短信记录等，甚至帐户密码、会话凭证、帐户数据等。例如，早期Google钱包将用户的信用卡数据明文存储，***者获取这些数据后，能够假装成持卡人进行进一步***以得到帐户使用权。这种数据就是“其余软件管理的重要数据”。
6)这个问题并无通用的解决方法，开发者可能须要根据实际状况寻找方案，并在可用性与安全性以前作出恰当的选择。
