上篇、中篇回顾：通过收费情况、样本测试后的扫描时间、漏洞项对比以及扫描能力这几个方面对阿里聚安全[1]、360App漏洞扫描[2]、腾讯金刚审计系统[3]、百度移动云测试中心[4]以及AppRisk Scanner[5]进行了对比分析。作为本系列的最后一篇，我将会以4个随机选取的APP的测试结果来进行对比。

四、扫描结果对比

选取的APP：说明一下这次选择的四个app是根据下载和安装量来选择，分别在网络工具类、天气、社交资讯类和搜索工具类选择了下载量和安装量最大的。出于对应用的隐私保护这里把最后选定的应用名隐去暂时叫做A应用。

评测方法：将以上4个APP分别上传到五家扫描平台，都分别得到5家平台的扫描速度和结果。除了在上篇中对比扫描时间外，这里还要对5家的扫描结果进行对比。但是实际操作下来4个APP的对比工作量实在太大，所以我最后从工作量小易于分析的原则出发，选择了A应用来最为结果对比。

下面我将以A应用的扫描结果为例，详细分析一下各个平台的扫描结果的漏报和误报，从而评估其扫描结果的可信度。

A应用的扫描结果如表4-1所示。

表4-1扫描结果总览

阿里

360

金刚

百度

AppRisk

WebView绕过证书校验漏洞

2

2

1

WebView组件远程代码执行漏洞

2

2

3

2

中间人攻击（Allow All host name）

1

1

备份功能开启风险

1

1

1

1

1

主机名弱校验

1

1

1

1

证书弱校验

4

2

4

1

拒绝服务

3

1

Intent协议解析越权漏洞

1

AES/DES弱加密

1

15

初始化IVParameterSpec函数出错

9

PendigIntent误用风险

2

5

2

WebView明文存储密码风险

6

25

30

WebView组件系统隐藏接口漏洞

5

12

1

32

日志泄露风险

5

1

241

286

强制类型转换本地拒绝服务漏洞

6

App存在隐式意图调用

2

3

组件导出风险

22

24

23

17

Intent泄露用户敏感信息

1

1

广播信息泄露风险

2

Dex文件动态加载

0

1

9

加密哈希函数漏洞MD5

12

加密哈希函数漏洞SHA-1

1

Native动态调试

1

密钥硬编码

10

安全加固风险

1

WebView File域同源策略绕过

2

A应用只有一个dex文件，这排除了隐藏dex对结果的影响，接下来的章节中对扫描结果进行详细的对比分析。

4.1 WebView绕过证书校验漏洞

表4-3 WebView绕过证书校验漏洞分析结果

误报

漏报

360

0

2

金刚

0

未知

阿里

0

未知

百度

0

1

AppRisk

0

2

WebView绕过证书校验漏洞是指onReceivedSslError函数中调用proceed方法，会导致WebView忽略校验证书的步骤。对于WebView绕过证书校验漏洞，经过比对，阿里和金刚定位的漏洞位置一致。因此我认为360和AppRisk漏报了2个，百度漏报了1个。我推测百度对于此类漏洞的检测规则是判断是否有onReceivedSslError这个函数。SslErrorHandler这个类会代表一个请求去处理ssl error。SslErrorHandler会被WebView创立然后传给onReceivedSslError函数进行处理。其实真正做证书处理的函数是SslErrorHandler类的proceed函数。这个函数一般会是在SslErrorHandler函数里面进行调用，但是它还是可能在其他函数中被调用。因此检查proceed这个函数会更加全面。阿里与金刚应该是检查Landroid/webkit/SslErrorHandler;->proceed()V。百度漏报的一个正好符合我的推论。

4.2 证书弱校验

表4-4 证书弱校验分析结果

误报

漏报

360

0

4

金刚

0

2

阿里

0

未知

百度

0

未知

AppRisk

0

3

证书弱校验漏洞是在实现的X509TrustManager子类中checkServerTrusted函数没有校验服务器端证书的合法性导致的。360漏报4个，金刚漏报2个，AppRisk漏报3个。经过我的分析，一共有6处调用了checkServerTrusted，其中2处对证书进行了验证；而4处没有验证，直接返回，有两种形式，如下图所示：

