移动APP安全测试

阅读量：5276 次

发布时间：2019-06-14

本文共 16261 字，大约阅读时间需要 54 分钟。

1 移动APP安全风险分析

1.1 安全威胁分析

安全威胁从三个不同环节进行划分，主要分为客户端威胁、数据传输端威胁和服务端的威胁。

1.2 面临的主要风险

1.3 Android测试思维导图

1.4 反编译工具

有两种反编译方式，dex2jar和apktool，两个工具反编译的效果是不一样的，dex2jar反编译出java源代码，apktool反编译出来的是java汇编代码。

dex2jar主要是用来把之前zip解压出来的classed.dex转成jar包的

jd-gui主要是用来打开Jar包的

2 本地客户端安全

2.1 反编译保护

2.1.1 问题描述

APP源代码对于一个公司是非常重要的信息资源，对APP的保护也尤为重要，APP的反编译会造成源代码被恶意者读取，以及APP的逻辑设计，

反编译方法

我们一般想要反编译一个apk，无非就是想获得三样东西：图片资源、XML资源、代码资源

一. 图片资源获取

首先准备一个apk，这里是一个.apk后缀的文件，我们先把后缀改成,zip，打开zip文件在res目录下，我们就可以获取到我们需要的图片了。

二. XML资源获取

我们可以在刚刚打开的zip文件目录下看到很多.xml的文件，这个xml文件是无法直接打开的，当你尝试着打开的时候都是乱码或者是空白，那么我们要如何获取到这个xml资源呢，这时候就需要借助一个jar包，就是它，axmlprinter2.jar，这个东西你只要百度下，就能搜到。然后你把他放跟你解压出来的xml放在同级目录下，用cmd命令找到这个目录，

我这边的示例是将xml放在了E盘，大家根据情况,cd到自己解压出来的目录下，然后执行

java -jar AXMLPrinter2.jar xxxxx.xml>xxxxx.txt

这个时候你就能获取到xml里的东西啦

三. 代码资源获取

这个重中之重了，这也是我们主要想要获取到的东西。但是存在一点，这里能够正确反编译出来的只有未加密或者没有混淆的代码，如果想要反编译一些加密或者混淆后代码，俺们就需要其他途径解决了

首先要准备两样东西：dex2jar.rar和jd-gui.zip这两个工具。

dex2jar主要是用来把之前zip解压出来的classed.dex转成jar包的

jd-gui主要是用来打开Jar包的

dex2jar用法：

把dex2jar 解压后，然后将之前zip的classes.dex放到 dex2jar目录下，

注意，必须要跟dex2jar.bat是同级目录。

然后又要用到cmd，cd 到dex2jar目录下，打命令行

dex2jar.bat classes.dex

然后你的目录里会多一个jar包

多了一个 classes-dex2jar.jar的文件

然后在用jd-gui把jar包打开，最终apk的代码就这样被剥离出来了

2.1.2 检测方法

通过反编译工具看是否能够对APP进行反编译

2.1.3 修复方法

采用加密和混淆技术达到反编译保护。

混淆技术作用是增加了用户反编译后阅读代码的难度。

2.2 APP二次打包

2.2.1 二次打包描述

“Android APP二次打包”则是盗版正规Android APP，破解后植入恶意代码重新打包。不管从性能、用户体验、外观它都跟正规APP一模一样但是背后它确悄悄运行着可怕的程序，它会在不知不觉中浪费手机电量、流量，恶意扣费、偷窥隐私等等行为。

面对二次打包不少公司都有自己的防范措施，知名公司的APP几乎都是自己在程序内部做过处理防止其APP被二次打包，一旦打包后重新运行则程序自动退出。接下来，我就来详解一下如何防止APP被二次打包。

要实现代码内部防止APP被二次打包首先得了解APK的机器识别原理，APK的唯一识别是依靠包名和签名来做鉴定的，类似豌豆夹的洗白白、360手机卫士等安全软件对APK的山寨识别，他们就是依赖包名来确定APK然后通过签名来确定其是否山寨。所以说自己的程序内部在启动的时候可以通过获取APK本身的签名然后和正确的签名做对比来识别自己是否被二次打包。

