WAF defense capability test method and device based on protocol analysis difference

Abstract

This invention discloses a method and apparatus for testing the defense capabilities of a Web Application Firewall (WAF) based on protocol parsing differences, relating to the field of network security technology. The method constructs protocol mutation verification test cases, generates mutation test messages containing non-standard protocol features and verification payloads, and sends them to the backend via both the test link and the baseline link. By comparing the response fingerprint with the expected result, it accurately determines whether the WAF is in a state of successful interception, bypassed, or repaired and bypassed. This invention enables a comprehensive and automated evaluation of the WAF's protocol-layer defense capabilities.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method and apparatus for testing the defense capabilities of a Web Application Firewall (WAF) based on protocol parsing differences. Background Technology

[0002] With the rapid development of internet technology, attack methods on web applications are becoming increasingly complex and diverse. Web application firewalls (WAFs), as the first line of defense for protecting backend servers, are widely deployed at network boundaries. They identify and block malicious requests by parsing HTTP / HTTPS traffic and using preset rules or models.

[0003] Currently, the verification of the effectiveness of WAF defense mainly relies on two types of technical means: one is black-box testing based on vulnerability scanning tools, that is, using tools such as Xray and AWVS to send attack payloads to targets protected by WAF and observe whether they are intercepted or vulnerabilities are detected; the other is fuzzing testing for specific attack payloads, which tests the WAF's ability to identify obfuscated attacks by performing character-level mutations such as URL encoding, Base64 encoding, and case transformation on the payload.

[0004] However, the aforementioned existing technologies have significant limitations: First, the testing focuses on variations in the attack payload content itself, severely neglecting potential differences in the HTTP protocol encapsulation and parsing layers. The HTTP protocol standard is complex, and different web servers have varying fault tolerance mechanisms for non-standard or ambiguous messages when implementing their parsing logic. If the WAF's protocol parsing engine is inconsistent with the backend server's parsing logic, attackers can construct bypass messages that the WAF cannot recognize but the server can successfully parse and execute by making minor modifications to the protocol header, delimiters, or version number. Existing tools lack the ability to detect such semantic inconsistencies at the protocol layer. Second, existing verification methods are mostly one-way packet-sending probes, heavily relying on HTTP status codes as the criterion for interception. However, in complex scenarios, HTTP status codes are deceptive, failing to distinguish between fake bypasses where the server's parsing crashes after the WAF allows access and genuine bypasses where execution is actually triggered. Furthermore, it is difficult to accurately attribute new security risks introduced by the WAF due to performance optimization or protocol standardization. Finally, the traditional single-link testing mode cannot effectively distinguish whether the attack failure is due to the effectiveness of the WAF defense or the incompatibility between the test sample and the environment, resulting in a low signal-to-noise ratio in the test results and difficulty in discovering bypass vulnerabilities that depend on a specific middleware environment.

[0005] In summary, existing WAF verification technologies have systemic deficiencies in protocol layer testing, attribution accuracy, environmental coverage, and risk identification, making it difficult to meet the needs for automated, systematic, and precise assessment of modern WAF defense capabilities. Summary of the Invention

[0006] In view of the aforementioned defects or deficiencies in the prior art, this invention provides a WAF defense capability testing method and apparatus based on protocol parsing differences. By automatically generating a large number of test requests with minor protocol format distortions but carrying malicious code, and sending them to both a WAF-protected test server and a directly exposed test server, the differences in the response results can be compared. This allows for precise determination of whether the WAF has security vulnerabilities due to inconsistencies between its protocol parsing logic and the backend server, and whether the WAF itself, in trying to fix distorted packets, might actually encourage attacks. This invention can uncover deep-seated security risks that were previously difficult to detect, enabling a comprehensive assessment of WAF defense capabilities.

[0007] One aspect of the present invention provides a method for testing WAF defense capabilities based on protocol parsing differences, comprising the following steps:

[0008] Construct a protocol mutation verification test case that encapsulates at least one protocol mutation operator and a verification payload; wherein the verification payload includes attack instructions with deterministic and predictable results;

[0009] The protocol variation verification test cases are used to reconstruct the protocol layer syntax of the original business request message, generate a variation test message containing at least one non-standard protocol feature and a verification payload, and pre-calculate the expected result of the verification payload.

[0010] The mutation test messages are sent to the backend test server via the test link protected by the target WAF and the reference link bypassing the target WAF, respectively.

