Android软件安全开发实践（下）

Android开发是当前最火的话题之一，但不多有人讨论这个领域的安全问题。本系列将分两期，探讨Android开发中常见的安全隐患和解决方案。第一期将从数据存储、网络通讯、密码和认证策略这三个角度，带你走上Android软件安全开发实践之旅。

过去两年，研究人员已发现Android上的流行软件广泛存在安全缺陷或安全漏洞。漏洞频发的缘由可能有不少，例如如下几种。

• 与一切都是集中管理的iOS相比，Android提供了一种开放的环境，在得到了灵活性、能够知足各类定制需求的同时，也损失了部分安全性。

• 开发团队一般将精力集中在产品设计、功能实现、用户体验和系统效率等方面，而不多考虑安全问题。

• 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卡，而后在软件运行时，使用 dalvik.system.DexClassLoader类或者java.lang.ClassLoader类加载这些文件，再经过Java反射，执行 其中的代码。

若是在安装或加载前，软件没有对SD卡上的文件进行完整性验证，判断其是否可能被篡改或伪造，就可能出现安全问题。

在这里，攻击者可使用称 为“重打包”（re-packaging）的方法。目前大量Android恶意代码已采用这一技术。重打包的基本原理是，将APK文件反汇编，获得 Dalvik指令的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权限，天然能够随意读写其余软件的内部文件。这种状况并很多见。

• 大量的第三方定制ROM提供了root权限管理工具，若是攻击者构造的软件伪形成一些功能强大的工具，能够欺骗用户授予它root权限。

• 即使手机安装的官方系统，国内用户也大多乐于解锁、刷recovery并刷入root管理工具。

• 在Android 2.2和2.3中，存在一些能够用于获取root权限的漏洞，而且对这种漏洞的利用不须要用户的确认。

所以，咱们并不能假设其余软件没法获取root权限。即使是存在内部的数据，依然有被读取或修改的可能。

前面提到，重要、敏感、隐私的数据应使用内部存储，如今又遇到root后这些数据依然可能被读取的问题。我对这个问题的观点是，若是攻击者铤而走险得到root权限（被用户觉察或者被安全软件发现的风险），那理论上他已拥有了系统的完整控制权，能够直接得到联系人信息、短信记录等。此时，攻击者感兴趣的 软件漏洞利用更多是得到其余由软件管理的重要数据，例如帐户密码、会话凭证、帐户数据等。例如，早期Google钱包将用户的信用卡数据明文存储，攻击 者获取这些数据后，能够假装成持卡人进行进一步攻击以得到帐号使用权。这种数据就是“其余由软件管理的重要数据”。

这个问题并无通用的解决方法。开发者可能须要根据实际状况寻找方案，并在可用性与安全性之间作出恰当的选择。

网络通讯

Android软件一般使用WiFi网络与服务器进行通讯。WiFi并不是老是可信的。例如，开放式网络或弱加密网络中，接入者能够监听网络流量；攻击者能够本身设置WiFi网络钓鱼。此外，在得到root权限后，还能够在Android系统中监听网络数据。

不加密地明文传输敏感数据

最危险的是直接使用HTTP协议登陆帐户或交换数据。例如，攻击者在本身设置的钓鱼网络中配置DNS服务器，将软件要链接的服务器域名解析至攻击者的另外一台服务器；这台服务器就能够得到用户登陆信息，或者充当客户端与原服务器的中间人，转发双方数据。

早期，国外一些著名社交网站的Android客户端的登陆会话没有加密。后来出现了黑客工具FaceNiff，专门嗅探这些会话并进行劫持（它甚至支持在WEP、WPA、WPA2加密的WiFi网络上展开攻击！）。这是目前我所知的惟一一个公开攻击移动软件漏洞的案例。

这类问题的解决方法很显然—对敏感数据采用基于SSL/TLS的HTTPS进行传输。

SSL通讯不检查证书有效性

在SSL/TLS通讯中，客户端经过数字证书判断服务器是否可信，并采用证书中的公钥与服务器进行加密通讯。

