A method and system for verifying the effectiveness of WAF protection in a network security verification system

Abstract

The application discloses a kind of network security authentication system WAF protection effectiveness verification method and system, method includes: attacker simulator extracts malicious HTTP message object list in local Web security authentication scenario parameter file, malicious HTTP message object list is cyclically handled, including: in the case of encryption, request message and response message are decrypted;Custom request header information is added in request message;And by Socket, send processed malicious HTTP request message to attacker simulator;Attacker simulator receives data at configuration port, for the message with custom request header information, extract the value corresponding to custom request header information, obtain corresponding response message, and return to attacker simulator;Attacker simulator judges whether simulation attack succeeds based on the comparison of response message.The application can be compatible with various Web attack request message, improve system stability and reliability.

Description

TECHNICAL FIELD

[0001] The application relates to a method for verifying the effectiveness of a WAF protection in a network security verification system (BAS), and belongs to the technical field of network security. BACKGROUND

[0002] A Web Application Firewall (WAF) is also known as a website application-level intrusion prevention system, which aims to protect web applications from various web attacks. The WAF protection device can filter and security audit the traffic accessing the web application, and can detect and block abnormal / malicious traffic, thereby ensuring the security of the web application. A network security verification system (BAS system for short) verifies the effectiveness of the network security protection system constructed by a user in a lossless manner by simulating hacker attacks and intrusions, detects and evaluates the defense capability of an organization against emerging threats in a timely manner. It can help users verify security policies, detect potential weaknesses, and provide real-time feedback to help organizations improve their security defense capabilities.

[0003] The BAS system mainly includes a BAS application system and a simulator (divided into an attacker simulator and a victim simulator). The security verification process of the BAS system is as follows: 1) the application system creates a verification task, selects a certain number of scripts, and assigns them to the simulator for execution; 2) the simulator executes the configured scripts one by one; 3) the application system judges the execution result of each script, and the result includes non-interception, blocking, and warning; 4) the application system comprehensively evaluates the overall security system of the user based on the results of the scripts.

[0004] The current implementation of the BAS system for verifying the effectiveness of the WAF device has the following challenges: 1) there are many web attack methods, such as cross-site scripting (XSS), cross-site request forgery (CSRF), SQL injection attacks, file upload vulnerability attacks, etc., involving various languages, encoding formats, and attack ports. 2) The client network configuration strategy usually adopts a strict port opening restriction strategy, and the simulator cannot use multiple ports for attack simulation. 3) The HTTP request needs to be responded to by the corresponding port and method, and if there is no corresponding server to respond, a 404 response status code is usually received. However, malicious network attack requests are not only in the HTTP request message, but also in the response message. Only by simulating the entire process of malicious attack requests and responses can the attack be considered successful. Moreover, the 404 response status code is not conducive to result analysis (the HTTP request method may not exist), and it is difficult to confirm whether the malicious attack request has reached the specified target, which is not conducive to the authenticity and accuracy of the verification result. SUMMARY

[0005] Purpose of the invention: The purpose of the present invention is to provide a method and system for verifying the effectiveness of WAF protection in a network security verification system, which can be compatible with various types of Web attack request messages and improve system stability and reliability.

[0006] Technical solution: To achieve the above-mentioned purpose, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a method for verifying the effectiveness of WAF protection in a network security verification system, comprising the following steps:

[0008] The attacker simulator extracts the malicious HTTP message object list from the local Web security verification script parameter file;

[0009] The attacker simulator processes the malicious HTTP message object list in a loop, including: determining whether the malicious HTTP message object is encrypted, and if so, decrypting the request message and response message; adding custom request header information to the request message, wherein the custom request header information is used to locate the Web security verification script parameter file and the location of the malicious HTTP message object in the file; and sending the processed malicious HTTP request message to the attacked simulator via a socket;

[0010] The attacked simulator receives data at the configured port based on a network communication framework that supports TCP / IP and HTTP services. For messages with custom request header information, it extracts the value corresponding to the custom request header information, finds the response message corresponding to the malicious HTTP message object from the local Web security verification script parameter file, decrypts the object if it is encrypted, and returns the response message to the attacker simulator. If the response message is empty, it constructs a default response message and returns it to the attacker simulator.

[0011] The attacker simulator determines whether the simulated attack is successful based on the comparison between the local original response message and the returned response message of the attacked simulator.

