CN113032792A - 系统业务漏洞检测方法、系统、设备及存储介质 - Google Patents

Abstract

本申请公开了一种系统业务漏洞检测方法、系统、设备及存储介质。该系统业务漏洞检测方法包括：获取待检测系统的目标检测地址；基于目标检测地址，构造目标请求报文和响应规则；将目标请求报文发送至待检测系统，以使待检测系统接收目标请求报文后，生成响应报文；获取响应报文；基于响应报文和响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果。采用本申请提供的系统业务漏洞检测方法，可以根据不同的目标检测地址构造不同的检测策略，生成不同的目标请求报文和响应规则，能够适应更多的检测场景，并且可以自动化完成整个检测过程，检测效率高。

Description

系统业务漏洞检测方法、系统、设备及存储介质

技术领域

本申请涉及移动通信领域和漏洞检测领域，具体涉及一种系统业务漏洞检测方法、系统、设备及存储介质。

背景技术

随着互联网技术的发展，各种业务办理过程均出现了其对应的业务系统。但是，随着业务系统的增多，业务系统的漏洞也逐渐增多，对业务办理造成了极大的影响。

目前，针对业务系统的漏洞检测方法主要有代码审计和人工渗透测试两种，通过手工和工具相结合，可对传统漏洞和逻辑漏洞进行深度挖掘，并根据挖掘的结果进行整改加固，从而消除逻辑缺陷、认证缺陷等隐患。

但是，代码审计和渗透测试均对人员要求非常高，不同人员风险挖掘不尽相同，受限于检测人员的经验，不利于推广和普及，检测效率较低。

发明内容

本申请实施例的目的是提供一种系统业务漏洞检测方法、系统、设备及存储介质，能够解决现有技术中漏洞检测方法受限于检测人员的经验，不利于推广和普及，检测效率较低的技术问题。

本申请的技术方案如下：

第一方面，提供了一种系统业务漏洞检测方法，包括：获取待检测系统的目标检测地址；基于目标检测地址，构造目标请求报文和响应规则；将目标请求报文发送至待检测系统，以使待检测系统接收目标请求报文后，生成响应报文；获取响应报文；基于响应报文和响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果。

在一些实施例中，在目标检测地址指示检测待检测系统中是否存在跳步骤办理目标业务的情况下，目标请求报文为获取第一请求集合，第一请求集合由待测系统办理目标业务过程中的所有请求构成；

基于响应报文和响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果，包括：

提取响应报文的第一请求集合中每个请求的至少一个特征信息；

基于预设方法和至少一个特征信息，计算得到第一请求集合中每个请求的标识信息；

基于标识信息和预设方法对第一请求集合中的请求进行排序，得到排序结果；

基于响应规则和排序结果，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果。

在一些实施例中，基于响应规则和排序结果，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果，包括：

计算响应规则和排序后的第一请求集合的匹配度；

在匹配度小于预设阈值的情况下，确定待检测系统的目标检测地址存在漏洞；

在匹配度不小于预设阈值的情况下，确定待检测系统的目标检测地址不存在漏洞。

在一些实施例中，在目标检测地址指示检测待检测系统中前端漏洞的情况下，目标请求报文为获取待检测系统的目标检测地址下的前端校验文件；

响应规则为在前端校验文件中存在资格校验规则的情况下，确定待检测系统的目标检测地址不存在漏洞，在前端校验文件中不存在资格校验规则的情况下，确定待检测系统的目标检测地址存在漏洞。

在一些实施例中，在目标检测地址指示检测待检测系统中修改资格校验状态标志的漏洞的情况下，目标请求报文为基于预设关键字定位目标参数；

基于响应报文和响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果，包括：

基于响应规则，修改响应报文中的目标参数的值；

将修改后的目标参数提交至待检测系统，以使待检测系统生成页面渲染结果；

基于页面渲染结果与响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果。

在一些实施例中，在目标检测地址指示检测待检测系统中越权访问风险的情况下，目标请求报文为基于预设方法修改目标信息后的业务办理请求；响应规则为在响应报文中的内容与修改目标信息前的返回内容相同的情况下，确定待检测系统的目标检测地址存在漏洞。

在一些实施例中，目标信息包括登录账号信息、本地目标文件信息、访问地址信息中的至少一个。

第二方面，提供了一种系统业务漏洞检测系统，包括：

