漏洞扫描方法、装置、存储介质及电子设备

摘要

本申请涉及网络安全技术领域，提供一种漏洞扫描方法、装置、存储介质及电子设备。其中，漏洞扫描方法包括：加载用于扫描目标漏洞的插件，加载的插件中包括相互之间包含有相似特征的第一类插件；确定特征库中与第一类插件对应的第一类特征；向目标主机发送第一类特征中包含的第一类请求报文，并接受目标主机返回的第一类响应消息；利用第一类特征中包含的匹配规则获取第一类响应消息中的第一类特征信息；利用第一类插件解析第一类特征信息，确定目标主机中有关目标漏洞的情况。该方法有利于降低了服务器压力、减小服务器和目标主机之间的网络带宽占用，以及降低请求报文被目标主机拒绝的概率。此外，该方法还有提高漏洞扫描的效率。

权利要求

1.一种漏洞扫描方法，其特征在于，包括：

加载用于扫描目标漏洞的插件，加载的插件中包括相互之间包含有相似的特征的第一类插件；其中，插件包含的特征由所述插件提取产生，所述特征为所述插件在发送请求报文以获取用于漏洞分析的特征信息的过程中涉及的关键信息，相似的特征是指包含的请求报文相同的特征；

确定特征库中与所述第一类插件对应的第一类特征；其中，所述特征库由插件提取出的特征构成，在所述特征库中相似的多个特征被合并为一个特征保存；

向目标主机发送所述第一类特征中包含的第一类请求报文，并接受所述目标主机返回的第一类响应消息；

利用所述第一类特征中包含的匹配规则获取所述第一类响应消息中的第一类特征信息；

利用所述第一类插件解析所述第一类特征信息，确定所述目标主机中有关所述目标漏洞的情况。

2.根据权利要求1所述的漏洞扫描方法，其特征在于，所述利用所述第一类特征中包含的匹配规则获取所述第一类响应消息中的第一类特征信息，包括：基于所述第一类特征中包含的匹配规则生成筛选规则，并利用所述筛选规则过滤所述第一类响应消息，得到剩余字符串；

利用所述匹配规则从所述剩余字符串中获取所述第一类特征信息。

3.根据权利要求2所述的漏洞扫描方法，其特征在于，所述第一类特征中包含的匹配规则包括至少一个正则表达式，其中每个正则表达式用于获取一项第一类特征信息，所述基于所述第一类特征中包含的匹配规则生成筛选规则，并利用所述筛选规则过滤所述第一类响应消息，得到剩余字符串，包括：基于所述至少一个正则表达式中的每个正则表达式所必须包含的字符串生成筛选规则，所述筛选规则为：过滤后得到的剩余字符串中至少包含一个正则表达式所必须包含的全部字符串；

利用所述筛选规则过滤所述第一类响应消息，得到所述剩余字符串。

4.根据权利要求3所述的漏洞扫描方法，其特征在于，所述利用所述筛选规则过滤所述第一类响应消息，得到所述剩余字符串，包括：利用多模匹配算法确定所述第一类响应消息中包含模式字符串的所述剩余字符串，所述模式字符串为任一正则表达式所必须包含的全部字符串。

5.根据权利要求1所述的漏洞扫描方法，其特征在于，所述特征中包含有用于保存所述特征信息的字段，所述利用所述第一类插件解析所述第一类特征信息，包括：向所述第一类特征的对应字段中写入所述第一类特征信息；

利用所述第一类插件从所述第一类特征的对应字段中读取并解析所述第一类特征信息。

6.根据权利要求1所述的漏洞扫描方法，其特征在于，所述合并后的特征中包含的匹配规则为合并前的多个特征中包含的匹配规则的并集。

7.根据权利要求6所述的漏洞扫描方法，其特征在于，所述合并后的特征中还包含有表示每项匹配规则来源的特征所对应的插件的标注信息，所述标注信息用于标识利用所述匹配规则获取到的、不同的插件所需解析的不同的特征信息。

8.根据权利要求1所述的漏洞扫描方法，其特征在于，所述向目标主机发送所述第一类特征中包含的第一类请求报文，包括：根据预设的排序规则对所述第一类特征中包含的第一类请求报文进行排序，并根据排序结果依次向目标主机发送所述第一类请求报文；其中，所述排序规则为：使得同一个第一类插件对应的第一类请求报文在发送时间上尽可能相近。

9.根据权利要求8所述的漏洞扫描方法，其特征在于，所述特征库有多个，同一个特征库中的特征均由带有同一种协议的插件提取产生，所述协议是指所述插件发送请求报文的协议。

10.根据权利要求1‑9中任一项所述的漏洞扫描方法，其特征在于，加载的用于扫描所述目标漏洞的插件还包括相互之间未包含有相似的特征的第二类插件；所述方法还包括：利用所述第二类插件向所述目标主机发送第二类请求报文，并接受所述目标主机返回的第二类响应消息；

利用所述第二类插件解析所述第二类响应消息，确定所述目标主机中有关所述目标漏洞的情况。

11.一种漏洞扫描装置，其特征在于，包括：

插件加载模块，用于加载用于扫描目标漏洞的插件，加载的插件中包括相互之间包含有相似的特征的第一类插件；其中，插件包含的特征由所述插件提取产生，所述特征为所述插件在发送请求报文以获取用于漏洞分析的特征信息的过程中涉及的关键信息，相似的特征是指包含的请求报文相同的特征；

特征确定模块，用于确定特征库中与所述第一类插件对应的第一类特征；其中，所述特征库由插件提取出的特征构成，在所述特征库中相似的多个特征被合并为一个特征保存；

