一种安全要素的治理方法

摘要

本申请涉及网络安全领域，具体涉及一种安全要素的治理方法。所述方法可以包括，获取网络报文；提取所述网络报文中与风险检测相关的预设维度的报文信息；将所述报文信息转化为预设格式的安全要素，并对所述安全要素进行组装，得到安全要素组合；基于与所述预设格式对应的检测规则，对所述安全要素组合进行网络安全风险检测。由此可以形成格式统一的安全要素组合，然后在风险检测场景中，可以基于与所述预设格式对应的检测规则完成风险检测，针对性强，检测效率高，检测性能强。

说明书

技术领域

本申请涉及网络安全领域，具体涉及一种安全要素的治理方法。

背景技术

随着互联网的发展，互联网应用越来越广泛。同时这些互联网应用越来越容易遭受网络安全威胁。

互联网应用遭受到攻击可能导致数据泄露引发一系列问题。可见，如何进行网络安全风险检测是很有必要的。

发明内容

有鉴于此，本申请公开一种安全要素的治理方法。所述方法可以包括：获取网络报文；提取所述网络报文中与风险检测相关的预设维度的报文信息；将所述报文信息转化为预设格式的安全要素，并对所述安全要素进行组装，得到安全要素组合。

在一些实施例中，所述将所述报文信息转化为预设格式的安全要素，包括以下至少一项：将所述网络报文包括的访问路径与所述网络报文包括的报文头中的第一预设字段的字段内容进行组合，得到第一安全要素；将所述报文头中的第二预设字段确定为第一参数，将所述第二预设字段对应的第二字段内容确定为与所述第一参数对应的第一参数值，以及将所述第一参数和所述第一参数值的组合确定为第二安全要素；在所述网络报文包括报文体的情形下，在所述报文体中识别第二参数，和与所述第二参数对应的第二参数值，将所述第二参数和所述第二参数值的组合确定为第三安全要素。

在一些实施例中，所述预设维度的报文信息包括用户自定义的第三预设字段的字段内容；所述第三预设字段包括以下至少一项：攻击结果字段；API标识字段；请求方法字段；文件上传的中Content-Disposition和/或Content-Type字段；文件头；文件尾；文件主体的首行；文件主体的末尾；安全要素组合的UUID。

在一些实施例中，所述在所述报文体中识别第二参数，和与所述第二参数对应的第二参数值，包括：调用与所述报文体的数据格式对应的库文件，识别所述报文体中的属性名和属性值；在识别到任意属性值以及和所述任意属性值对应的任意属性名的情形下，根据所述任意属性名确定所述第二参数，根据所述任意属性值确定所述第二参数值；在识别到任意属性值并且未识别到与所述任意属性值对应的任意属性名的情形下，根据预设属性名确定所述第二参数，根据所述任意属性值确定所述第二参数值。

在一些实施例中，在所述报文体的数据格式为JSON的情形下，所述根据所述任意属性名确定所述第二参数，包括：在所述任意属性名具备第一形式的多层嵌套的情形下，通过第一预设符号将所述任意属性名中不同层级的元素连接起来，生成格式统一的所述第二参数；在所述任意属性名具备第二形式的多层嵌套的情形下，通过第二预设符号将所述任意属性名中不同层级的元素连接起来，并且在末尾层级的元素后添加第三预设符号，生成格式统一的所述任意第二参数。

在一些实施例中，在所述报文体的数据格式为XML的情形下，所述根据预设属性名确定所述第二参数，包括：在所述任意属性值为请求方法属性值的情形下，获取第一预设属性名，将所述第一预设属性名确定为所述第二参数；在所述任意属性值为参数属性值的情形下，获取第二预设属性名，根据所述参数属性值的顺序，确定所述第二预设属性名的编号，以及将所述第二预设属性名与所述编号的组合，确定为所述第二参数。

在一些实施例中，所述将所述第一参数和所述第一参数值的组合确定为第二安全要素，包括：通过第一预设连接符，连接所述第一参数和与所述第一参数值，得到第二安全要素；所述将所述第二参数和所述第二参数值的组合确定为第三安全要素，包括：通过第二预设连接符，连接所述第二参数和与所述第二参数值，得到第三安全要素；所述对所述安全要素进行组装，得到安全要素组合，包括：通过第三预设连接符，在所述第一安全要素之后拼接所述第二安全要素；通过第四预设连接符，在所述第二安全要素之后连接所述第三安全要素，得到安全要素组合。

在一些实施例中，在将所述第二参数和所述第二参数值的组合确定为第三安全要素之后，所述方法还包括：对所述第三安全要素进行递归解码；其中，所述对所述第三安全要素进行递归解码，包括递归执行以下步骤，直到所述第三安全要素与预设的至少一个编码类型均不匹配：判断所述第三安全要素与预设的至少一个编码类型是否匹配；在所述第三安全要素与所述至少一个编码类型中的目标编码类型匹配的情形下，利用与所述目标编码类型对应的解码库对所述第三安全要素进行解码；在所述第三安全要素与至少两种编码类型匹配的情形下，分别利用所述至少两种编码类型中的每一种编码类型所对应的解码库对所述第三安全要素进行解码。

