1        移动APP安全风险分析

1.1     安全威胁分析

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

 

 

1.2     面临的主要风险

 

 

1.3     Android测试思惟导图

 

 

 

1.4     反编译工具

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

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

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

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   组件安全检查方法

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

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

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

四、 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 检测方法

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

方法二、检查代码中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  来关闭应用程序的备份和恢复功能，以避免形成信息泄露和财产损失。

 

一、不在 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>

                <action  android:name="android.intent.action.MAIN"/>

                <category  android:name="android.intent.category.LAUNCHER"/>

             </intent-filter>

         </activity>

         <activity android:name=".HomeActivity"/>

     </application>

</manifest>

二、在 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>

                <action  android:name="android.intent.action.MAIN"/>

                <category  android:name="android.intent.category.LAUNCHER"/>

             </intent-filter>

         </activity>

         <activity android:name=".HomeActivity"/>

     </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]这种一维形式，以后进行一系列的处理进行发送

4.1.9.3.2         检测方法

尝试屡次输入手势密码错误，例如连续输入3次或者5次密码错误，看是否会锁定帐号。

4.1.9.3.3         修复方法

手势密码策略建议连续输入3次或者5次进行锁定。

4.2     任意帐号注册

4.2.1   描述

使用任意帐号能够进行注册，形成非实名制注册风险，恶意注册者能够注册大量帐号。大量帐号能够用于薅羊毛等恶意操做。

4.2.2   检测方法

使用手机号139****1234注册某个APP，获取验证码060503，在确认提交时，拦截请求，修改注册的手机号码，便可注册任意帐号，这里修改成136****5678（任意手机号）；便可使用136****5678（任意手机号）登陆，都可以经过验证登陆。

4.2.3   修复建议

注册过程最后的确认提交时，服务器应验证提交的帐号是不是下发验证码的手机号。

4.3     短信重放×××

4.3.1   描述

检测应用中是否存在数据包重放×××的安全问题。是否会对客户端用户形成短信轰炸的困扰。 

4.3.2   检测方法

利用burpsuite抓包，而后进行重放操做。

4.3.3   修复建议

token和手机号一块儿，重放没法形成短信轰炸，另外就是限制每一个手机号天天只能发送短信次数，例如10次。每一个ip每分钟只能发送3次。

4.4     短信验证码

4.4.1   描述

短信验证码对于防止暴力破解是一种有效的手段，可是若是验证码没有使用有效，则会致使其没法发挥防暴力破解的效果。

4.4.2   检测方法

检测短信验证码是否能够屡次重复使用。通常验证码使用一次及失效。

检测短信验证码的有效期，通常验证码5分钟内有效便可。

4.4.3   修复建议

设置短信验证码使用一次即失效，而且每一个短信验证码在5分钟内有效。

4.5     业务逻辑漏洞

此处主要是一些越权漏洞。

4.6     服务端其余漏洞

此处和web端漏洞相似，例如SQL注入、XSS、任意文件上传漏洞等等