请求报文发送模块，用于向目标主机发送所述第一类特征中包含的第一类请求报文，并接受所述目标主机返回的第一类响应消息；

特征信息获取模块，用于利用所述第一类特征中包含的匹配规则获取所述第一类响应消息中的第一类特征信息；

漏洞分析模块，用于利用所述第一类插件解析所述第一类特征信息，确定所述目标主机中有关所述目标漏洞的情况。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行如权利要求1‑10中任一项所述的方法。

13.一种电子设备，其特征在于，包括存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行权利要求1‑10中任一项所述的方法。

说明书

漏洞扫描方法、装置、存储介质及电子设备

技术领域

[0001] 本发明涉及网络安全技术领域，具体而言，涉及一种漏洞扫描方法、装置、存储介质及电子设备。

背景技术

[0002] 随着网络信息化的迅速发展，计算机网络融入企业和个人的工作生活越来越紧密，网络信息安全的重要性也逐渐上升，而众多网络应用的兴起以及功能的多样化，使得维护网络信息安全的难度也随之增加。由于目前应用的功能需求不断增多，程序的代码持续迭代，难免会产生一些设计的缺陷或者逻辑上的漏洞，一旦这些漏洞被有心人利用，则会导致重要资料被窃取、用户数据被篡改、系统被破坏等严重后果，最终造成企业或个人难以预料的损失。因此，近年来漏洞的提前发现和修补等相关技术成为了工业界和学术界的研究热点，漏洞扫描技术也由此应运而生。

[0003] 在现有漏洞扫描技术中，通常通过漏洞扫描系统调用漏洞扫描插件进行漏洞扫描，每个插件对应一个相关漏洞，调用插件时会针对性地向待扫描的目标主机发出大量的请求报文，然后根据这些请求报文对应的响应消息来判断是否存在对应漏洞。然而，不同的插件很可能会发送一些重复的请求报文，导致部署漏洞扫描系统的服务器压力非常大。

发明内容

[0004] 本申请实施例的目的在于提供一种漏洞扫描方法、装置、存储介质及电子设备，以改善上述技术问题。

[0005] 为实现上述目的，本申请提供如下技术方案：

[0006] 第一方面，本申请实施例提供一种漏洞扫描方法，包括：加载用于扫描目标漏洞的插件，加载的插件中包括相互之间包含有相似的特征的第一类插件；其中，插件包含的特征由所述插件提取产生，所述特征为所述插件在发送请求报文以获取用于漏洞分析的特征信息的过程中涉及的关键信息，相似的特征是指包含的请求报文相同的特征；确定特征库中与所述第一类插件对应的第一类特征；其中，所述特征库由插件提取出的特征构成，在所述特征库中相似的多个特征被合并为一个特征保存；向目标主机发送所述第一类特征中包含的第一类请求报文，并接受所述目标主机返回的第一类响应消息；利用所述第一类特征中包含的匹配规则获取所述第一类响应消息中的第一类特征信息；利用所述第一类插件解析所述第一类特征信息，确定所述目标主机中有关所述目标漏洞的情况。

[0007] 在上述方法中，基于插件提取出的特征构建特征库，而在特征库中，包含的请求报文相同的特征会被合并为一个特征，从而基于特征库进行请求报文的发送，相同的请求报文不会被重复发送，有效降低了服务器压力，减小了服务器和目标主机之间的网络带宽占用。并且，还有利于降低请求报文被目标主机拒绝的概率(某些请求，如登陆请求，若发送次数过多，很可能被目标主机拒绝)，有利于漏洞扫描的顺利完成。

[0008] 此外，在现有技术中，每个插件可能是一个单独的进程，其独立发送请求报文并解析响应消息，导致插件维护困难，且对服务器的CPU、内存占用也非常高，而在上述方法中，对于每个第一类插件，可以基于特征库统一进行第一类请求报文的发送、第一类响应消息的接收以及第一类特征信息的匹配，直至获取到第一类特征信息后才需要将其交由各个第一类插件进行解析，有效整合了不同的插件中重复的处理逻辑，从而有利于开发人员对插件以及特征库进行管理和维护，减小了服务器的CPU和内存占用，加快了漏洞扫描的过程。

[0009] 在第一方面的一种实现方式中，所述利用所述第一类特征中包含的匹配规则获取所述第一类响应消息中的第一类特征信息，包括：基于所述第一类特征中包含的匹配规则生成筛选规则，并利用所述筛选规则过滤所述第一类响应消息，得到剩余字符串；利用所述匹配规则从所述剩余字符串中获取所述第一类特征信息。

[0010] 上述实现方式在进行字符串匹配之前，首先基于筛选规则对第一类响应消息进行过滤，将其中必然不可能满足匹配规则的字符串过滤掉，仅对剩余字符串进行匹配以提取第一类特征信息，从而显著降低了需要进行匹配的字符串的数量，加快了提取第一类特征信息的速度，进而提高了漏洞扫描的效率。并且，对第一类响应消息进行过滤是统一进行的，并非是每个插件独立进行过滤，所以不仅过滤效率较高，而其筛选规则也具有通用性，开发维护起来都比较方便。

[0011] 在第一方面的一种实现方式中，所述第一类特征中包含的匹配规则包括至少一个正则表达式，其中每个正则表达式用于获取一项第一类特征信息，所述基于所述第一类特征中包含的匹配规则生成筛选规则，并利用所述筛选规则过滤所述第一类响应消息，得到剩余字符串，包括：基于所述至少一个正则表达式中的每个正则表达式所必须包含的字符串生成筛选规则，所述筛选规则为：过滤后得到的剩余字符串中至少包含一个正则表达式所必须包含的全部字符串；利用所述筛选规则过滤所述第一类响应消息，得到所述剩余字符串。

