CN113392033B - 一种确定被动iast测试api覆盖率的方法及装置 - Google Patents

Abstract

本申请公开的实施例提供了一种确定被动IAST测试API覆盖率的方法及装置。其中，在上述方案中，主要包括：通过采集获取目标Web应用程序中的全量API信息，并在测试过程中通过插桩获取测试请求访问过的URL路径信息，记录所述URL路径对应的API的执行情况，以及根据记录的至少被执行一次的API数与采集获取的全量API的总数，确定所述测试的API覆盖率。相较于现有技术，上述方案显然开销更小，受人为因素影响小，结果更为准确，而且能够在不掌握全量代码的情形下仍能够得到所述API覆盖率。

Description

一种确定被动IAST测试API覆盖率的方法及装置

技术领域

本申请公开的实施例主要涉及Web应用程序安全测试相关的技术领域，且更具体地，涉及一种确定被动IAST测试API覆盖率的方法及装置。

背景技术

Web应用程序通常采用主从式架构。而主从式架构的Web应用程序又被视为前端（一般地，是指浏览器、客户端程序上运行的部分或客户端程序本身）和后端（一般地，是指服务器端运行的部分）两部分。得益于前端技术的发展，前后端分离已经成为行业内开展互联网项目、开发相关Web应用程序的标配模式。通过前、后端的有效解耦，实现前后端分离，前端开始更加注重页面开发的工程化、自动化，后端则更专注于API（这里的API，主要是指前后端分离模式下一种非常重要的后端路由实现方式）的提供和数据库的保障。因此，在针对Web应用程序的测试中，往往将API覆盖率作为衡量相关软件测试完整性的重要指标。

虽然，也有人提出利用代码覆盖率工具通过执行测试用例、收集程序执行轨迹信息以及进而结合代码结构信息分析的方式统计整个软件测试全过程的API覆盖率；然而，如此不免要尽可能地掌握全量代码，同时更是大费周章，却往往有因对代码结构信息分析不到位造成API覆盖率统计失准。

此外，还需要指出的是，统计API覆盖率虽然看上去似乎是存在一种捷径，即掌握已执行API和全量API，即可计算出统计API覆盖率；但是，事实上是，除了随着Web应用程序的规模越来越大、越来越依赖第三方开源组件等因素几乎很难获得目标Web应用程序的全量API信息外，在例如被动IAST测试等一些测试中，由于其与自动化功能测试并行，在发出攻击报文的测试端并不统计请求访问的API信息，故连已执行API信息的获取都是统计API覆盖率时要解决的技术问题。

发明内容

根据本申请公开的实施例，提供了一种针对例如被动IAST测试等的Web应用程序安全测试统计其API覆盖率的方案。

在本公开的第一方面中，提供了一种确定被动IAST测试API覆盖率的方法。该方法包括：获取目标Web应用程序中的全量API信息，使所述API信息包括所述API对应的URL路径信息；并在所述测试过程中，通过预先插桩的第一探针获取其中测试请求访问过的URL路径信息，记录所述URL路径对应的API的执行情况；以及根据记录的至少被执行一次的API数与所述的全量API的总数，确定所述测试的API测试覆盖率。

在本公开的第二方面中，提供了一种确定被动IAST测试API覆盖率的装置。该装置包括：采集模块、测试记录模块和计算模块；其中，采集模块，被配置为用于采集目标Web应用程序中的全量API信息；测试记录模块，被配置为在测试过程中通过预先插桩的第一探针获取其中测试请求访问过的URL路径信息，记录所述URL路径对应的API的执行情况；计算模块，被配置为根据测试记录模块记录的至少被执行一次的API数与采集模块采集的所述全量API的总数，计算所述测试的API测试覆盖率。

在本公开的第三方面中，提供了一种基于插桩的Web后端API获取装置。该装置包括：至少一个处理器，和至少一个处理器耦合的存储器，以及存储在存储器中的计算机程序；其中的处理器执行所述计算机程序，能够实现第一方面述及的方法。

在本公开的第四方面中，提供了一种计算机可读存储介质。该介质上存储有测试相关的计算机指令，该计算机指令在被计算机处理器执行时能够实现第一方面述及的方法。

在本公开的第五方面中，提供了一种计算机程序产品。该程序产品包括计算机程序，该计算机程序在被计算机处理器执行时能够实现第一方面述及的方法。

应当理解，发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征，亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。

附图说明

结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标注表示相同或相似的元素，其中：

图1示出了现有技术中主从式架构Web应用程序中基于所述API技术提供的后端路由的过程的示意图；

图2示出了根据本公开的实施例的确定被动IAST测试API覆盖率的过程的示意图；

图3示出了现有技术中Web应用程序中后端路由的具体实现过程以及据此在上述实施例中的一些的有效获取目标Web应用程序中的全量API信息的一种实现方式；其中，图3中a示出了请求进入应用程序中的后端路由的具体实现过程的示意图；图3中b示出了上述实施例中的一些的有效获取目标Web应用程序中的全量API信息的过程的示意图；

