app漏洞扫描工具有哪些，app漏洞挖掘教程分享

目前android应用代码漏洞扫描工具种类繁多，效果良莠不齐，这些工具有一个共同的特点，都是在应用打包完成后对应用进行解包扫描。这种扫描有非常明显的缺点，扫描周期较长，不能向开发者实时反馈代码中存在的安全问题，并且对于问题代码的定位需要手动搜索匹配源码，这样就更不利于开发者对问题代码进行及时的修改。code arbiter正是为解决上述两个问题而开发的，专门对android studio中的源码进行安全扫描。

1 背景介绍

为实现对android studio中的源码进行扫描，最方便的方式便是将扫描工具以ide插件的形式进行工作。此时一个很自然的想法便是从头构建一个android studio插件，但是进行仔细的评估后会发现，这样做难度并不小：

1. 工作量大，许多知识需要学习，如ide开放api接口、插件ui构建等，同时许多底层模块需要从头构建；
2. 插件的稳定性、检测问题的准确性上都不一定能够达到已有开源工具的效果。

因此我们转而考虑在已有漏洞检测插件的基础上进行扩展，以满足需求。经过调研，最终入围的两款检测插件是pmd和findbugs，其中pmd是对java源码进行扫描，而findbugs则是对java源码编译后的class文件进行扫描。考虑到可扩展性及检测的准确性，最终选定了findbugs。findbugs是一个静态分析工具，它检查类或者jar文件，将字节码与一组缺陷模式进行对比来发现可能的问题，可以以独立的jar包形式运行，也可以作为集成开发工具的插件形式存在。

扩展优化

那么，怎么扩展findbugs呢？调研发现findbugs插件具有着极强的可扩展性，只需要将扩展的jar包导入findbugs插件，重启，即可完成相关功能的扩展。安装jar包示意图如下所示。

下面的问题是如何构建可安装的jar包。继续调研，发现findbugs有一款专门对安全问题进行检测的扩展插件find security bugs，该插件主要用于对web安全问题进行检测，也有极少对android相关安全问题的检测规则。考虑以下几个原因，需要对该插件的源码进行重构。

1. 对android安全问题的检测太少，只包含外部文件使用、webview、broadcast使用等寥寥几项；
2. 检测的细粒度上考虑不够完全，会造成大量的误报，无法满足检测精度的要求；
3. 检测问题的上报只支持英文模式，且问题展示的逻辑性不够严谨，不便于开发者进行问题排查。

基于以上三个原因，我们需要对find security bugs的源码进行重写、优化，通过增加检测项来检测尽可能多的安全问题，通过优化检测规则来减少检测的误报，问题展示使用中文进行描述，同时优化问题描述的逻辑性，使得开发者能够更易理解并修改相关问题，至此插件实现及优化的方案确定。

2 工具实现介绍

findbugs检测的是class文件，因此当待检测的源码未生成编译文件时，findbugs会先将源码编译生成.class文件，然后对这个class文件进行分析。findbugs会完成对class文件的自动建模，在此模型的基础上对代码进行分析。按照在实际编写检测代码过程中的总结，把检测的实现方式分成四种方式，下面分别进行介绍。

2.1 逐行检查

逐行检查主要是针对代码中使用的一些不安全方法或参数进行检测，其实现方式是重写sawopcode()方法，下面以android中使用外部存储问题作为示例进行讲解。

android中获取外部存储文件夹地址的方法主要包括下面这些方法：

getexternalcachedir()

检测的方式便是，如果发现存在该方法的调用，则作为一个问题进行上报，实现完整代码如下所示：