在一些实施例中，所述判断所述第三安全要素与预设的至少一个编码类型是否匹配，包括：获取与至少一个编码类型分别对应的正则表达式；将所述第三安全要素与每一所述正则表达式进行匹配；响应于所述第三安全要素只与任一目标正则表达式匹配，确定所述第三安全要素与所述目标正则表达式对应的目标编码类型匹配；响应于所述第三安全要素与至少两个正则表达式匹配，确定所述第三安全要素与所述至少两个正则表达式对应的至少两种编码类型匹配。

在一些实施例中，所述检测模型包括基于人工智能生成的网络安全风险检测模型；在得到安全要素组合之后，所述方法还包括：基于所述安全要素组合以及所述安全要素组合对应的风险标签，构建训练样本；所述训练样本用于对所述网络安全风险检测模型进行训练。

前述实施例记载的方案中，可以根据与风险检测相关的预设维度，从网络报文中检测出与风险检测相关的报文信息，然后对报文信息转换为预设格式的安全要素进行组装，不论原本报文的数据格式如何，均可形成格式统一的安全要素组合。在风险检测场景中可以基于与所述预设格式对应的检测规则完成风险检测。

由此，第一，有针对性的对报文中与风险检测相关的安全要素进行检测，针对性强，检测效率高，检测性能强。

第二，只需存储安全要素组合即可，无需存储全部报文，降低存储所需的空间、容量，减少了不必要的设备成本开支。

第三，不论原本报文的数据格式如何，均可形成格式统一的安全要素组合，然后可以基于与所述预设格式对应的检测规则完成风险检测，从而使用统一格式的进行规则检测，提高检测效率，降低规则维护成本。

第四，可以提前与风险检测相关的安全要素，并且预设格式的安全要素进行组装，形成格式统一的安全要素组合，将孤立的数据连接在了一起，在基于安全要素组合进行风险检测的时候，可以考虑到安全要素之间的关联关系，实现关联分析，有助于提升风险检测效果。

附图说明

下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍。

图1为本申请实施例示出的一种安全要素的治理方法的流程示意图。

图2为本申请示出的一种确定第二参数和第二参数值的方法流程示意图。

图3为本申请示出的针对URL编码的请求体的识别示意图。

图4为本申请示出的安全要素拼接示意图。

图5为拼装得到的安全要素组合的示意图。

图6为本申请示出的一种参数识别结果示意图。

图7为本申请示出的一种参数识别结果示意图。

图8为本申请示出的一种参数识别结果示意图。

图9为本申请示出的一种递归解码的流程示意图。

图10为本申请示出的第三安全要素与编码类型进行匹配的流程示意图。

图11为本申请示意的一种安全要素的治理系统的结构示意图。

图12为本申请示出的安全要素治理流程示意图。

具体实施方式

下面将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的设备和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在可以包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。还应当理解，本文中所使用的词语“如果”，取决于语境，可以被解释成为“在……时”或“当……时”或“响应于确定”。

在一些相关技术中，可以采用的全流量包存储、全文检索方式进行网络安全风险检测。比如，可以通过suricata、snort、YARA等规则引擎对完整的流量包逐一进行检测及存储，从而完成风险检测。

Suricata是一种开源入侵检测系统（IDS），它使用网络流量检测来发现潜在的网络威胁。Snort：Snort与Suricata类似，均是开源入侵检测系统，并且Snort2的规则可以用于Suricata的任意版本中。YARA是一种静态分析工具，用于检测和识别文件中的恶意软件。

相关技术中至少具有如下缺陷：

第一，检测效率低，检测性能差。

第二，对全文进行存储耗费巨大的空间、容量，造成了不必要的设备成本开支。

第三，报文数据格式多种多样，但是安全设备一般使用通用的网络安全风险检测规则，由此可能降低风险检出率；针对每种格式编写定制的风险检测规则，会增加检测规则的数量、占用更多的服务资源，并且占用人力，维护也比较繁琐困难；

第四，指示保留了原始的数据，这些数据相互孤立，并未形成关联，导致无法通过以上数据建立关联分析。

有鉴于此，本申请提出了一种安全要素的治理方法（可以简称为治理方法）。该方法中，可以根据与风险检测相关的预设维度，从网络报文中检测出与风险检测相关的报文信息，然后对报文信息转换为预设格式的安全要素进行组装，不论原本报文的数据格式如何，均可形成格式统一的安全要素组合，然后在风险检测场景中可以基于与所述预设格式对应的检测规则完成风险检测。

由此，第一，有针对性的对报文中与风险检测相关的安全要素进行检测，针对性强，检测效率高，检测性能强。

第二，只需存储安全要素组合即可，无需存储全部报文，降低存储所需的空间、容量，减少了不必要的设备成本开支。

第三，不论原本报文的数据格式如何，均可形成格式统一的安全要素组合，然后可以基于与所述预设格式对应的检测规则完成风险检测，从而使用统一格式的进行规则检测，提高检测效率，降低规则维护成本。

第四，可以提前与风险检测相关的安全要素，并且预设格式的安全要素进行组装，形成格式统一的安全要素组合，将孤立的数据连接在了一起，在基于安全要素组合进行风险检测的时候，可以考虑到安全要素之间的关联关系，实现关联分析，有助于提升风险检测效果。

下结合附图进行实施例说明。请参见图1，图1为本申请实施例示出的一种安全要素的治理方法的流程示意图。