[0011] Receive response information from the test link and the baseline link, extract response fingerprints from the response information, and match and compare the expected results of the verification payload with the response fingerprints of the test link and the baseline link respectively to obtain the matching and comparison results of the two links.

[0012] The validity of the sample is determined by comparing the results of the baseline link; the defense status of the target WAF in the test link is determined by comparing the validity of the sample with the results of the test link.

[0013] Another aspect of the present invention provides a WAF defense capability testing device based on protocol parsing differences, comprising:

[0014] The test case construction module is used to construct protocol mutation verification test cases that encapsulate at least one protocol mutation operator and a verification payload; wherein, the verification payload includes attack instructions with deterministic and predictable results;

[0015] The protocol mutation module is used to reconstruct the protocol layer syntax of the original business request message through the protocol mutation verification test case, generate a mutated test message containing at least one non-standard protocol feature and verification payload, and pre-calculate the expected result of the verification payload.

[0016] The differential detection module is used to send the mutation test message to the backend test server through the test link protected by the target WAF and the reference link bypassing the target WAF, respectively.

[0017] The response matching and comparison module is used to receive response information from the test link and the reference link, extract response fingerprints from the response information, and match and compare the expected result of the verification payload with the response fingerprints of the test link and the reference link respectively to obtain the matching and comparison results of the two links.

[0018] The determination module is used to determine the validity of the sample based on the matching comparison results of the baseline link; and to determine the defense status of the target WAF in the test link based on the validity of the sample and the matching comparison results of the test link.

[0019] The present invention provides a WAF defense capability testing method and apparatus based on protocol parsing differences, which has the following beneficial effects:

[0020] (1) By standardizing and reconstructing the protocol layer syntax such as HTTP start line, header fields, and delimiters through the protocol mutation operator library, it can effectively detect the semantic inconsistency between the WAF parsing engine and the backend Web server when processing non-standard and ambiguous messages, making up for the shortcomings of traditional testing that only focuses on payload content, and significantly improving the evaluation coverage.

[0021] (2) By introducing the matching and comparison of the expected results of the verification payload and the response fingerprint of the test server as the core criterion, the mutation operation of the protocol layer is deeply associated with the execution result of the application layer, which completely eliminates the dependence on deceptive HTTP status codes and ensures the accuracy and reliability of the defense assessment conclusion.

[0022] (3) By utilizing the dual-link differential architecture, samples with incompatible environments, samples with impaired payload semantics, and valid samples can be accurately distinguished during the testing of the baseline link, thereby achieving automatic elimination of test noise. On this basis, the test link can accurately attribute and determine the WAF's successful interception state, bypass state, and repair-to-bypass state, greatly improving the scientific nature and decision-making value of the test data.

[0023] (4) The baseline link supports polling tests in various heterogeneous middleware environments and can automatically discover bypass vulnerabilities that depend on specific web server environments. The system can automatically complete the entire process from sample generation, differential testing, result judgment to report generation, realizing a comprehensive and efficient evaluation of WAF protocol-level defense capabilities. Attached Figure Description

[0024] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0025] Figure 1 This is a flowchart illustrating a WAF defense capability testing method based on protocol parsing differences provided in one embodiment of this application;

[0026] Figure 2 This is a schematic diagram of the structure of a WAF defense capability testing device based on protocol parsing differences provided in one embodiment of this application;

[0027] Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] Example 1

[0030] This embodiment details a method for testing WAF defense capabilities based on protocol parsing differences. For example... Figure 1 As shown, the method mainly includes the following steps:

[0031] Step S101: Construct protocol variation verification test cases.

[0032] This step aims to establish a standardized input model for automated testing, addressing the issues of fragmented test scripts and the difficulty in systematically covering protocol variation dimensions in existing technologies. Its core is defining a structured protocol variation verification model that encapsulates test task metadata, protocol variation rule sets, and verification intent into a single unit, forming repeatable and accurately attributable variation verification test case units.

[0033] A protocol variation verification test case mainly consists of the following two parts:

[0034] (1) Use case header

[0035] Metadata that carries test tasks, used for internal management and traceability. Its structured data fields include at least:

[0036] Task_ID: A unique identifier for a task.

[0037] Base_Protocol_Fingerprint: The protocol fingerprint of the original standard business request.

[0038] Operator_Chain: It is an ordered sequence that defines the protocol mutation operators to be applied to the original request.

[0039] Verify_Intent_ID: Verification intent ID, which points to predefined verification logic, such as SQL injection echo verification, command execution verification, etc.

[0040] (2) Definition of external verification payload