第一获取模块，用于获取待检测系统的目标检测地址；

第一信息处理模块，用于基于目标检测地址，构造目标请求报文和响应规则；

第一发送模块，用于将目标请求报文发送至待检测系统，以使待检测系统接收目标请求报文后，生成响应报文；

第二获取模块，用于获取响应报文；

第二信息处理模块，用于基于响应报文和响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的系统业务漏洞检测方法的步骤。

第四方面，本申请实施例提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的系统业务漏洞检测方法的步骤。

本申请的实施例提供的技术方案至少带来以下有益效果：

本申请实施例提供的系统业务漏洞检测方法，基于目标检测地址，构造目标请求报文和响应规则，可以根据不同的目标检测地址构造不同的检测策略，生成不同的目标请求报文和响应规则，能够适应更多的检测场景。

将响应规则和待检测系统返回的响应报文进行比较，确定待检测系统的目标检测地址是否存在漏洞，自动化完成整个检测过程，检测效率高。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理，并不构成对本申请的不当限定。

图1是本申请实施例提供的一种漏洞检测系统的结构示意图；

图2是本申请实施例提供的一种系统业务漏洞检测方法的流程示意图；

图3是本申请实施例提供的跳步骤检测处理的流程示意图；

图4是本申请实施例提供的检测模型学习过程示意图；

图5是本申请实施例提供的WEB前端校验的流程示意图；

图6是本申请实施例中待检测系统返回的响应报文示意图；

图7是本申请实施例提供的一种系统业务漏洞检测系统的结构示意图；

图8是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为了使本领域普通人员更好地理解本申请的技术方案，下面将结合附图，对本申请实施例中的技术方案进行清楚、完整地描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的例子。

基于背景技术可知，现有技术中漏洞检测方法受限于检测人员的经验，不利于推广和普及，检测效率较低。

具体的，现有的漏洞检测方法，主要为代码审计和人工渗透检测的方案，其中代表性的就是渗透测试。渗透测试方案作为安全检测的重要手段之一，通过手工和工具相结合，可对传统漏洞和逻辑漏洞进行深度挖掘，并根据挖掘的结果进行整改加固，从而消除逻辑缺陷、认证缺陷等隐患。

目前已有的代码审计和渗透测试检测缺点总结如下：代码审计和渗透测试对人员要求非常高，不同人员风险挖掘不尽相同，受限于检测人员的经验，不利于推广和普及。代码审计和渗透测试测试能够解决系统在开发、部署、使用过程中存在的安全风险，但在日常系统升级、功能变更和新增的多次检测需求，虽然也可以勉强胜任，但缺乏足够的灵活性。解决方案未提供自动或批处理机制基本都是需要靠检测人工对系统进行测试，当作务多达成千上万时，检测人员对系统各功能模块逐一测试、代码逐行审核是非常耗时和单调，从而难以专注于数据本身。

基于上述发现，本申请实施例提供了一种系统业务漏洞检测方法、系统、设备及存储介质。本申请实施例中的技术方案，在未来系统发现变更时，可以快速实现优化，使业务安全检测覆盖更全，至少解决了传统人工方式“抽样检测”带来的漏洞遗漏问题。

本申请实施例中的系统业务漏洞检测方法可以应用于漏洞检测系统，漏洞检测系统的结构可以如图1所示。该漏洞检测系统可以包括输入接口101、漏洞检测工具102和输出接口103。其中，输入接口101用于确认目标url列表和明确检测对象，漏洞检测工具102包括各类功能检测模块及与其对应的检测规则，输出接口103用于输出可视化视图、检测报告以及连接风险管理台账和解决方案库。漏洞检测工具102可以采用Python脚本语言进行开发，在架构上分为扫描任务模块、拨测模块，逻辑策略模块，结果验证模块。

下面结合附图对本申请实施例提供的系统业务漏洞检测方法进行详细说明。

图2示出了本申请实施例提供的一种系统业务漏洞检测方法的流程示意图，可以应用于前文中的漏洞检测系统，如图2所示，该方法可以包括步骤S110-S150。

步骤S110，获取待检测系统的目标检测地址。

待检测系统，该待检测系统可以是各类业务处理系统，在此不作限定。下文中以待检测系统为客户管理系统(CRM系统)为例进行说明。

目标检测地址，可以是一个也可以是多个，对于数量不作限定。该目标检测地址具体可以是目标url列表。