[0012] Preferably, the Web security verification script parameter file includes: a malicious HTTP message object list for storing malicious HTTP messages of the same type; the malicious HTTP message objects include original malicious HTTP request messages, original malicious HTTP response messages, and a mark indicating whether the malicious HTTP message object is encrypted.

[0013] Preferably, the custom request header information includes the script unique identifier, the task number, the position of the current malicious HTTP message object in the list, and the unique identifier of the current malicious request.

[0014] Further, before extracting the list of malicious HTTP message objects in the local web security verification script parameter file, the attacker simulator further comprises: sending a test HTTP request to the attacked simulator to verify whether the attacker simulator and the attacked simulator can normally interact; if the attacker simulator receives a response message returned by the attacked simulator, and the content of the response message body is the expected value, it is considered that the normal interaction can be performed, and the task is continued to be executed.

[0015] Further, before extracting the list of malicious HTTP message objects in the local web security verification script parameter file, the attacker simulator further comprises: sending a test HTTP request to the attacked simulator to verify whether the attacker simulator and the attacked simulator can normally interact; if the attacker simulator receives a response message returned by the attacked simulator, and the content of the response message body is the expected value, it is considered that the normal interaction can be performed, and the task is continued to be executed.

[0016] Further, the attacked simulator comprises a custom HTTP Handler interceptor and a TCP Handler interceptor, the HTTP Handler interceptor is used for interaction between the attacker simulator and the attacked simulator, and the TCP Handler interceptor is used for responding to malicious requests sent by the web script.

[0017] Further, the attacker simulator judges whether the simulation attack is successful based on the comparison between the local original response message and the returned response message of the attacked simulator, and specifically comprises:

[0018] First, it is judged whether the returned response message is empty. If it is empty, the result is that the attack fails; otherwise, it is further judged whether the original response message is empty.

[0019] If the original response message is empty, it is judged whether the response body part in the returned response message is consistent with the preset content. If it is consistent, it is judged that the attack is successful; if it is not consistent, it is judged that the attack fails.

[0020] If the original response message is not empty, it is further judged whether the returned response message is consistent with the original response message. If it is consistent, the attack is successful; if it is not consistent, it is further judged whether the response body of the returned response message is consistent with the response body of the original response message. If it is consistent, the attack is successful; otherwise, the attack fails.

[0021] In a second aspect, the present application provides a network security verification system for WAF protection effectiveness verification, comprising a server, and an attacker simulator and an attacked simulator arranged on two sides of a WAF device; the attacker simulator is configured to extract a list of malicious HTTP message objects in a local web security verification script parameter file, and perform loop processing on the list of malicious HTTP message objects, including: judging whether the malicious HTTP message objects are encrypted, and if so, decrypting the request message and the response message; adding custom request header information in the request message, the custom request header information being used to locate the position of the web security verification script parameter file and the malicious HTTP message objects in the file; sending the processed malicious HTTP request message to the attacked simulator through a socket; and judging whether the simulated attack is successful based on the comparison between the local original response message and the returned response message of the attacked simulator.

[0022] The attacked simulator is configured to receive data at a configured port based on a network communication framework supporting TCP / IP and HTTP services, for a message with custom request header information, extract the value corresponding to the custom request header information, find the response message of the corresponding malicious HTTP message object from the local web security verification script parameter file, decrypt the object if encrypted, and return the response message to the attacker simulator, or construct a default response message and return it to the attacker simulator if the response message is empty.

[0023] Further, according to the configuration rules of the WAF device, it is judged whether the WAF device needs to perform reverse proxy, if the WAF device needs to perform reverse proxy, a protection site of the attacked simulator is added on the WAF device, and the attacked simulator is reverse proxied; the IP and port proxied out by the WAF device are configured on the network security verification system, and the attacker simulator attacks the IP and port proxied out; if the WAF device does not need to be configured with reverse proxy, the attacker simulator directly attacks the IP and port of the attacked simulator itself.

[0024] In a third aspect, the present application provides a computer program product comprising computer programs / instructions, which, when executed by a processor, implement the processing steps of the attacker simulator and / or the attacked simulator in the method for WAF protection effectiveness verification of the network security verification system.

[0025] Advantages: Compared with the prior art, the present application has the following advantages:

[0026] 1、The application realizes the comprehensive compatibility of the arbitrary format HTTP request message by sending the malicious HTTP request message through the Socket technology, ensures that the request message can be effectively processed regardless of the language or encoding format, thereby avoiding the parsing error or format incompatibility problem caused by the language or encoding difference.