[0041] It defines the core content of the mutated message that will ultimately be sent over the network, and consists of the following two modules:

[0042] The Protocol Mutation Semantics module, implemented based on mutation operators, describes the parameters and rules for non-standardized reconstruction of protocol layer syntax such as the start line, header fields, and delimiters of HTTP requests. For example, it describes injecting two spaces before the equals sign in the name attribute of the Content-Disposition header.

[0043] The verification module encapsulates the specific logic of the verification intent. It defines how to generate verification factors, how to calculate the expected result of the verification payload based on the verification factors, and how to embed the verification payload into the specific location of the mutated message. The verification payload is an attack instruction with a deterministic and predictable result, such as an SQL statement embedding a verification factor. The expected result of its verification payload can be calculated locally before the mutated message is sent.

[0044] Furthermore, the verification payload includes one or more of the following attack instructions: instructions to trigger command execution to generate the expected result after encoding and operating on a random string; instructions to trigger SQL injection to generate the expected result after hashing a specific input; and instructions to trigger file upload to generate a specific file fingerprint that can be obtained through subsequent associated requests.

[0045] The protocol mutation verification test cases built through this step standardize and model the originally scattered protocol mutation techniques and attack verification logic, laying the foundation for subsequent automated batch testing and accurate attribution.

[0046] Step S102: Generate a mutation test message and calculate the expected results.

[0047] This step, based on the protocol mutation verification test case constructed in step S101, performs specific protocol mutation and verification payload implantation operations to generate a mutation test message that can be sent and contains non-standard protocol features and verification payload.

[0048] Specifically, the mutation operators and verification modules in the protocol mutation verification test cases are parsed. The protocol semantic mutation engine schedules the corresponding protocol mutation operators to reconstruct the syntax of the original business request message. At the same time, the verification payload generator instantiates the verification module, generates specific attack instruction strings, and implants them into the specified position of the mutated message.

[0049] It should be noted that protocol mutation operators are a series of standardized functional units that perform ambiguity operations on different aspects of the HTTP protocol. In this step, the protocol layer syntax of the original business request message is reconstructed, including but not limited to one or more of the following methods: non-standardized rewriting of the key-value pair assignment syntax in the original business request message; non-standardized rewriting of the protocol version or request method of the request line in the original business request message; replacement of line terminators in the original business request message paragraphs; injection of redundant data at the beginning of the request header or request body of the original business request message; and construction of message fields containing duplicate or conflicting semantics in the original business request message.

[0050] (1) Non-standardized rewriting of key-value pair assignment syntax

[0051] For the Content-Disposition header in formats such as multipart / form-data, modify the key-value pair assignment syntax such as name="user_id".

[0052] For example, the spaces on both sides of the equals sign can be modified (name ="user_id"), double quotes can be replaced with single quotes (name='user_id'), and repeated equals signs can be used (name=="user_id"). This way, when using WAF to extract parameters, it may rely on strict regular expression matching, while the backend middleware has higher fault tolerance and can automatically trim spaces or perform fault-tolerant parsing, thus creating the difference that WAF fails to extract the key name while the server successfully parses it.

[0053] (2) Request line non-standard rewriting

[0054] The start line of the mutated message. For example: change the protocol version HTTP / 1.1 to HTTP / 1.10 or HTTP / 1.a; change the request method POST to PXPOST or POST. This can detect inconsistencies between the WAF's handling strategy for unknown protocol versions or non-standard methods and the fault tolerance mapping mechanism that may exist in the backend framework.

[0055] (3) Replacement of message line end character

[0056] Replace the standard line terminator \r\n (CRLF) with illegal sequences such as \n (LF), \r (CR), or \n\r. This tests the WAF's strictness in determining header boundaries. Some backend servers may accept \n as a line terminator, leading to WAF misinterpreting the packet structure due to differences in delimiter parsing, thus allowing subsequent attack payloads to escape detection.

[0057] (4) Inject redundant data at the beginning of the request header or request body.

[0058] Injecting large amounts of meaningless redundant data into the message request header or the beginning of the request body allows for automated detection of WAF detection thresholds set for performance reasons. When the verification payload is pushed beyond the detection window by the padded data, it may cause the WAF to miss detections, thus verifying the security boundaries introduced by performance optimizations.

[0059] (5) Constructing semantic fields for duplicates or conflicts