2.2.2 防二次打包检测方法

利用二次打包工具对APP进行二次打包，看APP能否成功打包运行，如果重新打包后无法运行程序说明有防二次打包安全措施。

2.2.3 防二次打包修复方法

采用签名的方法进行保护：获取二次打包后APK的签名与正确的APK签名做对比，判断APK程序是否进行过二次打包。

建议：客户端使用从属方证书进行签名后进行发布而不是使用第三方开发商的证书进行签名，以防开发商内部监管异常，证书滥用的情况出现。

2.3 组件导出安全

2.3.1 四大组件描述

Android主要包含4大组件，分别是activity组件、service组件、content provider组件和broadcast receiver组件。

Activity组件

（1）一个Activity通常就是一个单独的屏幕（窗口）。

（2）Activity之间通过Intent进行通信。

（3）android应用中每一个Activity都必须要在AndroidManifest.xml配置文件中声明，否则系统将不识别也不执行该Activity。

Service组件

(1)service用于在后台完成用户指定的操作。

(2)开发人员需要在应用程序AndroidManifest.xml配置文件中声明全部的service，使用<service></service>标签。

(3)Service通常位于后台运行，它一般不需要与用户交互，因此Service组件没有图形用户界面。Service组件需要继承Service基类。Service组件通常用于为其他组件提供后台服务或监控其他组件的运行状态。

Content Provider组件

（1）android平台提供了Content Provider使一个应用程序的指定数据集提供给其他应用程序。其他应用可以通过ContentResolver类从该内容提供者中获取或存入数据。

（2）只有需要在多个应用程序间共享数据是才需要内容提供者。例如，通讯录数据被多个应用程序使用，且必须存储在一个内容提供者中。它的好处是统一数据访问方式。

（3）ContentProvider实现数据共享。ContentProvider用于保存和获取数据，并使其对所有应用程序可见。这是不同应用程序间共享数据的唯一方式，因为android没有提供所有应用共同访问的公共存储区。

broadcast receiver

（1）你的应用可以使用它对外部事件进行过滤，只对感兴趣的外部事件(如当电话呼入时，或者数据网络可用时)进行接收并做出响应。广播接收器没有用户界面。然而，它们可以启动一个activity或serice来响应它们收到的信息，或者用NotificationManager来通知用户。通知可以用很多种方式来吸引用户的注意力，例如闪动背灯、震动、播放声音等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。

（2）广播接收者的注册有两种方法，分别是程序动态注册和AndroidManifest文件中进行静态注册。

（3）动态注册广播接收器特点是当用来注册的Activity关掉后，广播也就失效了。静态注册无需担忧广播接收器是否被关闭，只要设备是开启状态，广播接收器也是打开着的。也就是说哪怕app本身未启动，该app订阅的广播在触发时也会对它起作用。

四大组件总结

（1）4大组件的注册

4大基本组件都需要注册才能使用，每个Activity、service、Content Provider都需要在AndroidManifest文件中进行配置。AndroidManifest文件中未进行声明的activity、服务以及内容提供者将不为系统所见，从而也就不可用。而broadcast receiver广播接收者的注册分静态注册（在AndroidManifest文件中进行配置）和通过代码动态创建并以调用Context.registerReceiver()的方式注册至系统。需要注意的是在AndroidManifest文件中进行配置的广播接收者会随系统的启动而一直处于活跃状态，只要接收到感兴趣的广播就会触发（即使程序未运行）。

（2）4大组件的激活

内容提供者的激活：当接收到ContentResolver发出的请求后，内容提供者被激活。而其它三种组件activity、服务和广播接收器被一种叫做intent的异步消息所激活。

2.3.2 组件安全检查方法

1、 AndroidManifest.xml文件中activity组件里面有设置android:exported为true，表示此组件可以被外部应用调用。