[0027] 2、The application introduces the network communication framework such as Netty which supports TCP / IP and HTTP service as the message server, supports the HTTP service and TCP service at the same time, only needs to open one port, can meet the message communication demand between the simulators and process the malicious HTTP request, realizes the effective integration and utilization of resources, and the framework such as Netty can better cope with the complex network request environment, avoids the 404 error caused by the non-existent HTTP request method, and improves the stability and reliability of the system.

[0028] 3、The application specially processes the message of the request part when sending the malicious HTTP request message, adds the identification information, so that each request message has clear context information and task indication, simplifies the subsequent analysis work of the malicious HTTP request, and through the unified analysis process, can adapt to all malicious HTTP requests with identification information, realizes the efficient and accurate processing of the request message. BRIEF DESCRIPTION OF DRAWINGS

[0029] Figure 1 It is the HTTP protocol rule schematic diagram.

[0030] Figure 2 It is the overall flowchart of the embodiment of the application.

[0031] Figure 3 It is the web security verification script parameter file making flowchart.

[0032] Figure 4 It is the detailed flowchart of the WAF protection effectiveness verification method in the embodiment of the application.

[0033] Figure 5 It is the network security verification system deployment and verification flowchart of the embodiment of the application. DETAILED DESCRIPTION

[0034] The technical scheme of the application will be described clearly and completely in combination with the drawings and specific embodiments.

[0035] The present invention takes into account common Web attack methods, such as cross-site scripting (XSS), cross-site request forgery (CSRF), SQL injection attacks, file upload vulnerability attacks, etc., which are basically sending malicious HTTP requests to the target Web application. The WAF device detects these malicious traffic, detects which are malicious traffic and which are normal business request traffic, intercepts or issues an alarm for malicious traffic requests, and directly releases normal traffic. In order to verify the effectiveness of the WAF device protection, it is necessary to simulate the process of reproducing the Web attack to verify whether the WAF device can intercept or issue an alarm for the simulated attack.

[0036] Analyze the HTTP traffic packets generated by Web attacks using a professional network traffic analysis tool (Wireshark) and compare Figure 1 The HTTP protocol rules shown indicate that HTTP traffic packets from a web attack are divided into two parts: the first half is the malicious HTTP request message, and the second half is the response message from the web application after a successful attack. A malicious HTTP request may fail, leaving the second half of the response message empty. Based on the above analysis, the present invention considers saving malicious HTTP requests from web attacks as a web security script, which is then constructed during execution by the attacker simulator to create a standard HTTP request.

[0037] The present invention further takes into account that in a real network environment, the HTTP protocol belongs to the application layer in the TCP / IP five-layer network transmission protocol model. The application layer is the top layer of the model, which provides users with a method for communicating with the network. It contains various applications, including web browsers, e-mail, file transfer protocols, etc. These applications can construct application layer data packets and transmit data through the transport layer. Constructing an HTTP request is to construct an application layer data packet. The constructed application layer data packet is then transmitted to the network layer through the transport layer, and then can be sent to the corresponding target address. If the original message of a malicious HTTP request has been obtained, the process of constructing the standard HTTP protocol can be bypassed, and there is no need to send data through the HTTP protocol. Socket can be used directly to simulate this process, and the attacker simulator sends a malicious request to the target through the Socket.

[0038] For the HTTP request response and port resource problems, the application considers using network communication frameworks such as Netty, Mina, Twisted, etc. to build TCP / IP and HTTP servers on the attacker simulator. This embodiment takes the Netty framework as an example. In the Netty framework, developers can customize interceptors for classifying received data and assigning corresponding processors. For example, if we customize an HTTP interceptor for Netty, the interceptor will determine whether it is an HTTP message according to the message type (such as the Content-type field in the HTTP request header or other identifiers) when receiving data. Once it is confirmed that it is an HTTP message, the interceptor will pass the message to the designated HTTP message processor. In the processor method, we can further parse the content of the HTTP message, such as the request path, request parameters, request headers, etc., and then execute the corresponding business logic according to the parsing result, construct and return the corresponding response message. The Netty framework can accept any format of data and process these data through customized interceptors. Even for non-standard HTTP requests or unknown data formats, it can also be correctly processed according to the configuration, and it will not return a 404 error like traditional web servers. The Netty framework can save the opening of ports, and only one port needs to be opened to complete the corresponding task and interaction, reducing the customer's concern about the security of opening multiple ports.

