WAF protection validity verification method and system in network security verification system

Abstract

The invention discloses a WAF protection validity verification method and system in a network security verification system, and the method comprises the steps: an attacker simulator extracts a malicious HTTP message object list in a local Web security verification script parameter file, and carries out the circulation processing of the malicious HTTP message object list, comprising the following steps: decrypting a request message and a response message under an encryption condition; adding custom request header information in the request message; the processed malicious HTTP request message is sent to the attacked person simulator through the Socket; the attacker simulator receives data at the configuration port, extracts a value corresponding to the custom request header information for the message with the custom request header information, obtains a corresponding response message, and returns the response message to the attacker simulator; and the attacker simulator judges whether the simulation attack is successful or not based on the comparison condition of the response message. The method can be compatible with various Web attack request messages, and the stability and reliability of the system are improved.

Description

Technical Field

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

[0002] Web Application Firewall (WAF), also known as website application-level intrusion prevention system, is designed to protect web applications from various web attacks. WAF protection devices can filter and perform security audits on traffic accessing web applications, detect and block abnormal / malicious traffic, and thus ensure the security of web applications. The network security verification system (BAS system for short) verifies the effectiveness of the network security protection system that users have built by simulating hacker attacks and intrusions, and timely detects and evaluates the organization's defense capabilities against emerging threats. 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 is mainly divided into the BAS application system and the simulator (divided into the attacker simulator and the attacked simulator). The process of BAS system security verification is as follows: 1) Create a verification task through the application system, select a certain number of scripts and assign them to the simulator for execution; 2) The simulator executes the configured scripts in sequence; 3) The application system determines the execution result of each script, including non-interception, blocking, and alarm; 4) The application system integrates the results of the script and conducts an overall assessment of the user's security system.

[0004] Currently, there are the following challenges in implementing the validity verification of WAF devices in the BAS system: 1) There are many Web attack methods, such as cross-site scripting attacks (XSS), cross-site request forgery (CSRF), SQL injection attacks, file upload vulnerability attacks, etc., involving various languages, encoding formats and attack ports. 2) Usually, the customer network configuration policy will adopt a policy that strictly limits the port opening, and the simulator cannot use multiple ports for attack simulation. 3) HTTP requests require a corresponding port and method to respond. If there is no corresponding server to respond, a 404 response status code will usually be received. Malicious network attack requests are not only reflected in the HTTP request message, but there are also some data leakage problems in the response message. Only when the malicious attack request and response process are completely simulated can the attack be considered successful. In addition, the 404 response status code is not conducive to result analysis (it may be that the HTTP request method does not exist), and it is impossible to confirm whether the malicious attack request has reached the specified target, which is not conducive to reflecting the authenticity and accuracy of the verification results. Summary of the invention

[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 invention object, 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 it is encrypted, decrypting the request message and the 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 position of the malicious HTTP message object in the file; and sending the processed malicious HTTP request message to the attacked simulator through Socket;

[0010] The attacked simulator receives data at the configured port based on the 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 a unique identifier of the script, a task number, a position of the current malicious HTTP message object in the list, and a unique identifier of the current malicious request.

[0014] Furthermore, 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 can continue to be executed.

[0015] Furthermore, 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, and if not, downloads the corresponding Web script compression package from the server and decompresses it; after the download and decompression are successful, the HTTP task of downloading the Web script is sent to the attacked simulator, and after receiving the response of the attacked simulator that the download and decompression is successful, the task continues to be executed.

[0016] Furthermore, a custom HTTP Handler interceptor and a TCP Handler interceptor are provided in the attacked simulator. The HTTP Handler interceptor is used for interaction between the attacker simulator and the attacked simulator, and the TCP Handler interceptor is used for correspondingly responding to malicious requests sent by the Web class script.

[0017] Furthermore, 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, specifically including:

[0018] First, determine whether the returned response message is empty. If it is empty, the result is that the attack fails. Otherwise, determine whether the original response message is empty.

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

[0020] If the content of the original response message is not empty, then determine whether the returned response message is consistent with the original 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 response message. If they are consistent, the attack is judged to be successful. Otherwise, the attack is judged to be unsuccessful.

[0021] In a second aspect, the present invention provides a network security verification system for verifying the effectiveness of WAF protection, including a server, and an attacker simulator and an attacked simulator arranged on both sides of the WAF device; 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 it is encrypted, decrypting the request message and the response message; adding custom request header information to the request message, and 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 through a Socket; and determining whether the simulated attack is successful based on the comparison between the local original response message and the return response message of the attacked simulator;

[0022] 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.

[0023] Furthermore, according to the WAF device configuration rules, determine whether the WAF device is required to perform reverse proxy. If the WAF device is required to perform reverse proxy, add a protection site of the attacked simulator on the WAF device to reverse proxy the attacked simulator; configure the IP and port proxied by the WAF device on the network security verification system, and attack the IP and port proxied by the attacker simulator when attacking; if the WAF device does not need to be configured with a reverse proxy, the attacker simulator directly attacks the IP and port of the attacked simulator itself.

[0024] In a third aspect, the present invention provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the processing steps of an attacker simulator and / or an attacked simulator in the method for verifying the effectiveness of WAF protection in the network security verification system.

[0025] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0026] 1. The present invention uses Socket technology to send malicious HTTP request messages, thereby achieving full compatibility with HTTP request messages in any format, ensuring that no matter what language or encoding format the request message uses, it can be effectively processed, thereby avoiding parsing errors or format incompatibility problems caused by different languages ​​or encoding differences.

