文档介绍：-
. z.
关于安卓
与一切都是集中管理的iOS相比，Android提供了一种开放的环境，在获得了灵活性、可以满足各种定制需求的同时，也损失了局部平安性。
开发团队通常将精力集前，对其完整性做验证，判断其与实现保存在内部存储中的〔或从效劳器下载来的〕哈希值是否一致。
全局可读写的内部文件
如果开发者使用openFileOutput(String name,int mode)方法创立内部文件时，将第二个参数设置为Conte**，就会让这个文件变为全局可读或全局可写的。
开发者也许是为了实现不同软件之间的数据共享，但这种方法的问题在于无法控制哪个软件可以读写，所以攻击者编写的恶意软件也拥有这一权限。
如果要跨应用共享数据，一种较好的方法是实现一个Content Provider组件，提供数据的读写接口，并为读写操作分别设置一个自定义权限。
内部敏感文件被root权限软件读写
如果攻击者的软件已获得root权限，自然可以随意读写其他软件的内部文件。这种情况并不少见。
大量的第三方定制ROM提供了root权限管理工具，如果攻击者构造的软件伪造成一些功能强大的工具，可以欺骗用户授予它root权限。
即便手机安装的官方系统，国内用户也大多乐于解锁、刷recovery并刷入root管理工具。
在Android ，存在一些可以用于获取root权限的漏洞，并且对这种漏洞的利用不需要用户确实认。
因此，我们并不能假设其他软件无法获取root权限。即便是存在内部的数据，依然有被读取或修改的可能。
前面提到，重要、敏感、隐私的数据应使用内部存储，现在又遇到root后这些数据依然可能被读取的问题。我对这个问题的观点是，如果攻击者铤而走险获得root权限〔被用户觉察或者被平安软件发现的风险〕，那理论上他已拥有了系统的完整控制权，可以直接获得联系人信息、短信记录等。此时，攻击者感兴趣的软件漏洞利用更可能是获得其他由软件管理的重要数据，例如账户密码、会话凭证、账户数据等。例如，早期Google钱包将用户的信用卡数据明文存储，攻击者获取这些数据后，可以伪装成持卡人进展进一步攻击以获得账号使用权。这种数据就是“其他由软件管理的重要数据〞。
-
. z.
这个问题并没有通用的解决方法。开发者可能需要根据实际情况寻找方案，并在可用性与平安性之间做出恰当的选择。
网络通信
Android软件通常使用WiFi网络与效劳器进展通信。WiFi并非总是可信的。例如，开放式网络或弱加密网络中，接入者可以监听网络流量；攻击者可以自己设置WiFi网络钓鱼。此外，在获得root权限后，还可以在Android系统中监听网络数据。
不加密地明文传输敏感数据
最危险的是直接使用HTTP协议登录账户或交换数据。例如，攻击者在自己设置的钓鱼网络中配置DNS效劳器，将软件要连接的效劳器域名解析至攻击者的另一台效劳器；这台效劳器就可以获得用户登录信息，或者充当客户端与原效劳器的中间人，转发双方数据。
早期，国外一些著名社交的Android客户端的登录会话没有加密。后来出现了黑客工具FaceNiff，专门嗅探这些会话并进展劫持〔它甚至支持在WEP、WPA、WPA2加密的WiFi网络上展开攻击！〕。这是目前我所知的唯一一个公开攻击移动软件漏洞的案例。
这类问题的解决方法很显然—对敏感数据采用基于SSL/TLS的HTTPS进展传输。
SSL通信不检查证书有效性
在SSL/TLS通信中，客户端通过数字证书判断效劳器是否可信，并采用证书中的公钥与效劳器进展加密通信。
然而，有开发者在代码中不检查效劳器证书的有效性，或选择承受所有的证书。例如，开发者可以自己实现一个*509TrustManager接口，将其中的checkServerTrusted()方法实现为空，即不检查效劳器是否可信；或者在SSLSocketFactory的实例中，通过 setHostnameVerifier()，承受所有证书。做出这两种选择的可能原因是，使用了自己生成了证书后，客户端发现证书无法与系统可信根CA形成信任链，出现了CertificateE*ception等异常。
这种做法可能导致的问题是中间人攻击。
在钓鱼WiFi网络中，同样地，攻击者可以通过设置DNS效劳器使客户端与指定的效劳器进展通信。攻击者在效劳器上部署另一个证书，在会话建立阶段，客户端会收到这*证书。如