2、 AndroidManifest.xml文件中activity组件里面有设置android:exported为false，表示此组件不可以被外部应用调用。只有同一个应用的组件或者有着同样user ID的应用可以

3、 AndroidManifest.xml文件中activity组件里面没有设置android:exported属性，但是有intent-filter，则exported默认属性为true，true表示此组件可以被外部应用调用。

4、 AndroidManifest.xml文件中activity组件里面没有设置android:exported属性，也没有设置intent-filter，则exported默认属性为false，false表示此组件不可以被外部应用调用。只有同一个应用的组件或者有着同样user ID的应用可以

备注：采用drozer工具可以进行检测组件是否存在导出风险

2.3.3 修复建议

(1)如果应用的Service组件不必要导出，或者组件配置了intent filter标签，建议显示设置组件的“android:exported”属性为false

(2)如果组件必须要提供给外部应用使用，建议对组件进行权限控制

2.4 Webview漏洞

2.4.1 WebView任意代码执行漏洞

2.4.1.1 描述

出现该漏洞的原因有三个

WebView 中 addJavascriptInterface（）接口

WebView 内置导出的 searchBoxJavaBridge_对象

WebView 内置导出的 accessibility 和 accessibilityTraversalObject 对象

addJavascriptInterface 接口引起远程代码执行漏洞

JS调用Android的其中一个方式是通过addJavascriptInterface接口进行对象映射, 当JS拿到Android这个对象后，就可以调用这个Android对象中所有的方法，包括系统类（java.lang.Runtime 类），从而进行任意代码执行。

searchBoxJavaBridge_接口引起远程代码执行漏洞

在Android 3.0以下，Android系统会默认通过searchBoxJavaBridge_的Js接口给 WebView 添加一个JS映射对象：searchBoxJavaBridge_对象

该接口可能被利用，实现远程任意代码。

accessibility和 accessibilityTraversal接口引起远程代码执行漏洞

问题类似以上

2.4.1.2 检测方法

addJavascriptInterface 接口引起远程代码执行漏洞

检查是通过addJavascriptInterface接口进行对象映射

searchBoxJavaBridge_接口引起远程代码执行漏洞

检查是否通过searchBoxJavaBridge_的Js接口给 WebView 添加一个JS映射对象

accessibility和 accessibilityTraversal接口引起远程代码执行漏洞

问题类似以上

2.4.1.3 修复建议

addJavascriptInterface 接口引起远程代码执行漏洞

B1. Android 4.2版本之后

Google 在Android 4.2 版本中规定对被调用的函数以 @JavascriptInterface进行注解从而避免漏洞×××

B2. Android 4.2版本之前

在Android 4.2版本之前采用拦截prompt（）进行漏洞修复。

searchBoxJavaBridge_接口引起远程代码执行漏洞

删除searchBoxJavaBridge_接口

// 通过调用该方法删除接口

removeJavascriptInterface（）；

accessibility和 accessibilityTraversal接口引起远程代码执行漏洞

删除accessibility和 accessibilityTraversal接口

2.4.2 密码明文存储漏洞

2.4.2.1 描述

WebView默认开启密码保存功能：

mWebView.setSavePassword(true)

开启后，在用户输入密码时，会弹出提示框：询问用户是否保存密码；

如果选择”是”，密码会被明文保到 /data/data/com.package.name/databases/webview.db 中，这样就有被盗取密码的危险

2.4.2.2 检测方法

方法1、用户输入密码时看是否有弹出提示框，询问用户是否保存密码，如果有询问则表示存在漏洞，否则不存在。

方法2、检查代码中setSavePassword的值是否为false。

2.4.2.3 修复建议

关闭密码保存提醒

WebSettings.setSavePassword(false)

2.5 数据安全-本地敏感信息安全

2.5.1 APP所在目录的文件权限

2.5.1.1 问题描述

测试客户端APP所在目录的文件权限是否设置正确，非root账户是否可以读，写，执行APP目录下的文件。

2.5.1.2 检测方法

