基于库源码和客户源码挖掘的API误用检测方法及系统

基于库源码和客户源码挖掘的api误用检测方法及系统
技术领域
1.本发明涉及的是一种信息安全领域的技术，具体是一种基于库源码和客户源码挖掘的api误用检测(cl-detector)方法及系统。


背景技术：

2.近年来，越来越多的软件系统通过调用应用程序编程接口(api)来复用第三方库或框架，以节省软件开发时间，提高软件开发效率。调用api应遵循api的各种约束，例如调用顺序、条件检查和异常处理。由于api数量众多，人工定义api约束和发现api误用非常繁琐，于是出现许多基于代码静态分析或动态分析方法的api误用自动检测研究。
3.现有基于客户代码挖掘的api误用检测技术从众多api使用代码片段中挖掘频繁出现的api使用模式，然后将违反api使用模式的api使用代码片段视为候选api误用，最后按可疑程度倒序排序。但是从客户代码挖掘到的api使用模式只代表常见的一部分api用法，和实际api约束存在较大鸿沟，缺乏全面性和精确性，从而导致api误用检测的召回率和精确度较低，难以投入实际使用。而且这不适用于不常见或新发布的api，因为难以获取足够的客户代码用于挖掘使用模式。因此如何挖掘全面且精确的api约束来提升api误用检测效果，需要深入探讨。


技术实现要素：

