CN113886837A - 一种漏洞检测工具可信度验证方法和系统 - Google Patents

Abstract

本发明涉及一种漏洞检测工具可信度验证方法和系统，所述方法包括：基于测试端浏览器向测试目标发送功能点测试请求；手动检测工具截获所述测试请求的数据包，并由安全工程师根据漏洞检测策略手动检测以获得对应功能点的第一检测结果；自动检测工具获取所述测试请求的镜像数据包，根据预置检测策略对镜像数据包对应的功能点进行漏洞检测以获得第二检测结果；对比所述第一检测结果和所述第二检测结果；以及根据对比结果确定所述自动检测工具对所述功能点漏洞检测的可信度。本发明基于手动检测结果对自动漏洞检测工具进行验证，只需要安全工程师在必要时给予确认，不需要过多的人工参与，人为因素影响小、验证效率高。

Description

一种漏洞检测工具可信度验证方法和系统

技术领域

本发明涉及网络安全技术领域，特别地涉及一种漏洞检测工具可信度验证方法和系统。

背景技术

在信息时代，网络信息安全始终是企业和个人关心的头等大事。无论是硬件、软件还是协议，当其存在缺陷或系统安全策略不足时，则形成漏洞，攻击者利用漏洞在未经授权时即可访问或破坏系统，导致信息系统受到木马、蠕虫病毒的攻击或控制、数据泄露、数据被篡改、删除等等，从而给个人和企业带来不可估量的损失，尤其是一些互联网企业，为了保证线上业务的正常运行，保护用户信息的安全，通常配有安全工程师对线上业务进行漏洞的安全检测，以发现漏洞，并及时通知相关部门进行修复。目前，大部分的安全工程师采用风险扫描器，基于安全测试项目文档进行人工测试。但是这种安全检测模式面临以下问题：

第一、人为因素影响大。由于安全工程师的工作状态、安全知识储备、对于测试项目的理解等因素，无法保证安全测试策略得到很好地执行以及待检测业务功能的全量覆盖。另外，不同业务可能采用不同开发框架，如原生PHP模式、基于MVC框架的自编写模式、第三方框架模式等等，不同开发框架具有不同的测试策略，因而需要安全工程师针对项目的开发框架加载对应的测试策略，但是在实际操作过程中，安全工程师不一定会对此进行关注，导致安全测试策略加载错误进行无效检测。

第二、检测工具的效能有待提高。目前安全测试流程中常用的自动化应用风险扫描器如Appscan、绿盟极光等仅能覆盖一些简单的基于请求响应模型的安全风险，无法覆盖权限类安全漏洞及需要交互如存储型XSS类型的安全漏洞。

第三、漏检。虽然传统自动化扫描器爬虫能获取大部分的业务功能点，但无法获取高交互的业务功能点，无法有效解决业务功能漏检情况。

第四、安全测试经验和测试策略不能共享。安全工程师对于历史项目的测试经验和测试策略仅能通过自行记录的方式复用于同项目的下一次测试，无法实现不同工程师间的分享，并且无法得知是否出现漏检的情况，最终会导致测试周期长且结果不可信。

第四、测试环境受限。由于甲方安全测试通常在测试环境的服务器进行，此类测试服务器性能较差，仅能支持少量并发的测试请求，但市场中主流扫描器都是基于海量的攻击模拟请求进行，慢速进行的话，无法在有限的测试周期完成。

综上所述，现有的漏洞检测模式、方法及系统还有很多可以提升的空间。

发明内容

针对现有技术中存在的技术问题，本发明提出了一种漏洞检测工具可信度验证方法和系统，用以在进行漏洞检测时检验检测工具的可信度，以提高漏洞检测结果的可信度。

为了解决上述的技术问题，根据本发明的一个方面，本发明提供了一种漏洞检测工具可信度验证方法，其包括：基于测试端浏览器向测试目标发送功能点测试请求；手动检测工具截获所述测试请求的数据包，并由安全工程师根据漏洞检测策略手动检测以获得对应功能点的第一检测结果；自动检测工具获取所述测试请求的镜像数据包，根据预置检测策略对镜像数据包对应的功能点进行漏洞检测以获得第二检测结果；对比所述第一检测结果和所述第二检测结果；以及根据对比结果确定所述自动检测工具对所述功能点漏洞检测的可信度。

为了解决上述的技术问题，根据本发明的另一个方面，本发明提供了一种漏洞检测工具可信度验证系统，其包括测试端浏览器、手动检测工具、自动检测工具和可信度验证模块，其中，所述测试端浏览器，经配置以通过预置的代理端口向测试目标发送功能点测试请求，并接收从测试目标返回的响应数据包；所述手动检测工具经配置以截取向测试目标发出的测试请求数据包，提供手动检测界面供安全工程师手动检测，并获取第一检测结果；所述自动检测工具经配置以获取经所述代理端口发出的来自于测试端浏览器的功能点测试请求的镜像数据包，根据预置检测策略对镜像数据包对应的功能点进行漏洞检测以获得第二检测结果；所述可信度验证模块与所述手动检测工具和自动检测工具相连接，经配置以所述第一检测结果和所述第二检测结果；根据对比结果确定所述自动检测工具的可信度。

本发明基于手动检测结果对自动漏洞检测工具进行验证，以确认所述自动漏洞检测工具在进行自动检测时是否能够准确地检测出漏洞风险，并基于验证数据自动更新自动漏洞检测工具，确保自动检测工具对漏洞检测的准确性。验证过程只需要安全工程师在必要时给予确认，不需要过多的人工参与，因而人为因素影响小；并且可以在检测过程中实时进行验证，在检测完成时即可以得到验证结果，验证效率高。

附图说明

下面，将结合附图对本发明的优选实施方式进行进一步详细的说明，其中：

图1是根据本发明的一个实施例提供的漏洞检测系统原理框图；

图2是根据本发明的一个实施例提供的项目检测管理模块原理框图；

图3是根据本发明的一个实施例提供的漏洞检测方法流程图；

图4是根据本发明的一个实施例提供的自动检测工具的原理框图；

图5是根据本发明的一个实施例提供的数据包分析模块的原理框图；

图6是根据本发明的一个实施例提供的检测模块的原理框图；

图7是根据本发明的一个实施例提供的对一个功能点进行检测的流程图；

图8是根据本发明的一个实施例提供的对一个初始化漏洞进行检测的流程图；

图9是根据本发明的一个实施例提供的对运行态漏洞组的一个漏洞的检测流程图；

图10是根据本发明的一个实施例提供的检测模型单元的原理框图；

图11是根据本发明的一个实施例提供的自动检测工具可信度验证方法流程图；

图12是根据本发明的一个实施例在一个功能点进行某个漏洞检测过程中进行验证方法流程图；

图13是根据本发明的一个实施例提供的自动检测工具可信度验证系统原理框图；以及