[0060] Constructing duplicate Content-Length headers, Content-Type headers, or other header fields with the same name in the message. By exploiting the difference in the strategies chosen by the WAF and the backend server when handling multiple value conflicts in header fields, the WAF can be made to detect based on one value, while the backend is parsed based on another value, thus allowing the WAF to bypass the detection.

[0061] Furthermore, while generating the mutation test message, the system generates a random or specific verification factor r (used to embed into the constructed attack instruction template to form the final verification payload) according to the definition of the verification module, and uses local calculation logic to derive the expected result H(r) after the verification payload is executed. For example, for an SQL injection payload, H(r) = MD5(r); for a command execution payload, H(r) = Base64(SHA256(r)). This expected result H(r) will serve as the gold standard for subsequent comparisons.

[0062] This step can automatically and in batches generate massive amounts of high-quality mutation test messages. These messages not only carry effective verification payloads (attack instructions), but more importantly, they introduce carefully constructed syntax mutations at the protocol encapsulation layer that may cause differences in parsing between the WAF and the backend, providing a testing basis for systematically probing ways to bypass protocol layer vulnerabilities.

[0063] Step S103, dual-link differential detection.

[0064] This step aims to establish a comparative system for accurately determining the WAF defense status in the future through differential probing of the test link and the baseline link. The test link refers to the path taken by the mutated test packet after passing through the target WAF device to be evaluated and reaching the backend test server. The baseline link refers to the path taken by the same mutated test packet that bypasses the target WAF and is sent directly to the backend test server. The backend of the baseline link can be configured to a homogeneous environment consistent with the backend of the test link, or it can support polling tests in various heterogeneous middleware environments (such as Nginx, Tomcat, IIS, Jetty, etc.).

[0065] Specifically, the system uses a differential probe distribution controller to send the mutation test messages generated in step S102 to the test link and the baseline link simultaneously or, provided that logical consistency is met. For heterogeneous environment polling tests, the differential probe distribution controller will sequentially send messages to the baseline link environment configured with different middleware.

[0066] This step, through differential link probing, solves the problems of traditional single-link testing, which cannot distinguish whether attack failure stems from WAF interception or from an invalid sample, and also fails to detect the hidden risks of WAF patching malformed packets to make it effective. By introducing a baseline link as a comparison for the test link, an objective reference system is provided for accurate attribution, enabling controlled comparison of the test, eliminating interference from environmental factors and the sample's own effectiveness, and making the assessment of the WAF's own defense capabilities more pure and accurate.

[0067] Step S104: Response information capture and response fingerprint matching and comparison.

[0068] First, the system receives raw HTTP response information from the test link and the baseline link;

[0069] Subsequently, the semantic loop closure determination module performs normalization processing on each response, including but not limited to: processing block transmission encoding, decompression, character set conversion, etc., to eliminate the differences caused by transmission and encoding and obtain a normalized response content;

[0070] Next, evidence related to the expected result is extracted from the normalized response content based on the verification intent (such as from JSON fields, HTML specific tag content, or plain text). This evidence is called the response fingerprint, which is an extracted and normalized string or feature value used to represent whether the response contains the result of the attack execution.

[0071] Finally, the system calls a matching function to compare the extracted response fingerprint with the expected result pre-calculated in step S102. The matching rules are defined according to the verification intent and can be exact equality, inclusion relationship, or conformity to a specific regular expression pattern. Typically, the matching function outputs a boolean value indicating whether the response of the link matches the response fingerprint.

[0072] This step constructs a deterministic criterion that does not rely on fuzzy indicators such as HTTP status codes and response body length through standardized response processing and fingerprint extraction. If the response fingerprint matches the expected result, it uniquely indicates that the verification payload was successfully executed on the backend and produced the expected response. This fundamentally solves the status code spoofing problem mentioned in the background technology, elevating the judgment criteria from the network layer to the deterministic business logic execution layer, significantly improving the reliability of verification.

[0073] Step S105: Determine the validity of the sample and the WAF defense status.

[0074] Based on the matching comparison results of the two links obtained in step S104, the judgment logic consisting of sample validity determination and WAF defense status determination is executed respectively, specifically including:

[0075] (1) Determination of sample validity

[0076] This determination is based entirely on the matching and comparison results between the response fingerprint of the baseline link and the expected result, denoted as Match_B.