public class externalfileaccessdetector extends opcodestackdetector { private static final string android_external_file_access_type = "android_external_file_access"; private bugreporter bugreporter; public externalfileaccessdetector(bugreporter bugreporter) { this.bugreporter = bugreporter;

该类的实现是继承opcodestackdetector类，是findbugs中的一个抽象类，封装了对于获取代码特定参数的方法调用。sawopcode方法参数可以理解为待检测代码行的行号，通过printopcode(seen)可以打印该代码行的具体内容。constants.invokevirtual表示该行调用类的实例方法，constants.invokestatic表示调用类的静态方法。getnameconstantoperand方法表示获取被调用方法的名称，getclassconstantoperand方法表示获取调用类的名称，getsigconstantoperand方法表示获取方法的所有参数。bugreporter.reportbug用于上报检测到的漏洞信息，其中buginstance的三个参数分别表示：检测器、漏洞类型、漏洞等级，其中漏洞等级分为五个级别，如下表所示：

名称	参数	含义
high_priority	1	高危风险
normal_priority	2	中危风险
low_priority	3	低危风险
exp_priority	4	安全提醒
ignore_priority	5	可忽略风险

addclass、addmethod、addsourceline用于指定该漏洞所在的类、方法、行，方便报告漏洞时定位关键代码。

2.2 逐方法检查

逐方法检查首先获取待检测类的所有内容，然后对类中的方法进行逐个检查，多用于对方法体进行检测，其实现的方法主要是通过重写visitclasscontext方法，下面以对android trustmanager的空实现的检测为例进行说明。

trustmanager的空实现，主要是指对于检测server端证书是否可信的方法checkservertrusted，是否是空实现。下面展示问题代码，如果是空实现那么将导致客户端接收任意证书，从而造成加密后的https消息被中间人解密。

@overridepublic void checkservertrusted(x509certificate[] x509certificates, string s) throws certificateexception {

检测的方式是通过遍历类中的所有方法，找到checkservertrusted方法，对方法整体进行检测，确定其是否为空实现，部分代码如下所示：

public class weaktrustmanagerdetector implements detector {

classcontext.getjavaclass用于获取整个类的所有内容；javaclass.getmethods用于获取该类中的所有方法，以一个方法列表的形式返回；classcontext.getmethodgen用于获取该方法的内容；isemptyimplementation将方法的内容导入该函数进行检测，用于确定方法是否是空实现，该方法的代码如下所示：

private boolean isemptyimplementation(methodgen methodgen){ boolean invokeinst = false; boolean loadfield = false; for (iterator itins = methodgen.getinstructionlist().iterator();itins.hasnext();) {

该方法主要用于检测方法中是否包含方法调用、域操作，如果没有包含则认为是一个空实现的方法。因此该方法对于只包含 return true/false 语句的方法体同样认为是一个空实现。

2.3 污点分析

数据流分析主要用于分析特定方法加载的参数是否能够被用户控制，即进行污点分析。做污点分析首先需要定义污染源（source点），污染源可以理解为能够被用户控制的输入数据，这里定义的android污染源主要包括用户的输入、intent传入的数据，下面展示定义的部分污染源（source点）：

- edittext

定义好污染源后就需要确定污染的触发点（sink点），可以理解为会触发危险操作的函数。定义sink点的方式有两种，一种是直接从文件中导入，以命令注入为示例，代码如下：

public class commandinjectiondetector extends basicinjectiondetector { public commandinjectiondetector(bugreporter bugreporter) { super(bugreporter);

从代码中可以清楚的看到其导入方式是继承basicinjectiondetector类，然后再该类的构造方法中通过loadconfiguredsinks方法，导入包含sink点的文件，下面展示该示例文件中的内容：

java/lang/runtime.exec(ljava/lang/string;)ljava/lang/process;:0

另一种是自定义导入，其实现是通过覆盖basicinjectiondetector类中的getinjectionpoint方法，以webview.loadurl方法为例，示例代码如下所示：

@override

通过实例化injectionpoint类构造新的sink点，其构造方法中的第一个参数表示该方法接收污染数据参数的位置，如方法为webview.loadurl(url)，其第一个参数就是new int[]{0}，其它的以此类推。

上报发现漏洞的情况，则通过覆盖getpriorityfromtaintframe方法的实现，示例代码如下所示：

@override

通过fact.getstackvalue获取检测的函数变量，如果该变量被污染（istainted）或 变量是否被污染未知（但是是可控制变量），那么作为一个中危风险（
priorities.normal_priority）进行上报，其它的情况则上报为可忽略风险（
priorities.ignore_priority）。

2.4 自定义代码检测

自定义代码检测实现的前半部分同2.2的逐方法检测类似，均是获取类的内容，然后遍历所有的方法，对方法的内容进行检测，但是在具体代码检测实现上是通过自定义分析进行。目前自定义检测只应用到android中本地拒绝服务的检测。本地拒绝服务的被触发的重要原因在于对通过intent获取的参数未进行异常捕获，因此检测实现的方式便是检测获取参数的代码行是否被try catch包裹（这个存在误差，待改进）。对于其代码分析，不能使用findbugs模型进行分析，而是使用最原始的class代码进行分析，原始class代码的形式通过javap命令进行查看，下图展示示例代码。

对原始class文件进行分析存在的缺陷是无法定位具体的代码行，那么在进行问题上报时无法将问题定位到代码行，因此第一步需要在原有模型的基础上对所有包含intent获取参数的方法的位置存储到一个map结构中，方便后面对方法的定位，代码实现如下所示，获取方法所在的行，然后以方法名作为key值，以代码行相关信息作为value值，存储到map中。

private map<string, list<location>> get_line_location(method m, classcontext classcontext){

之后获取exception包裹的范围，findbugs中包含对exception的建模，因此能够通过其模型能够直接获取其范围并存储到一个列表中，代码如下所示，其中exceptiontable[i].getstartpc用于获取try catch 的起始代码行，exceptiontable[i].getendpc用于获取try catch 的结束代码行。

public int[] getexceptionscope(){ try {

在对代码进行逐行检查时，因为使用的是最原始class文件形式，因此需要限定其遍历的范围，限定的方式是通过代码的行号，即上图中每行代码的第一个数值。首先需要获取代码总行数的大小，获取的方式便是解析findbugs建模后的第一行代码，找到关键词code-length后面的数值，即为代码的行数，解析代码如下所示：

public int get_code_length(string firstlinecode){ try{

最后对代码进行逐行遍历，遍历中为防止try catch块被遍历到，使用行号来限制遍历的范围。检测代码行是否包含通过intent获取参数，及该行是否被try catch 包裹，如果上述两个条件均被触发，那么就作为一个问题进行上报。示例代码如下，其中get_code_line_index方法用于获取代码的行号，获取的方式是截取代码行的首字符的数值，以确定是否在代码包裹的范围内。

private void analyzemethod(javaclass javaclass, method m, classcontext classcontext) throws cfgbuilderexception {

3 注册打包

上面详细叙述了如何构造自己的问题检测代码，完成检测方法的书写后，下一步就是在配置文件中对检测方法进行注册，才能使检测代码运转起来。

需要在两个文件中进行注册，第一个是findbugs.xml，注册示例如下：

<detector class="com.h3xstream.findsecbugs.android.localdenialofservicedetector" reports="local_denial_service"/>

其中detector用于注册该检测方法的位置及其唯一标识，bugpattern用于对检测出的问题进行归类，方便展示，如此处归类到”android安全问题”中，那么在生成报告的时候问题也将被归类到”android安全问题”中。

第二个是messages.xml注册，注册示例如下，该注册主要是对该问题进行说明，包括问题的危害及修复方法。

<detector class="com.h3xstream.findsecbugs.android.localdenialofservicedetector"><details>local denial of service.</details></detector><bugpattern type="local_denial_service"><shortdescription>本地拒绝服务</shortdescription><longdescription>通过intent接收的参数未进行异常捕获，导致出现异常使得应用崩溃</longdescription><details><![cdata[ <p> <b>危害:</b><br/> <pre> 应用崩溃无法使用，影响用户体验； 被竞争对手利用，进行点对点攻击。 </pre> </p> <p> <b>错误代码:</b><br/> <pre> bundle.getstring(""); //未try/catch intent.getstringextra(""); //未try/catch </pre> </p> <p> <b>解决方案:</b><br/> <pre> 对通过intent接收的参数处理时，进行严格的异常捕获。 try { bundle.getstring(""); intent.getstringextra("");  }catch (exception e){} </pre> </p>]]></details></bugpattern><bugcode abbrev="secldos">本地拒绝服务</bugcode>

一切完成就绪后使用maven进行打包，就生产了供findbugs集成开发工具插件使用的jar包，完成安装并重启，即可使用自定义插件对特定问题进行检测。

最终分析的效果图如下图所示：

4 结语

本文介绍了android集成开发环境android studio的代码实时检测工具code arbiter的产生原因及代码实现，最后展示了分析的效果。通过code arbiter在生产环境中的应用，其检测效果还是相当不错，能够发现很多编码过程中存在的问题。但是code arbiter仍然存在许多不足，需要优化。后续将在以下两个方面对工具进行改进：

1. 扩大漏洞检测范围，使code arbiter能够囊括android编码常见安全问题；
2. 优化漏洞检测规则，提高检测的准确性，减少误报。