然而，有开发者在代码中不检查服务器证书的有效性，或选择接受全部的证书。例如，开发者能够本身实现一个X509TrustManager接口，将其中的 checkServerTrusted()方法实现为空，即不检查服务器是否可信；或者在SSLSocketFactory的实例中，经过 setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER)，接受全部证 书。作出这两种选择的可能缘由是，使用了本身生成了证书后，客户端发现证书没法与系统可信根CA造成信任链，出现了 CertificateException等异常。

这种作法可能致使的问题是中间人攻击。

在钓鱼WiFi网络中，一样地，攻 击者能够经过设置DNS服务器使客户端与指定的服务器进行通讯。攻击者在服务器上部署另外一个证书，在会话创建阶段，客户端会收到这张证书。若是客户端忽略 这个证书的异常，或者接受这个证书，就会成功创建会话、开始加密通讯。但攻击者拥有私钥，所以能够解密获得客户端发来数据的明文。攻击者还能够模拟客户 端，与真正的服务器联系，充当中间人作监听。

解决问题的一种方法是从可信CA申请一个证书。但在移动软件开发中，不推荐这种方法。除了申请 证书的时间成本和经济成本外，这种验证只判断了证书是否CA可信的，并无验证服务器自己是否可信。例如，攻击者能够盗用其余可信证书，或者盗取CA私钥 为本身颁发虚假证书，这样的攻击事件在过去两年已有屡次出现。

事实上，移动软件大多只和固定的服务器通讯，所以能够在代码中更精确地直接验 证是否某张特定的证书，这种方法称为“证书锁定”（certificate pinning）。实现证书锁定的方法有两种：一种是前文提到的实现X509TrustManager接口，另外一种则是使用KeyStore。具体可参考 Android开发文档中HttpsURLConnection类的概览说明。

使用短信注册帐户或接收密码

也有软件使用短信进行通讯，例如自动发送短信来注册、用短信接收初始密码、用短信接收用户重置的密码等。

短 信并非一种安全的通讯方式。恶意软件只要申明了SEND_SMS、RECEIVE_SMS和READ_SMS这些权限，就能够经过系统提供的API向任 意号码发送任意短信、接收指定号码发来的短信并读取其内容，甚至拦截短信。这些方法已在Android恶意代码中广泛使用，甚至2011年就已出现拦截并 回传短信中的网银登陆验证码（mTANs）的盗号木马Zitmo。

所以，这种经过短信注册或接收密码的方法，可能引发假冒注册、恶意密码重置、密码窃取等攻击。此外，这种与手机号关联的帐户还可能产生增值服务，危险更大。较好的实现方式仍是走Internet。

密码和认证策略

明文存储和编码存储密码

许多软件有“记住密码”的功能。若是开发者依字面含义将密码存储到本地，可能致使泄漏。

另 外，有的软件不是直接保存密码，而是用Base6四、固定字节或字符串异或、ProtoBuf等方法对密码编码，而后存储在本地。这些编码也不会增长密码 的安全性。采用smali、dex2jar、jd-gui、IDA Pro等工具，攻击者能够对Android软件进行反汇编和反编译。攻击者能够借此了解软件对密码的编码方法和编码参数。

较好的作法是，使用基于凭据而不是密码的协议知足这种资源持久访问的需求，例如OAuth。

对外服务的弱密码或固定密码

另外一种曾引发关注的问题是，部分软件向外提供网络服务，而不使用密码或使用固定密码。例如，系统辅助软件常常在WiFi下开启FTP服务。部分软件对这个FTP服务不用密码或者用固定密码。在开放或钓鱼的WiFi网络下，攻击者也能够扫描到这个服务并直接访问。

还有弱密码的问题。例如，早期Google钱包的本地访问密码是4位数字，这个密码的SHA256值被存储在内部存储中。4位数字一共只有10000种状况，这样攻击软件即使是在手机上直接暴力破解，均可以在短期内得到密码。

使用IMEI或IMSI做为惟一认证凭据

IMEI、IMSI是用于标识手机设备、手机卡的惟一编号。若是使用IMSI或IMEI做为用户认证的惟一凭据，可能致使假冒用户的攻击。