[0077] Scenario A (Environmentally Incompatible Sample): If Match_B is false, meaning the baseline link does not match the response fingerprint, and the baseline link's response exhibits a protocol rejection diagnostic state (e.g., returning 400 Bad Request, 413 Request EntityToo Large, the connection being directly closed by the server, or the response content containing obvious protocol parsing errors), then the mutated test packet is determined to be an environment-incompatible sample. Environment-incompatible samples indicate that the packet's non-standard protocol characteristics are incompatible with the backend protocol stack of the current baseline environment, and the request has been rejected before entering the business logic. Such samples do not prove the attack payload itself is invalid, therefore they are retained for subsequent probing of potential WAF remediation actions.

[0078] Case B (Payload Semantic Impairment Sample): If Match_B is false, and the response from the baseline link does not belong to the protocol rejection diagnostic state (e.g., returning 200 OK, but the response content does not contain the expected result), then the mutated test message is determined to be a payload semantic impairment sample. A payload semantic impairment sample indicates that the message has successfully reached the backend application, but the attack payload it carries has been corrupted due to the protocol mutation operation, losing its execution conditions or logical closure, and is considered a truly invalid test noise point. Such samples should be removed from subsequent judgments to ensure a high signal-to-noise ratio in the test set.

[0079] Case C (Valid Sample): If Match_B is true, the mutation test packet is considered a valid sample. A valid sample indicates that the attack payload can be successfully executed in the current baseline environment. If the baseline link performs heterogeneous polling of different middleware, the specific middleware environment for all samples determined to be valid is recorded.

[0080] (2) WAF defense status determination

[0081] The WAF defense status determination combines the sample validity determination result and the test link matching comparison result Match_T.

[0082] Status 1 (Successful Interception): If the mutated test packet is a valid sample and Match_T is false, then the target WAF has successfully identified and intercepted this mutated attack, and the defense is effective.

[0083] State 2 (Bypass State): If the mutated test message is a valid sample and Match_T is true, then the target WAF is determined to be bypassed, the attack successfully reaches the backend and executes.

[0084] State 2 above can be further subdivided into:

[0085] General Protocol Bypass Status 2.1: If the valid sample is verified to be valid and bypassed in multiple different benchmark middleware environments during the multi-middleware heterogeneous polling in step S103, it indicates that the vulnerability exploits the general defects of WAF in protocol parsing.

[0086] Environment-dependent bypass status 2.2: If the valid sample is only valid in one or a few specific benchmark middleware environments, and bypass occurs in a test link with a homogeneous configuration, it indicates that the vulnerability is highly dependent on the parsing differences between the WAF and the specific middleware.

[0087] State 3 (Repair-Induced Bypass State): If the mutated test packet is an environment-incompatible sample and Match_T is true, then the target WAF is considered to have a repair-induced bypass risk. This indicates that the original packet was rejected by the baseline environment due to malformation, but when it passed through the WAF, the WAF, for compatibility or detection purposes, performed normalization and cleaning operations such as correcting malformed syntax, removing extra spaces, and standardizing newline characters. The repaired packet was judged harmless by the WAF and allowed to pass, and could be successfully parsed and executed by the backend. The repair-induced bypass risk reveals a new attack surface that may be introduced by the WAF's own proactive behavior, a deep risk that is difficult to detect using traditional testing methods.

[0088] This step employs a rigorous two-level decision-making logic to achieve refined attribution of test results. It not only accurately assesses the WAF's interception capabilities but also intelligently distinguishes invalid samples, identifies environment-dependent vulnerabilities, and systematically defines the risk of WAF remediation leading to bypass in automated testing.

[0089] Example 2

[0090] The following is a complete simulated test scenario, used as a separate embodiment, to demonstrate the specific application process of the method described in Embodiment 1. This embodiment assumes that the test environment is a controllable laboratory range, removing business layer interference such as CSRF tokens, and that the backend contains verification points that can trigger SQL injection echoes.

[0091] 1. Scene Setup

[0092] Target WAF: A vendor's next-generation WAF, currently in blocking mode.

[0093] The test backend is a Tomcat 9.0 server running a test web application with an SQL injection vulnerability.

[0094] Baseline environment pool: includes three middleware environments: Nginx 1.18, Tomcat 9.0, and IIS 10.0, all deployed with the same test application.

[0095] Original request: A normal file upload request in multipart / form-data format, which includes the parameter name="file_id".

[0096] 2. Testing Process

[0097] Construct test cases to verify protocol mutations:

[0098] Task_ID: TEST_2023_001

[0099] Base_Protocol_Fingerprint: [Standard request fingerprint]

[0100] Operator_Chain: [Operator A: Injection of leading whitespace in attribute key names, Operator B: Request line version malformation]