[0012] 在上述实现方式中，完整的正则表达式匹配起来比较慢，而如果基于正则表达式中所必须包含的字符串来设置筛选规则并进行字符串过滤，则执行效率较高(此时筛选规则可以在某种意义上视为正则表达式的简化版本)。而后，在剩余的少量字符串中进行正则匹配，耗时也不会太长。

[0013] 在第一方面的一种实现方式中，所述利用所述筛选规则过滤所述第一类响应消息，得到所述剩余字符串，包括：利用多模匹配算法确定所述第一类响应消息中包含模式字符串的所述剩余字符串，所述模式字符串为任一正则表达式所必须包含的全部字符串。

[0014] 多模式匹配算法如Aho‑Corasick算法、Wu‑Manber算法等可以实现高效的多模式字符串匹配，有利于提高字符串过滤的效率。

[0015] 在第一方面的一种实现方式中，所述特征中包含有用于保存所述特征信息的字段，所述利用所述第一类插件解析所述第一类特征信息，包括：向所述第一类特征的对应字段中写入所述第一类特征信息；利用所述第一类插件从所述第一类特征的对应字段中读取并解析所述第一类特征信息。

[0016] 在特征库的特征中，可以预留出特征信息的字段，待根据响应消息提取出特征信息后再填充这些字段，之后插件解析特征信息时直接从特征库中获取即可。

[0017] 在第一方面的一种实现方式中，所述合并后的特征中包含的匹配规则为合并前的多个特征中包含的匹配规则的并集。

[0018] 对于包含的请求报文相同的特征，其包含的匹配规则并不一定相同，所以在合并特征的时候需要取匹配规则的并集，以保证基于合并后的特征能够提取到特征信息和基于合并前的特征能够提取到的特征信息是相同的。

[0019] 在第一方面的一种实现方式中，所述合并后的特征中还包含有表示每项匹配规则来源的特征所对应的插件的标注信息，所述标注信息用于标识利用所述匹配规则获取到的、不同的插件所需解析的不同的特征信息。

[0020] 在上述实现方式中，通过设置标注信息，使得每一项特征信息在提取后要交由哪个插件进行解析是明确的。当然在另一些实现方式中，也可以不设置标注信息，只是将所有的特征信息提取出来，由每个插件自行获取自己需要的特征信息进行解析。

[0021] 在第一方面的一种实现方式中，所述向目标主机发送所述第一类特征中包含的第一类请求报文，包括：根据预设的排序规则对所述第一类特征中包含的第一类请求报文进行排序，并根据排序结果依次向目标主机发送所述第一类请求报文；其中，所述排序规则为：使得同一个第一类插件对应的第一类请求报文在发送时间上尽可能相近。

[0022] 在上述实现方式中，通过对发送第一类请求报文的顺序进行排序，使得同一个第一类插件对应的第一类请求报文在发送时间上尽可能相近，从而有利于每个第一类插件尽可能快地获取到所需的特征信息并进行解析，进而有利于提高漏洞扫描的效率。

[0023] 在第一方面的一种实现方式中，所述特征库有多个，同一个特征库中的特征均由带有同一种协议的插件提取产生，所述协议是指所述插件发送请求报文的协议。

[0024] 一般而言，带有同一种协议的插件其对应的请求报文才有可能相同(前者是后者的必要条件)，因此可以先按照协议将插件划分为不同的集合，然后基于各个插件集合构建不同的特征库，这样可以提高特征库构建的效率，避免大量无效的比较(例如，比较带有不同协议的插件请求报文是否相同)。

[0025] 在第一方面的一种实现方式中，加载的用于扫描所述目标漏洞的插件还包括相互之间未包含有相似的特征的第二类插件；所述方法还包括：利用所述第二类插件向所述目标主机发送第二类请求报文，并接受所述目标主机返回的第二类响应消息；利用所述第二类插件解析所述第二类响应消息，确定所述目标主机中有关所述目标漏洞的情况。

[0026] 对于第二类插件，由于相互之间不包含相似的特征，所以即使通过特征库进行请求报文的发送，也不会减少请求报文的数量，所以可以直接按照传统方式处理，即上述实现方式的方案还具有良好的兼容性。此外，还有一些插件，不需要发送请求报文，只需要从其他插件处获取信息进行漏洞分析，这类插件也可以按照传统方式处理。

[0027] 第二方面，本申请实施例提供一种漏洞扫描装置，包括：插件加载模块，用于加载用于扫描目标漏洞的插件，加载的插件中包括相互之间包含有相似的特征的第一类插件；其中，插件包含的特征由所述插件提取产生，所述特征为所述插件在发送请求报文以获取用于漏洞分析的特征信息的过程中涉及的关键信息，相似的特征是指包含的请求报文相同的特征；特征确定模块，用于确定特征库中与所述第一类插件对应的第一类特征；其中，所述特征库由插件提取出的特征构成，在所述特征库中相似的多个特征被合并为一个特征保存；请求报文发送模块，用于向目标主机发送所述第一类特征中包含的第一类请求报文，并接受所述目标主机返回的第一类响应消息；特征信息获取模块，用于利用所述第一类特征中包含的匹配规则获取所述第一类响应消息中的第一类特征信息；漏洞分析模块，用于利用所述第一类插件解析所述第一类特征信息，确定所述目标主机中有关所述目标漏洞的情况。

[0028] 第三方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