我推测，漏报的原因是多了两行param导致扫描器认为对证书有校验。

4.3 WebView明文存储密码风险

表4-5 WebView明文存储密码风险分析结果

误报

漏报

360

无检测

无检测

金刚

无检测

无检测

阿里

0

4

百度

15

未知

AppRisk

23

3

经过分析，我猜测AppRisk是通过loadUrl函数判断是否使用了WebView，然后在使用loadUrl的类中搜索该WebView是否调用setSavePassword(false)方法。而我在反编译的代码中进行全局搜索，一共有34处调用loadUrl；其中4处所处的类中显式调用了setSavePassword(false)方法，符合我的猜测，由于其他3处没有调用loadUrl，所以AppRisk漏报了3处。

百度的检测逻辑就比较难猜测，它不仅通过loadUrl，还通过其他方法判断是否使用了WebView，所以它可能没有漏报，但是误报率比较高。阿里没有检测出那些通过findViewById方法获得的WebView引起的明文密码存储风险，漏报了4处。

4.4 日志泄露风险

表4-6 日志泄露风险分析结果

误报

漏报

360

未知

未知

金刚

无检测

无检测

阿里

未知

未知

百度

未知

未知

AppRisk

未知

未知

各个扫描平台对日志泄露风险的处理方式完全不同，在此一起讨论。

从扫描结果来看，阿里好像只检测System.out.print函数打印的内容。并没有过滤Log函数。实际上，Log函数也会泄露敏感的日志信息。

360认为只要存在Log日志，不管是System.out.print还是Log函数，都认为存在日志泄露风险。但无论日志泄露有多少，都只会给出一个存在Log日志泄露的风险，而且没有具体的漏洞位置。

百度和AppRisk对待日志泄露的态度相似，检测Log函数。

所以从我这看，阿里、360以及百度和AppRisk的出发点是不同的。结果也没有很好的可比性。能可比的，就是对待这个日志泄露风险的一个规则。

4.5 PendingIntent误用风险

表4-7 PendingIntent误用风险分析结果

误报

漏报

360

无检测

无检测

金刚

无检测

无检测

阿里

0

3

百度

0

未知

AppRisk

0

3

百度的PendingIntent误用风险，不仅包括Intent为空的情况，还包含了隐式Intent的情况。A应用中，有2个是空Intent，有3个是隐式Intent。而阿里和AppRisk的PendingIntent误用风险监测可能只包括Intent为空的情况，所以只检测出2处漏洞，漏报了3个隐式的Intent。如果从两者的检测内容上看，阿里、百度和AppRisk都没有误报的情况。

4.6 WebView远程代码执行漏洞

五个扫描都具有扫描WebView远程代码执行漏洞，但是给出的结果却不一样。扫描结果如下表所示：

表 4-8 WebView远程代码执行漏洞分析结果

误报

漏报

360

0

3

金刚

0

1

阿里

0

1

百度

0

未知

AppRisk

0

1

在WebView远程代码执行漏洞检测中，经过人工分析，确认阿里、金刚以及AppRisk各漏报1个，360漏报3个。阿里没有识别findViewById方法实例化的WebView，因而漏报了1个。

4.7 Dex文件动态加载

只有阿里、百度和AppRisk这三个扫描器包含该扫描项。

阿里的检测规则（猜测）：

1) 检测特征函数DexClassLoader以及PathClassLoader的构造函数。

2) 检测该特征函数的传入参数（加载路径）是否包含“sdcard”字符串

百度的检测规则（猜测）：

1) 检测特征函数DexClassLoader以及PathClassLoader的构造函数

AppRisk的检测规则（猜测）：

2) 检测DexClassLoader中loadClass调用

我在反编译的代码中进行全局搜索“DexClassLoader;->loadClass”，一共有9处，故猜测AppRisk的检测规则为检测loadClass函数的调用。

由于检测点不一样无法判断具体的漏报和误报。

4.8 AES/DES弱加密

表4-9 AES/DES弱加密分析结果

误报

漏报

360

0

1

金刚

无检测

无检测

阿里

0

未知

百度

14

未知

AppRisk

0

1