[0039] However, it is a challenge to accurately match and respond to malicious requests sent by attackers, especially when the request method may be repeated but the parameter or request header content is different. In the Netty framework, although all requests can be received, it is not only a huge workload to write a special processor for each possible malicious request, but also not conducive to the maintenance and expansion of the system script. In view of this, the application considers adding identification information of the script in the request header of the malicious request when the attacker simulator sends the malicious request of the web script, which facilitates the analysis of the attacker simulator.

[0040] Based on the above analysis, the application discloses a method for verifying the effectiveness of WAF protection in a network security verification system, as shown in Figure 2 , mainly including the following steps:

[0041] The attacker simulator extracts the list of malicious HTTP message objects in the local web security verification script parameter file;

[0042] The attacker simulator loops through the list of malicious HTTP message objects, including: determining whether the malicious HTTP message object is encrypted, and if so, decrypting the request message and the response message; adding custom request header information in the request message, which is used to locate the web security verification script parameter file and the position of the malicious HTTP message object in the file; and sending the processed malicious HTTP request message to the attacked simulator via a Socket;

[0043] The attacked simulator receives data at a configured port based on the Netty framework, and for a message that includes custom request header information, extracts the value corresponding to the custom request header information, finds the response message of the corresponding malicious HTTP message object from the local web security verification script parameter file, decrypts the response message if the object is encrypted, and returns the response message to the attacker simulator, or constructs a default response message and returns it to the attacker simulator if the response message is empty.

[0044] The attacker simulator determines whether the simulation attack is successful based on a comparison between the local original response message and the returned response message from the attacked simulator.

[0045] In some embodiments, if it is uncertain whether the attacker simulator and the attacked simulator can interact normally, the attacker simulator may, before extracting the list of malicious HTTP message objects from the local web security verification script parameter file, also include: the attacker simulator sending a test HTTP request to the attacked simulator to verify whether the attacker simulator and the attacked simulator can interact normally; if the attacker simulator receives a response message returned by the attacked simulator, and the content of the response message body is the expected value, it is considered that normal interaction is possible, and the task is continued to be executed.

[0046] In some embodiments, if it is uncertain whether the attacker simulator and the attacked simulator have the script file locally, the attacker simulator may, before extracting the list of malicious HTTP message objects from the local web security verification script parameter file, also include: the attacker simulator determining whether a web script folder corresponding to the task exists locally, and if not, downloading a corresponding web script compressed package from the server and decompressing it; after successful downloading and decompression, the attacker simulator sends a HTTP task to download the web script to the attacked simulator, and after receiving a response from the attacked simulator indicating successful downloading and decompression, the task is continued to be executed.

[0047] Specifically, in this embodiment, the Web security verification script parameter file includes: a malicious HTTP message object list for storing malicious HTTP messages of the same type; the malicious HTTP message object includes an original malicious HTTP request message, an original malicious HTTP response message, and a flag indicating whether the malicious HTTP message object is encrypted. Specifically, an exemplary Web security verification script parameter file model.json has the following format:

[0048]

[0049]

[0050] The http_request_pair stores a list of malicious HTTP message objects, and malicious HTTP messages of the same type can be placed in this list. The malicious HTTP message object has three fields: raw_request represents the original malicious HTTP request message, raw_response represents the original malicious HTTP response message, and base64 indicates whether the current malicious HTTP message object is encrypted using base64 (true / false, encrypted true, and not encrypted false). Because the HTTP request object may contain some illegal characters or some garbled characters, in order to avoid the problem of garbled characters when displaying the content on the front-end page, the malicious HTTP message objects containing illegal characters or garbled characters are encrypted using base64, and the encrypted data is displayed on the front-end when displaying, while the attacker simulator will perform decryption when used.

[0051] In actual application, common cross-site scripting, cross-site request forgery, SQL injection attack, file upload vulnerability attack, and other attack process message files can be collected on platforms such as Github, or message files during execution of common mobile vulnerability scanning tools and sqlMap tools. Malicious HTTP request messages and corresponding response messages can be extracted manually or by code analysis.