[0101] Verify_Intent_ID: SQLI_ECHO (SQL injection echo verification)

[0102] The validation module is defined as follows: It generates a validation factor r = "abc123" and calculates the expected result H(r) = MD5("abc123") = 900150983cd24fb0d6963f7d28e17f72. The implanted validation payload is: file_id = 1' AND (SELECT MD5('abc123'))--.

[0103] 3. Generate mutation test messages

[0104] The protocol semantic mutation engine executes the following operators:

[0105] Operator A: Transforms name="file_id" into name ="file_id" (i.e., inserts two spaces before the equals sign).

[0106] Operator B: Transforms the request line POST / upload HTTP / 1.1 into POST / upload HTTP / 1.10.

[0107] The validation payload generator inserts the validation payload into the mutated file_id parameter value.

[0108] Finally, the mutation test message M1 is generated and the expected result is stored locally: H(r)=900150 983cd24fb0d6963f7d28e17f72.

[0109] 4. Baseline Link Test

[0110] The system sequentially sends the mutation test message M1 to the three environments of the baseline link.

[0111] In the Nginx environment: the response returned a 400 Bad Request, the response fingerprint E_b(resp)_Nginx did not contain the expected result H(r), and the protocol rejected the diagnostic. The mutated test message M1 is an environment-incompatible sample in the Nginx environment.

[0112] Tomcat environment: The response returns 200 OK. The response fingerprint E_b(resp)_Tomcat is extracted from the response body. Match(E_b(resp)_Tomcat, H(r)) is true, meaning the response fingerprint matches the expected result. The mutation test message M1 is marked as a valid sample in the Tomcat environment, and this successful response fingerprint is cached.

[0113] In the IIS environment: the response returns 200 OK, but the content is an application error page. The response fingerprint E_b(resp)_IIS does not contain the expected result H(r), and it is not a protocol rejection. The tagged mutation test message M1 is a sample with semantically corrupted payload in the IIS environment.

[0114] 5. Test Link Detection and Final Judgment

[0115] Scenario A: Testing in a Tomcat environment

[0116] Configure the test pipeline backend to Tomcat (isomorphic to the effective benchmark environment).

[0117] Send a mutation test message M1 to the test link (via the target WAF).

[0118] Receive the test link response and extract the response fingerprint E_t(resp).

[0119] The result of the determination is: Match(E_t(resp), H(r)) is true, meaning the response fingerprint matches the expected result. The target WAF has a Tomcat-dependent bypass risk for this mutated test message.

[0120] Scenario B: Testing in an Nginx environment

[0121] Configure the test link backend as Nginx (isomorphic to the protocol rejection benchmark environment).

[0122] Send a mutation test message M1 to the test link.

[0123] The judgment result: Match(E_t(resp), H(r)) is true, meaning the response fingerprint matches the expected result. The target WAF exists in a repaired state that allows bypass. Because the original malformed message containing spaces was rejected by Nginx, the WAF removed the extra spaces before the key name during parsing, repairing it to the standard name="file_id", and failed to detect the SQL injection verification payload, causing the repaired message to be allowed to pass and successfully executed on the Nginx backend.

[0124] 6. Evaluation report generation:

[0125] The system automatically aggregates the above results and generates an evaluation report. An example of the report content is as follows:

[0126] "A vulnerability was discovered that bypasses the parsing of whitespace in attribute key names in a Tomcat environment (with trigger message M1 and echo evidence). A vulnerability was also discovered that bypasses the protocol fix in an Nginx environment (with the original malformed message, the inferred message after WAF fix, and execution evidence). The vulnerability analysis and hardening recommendations are: WAF should enhance its tolerance consistency checks for whitespace around key name assignment characters; protocol normalization should be carried out prudently to avoid fixing invalid messages into valid messages."

[0127] As can be seen from the above embodiments, the present invention can automatically complete the entire process from protocol mutation, heterogeneous environment adaptation, dual-link differential testing to accurate attribution determination, effectively discovering protocol layer parsing difference vulnerabilities that are difficult to reach by traditional methods and cleaning risks introduced by the WAF itself, and realizing in-depth evaluation of WAF defense capabilities.

[0128] Example 3

[0129] See Figure 2 Another embodiment of the present invention provides a WAF defense capability testing device 200 based on protocol parsing differences, including a test case construction module 201, a protocol mutation module 202, a differential detection module 203, a response matching and comparison module 204, and a judgment module 205. The WAF defense capability testing device 200 based on protocol parsing differences can execute the WAF defense capability testing method based on protocol parsing differences in the method embodiment.