采用ls –l查看app目录的文件权限，其它组成员不允许读写权限。Linux文件权限为第一个为文件所有者对此文件的权限，第二个为所有者所在组的其它成员对此文件的权限，第三个为其他组成员对此文件的权限。

2.5.1.3 修复建议

检查App所在的目录，其权限必须为不允许其他组成员读写

2.5.2 SQLite数据库文件的安全性

2.5.2.1 描述

SQLite，是一款轻型的数据库，是遵守ACID的关系型数据库管理系统.是开源的，高效率的，可嵌入且程序驱动的数据库。

我们都知道，Android系统内置了SQLite数据库，并且提供了一整套的API用于对数据库进行增删改查操作。数据库存储是我们经常会使用到的一种存储方式，相信大多数朋友对它的使用方法都已经比较熟悉了吧。在Android中，我们既可以使用原生的SQL语句来对数据进行操作，也可以使用Android API提供的CRUD方法来对数据库进行操作，两种方式各有特点，选择使用哪一种就全凭个人喜好了。

不过，使用SQLite来存储数据却存在着一个问题。因为大多数的Android手机都是Root过的，而Root过的手机都可以进入到/data/data//databases目录下面，在这里就可以查看到数据库中存储的所有数据。如果是一般的数据还好，但是当涉及到一些账号密码，或者聊天内容的时候，我们的程序就会面临严重的安全漏洞隐患。

2.5.2.2 检测方法

手机进行root之后，查看/data/data//databases下的数据库文件是否包含敏感信息。

2.5.2.3 修复建议

重要信息进行加密存储

2.5.3 Logcat日志

2.5.3.1 描述

检测客户端对应的Logcat日志是否会打印一些用户或服务器的敏感信息。

2.5.3.2 检测方法

通过usb连接手机，然后使用adb logcat -v time > d:\xx的方式获取logcat信息

或者使用DDMS工具查看logcat信息。

2.5.3.3 修复建议

具有敏感信息的调试信息开关一定要关闭。

对于安卓开发来讲，我们解决敏感信息问题就是对重要数据进行加密存储，log日志不打印敏感信息。切记不要把账号密码等敏感信息保存在本地明文存储，如果一定要存储敏感信息务必进行加密存储重要信息。

2.5.4 敏感数据明文存储于Sdcard

2.5.4.1 描述

Android提供了几种保存持久化应用数据的选择，其中之一就是外部存储（/sdcard, /mnt/sdcard）。外部存储包括设备内部的微型或标准大小的SD卡，挂载到PC上的Android设备存储卡以及Android/obb目录。

Android4.1之前的版本，存放在外部存储的文件是world-readable（能够被任何用户读取的）和world-writable（能够被任何用户写入）。从Android4.1到Android4.3，一个app想要写入外部存储的任意文件时，只需在AndroidManifest文件中声明WRITE_EXTERNAL_STORAGE权限。但从Android4.4开始，引入了基于目录结构创建分组和文件模式，这使得一个app在外部存储中的只能在以自己包名命名的目录下才具有文件的读写权限。非系统级的app只允许在Android/data/<package-name>/目录下操作。因此，每个app的文件读写权限被独立开来，不能互相访问。

上面描述的访问权限限制的不足，导致写入到外部存储的文件可能存在被同一设备上不同的app修改和读取的风险（Android4.4之前版本）。

2.5.4.2 检测方法

查看是否有代码把内容写入到外部存储设备。

2.5.4.3 修复建议

在将文件保存到外部存储之前，先对文件内容进行加密。

2.6 键盘安全风险

2.6.1 键盘劫持测试

2.6.1.1 描述

安卓应用中的输入框默认使用系统软键盘，手机安装×××后，×××可以通过替换系统软键盘，记录应用的密码。

2.6.1.2 检测方法

通过观察app在输入密码的地方是否会弹出自定义的软键盘。

2.6.1.3 修复建议

建议客户端开发自定义软键盘而不是使用系统软件盘以防止键盘劫持×××。

2.6.2 软键盘安全性测试