[0027] 2. The present invention introduces a network communication framework such as Netty that supports TCP / IP and HTTP services as a message service end, and supports both HTTP services and TCP services. Only one port needs to be opened to meet the message communication needs between simulators and handle malicious HTTP requests, thus achieving effective integration and utilization of resources. In addition, frameworks such as Netty can better cope with complex network request environments, avoid 404 errors caused by the non-existence of HTTP request methods, and improve the stability and reliability of the system.

[0028] 3. When sending malicious HTTP request messages, the present invention performs special processing on the request part of the message and adds identification information, so that each request message has clear context information and task instructions, simplifying the subsequent parsing of malicious HTTP requests. Through a unified parsing process, it can adapt to all malicious HTTP requests with identification information, and realize efficient and accurate processing of request messages. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 This is a schematic diagram of HTTP protocol rules.

[0030] Figure 2 It is an overall flow chart of an embodiment of the present invention.

[0031] Figure 3 A flowchart for creating a parameter file for a Web security verification script.

[0032] Figure 4 The following is a detailed flow chart of the WAF protection effectiveness verification method in an embodiment of the present invention.

[0033] Figure 5 This is a flow chart of deployment and verification of a network security verification system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0034] The technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying 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, and the WAF device detects these malicious traffic, detects which are malicious traffic and which are normal business request traffic, intercepts or warns the request for malicious traffic, and directly releases the normal traffic. In order to verify the effectiveness of WAF device protection, it is necessary to simulate the process of reproducing Web attacks, so as to verify whether the WAF device can intercept or warn 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 in the figure show that the HTTP traffic message of the Web attack is divided into two parts, the first half is the HTTP malicious request message, and the second half is the response message of the Web application after the attack is successful. The HTTP malicious request may fail in the attack, and the response message in the second half may be empty. Based on the above analysis, the present invention considers saving the malicious HTTP request during the Web attack as a Web site security script, and then the attacker simulator is constructed during execution to construct a standard HTTP request.

[0037] The present invention further considers 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 a method for users to communicate with the network, including various applications, including Web browsers, e-mails, file transfer protocols, etc. These applications can construct data messages of the application layer and transmit data through the transport layer. Constructing an HTTP request is to construct a data message of the application layer. The constructed application layer data message 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 the malicious HTTP request has been obtained, the process of constructing the standard HTTP protocol can be bypassed, and data does not need to be sent through the HTTP protocol. Socket can be directly used to send to simulate this process, and the attacker simulator sends malicious requests to the target through Socket.

[0038] In view of the HTTP request response and port resource problems, the present invention considers using network communication frameworks such as Netty, Mina, Twisted, etc. to build TCP / IP and HTTP servers on the attacked simulator. This embodiment is explained by taking the Netty framework as an example. In the Netty framework, developers can customize interceptors to classify the received data and assign corresponding processors. For example: If we customize an HTTP interceptor for Netty, when receiving data, the interceptor will determine whether it is an HTTP message based on the message type (such as the Content-type field or other identifiers in the HTTP request header). Once it is confirmed that it is an HTTP message, the interceptor will pass the message to the specified 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 header, etc., and then execute the corresponding business logic according to the parsing results, construct and return the corresponding response message. The Netty framework can accept data in any format and classify and process these data through a customized interceptor. Even for non-standard HTTP requests or unknown data formats, it can be correctly processed according to the configuration, and will not return a 404 error like a traditional Web server. The Netty framework can save the opening of ports. Only one port needs to be opened to complete the corresponding tasks and interactions, reducing customers' concerns 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 parameters or request header content are different. In the Netty framework, although all requests can be received, directly writing a dedicated processor for each possible malicious request is not only a huge workload, but also not conducive to the maintenance and expansion of the system script. In view of this, the present invention considers adding the identification information of the script in the request header of the malicious request when the attacker simulator sends a malicious request for the Web script, so as to facilitate the parsing of the attacked simulator.