[0130] Specifically, the WAF defense capability testing device 200 based on protocol parsing differences includes:

[0131] The test case construction module 201 is used to construct a protocol mutation verification test case that encapsulates at least one protocol mutation operator and a verification payload; wherein the verification payload includes attack instructions with deterministic and predictable results.

[0132] The protocol mutation module 202 is used to reconstruct the protocol layer syntax of the original business request message through the protocol mutation verification test case, generate a mutation test message containing at least one non-standard protocol feature and verification payload, and pre-calculate the expected result of the verification payload.

[0133] The differential detection module 203 is used to send the mutation test message to the backend test server through the test link protected by the target WAF and the reference link bypassing the target WAF, respectively.

[0134] The response matching and comparison module 204 is used to receive response information from the test link and the reference link, extract response fingerprints from the response information, and match and compare the expected result of the verification payload with the response fingerprints of the test link and the reference link respectively to obtain the matching and comparison results of the two links.

[0135] The determination module 205 is used to determine the validity of the sample based on the matching comparison results of the baseline link; and to determine the defense status of the target WAF in the test link based on the validity of the sample and the matching comparison results of the test link.

[0136] It should be noted that the WAF defense capability testing device 200 based on protocol parsing differences provided in this embodiment corresponds to the technical solutions that can be used to execute various method embodiments. Its implementation principle and technical effect are similar to the method, and will not be repeated here.

[0137] Example 4

[0138] See Figure 3 Another embodiment of the present invention provides a schematic diagram of an electronic device 300, which is used to implement the WAF defense capability testing method based on protocol parsing differences in the method embodiment. The electronic device 300 in the embodiments of the present invention may include, but is not limited to, a security testing workstation, a security testing server, or a dedicated security testing control platform. Figure 3 The electronic device 300 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0139] like Figure 3 As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes to implement the methods of the embodiments described herein, based on a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing device 301, ROM 302, and RAM 303 are interconnected via a bus 305. An input / output (I / O) interface 304 is also connected to the bus 305.

[0140] Typically, the following devices can be connected to I / O interface 304: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0141] The above description is merely a preferred embodiment of the present invention. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to the specific combination of the above-described technical features, but should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A method for testing the defense capabilities of a WAF based on protocol parsing differences, characterized in that, Includes the following steps: Construct a protocol mutation verification test case that encapsulates at least one protocol mutation operator and a verification payload; wherein the verification payload includes attack instructions with deterministic and predictable results; The protocol variation verification test cases are used to reconstruct the protocol layer syntax of the original business request message, generate a variation test message containing at least one non-standard protocol feature and a verification payload, and pre-calculate the expected result of the verification payload. The mutation test messages are sent to the backend test server via the test link protected by the target WAF and the reference link bypassing the target WAF, respectively. Receive response information from the test link and the baseline link, extract response fingerprints from the response information, and match and compare the expected results of the verification payload with the response fingerprints of the test link and the baseline link respectively to obtain the matching and comparison results of the two links. The validity of the sample is determined by comparing the results of the baseline link; the defense status of the target WAF in the test link is determined by comparing the validity of the sample with the results of the test link.

2. The WAF defense capability testing method based on protocol parsing differences according to claim 1, characterized in that, The step of reconstructing the protocol layer syntax of the original business request message includes one or more of the following methods: The key-value pair assignment syntax in the original business request message is rewritten in a non-standardized manner; The protocol version or request method of the request line in the original business request message is rewritten in a non-standardized manner; Replace the line ending characters in the original business request message segments; Inject redundant data at the beginning of the request header or request body of the original business request message; Construct message fields containing duplicate or conflicting semantics from the original business request message.

3. The WAF defense capability testing method based on protocol parsing differences according to claim 1, characterized in that, The verification payload includes one or more of the following attack instructions: Instructions used to trigger command execution to generate the expected result after encoding and operating on a random string; Instructions used to trigger SQL injection to generate the expected result after hashing a specific input; Instructions used to trigger file uploads generate a specific file fingerprint that can be obtained through subsequent associated requests.

4. The WAF defense capability testing method based on protocol parsing differences according to claim 1, characterized in that, The baseline link is configured to poll and test in multiple heterogeneous middleware environments to determine the effectiveness of the mutation test messages in different middleware environments.

