关于安卓开发.docx

关于安卓
与一切都是集中管理的iOS相比，Android提供了一种开放的环境，在获得了灵活性、可以满足各种定制需求的同时，也损失了部分安全性。
开发团队通常将精力集中在产品设计、功能实现、用户体验和系统效率等方面，而很少考虑安全问题。
Android提供的安全机制比较复杂，开发者需要理解它们，并对常见的攻击思路和攻击方法有所了解，才能有效地保护软件。
一方面，目前很少出现对特定移动软件安全漏洞的大规模针对性攻击，在真实的攻击出现之前，许多人对此并不重视。另一方面，利用这些漏洞展开攻击并不太难，许多攻击方法和工具都已经成熟。一旦出现这种攻击，用户的个人隐私数据可能发生泄漏，账户信息可能被盗取，如果与钓鱼等攻击结合，甚至可能产生经济损失。产品开发团队则可能由此面临信任危机和法律风险。
数据存储
Android软件可以使用的存储区域分为外部（SD卡）和内部（NAND闪存）两种。除了大小和位置不同之外，两者在安全权限上也有很大的区别。外部存储的文件没有读写权限的管理，所有应用软件都可以随意创建、读取、修改、删除位于外部存储中的任何文件，而仅仅需要申明READ_EXTERNAL_STORAGE和READ_EXTERNAL_STORAGE权限。内部存储则为每个软件分配了私有区域，并有基于Linux的文件权限控制，其中每个文件的所有者ID均为Android为该软件设立的一个用户ID。通常情况下，其他软件无权读写这些文件。
关于数据存储可能出现的问题包括以下几种。
将隐私数据明文保存在外部存储
例如，聊天软件或社交软件将聊天记录、好友信息、社交信息等存储在SD卡上；备份软件将通信录、短信等备份到SD卡上等。如果这些数据是直接明文保存（包括文本格式、XML格式、SQLite数据库格式等）的，那么攻击者写的软件可以将其读取出来，并回传至指定的服务器，造成隐私信息泄露。
较好的做法是对这些数据进行加密，密码保存在内部存储，由系统托管或者由用户使用时输入。
将系统数据明文保存在外部存储
例如，备份软件和系统辅助软件可能将用户已安装的其他软件数据保存至SD卡，以便刷机或升级后进行恢复等；或者将一些系统数据缓存在SD卡上供后续使用。同样的，如果这些数据是明文保存的，恶意软件可以读取它们，有可能用于展开进一步的攻击。
将软件运行时依赖的数据保存在外部存储
如果软件将配置文件存储在SD卡上，然后在运行期间读取这些配置文件，并根据其中的数据决定如何工作，也可能产生问题。攻击者编写的软件可以修改这些配置文件，从而控制这些软件的运行。例如，如果将登录使用的服务器列表存储在SD卡中，修改后，登录连接就会被发往攻击者指定的服务器，可能导致账户泄露或会话劫持（中间人攻击）。
对这种配置文件，较安全的方法是保存到内部存储；如果必须存储到SD卡，则应该在每次使用前判断它是否被篡改，例如，与预先保存在内部的文件哈希值进行比较。
将软件安装包或者二进制代码保存在外部存储
现在很多软件都推荐用户下载并安装其他软件；用户点击后，会联网下载另一个软件的APK文件，保存到SD卡然后安装。
也有一些软件为了实现功能扩展，选择动态加载并执行二进制代码。例如，下载包含了扩展功能的DEX文件或JAR文件，保存至SD卡，然后在软件运行时，，再通过Java反射，执行其中的代码。
如果在安装或加载前，软件没有对SD卡上的文件进行完整性验证，判断其是否可能被篡改或伪造，就可能出现安全问题。
在这里，攻击者可以使用称为“重打包”（re-packaging）的方法。目前大量Android恶意代码已采用这一技术。重打包的基本原理是，将APK文件反汇编，得到Dalvik指令的smali语法表示；然后在其中添加、修改、删除等一些指令序列，并适当改动Manifest文件；最后，将这些指令重新汇编并打包成新的APK文件，再次签名，就可以给其他手机安装了。通过重打包，攻击者可以加入恶意代码、改变软件的数据或指令，而软件原有功能和界面基本不会受到影响，用户难以察觉。
如果攻击者对软件要安装的APK文件或要加载的DEX、JAR文件重打包，植入恶意代码，或修改其原始代码；然后在SD 卡上，用其替换原来的文件，或者拷贝到要执行或加载的路径，当软件没有验证这些文件的有效性时，就会运行攻击者的代码。攻击结果有很多可能，例如直接发送扣费短信，或者将用户输入的账户密码发送给指定的服务器，或者弹出钓鱼界面等。
因此，软件应该在安装或加载位于SD卡的任何文件之前，对其完整性做验证，判断其与实现保存在内部存储中的（或从服务器下载来的）哈希值是否一致。
全局可读写的内