[0029] 第四方面，本申请实施例提供一种电子设备，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

附图说明

[0030] 为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

[0031] 图1示出了本申请实施例提供的一种漏洞扫描方法的原理图；

[0032] 图2示出了本申请实施例提供的一种漏洞扫描方法的流程图；

[0033] 图3示出了本申请实施例提供的一种漏洞扫描装置的模块图；

[0034] 图4示出了本申请实施例提供的一种电子设备的示意图。

具体实施方式

[0035] 下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

[0036] 在介绍本申请实施例提供的漏洞扫描方法之前，先说明一下开始漏洞扫描之前需要进行的准备工作。

[0037] 漏洞扫描的对象为目标主机，具体可以是目标主机上的应用软件、目标主机的操作系统等。漏洞扫描通过插件完成，每个插件用于扫描一个漏洞。在开始漏洞扫描前，首先可以收集漏洞信息，并根据漏洞信息开发用于漏洞扫描的插件，开发好的插件可以放入插件库进行管理。其中，漏洞信息可以从一些企业或者组织机构的漏洞信息通告平台处进行收集，例如国家信息安全漏洞共享平台www.cnvd.org.cn等。

[0038] 绝大部分插件进行漏洞扫描的方式可以概括为：向目标主机发送请求报文，然后对目标主机返回的响应消息进行解析，以获得关于漏洞的情况(例如，是否存在漏洞等)。当然也不排除某些插件不采用这样的方式扫描漏洞，例如，某些插件也可能从其他插件处获取所需的信息而不是自己发送请求报文，当然为简单起见，后文主要阐述通过发送请求报文进行漏洞扫描的方式，所针对的插件也主要是指采用此种方式进行漏洞扫描的插件。

[0039] 插件进行漏洞扫描并非要解析响应消息的全部内容，而只需解析其中的某些特定的信息即可，例如，目标主机的操作系统类型、MAC地址、目标主机上的应用采用的协议、该应用的版本、该应用的权限信息等等，称这些特定的信息为特征信息。

[0040] 发明人长期研究发现，各插件在进行漏洞扫描时很可能会发送相同的请求报文，获取到相同的响应消息，只是不同的插件会从响应消息中提取不同的特征信息进行解析，从而得到不同的结果。也就是说，各插件所做的工作有很大一部分在逻辑上是重复的，若由每个插件独立地执行这些重复的逻辑(例如，每个插件启动一个进程)，必然造成资源浪费。从而，若能够对各插件进行整合，将各插件的处理逻辑中具有共性的部分提取出来统一进行处理，将有利于减少资源浪费，提高漏洞扫描的效率。

[0041] 因此，在上述发现的基础上，本申请提出特征这一概念，特征是指插件在发送请求报文以获取特征信息的过程中涉及的关键信息，即特征可以视为对插件发送请求报文以获取特征信息这一过程的抽象表示。例如，某个插件对应特征中可以包括该插件要发送的请求报文，可以包括用于从响应消息中匹配得到特征信息的匹配规则(如，正则表达式等)，可以包括用于保存特征信息的字段(在获取到特征信息后可以将其写入该字段)，等等。总之，基于一个特征中提供的关键信息，就可以完整地描述插件从发送请求报文直至获取到特征信息的流程。

[0042] 对于每个开发好的插件，都可以提取其特征，在漏洞扫描过程中，一个插件可能会发送多个请求报文，得到多个响应消息，并从多个响应消息中分别获取特征信息用于漏洞分析。从而，针对每个插件都可能提取出多个特征，每个特征中包含一个请求报文。下面的代码示出了一个提取出的特征：

[0043]

[0044]

[0045] 其中，选项(Option1、Option2)以及键值对(Keys)都属于用于从响应消息中提取特征信息的匹配规则，例如，根据“版本号”中的正则匹配响应消息，就可以提取目标主机上apache的版本号。

[0046] 基于提取到的特征可以进行特征库的构建，构建时可以将每个特征作为一个单独的文件保存，当然在某些实现方式中也可以多个特征保存在一个文件中，或者不采用文件的方式，比如用数据库表格存储特征。

[0047] 对于相似的特征，在构建特征库时应当进行合并，所谓相似的特征是指包含的请求报文相同的特征。两个特征包含的请求报文相同，并不意味这两个特征完全相同(例如，其包含的匹配规则很可能不同)，但至少表明这两个特征所需提取的特征信息可以通过发送同一个请求报文、并从该请求报文对应的响应消息中提取特征信息。在合并特征时，对于合并前的多个特征所包含的匹配规则应取并集以得到合并后的特征中的匹配规则，这样才能够确保基于合并后的特征能够提取到特征信息和基于合并前的特征能够提取到的特征信息是相同的。

[0048] 此外，合并后的特征中还可以包含表示每项匹配规则来源的特征所对应的插件的标注信息，利用匹配规则从响应消息中匹配得到特征信息以后，根据该标注信息就可以获知提取出的特征信息是哪个插件所需的，从而可以将该特征信息发送给相应的插件进行解析处理。当然，标注信息并非必须的，在另一些实现方式中，负责提取特征信息的进程可以只是将所有的特征信息提取出来，由每个插件自行获取自己需要的特征信息并进行解析。

[0049] 在一些实现方式中，可以将所有插件提取出的特征都加入到一个特征库中；在另一些实现方式中，也可以设置多个特征库，带有同一种协议的插件所提取出的特征被加入到一个特征库中，此处的协议是指插件发送请求报文的协议，例如上文代码中的Http协议。一般而言，带有同一种协议的插件其对应的请求报文才有可能相同(协议相同可视为请求报文相同的必要条件)，因此若先按照协议将插件划分为不同的集合，然后基于各个插件集合构建不同的特征库，这样可以提高特征库构建的效率，避免大量无效的比较(例如，比较带有不同协议的插件所提取出的特征中的请求报文是否相同，从而决定是否要进行特征合并)。