图14是根据本发明的一个实施例提供的可信度验证模块原理框图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在以下的详细描述中，可以参看作为本申请一部分用来说明本申请的特定实施例的各个说明书附图。在附图中，相似的附图标记在不同图式中描述大体上类似的组件。本申请的各个特定实施例在以下进行了足够详细的描述，使得具备本领域相关知识和技术的普通技术人员能够实施本申请的技术方案。应当理解，还可以利用其它实施例或者对本申请的实施例进行结构、逻辑或者电性的改变。

图1是根据本发明的一个实施例提供的漏洞检测系统原理框图。参考图1，所述漏洞检测系统包括测试端浏览器1、可选的手动检测工具2、自动检测工具3和项目检测管理模块4，其中，所述项目检测管理模块4与所述测试端浏览器1、手动检测工具2和自动检测工具3相连接。所述测试端浏览器1为安全工程师使用的浏览器，通过在安全工程师使用的电脑上配置浏览器代理服务器设置指定的代理端口P，则所述测试端浏览器1连接所述代理端口P。如在一个实施例中，通过FoxyProxy选择代理扫描，并指定代理IP地址，在此配置下，通过所述测试端浏览器1发送的测试请求可由自动检测工具3截取。手动检测工具2为可选的一个现有手动漏洞检测装置，当需要使用手动检测工具2时，通过FoxyProxy选择安全工程师电脑上配置的手动检测工具bump，而后在手动检测工具bump提供的操作界面中设置代理服务器。在此配置下，所述测试端浏览器1发送测试请求时，手动检测工具bump截取所述测试请求的数据包通过操作界面提供给安全工程师，安全工程师手工对该测试请求的数据包进行篡改、人工查看返回的结果并人工判断是否存在漏洞风险。。

如图2所示，所述项目检测管理模块4包括管理界面41、功能列表生成单元42和监测单元43，所述管理界面41用以提供安全检测参数项的设置、检测过程及结果数据及通知的显示。其中，通过管理界面41可以设置或选择测试项目名，如xxx业务，并在该业务下可以包含多个测试的业务线，设置或选择业务线名称；设置或选择测试项目域名，如xxx.yy.com，用以限定测试项目涉及的域名，非项目相关域名不进行测试，避免额外性能开销；设置或选择测试端IP地址，如10.100.x.x，用以限定进行漏洞检测的安全工程师的PC的IP地址，从而指定了测试端浏览器1，可以限制使用本系统的来源，避免系统被滥用。其中还包括进行自动检测时的一些参数，例如请求并发数、排除文件类型、排除域名列表、用于识别业务功能的各种关键词、权限认证模式的相关配置及关于测试目标的相关参数，如开发框架、开发语言，对应的解析逻辑等等，还有自动检测时使用的检测策略，其中涉及包括各种参数、测试请求构造方法、校验条件、校验/检测流程等等。其中，为了减少测试用例，减轻对测试环境的测试压力，本发明将页面错误回显状态设置为“是”，以便在对如任意文件下载漏洞、显错型SQL注入漏洞等漏洞的检测过程中，在从测试目标返回的响应中能够包含错误回显内容，便于使用较少的测试用例即可得到检测结果。管理界面41中还提供验证指标及其参考数据的设置，例如验证指标例如功能点数量、漏洞校验类型及其检测策略、每种漏洞校验类型的漏洞数量、检测策略的一致性、同一漏洞的检测风险的一致性等等。管理界面41还包括各种数据的显示区域，例如检测结果显示区域，用于显示各种漏洞的检测过程数据和结果数据，如得到的漏洞风险名称、风险等级、风险参数、对应的功能路径等等，并包括对应的详细信息，如原始请求头信息、扫描信息等。

功能列表生成单元42与管理界面41相连接，根据管理界面41配置的关于测试目标的参数及测试目标的源代码生成待测功能点列表，所述功能点列表包括URL(UniformResource Locator，统一资源定位器)列表字段，其中包括需要测试的各个功能点的URL。所述功能点列表可显示在管理界面相应显示区域中。

监测单元43根据监测指标监测检测过程，并根据监测结果生成相应的监测通知以显示在所述管理界面41上。例如在接收到检测结束指令时查询功能点列表是否完全检测完成，功能点列表中还有未完成的功能点时，发出继续检测提醒通知，显示在管理界面41上以提醒安全工程师还有未完成检测的功能点，直到功能点列表中的功能点全部检测完成才允许漏洞检测结束。又例如，功能点列表中还包括URL标识字段，在URL标识字段中包括有多种功能标识，以表示当前功能点的业务功能。监测单元43监测功能点的URL标识字段，在接收到检测结束指令时，当监测到功能点的URL标识字段中某个标识内容未标记时，发出标记提醒通知显示在管理界面41上以提醒安全工程师对所述功能点的标识字段的标识内容进行标识，直到功能点列表中的功能点URL标识字段的标识内容全部标识完成才允许漏洞检测结束。

图3是根据本发明的一个实施例提供的漏洞检测方法流程图，安全工程师执行漏洞检测的方法流程包括以下步骤：

步骤S1，安全工程师通过所述项目检测管理模块4的管理界面41进行相应的配置或选择。其中，在测试目标不是第一次检测时，管理界面已经存储了上次检测时进行的配置，通过在项目名参数项中选择对应的名称，即可以得到上次测试时的所有配置。安全工程师可以直接使用上次的配置，也可以根据自身经验对上次配置进行改进。因而，本发明可以将检测经验和测试策略在安全工程师之间共享，并可以在前人的经验基础上进行改进，从而使得测试策略得到进一步改进，进而提高测试效果，增加测试的可信度，减小测试周期长。

步骤S2，项目检测管理模块4的的功能列表生成单元42根据管理界面41配置的关于测试目标的参数及测试目标的源代码生成由功能点列表。在一个实施例中，所述功能点列表包括URL列表字段、URL标识字段、功能点身份标识字段、检测状态字段等等。其中，所述URL列表字段记录有与功能点对应的URL，其中的URL包括了参数及参数值。URL标识字段包括有多种用于表明业务功能的标识内容，如账户权限、信息存储、上传功能、敏感功能和用户私有功能等中的一种或多种，应将其标记为“是(Y)”或“否(N)”的状态。功能点身份标识字段在一个实施例中可以为基于URL和参数计算的哈希值，其为该功能点的身份的唯一标识。检测状态字段可以由数字代表该功能点处于未检测的初始化状态、通过检测、检测有风险、已检测但检测失败等等不同的状态。具体地，功能列表生成单元42根据管理界面41中对测试项目的配置获取到测试项目的名称、开发语言及框架，选取对应的解析逻辑，再从源代码管理库中读取所述测试项目的源代码，根据解析逻辑对源代码进行解析得到需要检测的功能点，从而生成功能点列表。其中，不同的开发语言及框架对应不同的解析逻辑。所述的开发语言例如为PHP、JAVA、.NET、ASP、Ruby、Python、Vue等等，所述的开发框架例如为基于MVC的开源框架或自定义框架、基于三层架构的自定义框架或其它的一些框架。以PHP作为开发语言、以基于MVC的开源框架为例，简要说明生成功能点列表的过程：首先通过Web容器配置获取Web目录及起始文件；然后解析起始文件index.php，通过正则匹配找到应用目标及名称，输出所述应用目录；再根据所述应用目录得到控制器(Controller)路径；获取所述控制器(Controller)路径所有文件列表；而后解析所述文件列表中的文件，得到文件中的控制器名及控制器中的方法名，并去除private、_initialize、protected等私有化方法；最后采用正则表达式匹配获取用户输入参数名；最终输出功能列表、参数、类型、作为功点身份标识的唯一hash值。所述hash值为基于URL和参数计算的哈希值。

