CN114422274B - 一种基于云原生的多场景漏洞检测方法、装置及存储介质 - Google Patents

Abstract

本申请公开了一种基于云原生的多场景漏洞检测方法、装置及存储介质，可应用于云安全、云原生、地图车联等领域或场景。通过在系统层进行漏洞检测并执行系统处理操作；然后对应用层进行检测；进而获取目标应用对应的运行数据请求；然后基于预设检测模块依次对运行数据请求进行漏洞检测，以基于应用处理操作进行对应的漏洞处理。从而实现系统层与应用层的全方位漏洞检测过程，由于采用系统层的端口检测过程，提高了服务器维度的安全性，并结合应用层采用实时的漏洞检测，在接入应用数据前即可得到相应的异常信息，提高了漏洞检测的准确性。

Description

一种基于云原生的多场景漏洞检测方法、装置及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种基于云原生的多场景漏洞检测方法、装置及存储介质。

背景技术

随着互联网技术的迅速发展，人们对数据安全的要求越来越高。在云场景中进行漏洞检测即为一种重要的检测场景。

一般，可通过对应用程序的执行代码进行检测，并配置相应的漏洞处理方式。

但是，基于代码的漏洞检测耦合度较高，主要在应用程序上做拦截和检测，如果程序更新，原有检测方法将不适用，影响漏洞检测的准确性。

发明内容

有鉴于此，本申请提供一种基于云原生的多场景漏洞检测方法，可以有效提高漏洞检测的准确性。

本申请第一方面提供一种基于云原生的多场景漏洞检测方法，可以应用于终端设备中包含漏洞的处理功能的系统或程序中，具体包括：

响应于云原生场景中系统状态的变化，对系统层基于所述系统状态的变化所对应的端口信息或操作信息进行系统层的漏洞检测；

基于所述系统层的漏洞检测的进程，调用所述系统层中与所述端口信息或所述操作信息相应的系统功能模块执行系统处理操作；

响应于所述系统处理操作的执行，对所述云原生场景中应用层所包含的目标应用进行应用层的漏洞检测；

基于所述应用层的漏洞检测的进程检测所述目标应用的启动，以获取所述目标应用在启动时对应的运行数据请求；

将所述运行数据请求依次输入预设检测模块进行异常项目的检测，以确定异常信息，所述异常项目基于所述预设检测模块指示的漏洞类型设定；

对所述异常信息中包含的访问参数进行解析得到应用处理操作，以基于所述应用处理操作进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述对所述异常信息中包含的访问参数进行解析得到应用处理操作，以基于所述应用处理操作进行对应的漏洞处理，包括：

对所述异常信息中包含的访问参数进行解析，以确定所述访问参数中的特殊符号；

对所述特殊符号进行转义以确定对应的所述应用处理操作；

根据所述应用处理操作确定说明字符，并将所述说明字符发送至所述目标应用进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述方法还包括：

获取所述异常信息中包含的访问参数所对应的操作记录；

根据所述操作记录中指示的异常日志将所述异常信息发送至所述目标应用，以使得所述目标应用对所述异常信息进行记录，记录后的所述异常信息用于对应预设处理模块的定制。

可选的，在本申请一些可能的实现方式中，所述对所述异常信息中包含的访问参数进行解析得到应用处理操作，以基于所述应用处理操作进行对应的漏洞处理，包括：

对所述异常信息中包含的访问参数进行解析得到指示访问目的的地址信息；

基于所述地址信息进行预设地址的匹配，以得到匹配信息；

根据所述匹配信息中指示的所述地址信息与所述预设地址的关联度确定所述应用处理操作；

基于所述应用处理操作对所述地址信息进行拦截，以进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述方法还包括：

响应于配置操作获取针对于访问目的配置的目标黑名单；

若所述地址信息为所述目标黑名单中的地址，则将所述地址信息替换为预设地址发送至所述目标应用。

可选的，在本申请一些可能的实现方式中，所述对所述异常信息中包含的访问参数进行解析得到应用处理操作，以基于所述应用处理操作进行对应的漏洞处理，包括：

对所述异常信息中包含的访问参数进行解析，以确定所述异常信息指示的漏洞类型；

若所述漏洞类型对应的应用处理操作为开发者自定义处理，则将所述异常信息发送至开发者自定义处理程序，以基于所述应用处理操作进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述方法还包括：

响应于所述开发者自定义处理程序的执行，获取执行过程中的日志信息；

将所述日志信息与所述异常信息进行关联，以得到关联信息；

基于所述关联信息对预设处理模块进行更新，以执行漏洞检测过程中所述预设处理模块的调用。

可选的，在本申请一些可能的实现方式中，所述将所述运行数据请求依次输入预设检测模块进行异常项目的检测，以确定异常信息，包括：

对所述应用层中配置的检测模块库进行遍历，以确定所述检测模块库中异常项目适配于所述运行数据请求的多个所述预设检测模块；

将所述运行数据请求依次输入多个所述预设检测模块进行异常项目的检测，以确定所述异常信息。

可选的，在本申请一些可能的实现方式中，所述将所述运行数据请求依次输入多个所述预设检测模块进行异常项目的检测，以确定所述异常信息，包括：

对所述异常项目对应的检测次数进行统计，以得到所述异常项目对应的检测分布信息；

基于所述检测分布信息对所述预设检测模块进行排序，以确定执行次序；

根据所述执行次序将所述运行数据请求依次输入多个所述预设检测模块进行异常项目的检测，以确定所述异常信息。

可选的，在本申请一些可能的实现方式中，所述基于所述检测分布信息对所述预设检测模块进行排序，以确定执行次序，包括：

基于所述应用层执行负载检测操作，以获取云原生场景的负载信息；

根据所述负载信息对所述预设检测模块的数量进行限制，以得到负载检测数量；

基于所述负载检测数量对所述预设检测模块进行筛选，以确定排序检测模块；

基于所述检测分布信息对所述排序检测模块进行排序，以确定所述执行次序。

可选的，在本申请一些可能的实现方式中，所述对所述应用层中配置的检测模块库进行遍历，以确定所述检测模块库中异常项目适配于所述运行数据请求的多个所述预设检测模块，包括：

获取所述运行数据请求指示的目标应用所对应的画像信息；

根据所述画像信息确定异常项目的范围分布参数；

基于所述范围分布参数对所述应用层中配置的检测模块库进行遍历，以确定所述检测模块库中异常项目适配于所述范围分布参数的多个所述预设检测模块。

可选的，在本申请一些可能的实现方式中，所述方法还包括：

确定所述目标应用在所述云原生场景中所处的目标集群；

对所述目标集群中的应用对象进行解析，以确定与所述目标应用具有相似访问特征的关联应用；

获取所述关联应用在所述应用层中配置的关联处理模块；

基于所述关联处理模块进行功能复制，以对所述预设处理模块进行更新。

本申请第二方面提供一种基于云原生的多场景漏洞检测装置，包括：

检测单元，用于响应于云原生场景中系统状态的变化，对系统层基于所述系统状态的变化所对应的端口信息或操作信息进行系统层的漏洞检测；

调用单元，用于基于所述系统层的漏洞检测的进程，调用所述系统层中与所述端口信息或所述操作信息相应的系统功能模块执行系统处理操作；

所述检测单元，还用于响应于所述系统处理操作的执行，对所述云原生场景中应用层所包含的目标应用进行应用层的漏洞检测；

获取单元，用于基于所述应用层的漏洞检测的进程检测所述目标应用的启动，以获取所述目标应用在启动时对应的运行数据请求；

所述检测单元，还用于将所述运行数据请求依次输入预设检测模块进行异常项目的检测，以确定异常信息，所述异常项目基于所述预设检测模块指示的漏洞类型设定；