[0050] 图1的上半部分示出了一种特征库的构建过程，在图1示出的实现方式中，首先将带有Http协议的插件整理为一个集合，对该集合中的插件进行特征提取，然后形成一个针对该集合的特征库。

[0051] 在提取插件的特征以后，要选择其中的哪些特征构建特征库，可以有不同的实现方式：

[0052] 方式一，将所有插件提取到的所有特征都加入到特征库中。

[0053] 方式二，只将相互之间包含有相似的特征的插件所对应的特征加入到特征库中，对于相互之间未含有相似的特征的插件所对应的特征则不加入到特征库，其中，插件包含的特征是指由该插件提取出的特征，若两个插件都包含多个特征，则它们只要有一个或以上的特征相似，这两个插件都属于相互之间包含有相似的特征的插件。这样处理的原因在于，构建特征库的出发点之一是通过特征的合并减少需要发送的请求报文的数量(详见后文对图2的阐述)，对于相互之间不包含有相似的特征的插件，即使将这些插件的特征加入到特征库中，也不会减少需要发送的请求报文的数量，这类插件在进行漏洞扫描时仍可维持现有技术中的方式，不必利用特征库。至于之前提到的少数不需发送请求报文的插件，自然也不需要将其特征加入特征库。

[0054] 方式三，只将相似的特征加入到特征库中，若一个特征不与其他任何特征相似，则不会被加入到特征库中。此种方式下，一个包含多个特征的插件可能有部分特征加入到了特征库，有部分特征未加入特征库。对于加入到特征库中的特征，由于存在与之相似的特征，所以可以进行合并以减少需要发送的请求报文的数量；对于未加入到特征库中的特征，其对应的请求可以按照现有技术中的方式发送，后续分析漏洞也按照现有技术中的方式分析。

[0055] 参照图1，图1采取的是方式二，对带有Http协议的插件集合进行特征提取后，只将包含有相似的特征的插件所对应的特征加入到特征库中(用连线示出)，对于未含有相似的特征的插件所对应的特征则不加入到特征库。

[0056] 图2示出了本申请实施例提供的一种漏洞扫描方法的流程图。该方法可由一电子设备执行(例如，由电子设备上安装的漏洞扫描系统执行)，图4示出了该电子设备的一种可能的结构，具体可参考后文关于图4的描述。后文为简单起见，以该电子设备是服务器为例进行说明。参照图2，该方法包括：

[0057] 步骤S110：加载用于扫描目标漏洞的插件，其中包括相互之间包含有相似的特征的第一类插件。

[0058] 在执行步骤S110前，假设插件特征已经提取，并且基于提取出的特征，特征库已经构建完毕，在后文中为简单起见，不妨以特征库采用方式二构建的情况为例进行相关阐述。

[0059] 目标漏洞是指本次漏洞扫描任务需要扫描的漏洞，由于漏洞和插件具有对应关系，所以根据目标漏洞可以确定并加载需要的插件。加载的插件中包括相互之间包含有相似的特征的第一类插件，根据构建特征库的第二种方式，这类插件的特征会被用于构建特征库。当然，根据扫描的需求，还有可能加载相互之间未包含有相似的特征的第二类插件，根据构建特征库的第二种方式，这类插件的特征不会被用于构建特征库。参照图1的下半部分，在扫描进程中，两类插件都进行了加载，注意，第一类插件是用于扫描目标漏洞的，其可能只是相互之间包含有相似的特征的插件中的一部分，所以在图1中上半部分和下半部分中进行了区别表示，第二类插件同理。

[0060] 步骤S120：确定特征库中与第一类插件对应的第一类特征。

[0061] 由于特征库由插件提取出的特征构成，所以插件和特征的对应关系是可以获知的，根据该关系可以确定出第一类插件在特征库中对应的特征，称之为第一类特征。

[0062] 步骤S130：向目标主机发送第一类特征中包含的第一类请求报文，并接受目标主机返回的第一类响应消息。

[0063] 根据前文阐述，每个特征中都包含请求报文，从而根据特征可以进行请求报文的发送，称第一类特征中包含的请求报文为第一类请求报文，目标主机接收到第一类请求报文后，会向服务器返回响应消息，称为第一类响应消息。由于特征库中进行了特征合并，所以基于特征库中的第一类特征发送的第一类请求报文不会存在重复。

[0064] 若在步骤S110中，还加载了第二类插件，则第二类插件在进行漏洞扫描时，也会向目标主机发送报文，成为第二类请求报文，目标主机接收到第二类请求报文后，会向服务器返回响应消息，称为第二类响应消息。

[0065] 继续参照图1，对于第二类请求报文，是插件自行发送的，即传统方式。而对于第一类请求报文，是基于特征库中的特征进行发送的，例如，可以另起一个进程专门负责发送第一类请求报文(当然，接受第一类响应消息以及后续步骤中的提取第一类特征信息也可由该进程负责执行)，此种方式在图1中称为托管，意思是将发送请求报文这项功能交给该进程统一处理，各插件不再负责处理。

[0066] 在一些实现方式中，可以根据预设的排序规则先对第一类特征中包含的第一类请求报文进行排序，再根据排序结果依次向目标主机发送第一类特征中包含的第一类请求报文，其中，排序规则被设置为：使得在排序后，同一个第一类插件对应的第一类请求报文在发送时间上尽可能相近。