2.6.2.1 描述

测试客户端是否使用随机布局的密码软键盘。

2.6.2.2 检测方法

用眼观察每次弹出来的自定义的软键盘是否随机变化布局

2.6.2.3 修复建议

建议客户端对自定义软键盘进行随机化处理，同时在每次点击输入框时都进行随机初始化。

2.7 屏幕录像测试

2.7.1 描述

测试通过连续截图，是否可以捕捉到用户密码输入框的密码。

2.7.2 检测方法

通过连续截图，是否可以捕捉到用户密码输入框的密码。

2.7.3 修复建议

建议客户端针对第三方或系统截屏编写抵抗逻辑，例如屏蔽和截屏相关的函数或是当客户端处于进程栈顶层时将截屏图片用纯黑×××片对象进行覆盖。

2.8 界面劫持保护

2.8.1 界面劫描述

Activity劫持是指当启动某个窗口组件时，被恶意应用探知，若该窗口界面是恶意程序预设的×××对象，恶意应用将启动自己仿冒的界面覆盖原界面，用户在毫无察觉的情况下输入登录信息，恶意程序在把获取的数据返回给服务端。

需要理解，Android启动一个Activity时，是这样设计的，给Activity加入一个标志位FLAG_ACTIVITY_NEW_TASK，就能使它置于栈顶并立马呈现给用户。但是这样的设计却有一个缺陷。如果这个Activity是用于盗号的伪装Activity呢？这种现象在XcodeGhost事件中，已经被证实是可以实现的。

在Android系统当中，程序可以枚举当前运行的进程而不需要声明其他权限，这样的话，就可以编写一个程序，启动一个后台的服务，这个服务不断地扫描当前运行的进程，当发现目标进程启动时，就启动一个伪装的Activity。如果这个Activity是登录界面，那么就可以从中获取用户的账号密码，具体的过程如下图：

2.8.2 界面劫持防护方法

作为一名移动应用开发者，要防御APP被界面劫持，最简单的方法是在登录窗口等关键Activity的onPause方法中检测最前端Activity应用是不是自身或者是系统应用。如果检测到不是自己，则弹出告警或者退出。

2.8.3 界面劫持案例

应用存在钓鱼劫持风险。应用程序没有做防钓鱼劫持措施，通过劫持应用程序的登录界面，可以获取用户的账号和密码，可能导致用户账号信息的泄露。

2.8.4 整改建议

应用程序自身通过获取栈顶activity，判断系统当前运行的程序，一旦发现应用切换（可能被劫持），给予用户提示以防范钓鱼程序的欺诈。

获取栈顶activity（如下图），当涉及敏感activity（登录、交易等）切换时，判断当前是否仍留在原程序，若不是则通过Toast给予用户提示。

使用HTML5架构或android+HTML5混合开发，实现登陆、支付等关键页面，降低被劫持的风险。

2.9 本地拒绝服务

2.9.1 漏洞描述

Android系统提供了Activity、Service和Broadcast Receiver等组件，并提供了Intent机制来协助应用间的交互与通讯，Intent负责对应用中一次操作的动作、动作涉及数据、附加数据进行描述，Android系统则根据此Intent的描述，负责找到对应的组件，将Intent传递给调用的组件，并完成组件的调用[1]。Android应用本地拒绝服务漏洞源于程序没有对Intent.getXXXExtra()获取的异常或者畸形数据处理时没有进行异常捕获，从而导致×××者可通过向受害者应用发送此类空数据、异常或者畸形数据来达到使该应用crash的目的，简单的说就是×××者通过intent发送空数据、异常或畸形数据给受害者应用，导致其崩溃。

本地拒绝服务漏洞影响范围：Android系统所有版本

2.9.2 漏洞检测方法

使用Android扫描工具可以进行扫描。

2.9.3 修复建议

本地拒绝服务漏洞修复建议：

　　1) 将不必要的导出的组件设置为不导出