该项金刚不会检测，而360和AppRisk都没有检测出AES/DES弱加密风险，都漏报了1个。而百度却检测出15个弱加密风险。经过分析，我猜测百度只是检测是否包含AES或者DES，并没有判断加密模式是否为ECB，使用其他加密模式是不存在安全隐患的。而阿里正确检测出1个，因此我的结论是百度误报14个漏洞，360和AppRisk漏报1个。

4.9 WebView组件系统隐藏接口漏洞

表4-10 WebView组件系统隐藏接口漏洞分析结果

误报

漏报

360

0

未知

金刚

9

2

阿里

0

未知

百度

0

4

AppRisk

27

3

360没有扫描出WebView隐藏接口漏洞，原因未知。

金刚误报了9个，而且还有2个漏洞漏报；百度漏报了4个漏洞，只正确找出1个。通过之前的扫描能力分析我可知，金刚可能仅仅是寻找是否有使用了WebView，而没对WebView是否启用了JavaScript进行检查，所以误报率很高。百度没有误报，但漏报很多，可能是百度没有判断WebView是否启用了JavaScript，所以本着减少误报的原则，只报告百分之百确定的漏洞。

AppRisk的检测规则可能非常简单粗暴，仅仅检查loadUrl来确定是否使用了WebView，因而误报率很高。

阿里可能首先判断WebView是否允许JavaScript运行。只有在JavaScript允许运行时移除隐藏接口才有意义；然后如果JavaScript开启，那么就判断WebView是否移除了“searchBoxJavaBridge_”、“accessibilityTraversal”以及“accessibility”这3个接口。如果都移除了才安全。所以阿里漏报和误报都很低。

五、总结和展望

通过此次评测，我基本了解了目前国内移动安全扫描平台的发展状况，了解了主流扫描平台的检测能力，包括扫描项、漏洞的检测规则等。我发现没有一家扫描平台可以覆盖所有的安全漏洞和风险。相对来说， AppRisk扫描速度最快，扫描结果展示更加专业；360和金刚作为老牌的扫描器，尽管扫描速度慢了一点，但扫描能力和结果展示也比较不错；阿里聚安全的扫描项覆盖广一些，漏报和误报率较低，检测结果更加可信一点。百度作为其中唯一一家收费的扫描平台，在某些扫描项的扫描能力上处于领先位置，扫描速度也比较快。总之，五家扫描平台在竞争中互相学习，取长补短。

Reference：

［1］ 阿里聚安全  http://jaq.alibaba.com/

［2］ 360APP漏洞扫描  http://dev.360.cn/mod/vulscan/

［3］  腾讯金刚审计系统  http://service.security.tencent.com/kingkong

［4］  百度移动云测试中心  http://mtc.baidu.com/startTest/safe

［5］  AppRisk Scanner  https://apprisk.newskysecurity.com