所述检测单元，还用于对所述异常信息中包含的访问参数进行解析得到应用处理操作，以基于所述应用处理操作进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述检测单元，具体用于对所述异常信息中包含的访问参数进行解析，以确定所述访问参数中的特殊符号；

所述检测单元，具体用于对所述特殊符号进行转义以确定对应的所述应用处理操作；

所述检测单元，具体用于根据所述应用处理操作确定说明字符，并将所述说明字符发送至所述目标应用进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述检测单元，具体用于获取所述异常信息中包含的访问参数所对应的操作记录；

所述检测单元，具体用于根据所述操作记录中指示的异常日志将所述异常信息发送至所述目标应用，以使得所述目标应用对所述异常信息进行记录，记录后的所述异常信息用于对应预设处理模块的定制。

可选的，在本申请一些可能的实现方式中，所述检测单元，具体用于对所述异常信息中包含的访问参数进行解析得到指示访问目的的地址信息；

所述检测单元，具体用于基于所述地址信息进行预设地址的匹配，以得到匹配信息；

所述检测单元，具体用于根据所述匹配信息中指示的所述地址信息与所述预设地址的关联度确定所述应用处理操作；

所述检测单元，具体用于基于所述应用处理操作对所述地址信息进行拦截，以进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述检测单元，具体用于响应于配置操作获取针对于访问目的配置的目标黑名单；

所述检测单元，具体用于若所述地址信息为所述目标黑名单中的地址，则将所述地址信息替换为预设地址发送至所述目标应用。

可选的，在本申请一些可能的实现方式中，所述检测单元，具体用于对所述异常信息中包含的访问参数进行解析，以确定所述异常信息指示的漏洞类型；

所述检测单元，具体用于若所述漏洞类型对应的应用处理操作为开发者自定义处理，则将所述异常信息发送至开发者自定义处理程序，以基于所述应用处理操作进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述检测单元，具体用于响应于所述开发者自定义处理程序的执行，获取执行过程中的日志信息；

所述检测单元，具体用于将所述日志信息与所述异常信息进行关联，以得到关联信息；

所述检测单元，具体用于基于所述关联信息对预设处理模块进行更新，以执行漏洞检测过程中所述预设处理模块的调用。

可选的，在本申请一些可能的实现方式中，所述检测单元，具体用于对所述应用层中配置的检测模块库进行遍历，以确定所述检测模块库中异常项目适配于所述运行数据请求的多个所述预设检测模块；

所述检测单元，具体用于将所述运行数据请求依次输入多个所述预设检测模块进行异常项目的检测，以确定所述异常信息。

可选的，在本申请一些可能的实现方式中，所述检测单元，具体用于对所述异常项目对应的检测次数进行统计，以得到所述异常项目对应的检测分布信息；

所述检测单元，具体用于基于所述检测分布信息对所述预设检测模块进行排序，以确定执行次序；

所述检测单元，具体用于根据所述执行次序将所述运行数据请求依次输入多个所述预设检测模块进行异常项目的检测，以确定所述异常信息。

可选的，在本申请一些可能的实现方式中，所述检测单元，具体用于基于所述应用层执行负载检测操作，以获取云原生场景的负载信息；

所述检测单元，具体用于根据所述负载信息对所述预设检测模块的数量进行限制，以得到负载检测数量；

所述检测单元，具体用于基于所述负载检测数量对所述预设检测模块进行筛选，以确定排序检测模块；

所述检测单元，具体用于基于所述检测分布信息对所述排序检测模块进行排序，以确定所述执行次序。

可选的，在本申请一些可能的实现方式中，所述检测单元，具体用于获取所述运行数据请求指示的目标应用所对应的画像信息；

所述检测单元，具体用于根据所述画像信息确定异常项目的范围分布参数；

所述检测单元，具体用于基于所述范围分布参数对所述应用层中配置的检测模块库进行遍历，以确定所述检测模块库中异常项目适配于所述范围分布参数的多个所述预设检测模块。

可选的，在本申请一些可能的实现方式中，所述检测单元，具体用于确定所述目标应用在所述云原生场景中所处的目标集群；

所述检测单元，具体用于对所述目标集群中的应用对象进行解析，以确定与所述目标应用具有相似访问特征的关联应用；

所述检测单元，具体用于获取所述关联应用在所述应用层中配置的关联处理模块；

所述检测单元，具体用于基于所述关联处理模块进行功能复制，以对所述预设处理模块进行更新。

本申请第三方面提供一种计算机设备，包括：存储器、处理器以及总线系统；所述存储器用于存储程序代码；所述处理器用于根据所述程序代码中的指令执行上述第一方面或第一方面任一项所述的基于云原生的多场景漏洞检测方法。

本申请第四方面提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面任一项所述的基于云原生的多场景漏洞检测方法。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述第一方面或者第一方面的各种可选实现方式中提供的基于云原生的多场景漏洞检测方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

通过响应于云原生场景中系统状态的变化，在系统层进行漏洞检测并调用相应的系统功能模块执行系统处理操作；然后基于系统处理操作的执行，对云原生场景中的应用层进行检测；进而响应于在应用层中检测到目标应用的启动，获取目标应用对应的运行数据请求；然后基于预设检测模块依次对运行数据请求进行漏洞检测，以确定异常信息；进而根据异常信息确定对应的应用处理操作，以基于应用处理操作进行对应的漏洞处理。从而实现系统层与应用层的全方位漏洞检测过程，由于采用系统层的端口检测过程，提高了服务器维度的安全性，并结合应用层采用实时的运行数据请求进行漏洞检测，在接入应用数据前即可得到相应的异常信息，提高了漏洞检测的准确性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为漏洞的处理系统运行的网络架构图；

图2为本申请实施例提供的一种基于云原生的多场景漏洞检测的流程架构图；

图3为本申请实施例提供的一种基于云原生的多场景漏洞检测方法的流程图；

图4为本申请实施例提供的一种基于云原生的多场景漏洞检测方法的流程示意图；

图5为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；

图6为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；

图7为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；

图8为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；

图9为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；

图10为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；

图11为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；

图12为本申请实施例提供的一种基于云原生的多场景漏洞检测装置的结构示意图；

图13为本申请实施例提供的一种终端设备的结构示意图；

图14为本申请实施例提供的一种服务器的结构示意图。

具体实施方式

本申请实施例提供了一种基于云原生的多场景漏洞检测方法以及相关装置，可以应用于终端设备中包含漏洞的处理功能的系统或程序中，通过响应于云原生场景中系统状态的变化，在系统层进行漏洞检测并调用相应的系统功能模块执行系统处理操作；然后基于系统处理操作的执行，对云原生场景中的应用层进行检测；进而响应于在应用层中检测到目标应用的启动，获取目标应用对应的运行数据请求；然后基于预设检测模块依次对运行数据请求进行漏洞检测，以确定异常信息；进而根据异常信息确定对应的应用处理操作，以基于应用处理操作进行对应的漏洞处理。从而实现系统层与应用层的全方位漏洞检测过程，由于采用系统层的端口检测过程，提高了服务器维度的安全性，并结合应用层采用实时的运行数据请求进行漏洞检测，在接入应用数据前即可得到相应的异常信息，提高了漏洞检测的准确性。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等（如果存在）是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“对应于”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，对本申请实施例中可能出现的一些名词进行解释。

云原生（cloud native）：是一种基于云的基础之上的软件架构思想,以及基于云进行软件开发实践的一组方法论。云原生架构中，应用程序位于云中，而不是传统的数据中心，即应用程序在设计之初即考虑到云的环境，原生为云而设计，在云上以最佳形态运行，充分利用和发挥云平台的弹性+分布式优势。云原生也是一种利用云计算软件交付模型的优势，来构建和运行应用程序的方法。这些应用的特点是可以实现快速和频繁的构建、发布、部署，结合云计算的特点实现和底层硬件和操作系统解耦，可以方便的满足在扩展性，可用性，可移植性等方面的要求，并提供更好的经济性。