图1示出的安全要素的治理方法可以应用于电子设备中。其中，所述电子设备可以通过搭载与安全要素的治理方法对应的软件逻辑执行该方法。所述电子设备的类型可以是笔记本电脑，计算机，服务器，手机，掌上电脑（Personal Digital Assistant，PDA）等。在本申请中不特别限定所述电子设备的类型。所述电子设备也可以是客户端设备或服务端设备。

如图1所示，所述方法可以包括S102-S106。除特别说明外，本申请不特别限定这些步骤的执行顺序。

S102，获取网络报文。

所述网络报文是指网络通信中交换与传输的数据单元。网络报文中包括与通信相关的很多信息，比如访问地址，接口信息，访问的数据信息等等。通过对网络报文解析可以完成风险检测。在一些实施例中，所述网络报文可以是基于HTTP协议生成的请求报文或者响应报文。

在一些方式中可以通过部署埋点完成上述网络报文的采集。在一些方式中，可以通过使用客户（Agent）端或者使用eBPF等技术可以采集到HTTP(SSL/TLS)相关的报文，然后利用获取到的加密算法的证书完成报文解密之后再进行后续的风险分析。

其中，eBPF（Extended Berkeley Packet Filter）技术是一种Linux内核中的动态跟踪工具，允许用户编写安全且高效的内核空间代码。

HTTP(SSL/TLS)，即HTTPS，是指将HTTP下层的传输协议由TCP/IP换成了SSL/TLS。SSL，安全套接层（Secure Sockets Layer）。TLS ，传输层安全性协议（英语：TransportLayer Security，缩写作TLS），是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。

S104，提取所述网络报文中与风险检测相关的预设维度的报文信息。

所述预审维度是指根据经验得到的，预先设置的与风险检测相关维度。在一些方式中，可以通过界面让用户对预设维度进行配置。

例如，所述预审维度可以报文头中的一些字段。比如，HTTP请求头中与身份验证、授权相关的字段，如Cookie、Authorization、X-API-Key等，当然，还可以结合业务场景预设Content-Type、Content-Length等字段。这些字段可以反馈数据传输的格式及大小，指示是否存在风险攻击。譬如如果请求中Content-Length忽然激增，则可以反映有恶意攻击者尝试使用垃圾数据绕过安全设备。再比如所述预设维度可以是报文头与代理相关的字段：x-client-ip、x-true-ipwl-proxy-client-ip、x-real-ip等等。在后续检测时，可以不同字段发现代理地址不一样，则可以进一步进行分析，检测到风险行为。

再例如，所述预设维度可以对报文体解析得到的属性和属性值。这些属性和属性值可以指示出是否发送网络风险。

在一些实施例中，可以增加一些用户结合业务场景自定义的第三预设字段。所述预设维度的报文信息包括用户自定义的第三预设字段的字段内容；所述第三预设字段包括以下至少一项：攻击结果字段；API标识字段；请求方法字段；文件上传的中Content-Disposition和/或Content-Type字段；文件头；文件尾；文件主体的首行；文件主体的末尾；安全要素组合的UUID。

其中，所述攻击结果字段用于指示攻击是否成功。所述API标识字段可以指示访问方式是否为API。所述请求方法字段指示请求或响应方式的类型。比如，GET、HEAD、POST、PUT、PATCH、DELETE。

通过这些第三预设字段可以辅助进行风险检测，并且有助于实现请求报文和对应的响应报文的关联分析，提升风险检测效果。

例如，可以在请求报文和对应的响应报文用同一UUID，并将该UUID作为安全要素添加到安全要求组合中。后续通过UUID将请求与响应建立联系，便于进行关联分析，提升风险检测效果。

再例如，可以将所述API标识字段作为安全要素添加到安全要求组合中。后续可以搜索api=1，则可以快速定位到哪些报文为API，对这些报文完成关联分析，提升风险检测效果。

再例如，可以将所述请求方法字段作为安全要素添加到安全要求组合中。例如，正常的请求应该是GET请求，但现在使用了POST请求，则可以在拼接后的字段中通过对比，快速判断出异常。

再例如，可以将所述请求方法字段作为安全要素添加到安全要求组合中。针对内存马连接的场景，攻击者可以使用不寻常的请求方式加载已经上传的内存马，譬如正常情况下，网站中会存在favicon.ico，假设这个文件已经被黑客写入了恶意的内存马，那么对/favicon.ico进行GET请求还是是正常的，但是如果对/favicon.ico使用POST请求，则可能是连接内存马的恶意攻击。由此通过请求方法字段即可实现这种场景下的风险检测。

再例如，可以将文件上传的中Content-Disposition字段、Content-Type字段、文件头、文件尾、文件主体的首行、文件主体的末尾这些内容中作为安全要素添加到安全要求组合中。可以通过比较Content-Type与文件头、文件尾生成的文件格式是否一致，如果不一致则代表可能里面写了恶意的木马，遭受到了攻击，从而实现关联分析，提升风险检测效果。

本步骤中可以通过预设的与不同预设维度对应的信息提取逻辑完成报文信息的提取。

S106，将所述报文信息转化为预设格式的安全要素，并对所述安全要素进行组装，得到安全要素组合。