[0052] As shown in Figure 3 , the collected malicious HTTP traffic messages are made into a Web script. The malicious HTTP traffic messages are split into request and response parts, and it is determined whether they contain illegal characters. If they contain illegal characters, they need to be encrypted using base64, and the base64 field value is set to true before being added to the HTTP request list. If they do not contain illegal characters, the base64 field value is set to false, and then added to the base64 list object. After adding, the HTTP request object is output to the Web security verification script parameter file model.json file.

[0053] The script has a unique identification scenario_id (for example: YSybujXFt89JDvxbTJ87C). In this embodiment, the model.json file is stored in a folder named with the unique identification scenario_id of the script, and is stored in the form of a compressed package (for example: YSybujXFt89JDvxbTJ87C.zip) in the server of the BAS system. When the corresponding script task is executed, the attacker simulator and the attacked simulator can download the compressed package file of the script file from the server and decompress it.

[0054] In this embodiment, the added custom request header information includes: Scenario (UUID of the script, unique identification), Task (task ID, corresponding batch of tasks), Entity (position of the current malicious HTTP message object in the list), and Flag (unique identification of the current malicious request, composed of 8 random characters). After receiving the request, the attacked simulator finds the corresponding script parameter file by extracting the Scenario information, finds the corresponding index parameter of the request in the http_request_pair request list in the script parameter file model.json through the Entity information, extracts the corresponding response message, and if the response message content is empty, a default response message is constructed based on the default rule, for example, a standard HTTP response message is returned based on the Flag information. In this way, the attacked simulator does not need to adapt to each type of request when responding, and as long as it follows this set of rules, it can adapt to all Web scripts, reducing the workload of Web script adaptation and facilitating the expansion of Web scripts in the later stage.

[0055] In this embodiment, the attacked simulator builds a Netty framework and sets the port to 10080. Custom HTTPHandler interceptor and TCP Handler interceptor, HTTP Handler interceptor is used for interaction between the attacker simulator and the attacked simulator, such as the attacker simulator sending a HTTP request to the attacked simulator to download the script file before starting to execute the task. This part of the interaction process is based on the HTTP protocol, and through the custom HTTP Handler, different HTTP requests are processed accordingly. The TCP Handler interceptor is used to respond to the malicious requests sent by the Web script.

[0056] The HTTP Handler interceptor process judges whether the received data contains HTTP request type information such as GET, POST, PUT, DELETE, etc. If the header information contains such information, it is judged whether the method (for example: / startDown) for downloading the script is contained, and then the corresponding download step is executed and the response result is returned to the attacker simulator. The TCP Handler interceptor process judges whether the received data contains the custom-added request header information Scenario, Task, Entity, and Flag. If the four corresponding header information values are contained, the Scenario script UUID is extracted to find the script folder, then the model.json file under the script folder is read, and the malicious HTTP message object list is extracted. According to the Entity value, the malicious HTTP message object corresponding to the subscript is found. After finding the corresponding malicious HTTP message object, it is also necessary to judge whether the value of the base64 field is true. If it is true, the raw_response field content needs to be base64 decrypted. After decryption, the raw_response field content is returned to the attacker simulator. If the raw_response field content is empty, a default response message needs to be constructed according to the Flag, and the Flag is returned to the attacker simulator as the response body.

[0057] The detailed implementation steps of the method for verifying the effectiveness of WAF protection in the network security verification system disclosed by the embodiments of the application are described below with reference to Figure 4

[0058] Step S101, after the attacker simulator receives the web security verification script parameters, it sends a test HTTP request (request method is / ping, parameter is flag, for example: http:

[0059] / / xxx.xxx.xxx.xxx:10080 / ping?test=1) to the attacked simulator. In order to verify whether the attacker simulator and the attacked simulator can normally interact, if the attacker simulator receives the response message returned by the attacked simulator, and the content of the response message body is the value of test, it is considered that the attacker simulator and the attacked simulator can normally interact, and the task continues to be executed. If there is no response message or the content of the response message body is inconsistent with the value of test, it is considered that the attacker simulator and the attacked simulator cannot normally interact, and the execution ends, and a failure result is returned to the server.