漏洞检测系统中的扫描任务模块，通过输入接口接收用户输入的目标url列表。

步骤S120，基于目标检测地址，构造目标请求报文和响应规则。

目标请求报文，该请求报文与目标检测地址一一对应，在目标检测地址不同的情况下，对应的目标请求报文则不同。目标检测地址与目标请求报文的对应关系，详见下文实施例中的详细论述，在此不再赘述。

响应规则，与目标请求报文一一对应，同样是基于目标检测地址的不同而不同。一般情况下，该响应规则是与待检测系统接收目标请求报文后返回的响应报文相关，二者结合判断得出待检测系统是否存在漏洞。对于具体的响应规则详见下文实施例中的详细论述，在此不再赘述。

漏洞检测系统中的逻辑策略模块针对不同目标检测地址对应的不同漏洞场景构造http请求，即目标请求报文，以及给出预期的响应规则，用于判断响应报文。

步骤S130，将目标请求报文发送至待检测系统，以使待检测系统接收目标请求报文后，生成响应报文。

漏洞检测系统中的拨测模块负责按逻辑策略封装目标请求报文，即http请求报文，并向待检测系统发送封装后的目标请求报文。待检测系统在接收到http请求报文，将返回响应报文给漏洞检测系统中的结果验证模块。

步骤S140，获取响应报文。

漏洞检测系统中的结果验证模块可以接收到待检测系统返回的响应报文。

步骤S150，基于响应报文和响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果。

漏洞检测系统中的结果验证模块，判断响应报文是否满足响应规则的要求，在符合响应规则要求的情况下确认待检测系统的目标检测地址不存在漏洞，否则存在漏洞。响应报文是否满足响应规则的要求，该判断过程与具体的响应规则有关，具体的判断过程详见下文中针对具体的目标检测地址阐述的实施例，在此不再赘述。

本申请实施例提供的系统业务漏洞检测方法，基于目标检测地址，构造目标请求报文和响应规则，可以根据不同的目标检测地址构造不同的检测策略，生成不同的目标请求报文和响应规则，能够适应更多的检测场景。将响应规则和待检测系统返回的响应报文进行比较，确定待检测系统的目标检测地址是否存在漏洞，自动化完成整个检测过程，检测效率高。

在一些实施例中，未做业务校验下沉的业务办理模块中，办理资格校验与业务办理提交分步骤进行，即校验和办理操作在不同页面模块中完成。因此，系统可能存在的一类逻辑漏洞，即在业务办理请求时，服务端完全不判断当前业务提交时，是否已完成前一步骤的资格校验，那么恶意人员可以直接构造一个最终的业务提交请求，绕过资格校验成功办理业务。漏洞检测系统在处理此类检测时，目标检测地址具体可以指示检测待检测系统中是否存在跳步骤办理目标业务。

在上述情况下，目标请求报文可以为获取第一请求集合，第一请求集合由待测系统办理目标业务过程中的所有请求构成。该风险的检测，在业务风险测试过程中，以组为单位，一个业务模块办理过程中的所有HTTP请求，标记为一个请求组，即第一请求集合。自动重复业务提交请求，通过业务办理状态是否成功来判断当前模块有没有跳步骤办理业务的漏洞。

请参考附图3，跳步骤检测处理流程示意图，其中在跳步骤漏洞的检测中，可以构建一个检测模型，用于执行上述实施例中的步骤S150。

检测模型构建流程如图4所示，模型学习模块通过HTTP/HTTPS协议在访问CRM系统的过程中，对请求信息中的目标IP地址、请求类型、URL标签、请求参数等特征维度计算单个请求的唯一指纹标志，协同Referer特征维度的指纹标志对CRM系统所有请求指纹标志进行串联，并通过TITLE、请求参数关联出功能模块，最后根据请求时间序列动态的构建检测模型。

模型重放模块会自动构建多个重放请求器，一般情况下每个请求器对应一组或多组检测模型，各个请求器中采用的逻辑完全一致，请求器对单个请求组内的所有请求指纹标志列表进行逐一移除并对移除后的请求组重新进行模拟请求提交，重新构建的每个请求组分别对应一个响应结果，重放模块会对发起请求后的响应结果内容予以暂时保存，并采用相似度算法与原始内容进行内容对比，当相似度小于特定阈值后即判定为疑似存在跳步骤办理业务的漏洞。