所述预设格式是预先设置的数据格式。例如针对访问地址，该预设格式可以是URL地址格式。针对报文头和报文体，该预设格式可以表达参数和参数值的对应关系。例如，预设格式可以是“参数=参数值”，“参数：参数值”，“参数[参数值]”等等。在一些实施例中预设格式为“参数=参数值”。本步骤可以通过预设的转换逻辑，将JSON、XML、URL等格式的数据转换为“参数=参数值”的方式，实现数据格式的同一。

完成格式统一之后，可以对这些安全要素进行组装。例如可以通过预设连接符号完成各安全要素的连接，得到安全要素组合。比如，可以在访问地址和“参数=参数值”这种方式的安全要素之间通过“？”这一连接符连接，将“参数=参数值” 这种方式的安全要素之间通过“&”这一连接符连接。

在一些方式中，可以将得到完成治理的安全要素组合存储起来，进行模型训练，风险检测等等。

在一些风险检测场景中，在完成安全要素治理后，还可以基于与所述预设格式对应的检测规则，对所述安全要素组合进行网络安全风险检测。

所述检测规则，可以是一些匹配规则，也可以是一些人工智能模型规则。本步骤中可以预设设置一些检测规则，对所述安全要素组合进行网络安全风险检测，得到风险检测结果。

通过S102-S106记载的方案，可以根据与风险检测相关的预设维度，从网络报文中检测出与风险检测相关的报文信息，然后对报文信息转换为预设格式的安全要素进行组装，不论原本报文的数据格式如何，均可形成格式统一的安全要素组合。在风险检测场景中可以基于与所述预设格式对应的检测规则完成风险检测。

由此，第一，有针对性的对报文中与风险检测相关的安全要素进行检测，针对性强，检测效率高，检测性能强。

第二，只需存储安全要素组合即可，无需存储全部报文，降低存储所需的空间、容量，减少了不必要的设备成本开支。

第三，不论原本报文的数据格式如何，均可形成格式统一的安全要素组合，然后可以基于与所述预设格式对应的检测规则完成风险检测，从而使用统一格式的进行规则检测，提高检测效率，降低规则维护成本。

第四，可以提前与风险检测相关的安全要素，并且预设格式的安全要素进行组装，形成格式统一的安全要素组合，将孤立的数据连接在了一起，在基于安全要素组合进行风险检测的时候，可以考虑到安全要素之间的关联关系，实现关联分析，有助于提升风险检测效果。

在一些实施例中，所述网络报文可以包括请求方法，访问路径，报文头和报文体。在一些场景中网络报文也可能没有报文体。例如请求方法可以包括为GET、HEAD、POST、PUT、PATCH、DELETE。其中GET、HEAD是没有报文体的，在POST、PUT、PATCH、DELETE这四类请求方法中是有报文体的。

S106中，将所述报文信息转化为预设格式的安全要素，包括以下至少一项。

第一项，将所述网络报文包括的访问路径与所述网络报文包括的报文头中的第一预设字段的字段内容进行组合，得到第一安全要素。

所述第一预设字段可以是指与报文交互关联的字段。例如HOST字段。将该字段的字段内容与访问路径组合可以详细指示报文交互相关的细节信息，有助于提升风险检测的效果。

其中组合的方式可以是通过预设连接字符对二者进行连接。例如，可以通过“/”将访问路径和第一预设字段进行组合。

第二项，将所述报文头中的第二预设字段确定为第一参数，将所述第二预设字段对应的第二字段内容确定为与所述第一参数对应的第一参数值，以及将所述第一参数和所述第一参数值的组合确定为第二安全要素。

针对报文头，可以将报文头内的第二预设字段和其对应的第二字段内容统一转换为“参数=参数值”的预设格式。

本步骤中可以通过关键词匹配等方式查询到第二预设字段以及其对应的第二字段内容。然后将所述第二预设字段作为第一参数，将第二字段内容作为第一参数值。

然后在将所述第一参数和所述第一参数值的组合确定为第二安全要素的过程中，可以通过第一预设连接符，连接所述第一参数和与所述第一参数值，得到第二安全要素。

所述第一预设连接符可以根据需求进行设定。例如所述第一预设字符可以是“=”。由此可以将报文头中的内容转换为“第一参数=第一参数值”的预设格式，完成报文头的格式标准化。

第三项，在所述网络报文包括报文体的情形下，在所述报文体中识别第二参数，和与所述第二参数对应的第二参数值，将所述第二参数和所述第二参数值的组合确定为第三安全要素。

在POST、PUT、PATCH、DELETE这四类请求方法中，网络报文时包括报文体的，即需要对报文体进行格式标准化。

在一些方式中，可以基于库文件识别报文体中的属性和属性值，然后再根据识别出的属性和属性值确定第二参数和第二参数值。

请参见图2，图2为本申请示出的一种确定第二参数和第二参数值的方法流程示意图。如图2所示，所述方法可以包括S202-S204。

S202，调用与所述报文体的数据格式对应的库文件，识别所述报文体中的属性名和属性值。

相关技术中，每种数据格式都有对应的库文件，用于解析相关内容。本步骤可以预先存储与不同数据格式对应的库文件，在确定报文体的数据格式后，可以利用相应的库文件，完成识别报文体中的属性名和属性值。

S204，根据识别出的所述报文体中的属性名和属性值，确定第二参数和第二参数值。