[0060] ​In step S102, the attacker simulator determines whether the corresponding Web script folder exists locally. If not, it goes to the server to download the corresponding Web script compressed package. If the download fails, it directly returns the download failure result to the server. After the download is successful, the script compressed package is decompressed. If the decompression fails, the decompression failure result is returned to the server. After the decompression is successful, the HTTP task of downloading the Web script is sent to the attacked simulator. After the attacked simulator receives the task of downloading the Web script, it will also determine whether the corresponding Web script file exists locally. If it exists, it returns a successful response to the attacker simulator. If not, it goes to the server to download the corresponding Web script compressed package. If the download fails, it returns a failed response result to the attacker simulator. If the download is successful, the Web script compressed package is decompressed again. If the decompression fails, the failed response result is returned to the attacker simulator. If the decompression is successful, it returns a successful response to the attacker simulator. The attacker simulator determines whether to proceed to the next step based on the success or failure response result returned by the attacked simulator. If a failure response result is received, the attacker simulator returns the result of the failure to download the script file to the server. If a success response result is received, the attacker simulator proceeds to the next step.

[0061] Step S103: The attacker simulator extracts the file content of the Web security verification script parameter file model.json. If the extracted content is empty, it is judged that the task is abnormal and there are no executable parameters; if the content is not empty, it continues to parse and extract the malicious HTTP message object list. If the parsing fails or the extracted malicious HTTP message object list is empty, it is judged that the task is abnormal and the executable parameter parsing fails. If the malicious HTTP message object list is not empty, it continues to execute.

[0062] Step S104: the attacker simulator loops through the list of malicious HTTP message objects. First, it needs to determine whether the malicious HTTP message object is encrypted using base64. If the base64 field value of the malicious HTTP message object is true, it is determined that the current malicious HTTP message object is encrypted using base64, and the original request message and the original response message need to be decrypted using base64. If the base64 field value of the malicious request object is false, the original request message and the original response message do not need to be decrypted using base64. Then the original request message is processed, and the request header part and the request parameter part of the original request message are segmented according to "\n\n". Four request header information, Scenario, Task, Entity, and Flag, are added after the request header. After the addition, the added request header and the request parameter are spliced again through "\n\n" to form a complete request message. Then the processed request message is sent to the attacked simulator through Socket. The response message received is judged.

[0063] Step S105: the attacker simulator judges the result of the returned response message. First, it is determined whether the returned response message is empty. If the returned response message is empty, the attack is determined to be unsuccessful. If the returned response message is not empty, it is determined whether the original response message is empty. If the original response message is empty, it is determined whether the response body part in the returned response message is consistent with the Flag value constructed when the malicious request is sent. If they are consistent, the attack is determined to be successful. If they are not consistent, the attack is determined to be unsuccessful. If the original response message is not empty, it is determined whether the returned response message is consistent with the original response message. If they are consistent, the attack is determined to be successful. If they are not consistent, it is determined whether the response body of the returned response message is consistent with the response body of the original response message. Because some WAF security protection devices encapsulate all response header parts, we need to compare the consistency of the response body parts. If the response body part of the returned response message is consistent with the response body part of the original response message, the attack is determined to be successful. Otherwise, the attack is determined to be unsuccessful.

[0064] Step S106: the attacker simulator judges the result of the list of malicious HTTP message objects. If all the malicious HTTP message objects in the list of malicious HTTP message objects are successfully attacked, the result of the web script task is determined to be unblocked. If one or more malicious HTTP message objects in the list of malicious HTTP message objects fail, the result of the web script task is determined to be an alarm. If all the malicious HTTP message objects in the list of malicious HTTP message objects fail, the result of the web script task is determined to be blocked.

[0065] Step S107, the attacker simulator returns the web script task execution result to the server.

[0066] Based on the same inventive concept, the embodiment of the present application also discloses a network security verification system for WAF protection effectiveness verification, comprising a server, and an attacker simulator and an attacked simulator arranged on both sides of a WAF device; the attacker simulator is used for extracting a list of malicious HTTP message objects in a local web security verification script parameter file, and performing loop processing on the list of malicious HTTP message objects, including: judging whether the malicious HTTP message objects are encrypted, and if yes, decrypting the request message and the response message; adding custom request header information in the request message, the custom request header information being used for locating the positions of the web security verification script parameter file and the malicious HTTP message objects in the file; sending the processed malicious HTTP request message to the attacked simulator through a Socket; and judging whether the simulation attack is successful based on the comparison between the local original response message and the returned response message of the attacked simulator; the attacked simulator is used for receiving data on a configured port based on a Netty framework, for the message with the custom request header information, extracting the value corresponding to the custom request header information, finding the response message of the corresponding malicious HTTP message object from the local web security verification script parameter file, decrypting the object if encrypted, and returning the response message to the attacker simulator, and if the response message is empty, constructing a default response message and returning the same to the attacker simulator.