[0067] 在排序时，既可以对第一类特征进行排序，由于每个第一类特征中都包含相应的第一类请求报文，所以对特征排序相当于对请求报文排序；当然也可以直接对要发送的第一类请求报文进行排序，这和对第一类特征进行排序在效果上是一样的。

[0068] 这样设置排序规则的原因是：若某个第一类插件对应的第一类请求报文(指该第一类插件对应的第一类特征中所包含的第一类请求报文)在发送时间接近，则可以认为该第一类插件对应的第一类响应消息在接收时间上也是接近的，进而该第一类插件可以在比较短的时间段内从第一类响应消息中提取第一类特征信息并进行漏洞分析。若每个第一类插件都尽可能地满足这样的条件，则可以使每个第一类插件都尽可能快地获取到所需的第一类特征信息并进行解析，从而有利于快速完成漏洞扫描任务。

[0069] 下面举例说明：假设某个第一类插件a需要发送第一类请求报文1、4、5，另一个第一类插件b需要发送第一类请求报文1、3，另一个第一类插件c需要发送第一类请求报文2、3、5，且a、b、c对应的第一类特征都在特征库中。则可以将a、b、c对应的第一类特征排序为1、
4、5、3、2，从而基于这样的特征排序发送第一类请求报文，会先连续发送报文1、4、5，使得插件a得以在较短时间内从相应的第一类响应消息中获取到第一类特征信息1、4、5，此时插件a所需的第一类特征信息已经全部获取，可以开始漏洞分析；再发送报文3(报文1已经发过了，无需重复)，使得插件b得以从相应的第一类响应消息中获取到第一类特征信息3，此时插件b所需的第一类特征信息已经全部获取，可以开始漏洞分析；再发送报文2(报文3、5已经发过了，无需重复)，使得插件c得以从相应的第一类响应消息中获取到第一类特征信息
2，此时插件c所需的第一类特征信息已经全部获取，可以开始漏洞分析。

[0070] 举个反例，如果先发送报文2，再发送报文3，则发送报文2后，无论是插件b还是插件c，都不能获取到其分析漏洞所需的全部第一类特征信息，因此其进行漏洞扫描的进度将慢于上面的方案。

[0071] 下面总结出一种较为通用的实现方案，分为3个步骤：

[0072] 步骤(1)：创建一个队列以及一个字典树存储结构。其中，队列用来保存请求报文的发送顺序，字典树用来保存队列中存在的报文，字典树的优点是利用字符串的公共前缀减少查询时间。

[0073] 步骤(2)：获取一个第一类插件，对于该插件需要发送的每个第一类请求报文，判断该报文是否存在于字典树中，如果某个第一类请求报文不在字典树中，则表示其也不在队列中，将该第一类请求报文加入队列，同时也加入字典树，如果已在字典树中则跳过该第一类请求报文。其中，根据特征库中与该第一类插件对应的全部第一类特征可以获取到该第一类插件需要发送的全部第一类请求报文并用于执行上述判断。另外，将某个报文加入队列可以指将该报文的某种标识(如，一个指针或引用)加入队列，将某个报文加入字典树可以指将该报文的具体内容加入字典树，通过报文的标识可以关联到报文的具体内容。

[0074] 步骤(3)：重复步骤(2)，直到获取完所有本次漏洞扫描中被加载的第一类插件，此时，队列里面保存的请求报文顺序即为发送顺序。

[0075] 步骤S140：利用第一类特征中包含的匹配规则获取第一类响应消息中的第一类特征信息。

[0076] 步骤S140即从第一类响应消息查找满足匹配规则的字符串，若存在这样的字符串，则匹配成功，找到的字符串即为第一类插件分析漏洞所需的特征信息，称为第一类特征信息。匹配规则可以采用正则表达式，但不限于正则表达式。

[0077] 步骤S150：利用第一类插件解析第一类特征信息，确定目标主机中有关目标漏洞的情况。

[0078] 如何根据第一类特征信息进行漏洞分析，可以参考现有技术，此处不具体阐述。这里所谓的有关目标漏洞的情况，可以包括有无目标漏洞，还有可能包括和目标漏洞有关的更多信息。

[0079] 前文提到，特征库的特征中可以包含用于保存特征信息的字段(如前文代码中的AC字段)，在生成特征时，这些字段暂时留空，而后根据从响应消息中提取出的特征信息可以对这些字段进行填充(如前文代码中向AC字段写入了apache)。从而，在步骤S140中获取到第一类特征信息后，可以将其写入第一类特征中相应的字段，而在步骤S150中，在利用第一类插件解析第一特征信息时，可以从该字段处读取第一类特征信息。

[0080] 若在步骤S110中还加载了第二类插件，后续也获得了第二类响应消息，则第二类插件会解析第二类响应消息，并根据解析结果确定目标主机中有关目标漏洞的情况。可以看出，第二类插件在漏洞扫描的流程上与现有技术类似，即本申请的方案具有良好的兼容性。

[0081] 综上所述，在本申请实施例提供的漏洞扫描方法中，基于由插件提取出的特征构建特征库，而在特征库中，包含的请求报文相同的多个特征会被合并为一个特征，从而在基于特征库中的特征统一进行请求报文的发送时，相同的请求报文不会被重复发送，因此该方法有效降低了服务器压力，减小了服务器和目标主机之间的网络带宽占用。