APP漏洞自动化扫描专业评测报告（下篇）的更多相关文章

  1. APP漏洞自动化扫描专业评测报告

    一.前言 目前在业界有很多自动化检测APP安全性的在线扫描平台.为了了解目前国内移动APP在线漏洞扫描平台的发展情况,我进行了一次移动安全扫描平台的评测分析:主要从漏洞项对比.扫描能力对比以及扫描结果 ...

  2. APP漏洞自动化扫描专业评测报告（中篇）

    前言 上一篇中通过对阿里聚安全[1].360App漏洞扫描[2].腾讯金刚审计系统[3].百度移动云测试中心[4]以及AppRisk Scanner[5] 在收费情况.样本测试后的扫描时间对比和漏洞项 ...

  3. APP漏洞自动化扫描专业评测报告（上篇）

    一.前言 随着Android操作系统的快速发展,运行于Android之上的APP如雨后春笋般涌现.由于一些APP的开发者只注重APP业务功能的实现,对APP可能出现安全问题不够重视,使得APP存在较多 ...

  4. 移动APP漏洞自动化检测平台建设

    移动APP漏洞自动化检测平台建设   前言:本文是<移动APP客户端安全笔记>系列原创文章中的第一篇,主要讲的是企业移动APP自动化漏洞检测平台建设,移动APP漏洞检测发展史与前沿技术,A ...

  5. 安全基线自动化扫描、生成报告、加固的实现（以Tomcat为例）

    一.背景说明 当前在服务上线前,安全部门都会对服务基线配置进行把关,整个流程可以分为扫描.生成报告.修复三步. 在执行这一流程时当前普遍的做法是半自动化的,扫描和生成报告是自动化的,执行扫描.执行生成 ...

  6. 国内APP漏洞扫描收费情况调查

    概述 上一次分享了应用加固的评测后,很多人想看看漏洞扫描相关的对比数据.其实在选择市面上这些移动安全类的产品时,经常为各种复杂的数据而感到疑惑,不知道怎么来评判各自的性能以及价格,从而选择出一款性价比 ...

  7. APP漏洞扫描器之本地拒绝服务检测详解

    APP漏洞扫描器之本地拒绝服务检测详解 阿里聚安全的Android应用漏洞扫描器有一个检测项是本地拒绝服务漏洞的检测,采用的是静态分析加动态模糊测试的方法来检测,检测结果准确全面.本文将讲一下应用漏洞 ...

  8. APP漏洞扫描用地址空间随机化

    APP漏洞扫描用地址空间随机化 前言 我们在前文<APP漏洞扫描器之本地拒绝服务检测详解>了解到阿里聚安全漏洞扫描器有一项静态分析加动态模糊测试的方法来检测的功能,并详细的介绍了它在针对本 ...

  9. APP漏洞扫描用地址空间随机化【转】

    转自:http://www.cnblogs.com/alisecurity/p/6141575.html 前言 我们在前文<APP漏洞扫描器之本地拒绝服务检测详解>了解到阿里聚安全漏洞扫描 ...

随机推荐

  1. GYM 100741A Queries(树状数组)

    A. Queries time limit per test 0.25 seconds memory limit per test 64 megabytes input standard input ...

  2. Python 33（1） UDP协议 数据报协议 socketsever模块

    一:基于UDP协议通信的套接字  基于UDP协议 只要是套接字,在开发的过程中一定要有服务端和客户端. UDP协议说的就是数据报协议,也就是说,基于UDP协议来发数据,每发一个数据,都是带有报头的数据 ...

  3. 模拟Queue(wait/notify)

    BlockingQueue:顾名思义,首先它是一个队列,并且支持阻塞的机制,阻塞的放入和得到数据.我们要实现LinkedBlockingQueue下面的两个方法put和take. put(anObje ...

  4. Win7的虚拟Wi-Fi

    前几天无意中发现,Win7的硬件驱动里有个叫Microsoft Virtual WiFi Miniport Adapter的东东,从网上查了一下,可以用来组建临时网络,共享Internet.一块无线网 ...

  5. poj2376 Cleaning Shifts 区间贪心

    题目大意: (不说牛了) 给出n个区间,选出个数最少的区间来覆盖区间[1,t].n,t都是给出的. 题目中默认情况是[1,x],[x+1,t]也是可以的.也就是两个相邻的区间之间可以是小区间的右端与大 ...

  6. Mongo连接远程数据库

    mongo IP+Port CrabyterV5 首先这么操作是基于配置了环境变量的,可以参照http://www.cnblogs.com/daiyonghui/p/5209076.html mong ...

  7. DNN结构演进History—CNN-GoogLeNet ：Going Deeper with Convolutions

    抄袭了一片文章,进行少量修改:http://www.gageet.com/2014/09203.php       作者:Christian Szegedy( google )  刘伟(北卡罗来纳  ...

  8. js对cookie增删改查的封装

    /** * 获取cookie * @param name * @returns {*} */ function getCookie(name) { var cookieArr = document.c ...

  9. Docker系列之入门

    Docker基本介绍 一.什么是Docker 在docker的官方之什么是docker中提到了一句话:“当今各大组织或者团体的创新都源于软件(例如OA.ERP等),其实很多公司都是软件公司" ...

  10. CodeIgniter-CI之MySQL

    首先我们需要进行一下配置,这里需要修改的文件为application目录下的config目录下的database.php文件,我们修改相应的配置项,比如这里是我的配置情况: 通常我们在操作数据库之前, ...