步骤S3，安全工程师通过测试端浏览器P发出对应测试目标功能点的测试请求数据包。所述安全工程师可以通过点击功能点列表中的URL发出测试请求数据包，也可以在手动检测工具中通过测试端浏览器P选择相应的功能点，并根据需要增加或替换测试用例从而构造测试请求数据包，再经过测试端浏览器P发出。

步骤S4，测试端浏览器1发出的测试请求数据包经过代理端口P发送给测试目标T，接收测试目标T返回的响应数据包。

一方面，在步骤S51，根据需要，安全工程师通过手动检测工具2基于安全测试项目文档进行人工检测、判断、确定是否存在风险，并记录检测结果，称为第一检测结果。需要说明的是，本步骤并不是每个功能点检测时都必须要做的，当安全工程师对自动检测结果存在疑虑时，可以执行本步骤中的人工检测，对自动检测结果进行校验。

另一方面，在步骤S52，与代理端口连接的自动检测工具3获取来自于测试端浏览器的测试请求镜像数据包，根据预置检测策略进行漏洞检测，并记录检测结果，称为第二检测结果。

步骤S6，安全工程师判断是否还有未进行检测的功能点，如果安全工程师认为所有功能点已全部检测完成而决定结束检测，则在步骤S7发出检测结束指令，如在管理界面41上点击结束按钮。如果安全工程师认为还有功能点没有检测，则返回步骤S3，重新针对新的功能点发出测试请求数据包。

监测单元43在接收到检测结束指令时，同时执行步骤S81和S91，或者顺序执行步骤S81、S91或顺序执行步骤S91、S81。

步骤S81，查询所述功能点列表的检测完成进度。例如查看每一个功能点的检测状态字段。

步骤S82，判断功能点列表中的功能点是否全部检测完成。其中，可以通过查看每个功能点的检测状态字段来确定是已完成检测，如果检测状态字段中的数字为代表初始化状态时，则说明所述功能点没有被检测，则在步骤S83发出继续检测提醒通知，并显示在管理界面41上；如果功能点列表中的功能点已全部检测完，则结束检测。当安全工程师发现其按下结束按钮时检测并没有结束，并且出现要求其继续检测的通知时，根据通知中的未检测的功能点，执行步骤S3完成对应的检测。从而可以避免由于人为原因漏检。

步骤S91，监测对应于每一个功能点的URL标识字段。在一个实施例中，每一个功能点URL标识字段包括账户权限、信息存储、上传功能、敏感功能和用户私有功能等URL标识内容，用以表明所述功能点的业务功能，对应每个URL标识内容包括有“是”和“否”两种状态，每个功能点或者标记为“是”，或者标记为“否”。通过查询每个功能点的每种URL标识内容是否已经标识了“是”或“否”可以监测到功能点是否完成业务功能的识别。

步骤S92，判断每一个功能点的URL标识字段是否标记，如果功能点列表中某个或某些功能点的URL标识字段未标记，则在步骤S93发出标记提醒通知，并显示在管理界面41上。如果每一个功能点的URL标识字段都已经标记，则结束检测流程。当安全工程师发现其按下结束按钮时检测并没有结束，并且出现要求其标记URL标识字段的通知时，根据通知中指示的功能点，在步骤S94在功能点列表中对所述功能点的URL标识字段进行标识。然后再执行步骤S92。其中，在一些实施例中，需要安全工程师标识的URL标识字段的标识内容包括敏感功能和帐户功能。在这些实施例中，通过安全工程师的人为判断为功能列表中的每一个功能点进行标识。

本发明通过对测试目标源代码的解析可以得到功能点列表，并且只有在功能点列表中的全部功能点检测完成才可以结束检测，从而实现了业务功能点的全量覆盖。每次检测完成后所有的配置均存储在相应参数项中，可以对安全工程师的研究成果和经验进行积累，并分享给其他安全工程师。本发明能够收集测试项目历史信息，为后续安全测试提供依据。对于一个测试项目，对功能点进行了功能标识之后，该标识则存储在标识字段中，在第一次测试时经过工程师的标识、复核后，不再需要工程师标识，为后续的检测简化了流程，并减少了对工程师的依赖，使系统可以自动、准确地执行自动检测。

图4是根据本发明一个实施例的自动检测工具的原理框图，其中，所述自动检测工具包括数据包获取模块31、数据包分析模块32和检测模块33，其中，所述数据包获取模块31与代理端口P连接，从预置的代理端口P获取测试端浏览器1发送给测试目标T的对应功能点的镜像数据包，并向测试目标T发送自动检测工具构造的自动测试请求数据包，并接收测试目标T返回的响应数据包。数据包分析模块32与所述数据包获取模块31相连接，用以对镜像数据包和响应数据包进行解析，从所述镜像数据包中至少获取去除参数的URL、参数及参数值、功能点身份标识及功能点检测标识；从所述响应数据包中至少获取响应内容。其中，如图5所示，所述数据包分析模块32包括请求包解析单元321、响应包解析单元322、标记单元323、哈希值计算单元324和清洗单元325。

其中，所述请求包解析单元321用以解析镜像数据包的请求头(Header)、请求参数和用户凭证。其中，通过解析镜像数据包的请求头(Header)可以得到请求头中的参数，如Cookie，x-forward，refer和user-agent等参数。首先根据管理界面41中的相应配置校验参数名，然后剔除不需要检测的参数，而后判断余下的参数中是否有Cookie字段，如果有，则剔除Cookie，此时得到请求头参数，并通知标记单元323在功能点列表中相应功能点的URL标识字段中标记“发现认证标识”；如果参数中没有Cookie参数，则通知标记单元323在功能点列表中相应功能点的URL标识字段中标记为“未发现认证标识”。在解析请求参数时，首先根据请求类型，如GET请求类型或POST请求类型，进行相应的URL解析，从中获得GET参数或POST参数。所述清洗单元325与所述请求包解析单元321相连接，判断参数值中是否包括了测试用例，如果包括了测试用例，将其删除，从而得到去除了参数的URL、参数及相应的参数值。在解析用户凭证时，首先读取管理界面41中配置的权限认证模式，如Cookie模式或API模式，并读取配置中的认证标识关键词，如sign，token或key等。如果所述镜像数据包中的认证模式是Cookie模式，则解析Cookie字段，获取参数名，如username、ci_session。其中ci_session为认证凭证参数，其篡改后会无法访问，所以需要进行权限类检测，因而需要在URL标识字段中标记“发现认证标识”，此时，去掉认证凭证，从而得到去掉固定值的请求参数。如果所述镜像数据包中的认证模式是API模式时，查询参数名是否与管理界面中配置的认证关键词相匹配，如果匹配，则将所述认证关键词剔除，并通知标记单元323在功能点列表中相应功能点的URL标识字段中标记“发现认证标识”。如果参数名与管理界面中配置的认证关键词不匹配，则通知标记单元323在功能点列表中相应功能点的URL标识字段中标记“未发现认证标识”。经过所述请求包解析单元321的解析得到去除参数的URL、参数及参数值。