基于上述内容步骤S150，可以具体包括步骤S151-S154。

步骤S151，提取响应报文的第一请求集合中每个请求的至少一个特征信息。

特征信息，具体可以是目标IP地址、请求类型、URL标签、请求参数中的至少一个。此处可以是所有这些特征信息。

步骤S152，基于预设方法和至少一个特征信息，计算得到第一请求集合中每个请求的标识信息。

该标识信息即前文中的指纹标志，单个请求的只对应唯一的指纹标志，即标识信息。

步骤S153，基于标识信息和预设方法对第一请求集合中的请求进行排序，得到排序结果。

步骤S154，基于响应规则和排序结果，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果。

请求器对单个请求组内的所有请求指纹标志列表进行逐一移除并对移除后的请求组重新进行模拟请求提交，重新构建的每个请求组分别对应一个响应结果。重放模块会对发起请求后的响应结果内容予以暂时保存，并采用相似度算法与原始内容进行内容对比，当相似度小于特定阈值后即判定为疑似存在跳步骤办理业务的漏洞。其中相似度小于特定阈值时，其对应的距离值即匹配度值不小于预设阈值。

作为一个示例，步骤S154，可以具体包括：

步骤S1541，计算响应规则和排序后的第一请求集合的匹配度。

在数据分析和数据挖掘的过程中，我们经常需要知道个体间差异的大小，进而评价个体的相似性和类别。最常见的是数据分析中的相关分析，数据挖掘中的分类和聚类算法，如K最近邻(KNN)和K均值(K-Means)。该匹配度的值具体可以是响应规则中的数据和排序后的第一请求集合中数据进行距离度量或相似度度量的值。

步骤S1542，在匹配度小于预设阈值的情况下，确定待检测系统的目标检测地址存在漏洞。

步骤S1543，在匹配度不小于预设阈值的情况下，确定待检测系统的目标检测地址不存在漏洞。

距离度量，用于衡量个体在空间上存在的距离，距离越远说明个体间的差异越大。具体可以采用欧几里得距离、明可夫斯基距离、曼哈顿距离、切比雪夫距离、马哈拉诺比斯距离等。

在本申请实施例中距离值可以采用如下距离算法对响应内容进行编辑距离计算。

假设响应内容p1：业务办理成功；响应内容p2：业务办理失败，根据内容p1内容p2由编辑距离公式得到编辑距离ld：2，带入相似度计算公式得到响应内容相似度≈67％，采用的相似度计算公式如下：

相似度度量，即计算个体间的相似程度，与距离度量相反，相似度度量的值越小，说明个体间相似度越小，差异越大。

本申请实施例中的系统业务漏洞检测方法，可以准确检测出待检测系统中是否存在跳步骤办理业务的漏洞，检测的准确率高，相比人工检测效率高。

在一些实施例中，CRM业务办理过程中，部分业务需要对客户的办理资格进行校验，校验逻辑不严谨时，存在使用JS在前端校验的情况，该情况下，恶意人员可以通过HTTP截断代理的方式，拦截数据包并修改校验结果，达到绕过限制，达到为不满足资格客户违规办理业务的目的。

如图5所示，在目标检测地址指示检测待检测系统中前端漏洞的情况下，目标请求报文为获取待检测系统的目标检测地址下的前端校验文件。该前端校验文件可以是JS文件。

响应规则为在前端校验文件中存在资格校验规则的情况下，确定待检测系统的目标检测地址不存在漏洞，在前端校验文件中不存在资格校验规则的情况下，确定待检测系统的目标检测地址存在漏洞。

本申请实施例中的系统业务漏洞检测方法，为快速的发现哪些模块使用前端JS校验，通过脚本工具，在CRM业务安全检测过程中，实现爬取所有的JS文件，该脚本工具对JS文件内容进行模式匹配，可以快速的发现JS脚本中的资格校验规则，避免了人工分析脚本耗时长漏报高的问题，大幅度提升安全检测的速度和准确性。

在一些实施例中，CRM业务办理过程中，部分旧模块未做业务校验下沉，办理资格校验与业务办理提交分步骤进行，校验模块对客户办理资格校验后，向前端返回校验标志，校验标志通常为Y/N或0/1，表示校验通过或不通过，前端发送带有校验标志的请求给业务办理提交模块。该过程中，可以通过篡改校验标志的方式，达到绕过客户资格校验违规办理业务的目的。