首先，应用要获取手机的IMEI、手机卡的IMSI并不须要特殊权限。事实上，许多第三方广告库回传它们用于用户统计。其次，获得IMEI或IMSI后，攻 击者有多种方法伪形成用户与服务器进行通讯。例如，将原软件重打包，使其中获取IMEI、IMSI的代码始终返回指定的值；或修改Android代码，使 相关API始终返回指定的值，编译为ROM在模拟器中运行；甚至能够分析客户端与服务器的通讯协议，直接模拟客户端的网络行为。

所以，若使用IMEI或IMSI做为认证的惟一凭据，攻击者可能得到服务器中的用户帐户及数据。

 

咱们讨论了数据存储、网络通讯、密码和认证策略等安全问题和解决方案，本期将继续从组件间通讯、数据验证和保全保护等方面来实践Android软件安全开发之路。

组件间通讯

组件间通讯的安全问题是Android所独有的，也是目前软件中最常出现的一种问题。

咱们先回顾一下组件间通讯机制。Android有四类组件：activity、service、broadcast receiver和content provider。在同一个软件之中或不一样软件之间，前三种组件使用Intent相互调用，使用ContentResolver对象访问content provider，共同实现软件的功能。使用Intent，能够显式或隐式地调用：

• 显式（explicit）：调用者知道要调用谁，经过组件名指定具体的被调用者；

• 隐式（implicit）：调用者不知道要调用谁，只知道执行的动做，由系统选择组件处理这个请求。

以下面的代码所示：

不管是显式仍是隐式，若是要跨应用调用，还须要被调用的组件是对外暴露的。默认状况下，service、broadcast receiver和content provider是暴露的，申明了Intent-filter的actvity也是暴露的。

抽象地说，组件A要调用组件B，以期待B完成某个功能；它能够发送一些数据给组件B，也能够得到B执行后的返回结果。在这个模型中，问题出如今A和B之间不必定互相可信。

若是B是暴露的，任何软件均可以调用它，包括攻击者编写的软件。攻击者可能但并不是总能成功：

• 直接调用暴露的B，以得到其执行结果；

• 构造特定的数据，并用于调用暴露的B，从而试图影响B的执行；

• 调用暴露的B，并获取它执行完返回的结果。

若是A用的是隐式调用，任何软件均可以实现它的action从而响应调用。攻击者可能（但并不是总能成功）：

• 构造伪造的组件C，响应A的Intent，以读取A要发给B的数据；

• 构造伪造的组件C，响应A的Intent，弹出虚假的用户界面以展开进一步攻击（例如钓鱼）；

• 构造伪造的组件C，响应A的Intent，返回伪造的执行结果。

这样说可能比较抽象。下面咱们对这两种状况分别讨论。

组件暴露的问题

看一个例子。在一个第三方深度定制的ROM中，预装了名为Cit.apk的软件，用于手机的硬件测试。它的AndroidManifest.xml局部以下：

能够看到，它申明一个名为.CitBroadcastReceiver的receiver，响应名为android.provider.Telephony.SECRET_CODE的action，而且指定了URI格式。

再来看这个receiver的代码片断（下面的代码是我反编译获得的，不必定与软件源码彻底一致）：

能够看到，当调用这个receiver，而且提供的URI中host字段为284时，会以root权限调用本地的bugreport工具，并将结果输出至m_logFileName指定的文件中。

默认状况下receiver是暴露的，所以这个receiver能够被其余软件调用，代码以下：

当这四行代码执行时，就会触发CitBroadcast-Receiver的那段代码。从上下文看，输出文件m_logFileName位于SD卡，任何软件均可以随意读写。所以，攻击者能够得到bugreport的输出结果，其中包含大量系统数据和用户数据。

请注意，在这个例子中，攻击者的软件不须要任何特殊权限，尤为是不须要root权限。这种因为组件暴露得到额外权限的攻击，被称之为permission re-delegation（权限重委派）。

