移动平台提供了很多服务，从身份验证到安全数据存储再到安全网络通信。但是，如果平台的某些功能使用不当，可能会导致数据泄露，允许不信任主机连接等问题。本文我们总结了一些安卓的checklist。

M1–平台使用不当

移动平台(iOS，Android，Windows phone)为我们提供了文档结构良好且通俗易懂的特性和功能，而这类风险的特征就是app没有使用这种功能或者使用不当。

另请阅读：完整的移动应用渗透测试指南

导致这种风险的行为有如下几种：

违反发布的指南

所有平台都会开发安全指南。如果某个app不遵守安全指南，违反开发者提供的最佳做法，就会存在该风险。

违反条款或惯例

开发者编写的指南并不会包含所有的最佳做法，在某些情况下，有些最佳做法是移动app中约定俗成的。

无意的使用不当

一些app想要正确执行某些操作，但实际操作起来却发生了某些错误。这可能只是一个小错误，比如在API调用上设置错误的标志，或者对保护措施的理解有误。

这类错误包括错误使用平台功能或没有使用平台安全控件。这可能包括Android intents，平台权限，错误使用Touch ID或其他的一些安全控件，这些都是移动操作系统的一部分。

移动app的隐私和权限也是平台的一部分。因此，如果没有使用平台的功能，会导致泄露终端用户隐私的风险。

下表是一些检查项和对应的描述：

M2–不安全的数据存储

不安全的数据存储和意外的数据泄露

不安全的数据存储漏洞，当开发团队认为用户或恶意软件无法访问设备上的文件系统及其文件存储中的敏感信息时，就会发生该漏洞。文件系统其实是很容易访问的，所以开发团队不能想当然的认为他们无法访问，而应该假设恶意用户和恶意软件是能够查看敏感数据的。

对设备进行root或越狱可以绕过任何的密码保护。如果数据没有得到正确的保护，那么只要一些特殊的工具就可以查看app的数据。当开发者无意中将敏感信息存储在设备中某个位置，而该位置能够轻易被其他app访问时就会导致无意的数据泄露漏洞。

首先，开发者编写代码来处理用户或终端提供的敏感信息。在处理过程中，某个小问题(开发者没有意识到的问题)可能会导致信息存储在设备中某个不安全的位置，而设备上的app能够随意访问这个位置。

不安全的数据存储位置包括—日志文件，plist文件，SD卡，XML数据存储，数据库，二进制数据存储，云同步，OS缓存数据，图片，按键，日志记录和缓冲区等。

下表是一些其他检查项：

 

M3—不安全的通信

移动应用程序通常不会保护网络流量。他们可能在身份验证期间使用SSL/TLS，但在其他地方并不会使用。这会导致数据泄露和会话ID被拦截的风险。

使用传输层安全协议并不意味着所有app都正确部署实施了。要检测基本的漏洞，还是要对手机流量进行仔细观察。更细微的漏洞需要检查应用程序的设计和配置。

可能会存在以下威胁

· 与你共享网络的攻击者(入侵或监听你的WiFi)

· 运行商或网络设备(路由器，手机信号塔，代理等)

要确定应用程序是否有足够的传输层安全保护，可以通过代理来查看应用程序的流量。首先要思考下面的几个问题：

· 所有连接，不仅仅是发送到你服务器的连接，是否进行正确加密？

· SSL证书是最新的吗？

· SSL证书是自签名的吗？

· SSL是否使用高强度的密码？

· 你的应用是否会接受用户接受的证书作为授权？

这包括了不安全的握手协议，不正确的SSL版本，弱协商和敏感资产的明文传输等。

还有下面这些检查项

M4—不安全的身份验证

身份验证不完善或者缺失会导致攻击者匿名执行移动应用程序或应用程序使用的后端服务器中的功能。由于移动设备采用表单输入，而表单的身份验证机制比较脆弱，但是却非常普遍。

表单因素大力支持纯4位数字的PIN短密码。由于可用性的要求，移动应用的身份验证要求与传统的web身份验证方案存在很大的不同之处。在移动应用中，用户在会话期间不会总是在线，所以移动互联网连接比传统的web连接更不可靠，更不可预测。

因此，移动app在正常运行时有一个要求，就是进行离线身份验证。这种离线身份验证的要求对开发人员来说，在实施身份验证过程中，他们要考虑的事情就会变得更多，更复杂。