图4示出了根据本公开内容示例性实现的一种用于确定被动IAST测试API覆盖率的装置的框图；

图5示出了根据本公开内容示例性实现的一种分布式的确定被动IAST测试API覆盖率的装置的框图；

图6示出了能够实施本公开的多个实施例的计算设备的框图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

在本公开的实施例的描述中术语“包括”及其类似用语应当理解为开放性包含，即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实施例”或“该实施例”应当理解为“至少一个实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。

在本公开的实施例的描述中技术术语“插桩”，又称“程序插桩”，是指在保证被测程序原有逻辑完整性的基础上在程序中插入“探针”，通过“探针”的执行获取程序的运行特征数据（即运行时数据）；通过对目标特征数据的分析，可以获得程序的控制流、数据流、逻辑覆盖等动态信息，实现相应的测试目的的技术手段。其中的“探针”，本质上是进行信息采集的代码片段。在本公开的实施例的“探针”除了用于获取请求数据和返回数据、获取代码执行中传递的数据、监听内存中特定的值、识别受污染的输入等外，还可以根据插桩点、测试目的、涉及需求等的不同，设计并实现具有相应自定义功能的“探针”。

在本公开的实施例的描述中技术术语“目标Web应用”，是指在被作为测试对象的Web应用，也即一些实施例中的待发现其全量对外API信息的目标对象，和一些实施例中以其为测试对象进行测试、并待确定其在该测试中测试覆盖率的对象。在本公开的实施例的描述中技术术语“目标Web应用程序”，主要是指Web后端应用程序，即如无特殊说明，“目标Web应用程序”具体是指对外提供所述API的Web后端应用程序。

信息化时代，人们的生产生活活动越来越离不开软件技术的支持。然而，软件技术在促进人类社会发展的同时，程序漏洞等信息安全问题也越来越危害到人们的个人隐私信息、财产安全甚至生命安全。于是，为确保Web应用程序在交付前后的安全性，就需要行业内在这些漏洞、缺陷被黑客找到前，运用Web应用安全测试技术发现它们。IAST（交互式应用程序安全测试），是一种新型应用程序安全测试方案；较之传统的SAST、DAST技术，IAST技术能够高效、准确地识别安全缺陷及漏洞，甚至可以准确确定漏洞所在的代码文件、行数、函数及参数。其中的被动IAST测试技术更是仅通过被动插桩在运行时监视应用并分析代码，其不会主动对Web应用程序执行攻击，而是纯粹被动地分析检测代码，而被行业内认为是最有实用意义的IAST技术。然而，由于是被动监视目标Web应用程序，在测试过程中，测试人员一般只能够掌握到表象的测试用例执行情况，而不能实质性地了解到测试过程中包括API覆盖等在内的目标对象内部运行相关的表征测试的参数。其中，例如，API覆盖率，就是评估测试完整性时最有价值的指标之一。

关于所述API，其是指在主从式架构的Web应用程序中，后端以之提供后端路由功能而对前端暴露的一类接口。图1示出了基于所述API请求发出和进入应用程序后经后端路由、被实际处理的过程100的示意图。如图1所示，过程100包括：请求发出并经Web服务器进入应用程序后，经路由系统110将其映射到相应的实际处理程序120，进而得到实际处理。因此，在测试过程中，API提供的后端路由的执行情况，无疑实质性地反映着测试最具实质意义的覆盖程度。而在一些现有技术中，有人提出利用代码覆盖率工具通过执行测试用例、收集程序执行轨迹信息以及进而结合代码结构信息分析的方式统计整个软件测试全过程的API覆盖率；然而，Web应用程序的规模越来越大、越来越依赖第三方开源组件，无论是是否能够获取到全量代码的决定性阻碍、还是测试过程中需要遍历全量代码的庞大开销问题，亦或是因对代码结构信息分析不足导致最终API覆盖率统计误差（而说到对代码结构进行分析，一般需要资深开发人员；对于大规模软件项目，往往更是需要连续参与甚至是主导项目的开发人员），上述方案都非优选。

根据本公开的实施例，提供了一种确定被动IAST测试API覆盖率的方案。在该方案中，通过采集获取目标Web应用程序中的全量API信息，并在测试过程中通过插桩获取测试请求访问过的URL路径信息，记录所述URL路径对应的API的执行情况，以及根据记录的至少被执行一次的API数与采集获取的全量API的总数，确定所述测试的API覆盖率。相较于现有技术，上述方案显然开销更小，受人为因素影响小，结果更为准确，而且能够在不掌握全量代码的情形下仍能够得到所述API覆盖率。