[0082] 再者，在现有技术中，某些请求，如登陆请求，若重复发送次数过多(同一个账号反复登录)，很可能被目标主机拒绝，导致漏洞扫描无法正常进行。而本申请的方案由于避免了重复发包，有效降低了请求报文被目标主机拒绝的概率，有利于漏洞扫描的顺利完成。

[0083] 此外，在现有技术中，每个插件可能是一个单独的进程，其独立发送请求报文并解析响应消息，导致插件维护困难，资源浪费严重(如大量占用服务器的CPU、内存资源)，而在本申请的方案中，对于每个第一类插件，可以基于特征库统一进行第一类请求报文的发送、第一类响应消息的接收以及第一类特征信息的匹配(例如，可以设置一个独立的进程进行统一处理)，直至获取到第一类特征信息后才需要将其交由各个第一类插件进行解析，从而有效整合了不同的插件中存在的重复处理逻辑，显著改善了漏洞扫描过程中的资源浪费，有利于加快漏洞扫描的过程，并且还有利于开发人员对插件以及特征库进行管理和维护。

[0084] 下面再对步骤S140进行进一步阐述，在一些实现方式中，步骤S140中可以增加字符串过滤操作，具体为：先基于第一类特征中包含的匹配规则生成筛选规则，然后利用筛选规则过滤第一类响应消息，得到剩余字符串，最后利用匹配规则从剩余字符串中获取第一类特征信息。

[0085] 在最原始方案中，直接利用匹配规则从第一类响应消息中提取第一类特征信息，在有时，比如匹配规则是复杂的正则表达式，而第一类响应消息数据量又比较大，提取第一类特征信息将会很慢。而在上述实现方式中，先利用筛选规则过滤掉第一类响应消息中的部分字符串，只对剩余字符串进行匹配，执行效率会提高不少。

[0086] 例如，若匹配规则是正则表达式，则筛选规则可以是该正则表达式的某种简化版本(满足筛选规则是满足匹配规则的必要条件)。从而基于筛选规则对第一类响应消息进行过滤，可以在短时间内将其中必然不可能满足匹配规则的字符串过滤掉，仅对剩余字符串进行正则匹配以提取第一类特征信息，即使正则匹配较慢，由于剩余字符串的数据量不大(在筛选规则设置得当时)，从而可以快速完成第一类特征信息的提取。此外，在本申请的方案中，对第一类响应消息进行过滤是统一进行的(例如，可以设置一个独立的进程进行统一处理)，并非是每个插件独立进行过滤，所以不仅过滤效率较高，而其筛选规则也具有通用性，不需要每个插件分别设置规则，开发维护起来都比较方便。

[0087] 下面在一个比较具体的场景下说明应该如何设置过滤规则。在该场景中，第一类特征中包含的匹配规则包括至少一个正则表达式，其中每个正则表达式用于获取一项第一类特征信息，则可以基于其中每个正则表达式所必须包含的字符串生成筛选规则。具体规则为：使得过滤后得到的剩余字符串中至少包含一个正则表达式所必须包含的全部字符串。

[0088] 例如，匹配规则为4个正则表达式，用于获取4项第一类特征信息：

[0089] 1.abc*de，必须包含的字符串为ab和de

[0090] 2.runoo+，必须包含的字符串为runoo

[0091] 3.colou？r，必须包含的字符串为colou和r

[0092] 4.bCha*，必须包含的字符串为bCh

[0093] 则筛选规则为：使得过滤后得到的剩余字符串中至少包含ab和de，或者至少包含runoo，或者至少包含colou和r，或者至少包含bCh。可以理解的，若不满足该筛选规则的字符串，必然不可能被正则1‑4中的任一项匹配上，当然，满足该筛选规则的字符串，也未必会被正则1‑4中的某项匹配上，但匹配上的概率会相对较高。从而，通过该筛选规则可以初步筛选出那些有可能被正则1‑4中的某项匹配上的字符串，在此基础上进一步做正则匹配，效率较高。并且不难看出，筛选规则仅仅涉及简单的字符串匹配，没有正则表达式中常见的通配符等复杂运算，筛选起来比较容易。

[0094] 进一步的，在利用上述筛选规则过滤第一类响应消息时，可以采用多模匹配算法(如Aho‑Corasick算法、Wu‑Manber算法等)，即利用多模匹配算法确定第一类响应消息中包含模式字符串(指算法中要查找的字符串)的剩余字符串，其中，模式字符串为任一正则表达式所必须包含的全部字符串。由于多模式匹配算法可以实现高效的多模式字符串匹配，从而有利于提高字符串过滤的效率。

[0095] 图3示出了本申请实施例提供的漏洞扫描装置200的功能模块图。参照图3，漏洞扫描装置200包括：

[0096] 插件加载模块210，用于加载用于扫描目标漏洞的插件，加载的插件中包括相互之间包含有相似的特征的第一类插件；其中，插件包含的特征由所述插件提取产生，所述特征为所述插件在发送请求报文以获取用于漏洞分析的特征信息的过程中涉及的关键信息，相似的特征是指包含的请求报文相同的特征；

[0097] 特征确定模块220，用于确定特征库中与所述第一类插件对应的第一类特征；其中，所述特征库由插件提取出的特征构成，在所述特征库中相似的多个特征被合并为一个特征保存；

[0098] 请求报文发送模块230，用于向目标主机发送所述第一类特征中包含的第一类请求报文，并接受所述目标主机返回的第一类响应消息；

[0099] 特征信息获取模块240，用于利用所述第一类特征中包含的匹配规则获取所述第一类响应消息中的第一类特征信息；

[0100] 漏洞分析模块250，用于利用所述第一类插件解析所述第一类特征信息，确定所述目标主机中有关所述目标漏洞的情况。