怎么避免因为组件暴露产生的安全问题？有的组件必须暴露，例如入口activity，或者确实对外提供服务或跨软件协做；但也有的组件不必暴露。接下来咱们分别讨论。

不须要暴露的组件

再次回顾，默认状况下，service、broadcast receiver和content provider是暴露的，申明了Intent-filter的actvity也是暴露的。若是它们只被同一个软件中的代码调用，应该设置为不暴露。很容 易作到—在AndroidManifest.xml中为这个组件加上属性android:exported=”false”便可。

须要暴露的组件

若是组件须要对外暴露，应该经过自定义权限限制对它的调用。

首先，在实现了被调用组件的软件的Android-Manifest.xml中自定义一个权限：

接下来，为被调用组件添加这个权限限制，即在AndroidManifest.xml中为这个组件添加android:permission属性：

另外一种方法是在组件的实现代码中使用Context.checkCallingPermission()检查调用者是否拥有这个权限。

最后，要调用这个暴露的组件，调用者所在的软件应该申明使用这个权限，即在AndroidManifest.xml中添加相应的use-permission申明。

进一步地，还能够将这种组件暴露的需求分为两种状况。

• 若是这个组件只打算给本身开发的其余软件使用，而不但愿暴露给第三方软件，在定义权限时，protectionLevel字段应该选择signature。 这种设置要求权限使用者（即调用者）与权限定义者（即被调用者）必须由相同的证书进行签名，所以第三方没法使用该权限，也就没法调用该组件。

• 若是这个组件要暴露给第三方，则protection-Level应使用normal或dangerous。此时，任何软件均可以使用该权限，只在安装时会 通知用户。考虑到用户通常会忽略权限提示，此时自定义权限实际失去了保护效果，咱们依然要仔细审查该组件的代码，避免出现能力泄露或权限重委派等问题。

此外，对content provider，能够更细粒度地为读取数据和写入数据设置不一样的权限，对应的manifest标签分别为android:readPermission和android:writePermission。

隐式调用的问题

隐式调用的主要问题是被劫持，或Intent携带的数据被读取。

为了劫持调用，攻击者能够实现一个恶意的组件，申明相同的Intent-filter。在多个组件均可以响应同一个Intent的状况下，若是是调用 activity，系统会弹出界面要求用户对多个软件作出选择，攻击者能够模仿真实软件的图标和名称吸引用户点击；若是是调用service，系统会随机 选择一个service；若是是调用receiver，系统会逐一地将Intent发给这些receiver。

劫持了调用后，攻击者能够（但并不是总能成功）：

• 启动一个虚假的软件界面，展开钓鱼攻击（例如要求用户输入帐户密码）

• 读取Intent携带的数据

• 拦截broadcast的进一步发送，致使真正的receiver没法收到消息，从而拒绝服务

• 若是是用startActivityForResult()调用了虚假的activity，能够返回恶意或虚假的结果给调用者

• 执行其余恶意代码

限于篇幅，对这些情形咱们不提供示例代码。来看一下怎么解决这类问题。

不须要隐式调用

除了基于Intent类中已有ACTIONs的隐式调用，绝大部分隐式调用都属于这两种状况：同一软件中不一样组件的调用；同一开发者不一样软件间的调用。

这两种状况下，事实上，开发时都已能够肯定要调用的组件是哪一个。所以能够避免隐式调用，改成基于组件名的显式调用。

须要隐式调用

发送broadcast除了使用sendBroadcast(Intent)，还有一个方法是sendBroadcast(Intent, String)，它的第二个参数能够指定接受者须要的权限。

若是是调用activity或者service，目前我所知，尚未简单的方法实现接收者的权限限制。在Android文档中提出能够自定义Binder和AIDL实现通讯双方的互相验证，但真正实现并不容易，也不为官方所推荐。

数据验证

不管是客户端仍是服务器，在处理外部得到的数据以前，都应先判断和验证数据的有效性。这里主要指是否包含畸形的数据。

