一、Android安全问题产生的根源
【51CTO专稿】研究人员已发现Android上的流行软件普遍存在安全陷阱与安全漏洞，漏洞频发的原因可能有很多，主要有如下几种：
- 与一切都是集中管理的IOS相比，Android提供了一种开放的环境，在获得了灵活性、可以满足各种定制需求的同时，也损失了部分安全性。
- 开发团队通常将精力集中在产品设计、功能实现、用户体验和系统等方面，而很少考虑安全问题
- Android提供的安全机制比较复杂，开发者需要理解它们，并对相应的攻击思路和攻击方法有所了解，才能有效地保护软件。
- 一方面，目前很少出现对特定移动软件安全漏洞的大规模针对性攻击，在真实的攻击出现之前，许多人对此并不重视，另一方面，利用这些漏洞展开攻击并不太难，许多攻击方法和工具都已经成熟，一旦出现这种攻击，用户的个人隐私数据可能发生泄漏，账户信息可能被收集，如果与钓鱼等攻击结合，甚至可能产生经济损失。产品开始团队则可能由此面临信任危机和法律风险。
下面简单的例举几个不注重安全的现象，这些也是我们Android开发团队容易忽略的地方。
二、数据存储安全问题
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)这个问题并没有通用的解决方法，开发者可能需要根据实际情况寻找方案，并在可用性与安全性之前做出恰当的选择。
本文转自samsunglinuxl51CTO博客，原文链接： http://blog.51cto.com/patterson/1162020
，如需转载请自行联系原作者
