写在前面

最近研究了下Android应用测试，找了一些资料，觉得OWASP这篇写的还是比较系统的，所以翻译出来给大家分享下。文中的翻译尽可能保持原文格式，但一些地方为了通顺和易于理解也做了一定改动，如有翻译问题，还请各位大牛指正。本文翻译时版本是20170911，后续如果有大更新的话同样会跟进更新。

介绍

这份速查表提供了一份进行Android应用测试所需要进行的测试清单。主要根据OWASP十大移动安全问题进行叙述。

1.1.  测试方法论

一个完整的安卓应用渗透测试包含了几个不同的领域，如上图所示。

1.1.1. 应用架构

在这个领域，重点在于理解应用程序逻辑和应用程序到底是做什么的。这包含了一些手动测试项目，我们会进行一些基本操作例如安装APK到手机上，登录并且了解APP的功能。

了解应用的架构，并寻找可能的攻击向量例如：

1.应用程序的类型是什么？（游戏，商业，生产力等等）

2.应用程序是否连接到后台的Web服务？

3.应用程序是完全自行编写还是使用了现有框架？

4.应用程序是否在设备上存储数据？

5.应用程序都使用了设备上的哪些功能？（摄像头，陀螺仪，通讯录等等）

1.1.2. 客户端攻击

这是渗透测试过程中最具挑战性和激动人心的部分。安卓APP被打包成APK文件，也被称为Android Package Kit或Android Application Package。作为渗透测试人员的任务就是确认应用程序在面对已知攻击向量时，现有的防护机制是否有效。安卓的移动应用通常是通过例如Google Play的平台进行分发。自从应用完全安装在客户端上以后，它就需要承受来自客户端的任何种类攻击。

1.1.3. 网络攻击

正如我们需要识别客户端中的漏洞，通过分析流量来确认客户端和服务器端的通信是否安全也是十分必要的。为达到这个目的，使用代理工具，评估潜在的SSL问题，以及分析Wireshark抓包文件都是进行评估工作的必要组成部分。

1.1.4. 服务端攻击

最后但重要的是，服务端层面的问题同样会影响应用程序的安全。一些不安全的实现例如错误配置，存在漏洞和问题的API或数据库层面的问题，同样会影响到应用的安全性

在设备层面，应用需要以两种方式进行测试。逆向工程是移动应用测试的必要组成部分。这需要一台已经ROOT的设备。如果对为什么我们需要对已安装的APK进行逆向工程比较疑惑，主要原因在于客户端上。

1.2.  设备

同样有两种方法测试应用程序，我们需要考虑在测试中具体使用哪种方法。

1.安卓设备运行在出厂设备或普通模式下测试

2.安卓设备运行在ROOT模式下测试

在应用层面，应当以两种方式进行测试

1.应用程序在真实设备中运行（有利于测试触摸相关特性）

2.应用程序在模拟器中运行（使用台式或笔记本的大屏有利于进行测试）

OWASP入门指南

对于下面的每个标准，测试人员应遵循多个步骤进行测试

2.1.  M1-平台使用不当【客户端攻击】

l  检查AndroidManifest.xml权限配置，某些权限配置可能是危险的。

l  如果应用使用了指纹识别，根据此特性测试不同的漏洞。参考https://www.blackhat.com/docs/us-15/materials/us-15-Zhang-Fingerprints-On-Mobile-Devices-Abusing-And-Leaking-wp.pdf

2.2.  M2-不安全的数据存储【客户端攻击】

这部分测试应该在使用应用一段时间以后进行，以便充分测试。这种方式需要给予应用将一些数据存储在磁盘上所需的时间。这可能需要一个已经ROOT的安卓设备，以便能访问安卓中的例如’/sdcard’的常见路径。

/data/data/app_folder
/sdcard/
/sdcard1/

安卓应用程序需要在本地以sqllite或XML结构存储数据，因此需要执行SQL/XML查询或监控文件I/O。

由此可能造成2种主要威胁。

1.SQL/XML注入，并且如果读取目标是公开的，那另一个应用也可能读取此数据。

2.本地文件读取可能允许其他应用程序读取相关应用程序文件，如果它们包含敏感数据，那数据可能通过此途径泄露。

如果应用程序是一个HTML5的混合应用程序，则还需要考虑跨站脚本（XSS）问题。XSS会将整个应用程序暴露给攻击者，因为HTML5应用程序能够调用本机功能，从而控制整个应用（WebView）。

另外，应用程序可以使用“adb backup”的选项来制作应用程序的备份，通过分析备份内容可以识别当与客户端进行交互的时候，应用程序存储和泄露了什么。

2.3.  M3-网络层保护不足【网络/流量攻击】

这里提供对不同层面进行测试的方法。

2.3.1. 服务器侧

l  识别所有SSL终端。

l  使用（sslscan）或类似软件识别SSL加密方式

l  是否禁用SSLv2,SSLv3

l  是否支持TLS1.2和1.1（1.2对于确保尽可能高的安全连接十分重要）

l  是否禁用RC4和基于CBC的加密算法

l  DH参数应当>2048位

l  SSL证书应当至少使用sha2/sha256签署

l  ECDHE密钥/密钥应当支持完全正向保密

l  SSL证书应当由受信任的RootCA签发

l  SSL证书不应过期

l  验证进程间通信实现是否存在问题

2.3.2. 设备侧

l  通过浏览确认应用是否正常工作

l  在应用程序和远端服务器间设置代理。如果应用无法加载，应用程序可能进行了证书校验。注意logcat（译者注：logcat是Android中一个命令行工具，可以用于得到程序的log信息。）是否有消息输出

l  将代理使用的RootCA证书添加至设备受信任的RootCA列表。