本步骤中，在识别到任意属性值并且未识别到与所述任意属性值对应的任意属性名的情形下，根据预设属性名确定所述第二参数，根据所述任意属性值确定所述第二参数值。

在一般情形中，属性值和属性名成对出现，但是在一些场景中报文体中可能只包括属性值，但是没有与其对应的属性名，这些情形下，为了保证格式标准化，可以取预设属性名作为属性名。所述预设属性名可以根据需求进行设定。比如，所述预设属性名可以是param，canshu等等。

例如，报文体为HelloWorld，只有属性值，没有属性名。此时可以将预设属性名param作为该属性值的属性名。由此得到第二参数为param，第二参数值为HelloWorld。

可以理解的是，不论何种数据格式下，都有可能存在只有属性值没有属性名的情况，这些请看下可以参照利用预设属性名来作为参数的方案。

在识别到任意属性值以及和所述任意属性值对应的任意属性名的情形下，根据所述任意属性名确定所述第二参数，根据所述任意属性值确定所述第二参数值。

本步骤中可以包括以下四种情形。

情形一，在所述报文体的数据格式为URL的情形下，可以利用URL对应的库文件从报文体中识别出成对的属性名和属性值，然后可以将属性名作为第二参数，将属性值作为第二参数值。

例如URL：http://www.example.com/api/user/login?username=admin&password=abcdefg。对该URL进行解析可以得到属性名1为username，属性值1为admin，属性名2为password，属性值2为abcdefg。由此可以得到两对参数和参数值。

情形二，在所述报文体的数据格式为JSON的情形下，可以利用JSON对应的库文件从报文体中识别出成对的属性名和属性值，然后可以根据属性名确定第二参数，将根据属性值确定第二参数值。

在一些场景中，属性名可能存在嵌套。针对这些场景也需要进行标准化处理。在根据所述任意属性名确定所述第二参数的步骤中，在所述任意属性名具备第一形式的多层嵌套的情形下，通过第一预设符号将所述任意属性名中不同层级的元素连接起来，生成格式统一的所述第二参数。

所述第一形式的多层嵌套可以是基于对象形式形成的嵌套。

所述第一预设符号可以根据需求进行设定。例如可以是“.”，“-”等。

以存在两层嵌套的JSON举例。{ "username": "admin", "password": "abcdefg", "verify": { "code": "1234", "question": "B" }}。其中针对"verify":{ "code": "1234", "question": "B" }形成了两层嵌套。针对该种情形，可以针对不同层级的元素用“.”连接起来，形成verify. code作为第二参数，verify. Question为另外一个第二参数。由此在报文体有层级嵌套的场景中，也可以形成格式统一的第二参数。

在根据所述任意属性名确定所述第二参数的步骤中，在所述任意属性名具备第二形式的多层嵌套的情形下，通过第二预设符号将所述任意属性名中不同层级的元素连接起来，并且在末尾层级的元素后添加第三预设符号，生成格式统一的所述任意第二参数。

所述第二形式的多次嵌套可以是基于数组格式形成的嵌套。

所述第二预设符号可以根据需求进行设定。例如可以是“.”，“-”等。

所述第三预设符号可以根据需求进行设定。例如可以是“[n]”，“{n}”等，其中n与属性值的顺序有关。

以存在两层嵌套的JSON举例。{"username": "admin","password": "abcdefg","verify": [ "1234","B" ]}。其中针对"verify": [ "1234","B" ]形成了两层嵌套。针对该种情形，可以针对不同层级的元素用“.”连接起来，本例中虽然有两个层级，但是与属性名相关的元素只有一个，所以不需要用“.”连接。然后可以在末尾层级的元素之后增加“[n]”。其中，属性值"1234"为第一个属性值，所以其对应的参数被命名为verify[0]，属性值"B"为第二属性值，所以其对应的参数被命名为verify[1]。由此在报文体有层级嵌套的场景中，也可以形成格式统一的第二参数。

情形三，在所述报文体的数据格式为XML的情形下，可以利用XML对应的库文件从报文体中识别出成对的属性名和属性值，然后可以根据属性名确定第二参数，将根据属性值确定第二参数值。

在XML格式的报文体中可以存在请求方法属性值，在所述任意属性值为请求方法属性值的情形下，可以将第一预设属性名作为请求方法属性值的属性名，然后形成第二参数。

所述请求方法属性值指示XML的请求方法，例如wp.getUsersBlogs。

所述第一预设属性名可以根据需求进行设定。例如，method，way，means等等。

在XML格式的报文体中可以存在常规的参数属性值，在所述任意属性值为参数属性值的情形下，获取第二预设属性名，根据所述参数属性值的顺序，确定所述第二预设属性名的编号，以及将所述第二预设属性名与所述编号的组合，确定为所述第二参数。

所述第二预设属性名可以根据需求进行设定。例如可以是param n，其中n与参数属性值的顺序相关。

例如，XML格式的报文体如下：

    wp.getUsersBlogs

    

        

            admin

        

        

            abcdefg

        

    

。

针对该XML格式的报文体，报文体中属性值需要格式化时，可以根据属性值的顺序利用param n的方式进行命名，命名，例如param1、param2等。上面报文体的请求方法属性值为wp.getUsersBlogs，因此还需自定义一个请求方法的参数method。由此针对XML格式的报文体内的属性和属性值进行格式标准化，形成统一的参数与参数值对。