[0040] Based on the above analysis, a method for verifying the effectiveness of WAF protection in a network security verification system disclosed in an embodiment of the present invention is as follows: Figure 2 As shown, it mainly includes the following steps:

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

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

[0043] The attacked simulator receives data at the configured port based on the Netty framework. 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.

[0044] 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.

[0045] In some embodiments, if it is uncertain whether the attacker simulator and the attacked simulator can interact normally, the attacker simulator may also include before extracting the list of malicious HTTP message objects in the local Web security verification script parameter file: 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.

[0046] In some embodiments, if it is uncertain whether the attacker simulator and the attacked simulator have script files locally, 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, downloads the corresponding Web script compression package from the server and decompresses it; after the download and decompression are successful, an HTTP task for downloading the Web script is sent to the attacked simulator, and after receiving a response from the attacked simulator that the download and decompression is successful, the task continues to be executed.

[0047] Specifically, in this embodiment, the Web security verification script parameter file includes: a malicious HTTP message object list, which is used to store malicious HTTP messages of the same type; the malicious HTTP message object includes the original malicious HTTP request message, the original malicious HTTP response message, and a mark indicating whether the malicious HTTP message object is encrypted. Specifically, the exemplary Web security verification script parameter file model.json format is as follows:

[0048]

[0049]

[0050] Among them, http_request_pair stores a list of malicious HTTP message objects. All malicious HTTP messages of the same type can be put into this list. There are three fields in the malicious HTTP message object, namely: raw_request represents the original malicious HTTP request message, raw_response represents the original malicious HTTP response message, and base64 represents whether the current malicious HTTP message object uses base64 encryption (true / false, true for encryption, false for non-encryption). Because the HTTP request object may contain some illegal characters or some garbled characters, in order to avoid the garbled problem when displaying this content on the front-end page, base64 encryption is performed on these malicious HTTP message objects containing illegal characters or garbled characters, and the encrypted data is displayed when the front-end is displayed, and the attacker simulator will only decrypt it when it is used.

[0051] In actual application, you can collect common attack process message files such as cross-site scripting attacks, cross-site request forgery, SQL injection attacks, file upload vulnerability attacks, etc. on platforms such as Github, or message files during the execution of common vulnerability scanning tools and sqlMap tools on mobile phones, and extract malicious HTTP request messages and corresponding response messages through manual extraction or code parsing.

[0052] like Figure 3 As shown, the collected malicious HTTP traffic messages are made into a Web script. The malicious HTTP traffic messages are split into a request part and a response part, and it is determined whether they contain illegal characters. If they contain illegal characters, base64 encryption is required, and the base64 field value is set to true before adding them 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 will have a unique identifier scenario_id (e.g., YSybujXFt89JDvxbTJ87C). In this embodiment, the model.json file is stored in a folder named after the unique identifier scenario_id of the script, and is stored in the form of a compressed package (e.g., YSybujXFt89JDvxbTJ87C.zip) on the server side of the BAS system. When executing the corresponding script task, the attacker simulator and the attacked simulator can download the compressed package file of the script file from the server side and decompress it.

[0054] In this embodiment, the added custom request header information includes: Scenario (UUID of the script, unique identifier), Task (task ID, corresponding to the batch of tasks), Entity (the position of the current malicious HTTP message object in the list), Flag (the unique identifier of the current malicious request, consisting of 8 random characters). After the attacked simulator receives the request, it finds the corresponding script parameter file by extracting the Scenario information, and finds the corresponding subscript parameter of the request in the http_request_pair request list in the script parameter file model.json through the Entity information, and extracts the corresponding response message therefrom. If the response message content is empty, a default response message will be constructed based on the default rules, for example, based on the Flag information, a standard HTTP response message will be constructed and returned. In this way, there is no need for the attacked simulator to adapt each request when responding. As long as this set of rules is followed, all Web scripts can be adapted, reducing the workload of Web script adaptation and making it easier to expand Web scripts in the later stage.