Web漏洞：指网站程序上的漏洞，可能是由于代码编写者在编写代码时考虑不周全等原因而造成的漏洞，包括SQL注入、XSS跨站点脚本、跨目录访问、缓冲区溢出、cookies修改、HTTP方法篡改、CSRF、SSRF、CRLF、命令行注入等。

结构化查询语言（Structured Query Language，SQL）：是一种特殊目的的编程语言，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统。

跨站脚本攻击（Cross Site Scripting，XSS）：通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行制造的网页程序。

缓存数据（cookies）：是某些网站为了辨别用户身份，进行身份跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息。

超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在协议连接之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。

跨站请求伪造（Cross-site request forgery，CSRF）：是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。

服务器端请求伪造 (Server-Side Request Forgery，SSRF)：由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制导致对象可以传入任意的地址来让后端服务器对其发起请求，并返回对该目标地址请求的数据。

回车换行（Carriage-Return Line-Feed，CRLF）：能够将命令注入到系统中，它不是系统或服务器软件的漏洞，而是网站应用开发时，有些开发者没有意识到此类攻击存在的可能而造成的。

应理解，本申请提供的基于云原生的多场景漏洞检测方法可以应用于终端设备中包含漏洞的处理功能的系统或程序中，例如漏洞检测，具体的，漏洞的处理系统可以运行于如图1所示的网络架构中，如图1所示，是漏洞的处理系统运行的网络架构图，如图可知，漏洞的处理系统可以提供与多个信息源的漏洞的处理过程，即通过终端侧的交互操作调用云服务器中对应的应用程序，并在服务器中基于应用请求进行漏洞检测；可以理解的是，图1中示出了多种终端设备，终端设备可以为计算机设备，在实际场景中可以有更多或更少种类的终端设备参与到漏洞的处理的过程中，具体数量和种类因实际场景而定，此处不做限定，另外，图1中示出了一个服务器，但在实际场景中，也可以有多个服务器的参与，具体服务器数量因实际场景而定。

本实施例中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是手机、平板电脑、笔记本电脑、台式电脑、掌上电脑、智能音箱、智能手表、智能语音交互设备、智能家电、车载终端等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，终端以及服务器可以连接组成区块链网络，本申请在此不做限制。

可以理解的是，上述漏洞的处理系统可以运行于个人移动终端，例如：作为漏洞检测这样的应用，也可以运行于服务器，还可以作为运行于第三方设备以提供漏洞的处理，以得到信息源的漏洞的处理处理结果；具体的漏洞的处理系统可以是以一种程序的形式在上述设备中运行，也可以作为上述设备中的系统部件进行运行，还可以作为云端服务程序的一种，本实施例可应用于云技术、自动驾驶等场景，具体运作模式因实际场景而定，此处不做限定。

随着互联网技术的迅速发展，人们对数据安全的要求越来越高。在云场景中进行漏洞检测即为一种重要的检测场景。

一般，可通过对应用程序的执行代码进行检测，并配置相应的漏洞处理方式。

但是，基于代码的漏洞检测耦合度较高，主要在应用程序上做拦截和检测，如果程序更新，原有检测方法将不适用，影响漏洞检测的准确性。

为了解决上述问题，本申请提出了一种基于云原生的多场景漏洞检测方法，该方法应用于图2所示的漏洞的处理的流程框架中，如图2所示，为本申请实施例提供的一种基于云原生的多场景漏洞检测的流程架构图，响应于用户在终端的交互操作，在云服务器系统层面和应用层面做漏洞检测及处理，系统层面，将对系统端口和异常配置进行告警修复。应用层面，将对请求方法，DNS漏洞，CSRF，SQL注入，XSS等漏洞进行实时的检测。本实施例将应用层面做成模块，可以供开发者接入和定制开发，做一层实时检测防护。系统层面也会对异常的操作进行检测。

本实施例通过在系统层设置漏洞拦截检测，例如当端口开放或关闭、网络波动、命令执行等时做端口扫描检测以及异常操作检测，然后调用对应的功能模块进行异常操作的告警通知以及后续的修复处理；系统层的拦截后通过布局应用层的漏洞拦截和检测，并根据实际的应用场景选择调用对应的漏洞检测模块（例如SSRF、XSS、SQL注入等）来对不同场景进行漏洞检测；例如当接收到客户端发送的请求后，首先通过应用层的检测，根据已选择的模块逐一对请求进行拦截检测，若上述请求为SQL注入攻击，则进入应用层检测后会依次调用对应的检测模块进行拦截，当检测出异常后就停止检测，并将上述请求进行IP封禁或者返回错误提示，如果未检测出异常，则上述客户端请求正常进入应用程序。本实施例提供系统层面和应用层面的漏洞检测及处理，系统层面，将对系统端口和异常配置进行告警修复。应用层面，将对请求方法，DNS漏洞，SSRF，SQL注入，XSS等漏洞进行实时的检测。本实施例将应用层面做成模块，可以供开发者接入和定制开发，做一层实时检测防护，增加了程序的安全性，另外系统层面也会对异常的操作进行检测。

可以理解的是，本申请所提供的方法可以为一种程序的写入，以作为硬件系统中的一种处理逻辑，也可以作为一种基于云原生的多场景漏洞检测装置，采用集成或外接的方式实现上述处理逻辑。作为一种实现方式，该漏洞的处理装置通过响应于云原生场景中系统状态的变化，在系统层进行漏洞检测并调用相应的系统功能模块执行系统处理操作；然后基于系统处理操作的执行，对云原生场景中的应用层进行检测；进而响应于在应用层中检测到目标应用的启动，获取目标应用对应的运行数据请求；然后基于预设检测模块依次对运行数据请求进行漏洞检测，以确定异常信息；进而根据异常信息确定对应的应用处理操作，以基于应用处理操作进行对应的漏洞处理。从而实现系统层与应用层的全方位漏洞检测过程，由于采用系统层的端口检测过程，提高了服务器维度的安全性，并结合应用层采用实时的运行数据请求进行漏洞检测，在接入应用数据前即可得到相应的异常信息，提高了漏洞检测的准确性。

结合上述流程架构，下面将对本申请中基于云原生的多场景漏洞检测方法进行介绍，请参阅图3，图3为本申请实施例提供的一种基于云原生的多场景漏洞检测方法的流程图，该管理方法可以是由服务器或终端执行的，本申请实施例至少包括以下步骤：

301、响应于云原生场景中系统状态的变化，对系统层基于系统状态的变化所对应的端口信息或操作信息进行系统层的漏洞检测。

本实施例中，系统状态的变化包括端口开放或关闭（服务器端口）、网络波动（网络断开）、命令执行（应用程序执行命令）、程序关闭启动以及定时检测(定时对端口以及异常操作的定时检测)等情况，具体的变化情况因实际场景而定。

具体的，对于系统层的处理过程如图4所示，图4为本申请实施例提供的一种基于云原生的多场景漏洞检测方法的流程示意图；图中示出了系统层面的漏洞拦截检测，当出现端口开放或关闭（服务器端口）、网络波动（网络断开）、命令执行（应用程序执行命令）、程序关闭启动以及定时检测(定时对端口以及异常操作的定时检测)以上几种情况时，针对上述几种情况做端口检测以及异常操作检测，检测内容主要为异常端口的扫描检测，当端口未使用是关闭未使用的端口，异常操作主要有含有攻击类型的命令，执行某些异常命令，删除，执行脚本等操作。出现这些问题后调用对应的异常告警模块接口以及自动处理模块接口，以调用对应的模块功能进行异常操作的告警通知以及异常操作的后续处理。

可以理解的是，系统层的检测可以减少服务器被攻击的风险，实现服务器的安全拦截，增加程序的安全性。