响应包解析单元322从响应包中得到响应状态码，如表示成功、重定向、客户端错误或服务端误的代码，经过头解析可以得到响应包长度、响应包内容等信息。

标记单元323与所述请求包解析单元321相连接，在所述请求包解析单元321的解析完成后，读取解析得到参数及参数值，并根据管理界面41已配置的参数确定所述功能点的业务功能是否为上传功能、是否属于私有功能。并根据确定的结果标记所述功能点URL标识字段的上传功能和用户私有功能为“是”或“否”。更进一步地，在标记单元323根据所述请求包解析单元321的通知标记“发现认证标识”时，发送确认通知到管理界面41，提醒安全工程师根据所述标记对该功能点的URL标识字段中的“帐户权限”进行标识。另外，所述标记单元323在检测过程中，当需要开源的爬虫引擎进行功能点爬取时，如果能够爬取到功能点，则点该功能点URL标识字段的“账户权限”标记为“否”。例如，A账户用户可以访问自己私有功能URL和公用的首页上的功能URL；当使用NoAuth(未登录用户)账户访问A账户的私有功能URL和公用的首页功能时，结果应该是对A账户私有的功能URL访问失败，公用的首页功能URL访问成功。因而在检测过程中如果发现使用A账号和NoAuth账号都能访问一个功能点URL时，是有可能存在权限类风险的，为了校验此类权限类风险，检测模块开启爬虫引擎使用NoAuth(未登录用户)账户或General Auth(普通用户)抓取功能链接，如果能够抓取到功能链接，说明该功能点不具有权限功能，所述功能点可能是前述的公用首页功能，因而通知所述标记单元323将此功能点URL标识字段的“账户权限”标记为“否”。

哈希值计算单元324与所述请求包解析单元321相连接，根据去除参数的URL和参数计算第一哈希值，根据去除参数的URL、参数及参数值计算第二哈希值。第一哈希值作为功能点的身份标识，第二哈希值作为功能点检测标识。

检测模块33与所述数据包分析模块32相连接，根据预置检测策略基于所述镜像数据包及其解析结果进行漏洞检测。在本发明中，根据漏洞的校验类型将需要检测的多种漏洞进行分组，为不同校验类型的漏洞组设置相应的检测流程。并且由相应的检测模型单元来执行对应校验类型的检测流程。如图6所示，检测模块33包括检测管理单元330和多个检测模型单元331、332、……33n,检测管理单元330根据检测流程控制多个检测模型单元有序地进行漏洞检测。例如，根据检测的运行状态，检测管理单元330将多个漏洞组分成初始化漏洞组和运行态漏洞组，并设置不同的检测策略。例如先对初始化漏洞组进行检测，然后再对运行态漏洞组进行检测。初始化漏洞组由一次请求完成检测，而对于运行态漏洞组，依据漏洞类型，实行粗粒度和细粒度相结合的检测策略，或者粗粒度和结果校验的检测策略。在进行粗粒度检测时，使用少量的测试用例，如1-5个，通过一次请求完成检测，在得到疑似风险后，再进行细粒度检测或根据漏洞类型进行校验。检测管理单元330还维护可以通过管理界面41显示的请求记录表，其中记录有漏洞检测详情，如原始测试请求数据包、URL、功能点身份标识、功能点检测状态标识、风险状态、风险类型、风险等级等等。每个检测模型单元用于完成一种校验类型的漏洞组的检测。检测管理单元330按照扫描策略协调多个检测模型单元对其校验类型的漏洞进行检测，每个检测模型单元根据检测管理单元的指令按照检测策略完成一个校验类型的漏洞组的检测。

如图7所示，为检测模块33对一个功能点进行检测的流程，其包括以下步骤：

步骤S1a，检测管理单元330接收来自于所述数据包分析模块32的所述镜像数据包及其解析结果。

步骤S2a，检测管理单元330将第一哈希值与功能点列表中的身份标识字段中的哈希值进行比较。

步骤S3a，判断作为功能点身份标识的第一哈希值是否在功能点列表中，如果没有，在步骤S4a将镜像数据包中的URL地址、参数等数据加入到功能点列表的相应字段中，从而可以弥补在生成功能点列表时漏掉的功能点；如果有，则执行步骤S5a。

步骤S5a，检测管理单元330在查询请求记录表中所述功能点检测标识字段。

步骤S6a，判断第二哈希值是否位于所述请求记录表中，即所述功能点检测标识字段中是否已包含了所述第二哈希值，如果第二哈希值位于所述功能点检测标识字段中，说明所述功能点已检测完成，此时不需要再进行检测，结束此功能点的检测，因而可以避免功能点的重复检测。如果没有，则执行步骤S7a。

步骤S7a，扫描初始化漏洞组进行初始化检测。检测管理单元330控制对应初始化漏洞组的检测模型单元依次根据漏洞类型进行漏洞检测。在一个实施例中，初始化漏洞组为初始化响应内容校验型，对应的检测模型单元331基于镜像数据包(即原始数据包)分别对初始化漏洞组所包含的漏洞类型发出一次测试请求则完成检测。对应的漏洞类型例如为服务器指纹泄露漏洞、HTTP请求模式漏洞和敏感信息明文传输漏洞。

以检测服务器指纹泄露漏洞为例，说明检测模型单元331的流程，如图8所示：

步骤S1b，检测模型单元331将镜像数据包放入请求队列。在实际检测过程中，可能会有多个功能点的镜像数据包需要进行初始化响应内容校验型的漏洞检测，因而这些功能点检测的镜像数据包放入请求队列中进行排队。

步骤S2b，判断所述镜像数据包是否达到请求队列的顶部，如果达到请求队列顶部，则在步骤S3b，将其通过数据包获取模块31发送给测试目标T；如果没有达到顶部，则等待。

步骤S4b，接收数据包分析模块32解析后得到响应包的响应内容。

