一种确定被动IAST测试API覆盖率的方法及装置转让专利
申请号 : CN202110940183.5
文献号 : CN113392033B
文献日 : 2022-03-08
发明人 : 张涛 , 宁戈 , 蔡智强 , 董毅
申请人 : 北京安普诺信息技术有限公司
摘要 :
权利要求 :
1.一种确定被动IAST测试API覆盖率的方法,其特征在于,该方法包括:获取目标Web应用程序中的全量API信息,所述API信息包括所述API对应的URL路径信息;其中,获取全量API信息的过程,包括:在目标Web应用程序的路由注册函数中插桩第二探针,并配置得使所述第二探针在路由规则注册到路由系统的过程中/路由规则注册到路由系统后,获取对应的URL路径与实际处理程序的映射集合;以及根据所述映射集合中的每条URL路径与实际处理程序的映射关系信息,获取所述API信息;在测试过程中,通过预先插桩的第一探针获取其中测试请求访问过的URL路径信息,记录所述URL路径对应的API的执行情况;其中,所述第一探针为复用被动IAST测试中的探针,解析测试请求,获取每个测试请求的URL路径信息;根据记录的至少被执行一次的API数与所述的全量API的总数,确定所述测试的API测试覆盖率。
2.根据权利要求1所述的方法,其特征在于,对目标Web应用程序插桩所述探针的实现方式,包括:以运行时插桩的方式对目标Web应用程序插桩所述探针。
3.根据权利要求1所述的方法,其特征在于,在所述测试过程中,通过所述第一探针实时获取其中测试请求访问过的URL路径信息,记录所述URL路径对应的API的实时执行情况;
进而统计所述测试过程中的实时API覆盖率。
4.一种确定被动IAST测试API覆盖率的装置,其特征在于,该装置包括:采集模块、测试记录模块和计算模块;
所述采集模块,被配置为用于采集目标Web应用程序中的全量API信息;所述采集模块,具体被配置为在目标Web应用程序的路由注册函数中插桩第二探针,并配置得使所述第二探针在路由规则注册到路由系统的过程中/路由规则注册到路由系统后,获取对应的URL路径与实际处理程序的映射集合;以及根据所述映射集合中的每条URL路径与实际处理程序的映射关系信息,获取目标Web应用程序的全量API信息;所述测试记录模块,被配置为在测试过程中通过预先插桩的第一探针获取其中测试请求访问过的URL路径信息,记录所述URL路径对应的API的执行情况;其中,所述测试记录模块,具体被配置得使所述第一探针为复用所述被动IAST测试中的探针,解析测试请求,获取每个测试请求的URL路径信息;所述计算模块,被配置为根据测试记录模块记录的至少被执行一次的API数与采集模块采集的所述全量API的总数,计算所述测试的API测试覆盖率。
5.根据权利要求4所述的装置,其特征在于,所述探针,被配置得以运行时插桩的方式对目标Web应用程序进行插桩。
6.根据权利要求4所述的装置,其特征在于,所述测试记录模块,被配置为在所述测试过程中,通过所述第一探针实时获取其中测试请求访问过的URL路径信息,记录所述URL路径对应的API的实时执行情况;
进而配置得使所述计算模块实时统计所述测试过程中的API覆盖率。
7.一种确定被动IAST测试API覆盖率的装置,其特征在于,该装置包括:至少一个处理器,和至少一个处理器耦合的存储器,以及存储在存储器中的计算机程序;
其中的处理器执行所述计算机程序,能够实现权利要求1‑3任一所述的方法。
8.一种计算机可读存储介质,其特征在于,该介质上存储有确定测试覆盖率相关的计算机指令,该计算机指令在被计算机处理器执行时能够实现权利要求1‑3任一所述的方法。
说明书 :
一种确定被动IAST测试API覆盖率的方法及装置
技术领域
背景技术
服务器端运行的部分)两部分。得益于前端技术的发展,前后端分离已经成为行业内开展互
联网项目、开发相关Web应用程序的标配模式。通过前、后端的有效解耦,实现前后端分离,
前端开始更加注重页面开发的工程化、自动化,后端则更专注于API(这里的API,主要是指
前后端分离模式下一种非常重要的后端路由实现方式)的提供和数据库的保障。因此,在针
对Web应用程序的测试中,往往将API覆盖率作为衡量相关软件测试完整性的重要指标。
此不免要尽可能地掌握全量代码,同时更是大费周章,却往往有因对代码结构信息分析不
到位造成API覆盖率统计失准。
的规模越来越大、越来越依赖第三方开源组件等因素几乎很难获得目标Web应用程序的全
量API信息外,在例如被动IAST测试等一些测试中,由于其与自动化功能测试并行,在发出
攻击报文的测试端并不统计请求访问的API信息,故连已执行API信息的获取都是统计API
覆盖率时要解决的技术问题。
发明内容
信息;并在所述测试过程中,通过预先插桩的第一探针获取其中测试请求访问过的URL路径
信息,记录所述URL路径对应的API的执行情况;以及根据记录的至少被执行一次的API数与
所述的全量API的总数,确定所述测试的API测试覆盖率。
用程序中的全量API信息;测试记录模块,被配置为在测试过程中通过预先插桩的第一探针
获取其中测试请求访问过的URL路径信息,记录所述URL路径对应的API的执行情况;计算模
块,被配置为根据测试记录模块记录的至少被执行一次的API数与采集模块采集的所述全
量API的总数,计算所述测试的API测试覆盖率。
序;其中的处理器执行所述计算机程序,能够实现第一方面述及的方法。
法。
解。
附图说明
中a示出了请求进入应用程序中的后端路由的具体实现过程的示意图;图3中b示出了上述
实施例中的一些的有效获取目标Web应用程序中的全量API信息的过程的示意图;
具体实施方式
里阐述的实施例,相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的
是,本公开的附图及实施例仅用于示例性作用,并非用于限制本公开的保护范围。
例”应当理解为“至少一个实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对
象。下文还可能包括其他明确的和隐含的定义。
征数据(即运行时数据);通过对目标特征数据的分析,可以获得程序的控制流、数据流、逻
辑覆盖等动态信息,实现相应的测试目的的技术手段。其中的“探针”,本质上是进行信息采
集的代码片段。在本公开的实施例的“探针”除了用于获取请求数据和返回数据、获取代码
执行中传递的数据、监听内存中特定的值、识别受污染的输入等外,还可以根据插桩点、测
试目的、涉及需求等的不同,设计并实现具有相应自定义功能的“探针”。
其为测试对象进行测试、并待确定其在该测试中测试覆盖率的对象。在本公开的实施例的
描述中技术术语“目标Web应用程序”,主要是指Web后端应用程序,即如无特殊说明,“目标
Web应用程序”具体是指对外提供所述API的Web后端应用程序。
息、财产安全甚至生命安全。于是,为确保Web应用程序在交付前后的安全性,就需要行业内
在这些漏洞、缺陷被黑客找到前,运用Web应用安全测试技术发现它们。IAST(交互式应用程
序安全测试),是一种新型应用程序安全测试方案;较之传统的SAST、DAST技术,IAST技术能
够高效、准确地识别安全缺陷及漏洞,甚至可以准确确定漏洞所在的代码文件、行数、函数
及参数。其中的被动IAST测试技术更是仅通过被动插桩在运行时监视应用并分析代码,其
不会主动对Web应用程序执行攻击,而是纯粹被动地分析检测代码,而被行业内认为是最有
实用意义的IAST技术。然而,由于是被动监视目标Web应用程序,在测试过程中,测试人员一
般只能够掌握到表象的测试用例执行情况,而不能实质性地了解到测试过程中包括API覆
盖等在内的目标对象内部运行相关的表征测试的参数。其中,例如,API覆盖率,就是评估测
试完整性时最有价值的指标之一。
由、被实际处理的过程100的示意图。如图1所示,过程100包括:请求发出并经Web服务器进
入应用程序后,经路由系统110将其映射到相应的实际处理程序120,进而得到实际处理。因
此,在测试过程中,API提供的后端路由的执行情况,无疑实质性地反映着测试最具实质意
义的覆盖程度。而在一些现有技术中,有人提出利用代码覆盖率工具通过执行测试用例、收
集程序执行轨迹信息以及进而结合代码结构信息分析的方式统计整个软件测试全过程的
API覆盖率;然而,Web应用程序的规模越来越大、越来越依赖第三方开源组件,无论是是否
能够获取到全量代码的决定性阻碍、还是测试过程中需要遍历全量代码的庞大开销问题,
亦或是因对代码结构信息分析不足导致最终API覆盖率统计误差(而说到对代码结构进行
分析,一般需要资深开发人员;对于大规模软件项目,往往更是需要连续参与甚至是主导项
目的开发人员),上述方案都非优选。
请求访问过的URL路径信息,记录所述URL路径对应的API的执行情况,以及根据记录的至少
被执行一次的API数与采集获取的全量API的总数,确定所述测试的API覆盖率。相较于现有
技术,上述方案显然开销更小,受人为因素影响小,结果更为准确,而且能够在不掌握全量
代码的情形下仍能够得到所述API覆盖率。
如图2所示,确定被动IAST测试API覆盖率的过程200,主要包括:首先,通过读取输入配置或
实时获取等方式,获取目标Web应用程序中的全量API信息,其中,使所述API信息包括所述
API对应的URL路径信息(参考框201);并且在需要确定API覆盖率的测试的进行过程中,通
过预先插桩第一探针,和通过其获取其中测试请求访问过的URL路径信息,记录所述URL路
径对应的API的执行情况(参考框202);进而,根据记录的至少被执行一次的API数与所述的
全量API的总数,确定所述测试的API测试覆盖率(参考框203)。
应的URL路径信息。具体地,其实现过程可以是,包括:配置得使所述被动IAST测试中的探针
在执行获取运行时数据等功能的同时,也能够获取其中测试请求访问过的URL路径信息,记
录所述URL路径对应的API的执行情况。其中,上述实施例中选择的所述被动IAST测试中探
针,优选可以是其中用于解析测试请求探针,也可以是被动IAST测试过程中其他位点插桩
的探针。
示意图。如图3中a所示,目标Web应用程序中的路由系统110,具体地,可以是包括:路由注册
模块310和路由发现模块320;请求进入到应用程序时,具体地,可以是:请求进入到路由发
现模块320,并经路由注册模块310注册到其中路由对象中的路由规则,映射到实际处理程
序120。结合图3中a,对应地,图3中b即示出了上述实施例中的一些的有效获取目标Web应用
程序中的全量API信息的过程的示意图。如图3中b所示,采用插桩方式获取目标Web应用程
序的全量API信息的过程300,可以是,包括:在目标Web应用程序的路由注册函数中插桩第
二探针,并配置得使所述第二探针在路由规则注册到路由系统的过程中/路由规则注册到
路由系统后,获取对应的URL路径与实际处理程序的映射集合(参考框301);以及根据所述
映射集合中的每条URL路径与实际处理程序的映射关系信息,获取所述全量API信息(参考
框302)。
序启动过程中,对目标插桩位点插桩所述第一探针、第二探针以及IAST测试过程中的其他
探针。例如,对于Java编程的目标Web应用程序,可以在其类加载时,通过如手动、字节码插
桩工具修改等方式对目标插桩点插桩所述探针。
实时记录的至少被执行一次的API数与所述的全量API的总数,确定所述测试的实时的API
测试覆盖率。
中,采集模块410,被配置为用于采集目标Web应用程序中的全量API信息;测试记录模块
420,被配置为在测试过程中通过预先插桩的第一探针获取其中测试请求访问过的URL路径
信息,记录所述URL路径对应的API的执行情况;计算模块430,被配置为根据测试记录模块
记录的至少被执行一次的API数与采集模块采集的所述全量API的总数,计算所述测试的
API测试覆盖率。为提高系统健壮性,在一些实施例中,可以是采用分布式架构。图5示出了
上述实施例的一种分布式的确定被动IAST测试API覆盖率的装置500的框图。如图5所示,装
置500,包括:采集模块510、测试记录模块520,以及分开部署的计算模块530;其中的采集模
块510、测试记录模块520,分别配置得获取所述全量API信息、所述已执行API信息(即至少
被执行一次的API),并输出给计算模块530;而计算模块530则被配置为根据采集模块510输
入的全量API信息(全量API的总数)、测试记录模块520输入的已执行API信息(至少被执行
一次的API数),计算所述测试的实时的API测试覆盖率。
使所述被动IAST测试中的探针在执行获取运行时数据等功能的同时,也能够获取其中测试
请求访问过的URL路径信息,记录所述URL路径对应的API的执行情况。其中,上述实施例中
选择的所述被动IAST测试中探针,优选可以是其中用于解析测试请求探针,也可以是被动
IAST测试过程中其他位点插桩的探针。
二探针,并配置得使所述第二探针在路由规则注册到路由系统的过程中/路由规则注册到
路由系统后,获取对应的URL路径与实际处理程序的映射集合、并根据所述映射集合中的每
条URL路径与实际处理程序的映射关系信息,获取所述全量API信息。
中,对目标插桩位点插桩所述第一探针、第二探针以及IAST测试过程中的其他探针。例如,
对于Java编程的目标Web应用程序,可以在其类加载时,通过如手动、字节码插桩工具修改
等方式对目标插桩点插桩所述探针。
行情况;进而可以使计算模块根据上述实时记录的至少被执行一次的API数与所述的全量
API的总数,计算实时的API测试覆盖率。
开的一些实施例的计算设备600的框图。如图6所示,计算设备600,包括中央处理器(CPU)
601,其能够根据存储在只读存储器(ROM)602的计算机程序指令或从存储单元608加载到随
机访问存储器(RAM)603中的计算机程序指令,来执行各种适当的操作和处理,在(RAM)603
中,还可以存储计算设备600操作所需的各种程序代码、数据。CPU601、ROM602、RAM603通过
总线604彼此相连,且输入/输出(I/O)接口605也与总线604相连。计算设备600的一些部件
通过I/O接口605接入,包括:输入单元606,如键鼠等;输出单元607,如显示器等;存储单元
608,如磁盘、光盘、固态硬盘(SSD)等,以及通信单元609,如网卡、调制解调器等。通信单元
609能够使计算设备600通过计算机网络与其他设备交换信息/数据。CPU601能够执行上述
实施例中描述的各种方法和处理过程,例如过程200。在一些实施例中,过程200,可以被实
现为计算机软件程序,其被例如存储单元608等的计算机可读介质。在一些实施例中,计算
机程序的部分或全部被载入或安装到计算设备600。当计算机程序被加载到RAM603被
CPU601执行时,能够执行过程200的部分或者全部操作。
集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备
(CPLD)等等。
理器或控制器,使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的
功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行,作为独立软件
包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电
子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备,或者上述内容的任何合
适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计
算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM
或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD‑ROM)、光学储存设备、磁储存设备、或
上述内容的任何合适组合。
在一定环境下,多任务和并行处理可能是有利的。同样地,虽然在上面论述中包含了若干具
体实现细节,但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文
中描述的某些特征还可以组合地实现在单个实现中。相反地,在单个实现的上下文中描述
的各种特征也可以独立地或以任何合适的子组合的方式实现在多个实现中。
面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。