要检测这种不完善的身份验证方案，测试员可以对处于离线模式的移动app执行二进制攻击。

通过攻击，测试员可以迫使app绕过离线身份验证并且执行需要离线身份验证才能执行的功能。同样，测试员可以尝试是否能够匿名执行任意后端服务器功能，通过删除向移动app功能发出的任何POST/GET请求中的会话token来实现。

在本地进行用户身份验证，可能会导致客户端绕过漏洞。如果应用程序在本地存储数据，那么攻击者可以在越狱设备上，通过在运行时操作和修改二进制来绕过身份验证。

如果可能的话，确保所有的身份验证请求都是在服务器端完成的。只有身份验证成功后，应用程序数据才会加载到移动设备上。这就保证了应用程序数据只有在认证成功后才可用。

如果需要在客户端存储数据，那就需要使用加密密钥对数据进行加密，而这个加密密钥是根据用户输入的登陆凭证生成的。这也确保了只有在输入了正确的凭证之后才能访问存储在应用程序中的数据。

还有一些其他的风险，比如通过二进制攻击来破解加密的数据。

移动app中的持久身份验证功能(即记住我功能)千万不要在设备上存储用户的密码。

理想情况下，应用程序应该使用设备特定的身份验证令牌，用户可以在app中撤销该令牌。这样在设备被盗或丢失的情况下，通过app撤销令牌，可以降低未授权访问的风险。

切勿使用任何容易被篡改的值来验证用户身份。包括设备标识符或地理位置。还有移动app中的持久身份验证应该作为一个选项来让用户选择，不能默认启用。

不正确的会话处理通常跟不完善的身份验证所导致的结果一样。一旦认证成功并且得到了一个session，这个session就允许你访问移动app。移动app代码必须非常妥善的保护用户的会话，就像身份验证机制一样。

以下是身份验证不当的例子

· 后端没有及时终止会话

· 缺乏足够的超时保护

· 没有正确重置cookies

· 不安全的token生成

这类漏洞针对的是终端用户身份验证和错误会话管理。这包括：

· 在需用进行用户识别时根本无法识别用户

· 在需要维持用户身份时无法维持

· 会话管理存在漏洞

其他潜在的风险如下表：

M5—不安全的加密技术

在大多数利用加密技术的移动app中，使用不安全的加密技术是非常普遍的。在移动app中，破解密码有两种基本方式。第一种是利用加密/解密技术中的一个进程，该进程存在严重漏洞，攻击者可以利用这个漏洞来解密敏感数据。第二种，移动app可能使用的是脆弱的加密/解密算法，所以攻击者可以直接利用这种算法的漏洞进行破解。下面的内容将更加深入的探讨这两种方法。

1.依赖内置代码加密过程

使用像ClutchMod或者GBD这样的免费工具，攻击者可以将这个加密app下载到他们越狱的设备中，并且在IOS加载程序将它加载到内存并解密后(在加载程序开始执行之前)，对解密的app拍摄快照。

一旦攻击者拍摄了快照并存储在磁盘中，攻击者就可以使用IDA pro或Hopper工具对app进行静态/动态分析，然后执行进一步的二进制攻击。

2.糟糕的密钥管理流程

很多人确实使用了正确的算法，但还是犯了错误，使用他们自己的协议来部署。其中的一些问题包括：

· 将密钥放在与加密内容相同的文件夹中，而且攻击者可读

· 生成的密钥攻击者通过某种方式可以获得

· 在二进制中使用硬编码密钥

可以通过二进制攻击拦截密钥。关于如何防御二进制攻击的更多信息，请查看M10。

3.创建和使用自定义加密协议

始终使用安全社区认可的现代加密算法并尽可能在你的移动平台中使用最先进的加密API。

二进制攻击让攻击者能够识别你使用的公共库以及二进制文件中的任何硬编码密钥。如果对加密的安全性要求非常高，强烈建议你使用白盒加密技术。

4.使用不安全或过时的算法

很多加密算法和协议都应该停止使用，因为已经证明它们存在严重的漏洞，而且已经无法满足现代安全的要求。这些算法包括 RC2，MD4，MD5，SHA1。

下表是一些检查项和对应的描述：

本文是安卓应用程序渗透测试checklist第一部分，敬请期待第二部分。