048]封装单元，用于将经过编辑的报文体封装为待发送漏洞扫描请求报文；
[0049]发送单元，用于按照预先设置的时间周期向服务器发送所述漏洞扫描请求报文；
[0050]报文匹配单元，用于提取服务器返回的漏洞扫描响应报文，与预先设置的应用功能对应的标准请求响应报文进行匹配，以确定所述服务器是否存在漏洞。
[0051 ]优选地，所述预先设置的传输协议为超文本传输协议。
[0052]第三方面，本发明实施例提供一种电子设备，所述电子设备包括:壳体、处理器、存储器、电路板和电源电路，其中，电路板安置在壳体围成的空间内部，处理器和存储器设置在电路板上；电源电路，用于为上述电子设备的各个电路或器件供电；存储器用于存储可执行程序代码;处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的程序，用于执行前述任一所述的扫描漏洞的方法。
[0053]本发明实施例提供的扫描漏洞的方法、装置及电子设备，通过截获漏洞扫描请求报文，编辑报文体中的请求参数值来生成漏洞扫描请求报文，并按照预先设置的时间周期向服务器发送，依据响应报文实现对服务器漏洞的扫描，无需在不同的客户端中构造漏洞扫描请求报文，降低了实现服务器漏洞扫描所需的时间，从而提升漏洞扫描效率;进一步地，按照预先设置的时间周期向服务器发送封装的漏洞扫描请求报文，可以有效避免客户端预先设置的漏洞防范机制导致的服务器中存在的漏洞被漏检的情形，提高了漏洞扫描的准确率。
【附图说明】
[0054]为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
[0055]图1为本发明实施例扫描漏洞的方法流程示意图；
[0056]图2为本发明实施例扫描漏洞的装置结构示意图；
[0057]图3为本发明实施例的提取模块结构示意图；
[0058]图4为本发明实施例的编辑模块结构示意图；
[0059]图5为本发明第一实施例的漏洞扫描模块结构示意图；
[0060]图6为本发明第二实施例的漏洞扫描模块结构示意图；
[0061 ]图7为本发明电子设备一个实施例的结构示意图。
【具体实施方式】
[0062]下面结合附图对本发明实施例进行详细描述。
[0063]应当明确，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
[0064]图1为本发明实施例扫描漏洞的方法流程示意图。参见图1，该方法包括:
[0065]步骤11，截获客户端将要发送至服务器的各漏洞扫描请求报文；
[0066]本步骤中，在现有进行服务器漏洞扫描时，相关技术人员或维护人员可以通过依次调用客户端的应用功能，在调用的应用功能内容输入区中，输入有效载荷，客户端依据调用的应用功能以及输入的有效载荷，生成漏洞扫描请求报文，并向服务器提交。其中，有效载荷为进行漏洞扫描时构建的一些特殊输入数据。
[0067]作为一可选实施例，漏洞扫描请求报文可以是业务请求报文，也可以是构造测试报文。
[0068]本发明实施例中，考虑到通过客户端生成并向服务器提交的漏洞扫描请求报文，其中的一些请求参数是依据客户端的属性信息生成的，因而，不能在客户端对请求参数进行编辑，例如，漏洞扫描请求报文中包含的客户端标识，因而，不能进行编辑;进一步地，由于客户端预先设置的漏洞防范机制，可能使得服务器中存在的漏洞在客户端中被修复，例如，对于客户端要求生成验证码的情形，服务器在接收到客户端发送的包含验证码生成请求的漏洞扫描请求报文后，将生成的验证码下发给客户端，而在生成该客户端的验证码后，如果在预先设置的时间内再次接收到该客户端的验证码生成请求，是需要拒绝该验证码生成请求的，但由于客户端设置的漏洞防范机制，在客户端通过控件按钮发送一次验证码生成请求后，该控件按钮在设置的时间内失效，从而在客户端避免向服务器再次发送验证码生成请求。这样，如果服务器在预先设置的时间内再次接收到该客户端的验证码生成请求，未设置拒绝该验证码生成请求，使得服务器存在验证码漏洞，但通过该客户端发送的验证码生成请求，无法检测出服务器具有该验证码漏洞。因而，本发明实施例通过截获客户端将要发送至服务器的各漏洞扫描请求报文，从而可以对截获的漏洞扫描请求报文中的请求参数进行编辑，用以避免上述技术缺陷。
[0069]本发明实施例中，作为一可选实施例，可以是预先编写用于截获漏洞扫描请求报文的脚本，并将编写的脚本注入到客户端中。关于脚本编写为公知技术，在此略去详述。
[0070]步骤12，从截获的各漏洞扫描请求报文中，筛选出采用预先设置的传输协议传输的漏洞扫描请求报文；
[0071]本步骤中，作为一可选实施例，预先设置的传输协议为超文本传输协议(HTTP，Hypertext Transfer Protocol)，当然，实际应用中，预先设置的传输协议也可以是其他传输协议，例如，文件传输协议(FTP，File Transfer Protocol)、实时传输协议(RTP，Real_time Transport Protocol)ο
[0072]本发明实施例中，作为一可选实施例，筛选出采用预先设置的传输协议传输的漏洞扫描请求报文包括:
[0073]解析截获的漏洞扫描请求报文的报文头，如果解析得到的报文头中包含的相关字段为预先设置的传输协议字段，存储所述漏洞扫描请求报文。
[0074]本发明实施例中，对于未采用预先设置的传输协议传输的漏洞扫描请求报文，采用现有流程进行处理。
[0075]作为一可选实施例，在所述筛选出采用预先设置的传输协议传输的漏洞扫描请求报文之后，该方法还可以进一步包括:
[0076]对筛选出的漏洞扫描请求报文按照应用功能去重，获取每一应用功能对应的一漏洞扫描请求报文进行存储。
[0077]本步骤中，对于多个客户端发送的同一应用功能的漏洞扫描请求报文，由于后续中可以对漏洞扫描请求报文中的相关请求参数进行编辑，因而，对于针对同一应用功能的多份漏洞扫描请求报文，随机保留其中的一份漏洞扫描请求报文即可。
[0078]步骤13，对筛选出的漏洞扫描请求报文中的报文体进行解析，编辑解析的报文体中的请求参数值；
[0079]本步骤中，作为一可选实施例，对筛选出的漏洞扫描请求报文中的报文体进行解析，编辑解析的报文体中的请求参数值包括:
[0080]解析提取的漏洞扫描请求报文，得到解析的报文头以及报文体，依据所述解析的报文头判断客户端和服务器之间进行请求-响应时的方式:
[0081]如果所述客户端和服务器之间进行请求-响应时的方式为get方式，编辑报文体的统一资源定位符中的请求参数值；
[0082]如果所述客户端和服务器之间进行请求-响应时的方式为post方式，编辑报文体的包中的请求参数值。
[0083]本步骤中，客户端用于发送漏洞扫描请求报文，服务器用于接收漏洞扫描请求报文。客户端和服务器之间进行请求-响应时的方式包括:get方式以及post方式，其中，get方式用于从指定的资源(例如，服务器)请求数据，post方式用于向指定的资源提交要被处理的数据。
[0084]本发明实施例中，作为一可选实施例，报文体包括:统一资源定位符(URL，UniformResource Locator)以及包，对于get方式，请求参数以及请求参数对应的请求参数值包含在统一资源定位符中；对于post方式，请求参数以及请求