情形四，针对其它格式，可以利用其它格式对应的库文件识别出诸如文件头、文件尾、文件主体的第一行、最后一行等的属性值，以及然后为这些属性值进行唯一命名，形成参数与参数值对，以生成安全要素。

针对以上四种情形，得到格式统一的第二参数和第二参数值后，可以将所述第二参数和所述第二参数值的组合确定为第三安全要素。在一些方式中，可以通过第二预设连接符，连接所述第二参数和与所述第二参数值，得到第三安全要素。

所述第二预设连接符可以根据需求进行设定。例如“=”，“*”。以“=”为例。可以得到预设格式“第二参数=第二参数值”的第三安全要素。

在一些实施例中，在得到第一安全要素，第二安全要素，第三安全要素（若有）之后，可以对这些安全要素进行组装，得到安全要素组合。其中，可以通过第三预设连接符，在所述第一安全要素之后拼接所述第二安全要素；通过第四预设连接符，在所述第二安全要素之后连接所述第三安全要素，得到安全要素组合。

所述第三预设连接符可以根据需求进行设定。例如，“？”、“#”等等。以“？”为例。

所述第四预设连接符可以根据需求进行设定。例如，“&”、“$”等等。以“&”为例。

以HTTP请求URL为http://www.example.com/api/user/login为例，以下示意如何得到安全要素组合。

假设请求体的数据格式为URL编码，请求体包括username=admin&password=abcdefg。请参见图3，图3为本申请示出的针对URL编码的请求体的识别示意图。如图3所示，可以识别出username=admin和password=abcdefg两对参数和参数值，并通过连接符“&”连接得到username=admin&password=abcdefg。然后可以与URL进行拼接。请参见图4，图4为本申请示出的安全要素拼接示意图。如图4，可以通过“？”连接URL和安全要素，得到安全要素组合。如果有多个安全要素，也是类似的方式拼接，最终形成新的拼凑后的安全要素组合，可以单独进行存储。

如果请求体不包含参数，只包括参数值，比如请求体是：HelloWorld。则需要为其指定预设属性名param，与请求体中的HelloWorld拼接成param=HelloWorld，最终的拼接效果可以参见图5，图5为拼装得到的安全要素组合的示意图。

假设请求体的数据格式为JSON格式，请求体包括：

{ "username":"admin", "password":"abcdefg"}。

可以先识别参数和参数值，然后进行统一拼接。请参见图6，图6为本申请示出的一种参数识别结果示意图。如图6所示，识别出username=admin和password=abcdefg两对参数和参数值。然后与URL进行统一拼接，得到如图4所示的拼装结果。

针对请求体不包含参数的情形，可以参照前面的处理最终得到图5示意的拼装结果。

请求体可能存在对象格式的多层嵌套的情形。例如，{ "username": "admin", "password": "abcdefg", "verify": { "code": "1234", "question": "B" }}。参数和参数识别结果可以参照图7。图7为本申请示出的一种参数识别结果示意图。如图7所示可以识别出4对参数和参数值。为了标准化处理，可以使用“.”连接不同层级的元素，可以使用verify.code表示1234的参数、verify.question表示B的参数。如果是更多层的也是按照这种方法以此类推。然后进行与URL的拼装，最终可以得到安全要素组合：

http://www.example.com/api/user/login?username=admin&password=abcdefg&verify.code=1234&verify.question=B。

请求体可能存在数组格式的多层嵌套的情形。例如，{"username": "admin","password": "abcdefg", "verify": [ "1234","B" ]}。其中针对"verify": [ "1234","B" ]。参数和参数识别结果可以参照图8。图8为本申请示出的一种参数识别结果示意图。如图8所示，识别出两对参数和参数值，参数值3和参数值4没有对应的参数。为了标准化处理，可以使用“verify[n]”来表示参数。比如verify[0]表示1234的参数、verify[1]表示B的参数。然后进行与URL的拼装，最终可以得到安全要素组合：

http://www.example.com/api/user/login?username=admin&password=abcdefg&verify.code=1234&verify.question=B。

在一些场景中，报文体中的恶意攻击字符串存在至少一次编码，这会对风险检测造成影响，降低检出率。例如，攻击者通常使用../../进行目录穿越的攻击，而攻击者通常会对这些规则进行多次编码，譬如进行一次编码得到..%2F..%2F，进行两次编码得到..%252F..%252F，甚至更多次编码从而绕过检测，降低检出率。

在一些实施例中，可以通过对第三安全要素（从报文体中提取出的安全要素）进行递归解码，以解决由于编码导致的检出率低的问题。

请参见图9，图9为本申请示出的一种递归解码的流程示意图。图9示意的步骤为对一轮递归解码的步骤示意图。所述递归解码是指重复执行图9示意的步骤，直到所述第三安全要素与预设的至少一个编码类型均不匹配。如图9所示，所述方法可以包括S902-S906。

S902，判断所述第三安全要素与预设的至少一个编码类型是否匹配。

本步骤可以通过正则表达式的方式进行实现。

请参见图10，图10为本申请示出的第三安全要素与编码类型进行匹配的流程示意图。图10示意的步骤为对S902的说明。如图10所述，所述方法可以包括S1002-S1008。

S1002，获取与至少一个编码类型分别对应的正则表达式。

在一些方式中可以预先设置如下的正则表达式：