[0067] In addition, in the embodiment, considering the protection configuration of a common WAF, taking the Changting WAF as an example, the WAF is used to proxy the web application website needing protection in a reverse proxy manner, and a user accesses the web application website by accessing the address of the Changting WAF reverse proxy, therefore, in this case, the attacked simulator also needs the Changting WAF to configure a reverse proxy, and add proxy IP and proxy port configurations, and the attacker simulator can judge whether to attack the IP and port of the attacked simulator itself or the IP and port of the proxy according to whether the attacked simulator is configured with the proxy IP and the proxy port.

[0068] As shown in Figure 5 The complete flow of implementing the client web website security verification mainly includes:

[0069] Step S201, according to the protection device of the customer Web site and the protection strategy, a customized installation deployment scheme is installed, and the WAF protection device is taken as an example, the customer's Web site is attacked by the attacker simulator and the attacked simulator on both sides of the WAF security protection device, and the attacked simulator is simulated to the WAF protection device through the reverse proxy, and the real network scene of the customer is simulated.

[0070] Step S202, according to the WAF device configuration rule, it is judged whether the WAF device needs to be reverse proxy, if the WAF device needs to be reverse proxy, the protection site of the attacked simulator is added on the WAF device, and the attacked simulator is reverse proxy. The attacked simulator needs to configure the IP and port of the WAF device agent on the BAS system, and the attacker simulator attacks the IP and port of the agent; if the WAF device does not need to configure reverse proxy, the attacker simulator directly attacks the IP and port of the attacked simulator itself.

[0071] Step S203, create a task, select a Web security verification script, and select an attacker simulator and an attacked simulator deployed on both sides of the WAF protection device.

[0072] Step S204, assemble parameters, according to the selected Web security verification script, the attacker simulator and the attacked simulator, the execution parameters required for executing the script are automatically assembled.

[0073] Step S205, task dispatching, the attacker simulator automatically initiates a task request to the server, and the server returns the execution parameter information of the Web security verification script to the attacker simulator.

[0074] Step S206, after the attacker simulator receives the Web security verification script parameters, the task is executed according to steps S101 to S107 to obtain the task execution result.

[0075] Step S207, after the server receives the execution result returned by the attacker simulator, it is judged whether the script under the task has been executed completely, if it has been executed completely, the task is ended, and a security verification report is automatically generated.

[0076] The embodiment of the application also discloses a computer program product, which comprises computer programs / instructions, and the computer programs / instructions are executed by a processor to realize the processing steps of the attacker simulator and / or the attacked simulator in the WAF protection effectiveness verification method of the network security verification system.

Claims

1. A method for verifying the effectiveness of WAF protection in a network security verification system, characterized in that: The steps include: The attacker simulator extracts the malicious HTTP message object list from the local Web security verification script parameter file; The attacker simulator processes the malicious HTTP message object list in a loop, including: determining whether the malicious HTTP message object is encrypted, and if so, decrypting the original malicious HTTP request message and the original malicious HTTP response message; adding custom request header information to the original malicious HTTP request message, wherein the custom request header information is used to locate the Web security verification script parameter file and the location of the malicious HTTP message object in the file; and sending the processed malicious HTTP request message to the attacked simulator via a socket; The attacked simulator receives data at the configured port based on a network communication framework that supports TCP / IP and HTTP services. For messages with custom request header information, it extracts the value corresponding to the custom request header information, finds the response message corresponding to the malicious HTTP message object from the local Web security verification script parameter file, decrypts the object if it is encrypted, and returns the response message to the attacker simulator. If the response message is empty, it constructs a default response message and returns it to the attacker simulator. The attacker simulator determines whether the simulated attack is successful based on the comparison between the local original malicious HTTP response message and the returned response message of the attacked simulator.

2. The method for verifying the effectiveness of WAF protection in a network security verification system according to claim 1, characterized in that: The Web security verification script parameter file includes: a malicious HTTP message object list for storing malicious HTTP messages of the same type; the malicious HTTP message objects include original malicious HTTP request messages, original malicious HTTP response messages, and a mark indicating whether the malicious HTTP message object is encrypted.

3. The method for verifying the effectiveness of WAF protection in a network security verification system according to claim 1, characterized in that: The custom request header information includes the script unique identifier, the task number, the position of the current malicious HTTP message object in the list, and the unique identifier of the current malicious request.