[0055] In this embodiment, the attacked simulator builds the Netty framework and sets the port to 10080. Custom HTTPHandler interceptor and TCP Handler interceptor, HTTP Handler interceptor is used for the attacker simulator and the attacked simulator to interact. For example, the attacker simulator will send an 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. Through the custom HTTP Handler, corresponding processing is performed according to different HTTP requests. The TCP Handler interceptor is used to respond to malicious requests sent by Web-class scripts.

[0056] The HTTP Handler interceptor processes the data by determining whether it contains HTTP request type information, such as GET, POST, PUT, DELETE, etc. If it contains such header information, it determines whether it contains the method for downloading the script (for example: / startDown), then executes the corresponding download steps and returns the response result to the attacker simulator. The TCP Handler interceptor processes the data by judging whether the received data contains the custom added request header information Scenario, Task, Entity, and Flag. If so, it extracts the values ​​corresponding to the four corresponding header information, and uses the UUID of the extracted Scenario script to find the script folder. Then it reads the model.json file in the script folder, extracts the list of malicious HTTP message objects, and then finds the malicious HTTP message object with the corresponding subscript according to the Entity value. After finding the corresponding malicious HTTP message object, it is also necessary to first determine whether the value of the base64 field is true. If it is true, it is necessary to perform base64 decryption on the raw_response field content, and then return the raw_response field content to the attacker simulator after decryption. If the raw_response field content is empty, it is necessary to construct a default response message according to Flag, and Flag is returned to the attacker simulator as the response body.

[0057] Reference below Figure 4 , describing the detailed implementation steps of a method for verifying the effectiveness of WAF protection in a network security verification system disclosed in an embodiment of the present invention.

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

[0059] / / xxx.xxx.xxx.xxx:10080 / ping? test=1), in order 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, 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 interact normally and continue to execute the task; if there is no response message or the content of the response message response body is inconsistent with the test value, it is considered that the attacker simulator and the attacked simulator cannot interact normally, the execution is terminated, and the execution failure result is returned to the server.

[0060] In step S102, the attacker simulator determines whether there is a corresponding Web script folder 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 there is a corresponding Web script file 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, a successful response is returned 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 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 processes the malicious HTTP message object list in a loop. First, it is necessary to determine whether the malicious HTTP message object is encrypted with 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 with base64, and the original request message and the original response message need to be decrypted with 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 with base64. Then the original request message is processed, and the request header part and the request parameter part of the original request message are separated according to "\n\n", and the four request header information of Scenario, Task, Entity, and Flag are added after the request header. After the addition is completed, 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. And the result is judged according to the received response message.

[0063] Step S105, the attacker simulator judges the result according to the received return response message, first judges whether the return response message is empty, if the return response message is empty, the judgment result is that the attack fails; if the return response message is not empty, then judge whether the original response message is empty, if the original response message is empty, then judge whether the response body part in the return response message is consistent with the Flag value constructed when the malicious request is sent, if consistent, then judge that the attack is successful, if inconsistent, then judge that the attack fails; if the content of the original response message is not empty, then judge whether the return response message is consistent with the original response message, if consistent, then judge that the attack is successful, if inconsistent, then judge whether the response body of the return response message is consistent with the response body of the original response message, because some WAF security protection devices will encapsulate all response header parts, so we need to compare whether the response body parts are consistent, if the response body part of the return response message is consistent with the response body part of the original response message, then judge that the attack is successful, otherwise, if inconsistent, then judge that the attack fails.

[0064] Step S106, the attacker simulator judges the result of the malicious HTTP message object list. If all the malicious HTTP message objects in the malicious HTTP message object list are successfully attacked, the result of the Web script task is judged as not intercepted; if one or more malicious HTTP message objects in the malicious HTTP message object list fail to attack, the result of the Web script task is judged as an alarm; if all the malicious HTTP message objects in the malicious HTTP message object list fail to attack, the result of the Web script task is judged as blocked.

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

[0066] Based on the same inventive concept, an embodiment of the present invention also discloses a network security verification system for verifying the effectiveness of WAF protection, including a server, and an attacker simulator and an attacked simulator arranged on both sides of the WAF device; 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 it is encrypted, decrypting the request message and the response message; adding custom request header information to the request message, and the custom request header information is used to locate the Web security verification script parameter file and the malicious HTTP message object in the file; The method comprises the following steps: the first step is to detect the position of the malicious HTTP message object in the file; the second step is to send the processed malicious HTTP request message to the attacked simulator through Socket; and the method is used to determine whether the simulated attack is successful based on the comparison between the local original response message and the return response message of the attacked simulator; the attacked simulator is used to receive data at the configured port based on the Netty framework, and for messages with custom request header information, extract the value corresponding to the custom request header information, find the response message corresponding to the malicious HTTP message object from the local Web security verification script parameter file, decrypt the object if it is encrypted, and return the response message to the attacker simulator; if the response message is empty, construct a default response message and return it to the attacker simulator.