在目标检测地址指示检测待检测系统中修改资格校验状态标志的漏洞的情况下，目标请求报文为基于预设关键字定位目标参数；

基于上述内容步骤S150，可以具体包括步骤S501-S503。

步骤S501，基于响应规则，修改响应报文中的目标参数的值。

如图6所示，该图为服务端即待检测系统，返回的响应报文。其中，工具能够根据关键字快速定位“check_flag”参数即目标参数，并判断是否可以通过修改该参数值的方式绕过业务校验。因此，在该步骤中首先工具识别check_flag参数，并判断其参数值；判断参数枚举类型，在图6示例中，原参数值为“N”，那么工具将重放该报文并将参数对应修改为“Y”。

步骤S502，将修改后的目标参数提交至待检测系统，以使待检测系统生成页面渲染结果。

漏洞检测系统将修改后的参数值提交给页面渲染，并向检测人员展示页面。

步骤S503，基于页面渲染结果与响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果。

作为一个示例，基于页面渲染结果与响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果之后，还可以进一步分析越权访问的业务模块。基于此，该系统业务漏洞检测方法还可以包括步骤S154。

步骤S154，基于页面渲染结果与响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果之后，在待检测系统的目标检测地址存在漏洞的情况下，基于响应报文，确定漏洞关联的业务模块。

本申请实施例中的系统业务漏洞检测方法，为能快速发现分析应答报文中是否存在推进后续业务逻辑的状态标志，设计了客户资格校验状态标志发现脚本，CRM业务安全测试时，脚本监测业务办理过程中的页面内容，及时发现状态标志并给出提醒，帮助测试人员快速的发现存在该类校验逻辑的业务办理模块。

在一些实施例中，CRM账号根据账号所有人的岗位职责，具有不同的业务模块访问及业务办理权限。在模块的防止越权访问上，通过多种方式做限制，如通过判断当前访问请求中的账号是否具备访问权限，通过当前会话Session ID在服务端查找对应账号是否具备访问权限，或通过隐藏模块菜单的方式现在。而通过请求中的账号判断或隐藏菜单的方式，存在很大风险，可以通过修改请求中低权账号为高权账号、或获取到模块具体链接后直接访问的方式来绕过。

在目标检测地址指示检测待检测系统中越权访问风险的情况下，目标请求报文为基于预设方法修改目标信息后的业务办理请求；响应规则为在响应报文中的内容与修改目标信息前的返回内容相同的情况下，确定待检测系统的目标检测地址存在漏洞。

作为一个示例，目标信息包括登录账号信息、本地目标文件信息、访问地址信息中的至少一个。

本申请实施例中的系统业务漏洞检测方法，针对越权访问风险的检测，提供了专门的检测脚本，一个业务办理的请求，该脚本自动进行账号替换、Cookie替换、URI替换等多种形式，生成多个HTTP请求发送给服务端，通过对比服务端返回内容，判断业务模块是否存在越权访问漏洞。

基于相同的发明构思，本申请实施例还提供了一种系统业务漏洞检测系统。

图7示出了本申请实施例提供的一种系统业务漏洞检测系统，如图7所示，该系统业务漏洞检测系统700，可以包括：

第一获取模块710，可以用于获取待检测系统的目标检测地址；

第一信息处理模块720，可以用于基于目标检测地址，构造目标请求报文和响应规则；

第一发送模块730，可以用于将目标请求报文发送至待检测系统，以使待检测系统接收目标请求报文后，生成响应报文；

第二获取模块740，可以用于获取响应报文；

第二信息处理模块750，可以用于基于响应报文和响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果。

在一些实施例中，第一获取模块710中的目标检测地址可以指示检测待检测系统中是否存在跳步骤办理目标业务。第一信息处理模块720，目标请求报文为获取第一请求集合，第一请求集合由待测系统办理目标业务过程中的所有请求构成；

第二信息处理模块750，可以包括特征提取单元、标识确定单元、排序单元、漏洞检测单元。

特征提取单元，可以用于提取响应报文的第一请求集合中每个请求的至少一个特征信息；

标识确定单元，可以用于基于预设方法和至少一个特征信息，计算得到第一请求集合中每个请求的标识信息；