　　出于安全考虑，应将不必要的组件导出，防止引起拒绝服务，尤其是杀毒、安全防护、锁屏防盗等安全应用; 在AndroidMenifest.xml文件中，将相应组件的“android:exported”属性设置为“false”,如下示例：<android:exported="false">

　　2) intent处理数据时进行捕获异常

　　建议处理通过Intent.getXXXExtra()获取的数据时进行以下判断，以及用try catch方式进行捕获所有异常，以防止应用出现拒绝服务漏洞：

　　1) 空指针异常;

　　2) 类型转换异常;

　　3) 数组越界访问异常;

　　4) 类未定义异常;

　　5) 其他异常;

2.10 数据备份allowBackup

2.10.1 漏洞描述

Android API Level 8 及其以上 Android 系统提供了为应用程序数据的备份和恢复功能，此功能的开关决定于该应用程序中 AndroidManifest.xml 文件中的 allowBackup 属性值，其属性值默认是 True。当 allowBackup 标志为 true 时，用户即可通过 adb backup 和 adb restore 来进行对应用数据的备份和恢复，这可能会带来一定的安全风险。

Android 属性 allowBackup 安全风险源于 adb backup 容许任何一个能够打开 USB 调试开关的人从Android 手机中复制应用数据到外设，一旦应用数据被备份之后，所有应用数据都可被用户读取；adb restore 容许用户指定一个恢复的数据来源（即备份的应用数据）来恢复应用程序数据的创建。因此，当一个应用数据被备份之后，用户即可在其他 Android 手机或模拟器上安装同一个应用，以及通过恢复该备份的应用数据到该设备上，在该设备上打开该应用即可恢复到被备份的应用程序的状态。

尤其是通讯录应用，一旦应用程序支持备份和恢复功能，×××者即可通过 adb backup 和 adb restore 进行恢复新安装的同一个应用来查看聊天记录等信息；对于支付金融类应用，×××者可通过此来进行恶意支付、盗取存款等；因此为了安全起见，开发者务必将 allowBackup 标志值设置为 false 来关闭应用程序的备份和恢复功能，以免造成信息泄露和财产损失。

1、不在 AndroidManifest.xml 文件设置 allowBackup 属性值，其默认值为 true，则应用可通过 adb 命令进行备份整个应用的数据

AndroidManifest.xml文件内容：

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.alibaba.jaq.allowbackuppoc"

android:versionCode="1"

android:versionName="1.0">

<uses-sdk android:minSdkVersion="10"/>

<uses-permission android:name="android.permission.READ_PHONE_STATE" />

<application

android:label="@string/app_name">

<activity android:name="LoginActivity"

android:label="@string/app_name">

<intent-filter>

</intent-filter>

</activity>

</application>

</manifest>

2、在 AndroidManifest.xml 文件显示设置 allowBackup 属性值为 false，即android:allowBackup="false"，则 Android 应用不可通过 adb 命令进行备份和恢复整个应用的数据

AndroidManifest.xml文件内容：

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.alibaba.jaq.allowbackuppoc"

android:versionCode="1"

android:versionName="1.0">

<uses-sdk android:minSdkVersion="10"/>

<uses-permission android:name="android.permission.READ_PHONE_STATE" />

<application

android:allowBackup="false"

android:label="@string/app_name">

<activity android:name="LoginActivity"

android:label="@string/app_name">

<intent-filter>

</intent-filter>

</activity>

</application>

</manifest>

2.10.2 检测方法

查看AndroidManifest.xml文件中是否有allowBackup，如果没有则allowBackup属性值，默认allowBackup值为True，则默认为可以备份应用数据，存在安全风险；如果allowBackup属性值为false，则不可以备份应用数据。

2.10.3 修复方法

把AndroidManifest.xml文件中allowBackup属性值设置为false。

2.11 Debug调试

2.11.1 描述

在准备发布应用之前要确保关闭debug属性，即设置AndroidMainifest.xml中android:debuggable="false"，false表示关闭debug调试功能，true表示开启debug调试功能，但是有时候会忘记关掉这个属性。Debug调试开启会存在应用被调试的风险。