302、基于系统层的漏洞检测的进程，调用系统层中与端口信息或操作信息相应的系统功能模块执行系统处理操作。

本实施例中，系统层的漏洞检测的进程为整个系统状态发生变化时进行检测，为应用程序启动前的预判性检测过程，而应用层是当应用程序启动后的实时检测过程，从而实现全方位的云原生场景下的漏洞检测。

系统层中与端口信息即为系统状态改变时需要调用的系统端口，而操作信息即为系统状态改变时需要进行的异常配置，进一步的系统处理操作可以包括告警或修复，以便于应用层对于应用的启动。

303、响应于系统处理操作的执行，对云原生场景中应用层所包含的目标应用进行应用层的漏洞检测。

本实施例中，当应用程序启动时，先进行步骤301中系统层的扫描检测，然后开启应用层面的漏洞拦截和检测，实现层级式的漏洞检测过程，保证了漏洞检测的全面性。

具体的，系统层与应用层发起检测的关系如图5所示，图5为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；图中示出了系统层（整个系统的检测）和应用层（建立在开发者的程序上的拦截和检测），程序启动会进行一次系统层的扫描，紧接着进入应用层，系统层会在整个系统状态发生变化（端口开放或关闭、网络波动、命令执行、程序关闭启动以及定时检测）时进行检测，应用层是当应用程序启动后将实时的检测。

304、基于应用层的漏洞检测的进程检测目标应用的启动，以获取目标应用在启动时对应的运行数据请求。

本实施例中，当应用程序启动后，当运行数据请求（客户端访问服务器）过来时，会先对请求的数据进行检测和拦截。

具体的，获取目标应用对应的运行数据请求的过程为实时进行的过程，即目标应用可以是一个或多个，通过对运行数据请求的拦截，在应用程序进行数据交互之前即可进行漏洞检测，提高了漏洞检测的准确性。

305、将运行数据请求依次输入预设检测模块进行异常项目的检测，以确定异常信息。

本实施例中，异常项目基于预设检测模块指示的漏洞类型设定（例如漏洞类型为SQL注入，则异常项目为用户插入的查询参数等），而异常项目即为相关人员根据历史异常数据进行统计所得的漏洞或具有风险的项目，故预设检测模块基于相关人员的配置确定，例如SSRF和SQL注入，XSS跨域未接入等，具体的模块配置因漏洞类型设定。云原生将应用程序代码解耦成独立模块化单元，从而可以进行本实施例中预设检测模块的配置，不同于程序代码的修改方式，通过模块化的配置可以降低微服务的部属时间与互依性，提高应用的扩展性等。

具体的，在应用层的实时检测如图6所示，图6为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；图中示出了当有HTTP请求（运行数据请求）发起时，首先会进入应用层的检测，可以有两种处理方式，一种是开发者自定义处理，另一种是模块自动处理。其中，当检测到SSRF漏洞时，会指向开发者自定义的处理程序，由开发者决定遇到此漏洞怎么处理；另一种是模块自动处理，SQL注入接入的是应用层检测的自动化处理模块，当检测到SQL注入漏洞时，程序可以自动处理，例如封禁IP，返回错误的信息，告警等。

可以理解的是，由于应用层模块较多，可以开启需要的预设检测模块进行检测，如图6当前开发者只接入的SSRF和SQL注入，XSS跨域未接入，可以根据当前的应用程序进行挑选，减少模块的检测，提高性能。

306、对异常信息中包含的访问参数进行解析得到应用处理操作，以基于应用处理操作进行对应的漏洞处理。

本实施例中，由于云原生场景中应用在服务器侧运行，客户端需要运行应用时需要向服务器侧的云服务器发起数据请求或访问请求，即云原生场景中应用的运行在客户端的体现是通过访问/查询的方式进行的，故可以对异常信息中包含的访问参数进行解析，从而得到针对与漏洞设定的应用处理操作。

根据异常信息确定的不同的漏洞类型，可以执行对应的应用处理操作，具体的模块处理的过程如图7所示，图7为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；图中首先模拟了客户端三种攻击请求，端口扫描，SQL注入，HTTP请求试探，当请求（客户端访问服务器）进入服务器时，首先通过应用层的检测，这里可以选择接入端口异常检测，SQL注入检测和HTTP请求检测这三个模块，如图中所示根据已选择的模块，逐一对请求进行检测拦截，例如SQL注入攻击，进入应用层检测，他会依次进行端口异常检测，SQL注入检测和HTTP请求检测这三个模块拦截，当出现异常后停止检测，如图将SQL注入这个请求交给开发者自定义处理程序（开发者自行过滤，记录请求，记录日志等），进行IP封禁或返回错误，端口扫描也是如此，如图中检测到端口异常则会自动处理，进行告警等操作。如果未见异常，则请求正常进入应用程序。具体的漏洞类型因实际场景而定，此处不做限定。

下面介绍拦截实现，以异常信息指示为SQL注入和SSRF为例。对于SQL注入的场景，由于在编写SQL语句时，如果直接将用户传入的数据作为参数使用字符串拼接的方式插入到SQL查询中，那么攻击者可以通过注入其他语句来执行攻击操作，这些攻击包括可以通过SQL语句做的任何事：获取敏感数据、修改数据、删除数据库表等。故可以通过查询字符串获取用户插入的查询参数，并且不经过任何处理就使用字符串格式化的方法拼接到SQL语句中。以password为例，在这种情况下，如果攻击者输入的参数值为”‘or 1 =1”，即password=’or 1=1 --，那么视图函数中被执行的SQL语句就变成：select * from students wherepassword=’’or 1=1 --;’这时会把students表中所有记录全部查询并返回，也就意味着所有的记录都被攻击者窃取了。更可怕的是，如果攻击者将password参数的值设为”’; droptable users; --”，那么查询语句就会变成：select * from students where password=’’; drop table users; --’这个语句会把students表中所有的记录全部删掉。