步骤S5b，分析响应内容以确定是否具有风险。对应于服务器指纹泄露漏洞，通过正则表达式识别响应内容的参数值中是否包含数字，当响应内容的参数值中包含了数字时确定存在风险，例如：当响应内容中包含“X-Powered-By:PHP 5.2.5”时，其中包含了数字“5.2.5”这一具体版本，确认存在风险；当响应内容中没有包含数字时，如当响应内容为“X-Powered-By:PHP”时则确认无风险。

步骤S6b，将检测结果记录到请求记录表中。

步骤S8a，扫描运行态漏洞组依次进行漏洞检测。检测管理单元330控制多个检测模型单元依次完成相应漏洞的检测。其中运行态漏洞组的一个漏洞检测流程如图9所示：

步骤S1c，基于漏洞校验类型构造第一自动测试数据包，其中，对于响应内容校验型和请求重放校验型的漏洞，所述第一自动测试数据包为原始镜像数据包；对于请求响应校验型的漏洞，通过在原始镜像数据包的参数值中增加预置的测试用例而构成第一自动测试数据包；对于替换请求响应校验型的漏洞，通过将原始镜像数据包的参数值替换为预置的测试用例而构成第一自动测试数据包；对于登录凭证替换校验型的漏洞，通过将原始镜像数据包中的原来的用户认证凭证替换为预置的认证凭证而构成第一自动测试数据包。

步骤S2c，由相应的检测模型单元将第一自动测试数据包放入其内部的请求队列。

步骤S3c，判断所述第一自动测试数据包是否达到请求队列的顶部，如果达到请求队列顶部，则在步骤S4c，将其通过数据包获取模块31发送给测试目标T；如果没有达到顶部，则等待。

步骤S5c，接收数据包分析模块32解析后得到响应包的响应内容。

步骤S6c，分析响应内容。在分析响应内容时，根据所述漏洞所属的校验类型依据对应的策略进行分析。例如，对于请求响应校验型、替换请求响应校验型、响应内容校验型等漏洞，分析响应内容中是否包含检测策略中预置的内容；对于登录凭证替换校验型，对两次响应内容进行比较；对于请求重放校验型，将针对原始请求的响应和重放请求的响应进行比较。

步骤S7c，判断是否满足疑似风险的要求，如果不满足，说明没有风险，则在步骤S8c确认检测通过，并将检测结果记录到请求记录表中；如果满足，说明可能有风险，则执行为步骤S9c。例如，对于属于请求响应校验型的反射型跨站脚本风险，当响应内容中出现了原样回显，则认为满足疑似风险的要求，确认为疑似风险；对于属于登录凭证替换校验型的未授权访问漏洞，当两次响应内容高度相似，则认为满足疑似风险的要求，确认为疑似风险；对于属于请求重放校验型的跨站请求伪造漏洞，当两次请求响应完全一致，认为满足疑似风险的要求，确认为可能存在风险。

步骤S9c，获取具有所述疑似风险的漏洞的二次测试条件。所述二次测试条件根据漏洞类型的不同而不同，并记录在检测策略中，通过查询检测策略可以得到所述二次测试条件。例如，有些没有测试条件的限制，如属于请求响应校验型的反射型跨站脚本风险、属于响应校验测试的敏感信息泄露漏洞等；有些测试条件则规定了需要根据URL标记字段中相关标记内容的状态进行校验。

步骤S10c，依据对应的测试条件进行二次测试或校验。

步骤S11c，判断二次测试或校验的结构是否为风险，如果是，则在步骤S12c将请求记录表中的风险状态由“疑似”修改为“确认”，结束本次检测；如果经过二次测试或校验不是风险，则在步骤S13c将请求记录表中的风险状态由“疑似”修改为“误报”结束本次检测。

在步骤S10c中，针对不同的测试条件，其二次测试或校验的流程及判断的依据也不同。例如，对于属于请求响应校验型的反射型跨站脚本风险、属于响应校验测试的敏感信息泄露漏洞不需要任何的测试条件，则直接进行二次测试，如重新构造测试请求数据包，将其发送给测试目标，并分析返回的响应内容。根据是否满足风险的要求，将请求记录表中的风险状态“疑似”修改为“确认”或“误报”。

对于需要针对URL标识字段中的标识内容的标记状态进行校验的漏洞，例如在对未授权访问漏洞进行粗检测发现疑似风险时，查询所述功能点的URL标识字段中的标识内容“帐户权限”的标记为“是(Y)”还是“否(N)”，如果“帐户权限”的标记为“是(Y)”，则确认该漏洞类型的风险确实存在，将请求记录表中的风险状态由“疑似”修改为“确认”，如果“帐户权限”的标记为“否(N)”，则将风险状态由“疑似”修改为“误报”。又例如，在对水平越权漏洞进行检测出现疑似风险时，首先查询所述功能点的URL标识字段中的标识内容“帐户权限”的标记为“是(Y)”还是“否(N)”，如果“帐户权限”的标记为“否(N)”，则将风险状态由“疑似”修改为“误报”。如果“帐户权限”的标记为“是(Y)”，再查询“用户私有功能”的标记为“是(Y)”还是“否(N)”，如果是“否(N)”，则将风险状态由“疑似”修改为“误报”。如果是“是(Y)”，则确认该漏洞类型的风险确实存在，将请求记录表中的风险状态由“疑似”修改为“确认”。

对于在解析功能点确定所述功能点存在用户认证凭证、而该功能点的“帐户权限”还未被安全工程师进行标记时，开启爬虫引擎，使用NoAuth(未登录用户)账户或GeneralAuth(普通用户)抓取功能链接，如果能够抓取到功能链接，说明该功能点不具有权限功能，所述功能点可能是前述的公用首页功能，因而通知所述标记单元323将此功能点URL标识字段的“账户权限”标记为“否”。根据前述的校验流程，将“账户权限”标记为“否”的疑似风险排除。

其中，校验的时刻可以发生在检测过程中，也可以在检测过程完成、测试结束前。例如，对于“信息存储功能”的校验，在检测完成、安全工程师对所有URL功能进行标记后，如果对功能点的“信息存储功能”标记为“是”时，安全工程师需手动在表单项写入指定payload：sectxss'"<>。本系统自动重放所有信息存储功能标记为N的测试请求，并针对每一个测试请求的响应包进行校验。

在一个实施例中，如图10所示，一个检测模型单元331包括请求队列3311、发送子单元3312、接收子单元3313和校验子单元3314。所述请求队列3311用以存储向测试目标发送的测试请求数据包，其中，所述测试请求数据包为对初始化漏洞组中的漏洞进行检测时使用的镜像数据包，也可以为对运行状漏洞中的漏洞进行粗粒度检测时构造的测试请求数据包或用于细粒度检测的新的测试请求数据包。所述发送子单元3312按顺序从所述请求队列中取出测试请求数据包，经过数据包获取模块31通过代理端口发送给测试目标系统。所述接收子单元3313与数据包分析模块32连接，接收其对从测试目标返回的响应包解析后的响应内容。所述校验子单元3314内置有现其检测的校验类型对应的检测策略，并按照检测策略对返回的响应数据进行校验以确定是否存在相应漏洞的风险，并将校验结果发送给检测管理单元330。例如，对于请求响应校验型的反射型跨站脚本风险漏洞，在发送的测试请求数据包中包括4个测试用例，校验子单元3314校验响应内容中是否出现了原样回显，如果出现了原样回显，则确定为疑似风险。