4. The method for verifying the effectiveness of WAF protection in a network security verification system according to claim 1, characterized in that: Before the attacker simulator extracts the malicious HTTP message object list in the local Web security verification script parameter file, it also includes: the attacker simulator sends a test HTTP request to the attacked simulator to verify whether the attacker simulator and the attacked simulator can interact normally; if the attacker simulator receives a response message returned by the attacked simulator, and the content of the response message body is the expected value, it is considered that normal interaction can be carried out and the task continues to be executed.

5. The method for verifying the effectiveness of WAF protection in a network security verification system according to claim 1, characterized in that: Before the attacker simulator extracts the malicious HTTP message object list in the local Web security verification script parameter file, it also includes: the attacker simulator determines whether there is a Web script folder corresponding to the task locally. If not, it downloads the corresponding Web script compressed package from the server and decompresses it; after the download and decompression are successful, it sends an HTTP task to download the Web script to the attacked simulator, and continues to execute the task after receiving a response from the attacked simulator that the download and decompression are successful.

6. The method for verifying the effectiveness of WAF protection in a network security verification system according to claim 1, characterized in that: The victim simulator customizes an HTTP Handler interceptor and a TCP Handler interceptor. The HTTP Handler interceptor is used for interaction between the attacker simulator and the victim simulator. The TCP Handler interceptor is used for responding to malicious requests sent by the Web class script.

7. The method for verifying the effectiveness of WAF protection in a network security verification system according to claim 1, characterized in that: The attacker simulator determines whether the simulated attack is successful based on the comparison between the local original malicious HTTP response message and the returned response message of the attacked simulator, specifically including: First, determine whether the returned response message is empty. If so, the attack is considered failed. Otherwise, determine whether the original malicious HTTP response message is empty. If the original malicious HTTP response message is empty, then determine whether the response body in the returned response message is consistent with the preset content. If it is consistent, the attack is considered successful; if not, the attack is considered failed. If the content of the original malicious HTTP response message is not empty, then determine whether the returned response message is consistent with the original malicious HTTP response message. If they are consistent, the attack is judged to be successful. If not, then determine whether the response body of the returned response message is consistent with the response body of the original malicious HTTP response message. If they are consistent, then determine whether the attack is successful. Otherwise, the attack is judged to be failed.

8. A network security verification system for verifying the effectiveness of WAF protection, comprising a server, an attacker simulator and an attacked simulator provided on both sides of a WAF device; characterized in that: The attacker simulator is used to extract a list of malicious HTTP message objects in a local Web security verification script parameter file and perform cyclic processing on the list of malicious HTTP message objects, including: determining whether the malicious HTTP message object is encrypted, and if encrypted, decrypting the original malicious HTTP request message and the original malicious HTTP response message; adding custom request header information to the original malicious HTTP request message, wherein the custom request header information is used to locate the Web security verification script parameter file and the position of the malicious HTTP message object in the file; sending the processed malicious HTTP request message to the attacked simulator via a Socket; and determining whether the simulated attack is successful based on the comparison between the local original malicious HTTP response message and the return response message of the attacked simulator; The attacked simulator is used to receive data at a configured port based on a network communication framework that supports TCP / IP and HTTP services. For messages with custom request header information, the value corresponding to the custom request header information is extracted, and the response message corresponding to the malicious HTTP message object is found from the local Web security verification script parameter file. If the object is encrypted, it is decrypted and the response message is returned to the attacker simulator. If the response message is empty, a default response message is constructed and returned to the attacker simulator.

9. The network security verification system for WAF protection effectiveness verification according to claim 8, characterized in that: Based on the WAF device configuration rules, determine whether the WAF device needs to perform reverse proxy. If the WAF device needs to perform reverse proxy, add a protection site for the victim simulator on the WAF device and use it as a reverse proxy for the victim simulator. Configure the IP and port proxied by the WAF device on the network security verification system. When the attacker simulator attacks, it will attack the proxied IP and port. If the WAF device does not need to be configured with a reverse proxy, the attacker simulator will directly attack the IP and port of the attacked simulator itself.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by the processor, the processing steps of the attacker simulator and / or the attacked simulator in the method for verifying the effectiveness of WAF protection in a network security verification system according to any one of claims 1 to 7 are implemented.

Images