[0067] In addition, in this embodiment, taking into account the common WAF protection configuration, taking Changting WAF as an example, the Web application website that needs to be protected is represented by a reverse proxy. When using it, the user accesses the Web application website by accessing the address generated by the Changting WAF reverse proxy. Therefore, in this case, the attacked simulator also needs Changting WAF to configure a directional proxy, add the proxy IP and proxy port configuration, and the attacker simulator can determine whether to attack the IP and port of the attacked simulator itself, or the IP and port of the proxy, based on whether the attacked simulator is configured with a proxy IP and proxy port.

[0068] like Figure 5 As shown, using a network security verification system for WAF protection effectiveness verification described in an embodiment of the present invention, the complete process of implementing customer Web site security verification mainly includes:

[0069] Step S201, customize the installation and deployment plan according to the protection equipment and protection strategy of the customer's Web website. Taking the WAF protection device as an example, with the customer's permission, perform attack simulation on the customer's Web website where the customer has deployed a real WAF security protection device, deploy an attacker simulator and an attacked simulator on both sides of the WAF security protection device, where the attacked simulator is proxy-connected to the WAF protection device by reverse proxy, simulating the customer's real network scenario.

[0070] Step S202, according to 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 the protection site of the attacked simulator on the WAF device to reverse proxy the attacked simulator. The attacked simulator needs to configure the IP and port proxied by the WAF device on the BAS system, and the attacker simulator will attack the proxied IP and port when attacking; 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, assembling parameters, automatically assembling execution parameters required for executing the script according to the selected Web security verification script, attacker simulator and victim simulator.

[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 that needs to be executed by the simulator to the attacker simulator.

[0074] Step S206, after receiving the Web security verification script parameters, the attacker simulator executes the task with reference to steps S101 to S107 to obtain the task execution result.

[0075] Step S207, after receiving the execution result returned by the attacker simulator, the server determines whether all the scripts under the task have been executed. If they have been executed, the task is terminated and a security verification report is automatically generated.

[0076] The embodiment of the present invention also discloses a computer program product, including a computer program / instruction, which, when executed by a processor, implements the processing steps of the attacker simulator and / or the attacked simulator in the method for verifying the effectiveness of WAF protection in 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 it is encrypted, decrypting the request message and the 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 position of the malicious HTTP message object in the file; and sending the processed malicious HTTP request message to the attacked simulator through Socket; The attacked simulator receives data at the configured port based on the 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 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, downloads the corresponding Web script compression package from the server and decompresses it; after the download and decompression are successful, the HTTP task of downloading the Web script is sent to the attacked simulator, and after receiving the response of the attacked simulator that the download and decompression is successful, the task continues to be executed.

6. The method for verifying the effectiveness of WAF protection in a network security verification system according to claim 1, characterized in that: The attacked simulator customizes an HTTP Handler interceptor and a TCP Handler interceptor, wherein the HTTP Handler interceptor is used for interaction between the attacker simulator and the attacked simulator, and the TCP Handler interceptor is used for correspondingly 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 response message and the returned response message of the attacked simulator, specifically including: First, determine whether the returned response message is empty. If it is empty, the result is that the attack fails. Otherwise, determine whether the original response message is empty. If the original response message is empty, determine whether the response body in the returned response message is consistent with the preset content. If it is consistent, it is determined that the attack is successful; if it is inconsistent, it is determined that the attack fails; If the content of the original response message is not empty, then determine whether the returned response message is consistent with the original 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 response message. If they are consistent, the attack is judged to be successful. Otherwise, the attack is judged to be unsuccessful.

8. A network security verification system for verifying the effectiveness of WAF protection, comprising a server, and an attacker simulator and an attacked simulator arranged on both sides of the WAF device; characterized in that: The attacker simulator is used to extract the malicious HTTP message object list in the local Web security verification script parameter file, and cyclically process the malicious HTTP message object list, including: determining whether the malicious HTTP message object is encrypted, and if it is encrypted, decrypting the request message and the response message; adding custom request header information in the request message, and 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 through Socket; and determining whether the simulated attack is successful based on the comparison between the local original 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: According to 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 of the victim simulator on the WAF device to perform reverse proxy on 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 IP and port proxied. 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 / instructions are 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