排序单元，可以用于基于标识信息和预设方法对第一请求集合中的请求进行排序，得到排序结果；

第一漏洞检测单元，可以用于基于响应规则和排序结果，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果。

在一些实施例中，漏洞检测单元，可以包括第一计算组件、第一判断组件、第二判断组件。

第一计算组件，可以用于计算响应规则和排序后的第一请求集合的距离值，距离值指示响应规则和排序后的第一请求集合的相似度；

第一判断组件，可以用于在距离值不满足预设条件的情况下，确定待检测系统的目标检测地址存在漏洞；

第二判断组件，可以用于在距离值满足预设条件的情况下，确定待检测系统的目标检测地址不存在漏洞。

在一些实施例中，第一获取模块710中目标检测地址可以指示检测待检测系统中前端漏洞。第一信息处理模块720，目标请求报文可以为获取待检测系统的目标检测地址下的前端校验文件；响应规则可以为在前端校验文件中存在资格校验规则的情况下，确定待检测系统的目标检测地址不存在漏洞，在前端校验文件中不存在资格校验规则的情况下，确定待检测系统的目标检测地址存在漏洞。

在一些实施例中，第一获取模块710中目标检测地址指示检测待检测系统中修改资格校验状态标志的漏洞。第一信息处理模块720，目标请求报文可以为基于预设关键字定位目标参数；

第二信息处理模块750，可以包括：

参数修改单元，可以用于基于响应规则，修改响应报文中的目标参数的值；

第一发送单元，可以用于将修改后的目标参数提交至待检测系统，以使待检测系统生成页面渲染结果；

第二漏洞检测单元，可以用于基于页面渲染结果与响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果。

在一些实施例中，该系统业务漏洞检测系统700，还可以包括：

第三信息处理模块，可以用于基于页面渲染结果与响应规则，检测待检测系统的目标检测地址是否存在漏洞，得到检测结果之后，在待检测系统的目标检测地址存在漏洞的情况下，基于响应报文，确定漏洞关联的业务模块。

在一些实施例中，第一获取模块710中目标检测地址可以指示检测待检测系统中越权访问风险。第一信息处理模块720，目标请求报文为基于预设方法修改目标信息后的业务办理请求；响应规则为在响应报文中的内容与修改目标信息前的返回内容相同的情况下，确定待检测系统的目标检测地址存在漏洞。

在一些实施例中，第一信息处理模块720中目标信息可以包括登录账号信息、本地目标文件信息、访问地址信息中的至少一个。

本申请实施例提供的系统业务漏洞检测系统，可以用于执行上述各方法实施例提供的系统业务漏洞检测方法，其实现原理和技术效果类似，为简介起见，在此不再赘述。

基于同一发明构思，本申请实施例还提供了一种电子设备。

图8是本申请实施例提供的一种电子设备的结构示意图。如图8所示，电子设备可以包括处理器801以及存储有计算机程序或指令的存储器802。

具体地，上述处理器801可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本发明实施例的一个或多个集成电路。