在一些检测模型单元中，例如用于进行请求响应校验型、替换请求响应校验型和登录凭证替换校验型的漏洞组检测的检测模型单元，还包括测试请求构造子单元3310，其用于构造新的测试请求数据包。例如，用于对请求响应校验型漏洞组进行检测的检测模型单元中，测试请求构造子单元3310在镜像数据包的参数值中增加测试用例，将增加的测试用例与原有的参数值合并为攻击载荷，一起构成测试请求数据包。测试用例的数量可根据漏洞类型、粗粒度(level1)还是细粒度(level 2)而不同。例如，对于属于请求响应校验型的任意文件下载漏洞，在粗粒度检测中使用1个测试用例，细粒度检测中使用1个以上测试用例。对于属于请求响应校验型的反射型跨站脚本风险，在粗粒度检测中使用4个测试用例，细粒度检测中使用4个以上测试用例。对于属于替换请求响应校验型的任意文件上传漏洞，在粗粒度检测中使用3个测试用例。

在用于对替换请求响应校验型漏洞组进行检测的检测模型单元中，测试请求构造子单元3310将镜像数据包中的参数值替换为测试用例，从而够成测试请求数据包。当漏洞组的校验类型为登录凭证替换校验型时，3310将镜像数据包中的用户认证凭证分别替换为不同级别用户的认证凭证以构成多个所述自动测试请求数据包。例如，对于属于登录凭证替换校验型的未授权访问漏洞，分别用未登录用户帐户凭证和管理员等高级权限用户的认证凭证替换镜像数据包中的用户认证凭证以得到两个测试请求数据包。对应地，校验子单元3314比较这两个测试请求返回的响应内容，如果响应内容高度相似，则确定为疑似漏洞。

检测管理单元330接收检测模型单元331得到的校验结果，当检测管理单元330接收到检测模型单元发送来的校验结果为疑似风险时，根据漏洞类型确定是进行细粒度检测还是进行结果校验。例如，对于请求响应校验型漏洞组，如反射型跨站脚本风险、显错型SQL注入漏洞、任意文件下载漏洞等，在粗粒度检测结果为疑似风险时，重新利用一定量的测试用例构造测试请求数据包，进行细粒度的检测，如果按照检测策略仍然为风险，则可以将当前的疑似风险确认具有该漏洞。例如，对于任意文件下载漏洞、显错型SQL注入漏洞的疑似风险，当在细粒度(level 2)的检测过程中使用新的测试用例进行校验，如果两次请求响应内容不同则确认漏洞。又例如，对于反射型跨站脚本风险的疑似风险，当在细粒度(level2)的检测过程中，用新的测试用例时，在返回的响应内容中仍然出现原样回显，则确认漏洞。当疑似风险为对任意文件上传漏洞进行检测得到时，检测管理单元330则将其直接确认为风险。

对于一些漏洞的疑似风险，需要根据所述功能点的业务功能对粗粒度检测结果进行校验即可。因而，在一个实施例中检测模块33还包括结果校验单元334，其与所述检测管理单元330相连接，经配置以接收检测管理单元330的结果校验指令，按照校验策略对疑似风险进行校验。其中，需要校验的漏洞例如为一些涉及到权限类的漏洞，如水平越权漏洞、未授权访问漏洞和垂直越权漏洞，还可为一些涉及敏感功能的漏洞，如跨站请求伪造漏洞等。因而，所述结果校验单元334可以为一个，逐个对需要结果校验的漏洞按照对应的校验机制进行校验。结果校验单元334也可以为多个，分别对应不同的漏洞结果校验。

其中，对于水平越权漏洞、未授权访问漏洞和垂直越权漏洞等权限类漏洞，结果校验单元334查询URL标记字段中的标识内容为账户权限的标记，在账户权限没有标记时，开启爬虫引擎进行功能点链接的抓取。例如，对于未授权访问漏洞，开启爬虫引擎使用未登录帐户抓取所述功能点链接；对于垂直越权漏洞开启爬虫引擎使用普通帐户抓取所述功能点链接。在抓取到所述功能点链接时，将所述功能点URL标记字段中的账户权限标记为“否”，并排除所述风险，即将当前的风险状态由“疑似”修改为“误报”。

对于水平越权漏洞和垂直越权漏洞，当结果校验单元334查询到响应于URL标记字段中的账户权限的标记为“是”时，查询用户私有功能的标记；在用户私有功能的标记为“是”时，确认所述风险，即将当前的风险状态由“疑似”修改为“确认”，在用户私有功能的标记为“否”排除所述风险。

对于未授权访问漏洞，当结果校验单元334查询到响应于URL标记字段中的账户权限的标记为“是”时，排除所述风险。

另外，对于跨站请求伪造漏洞，结果校验单元334查询当前功能点URL标记字段的敏感功能，当其标记为“是”时，确认所述风险；当其标记为“否”时，排除所述风险。

检测管理单元330在全部功能点检测完成且所述的URL标记字段中的所有标识内容是否全部标记完成，查询每一个功能点URL标记字段中的标识内容为信息存储的标记，对于标记为“否”的功能点重新进行存储型跨站脚本漏洞的检测。即向检测存储型跨站脚本漏洞的检测模型单元发送重放请求的指令，检测存储型跨站脚本漏洞的检测模型单元根据所述指令重新发出测试请求数据包，其校验子单元根据当前请求的响应内容与粗检测时的响应内容进行对比，根据比较结果确认是否为风险。

前述漏洞检测方法根据校验类型将漏洞分为不同的小组，所述校验类型例如为请求响应校验型、替换请求响应校验型、登录凭证替换校验型、响应内容校验型或请求重放校验型。不同校验类型的漏洞，针对其漏洞类型具有不同的检测策略，并分别由一个检测模型单元执行。由于随着测试目标的版本更新等原因，漏洞的类型在不断变化，可能随时出现新的漏洞，当出现新的漏洞时，由于本发明采用检测模型单元模式，因而只需要为新的漏洞匹配对应的校验类型，将其增加到对应的小组即可。或者，当没有与其匹配的已有校验类型时，可以为其单独再增加一个检测模型单元，并不会影响其它检测模型单元的运行。这种模块化的检测模式具备良好的扩展性，可随时新增或删除某些漏洞检测。由于检测模型单元的检测流程制成标准化，检测项也固定为标准化形式，在增加漏洞检测时，安全工程师只需在前端(如本发明提供的管理界面)对相关参数项进行修改，如增加漏洞名称、类型，设定其对应的校验类型，或者增加新的校验类型等等，因而大大减少了对开发人员的依赖，减少开发人员的介入和工作量。并且由于检测流程及策略的标准化，使得仅拥有基础知识的初级安全工程师也能够完成最终的漏洞复核，高级别工程师则专注于检测策略制定及新规则研究。本发明将检测流程拆分为初始的粗粒度安全检测和复核的细粒度安全检测两步，粗粒度安全检测仅配置少量最优的测试用例，如出现疑似漏洞再调用大量而精准的测试用例进行复核，因而对测试服务器的性能要求不高，在较差性能的测试环境下可以快速完成漏洞的安全检测，准确性高、效率高。