l  尝试再次使用应用。如果应用仍然无法连接，应用程序可能使用了证书绑定。

你可以通过拦截或修改Smali代码来绕过证书绑定     

2.3.2.1. 使用Xposed：

l  安装Xposed Framework以及Just Trust Me模块（译者注：用于禁用SSL证书验证），启用JustTrustMe然后重启设备。

l  再试一次如果一切正常那我们就通过使用Xposed模块成功绕过了证书绑定。

l  目前安卓的安全提供程序（Securityprovider）已经针对SSL漏洞进行了适当更新。

2.3.2.2.  修改SMALI：

l  识别/搜索实现证书绑定的方法（查找关键字例如’sha256/’后面跟着证书值类似于”sha256/wl0L/C04Advn5NQ/xefY1aCEHOref7f/Q+sScuDcvbg=”）

l  将证书绑定值改变为你使用的BURP证书所对应的值。

2.4.  M4-不安全的认证【客户端/服务端攻击】

在这个部分的测试中，需要有一些必要的工具以进行评估。

l  代理工具如ZAP，BURP或者Charles

l  用于流量分析的Wireshark

通过分析客户端和服务器间的流量（HTTP请求/响应），注意检查以下项目

l  分析会话管理和工作流

l  使用代理分析API认证

l  不安全的WebView

l  检查凭据是存放在数据存储还是服务器端

l  滥用或可访问AccountManager（安卓的用户管理类）

l  Authenticating Callers组件调用

不正确的会话处理通常会和糟糕的身份验证带来同样结果。当你通过认证并给予一个会话信息时，这个会话信息允许你访问移动应用。这里有很多东西需要注意

l  检查并验证后端的会话

l  检查会话超时保护

l  检查不正确的Cookie配置

l  不安全的令牌创建

l  不安全的WebView实现

2.5.  M5-加密不足【客户端/网络/服务端攻击】

在这个部分，你需要在使用加密的地方进行枚举以执行一个全面分析。例如：

使用SSL/TLS加密类型

l  使用HTTPS URL或使用一个安全通道例如实现HttpsURLConnection或SSLSocket

l  身份验证会话令牌

l  在数据存储中明文存放敏感信息

l  可以访问加密密钥或不正确的密钥管理

l  使用已知的弱加密算法例如Rot13, MD4,MD5, RC2, RC4, SHA1

l  自制或自行设计的加密算法

l  程序代码内硬编码密钥

l  使用自有协议

l  不安全的使用随机生成器

2.6.  M6-不安全的授权【客户端/服务端攻击】

在对应用程序架构和数据流有所理解后，可以依照以下方法验证授权机制：

l  凭据处理：应用程序是否使用授权令牌而不是始终询问凭证？

l  验证应用程序是否仅允许指定角色访问。

l  在数据存储中存储用户名密码，而不是使用AccountManager

2.7.  M7-客户端代码质量【客户端攻击】

这部分有两种方法：

l  如果你可以访问源代码，对客户端代码和服务器API进行代码审计。

l  如果不能访问源代码，你可以通过反编译APK文件来检查代码

在这个案例里我们强烈建议进行代码审计。由于不正确的实现，这里肯定会有很多潜在的漏洞。

2.8.  M8-代码篡改【客户端攻击】

这一部分你需要一台已经root的设备以及逆向工程技术。

l  使用工具例如apktool, dex2jar /enjarify, Bytecodeviewer或商业工具类似JEB反编译APK文件。

l  使用反编译器例如JD-GUI或Bytecodeviewer分析代码。商业版本的工具类似JEB甚至允许你调试已经反编译的应用，虽然不是所有情况都可以。

l  在分析完代码后，尝试绕过各类功能，无论是通过Xposed或Frida框架修改Smali代码还是劫持方法实现。

l  验证应用程序是否进行了混淆并且通过搜索指定字符串验证混淆级别。

l  反编译APK并更改Smali（利用这个工具，它可以自动反编译，编译和签名应用。https://github.com/voider1/a2scomp）

l  安卓的二进制文件本质上是dex类，如果不加保护，可以直接反编译出源代码。

需要进行检查和验证是否有以下限制：

l  已越狱，Root后的设备-检测限制

l  校验和限制

l  证书绑定限制

l  调试器检测限制

l  Xposed检测限制

l  动态加载代码

l  使用安卓NDK中原生代码

2.9.  M9-逆向工程【客户端攻击】

逆向工程在移动应用测试中是一个必要部分。它同样需要使用一部已经Root的设备。为了这部分测试请确保你已经准备了以下工具:

l  已安装SDK工具的Android Studio

l  一部已经Rooted的安卓设备或模拟器

l  已经Root的安卓模拟器可以使用已安装Xposed的CuckoDroid

l  安装了不同的APK反编译工具例如apktool,Dex2Jar/enjarify或选择集成环境的话可以是Bytecodeviewer或JEB

l  IDA pro (分析代码流程)

l  Smali反编译器/编译器以及签名程序：https://github.com/voider1/a2scomp

验证以下问题：

l  应用程序是否进行了混淆？

l  利用工具Bytecodeviewer或JEB查找关键字符串以及关键词

l  搜索SSL证书绑定实现，设备Root权限获取或API连接（查找关键字例如’TrustManager’ , ‘SHA256′, X509 ,SHA, SSL ,更多细节请查阅安卓安全概览https://developer.box.com/docs/android-security-guidelines）

2.10.    M10-多余的功能

进行这部分的测试需要进行代码审计或对APK进行逆向工程（如果无法获得代码）

作者和主要编辑者

l  Jonathan Carter

l  Prashant Phatak

l  Milan Singh Thakur

l  Anant Shrivastava

l  Johanna Curiel

*参考来源：OWASP基金会，转载请注明来自FreeBuf.COM