2.11.2 检测方法

在发布之前最好进行测试，使用aapt工具：

aapt list -v -a myfile.apk

这个命令将会打印和apk相关的所有详细信息，找到“android:debuggable"，它的值分为：

0x0: debuggable false

0xffffffff: debugabble true

例如，在我的测试中，这一行的信息是：

A: android ebuggable(0x0101000f)=(type 0x12)0x0

这说明我的Release Build已经关闭了debuggable！

2.11.3 修复建议

把debuggable关闭

android:debuggable=false

3 通信过程安全

3.1 通信保密性

3.1.1 采用HTTPS通信

3.1.1.1 描述

验证客户端和服务器之前的通信是否使用https加密信道，采用https协议通信可以防止信息在传输过程被窃听的风险。。

3.1.1.2 检测方法

通过抓包工具（例如burpsuite、fiddler）抓取通信信息，看是否进行加密通信。

3.1.1.3 修复建议

使用https进行加密通信。

3.1.2 SSL劫持×××——证书校验

3.1.2.1 描述

目前虽然很多Android APP使用了https通信方式，但是只是简单的调用而已，并未对SSL证书有效性做验证，https通信只是对通信信道进行了加密，可以防止监听数据的风险，但是无法防止中间人×××方式，通过中间人拦截代理方式可以让采用https通信的数据暴露无遗，这样×××者就可以利用中间人拦截代理来做劫持×××，这种漏洞让https形同虚设，可以轻易获取手机用户的明文通信信息。

证书校验是为了防止中间人劫持×××，分为强校验和弱校验。强校验就是在手段端先预埋好服务端的证书，当手机端与服务端通信时获取证书，并且与手机本地预埋的服务端证书做对比，一旦不一致，则认为遭到了中间人劫持×××，自动断开与服务端的通信。弱校验则是在手机端校验证书的域名和手机真实访问的域名是否一致、证书颁发机构等信息。

强校验流程图：

弱校验流程图：

方案对比

方案	优点	缺点
强校验：服务器证书锁定	安全性最高，实施×××必须拿到对应服务器私钥证书。	更换证书时APP影响大
弱校验：根证书锁定+域名验证	更换服务器证书不受影响	安全性和CA机构以及域名验证机制有关。

3.1.2.2 检测方法

通过抓包看手机端程序是否运行正常，如果通过代理方式抓包，手机APP自动强制退出，说明手机APP有做证书校验。

3.1.2.3 整改方法

采用强校验或者弱校验方法。

3.2 访问控制

3.2.1 描述

测试客户端访问的URL是否仅能由手机客户端访问。是否可以绕过登录限制直接访问登录后才能访问的页面，对需要二次验证的页面（如私密问题验证），能否绕过验证。

3.2.2 检测方法

利用截包工具获取url，能用浏览器打开该url。

3.2.3 修复建议

建议服务器进行相应的访问控制，控制对应页面仅能通过手机客户端访问。同时进行页面访问控制，防止绕过登陆直接访问页面的非法访问。

4 服务端安全

4.1 安全策略设置

4.1.1 密码复杂度策略

4.1.1.1 描述

测试客户端程序是否检查用户输入的密码，禁止用户设置弱口令

4.1.1.2 检测方法

修改设置用户名密码时，可以设置111111类似弱口令

4.1.1.3 修复建议

建议在服务器编写检测密码复杂度的安全策略，并将其运用到账号注册，密码修改等需要进行密码变更的场景，以防止×××者通过弱密钥遍历账户的方式进行暴力猜解。

4.1.2 认证失败锁定策略

4.1.2.1 描述

测试客户端是否限制登录尝试次数。防止×××使用穷举法暴力破解用户密码

4.1.2.2 检测方法

错误密码登录请求多次（10次以上还没有就有问题了，一般都是3次）

4.1.2.3 修复建议

建议在服务端编写账户锁定策略的逻辑，当一天内多次输入密码错误时进行账号锁定以防止×××者通过暴力猜解密码。