存储器802可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器802可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器502可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器502可在综合网关容灾设备的内部或外部。在特定实施例中，存储器802是非易失性固态存储器。在特定实施例中，存储器802包括只读存储器(ROM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(PROM)、可擦除PROM(EPROM)、电可擦除PROM(EEPROM)、电可改写ROM(EAROM)或闪存或者两个或更多个以上这些的组合。

处理器801通过读取并执行存储器802中存储的计算机程序指令，以实现上述实施例中的任意一种系统业务漏洞检测方法。

在一个示例中，电子设备还可包括通信接口803和总线810。其中，如图8所示，处理器801、存储器802、通信接口803通过总线810连接并完成相互间的通信。

通信接口803，主要用于实现本发明实施例中各模块、设备、单元和/或设备之间的通信。

总线810包括硬件、软件或两者，将电子设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线810可包括一个或多个总线。尽管本发明实施例描述和示出了特定的总线，但本发明考虑任何合适的总线或互连。

该电子设备可以执行本发明实施例中的系统业务漏洞检测方法，从而实现上述各实施例中描述的系统业务漏洞检测方法和系统。

另外，结合上述实施例中的系统业务漏洞检测方法，本发明实施例可提供一种可读存储介质来实现。该可读存储介质上存储有程序指令；该程序指令被处理器执行时实现上述实施例中的任意一种系统业务漏洞检测方法。

需要明确的是，本发明并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本发明的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本发明的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本发明中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本发明不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

以上所述，仅为本发明的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。

Claims (10)

1.一种系统业务漏洞检测方法，其特征在于，包括：

获取待检测系统的目标检测地址；

基于所述目标检测地址，构造目标请求报文和响应规则；

将所述目标请求报文发送至待检测系统，以使所述待检测系统接收所述目标请求报文后，生成响应报文；

获取所述响应报文；

基于所述响应报文和所述响应规则，检测所述待检测系统的目标检测地址是否存在漏洞，得到检测结果。

2.根据权利要求1所述的方法，其特征在于，在所述目标检测地址指示检测所述待检测系统中是否存在跳步骤办理目标业务的情况下，所述目标请求报文为获取第一请求集合，所述第一请求集合由所述待检测系统办理目标业务过程中的所有请求构成；

所述基于所述响应报文和所述响应规则，检测所述待检测系统的目标检测地址是否存在漏洞，得到检测结果，包括：

提取所述响应报文的第一请求集合中每个请求的至少一个特征信息；

基于预设方法和所述至少一个特征信息，计算得到所述第一请求集合中每个请求的标识信息；

基于所述标识信息和预设方法对所述第一请求集合中的请求进行排序，得到排序结果；

基于所述响应规则和所述排序结果，检测所述待检测系统的目标检测地址是否存在漏洞，得到检测结果。

3.根据权利要求2所述的方法，其特征在于，所述基于所述响应规则和所述排序结果，检测所述待检测系统的目标检测地址是否存在漏洞，得到检测结果，包括：

计算所述响应规则和排序后的所述第一请求集合的匹配度；

在所述匹配度小于预设阈值的情况下，确定所述待检测系统的目标检测地址存在漏洞；

在所述匹配度不小于预设阈值的情况下，确定所述待检测系统的目标检测地址不存在漏洞。

4.根据权利要求1所述的方法，其特征在于，在所述目标检测地址指示检测所述待检测系统中前端漏洞的情况下，所述目标请求报文为获取所述待检测系统的目标检测地址下的前端校验文件；

所述响应规则为在所述前端校验文件中存在资格校验规则的情况下，确定所述待检测系统的目标检测地址不存在漏洞，在所述前端校验文件中不存在资格校验规则的情况下，确定所述待检测系统的目标检测地址存在漏洞。

5.根据权利要求1所述的方法，其特征在于，在所述目标检测地址指示检测所述待检测系统中修改资格校验状态标志的漏洞的情况下，所述目标请求报文为基于预设关键字定位目标参数；

所述基于所述响应报文和所述响应规则，检测所述待检测系统的目标检测地址是否存在漏洞，得到检测结果，包括：

基于所述响应规则，修改所述响应报文中的所述目标参数的值；

将修改后的所述目标参数提交至所述待检测系统，以使所述待检测系统生成页面渲染结果；

基于所述页面渲染结果与所述响应规则，检测所述待检测系统的目标检测地址是否存在漏洞，得到检测结果。

6.根据权利要求1所述的方法，其特征在于，在所述目标检测地址指示检测所述待检测系统中越权访问风险的情况下，所述目标请求报文为基于预设方法修改目标信息后的业务办理请求；所述响应规则为在所述响应报文中的内容与修改目标信息前的返回内容相同的情况下，确定所述待检测系统的目标检测地址存在漏洞。

7.根据权利要求6所述的方法，其特征在于，所述目标信息包括登录账号信息、本地目标文件信息、访问地址信息中的至少一个。

8.一种系统业务漏洞检测系统，其特征在于，包括：

第一获取模块，用于获取待检测系统的目标检测地址；

第一信息处理模块，用于基于所述目标检测地址，构造目标请求报文和响应规则；

第一发送模块，用于将所述目标请求报文发送至待检测系统，以使所述待检测系统接收所述目标请求报文后，生成响应报文；

第二获取模块，用于获取所述响应报文；

第二信息处理模块，用于基于所述响应报文和所述响应规则，检测所述待检测系统的目标检测地址是否存在漏洞，得到检测结果。

9.一种电子设备，其特征在于，包括处理器，存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1-7任一所述的系统业务漏洞检测方法的步骤。

10.一种可读存储介质，其特征在于，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如权利要求1-7任一所述的系统业务漏洞检测方法的步骤。

Images