具体的，对于SQL注入的处理，可以对异常信息中包含的访问参数进行解析，以确定访问参数中的特殊符号，例如["]特殊符号；然后对特殊符号进行转义以确定对应的应用处理操作；并根据应用处理操作确定说明字符，并将说明字符发送至目标应用进行对应的漏洞处理。

在一些可能的场景中，若需要记录这次攻击的日志信息，本模块将不支持，这种情况下，可以获取异常信息中包含的访问参数所对应的操作记录；然后根据操作记录中指示的异常日志将异常信息发送至目标应用，以使得目标应用对异常信息进行记录，该记录后的异常信息用于对应预设处理模块的定制。即本实施例支持将检测结果和本次请求信息交给应用程序做处理，这样开发者可以做一些定制化开发（记录攻击日志，记录请求信息），提高本实施例模块的灵活性。当请求没有异常，则直接进入开发者的应用程序。

具体的，对于SQL注入的处理过程如图8所示，图8为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；图中示出了当发现客户端请求，以SQL注入为例，开始检测请求，当发现请求中存在特殊符号，例如["]特殊符号，当检测到这些符号以后，开始处理请求，默认是本实施例程序自动处理，将会对特殊符号进行转义（转义字符一般以反斜杠符号\开头，用来说明后面的字符不是字符本身的含义，而是表示其它的含义），例如[\"]表示双引号["]，将这些特殊符号转义以后交给应用程序处理。在一些情况下，例如需要记录这次攻击的日志信息，可以将检测结果和本次请求信息交给应用程序做处理，这样开发者可以做一些定制化开发（记录攻击日志，记录请求信息），提高本实施例模块的灵活性。当请求没有异常，则直接进入开发者的应用程序。

对于漏洞为SSRF的场景，即SSRF服务端请求伪造。由于在服务器访问网页或者HTTP服务的场景，如果接收到的目标URL是解析到内网的，则服务器会尝试访问内网。因此黑客通过提交解析到内网的URL，服务器会帮黑客对内网进行攻击、扫描。例如内网8080端口

接口可以查询对象（用户）信息，当URL传递过来是

，这种情况下，当服务器访问该接口就会拿到name对象（用户）信息。

具体的，对于SSRF的处理，可以首先对异常信息中包含的访问参数进行解析得到指示访问目的的地址信息；然后基于地址信息进行预设地址的匹配，以得到匹配信息；并根据匹配信息中指示的所述地址信息与所述预设地址的关联度确定应用处理操作；从而基于应用处理操作对地址信息进行拦截，以进行对应的漏洞处理。

另外，还可以响应于配置操作获取针对于访问目的配置的目标黑名单；若地址信息为目标黑名单中的地址，则将地址信息替换为预设地址发送至目标应用。具体的，对于漏洞为SSRF的场景的处理流程如图9所示，图9为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；图中示出了针对SSRF，本实施例模块对需要解析的URL进行检测，确保不会解析到内网机器以及禁止访问的信息，首先检测请求信息是否包含127.0.0.1或0:0:0:0:0:0:0:1这类URL，并且本实施例模块支持单独配置域名黑名单，当请求的地址是内网地址或者域名黑名单中的信息，直接替换当前地址（比如替换成baidu.com）返回给应用程序，这样解析就不会出现信息泄露，当开发者需要解析的URL时，可以将检测的请求信息交给开发者自定义的程序进行处理（记录请求解析地址，记录解析次数）。

综合上述实施例，本实施对于运行数据请求的处理流程如图10所示，图10为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图；即首先确定异常信息指示的漏洞类型；若漏洞类型对应的应用处理操作为开发者自定义处理，则将异常信息发送至开发者自定义处理程序，以基于应用处理操作进行对应的漏洞处理。即当有请求（客户端访问服务器），首先进行模块检测，当无异常时正常请求应用程序，当出现异常时，有两种处理方式，第一种，自动处理，交给模块去处理，处理完成继续请求应用程序，第二种，当模块满足不了开发者需求时，将检测异常的请求交给开发者自定义处理程序，由开发者去处理当前的异常请求，例如SQL注入，开发者可以自行转义，然后记录日志，将处理完成的请求交给引用程序，或者直接返回错误，不进行请求。

另外，对于自定义的过程，还可以响应于开发者自定义处理程序的执行，获取执行过程中的日志信息；然后将日志信息与异常信息进行关联，以得到关联信息；从而基于关联信息对预设处理模块进行更新，以执行漏洞检测过程中预设处理模块的调用，以实现自定义过程的快速处理提升漏洞处理的效率。

以上举了两个常见漏洞，均由本实施例程序做请求过滤拦截，拦截以后将结果返回给应用程序，当开发者需要请求信息时可以交给开发者自定义的程序进行处理，满足开发者的定制化需求（记录日志，记录请求信息）。

本实施例可以进行实时的管理，实现自动化，将漏洞检测技术应用到系统底层，不在依赖于应用程序，也可以在本程序需要更新时做到在线更新，提高本发明的安全性和可用性。

另外，应用层模块化漏洞检测可以让开发者选择使用，做到开发者选择性的定制开发，应用层可以对开发者的程序增加上层（最外层的安全防护）拦截，开发者将安全问题交给本实施例程序即可，开发者将更多的时间花在业务逻辑，当开发者需要知道某个漏洞时，本实施例将检测结果交给自定义程序去记录日志或者自行处理漏洞，从而减少开发量。而系统层的检测可以减少服务器被攻击的风险，实现服务器的安全拦截，增加程序的安全性。

结合上述实施例可知，通过响应于云原生场景中系统状态的变化，在系统层进行漏洞检测并调用相应的系统功能模块执行系统处理操作；然后基于系统处理操作的执行，对云原生场景中的应用层进行检测；进而响应于在应用层中检测到目标应用的启动，获取目标应用对应的运行数据请求；然后基于预设检测模块依次对运行数据请求进行漏洞检测，以确定异常信息；进而根据异常信息确定对应的应用处理操作，以基于应用处理操作进行对应的漏洞处理。从而实现系统层与应用层的全方位漏洞检测过程，由于采用系统层的端口检测过程，提高了服务器维度的安全性，并结合应用层采用实时的运行数据请求进行漏洞检测，在接入应用数据前即可得到相应的异常信息，提高了漏洞检测的准确性。

在一种可能的场景中，本实施例中的预设检测模块可以是进行动态配置所得的，下面结合图11进行说明，图11为本申请实施例提供的另一种基于云原生的多场景漏洞检测方法的流程示意图，图中示出了如下步骤：

1101、响应于云原生场景中系统状态的变化，对系统层基于系统状态的变化所对应的端口信息或操作信息进行系统层的漏洞检测。

本实施例中，系统状态的变化包括端口信息，即端口开放或关闭（服务器端口）、网络波动（网络断开）；以及操作信息，即操作命令执行（应用程序执行命令）、程序关闭启动以及定时检测(定时对端口以及异常操作的定时检测)等情况，具体的变化情况因实际场景而定。

1102、基于系统层的漏洞检测的进程，调用系统层中与端口信息或操作信息相应的系统功能模块执行系统处理操作。

本实施例中，系统层中的系统功能模块基于示例漏洞在系统层中的展示形式而定，在系统维度的漏洞检测中，具有预判性检测的特点，即对于系统状态变化的操作进行预判。

1103、响应于系统处理操作的执行，对云原生场景中应用层所包含的目标应用进行应用层的漏洞检测。

本实施例中，结合云原生场景的系统架构，系统层是从整个系统的维度进行检测，而应用层是建立在开发者的程序维度上的拦截和检测过程。

具体的，程序启动会进行一次系统层的扫描，紧接着进入应用层，系统层会在整个系统状态发生变化（端口开放或关闭、网络波动、命令执行、程序关闭启动以及定时检测）时进行检测，应用层是当应用程序启动后将实时的检测。

1104、基于应用层的漏洞检测的进程检测目标应用的启动，以获取目标应用在启动时对应的运行数据请求。

本实施例中，获取目标应用对应的运行数据请求的过程为实时进行的过程，即目标应用可以是一个或多个，通过对运行数据请求的拦截，在应用程序进行数据交互之前即可进行漏洞检测，提高了漏洞检测的准确性。

1105、对应用层配置的检测模块库进行异常项目的适配，以确定预设检测模块。

本实施例中，检测模块库可以是由收集到的漏洞类型进行配置的，例如SQL注入；XSS跨站点脚本；跨目录访问；缓冲区溢出；cookies修改；HTTP方法篡改；CSRF；SSRF；CRLF；命令行注入等进行针对性配置所得的检测模块集合。

具体的，对于预设检测模块的确定可以是由上述示例的检测模块集合筛选所得，这是由于不同的应用可能出现的漏洞不同，通过减少逐次输入预设检测模块的数量，可以提高漏洞检测效率。即首先对应用层中配置的检测模块库进行遍历，以确定检测模块库中异常项目适配于运行数据请求的多个预设检测模块；然后将运行数据请求依次输入多个预设检测模块进行异常项目的检测，以确定异常信息。例如运行数据请求为单一站点的数据请求，则在预设检测模块的确定时可以除去XSS跨站点脚本、跨目录访问等涉及多站点交互的漏洞类型，从而提高漏洞检测效率。

可选的，在预设检测模块的确定过程中，还可以对各个模块的使用次数（检测次数）进行统计；即对异常项目对应的检测次数进行统计，以得到异常项目对应的检测分布信息，例如SQL注入10次、SSRF发生5次、CRLF发生3次；然后基于检测分布信息对预设检测模块进行排序，以确定执行次序，例如选取次数降序排序中次序的前3个作为预设检测模块；进而根据执行次序将运行数据请求依次输入多个预设检测模块进行异常项目的检测，以确定异常信息，从而在保证检测准确性的同时，提高漏洞检测的效率。

1106、获取目标应用对应的画像信息。

本实施例中，基于步骤1105的描述，在确定目标应用可能出现的漏洞时，可以是通过目标应用对应的画像信息进行的；具体的，可以首先获取运行数据请求指示的目标应用所对应的画像信息，该画像信息可以包括目标应用的类型、数据交互的方式、应用的运行逻辑等；然后根据画像信息确定异常项目的范围分布参数，例如数据交互的方式确定异常项目的范围分布参数为多对象交互，交互范围为同一云集群中的对象；进而基于范围分布参数对应用层中配置的检测模块库进行遍历，以确定检测模块库中异常项目适配于范围分布参数的多个预设检测模块，例如范围分布参数指示交互范围为同一云集群中的对象时，确定预设检测模块包括XSS跨站点脚本，从而提高预设检测模块选择的针对性。

1107、响应于检测模块库的调用发起负载检测。

本实施例中，考虑到云原生场景的性能，还可以在系统层进行负载检测，该负载检测可以是在系统层周期性发起的，在检测模块库的调用时获取最近周期检测所得的负载信息；还可以是即时发起的检测进程；在系统层进行负载检测后，即可基于应用层执行负载检测操作，以获取云原生场景的负载信息；然后根据负载信息对预设检测模块的数量进行限制，以得到负载检测数量；并基于负载检测数量对预设检测模块进行筛选，以确定排序检测模块，例如负载信息指示可负载的预设检测模块为10个，则排序检测模块即为10个；进而基于步骤1105中的检测分布信息对排序检测模块进行排序，以确定执行次序，从而保证云原生场景中云服务运行的稳定性。

1108、基于目标应用对应的目标集群进行关联应用的确定。

本实施例中，在云原生场景中，应用可以是基于容器进行运行的，即容器是与系统其他部分隔开的一系列进程。运行这些进程所需的所有文件都由一个镜像提供，从开发到测试再到生产的整个过程中，容器都具有可移植性和一致性，从而使得云原生场景可以提供与多个应用的扩展部署。进一步的，容器以集群的形式进行划分，对于同一集群中的容器，可能具有相似的特性。故在本实施例中，可以首先确定目标应用在云原生场景中所处的目标集群；然后对目标集群中的应用对象进行解析（应用类型、交互方式、端口调用等形式匹配），以确定与目标应用具有相似访问特征的关联应用；进而获取关联应用在应用层中配置的关联处理模块；故可以基于关联处理模块进行功能复制，以对预设处理模块进行更新，从而提高预设处理模块的确定效率。

1109、对关联应用配置的关联检测模块进行功能复制，以对预设检测模块进行更新。

本实施例中，对于基于集群的功能的调用复制过程，可以是实时检测的，即在云原生场景中存在集群之间关联性的心跳检测，从而保持集群之间的联系，在需要进行关联检测模块的确定时进行关联调用即可，

1110、将运行数据请求依次输入预设检测模块进行异常项目的检测，以确定异常信息，异常项目基于预设检测模块指示的漏洞类型设定。

本实施例中，异常项目基于预设检测模块指示的漏洞类型设定（例如漏洞类型为SQL注入，则异常项目为用户插入的查询参数等），而异常项目即为相关人员根据历史异常数据进行统计所得的漏洞或具有风险的项目，故预设检测模块基于相关人员的配置确定，例如SSRF和SQL注入，XSS跨域未接入等，具体的模块配置因漏洞类型设定。云原生将应用程序代码解耦成独立模块化单元，从而可以进行本实施例中预设检测模块的配置，不同于程序代码的修改方式，通过模块化的配置可以降低微服务的部属时间与互依性，提高应用的扩展性等。

具体的确定异常信息得示例参见图3中步骤305的描述，此处不做赘述。

1111、对异常信息中包含的访问参数进行解析得到应用处理操作，以基于应用处理操作进行对应的漏洞处理。

本实施例中，由于云原生场景中应用在服务器侧运行，客户端需要运行应用时需要向服务器侧的云服务器发起数据请求或访问请求，即云原生场景中应用的运行在客户端的体现是通过访问/查询的方式进行的，故可以对异常信息中包含的访问参数进行解析，从而得到针对与漏洞设定的应用处理操作。

可见，通过对预设检测模块进行针对性的配置可以在保证漏洞检测的准确性的同时，提高漏洞检测的效率，且动态的预设检测模块过程可以供开发者接入和定制开发，做一层实时检测防护，增加了程序的安全性。且能快速地发现更多的WEB安全漏洞问题；能覆盖黑盒测试的安全漏洞范围，并发现更多的深层次WEB安全问题；能降低白盒测试中高成本的问题；能准确定位漏洞代码的具体位置；可以保证检测过程中更低的漏报率和误报率。

为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关装置。请参阅图12，图12为本申请实施例提供的一种基于云原生的多场景漏洞检测装置的结构示意图，漏洞的检测装置1200包括：

检测单元1201，用于响应于云原生场景中系统状态的变化，对系统层基于所述系统状态的变化所对应的端口信息或操作信息进行系统层的漏洞检测；

调用单元1202，用于基于所述系统层的漏洞检测的进程，调用所述系统层中与所述端口信息或所述操作信息相应的系统功能模块执行系统处理操作；

所述检测单元1201，还用于响应于所述系统处理操作的执行，对所述云原生场景中应用层所包含的目标应用进行应用层的漏洞检测；

获取单元1203，用于基于所述应用层的漏洞检测的进程检测所述目标应用的启动，以获取所述目标应用在启动时对应的运行数据请求；

所述检测单元1201，还用于将所述运行数据请求依次输入预设检测模块进行异常项目的检测，以确定异常信息，所述异常项目基于所述预设检测模块指示的漏洞类型设定；

所述检测单元1201，还用于对所述异常信息中包含的访问参数进行解析得到应用处理操作，以基于所述应用处理操作进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述检测单元1201，具体用于对所述异常信息中包含的访问参数进行解析，以确定所述访问参数中的特殊符号；

所述检测单元1201，具体用于对所述特殊符号进行转义以确定对应的所述应用处理操作；

所述检测单元1201，具体用于根据所述应用处理操作确定说明字符，并将所述说明字符发送至所述目标应用进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述检测单元1201，具体用于获取所述异常信息中包含的访问参数所对应的操作记录；

所述检测单元1201，具体用于根据所述操作记录中指示的异常日志将所述异常信息发送至所述目标应用，以使得所述目标应用对所述异常信息进行记录，记录后的所述异常信息用于对应预设处理模块的定制。

可选的，在本申请一些可能的实现方式中，所述检测单元1201，具体用于对所述异常信息中包含的访问参数进行解析得到指示访问目的的地址信息；

所述检测单元1201，具体用于基于所述地址信息进行预设地址的匹配，以得到匹配信息；

所述检测单元1201，具体用于根据所述匹配信息中指示的所述地址信息与所述预设地址的关联度确定所述应用处理操作；

所述检测单元1201，具体用于基于所述应用处理操作对所述地址信息进行拦截，以进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述检测单元1201，具体用于响应于配置操作获取针对于访问目的配置的目标黑名单；

所述检测单元1201，具体用于若所述地址信息为所述目标黑名单中的地址，则将所述地址信息替换为预设地址发送至所述目标应用。

可选的，在本申请一些可能的实现方式中，所述检测单元1201，具体用于对所述异常信息中包含的访问参数进行解析，以确定所述异常信息指示的漏洞类型；

所述检测单元1201，具体用于若所述漏洞类型对应的应用处理操作为开发者自定义处理，则将所述异常信息发送至开发者自定义处理程序，以基于所述应用处理操作进行对应的漏洞处理。

可选的，在本申请一些可能的实现方式中，所述检测单元1201，具体用于响应于所述开发者自定义处理程序的执行，获取执行过程中的日志信息；

所述检测单元1201，具体用于将所述日志信息与所述异常信息进行关联，以得到关联信息；

所述检测单元1201，具体用于基于所述关联信息对预设处理模块进行更新，以执行漏洞检测过程中所述预设处理模块的调用。

可选的，在本申请一些可能的实现方式中，所述检测单元1201，具体用于对所述应用层中配置的检测模块库进行遍历，以确定所述检测模块库中异常项目适配于所述运行数据请求的多个所述预设检测模块；

所述检测单元1201，具体用于将所述运行数据请求依次输入多个所述预设检测模块进行异常项目的检测，以确定所述异常信息。

可选的，在本申请一些可能的实现方式中，所述检测单元1201，具体用于对所述异常项目对应的检测次数进行统计，以得到所述异常项目对应的检测分布信息；

所述检测单元1201，具体用于基于所述检测分布信息对所述预设检测模块进行排序，以确定执行次序；

所述检测单元1201，具体用于根据所述执行次序将所述运行数据请求依次输入多个所述预设检测模块进行异常项目的检测，以确定所述异常信息。

可选的，在本申请一些可能的实现方式中，所述检测单元1201，具体用于基于所述应用层执行负载检测操作，以获取云原生场景的负载信息；

所述检测单元1201，具体用于根据所述负载信息对所述预设检测模块的数量进行限制，以得到负载检测数量；

所述检测单元1201，具体用于基于所述负载检测数量对所述预设检测模块进行筛选，以确定排序检测模块；

所述检测单元1201，具体用于基于所述检测分布信息对所述排序检测模块进行排序，以确定所述执行次序。

可选的，在本申请一些可能的实现方式中，所述检测单元1201，具体用于获取所述运行数据请求指示的目标应用所对应的画像信息；

所述检测单元1201，具体用于根据所述画像信息确定异常项目的范围分布参数；

所述检测单元1201，具体用于基于所述范围分布参数对所述应用层中配置的检测模块库进行遍历，以确定所述检测模块库中异常项目适配于所述范围分布参数的多个所述预设检测模块。

可选的，在本申请一些可能的实现方式中，所述检测单元1201，具体用于确定所述目标应用在所述云原生场景中所处的目标集群；

所述检测单元1201，具体用于对所述目标集群中的应用对象进行解析，以确定与所述目标应用具有相似访问特征的关联应用；

所述检测单元1201，具体用于获取所述关联应用在所述应用层中配置的关联处理模块；

所述检测单元1201，具体用于基于所述关联处理模块进行功能复制，以对所述预设处理模块进行更新。

通过响应于云原生场景中系统状态的变化，在系统层进行漏洞检测并调用相应的系统功能模块执行系统处理操作；然后基于系统处理操作的执行，对云原生场景中的应用层进行检测；进而响应于在应用层中检测到目标应用的启动，获取目标应用对应的运行数据请求；然后基于预设检测模块依次对运行数据请求进行漏洞检测，以确定异常信息；进而根据异常信息确定对应的应用处理操作，以基于应用处理操作进行对应的漏洞处理。从而实现系统层与应用层的全方位漏洞检测过程，由于采用系统层的端口检测过程，提高了服务器维度的安全性，并结合应用层采用实时的运行数据请求进行漏洞检测，在接入应用数据前即可得到相应的异常信息，提高了漏洞检测的准确性。

本申请实施例还提供了一种终端设备，如图13所示，是本申请实施例提供的另一种终端设备的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该终端可以为包括手机、平板电脑、个人数字助理（personal digital assistant，PDA）、销售终端（point of sales，POS）、车载电脑等任意终端设备，以终端为手机为例：

图13示出的是与本申请实施例提供的终端相关的手机的部分结构的框图。参考图13，手机包括：射频（radio frequency，RF）电路1310、存储器1320、输入单元1330、显示单元1340、传感器1350、音频电路1360、无线保真（wireless fidelity，WiFi）模块1370、处理器1380、以及电源1390等部件。本领域技术人员可以理解，图13中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图13对手机的各个构成部件进行具体的介绍：

RF电路1310可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1380处理；另外，将设计上行的数据发送给基站。通常，RF电路1310包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器（low noiseamplifier，LNA）、双工器等。此外，RF电路1310还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统（globalsystem of mobile communication，GSM）、通用分组无线服务（general packet radioservice，GPRS）、码分多址（code division multiple access，CDMA）、宽带码分多址（wideband code division multiple access, WCDMA）、长期演进（long term evolution，LTE）、电子邮件、短消息服务（short messaging service，SMS）等。

存储器1320可用于存储软件程序以及模块，处理器1380通过运行存储在存储器1320的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1320可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序（比如声音播放功能、图像播放功能等）等；存储数据区可存储根据手机的使用所创建的数据（比如音频数据、电话本等）等。此外，存储器1320可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1330可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1330可包括触控面板1331以及其他输入设备1332。触控面板1331，也称为触摸屏，可收集用户在其上或附近的触摸操作（比如用户使用手指、触笔等任何适合的物体或附件在触控面板1331上或在触控面板1331附近的操作，以及在触控面板1331上一定范围内的隔空触控操作），并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1331可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1380，并能接收处理器1380发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1331。除了触控面板1331，输入单元1330还可以包括其他输入设备1332。具体地，其他输入设备1332可以包括但不限于物理键盘、功能键（比如音量控制按键、开关按键等）、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1340可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1340可包括显示面板1341，可选的，可以采用液晶显示器（liquidcrystal display，LCD）、有机发光二极管（organic light-emitting diode，OLED）等形式来配置显示面板1341。进一步的，触控面板1331可覆盖显示面板1341，当触控面板1331检测到在其上或附近的触摸操作后，传送给处理器1380以确定触摸事件的类型，随后处理器1380根据触摸事件的类型在显示面板1341上提供相应的视觉输出。虽然在图13中，触控面板1331与显示面板1341是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1331与显示面板1341集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器1350，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1341的亮度，接近传感器可在手机移动到耳边时，关闭显示面板1341和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上（一般为三轴）加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用（比如横竖屏切换、相关游戏、磁力计姿态校准）、振动识别相关功能（比如计步器、敲击）等; 至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1360、扬声器1361，传声器1362可提供用户与手机之间的音频接口。音频电路1360可将接收到的音频数据转换后的电信号，传输到扬声器1361，由扬声器1361转换为声音信号输出；另一方面，传声器1362将收集的声音信号转换为电信号，由音频电路1360接收后转换为音频数据，再将音频数据输出处理器1380处理后，经RF电路1310以发送给比如另一手机，或者将音频数据输出至存储器1320以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块1370可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图13示出了WiFi模块1370，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器1380是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1320内的软件程序和/或模块，以及调用存储在存储器1320内的数据，执行手机的各种功能和处理数据，从而对手机进行整体检测。可选的，处理器1380可包括一个或多个处理单元；可选的，处理器1380可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1380中。

手机还包括给各个部件供电的电源1390（比如电池），可选的，电源可以通过电源管理系统与处理器1380逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本申请实施例中，该终端所包括的处理器1380还具有执行如上述页面处理方法的各个步骤的功能。

本申请实施例还提供了一种服务器，请参阅图14，图14是本申请实施例提供的一种服务器的结构示意图，该服务器1400可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器（central processing units，CPU）1422（例如，一个或一个以上处理器）和存储器1432，一个或一个以上存储应用程序1442或数据1444的存储介质1430（例如一个或一个以上海量存储设备）。其中，存储器1432和存储介质1430可以是短暂存储或持久存储。存储在存储介质1430的程序可以包括一个或一个以上模块（图示没标出），每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1422可以设置为与存储介质1430通信，在服务器1400上执行存储介质1430中的一系列指令操作。

服务器1400还可以包括一个或一个以上电源1426，一个或一个以上有线或无线网络接口1450，一个或一个以上输入输出接口1458，和/或，一个或一个以上操作系统1441，例如Windows ServerTM，Mac OS XTM，UnixTM, LinuxTM，FreeBSDTM等等。

上述实施例中由管理装置所执行的步骤可以基于该图14所示的服务器结构。

本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有漏洞的处理指令，当其在计算机上运行时，使得计算机执行如前述图3至图11所示实施例描述的方法中漏洞的处理装置所执行的步骤。

本申请实施例中还提供一种包括漏洞的处理指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如前述图3至图11所示实施例描述的方法中漏洞的处理装置所执行的步骤。

本申请实施例还提供了一种基于云原生的多场景漏洞检测系统，所述漏洞的处理系统可以包含图12所描述实施例中的漏洞的处理装置，或图13所描述实施例中的终端设备，或者图14所描述的服务器。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，漏洞的处理装置，或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（read-onlymemory，ROM）、随机存取存储器（random access memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (15)

1.一种基于云原生的多场景漏洞检测方法，其特征在于，包括：

响应于云原生场景中系统状态的变化，对系统层基于所述系统状态的变化所对应的端口信息或操作信息进行系统层的漏洞检测；

基于所述系统层的漏洞检测的进程，调用所述系统层中与所述端口信息或所述操作信息相应的系统功能模块执行系统处理操作；

响应于所述系统处理操作的执行，对所述云原生场景中应用层所包含的目标应用进行应用层的漏洞检测；

基于所述应用层的漏洞检测的进程检测所述目标应用的启动，以获取所述目标应用在启动时对应的运行数据请求；

将所述运行数据请求依次输入预设检测模块进行异常项目的检测，以确定异常信息，所述异常项目基于所述预设检测模块指示的漏洞类型设定；

对所述异常信息中包含的访问参数进行解析得到应用处理操作，以基于所述应用处理操作进行对应的漏洞处理。

2.根据权利要求1所述的方法，其特征在于，所述对所述异常信息中包含的访问参数进行解析得到应用处理操作，以基于所述应用处理操作进行对应的漏洞处理，包括：

对所述异常信息中包含的访问参数进行解析，以确定所述访问参数中的特殊符号；

对所述特殊符号进行转义以确定对应的所述应用处理操作；

根据所述应用处理操作确定说明字符，并将所述说明字符发送至所述目标应用进行对应的漏洞处理。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

获取所述异常信息中包含的访问参数所对应的操作记录；

根据所述操作记录中指示的异常日志将所述异常信息发送至所述目标应用，以使得所述目标应用对所述异常信息进行记录，记录后的所述异常信息用于对应预设处理模块的定制。

4.根据权利要求1所述的方法，其特征在于，所述对所述异常信息中包含的访问参数进行解析得到应用处理操作，以基于所述应用处理操作进行对应的漏洞处理，包括：

对所述异常信息中包含的访问参数进行解析得到指示访问目的的地址信息；

基于所述地址信息进行预设地址的匹配，以得到匹配信息；

根据所述匹配信息中指示的所述地址信息与所述预设地址的关联度确定所述应用处理操作；

基于所述应用处理操作对所述地址信息进行拦截，以进行对应的漏洞处理。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

响应于配置操作获取针对于访问目的配置的目标黑名单；

若所述地址信息为所述目标黑名单中的地址，则将所述地址信息替换为预设地址发送至所述目标应用。

6.根据权利要求1所述的方法，其特征在于，所述对所述异常信息中包含的访问参数进行解析得到应用处理操作，以基于所述应用处理操作进行对应的漏洞处理，包括：

对所述异常信息中包含的访问参数进行解析，以确定所述异常信息指示的漏洞类型；

若所述漏洞类型对应的应用处理操作为开发者自定义处理，则将所述异常信息发送至开发者自定义处理程序，以基于所述应用处理操作进行对应的漏洞处理。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

响应于所述开发者自定义处理程序的执行，获取执行过程中的日志信息；

将所述日志信息与所述异常信息进行关联，以得到关联信息；

基于所述关联信息对预设处理模块进行更新，以执行漏洞检测过程中所述预设处理模块的调用。

8.根据权利要求1所述的方法，其特征在于，所述将所述运行数据请求依次输入预设检测模块进行异常项目的检测，以确定异常信息，包括：

对所述应用层中配置的检测模块库进行遍历，以确定所述检测模块库中异常项目适配于所述运行数据请求的多个所述预设检测模块；

将所述运行数据请求依次输入多个所述预设检测模块进行异常项目的检测，以确定所述异常信息。

9.根据权利要求8所述的方法，其特征在于，所述将所述运行数据请求依次输入多个所述预设检测模块进行异常项目的检测，以确定所述异常信息，包括：

对所述异常项目对应的检测次数进行统计，以得到所述异常项目对应的检测分布信息；

基于所述检测分布信息对所述预设检测模块进行排序，以确定执行次序；

根据所述执行次序将所述运行数据请求依次输入多个所述预设检测模块进行异常项目的检测，以确定所述异常信息。

10.根据权利要求9所述的方法，其特征在于，所述基于所述检测分布信息对所述预设检测模块进行排序，以确定执行次序，包括：

基于所述应用层执行负载检测操作，以获取云原生场景的负载信息；

根据所述负载信息对所述预设检测模块的数量进行限制，以得到负载检测数量；

基于所述负载检测数量对所述预设检测模块进行筛选，以确定排序检测模块；

基于所述检测分布信息对所述排序检测模块进行排序，以确定所述执行次序。

11.根据权利要求8所述的方法，其特征在于，所述对所述应用层中配置的检测模块库进行遍历，以确定所述检测模块库中异常项目适配于所述运行数据请求的多个所述预设检测模块，包括：

获取所述运行数据请求指示的目标应用所对应的画像信息；

根据所述画像信息确定异常项目的范围分布参数；

基于所述范围分布参数对所述应用层中配置的检测模块库进行遍历，以确定所述检测模块库中异常项目适配于所述范围分布参数的多个所述预设检测模块。

12.根据权利要求1-11任一项所述的方法，其特征在于，所述方法还包括：

确定所述目标应用在所述云原生场景中所处的目标集群；

对所述目标集群中的应用对象进行解析，以确定与所述目标应用具有相似访问特征的关联应用；

获取所述关联应用在所述应用层中配置的关联处理模块；

基于所述关联处理模块进行功能复制，以对预设处理模块进行更新。

13.一种基于云原生的多场景漏洞检测装置，其特征在于，包括：

检测单元，用于响应于云原生场景中系统状态的变化，对系统层基于所述系统状态的变化所对应的端口信息或操作信息进行系统层的漏洞检测；

调用单元，用于基于所述系统层的漏洞检测的进程，调用所述系统层中与所述端口信息或所述操作信息相应的系统功能模块执行系统处理操作；

所述检测单元，还用于响应于所述系统处理操作的执行，对所述云原生场景中应用层所包含的目标应用进行应用层的漏洞检测；

获取单元，用于基于所述应用层的漏洞检测的进程检测所述目标应用的启动，以获取所述目标应用在启动时对应的运行数据请求；

所述检测单元，还用于将所述运行数据请求依次输入预设检测模块进行异常项目的检测，以确定异常信息，所述异常项目基于所述预设检测模块指示的漏洞类型设定；

所述检测单元，还用于对所述异常信息中包含的访问参数进行解析得到应用处理操作，以基于所述应用处理操作进行对应的漏洞处理。

14.一种计算机设备，其特征在于，所述计算机设备包括处理器以及存储器：

所述存储器用于存储程序代码；所述处理器用于根据所述程序代码中的指令执行权利要求1至12任一项所述的基于云原生的多场景漏洞检测方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行权利要求1至12任一项所述的基于云原生的多场景漏洞检测方法。

Images