下文将参考图2至图6来详细地描述上述方案中确定被动IAST测试API覆盖率的过程。图2示出了根据本公开的一些实施例的确定被动IAST测试API覆盖率的过程的示意图。如图2所示，确定被动IAST测试API覆盖率的过程200，主要包括：首先，通过读取输入配置或实时获取等方式，获取目标Web应用程序中的全量API信息，其中，使所述API信息包括所述API对应的URL路径信息（参考框201）；并且在需要确定API覆盖率的测试的进行过程中，通过预先插桩第一探针，和通过其获取其中测试请求访问过的URL路径信息，记录所述URL路径对应的API的执行情况（参考框202）；进而，根据记录的至少被执行一次的API数与所述的全量API的总数，确定所述测试的API测试覆盖率（参考框203）。

在一些实施例中，参考框202，在例如被动IAST测试等的Web应用程序安全测试过程中，所述第一探针，可以是复用所述被动IAST测试中的探针，利用其获取所述测试请求对应的URL路径信息。具体地，其实现过程可以是，包括：配置得使所述被动IAST测试中的探针在执行获取运行时数据等功能的同时，也能够获取其中测试请求访问过的URL路径信息，记录所述URL路径对应的API的执行情况。其中，上述实施例中选择的所述被动IAST测试中探针，优选可以是其中用于解析测试请求探针，也可以是被动IAST测试过程中其他位点插桩的探针。

在一些实施例中，参考框201，可以是采用插桩方式获取目标Web应用程序的全量API信息。图3中a示出了上述实施例中请求进入应用程序中的后端路由的具体实现过程的示意图。如图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）。

在一些实施例中，可以是采用运行时插桩的方式，插桩所述探针。所述运行时插桩方式，是指在目标程序运行时对目标插桩位点插桩探针。具体地，可以是，在目标Web应用程序启动过程中，对目标插桩位点插桩所述第一探针、第二探针以及IAST测试过程中的其他探针。例如，对于Java编程的目标Web应用程序，可以在其类加载时，通过如手动、字节码插桩工具修改等方式对目标插桩点插桩所述探针。

在一些实施例中，在相关测试过程中，可以是：使所述第一探针实时获取其中测试请求访问过的URL路径信息，记录所述URL路径对应的API的实时执行情况；进而，根据上述实时记录的至少被执行一次的API数与所述的全量API的总数，确定所述测试的实时的API测试覆盖率。

图4示出了根据本公开的实施例的一种用于确定被动IAST测试API覆盖率的装置400的框图。如图4所示，装置400包括：采集模块410、测试记录模块420和计算模块430；其中，采集模块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路径信息。具体地，可以是，配置得使所述被动IAST测试中的探针在执行获取运行时数据等功能的同时，也能够获取其中测试请求访问过的URL路径信息，记录所述URL路径对应的API的执行情况。其中，上述实施例中选择的所述被动IAST测试中探针，优选可以是其中用于解析测试请求探针，也可以是被动IAST测试过程中其他位点插桩的探针。

在一些实施例中，采集模块，可以是：被配置为采用插桩方式获取目标Web应用程序的全量API信息；具体地，可以是，被配置为在目标Web应用程序的路由注册函数中插桩第二探针，并配置得使所述第二探针在路由规则注册到路由系统的过程中/路由规则注册到路由系统后，获取对应的URL路径与实际处理程序的映射集合、并根据所述映射集合中的每条URL路径与实际处理程序的映射关系信息，获取所述全量API信息。

在一些实施例中，所述探针，可以是采用运行时插桩的。所述运行时插桩，是指在目标程序运行时对目标插桩位点插桩探针。具体地，可以是，在目标Web应用程序启动过程中，对目标插桩位点插桩所述第一探针、第二探针以及IAST测试过程中的其他探针。例如，对于Java编程的目标Web应用程序，可以在其类加载时，通过如手动、字节码插桩工具修改等方式对目标插桩点插桩所述探针。

在一些实施例中，测试记录模块，可以是：被配置为在相关测试过程中使所述第一探针实时获取其中测试请求访问过的URL路径信息，记录所述URL路径对应的API的实时执行情况；进而可以使计算模块根据上述实时记录的至少被执行一次的API数与所述的全量API的总数，计算实时的API测试覆盖率。

根据本公开的一些实施例，还提出了一种装置，用于确定被动IAST测试的API覆盖率。所述装置，具体地，可以是一种计算设备；图6则示出了上述实施例的可以用来实施本公开的一些实施例的计算设备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的部分或者全部操作。

本文中以上描述的功能都可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：场可编程门阵列（FPGA）、专用集成电路（ASIC）、专用标准产品（ASSP）、芯片上系统的系统（SOC）、负载可编程逻辑设备（CPLD）等等。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦除可编程只读存储器（EPROM或快闪存储器）、光纤、便捷式紧凑盘只读存储器（CD-ROM）、光学储存设备、磁储存设备、或上述内容的任何合适组合。

此外，虽然采用特定次序描绘了各操作，但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行，或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以独立地或以任何合适的子组合的方式实现在多个实现中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

Claims (8)

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任一所述的方法。

Images