通过上述说明可见，自动检测工具对漏洞的检测准确性、完整性是本系统至关重要的部分。为了验证所述的自动检测工具是否符合要求，是否可信，以前提供了对其可信度验证方法。

图11是根据本发明一个实施例的自动检测工具可信度验证方法流程图。所述方法包括以下步骤：

步骤S100，获取验证指标参考数据。在本发明中，通过管理界面41配置验证指标，并设置对应的参考数据，例如，验证指标为“功能点数量”，并设置对应的数值作为其参考数据；验证指标为“漏洞校验类型”，并设置对应的类型名称及其检测策略；验证指标为“漏洞校验类型的漏洞数量”，并设置对应的数值，验证指标为“检测策略的一致性”、“同一漏洞的检测风险的一致性”等。这些验证指标，有的可以在检测过程中进行。例如，在检测完一个功能点的一个漏洞后，可以验证“同一漏洞的检测风险的一致性”、“检测策略的一致性”；在一个功能点全部检测完成后可以验证“漏洞校验类型”的种类、每种“漏洞校验类型的漏洞数量”等，在整个测试项目完成后，可以验证“功能点数量”。

步骤S200，获取手动检测策略。当安全工程师对不一漏洞进行手工检测时，获取并分析手动检测工具的检测数据。所述的检测数包括安全工程师在手工检测界面纂改的测试请求数据包数据，从测试目标返回的响应数据，以及安全工程师判断结果时的依据数据，及最终的检测结果数据，如没有风险，通过测试，或者有风险。从上述数据得到功能点URL、参数和/或安全工程师增加或替换的测试用例。根据测试用例、响应数据、判断数据及测试结果得到二者的关系，从而将其作为该漏洞的手动检测策略。

步骤S300，获取一个验证指标及其参考数据。

步骤S400，依据验证指标分析第二检测结果以得到对应所述验证指标的指标数据。例如，当验证指标为“功能点数量”时，将统计自动检测工具的检测结果，以确定已检测过的功能点数量，并将其与“功能点数量”的数值对比，对应的指标数据为二者相同，或者不同，如为不同时，在进行标记的同时，确定自动检测工具检测的功能点数量是多于参考数值，还是少于参考数值。又例如，当验证指标为“检测策略的一致性”时，对比自动检测工具使用的检测策略与手动检测策略是否一致，包括：测试用例、检测流程、校验方法等等是否相同或相似。又例如，当验证指标为“同一漏洞的检测风险的一致性”时，对比手动检测工具得到的第一检测结果与自动检测工具得到的第二检测结果是否一致。

步骤S500，判断是否还有验证指标未分析，如果有，则返步骤S300，如果没有，则在步骤S600，基于所述指标数据及每个功能点的每个漏洞的检测可信度生成可信度报告。其中详细包括各个验证指标的数据，并以各种形式展示，例如，以表格、图形等方案展示各个验证指标，并且多级链接的方式记录对应的详细信息。

图12是根据本发明一个实施例在一个功能点进行某个漏洞检测过程中进行验证方法流程图。具体包括以下步骤：

步骤S100a，安全工程师通过测试商浏览器发出对应测试目标一个功能点的测试请求。

步骤S201a，手动检测工具截获所述测试请求数据包。步骤S202a，安全工程师基于所述测试请求数据包进行人工检测，并在步骤S203a得到第一检测结果。

同时，在步骤S301a，自动检测工具获取测试请求的镜像数据包进行自动检测，并在步骤S302a构造自动测试请求进行自动检测，并在步骤S303a得到第二检测结果。

步骤S400a，对比第一检测结果和第二检测结果。在步骤S500a判断二者是否一致，如果一致，则将对比结果写入可信度验证报告，结束对该漏洞检测的验证。如果不一致，在步骤S501a，自动检测工具重新采用不同的测试用例构造不同的自动检测测试请求数据包以对该漏洞重复检测，例如，重复检测3-5次。

步骤S502a，判断多次检测结果是否一致，如果一至，则在步骤S503a将所述检测结果作为最终第二次检测结果，并执行步骤S505a。如果不一致，则在步骤S504a发送通知给安全工程师。

步骤S505a，对比第一检测结果和最终第二检测结果，并在步骤S506a将对比结果写入可信度验证报告。在第一检测结果和最终第二检测结果一致时，在可信度验证报告中对该漏洞的检测结果标记为可信。如果不一致，标记为可疑，并发送通知给安全工程师，等待进一步确认。

当安全工程师在检测过程中在管理界面41中接收到自动检测工具对同一漏洞重复检测时出现不同的结果的通知时，通过查看自动检测工具的检测数据确定原因，并根据原因修改自动检测工具的检测策略。

当安全工程师在管理界面41中接收到自动检测工具与手动检测工具的检测结果不同的通知时，通过查看自动检测工具的检测数据和手动检测工具的检测数据以确定哪一个结果正确，在必要时，对该漏洞重新手动检测。当确定手动检测工具的检测结果正确时，确认手动检测结果。此时，自动检测工具接收到所述确认消息后，采用手动检测策略更新自动检测工具对该漏洞的检测策略，例如替换测试用例及对应的校验参数。

图13是根据本发明一个实施例的漏洞检测工具可信度验证系统原理框图。所述系统在图1所示的系统的基础上还包括可信度验证模块5。其中，所述测试端浏览器1通过预置的代理端口向测试目标发送功能点测试请求，并接收从测试目标返回的响应数据包；所述手动检测工具2经配置以截取向测试目标发出的测试请求数据包，提供手动检测界面供安全工程师手动检测，并获取第一检测结果；所述自动检测工具3经配置以获取经所述代理端口发出的来自于测试端浏览器的功能点测试请求的镜像数据包，根据预置检测策略对镜像数据包对应的功能点进行漏洞检测以获得第二检测结果；所述可信度验证模块5与所述手动检测工具2和自动检测工具3相连接，经配置以所述第一检测结果和所述第二检测结果；根据对比结果确定所述自动检测工具的可信度。其中，所述项目检测管理模块4提供管理界面41，可配置检测策略、验证指标及其参考数据。