5. The WAF defense capability testing method based on protocol parsing differences according to claim 1, characterized in that, Also includes: Based on the determination of the target WAF's defense status, the protocol mutation operation that caused the WAF defense failure is automatically identified, and a WAF defense capability assessment report is generated. The WAF defense capability assessment report includes: the reasons why protocol mutation operations caused WAF defense failure, network packets containing all protocol mutation operations and verification payloads, and proof data of WAF defense failure.

6. The WAF defense capability testing method based on protocol parsing differences according to claim 1, characterized in that, The step of determining the validity of a sample based on the matching and comparison results of a benchmark link includes: If the response fingerprint of the baseline link does not match the expected result of the verification payload, and the response fingerprint belongs to the protocol rejection diagnostic state, then the variant test message is marked as an environment incompatible sample. If the response fingerprint of the baseline link does not match the expected result of the verification payload, and the response fingerprint does not belong to the protocol rejection diagnostic state, then the variant test message is marked as a sample with impaired payload semantics and removed from the subsequent determination. If the response fingerprint of the baseline link matches the expected result of the verification payload, the variant test message is marked as a valid sample.

7. The WAF defense capability testing method based on protocol parsing differences according to claim 6, characterized in that, The step of determining the defense status of the target WAF in the test link based on the validity of the sample and the matching comparison results of the test link includes: If the mutated test message is a valid sample and the response fingerprint of the test link does not match the expected result of the verification payload, then the target WAF is determined to be in a successful interception state. If the mutated test message is a valid sample, and the response fingerprint of the test link matches the expected result of the verification payload, then the target WAF is determined to be in a bypass state; if the valid sample is verified to be valid in at least two different types of heterogeneous middleware environments, then the bypass state is further determined to be a general protocol-type bypass state; if the valid sample is verified to be valid only in a base link composed of one type of heterogeneous middleware environment, then the bypass state is further determined to be a specific environment-dependent bypass state. If the variant test message is an environment-incompatible sample, and the response fingerprint of the test link matches the expected result of the verification payload, then the target WAF is determined to be in a repair-to-bypass state.

8. A WAF defense capability testing device based on protocol parsing differences, characterized in that, include: The test case construction module is used to construct protocol mutation verification test cases that encapsulate at least one protocol mutation operator and a verification payload; wherein, the verification payload includes attack instructions with deterministic and predictable results; The protocol mutation module is used to reconstruct the protocol layer syntax of the original business request message through the protocol mutation verification test case, generate a mutated test message containing at least one non-standard protocol feature and verification payload, and pre-calculate the expected result of the verification payload. The differential detection module is used to send the mutation test message to the backend test server through the test link protected by the target WAF and the reference link bypassing the target WAF, respectively. The response matching and comparison module is used to receive response information from the test link and the reference link, extract response fingerprints from the response information, and match and compare the expected result of the verification payload with the response fingerprints of the test link and the reference link respectively to obtain the matching and comparison results of the two links. The determination module is used to determine the validity of the sample based on the matching comparison results of the baseline link; and to determine the defense status of the target WAF in the test link based on the validity of the sample and the matching comparison results of the test link.

9. A WAF defense capability testing device based on protocol parsing differences according to claim 8, characterized in that, The determination module is further used for: If the response fingerprint of the baseline link does not match the expected result of the verification payload, and the response fingerprint belongs to the protocol rejection diagnostic state, then the variant test message is marked as an environment incompatible sample. If the response fingerprint of the baseline link does not match the expected result of the verification payload, and the response fingerprint does not belong to the protocol rejection diagnostic state, then the variant test message is marked as a sample with impaired payload semantics and removed from the subsequent determination. If the response fingerprint of the baseline link matches the expected result of the verification payload, the variant test message is marked as a valid sample.

10. A WAF defense capability testing device based on protocol parsing differences according to claim 9, characterized in that, The determination module is further used for: If the mutated test message is a valid sample and the response fingerprint of the test link does not match the expected result of the verification payload, then the target WAF is determined to be in a successful interception state. If the mutated test message is a valid sample and the response fingerprint of the test link matches the expected result of the verification payload, then the target WAF is determined to be in a bypass state. If the valid sample is verified to be valid in a baseline link composed of at least two different types of heterogeneous middleware environments, the bypass state is further determined to be a general protocol-type bypass state; if the valid sample is verified to be valid only in a baseline link composed of one type of heterogeneous middleware environment, the bypass state is further determined to be a specific environment-dependent bypass state. If the variant test message is an environment-incompatible sample, and the response fingerprint of the test link matches the expected result of the verification payload, then the target WAF is determined to be in a repair-to-bypass state.

Images