URL编码：%[0-9A-Fa-f]{2}；Unicode编码：^(U+[0-9A-F]{4,6})$；Hex编码：[0-9A-Fa-f]+；HTML实体编码：&(#[0-9]+|#x[0-9a-fA-F]+|[a-zA-Z0-9]+)；UTF-8编码：通过Unicode属性转义序列（如 \p{L} ）或Unicode范围（如 [\u0000-\uFFFF]）进行匹配；UTF-7编码：^(?:[A-Za-z0-9+\/]*(?:[A-Za-z0-9+\/]|(?<=\+)[A-Za-z0-9+\/]|(?<=\+)[A-Za-z0-9+\/]))*；Base64编码：[A-Za-z0-9+/]{4}(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?；Base32编码：

[A-Z2-7]{8}(?:[A-Z2-7]{2}={6}|[A-Z2-7]{4}={4}|[A-Z2-7]{5}={3}|[A-Z2-7]{7}={1})?。

本步骤可以获取这些表达式。当然在一些方式中，也可以对正则表达式进行一些变形，通过变形得到的正则表达式也是本申请想要保护的内容。

S1004，将所述第三安全要素与每一所述正则表达式进行匹配。

S1006，响应于所述第三安全要素只与任一目标正则表达式匹配，确定所述第三安全要素与所述目标正则表达式对应的目标编码类型匹配。

S1008，响应于所述第三安全要素与至少两个正则表达式匹配，确定所述第三安全要素与所述至少两个正则表达式对应的至少两种编码类型匹配。

S1004-S1008的步骤中，可以将第三安全要素依次与各正则表达式进行匹配，确定其中相匹配的正则表达式。如果没有匹配的正则表达式，说明第三安全要素当前为不存在编码的最小单元，可以结束递归解码。如果只有一个匹配的正则表达式（称为目标正则表达式），则说明第三安全要素只与目标编码类型匹配。如果有至少两个匹配的正则表达式，则说明第三安全要素与至少两种编码类型匹配。

通过S1002-S1008记载的方案可以通过正则表达式进行第三安全要素的编码类型的判断，有助于后续进行解码。

S904，在所述第三安全要素与所述至少一个编码类型中的目标编码类型匹配的情形下，利用与所述目标编码类型对应的解码库对所述第三安全要素进行解码。

本步骤中可以获取与目标编码类型对应的解码库，然后利用该解码库进行解码，得到解码结果。得到的解码结果可以作为下一轮递归解码的输入。

S906，在所述第三安全要素与至少两种编码类型匹配的情形下，分别利用所述至少两种编码类型中的每一种编码类型所对应的解码库对所述第三安全要素进行解码。

本步骤可以获取与所述至少两种编码类型中的每一种编码类型所对应的解码库，然后用每一种解码库都对第三安全要素进行解码，得到没有报错的解码结果。得到的解码结果可以作为下一轮递归解码的输入。

通过循环执行S902-S906，直到所述第三安全要素与预设的至少一个编码类型均不匹配，不仅可以对安全要素进行解码，提升检出率，而且可以通过预先判断可能的解码格式，然后进行解码尝试，这样可以缩小检测范围，提升任意字符串编码格式的检测效率。

在一些实施例中，用于进行风险检测的检测规则可以是基于人工智能生成的网络安全风险检测模型。由此可以利用人工智能完成风险检测。在利用该模型进行风险检测之前需要进行模型训练，而模型训练中比较困难的是构建训练样本。在一些方式中，可以基于所述安全要素组合以及所述安全要素组合对应的风险标签，构建训练样本；所述训练样本用于对所述网络安全风险检测模型进行训练。

所述风险标签可以由人工标注。得到风险标签之后可以将风险标签和安全要素组合作为训练样本，通过诸如有监督训练的方式对所述网络安全风险检测模型进行训练，使该模型具备风险检测的能力。由此可以基于提取的安全要素组合构建训练样本，完成基于人工智能生成的网络安全风险检测模型的训练，减少特征工程的时间，提升模型训练效率。

本申请还提出一种安全要素的治理系统。以下结合附图对实施例进行说明。

请参见图11，图11为本申请示意的一种安全要素的治理系统的结构示意图。如图11所示，所述系统可以包括数据采集单元1110，数据解析单元1120，数据处理单元1130，数据存储单元1140，风险检测单元1150和建模单元1160。

其中，所述数据采集单元1110，用于采集应用层协议中的HTTP流量或者HTTPS解密流量。其中HTTPS解密流量可以使用Agent端或者使用eBPF等技术采集到，然后通过加密算法的证书进行解密。

所述数据解析单元1120，用于对HTTP报文的每一个结构进行数据解析，按照HTTP请求方式、HTTP请求的URL、HTTP请求头、HTTP请求体、HTTP响应码、HTTP响应头、HTTP响应体等进行存储。

所述数据处理单元1130，用于从报文中提取标准的（预设格式的）安全要素，并且进行组装得到安全要素组合。处理过程可以参照S104-S106记载的内容及其相关实施例。处理过程至少包括数据格式统一、递归解码、参数与参数值组装、自定义参数组装（用户自定义字段）等。

所述数据存储单元1140，用于将提取到安全要素组合和安全要素进行存储，并生成请求、响应的UUID编号，将请求与响应建立联系，进行关联分析。

所述风险检测单元1150，用于可以利用风险检测规则和/或模型完成风险检测。

所述建模单元1160，用于将安全要素组合作为数据集，利用特征工程构建训练样本集，用于对风险检测模型的训练。

请参见图12，图12为本申请示出的安全要素治理流程示意图。治理流程包括从获取流量，提取安全要素，拼装安全要素和存储安全要素的步骤。具体地，如图12所示，该方法可以包括S1201-S1216。

S1201，开始。

S1202，通过流量、探针等设备采集HTTP流量，也可以采集部分支持解密的HTTPS流量。

S1203，从流量中提取请求方式、请求体、请求的URL，并得到相应的安全要素（第一安全要素和第二安全要素），然后进入S1204，并且可以进入S1210，进行响应报文的相关安全要素的提取。

S1204，判断流量是否存在请求体，如果存在执行第S1205步；如果不存在执行第S1209。

本步骤中，可以通过判断请求方式来判断是否具备请求体。其中，GET、HEAD请求没有请求体，POST、PUT、PATCH、DELETE这四类请求方式具备请求体。

S1205，判断请求体的数据格式。

S1206，根据请求体的数据格式进行标准化，得到第三安全要素，并与S1203得到的安全要素进行组装，得到安全要素组合。

本步骤可以参照S106，S202-S204及其相关实施例。所述相关实施例包括某一步骤对应的实施例和对该步骤进行说明（含详细说明，补充说明，进一步说明，下位说明）的实施例。

S1207，判断第三安全要素的参数、参数值是否为可以被解码，如果可以则执行S1208；如果不能被解码，则执行S1209。

S1208，根据请求体中的参数、参数值，按照常见的编码格式，进行递归解码，得到解码后的解析后的安全要素组合。

本步骤可以参照S902-S906及其相关实施例。

S1209，将安全要素组合和安全要素存储到数据库中，进入S1216结束流程。

S1210，判断是否存在响应报文，如果存在，则进入S1211步；如果不存在，则进入S1209。

S1211，判断是否存在响应体，如果存在，则进入S1212步；如果不存在，则进入S1209。

S1212，判断响应体数据格式。

S1213，根据响应体的数据格式进行标准化，得到第三安全要素，并组装到安全要素组合，进入S1214。

S1214，判断响应体中的参数、参数值是否为可以被解码，如果可以则执行S1215；如果不能被解码，则执行S1209。

S1215，根据响应体中的参数、参数值，按照常见的编码格式，进行递归解码，得到解码后的解析后的安全要素组合，执行S1209。

S1216，结束。

通过S1201-S1206可以完成从流量中提取安全要素并完成治理。后续可以将提取的安全要素用于风险检测或AI建模等应用场景。由此，第一，有针对性的对报文中与风险检测相关的安全要素进行检测，针对性强，检测效率高，检测性能强。

第二，只需存储安全要素组合即可，无需存储全部报文，降低存储所需的空间、容量，减少了不必要的设备成本开支。

第三，不论原本报文的数据格式如何，均可形成格式统一的安全要素组合，然后可以基于与所述预设格式对应的检测规则完成风险检测，从而使用统一格式的进行规则检测，提高检测效率，降低规则维护成本。

第四，可以提前与风险检测相关的安全要素，并且预设格式的安全要素进行组装，形成格式统一的安全要素组合，将孤立的数据连接在了一起，在基于安全要素组合进行风险检测的时候，可以考虑到安全要素之间的关联关系，实现关联分析，有助于提升风险检测效果。

第五，不仅可以对安全要素进行解码，提升检出率，而且可以通过预先判断可能的解码格式，然后进行解码尝试，这样可以缩小检测范围，提升任意字符串编码格式的检测效率。

第六，可以基于提取的安全要素组合构建训练样本，完成基于人工智能生成的网络安全风险检测模型的训练，减少特征工程的时间，提升模型训练效率。

本领域技术人员应明白，本申请一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本申请一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（可以包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本申请中的“和/或”表示至少具有两者中的其中一个。本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于数据处理设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

虽然本申请包含许多具体实施细节，但是这些不应被解释为限制任何公开的范围或所要求保护的范围，而是主要用于描述特定公开的具体实施例的特征。本申请内在多个实施例中描述的某些特征也可以在单个实施例中被组合实施。另一方面，在单个实施例中描述的各种特征也可以在多个实施例中分开实施或以任何合适的子组合来实施。此外，虽然特征可以如所述在某些组合中起作用并且甚至最初如此要求保护，但是来自所要求保护的组合中的一个或多个特征在一些情况下可以从该组合中去除，并且所要求保护的组合可以指向子组合或子组合的变型。

类似地，虽然在附图中以特定顺序描绘了操作，但是这不应被理解为要求这些操作以所示的特定顺序执行或顺次执行、或者要求所有例示的操作被执行，以实现期望的结果。在某些情况下，多任务和并行处理可能是有利的。此外，所述实施例中的各种系统模块和组件的分离不应被理解为在所有实施例中均需要这样的分离，并且应当理解，所描述的程序组件和系统通常可以一起集成在单个软件产品中，或者封装成多个软件产品。

以上仅为本申请一个或多个实施例的较佳实施例而已，并不用以限制本申请一个或多个实施例，凡在本申请一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请一个或多个实施例保护的范围之内。