参见图14，所述可信度验证模块5包括数据获取单元51、漏洞可信度单元52和综合分析单元53。其中所述数据获取单元51分别与手动检测工具2、自动检测工具3和项目检测管理模块4相连接，从手动检测工具2获取第一检测结果，从所述自动检测工具3获得第二检测结果，或者当手动检测工具2和自动检测工具3将其检测结果数据发送给项目检测管理模块4时，所述数据获取单元51从所述项目检测管理模块4中获得第一检测结果和第二检测结果。另外，所述数据获取单元51从手动检测工具或所述项目检测管理模块4中获得手动检测数据，并从中得到手动检测策略。所述数据获取单元51根据验证需要，从项目检测管理模块4中获取验证指标及对应的参考数据。

漏洞可信度单元52与所述数据分析单元51相连接，用以对比所述第一检测结果和所述第二检测结果，根据对比结果确定所述自动检测工具对所述功能点漏洞检测的可信度，具体过程可参见图12。

综合分析单元53按照预置验证指标分析所述第二检测结果，基于所述验证指标数据及每个功能点的每个漏洞的检测可信度生成可信度报告。具体可参见图11及前述对方法部分的说明，在此不再重复。

在另一个实施例中，如图13所示的虛线所示，所述系统还包括更新模块6，其分别与可信度验证模块5和项目检测管理模块4相连接，在可信度验证模块5确认到自动检测工具漏检的漏洞时，发送更新通知给所述更新模块6。所述更新模块6根据所述更新通知将漏检的漏洞及对应的手动检测策略增加给所述自动检测。当安全工程师通过管理界面41确认了一个漏洞的检测结果是手动检测结果正确可信后，发送通知给所述更新模块6。所述更新模块6根据所述更新通知采用检测所述漏洞时的手动检测策略更新自动检测工具中的对应检测策略。

通过以上验证方法和系统，可以确保自动检测工具对漏洞检测的准确性，不需要过多的人工参与，只需要安全工程师在必要时给予确认，因而人为因素影响小；并且可以在检测过程中实时进行验证，在检测完成时即可以得到验证结果，因而效率高。

上述实施例仅供说明本发明之用，而并非是对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明范围的情况下，还可以做出各种变化和变型，因此，所有等同的技术方案也应属于本发明公开的范畴。

Claims (12)

1.一种漏洞检测工具可信度验证方法，其中包括：

基于测试端浏览器向测试目标发送功能点测试请求；

手动检测工具截获所述测试请求的数据包，并由安全工程师根据漏洞检测策略手动检测以获得对应功能点的第一检测结果；

自动检测工具获取所述测试请求的镜像数据包，根据预置检测策略对镜像数据包对应的功能点进行漏洞检测以获得第二检测结果；

对比所述第一检测结果和所述第二检测结果；以及

根据对比结果确定所述自动检测工具对所述功能点漏洞检测的可信度。

2.根据权利要求1所述的方法，其中进一步包括：向所述自动检测工具加载与所述测试项目对应的检测策略；其中所述检测策略包括与漏洞类型对应的检测流程、测试请求构造方法、测试用例和用于判定风险的参数值。

3.根据权利要求2所述的方法，其中进一步包括：

获取并分析手动检测工具的检测数据；

从所述检测数据中确定测试请求数据、响应数据及第一检测结果数据；

从所述测试请求数据中获取功能点URL、参数和/或测试用例；以及

从所述响应数据及第一检测结果数据中确定所述测试用例及其响应值对应于风险的关系以得到漏洞的手动检测策略。

4.根据权利要求1所述的方法，其中进一步包括：提供验证指标参考数据；所述验证指标包括功能点数量、漏洞校验类型及其检测策略、每种漏洞校验类型的漏洞数量、检测策略的一致性、同一漏洞的检测风险的一致性中的一者或多者。

5.根据权利要求4所述的方法，其中进一步包括：

获取验证指标参考数据；

依据验证指标分析第二检测结果以得到对应所述验证指标的指标数据；以及

基于所述指标数据及每个功能点的每个漏洞的检测可信度生成可信度报告。

6.根据权利要求5所述的方法，其中进一步包括对自动检测工具更新的步骤：

响应于自动检测工具漏检的漏洞，获取手动检测工具检测所述漏洞的手动检测策略并增加至自动检测工具中；或

响应于安全工程师对第一检测结果的确认，采用所述漏洞的手动检测策略更新自动检测工具中的对应检测策略。

7.根据权利要求5所述的方法，其中在检测同一漏洞时手动检测工具检测到的漏洞风险与自动检测工具检测到的漏洞风险不一致时，自动检测工具更换测试用例对所述漏洞重复预置数量的检测；响应于获取预置重新检测数量的相同检测结果，以所述检测结果作为最终第二检测结果。

8.根据权利要求7所述的方法，其中进一步包括：在第一检测结果和最终第二检测结果中对应所述漏洞风险不同时，发送提醒通知。

9.一种漏洞检测工具可信度验证系统，其中包括：

测试端浏览器，经配置以通过预置的代理端口向测试目标发送功能点测试请求，并接收从测试目标返回的响应数据包；

手动检测工具，经配置以截取向测试目标发出的测试请求数据包，提供手动检测界面供安全工程师手动检测，并获取第一检测结果；

自动检测工具，经配置以获取经所述代理端口发出的来自于测试端浏览器的功能点测试请求的镜像数据包，根据预置检测策略对镜像数据包对应的功能点进行漏洞检测以获得第二检测结果；以及

可信度验证模块，其与所述手动检测工具和自动检测工具相连接，经配置以对比所述第一检测结果和所述第二检测结果；根据对比结果确定所述自动检测工具的可信度。

10.根据权利要求9所述的系统，其中还进一步包括项目检测管理模块，其提供管理界面，经配置以提供安全测试项目的配置、检测过程、结果数据及通知的显示；其中，所述的配置包括与所述测试项目对应的检测策略和验证指标及其参考数据。

11.根据权利要求9所述的系统，其中所述可信度验证模块包括：

数据获取单元，经配置以获取手动检测策略、验证指标及其参考数据、手动检测工具得到的第一检测结果和自动检测工具的第二检测结果；

漏洞可信度单元，其与所述数据分析单元相连接，经配置以对比所述第一检测结果和所述第二检测结果，根据对比结果确定所述自动检测工具对所述功能点漏洞检测的可信度；以及

综合分析单元，经配置以按照预置验证指标分析所述第二检测结果，基于所述验证指标数据及每个功能点的每个漏洞的检测可信度生成可信度报告。

12.根据权利要求11所述的系统，其中包括更新模块，其与可信度验证模块相连接，在确认到自动检测工具漏检的漏洞时，将手动检测策略增加到所述自动检测工具中；在对一个漏洞进行检测时，在第一检测结果和最终第二检测结果不同、且接收到对第一检测结果的确认信息时，采用手动检测策略更新自动检测工具中的对应检测策略。

Images