4.1.3 单点登录限制策略

4.1.3.1 描述

测试能否在两个设备上同时登录同一个帐号。

4.1.3.2 检测方法

测试能否在两个设备上同时登录同一个帐号。

4.1.3.3 修复建议

建议在服务器进行账号登陆限制相应逻辑代码的编写，通过Session或数据库标志位的方式控制同一时间只有一个设备可以登陆某一账号。

4.1.4 会话超时策略

4.1.4.1 描述

测试客户端在一定时间内无操作后，是否会使会话超时并要求重新登录。超时时间设置是否合理。

4.1.4.2 检测

客户端在一定时间内无操作（20分钟足够），是否会话超时登录

4.1.4.3 建议

建议在客户端编写会话安全设置的逻辑，当10分钟或20分钟无操作时自动退出登录状态或是关闭客户端。

4.1.5 界面切换保护

4.1.5.1 描述

检查客户端程序在切换到后台或其他应用时，是否能恰当响应（如清除表单或退出会话），防止用户敏感信息泄露

4.1.5.2 检测方法

应用切换到后台但程序没有结束运行，再返回应用的时候是否有身份验证，手势密码或者登陆密码。

4.1.5.3 修复建议

建议客户端添加响应的逻辑，在进行进程切换操作时提示用户确认是否为本人操作。

4.1.6 UI敏感信息安全

4.1.6.1 描述

检查客户端的各种功能，看是否存在敏感信息泄露问题。

4.1.6.2 检测方法

比如登录时，密码输入错误，APP是否会提示密码输入错误

4.1.6.3 修复建议

建议用户名或密码输入错误均提示“用户名或密码错误”，若客户端同时还希望保证客户使用的友好性，可以在登陆界面通过温馨提示的方式提示输入错误次数，密码安全策略等信息，以防用户多次输入密码错误导致账号锁定。

4.1.7 安全退出

4.1.7.1 描述

验证客户端在用户退出登录状态时是否会和服务器进行通信以保证退出的及时性

4.1.7.2 检测方法

客户端在用户退出登录时，查看session是否可用

4.1.7.3 修复建议

保证客户端和服务器同步退出，APP退出时服务器端的清除会话

4.1.8 密码修改验证

4.1.8.1 描述

验证客户端在进行密码修改时的安全性

4.1.8.2 检测方法

是否存在原密码验证

4.1.8.3 修复建议

建议在修改密码时，客户端及服务器系统增添原密码输入验证身份的逻辑，以防Cookie登陆修改密码的×××。

4.1.9 手势密码

4.1.9.1 手势密码修改和取消

4.1.9.1.1 描述

检测客户端在取消手势密码时是否会验证之前设置的手势密码，检测是否存在其他导致手势密码取消的逻辑问题

4.1.9.1.2 检测方法

检测客户端在取消手势密码时是否会验证之前设置的手势密码，检测是否存在其他导致手势密码取消的逻辑问题

4.1.9.1.3 修复建议

不应该存在其他导致手势密码取消的逻辑，客户端在取消手势密码时应验证之前设置的手势密码

4.1.9.2 手势密码本地信息保存

4.1.9.2.1 描述

检测在输入手势密码以后客户端是否会在本地记录一些相关信息，例如明文或加密过的手势密码。

4.1.9.2.2 检测方法

找到存储文件，看其是否加密

4.1.9.2.3 修复建议

应该进行加密

4.1.9.3 手势密码锁定策略

4.1.9.3.1 描述

测试客户端是否存在手势密码多次输入错误被锁定的安全策略。防止×××使用穷举法暴力破解用户密码。因为手势密码的存储容量非常小，一共只有9！=362880种不同手势，若手势密码不存在锁定策略，×××可以轻易跑出手势密码结果。手势密码在输入时通常以a[2][2]这种3*3的二维数组方式保存，在进行客户端同服务器的数据交互时通常将此二维数组中数字转化为类似手机数字键盘的b[8]这种一维形式，之后进行一系列的处理进行发送