[0101] 在漏洞扫描装置200的一种实现方式中，特征信息获取模块240利用所述第一类特征中包含的匹配规则获取所述第一类响应消息中的第一类特征信息，包括：基于所述第一类特征中包含的匹配规则生成筛选规则，并利用所述筛选规则过滤所述第一类响应消息，得到剩余字符串；利用所述匹配规则从所述剩余字符串中获取所述第一类特征信息。

[0102] 在漏洞扫描装置200的一种实现方式中，所述第一类特征中包含的匹配规则包括至少一个正则表达式，其中每个正则表达式用于获取一项第一类特征信息，特征信息获取模块240基于所述第一类特征中包含的匹配规则生成筛选规则，并利用所述筛选规则过滤所述第一类响应消息，得到剩余字符串，包括：基于所述至少一个正则表达式中的每个正则表达式所必须包含的字符串生成筛选规则，所述筛选规则为：过滤后得到的剩余字符串中至少包含一个正则表达式所必须包含的全部字符串；利用所述筛选规则过滤所述第一类响应消息，得到所述剩余字符串。

[0103] 在漏洞扫描装置200的一种实现方式中，特征信息获取模块240利用所述筛选规则过滤所述第一类响应消息，得到所述剩余字符串，包括：利用多模匹配算法确定所述第一类响应消息中包含模式字符串的所述剩余字符串，所述模式字符串为任一正则表达式所必须包含的全部字符串。

[0104] 在漏洞扫描装置200的一种实现方式中，所述特征中包含有用于保存所述特征信息的字段，漏洞分析模块250利用所述第一类插件解析所述第一类特征信息，包括：向所述第一类特征的对应字段中写入所述第一类特征信息；利用所述第一类插件从所述第一类特征的对应字段中读取并解析所述第一类特征信息。

[0105] 在漏洞扫描装置200的一种实现方式中，所述合并后的特征中包含的匹配规则为合并前的多个特征中包含的匹配规则的并集。

[0106] 在漏洞扫描装置200的一种实现方式中，所述合并后的特征中还包含有表示每项匹配规则来源的特征所对应的插件的标注信息，所述标注信息用于标识利用所述匹配规则获取到的、不同的插件所需解析的不同的特征信息。

[0107] 在漏洞扫描装置200的一种实现方式中，请求报文发送模块230向目标主机发送所述第一类特征中包含的第一类请求报文，包括：根据预设的排序规则对所述第一类特征中包含的第一类请求报文进行排序，并根据排序结果依次向目标主机发送所述第一类请求报文；其中，所述排序规则为：使得同一个第一类插件对应的第一类请求报文在发送时间上尽可能相近。

[0108] 在漏洞扫描装置200的一种实现方式中，所述特征库有多个，同一个特征库中的特征均由带有同一种协议的插件提取产生，所述协议是指所述插件发送请求报文的协议。

[0109] 在漏洞扫描装置200的一种实现方式中，加载的用于扫描所述目标漏洞的插件还包括相互之间未包含有相似的特征的第二类插件；请求报文发送模块230还用于利用所述第二类插件向所述目标主机发送第二类请求报文，并接受所述目标主机返回的第二类响应消息；漏洞分析模块250还用于利用所述第二类插件解析所述第二类响应消息，确定所述目标主机中有关所述目标漏洞的情况。

[0110] 本申请实施例提供的漏洞扫描装置200，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法施例中相应内容。

[0111] 图4示出了本申请实施例提供的电子设备300的一种可能的结构。参照图4，电子设备300包括：处理器310、存储器320以及通信接口330，这些组件通过通信总线340和/或其他形式的连接机构(未示出)互连并相互通讯。

[0112] 其中，存储器320包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存储器(Random Access Memory，简称RAM)，只读存储器(Read Only Memory，简称ROM)，可编程只读存储器(Programmable Read‑Only Memory，简称PROM)，可擦除只读存储器(Erasable Programmable Read‑Only Memory，简称EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read‑Only Memory，简称EEPROM)等。处理器310以及其他可能的组件可对存储器320进行访问，读和/或写其中的数据。

[0113] 处理器310包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器310可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、微控制单元(Micro Controller Unit，简称MCU)、网络处理器(Network Processor，简称NP)或者其他常规处理器；还可以是专用处理器，包括图形处理器(Graphics Processing Unit，GPU)、数字信号处理器(Digital Signal Processor,简称DSP)、专用集成电路(Application Specific Integrated Circuits，简称ASIC)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。并且，在处理器310为多个时，其中的一部分可以是通用处理器，另一部分可以是专用处理器。

[0114] 通信接口330包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行数据的交互。通信接口330可以包括进行有线和/或无线通信的接口。

[0115] 在存储器320中可以存储一个或多个计算机程序指令，处理器310可以读取并运行这些计算机程序指令，以实现本申请实施例提供的漏洞扫描方法以及其他期望的功能。

[0116] 可以理解，图4所示的结构仅为示意，电子设备300还可以包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。图4中所示的各组件可以采用硬件、软件或其组合实现。电子设备300可能是实体设备，例如PC机、笔记本电脑、平板电脑、手机、服务器、嵌入式设备等，也可能是虚拟设备，例如虚拟机、虚拟化容器等。并且，电子设备300也不限于单台设备，也可以是多台设备的组合或者大量设备构成的集群。

[0117] 本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机的处理器读取并运行时，执行本申请实施例提供的漏洞扫描方法。例如，计算机可读存储介质可以实现为图4中电子设备300中的存储器320。

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

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

[0120] 再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

[0121] 以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。