在 Web开发中，服务器须要对用户提交的数据进行有效性验证，不然很容易出现众所周知的SQL注入等攻击。在移动开发中也不例外。虽然客户端与服务器在底层 通讯协议上对用户是透明、不可见的，但开发者不该所以就假设双方传输的数据永远会和预先设计的一致。相似的，在读取用户从UI元素输入的输入、读取存储在 本地的数据后，使用前也应进行有效性验证。

软件版权保护

攻击者对Android软件进行逆向分析，除了寻找其中的安全漏洞，还能够直接攻击软件自己。

• 破解软件的收费机制、License验证或功能限制；

• 修改软件代码，去掉广告库，或者修改广告库（通常是改变推介ID字段），或者增长广告库，而后从新打包并分发；

• 从新打包，植入恶意代码并分发；

• 逆向分析，学习软件特点功能的实现方法，或者得到可复用的代码；

能够采起多种措施来增长破解、修改和逆向分析的难度，减小被攻击的可能。这些措施包括：

• 使用代码混淆工具，例如SDK带的ProGuard以及其余Java混淆器。

• 采用NDK开发核心模块。

• 使用官方或第三方的软件保护方案，例如SDK的android.drm包、Google Play的软件许可（Application Licensing）支持。

• 去掉开发时的调试代码，关闭调试开关，删除多余的Log代码。

然而，采起了这些措施并不等于就万无一失了。例如，用NDK开发的Native代码，也可使用IDA Pro及其插件来反汇编、反编译和调试；用Google的DRM方案，也有AntiLVL这样的破解工具。理论上，现有防护手段均可能找到方法继续攻击， 其价值只是提升攻击难度和成本。

总结

已出现和将要出现的威胁

到 目前为止，在学术研究之外，针对Android软件漏洞的攻击只出现一块儿—劫持国外多个社交网站客户端登录会话的黑客工具FaceNiff。但随着攻击者 制造传播恶意代码的成本增长和收益下降，以及移动终端隐私数据逐渐成为地下产业链的交易资源，针对Android流行软件漏洞的攻击在将来几年以内几乎一 定会出现并爆发。

统一的安全模型

限于篇幅，本文只介绍了几种常见且简单的安全问题，还存在许多咱们知道的、还不知道的漏洞。如何找到和解决这些问题？

回顾已介绍的内容，咱们能够发现它们有相似的安全模型：通讯双方的信任问题。

• 在数据存储中，读写数据的代码和存储在本地的数据互相不可信。

• 在数据通讯中，发送者和接受者互相不可信。

• 在登陆认证中，发起认证请求的用户的和接受认证请求的服务器互相不可信。

• 在组件间通讯中，发起Intent的组件与接收Intent的组件互相不可信。

• 在数据验证中，处理数据的模块不能相信产生数据的源。

面对未来的问题，咱们也能够尝试抽象出这种模型，区分互相不可信的实体，而后在不可信、不安全的基础上，尽量地实现相对的可信和安全。

进一步学习和行动

Android 的开发文档Best Practices: Designing for Security和源码文档Tech Info: Security分别从开发和系统实现的角度介绍了系统的安全机制。另外，viaForensics提供了名为42+ Best Practices: Secure mobile development for iOS and Android的在线教程，更详细地介绍了移动软件面临的安全威胁，并给出了安全开发实践策略。

社区方面，从Android安全开发的角 度，Stack-Overflow并不必定是很好的选择—其中一些最佳回答没有考虑安全，直接使用可能产生问题。Google Group的anroid-security-discuss讨论组则更为专业和准确。OWASP成立了一个Mobile Security工做组，目前已发布Top Ten Mobile Risks等多份白皮书，并举办了AppSec会议。这个工做组的效率虽然不高，但产出质量很是棒。

学术方面，2011和2012年的四大会议及其work-shop上均有移动软件漏洞挖掘和攻击阻止的论文出现，从它们的related works部分能够综合快速地了解学术界的思路。

目前的移动开发尚未造成如此成熟的体系，这也许与其轻快敏捷的互联网产品开发风格有关。但我相信，真正实效的移动软件安全开发，最终依然会融合到需求分析、系统设计、开发实现、测试验证、部署运维等每个环节，从而与PC平台的SDL异曲同工。