4.本发明针对现有方法从客户代码挖掘到的api使用模式和实际api约束相比缺乏全面性和精确性的问题，本发明提出一种基于库源码和客户源码挖掘的api误用检测方法及系统，利用api的第三方库源码挖掘出更全面和精确的api约束，有效弥补来自客户代码的api使用模式和实际api约束存在较大鸿沟，以及不常见api难以获取足够客户代码的问题，显著提高api误用检测的召回率和精确度。
5.本发明是通过以下技术方案实现的：
6.本发明涉及一种基于库源码和客户源码挖掘的api误用检测方法，分别通过频繁子图挖掘算法挖掘客户代码中频繁出现的api使用模式作为api使用模式约束、通过收集库源码中每个目标api类及其父类的所有方法进行代码解析构建出抽象语法树，然后使用推导策略从中抽取出api库源码约束；再将两种约束表示成api使用图后进行约束合并和约束优化，并采用图匹配算法进行api误用检测，根据得到的候选api误用计算其误用可疑程度，实现api误用检测。
7.所述的api误用是指：违反api约束的api使用代码片段，包括缺少条件检查、缺少异常处理、缺少方法调用、冗余调用等误用类型。
8.所述的客户代码是指：从github收集到的实际项目中使用特定api的代码片段。
9.所述的约束包括：条件检查约束、异常处理约束和调用顺序约束，其中：条件检查约束是指在调用某个对象的某个方法之前，要对方法参数取值或当前对象的状态进行检查，例如调用java.util.list类的get(intindex)方法前要检查index》＝0；异常处理约束
是指当调用某个方法时要考虑处理该方法可能抛出的异常，例如调用java.io.fileinputstream类构造方法时要处理文件不存在时抛出的nullpointerexception异常；调用顺序约束是指多个api方法往往需要按一定顺序调用才能正确发挥作用，例如调用java.util.iterator类next()方法前要先调用hasnext()方法确保迭代器中存在下一个元素。
10.所述的api使用模式约束是指：在客户代码中频繁出现的api用法，使用api使用图表示，其具体通过以下方式挖掘得到：
11.1)将每个api使用代码片段表示为api使用图：使用eclipse jdt解析工具将代码片段表示为ast抽象语法树，从中抽取出数据或动作实体、以及数据流和控制流关系来作为api使用图的节点和边，从而生成api使用图。
12.所述的api使用图是指：表示一个api使用代码片段中api用法的图。它由多种类型的点和边组成。api使用图的节点代表代码中的包括对象、值和字面值在内数据实体以及包括方法调用、操作符和指令在内的动作实体。api使用图的边代表节点之间的控制流和数据流，包括：发起调用、传递参数、初始化赋值、执行顺序、条件分支、异常抛出、异常捕获、同步锁。
13.2)从众多表示为api使用图的api使用代码片段中，使用频繁子图挖掘算法，得到在众多由点和边构成的图中频繁出现的子图，当频繁程度达到预设阈值时，将该api使用子图作为api使用模式。
14.所述的频繁子图挖掘算法将图中调用了目标api的方法调用节点作为初始子图，在保证频繁程度大于阈值的前提下向周围邻居节点递归扩展成为更大的子图；在递归扩展过程中，遍历子图周围的每个邻居节点，判断其能否加入子图，同时忽略仅通过控制流关系的边相连而无数据流关系的节点，因为这些节点与目标api的使用无关，通常是项目自身业务逻辑相关的代码。
15.所述的api库源码约束，通过以下方式挖掘得到：
16.1)确定库源码中分析的方法范围：确定库源码中每个目标api所在类的所有方法，当它继承父类，将所有父类的方法也纳入分析范围，因为很多父类的方法经常在子类中被使用。当目标api是接口而没有具体实现，则对其一个常用实现类的方法实现进行分析。
17.2)通过推导策略从库源码推导api约束：首先生成每个api方法源码的抽象语法树，然后根据推导策略从语法树节点信息抽取出api实现源码中隐含的api约束。
18.所述的api库源码约束中的条件检查约束，通过以下推到策略得到：
19.策略1:识别出源码中的assert关键字和objects.requirenonnull()方法的调用，提取其中的参数为条件检查约束。再识别@param或@throws注解中对方法参数取值的条件约束。
20.策略2:识别出throw关键字，再识别包裹throw异常抛出语句的条件分支语句中的条件，将包含外部无法访问的私有属性或局部变量的条件过滤掉，剩余作为条件检查约束。
21.策略3：java本地方法也有条件检查约束，但没有java源码实现，本实施例基于java开发经验人工分析常见的java本地方法，并定义其条件检查约束。
22.策略4:在api方法实现内部会调用其他方法，被调用的其他方法中存在的条件检查约束可能被传递到api方法。所以对一定调用深度内的其他方法也通过上述三种策略推
导约束。
23.所述的api库源码约束中的异常处理约束，通过以下推导策略得到：
24.策略5:识别出throw语句、throws关键字、@throws注解和@exception注解，其后的异常类就是可能被抛出的异常，提取为异常处理约束。
25.策略6:推导出异常处理约束和条件检查约束之间的可替换关系，对应api的客户代码只需满足可替换约束的其中之一即可。当某异常处理约束对应的throw语句被条件分支语句包裹，而可以根据策略2从该条件分支语句推导出条件检查约束，则二者存在可替换关系。
26.所述的api库源码约束中的调用顺序约束，通过以下推导策略得到：
27.策略7:从方法调用关系图推导调用顺序约束。当方法1初始化变量a，方法2使用变量a，则方法1需要先于方法2被调用。当方法3中使用对象o，方法4中清除对象o如置为null，则方法4需要后于方法3被调用。这二者顺序关系可以经过方法调用关系图传递到调用这些方法的方法中。
28.策略8:定义2个基于方法名称的启发式规则。一是方法名包含hasnext的方法先于方法名包含next的方法被调用，适用于遍历相关的api如java.util.iterator类。二是方法名包含close的方法后于方法名包含write的方法被调用，适用于资源使用相关的api如java.io.dataoutputstream类。
29.所述的约束合并，是指：将来自库源码的约束表示成api使用图形式，和来自客户代码的约束统一。对于每个约束，生成满足该约束的api使用代码片段，在将api使用代码片段表示为api使用图。例如方法method有条件检查约束condition，生成代码片段为“if(condition{}){method()；}”。
30.所述的约束优化，包括：增强来自客户代码的api约束和提高约束的全面性和丰富性。
31.所述的增强来自客户代码的api约束是指：当约束的方法和类型和库源码的约束重叠，将重叠的约束的精细语义细节传递给来自客户代码的约束，例如调用顺序约束的前置或后置类型；然后将来自库源码和客户源码的api约束集合直接合并。
32.所述的提高约束的全面性和丰富性是指：根据库源码的约束修改客户代码的约束，从而产生新的约束，当客户代码的约束中的子图与条件检查或异常处理相关，用库源码的相应类型约束替换该子图，生成与原始约束具有替代关系的新约束。
33.所述的api误用检测过程，具体包括：
34.1)对于每个待检测的api使用代码片段，生成其api使用图，然后使用图匹配算法与api约束的api使用图进行匹配，未能匹配即违反api约束的代码片段被视为候选的api误用。
35.2)计算候选api误用的误用可疑程度，取误用可疑程度最高的k个报告为最终api误用。
36.所述的误用可疑程度指：一个候选api误用作为真实api误用的可能性打分。影响该打分的因素有：所违反api约束在客户代码中出现的频繁程度、api约束是否从库源码挖掘到、这种api约束的违反情形在客户代码中出现的频繁程度和满足api约束的用法的差距。
37.本发明涉及一种实现上述方法的系统，包括：客户代码挖掘模块、库源码挖掘模块、约束结合模块和误用检测模块，其中：客户代码挖掘模块生成客户代码中频繁出现的api使用模式作为api约束，库源码挖掘模块推导api实现源码中隐含的api约束，约束结合模块将来自库源码和客户代码的api约束结合，误用检测模块检测出违反api约束的api误用。技术效果
38.本发明整体解决现有基于客户代码的api误用检测方法的api使用模式和实际api约束存在鸿沟且缺乏全面性和精确性的不足。本发明通过从api库源码挖掘api约束的组件、来自客户代码和库源码的api约束融合组件，基于多种挖掘策略从库源码中挖掘到包含多种类型的更为全面的api约束，在两种来源的api融合模块用来自库源码的约束去增强来自客户代码的约束，提高了api约束的丰富程度。与现有技术相比，本发明显著提高api误用检测的召回率和准确率，利用api库源码这一来源去推导api约束，无论api是否有足够客户代码，作为api约束起源的api库源码始终存在，且能推导得到较为全面且精确的api约束，有效解决来自客户代码的api使用模式和真实api约束存在鸿沟的问题，提高api误用检测的效果。
附图说明
39.图1为本发明方法架构图；
40.图2为实施例中api部分源码和隐含的api使用图形式的api约束实例示意图。
具体实施方式
41.如图1所示，涉及一种基于库源码和客户源码挖掘的api误用检测方法，包括：
42.1)采用数据集mubench作为待检测api使用代码片段。
43.所述的数据集mubench为api误用实例的数据集，其包括实际项目出现的一些api误用实例，每个api误用实例数据包括：误用所在的项目仓库地址、误用所在的项目版本的commitid、误用所在的文件和方法位置、误用的api、关于如何误用api的描述。
44.2)收集目标api及其所在第三方库的源码，用于后续客户代码的收集。
45.所述的目标api包括：api误用数据集mubench中误用实例涉及到的所有api类，以及在stackoverflow论坛中广泛讨论的前100个javaapi方法所在的api类。
46.3)从github收集使用目标api的客户代码，具体为：利用boa挖掘工具从github仓库中筛选出使用每个目标api次数最多的前20个开源项目作为客户项目，从每个客户项目中筛选出使用目标api的代码片段作为客户代码，使用api指的是某个类调用了该api类的方法。
47.4)分别从客户代码和库源码挖掘api约束后进行约束合并；
48.所述的挖掘api约束中，从客户代码挖掘出api约束是指：将客户代码表示为api使用图，使用频繁子图挖掘算法挖掘出频繁出现的api使用子图，频繁程度超过阈值为5的api使用子图作为api使用模式，即来自客户代码的api约束。
49.如图2(a)所示，为java.util.iterator这一api类中部分代码的实现，其中隐含了调用顺序约束:调用next()方法前需调用hasnext()、调用remove()方法前需调用next
()，这两个约束表示成api使用图如图2(b)所示。
50.所述的挖掘api约束中，从库源码挖掘api约束是指：对每个目标api类，收集该类及其父类的所有方法进行代码解析，构建抽象语法树，然后使用推导策略从抽象语法树中抽取出条件检查约束、异常处理约束和调用顺序约束。
51.所述的约束合并是指：将api库源码约束表示为api使用图，然后和api使用模式约束的api使用图集合合并到一起，得到最后的api约束集合。
52.5)基于挖掘到的api约束进行api误用检测，具体为：将待检测的api使用代码片段表示为api使用图，使用图匹配算法将其与api约束的api使用图进行匹配，再对违反api约束的候选api误用计算误用可疑程度，实现api误用检测。
53.所述的误用可疑程度的计算公式为：score＝(cs s
l
)/vs*vd，vd＝nm/nc，其中：cs为所违反的api约束在客户代码中出现的次数；s
l
为来自库源码的api约束的初始权重常量，当约束来自库源码，s
l
设置为1，否则，s
l
＝0；vs为该api约束误用在客户代码中出现的次数，越罕见越可能是真实误用；vd衡量该误用和满足对于api约束的用法的差距，通过计算该误用相比api约束所缺少的节点个数nm除以api约束的节点总数nc得到。
54.本实施例采用api误用数据集mubench和其他api误用检测进行对比实验，mubench数据集中包含57个实际项目中的223个api误用实例，这些误用涉及65个api的用法，其中110个误用是因为缺少条件检查，26个误用是因为缺少异常处理，81个是因为缺少方法调用，还有6个是因为存在冗余元素如冗余调用等。本实施例收集106个目标api，其中包含65个mubench涉及的api，和68个在stack overflow论坛中广泛讨论的api。本实施例收集每个目标api的客户代码和库源码。从客户代码中本实施例挖掘到1092条约束，而从库源码中，本实施例挖掘到12，538条约束，其中包含712条条件检查约束、3432条异常处理约束和8394条调用顺序约束。
55.本实施例采用recall召回率、precision精确度和f1这三个指标来衡量不同api误用检测工具的检测结果的优劣，其中：recall召回率衡量有多少mubench误用实例被正确地检测到。precision精确度衡量在误用检测结果排序靠前的误用中有多少是真正的误用。f1指标是指recall召回率和precision精确度的调和平均数，计算公式如下：f1＝2*(precision*recall)/(precision recall)。
56.精确度需要人工分析检测结果是否为真实误用，因为误用检测结果中不在mubench中的误用也有可能是真正的误用。所以本实施例从mubench的57个项目中随机抽样10个项目，每个项目取前20个误用检测结果来计算精确度。为减少人为判断带来的误差，两名java开发经验在3年以上的开发人员对检测结果进行独立标注，并采用cohen’s kappa指标来检验二者标注的一致性，最后对于二者不一致的地方进行讨论得出一致决定。
57.所述的kappa指标计算方式如下：k＝(p
o-pe)/(1-pe)。其中po是二者标注一致的样本数量之和除以总样本数。pe计算公式为pe＝(a1*a2 b*b2)/(n*n)，其中a1和a2为二者标注为正确误用的样本数量，b1和b2为二者标注为不正确误用的样本数量，n为总样本数。
58.本实施例选取的对比误用检测方法为mudetect。mudetect是最近表现最好的误用检测方法，它基于从客户代码挖掘到的api使用模式进行api误用检测。本实施例的误用检测方法是基于库源码和客户代码挖掘到的api约束，两种方法对比可以衡量来自库源码的api约束的有效性。
59.如表1所示，为mudetect和本方法在mubench数据集的recall召回率、precision精确度和f1指标的实验结果。
60.表1
61.从表1可以看出，本方法的误用检测结果的f1整体指标为45.6％，相比对比方法mudetect的f1结果34.5％有显著提升。本方法的召回率为50.2％，相比对比方法mudetect的召回率39.5％也有明显提升。从223个mubench误用实例中，本方法正确召回共112个误用，其中包括36个缺少条件检查、21个缺少异常处理和55个缺少方法调用。表1中的pre1和pre2分别表示标注者1、标注者2独立判断的精确度结果，pref为二者将不一致的地方讨论达成一致后的最终精确度结果。衡量一致性的kappa系数都在0.60以上，表明二者达到高度的一致性，精确度结果的可信度较高。本方法的最终精确度41.7％也显著高于mudetect。
62.对实验结果的分析如下：本方法在一定程度上解决由于来自客户代码的api使用模式与真正api约束存在鸿沟导致的api误用检测效果不好的问题。本方法从api约束起源的库源码出发，挖掘得到更全面且包含更多语义细节的精确的api约束，更全面的api约束能帮助检测到更多的api误用，更精确的api约束能减少被错误识别的误用，从而整体提升api误用检测结果的召回率和精确度。
63.上述具体实施例可由本领域技术人员在不背离本发明原理和宗旨的前提下以不同的方式对其进行局部调整，本发明的保护范围以权利要求书为准且不由上述具体实施例所限，在其范围内的各个实现方案均受本发明之约束。