Web attack detection method and device, electronic equipment and storage medium

Abstract

The present disclosure provides a web attack detection method and device, electronic equipment and storage medium, and relates to the technical field of web application security protection. The method comprises the following steps: obtaining an HTTP request parameter and performing multi-round decoding normalization processing to obtain a preprocessing result; performing syntax analysis and pattern matching on the preprocessing result respectively to obtain an analysis result and a matching result, the syntax analysis comprises at least one of structured semantic analysis based on a state machine, semantic analysis based on an abstract syntax tree, semantic analysis based on a syntax feature marker and semantic analysis based on rule replacement simulation, the pattern matching comprises constructing an automatic machine for each attack type, and performing multi-type pattern matching on the preprocessing result based on the automatic machine; and fusing the analysis result and the matching result according to the attack type difference weight to obtain a detection result, thereby improving the comprehensiveness and reliability of the web attack detection.

Description

Technical Field

[0001] This disclosure relates to the field of cybersecurity technology, specifically to the field of web application security protection technology, and in particular to web attack detection methods, devices, electronic devices, and storage media. Background Technology

[0002] Existing web attack detection technologies typically employ rule matching based on regular expressions or fingerprint lookup methods based on a single feature library for attack identification. However, regular expression-based methods rely on a large set of manually written rules, often exceeding two thousand rules, resulting in enormous computational overhead in high-traffic scenarios. Furthermore, the lack of coordination and priority ranking among rules easily leads to conflicts and false positives. Fingerprint lookup methods only focus on the surface feature sequence of the input content, without analyzing the value and contextual semantics of the features, resulting in extremely low detection rates for attacks such as structured query language injection, and severely insufficient coverage of other high-risk attack types such as remote command execution, server-side template injection, and configuration injection. In addition, existing solutions generally adopt a single-layer detection architecture, which cannot simultaneously balance detection accuracy, attack coverage, and processing performance. Their effectiveness is limited when facing advanced bypass techniques such as multi-layered code nesting or abstract syntax tree-level obfuscation (e.g., dynamic attribute access within square brackets, new function construction). These technical limitations create an insurmountable "impossible triangle" between detection rate, false positive rate, and performance in existing web application firewalls, failing to meet the security requirements for real-time and accurate detection of multiple types of web attacks in complex network environments. Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, and storage medium for detecting web attacks.

[0004] According to one aspect of this disclosure, a web attack detection method is provided, the method comprising: Obtain the HTTP request parameters and perform multiple rounds of decoding and normalization to obtain the preprocessed result; The preprocessed results are subjected to syntax parsing and pattern matching to obtain parsing results and matching results. The syntax parsing includes structured semantic analysis for various attack types. The structured semantic analysis includes at least one of state machine-based semantic analysis, abstract syntax tree-based semantic analysis, syntax feature tagging-based semantic analysis, and rule substitution simulation-based semantic analysis. The pattern matching includes constructing automata for various attack types and performing multi-type pattern matching on the preprocessed results based on the automata. The parsing results and the matching results are fused together according to the attack type differential weights to obtain the detection results.

[0005] According to another aspect of this disclosure, a web attack detection apparatus is provided, the apparatus comprising: The normalization module is used to obtain HTTP request parameters and perform multiple rounds of decoding and normalization to obtain preprocessed results. The processing module is used to perform syntax parsing and pattern matching on the preprocessed results to obtain parsing results and matching results. The syntax parsing includes performing structured semantic analysis for various attack types. The structured semantic analysis includes at least one of state machine-based semantic analysis, abstract syntax tree-based semantic analysis, syntax feature tag-based semantic analysis, and rule substitution simulation-based semantic analysis. The pattern matching includes constructing automata for various attack types and performing multi-type pattern matching on the preprocessed results based on the automata. The fusion module is used to fuse the parsing results and the matching results according to the attack type differential weights to obtain the detection results.

[0006] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described in any of the above technical solutions.

[0007] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any one of the methods described above.

[0008] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in any one of the above technical solutions.

[0009] This disclosure provides a web attack detection method, apparatus, device, and storage medium. By acquiring HTTP request parameters and performing multi-round decoding and normalization, this application effectively eliminates the interference of multi-layered encoding nesting and obfuscation on subsequent detection, providing a standardized data foundation for attack detection. Next, the preprocessed results are subjected to syntax parsing and pattern matching. The syntax parsing layer performs structured semantic analysis (including at least one of state machine-based semantic analysis, abstract syntax tree-based semantic analysis, syntax feature tagging-based semantic analysis, and rule substitution simulation-based semantic analysis) for various attack types, achieving high-precision deep detection based on semantic understanding. The pattern matching layer constructs automata for various attack types to perform multi-type pattern matching, achieving broad-coverage and fast detection based on feature rules. Finally, by fusing the two-layer detection results with differentiated weights according to attack type, high-precision semantic parsing and broad-coverage pattern matching complement each other, simultaneously balancing detection accuracy, coverage, and performance within a single architecture. In summary, this application achieves both accuracy and coverage through a two-layer parallel detection architecture and collaborative decision-making through differentiated weight fusion, effectively overcoming the limitation of traditional single-layer detection architectures that cannot achieve both detection rate and accuracy, and significantly improving the comprehensiveness and reliability of Web attack detection.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a schematic diagram of the steps of the Web attack detection method in the embodiments of this disclosure; Figure 2 This is a schematic diagram of step S102 in an embodiment of this disclosure; Figure 3 This is a schematic diagram of step S201 in an embodiment of this disclosure; Figure 4 This is a schematic diagram of step S202 in an embodiment of this disclosure; Figure 5 This is a schematic diagram of step S103 in an embodiment of this disclosure; Figure 6 This is a schematic diagram of the overall process of the Web attack detection method in the embodiments of this disclosure; Figure 7 This is a schematic block diagram of the Web attack detection device in the embodiments of this disclosure; Figure 8 This is a block diagram of an electronic device used to implement the Web attack detection method of the embodiments of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] This disclosure provides a method for detecting web attacks; see [link to relevant documentation]. Figure 1 As shown, Figure 1 This is a schematic diagram illustrating the steps of a web attack detection method in an embodiment of this disclosure. The method is applied to a Web Application Firewall (WAF) system and specifically includes: Step S101: Obtain the HTTP request parameters and perform multi-round decoding and normalization processing to obtain the preprocessed result.

[0014] Specifically, this step aims to address the problem of attackers bypassing traditional single-layer decoding detection engines through multi-layered encoding nesting (such as URL encoding, Unicode escaping, HTML entities, Base64, etc.). Specifically, it first extracts parameters from the HTTP request, including at least one of the following: query string, request body, cookie, request header, and path. Then, it performs at most three rounds of iterative decoding on the parameters, sequentially executing address decoding (i.e., percent sign encoding decoding, restoring the %XX format to its original characters), character encoding escape decoding (i.e., processing Unicode escape sequences such as \uXXXX), token entity decoding (i.e., restoring Hypertext Markup Language entities such as &, <, &#XXXX;), and encoded content decoding (i.e., decoding input that conforms to the encoding characteristics and verifying the printable character ratio of the decoded result to prevent misinterpreting binary data as plaintext or encountering maliciously constructed excessively long encoded inputs that could exhaust computational resources). Finally, it performs case-consistent processing on the decoded result (e.g., converting it to lowercase), thereby obtaining a preprocessed result that eliminates encoding confusion and unifies the format, providing a standardized input foundation for subsequent syntax parsing and pattern matching.

[0015] Step S102: Perform syntax parsing and pattern matching on the preprocessed results to obtain parsing results and matching results. The syntax parsing includes performing structured semantic analysis for various attack types. The structured semantic analysis includes at least one of the following: state machine-based semantic analysis, abstract syntax tree-based semantic analysis, syntax feature tag-based semantic analysis, and rule substitution simulation-based semantic analysis. The pattern matching includes constructing automata for various attack types and performing multi-type pattern matching on the preprocessed results based on the automata.

[0016] Specifically, this step aims to resolve the technical contradiction that traditional single-layer detection architectures cannot simultaneously achieve both detection accuracy and coverage. Here, syntax parsing refers to a technique that uses the structured rules of the target language to perform deep semantic understanding of the input content to identify attack patterns; pattern matching refers to a technique that compares the input content with a predefined attack feature library to quickly identify known attack patterns.

[0017] The specific implementation process of this scheme includes: simultaneously inputting the preprocessed results into the syntax parsing layer and the pattern matching layer for parallel processing. In the syntax parsing layer, structured semantic analysis is performed on various attack types, such as SQL injection, cross-site scripting, command injection, template injection, configuration injection, and database injection. This structured semantic analysis includes at least one of the following: state machine-based semantic analysis (i.e., identifying quotation mark boundary violations and illegal keyword combinations by tracking the nesting depth of quotation marks and the contextual relationships of query language keywords), abstract syntax tree-based semantic analysis (i.e., parsing script code fragments using an abstract syntax tree to extract dangerous function calls and dynamic access patterns from the tree structure), syntax feature tagging-based semantic analysis (i.e., matching template syntax tags and detecting sensitive object access), and rule-substitution simulation-based semantic analysis (i.e., simulating a variable substitution engine to process nested structures), thereby obtaining a semantically understanding-based parsing result. In the pattern matching layer, automata with built-in multiple attack modes are constructed for each attack type. Based on these automata, multi-type pattern matching is performed on the preprocessed results, and the hit attack types and matching positions are output according to a preset priority order, thereby obtaining a feature rule-based matching result. By combining high-precision semantic understanding at the syntax parsing layer with wide-coverage, fast detection at the pattern matching layer in parallel execution, both detection accuracy and coverage are achieved, providing dual-layer evidence support for subsequent fusion-based decision-making.

[0018] Step S103: The parsing results and matching results are fused according to the attack type differential weight to obtain the detection results.

[0019] Specifically, this step aims to address the technical challenge of comprehensive decision-making after two-layer parallel detection by achieving synergistic optimization of high-precision semantic parsing and wide-coverage pattern matching through a differentiated weight fusion mechanism. Differentiated weight fusion refers to a technical approach that configures different weight coefficients for different attack types based on their inherent confidence characteristics and false positive risk, and calculates a fusion score based on these weights to output the final detection result.

[0020] The specific implementation process of this scheme includes: First, determining the matching weight based on the attack type corresponding to the matching result. The matching weight is configured differently according to the false positive risk of the attack type; the lower the false positive risk, the higher the matching weight (e.g., configuring the highest matching weight for injection attacks, the second highest for cross-site scripting and external entity attacks, the lower for command injection, code execution, and server request forgery attacks, and the lowest for template injection attacks). Simultaneously, determining the position weight based on the parameter position corresponding to the preprocessing result. Different parameter positions (such as query strings, request bodies, request headers, paths, etc.) are configured with different weight bonuses according to their attack risk levels. Then, a fusion score is calculated based on the matching weight and the position weight. The specific calculation process is as follows: the pattern matching layer score is determined by multiplying the number of matches by the matching weight and combining it with a preset upper limit value. The larger value between the parsing result and the pattern matching layer score is taken as the initial fusion score. The fusion score is then calculated based on the initial fusion score and the position weight. When both the parsing result and the matching result meet the valid condition (i.e., both layers of detection produce attack evidence higher than a preset threshold), a preset gain value is applied to the fusion score to simulate the synergistic effect of multi-layer confirmation, obtaining the final detection result. Finally, the blocking threshold is determined based on the preset sensitivity level, which includes high sensitivity, medium sensitivity, and low sensitivity. The blocking threshold is inversely related to the sensitivity level (i.e., high sensitivity corresponds to a lenient threshold, and low sensitivity corresponds to a strict threshold). When the detection result is greater than or equal to the blocking threshold, a blocking decision is output. When the result is less than the blocking threshold but greater than or equal to the log threshold, a log recording decision is output. When the result is less than the log threshold, a release decision is output, thereby achieving interpretable and tunable fine-grained decision output.

[0021] This disclosure provides a method, apparatus, electronic device, and storage medium for web attack detection. By acquiring HTTP request parameters and performing multi-round decoding and normalization, this application effectively eliminates the interference of multi-layered encoding nesting and obfuscation on subsequent detection, providing a standardized data foundation for attack detection. Next, the preprocessed results are subjected to syntax parsing and pattern matching. The syntax parsing layer performs structured semantic analysis (including at least one of state machine-based semantic analysis, abstract syntax tree-based semantic analysis, syntax feature tag-based semantic analysis, and rule substitution simulation-based semantic analysis) for various attack types, achieving high-precision deep detection based on semantic understanding. The pattern matching layer constructs automata for various attack types to perform multi-type pattern matching, achieving broad-coverage and fast detection based on feature rules. Finally, by fusing the two-layer detection results with differentiated weights according to attack type, high-precision semantic parsing and broad-coverage pattern matching complement each other, simultaneously balancing detection accuracy, coverage, and performance within a single architecture. In summary, this application achieves both accuracy and coverage through a two-layer parallel detection architecture and collaborative decision-making through differentiated weight fusion, effectively overcoming the limitation of traditional single-layer detection architectures that cannot achieve both detection rate and accuracy, and significantly improving the comprehensiveness and reliability of Web attack detection.

[0022] In some alternative embodiments, see Figure 2 Step S102 involves parsing the preprocessed result to obtain the parsing result, specifically including: Step S201: Perform a structured scan on the preprocessed results, track the nesting depth of quotation marks and the contextual association of keywords in the query language, identify structured anomaly patterns based on the nesting depth of quotation marks and contextual association, and obtain structured parsing results.

[0023] This method corresponds to SQL injection syntax state machine detection. Specifically, this application performs a structured scan on the preprocessed results, tracks the depth of quotation mark nesting and the contextual relationships of query language keywords, identifies structured abnormal patterns based on the quotation mark nesting depth and contextual relationships, and obtains structured parsing results, thereby achieving lightweight semantic detection of structured query language injection attacks. Here, structured scanning refers to a processing method that traverses and analyzes the input content character by character according to preset rules. Quotation mark nesting depth refers to the counting of the opening and closing levels of single quotes, double quotes, and backticks during the scanning process, including escape processing logic. Contextual relationships of query language keywords refer to the sequence relationship formed by recording the most recently encountered query language keywords and their order of appearance during the scanning process. Structured abnormal patterns refer to the state of quotation mark boundary destruction or illegal combination of keywords that deviate from normal query syntax rules.

[0024] The specific implementation process of this scheme includes: scanning the preprocessed results, detecting single quotes, double quotes, and backticks character by character, calculating their nesting depth, and processing escape characters to obtain the quote depth status, thereby determining whether the string boundary is broken or whether there is an unclosed anomaly. Simultaneously, it records the query language keywords encountered during the scanning process (such as union queries, selection, conditional statements, etc.) and their order of appearance, obtaining keyword context associations to track the continuous occurrence of keywords and illegal grammatical combinations. Then, based on the quote depth status and keyword context associations, a collaborative judgment is made. When the quote nesting depth is odd and in a non-string context, or when query language keywords exhibit illegal continuous combinations (such as directly concatenating union queries and selections), or when a closed quote is immediately followed by a conditional statement keyword, it is identified as at least one of the following structured anomaly patterns: quote imbalance, union queries, Boolean tautology, comment injection, conditional comments, stacked queries, time-based blind injection, system table access, file operations, command execution, and backtick injection, resulting in a structured parsing result. By using dual state tracking of quotation mark nesting depth and keyword context association, the detection process can identify attack features at the structural level without building a complete syntax tree, significantly reducing computational overhead while ensuring detection accuracy.

[0025] Step S202: Perform multi-layer script attack vector detection on the preprocessed results to identify dangerous operation patterns in the marker layer, vector layer, and code layer, and obtain script attack parsing results.

[0026] This method corresponds to XSS detection. Specifically, this application performs multi-layer script attack vector detection on the preprocessed results to identify dangerous operation patterns at the tag layer, vector layer, and code layer, thereby obtaining script attack parsing results and achieving multi-dimensional progressive detection of cross-site scripting attacks from surface features to deep semantics. Multi-layer script attack vector detection refers to the technical means of screening potential attack paths layer by layer in the input content according to a hierarchical structure from shallow to deep. The tag layer refers to the structured representation layer of Hypertext Markup Language tags and attributes. The vector layer refers to the attack carrier layer unique to extended markup languages ​​such as Scalable Vector Graphics and Mathematical Markup Language. The code layer refers to the abstract syntax tree representation layer of the script code. Dangerous operation patterns refer to feature combinations or syntactic structures that may trigger malicious behavior at the corresponding layer.

[0027] The specific implementation process of this scheme includes: performing tag feature matching on the preprocessed results to identify dangerous tags (such as script, scalable vector graphics, frame tags, etc.), event handlers (such as event binding attributes for loading, clicking, mouse movement, etc.), and dangerous resource locator schemes (such as pseudo-protocols such as script protocols and data text hypertext markup languages), obtaining tag feature parsing results, thereby intercepting traditional cross-site scripting attack vectors at the hypertext markup language structure level. The preprocessed results are then subjected to scalable vector graphics and mathematical markup language-specific vector detection to identify embedded scripts (such as referencing external malicious resources through graphic elements) and animation event injection (such as triggering script execution through animation start, settings, etc.), obtaining specific vector parsing results, thereby covering unconventional injection carriers from the attack path level unique to extended markup languages. The preprocessed results undergo byte pre-scanning to identify script code fragments containing features such as brackets, member access, assignment, and identifiers. These fragments are then subjected to abstract syntax tree (AST) parsing, transforming the code into a tree-structured representation. From the AST, dangerous operation patterns are extracted, including function call expressions (such as evaluation and warning functions), member call expressions (such as document writing and window evaluation), constructor expressions (such as constructors for creating functions and asynchronous requests), assignment expressions (such as internal hypertext markup language assignment and positional assignment), and dynamic bracket access expressions (such as dynamic window evaluation and square bracket attribute access). This yields a semantic analysis result, enabling the identification of obfuscated script attacks from a program semantic understanding perspective. This three-layer progressive detection architecture (marker layer, vector layer, and code layer) requires attack payloads to simultaneously breach multiple defenses to escape detection, and each layer can be independently optimized and upgraded, achieving simultaneous improvements in detection depth and flexibility.

[0028] Step S203: Perform command delimiter detection and system command matching on the preprocessed results to obtain command injection parsing results.

[0029] This method corresponds to Shell command injection detection. Specifically, this application obtains command injection parsing results by performing command delimiter detection and system command matching on the preprocessed results, thereby achieving accurate identification of operating system command injection attacks. Command delimiters refer to specific characters or character combinations used to separate or connect multiple commands, such as semicolons, pipe characters, logical AND, logical OR, and command substitution characters. System command matching refers to the process of comparing the input content with a predefined system command library; the command injection parsing result refers to the attack judgment conclusion output based on the dual verification of delimiter location and command word recognition.

[0030] The specific implementation process of this scheme includes: First, performing a Data Uniform Resource Identifier (DRI) exemption check on the preprocessed results to identify semicolons in the DRI format (the semicolon is used as a Multipurpose Internet Mail Extensions (MIL) delimiter, not a command delimiter), thereby preventing normal DRIs from being misjudged as command injection. Next, performing command delimiter detection on the preprocessed results to locate the positions of semicolons, pipe characters, logical AND, logical OR, command substitution start characters, backticks, newlines, and other command delimiters, thereby identifying the syntactic structure of command concatenation or command substitution. Simultaneously, performing system command matching on the preprocessed results, comparing the input content with a predefined system command library (covering commands from both operating systems and Windows operating systems) to identify the appearance of system command terms. Furthermore, performing system path detection on the preprocessed results to identify sensitive file paths (such as system password files, system command interpreters, process environment information, etc.) and common naming convention path access (such as server shared formats), thereby assisting in determining the command execution intent from the path access dimension. When command delimiter detection and system command matching or system path detection both hit, a command injection attack is determined, and the command injection parsing result is obtained. By employing dual verification through delimiter location and command word matching, the detection process focuses on both the syntactic structure of command execution (the presence of delimiters) and the substantive content of command execution (command words or sensitive paths), avoiding false positives or false negatives caused by single-dimensional detection and achieving accurate identification of command injection attacks.

[0031] Step S204: Perform template syntax tag matching and sensitive object access detection on the preprocessed results to obtain template injection parsing results.

[0032] This method corresponds to SSTI template injection detection. Specifically, this application obtains template injection parsing results by performing template syntax markup matching and sensitive object access detection on the preprocessed results, thereby achieving accurate identification of server-side template injection attacks. Template syntax markup refers to the syntax symbols or instruction formats unique to various template engines, such as double curly braces expressions, percent sign blocks, hash symbols, and dollar sign expressions; sensitive object access refers to the invocation behavior of objects, classes, or methods with high-risk operation capabilities built into the template engine or the host language; and the template injection parsing result is the attack judgment conclusion output based on dual verification of template syntax feature recognition and sensitive object access tracking.

[0033] The specific implementation process of this scheme includes: performing template syntax markup matching on the preprocessed results to identify the syntax features of various template engines. These features include unclosed double curly braces expressions, percent sign instruction blocks (such as conditional statements, loop iterations, and other control instructions), hash sign setting and parsing instructions, dollar sign expressions and exclamation mark variable references, asterisk expressions and symbolic attribute references, hash sign setting and parsing instructions, text tags, and text block syntax. This determines whether the input contains template instructions from the template engine syntax dimension. Simultaneously, sensitive object access detection is performed on the preprocessed results to identify sensitive object calls in the host language. Sensitive objects include operating system interfaces, process management, command execution pipelines, class inheritance chains, subclass enumerations, runtime environment acquisition, and other operating system and process-related objects, as well as runtime execution environment acquisition and other runtime-related objects. This determines whether the input attempts to use the template engine to execute system commands or obtain sensitive information from the code execution dimension. When both template syntax markup matching and sensitive object access detection are successful, or when an unclosed template syntax markup is detected and a sensitive object access path subsequently appears, a template injection attack is determined, and the template injection parsing result is obtained. By using dual detection of template syntax markers and access to sensitive objects, the judgment process focuses on both the breaking of the template engine's syntax boundaries (unclosed markers or illegal instructions) and the actual harm caused by the breaking (calling of sensitive objects), effectively distinguishing between normal template use and malicious template injection, and achieving accurate identification of various template engine injection attacks.

[0034] Step S205: Perform variable substitution simulation and nested structure detection on the preprocessed results to obtain the configuration injection parsing results.

[0035] This method corresponds to Log4Shell detection. Specifically, this application obtains configuration injection parsing results by performing variable substitution simulation and nested structure detection on the preprocessed results, thereby achieving accurate identification of configuration injection attacks (such as log framework configuration injection). Variable substitution simulation refers to simulating the substitution behavior of the variable parsing engine in the target system, and restoring the variable references in the input content layer by layer. Nested structure detection refers to the process of identifying multi-level nested and recursively contained hierarchical structures in variable references. The configuration injection parsing result refers to the attack judgment conclusion output based on the dual verification of variable substitution simulation and nested structure tracing.

[0036] The specific implementation process of this scheme includes: First, direct matching layer detection is performed on the preprocessed results to identify direct combinations of variable substitution start markers and specific protocols (such as named directory interfaces, remote method calls, lightweight directory access protocols, etc.), thereby intercepting unobfuscated configuration injection attack payloads. Next, variable substitution simulation is performed on the preprocessed results, parsing the substitution rules in variable references layer by layer. The substitution rules include obfuscated variants such as case conversion (e.g., uppercase to lowercase, lowercase to uppercase), character selection (e.g., retaining specific characters, removing specific characters), environment variable reading, and default value rollback. The scheme simulates and restores the true content of variable references through up to five iterations, thus countering attackers' obfuscation methods that bypass direct matching through nested substitution rules. Simultaneously, nested structure detection is performed on the preprocessed results to identify recursive structures with multiple nested levels in variable references (e.g., variable references containing other variable references), tracing the nesting depth to discover bypass methods that hide attack intent through multiple nesting levels. When direct matching hits, variable substitution simulation restores attack characteristics, or nested structure detection discovers an abnormal level, a configuration injection attack is determined, and the configuration injection parsing result is obtained. By employing a dual mechanism of variable substitution simulation and nested structure detection, the detection process can identify both plaintext direct attack payloads and reconstruct attack payloads that have undergone multi-layer obfuscation and deformation. This effectively counters complex bypass techniques constructed by attackers using the variable parsing characteristics of the target system, achieving comprehensive coverage of configuration injection attacks.

[0037] Step S206: Perform database operator anomaly detection on the preprocessing results to obtain the database injection parsing results.

[0038] The parsing results include at least one of the following: structured parsing results, script attack parsing results, command injection parsing results, template injection parsing results, configuration injection parsing results, and database injection parsing results.

[0039] This method corresponds to NoSQL injection detection. Specifically, this application obtains database injection parsing results by performing database operator anomaly detection on the preprocessed results, thereby achieving accurate identification of document-oriented database injection attacks. Here, database operators refer to special symbols or keywords in document-oriented database query languages ​​used for conditional judgments, logical operations, regular expression matching, etc., such as conditional judgment operators, greater than operators, not equal to operators, regular expression operators, containment operators, logical OR operators, etc. Anomaly detection refers to identifying the behavior of operators appearing in unusual contexts (such as non-query statement structures or unexpected parameter positions). The database injection parsing result refers to the attack judgment conclusion output based on the occurrence of database operators in abnormal contexts.

[0040] The specific implementation process of this scheme includes: scanning the preprocessed results for database operators to identify conditional operators, greater than operators, not equal to operators, regular expression operators, containment operators, logical OR operators, and other operation symbols specific to document-oriented databases. Then, the context in which the operators appear is determined. When an operator appears in an unexpected position (such as user input parameters directly concatenated into query conditions, operators nested within string constants, or operators combined to form logical judgment structures), it is identified as a database operator anomaly. Simultaneously, illegal combination patterns of operators are detected (such as the logical OR operator combined with a tautology condition, or a regular expression operator combined with a full match pattern) to determine if there is an injection intent attempting to bypass authentication or extract data. When a database operator anomaly is detected, a database injection attack is determined, and the database injection parsing result is obtained.

[0041] The parsing results include at least one of the following: structured parsing results, script attack parsing results, command injection parsing results, template injection parsing results, configuration injection parsing results, and database injection parsing results. These cover SQL injection, XSS, Shell command injection, SSTI, Log4Shell, and NoSQL injection attacks, respectively, allowing the output of the syntax parsing layer to be flexibly combined according to the actual attack scenario. It supports both independent detection output for a single attack type and multi-dimensional evidence aggregation when multiple attack types occur concurrently, providing modular and scalable parsing evidence input for the subsequent feature fusion layer.

[0042] Thus, by performing structured scanning on the preprocessed results, tracking the depth of quotation mark nesting and the contextual relationships of query language keywords, abnormal patterns such as quotation mark boundary violations and illegal keyword combinations are identified at the syntactic structure level, achieving high-precision structured semantic analysis based on state machines. Through multi-layered script attack vector detection, dangerous markers and event handlers at the marker layer, scalable vector graphics and mathematical markup language-specific injections at the vector layer, and dangerous operation patterns in the abstract syntax tree at the code layer are identified layer by layer, achieving deep script semantic understanding based on progressive screening. Command injection attacks are identified from two dimensions: delimiter detection and system command matching, using delimiter location and command word comparison. Template injection attacks are identified from two perspectives: template engine syntax features and sensitive object access detection, using template engine syntax features and sensitive object calls. Configuration injection attacks are identified from two paths: variable substitution simulation and nested structure detection, using variable substitution engine behavior simulation and nested level analysis. Database injection attacks are identified from the abnormal occurrence of database operators in unconventional contexts, using database operator anomaly detection. The aforementioned attack types are subjected to independent structured semantic analysis, enabling each detector to deeply understand the syntactic features of specific attack types and avoiding the insufficient adaptability of single-layer general rules in different attack scenarios. Simultaneously, open enumeration ensures that the parsing results cover at least one of the following: structured parsing results, script attack parsing results, command injection parsing results, template injection parsing results, configuration injection parsing results, and database injection parsing results, achieving flexible coverage and independent optimization for multiple attack types. In summary, this application achieves simultaneous improvement in detection accuracy and attack type coverage by constructing specialized semantic analysis mechanisms for multiple attack types, effectively overcoming the limitations of traditional single-layer detection architectures that over-rely on SQL injection and cross-site scripting, and insufficient coverage of command injection, template injection, configuration injection, and database injection.

[0043] In some alternative embodiments, see Figure 3 Step S201 involves performing a structured scan on the preprocessed results, tracking the depth of quotation mark nesting and the contextual association of keywords in the query language, identifying structured anomaly patterns based on the depth of quotation mark nesting and contextual association, and obtaining structured parsing results, specifically including: Step S301: Scan the preprocessing results, count the nesting depth of single quotes, double quotes and backticks, and obtain the quote depth status.

[0044] Specifically, this application scans the preprocessed results and counts the nesting depth of single quotes, double quotes, and backticks to obtain the quote depth status, thereby providing a quantitative basis for identifying quote boundary violations in Structured Query Language (SQuery) injection attacks. Here, single quotes, double quotes, and backticks refer to the quoting symbols used in SQuery Language to identify string constants or database object names. Nesting depth refers to the count of the number of open and unclosed quote levels during the scanning process; quote depth status refers to structured data reflecting the nesting levels and balance relationships of various quote types at the current scanning position.

[0045] The specific implementation process of this scheme includes: scanning the preprocessed results character by character, sequentially detecting the occurrence of single quotes, double quotes, and backticks; when a quote character is detected, it is determined whether the quote is in an escaped state (i.e., the preceding character is an escape character). If it is in an escaped state, the nesting depth change is not counted; if it is not in an escaped state, the nesting depth count of the corresponding quote is updated (incremented by one when open, decremented by one when closed). Throughout the scanning process, the nesting depth values ​​of single quotes, double quotes, and backticks are continuously maintained to obtain the quote depth status. Through real-time statistics and escaping processing of quote nesting depth, the detection system can accurately determine the integrity of string boundaries in the input content, identify abnormal states such as unclosed quotes and unbalanced quotes, and provide structured evidence at the quote dimension for subsequent collaborative judgments related to the context of query language keywords, effectively countering attackers' injection methods that disrupt the query syntax structure through quote closure.

[0046] Step S302: Record the query language keywords encountered during the scanning process and their order of appearance to obtain the keyword context association.

[0047] Specifically, this application obtains keyword contextual relationships by recording the query language keywords encountered during the scanning process and their order of appearance, thereby providing a serialization basis for identifying illegal grammatical combinations in structured query language injection attacks. Here, query language keywords refer to reserved words or instructions with specific grammatical functions in structured query language, such as union queries, selection, conditional judgments, source, insertion, update, and deletion. The order of appearance refers to the temporal sequence in which keywords are detected during the scanning process; keyword contextual relationships refer to the serialized data structure constructed based on the adjacency, hierarchical, and logical combination relationships formed by the keyword appearance order.

[0048] The specific implementation process of this scheme includes: during the character-by-character scanning of the preprocessed results, a predefined set of query language keywords is simultaneously detected. When a complete keyword is detected, its type identifier and its position offset within the input content are recorded. The detected keywords are sequentially stored in a keyword sequence according to the scanning order, forming a keyword stack structure to maintain the most recently encountered query language keywords and their temporal relationships. Furthermore, the combination relationships of adjacent keywords are analyzed based on the keyword sequence (e.g., consecutive occurrences of union queries and selections, conditional statements followed by tautologies, semicolons followed by deletion instructions, etc.), identifying illegal keyword combinations that deviate from normal query syntax rules. Through recording the keyword occurrence order and contextual analysis, the detection system can track abnormal changes in query intent from a syntactic structure perspective, identify injection methods used by attackers to construct illegal query logic by concatenating keywords, and provide structured evidence at the keyword level for subsequent collaborative judgment with the depth state of quotation marks.

[0049] Step S303: Based on the quote depth state and keyword context association, identify at least one of the following: quote imbalance, union query, Boolean tautology, comment injection, conditional comment, stacked query, time blind injection, system table access, file operation, command execution, and backtick injection, and obtain structured parsing results.

[0050] Specifically, this application identifies at least one of the following attacks—quote imbalance, union queries, Boolean tautology, comment injection, conditional comments, stacked queries, time-based blind injection, system table access, file operations, command execution, and backtick injection—based on the context of quotation depth and keywords, thereby obtaining structured parsing results and achieving multi-dimensional pattern recognition of structured query language injection attacks. Specifically, quotation imbalance refers to the abnormal state where the nesting depth of quotation marks does not return to zero at the end of the scan or an odd number of quotation marks appears in a non-string context; union queries refer to attackers obtaining and manipulating additional data by concatenating union queries and selection instructions; Boolean tautology refers to a logical bypass technique where a conditional judgment is followed by a tautological expression (such as a number equal to itself or a string equal to itself); comment injection refers to an attack method that uses comment symbols to truncate the original query statement and append malicious instructions; conditional comments refer to comment block syntax that executes only under specific version conditions in a specific database dialect (such as version number conditional comments); and stacked queries refer to batch execution operations that append additional complete query statements using semicolon separators. Time-based blind injection refers to side-channel probing techniques that determine the truth or falsity of conditions through delay functions (such as sleep or benchmarking); system table access refers to the act of collecting information about the database structure by querying database metadata tables (such as information schemas or system object tables); file operations refer to high-risk operations that read or write to the server's file system by loading or exporting files; command execution refers to backdoor exploitation that calls database extended stored procedures (such as command line execution or object creation) to execute operating system commands; backtick injection refers to a variant of injection that disrupts the original query structure by using backticks to identify database objects; and structured parsing results refer to the attack type determination and confidence assessment output based on dual evidence of quotation mark status and keyword association.

[0051] The specific implementation process of this scheme includes: continuously maintaining the quote depth state and keyword context association during the scanning process, and triggering the identification of corresponding attack patterns when specific combination conditions are detected. When the quote nesting depth is odd and in a non-string context, it is identified as a quote imbalance pattern. When a keyword sequence contains consecutive union queries and selections in the result set syntax position, it is identified as a union query pattern. When a conditional statement is followed by a tautology expression (such as a value equal to itself), it is identified as a Boolean tautology pattern; when a comment symbol is detected followed by non-empty content or a keyword, it is identified as a comment injection pattern. When a version number conditional comment block is detected enclosing a keyword, it is identified as a conditional comment pattern. When a semicolon is followed by a query language keyword, it is identified as a stacked query pattern. When a conditional statement or logical join is followed by a delayed function call, it is identified as a time-based blind injection pattern. When a source instruction is followed by a system metadata table name, it is identified as a system table access pattern. When a file load or export instruction and path parameters are detected, it is identified as a file operation pattern. When an extended stored procedure call (such as command line execution or object creation) is detected, it is identified as a command execution pattern. When the nesting depth of backticks is abnormal and accompanied by query language keywords, it is identified as a backtick injection pattern. By collaboratively judging the quote depth state and the context of keywords, a single scan process can simultaneously output the identification results of multiple attack patterns. Moreover, the identification of each pattern shares the same quote depth and keyword sequence data maintained by the same state machine, avoiding the performance loss caused by repeated scans, and achieving efficient and accurate detection of structured query language injection attacks.

[0052] In this way, by scanning the preprocessed results and statistically analyzing the nesting depth of single quotes, double quotes, and backticks, the quote depth state is obtained, thereby identifying attempts to disrupt string closure from the quote boundary dimension. By recording the query language keywords encountered during the scanning process and their order of occurrence, keyword contextual relationships are obtained, thus tracking the continuous occurrence and illegal combination patterns of keywords from the syntactic structure dimension. Furthermore, based on the collaborative judgment of the quote depth state and keyword contextual relationships, at least one of the following is identified: quote imbalance, union queries, Boolean tautology, comment injection, conditional comments, stacked queries, time-based blind injection, system table access, file operations, command execution, and backtick injection, resulting in a structured parsing result. The above dual-state tracking of quote nesting depth and keyword contextual relationships allows the detection process to identify abnormal patterns at the structural level without performing complete syntactic parsing, significantly reducing computational overhead while ensuring detection accuracy. At the same time, state maintenance and pattern recognition are achieved through a single scan, avoiding the performance loss caused by multiple rounds of traversal. Furthermore, by enumerating eleven specific attack patterns, the detection scope is expanded from traditional quotation mark closure checks to complex attack scenarios such as joint queries, stacked queries, time-based blind injection, and system table access, achieving a simultaneous improvement in detection depth and breadth. In summary, this application utilizes a dual-state machine mechanism that associates quotation mark depth with keywords to achieve multi-dimensional attack pattern recognition within a lightweight scanning framework. This effectively overcomes the limitations of traditional regular expression matching in handling quotation mark escaping and recognizing complex nested structures, significantly improving the accuracy and efficiency of structured query language injection detection.

[0053] In some alternative embodiments, see Figure 4 Step S202 involves performing multi-layer script attack vector detection on the preprocessed results to identify dangerous operation patterns at the marker layer, vector layer, and code layer, thereby obtaining the script attack parsing results, specifically including: Step S401: Perform tag feature matching on the preprocessing results to identify hazard tags, event handlers, and hazard resource locator schemes, and obtain tag feature parsing results.

[0054] Specifically, this application achieves accurate identification of marker-layer injection vectors in cross-site scripting (XSS) attacks by performing marker feature matching on the preprocessed results to identify dangerous markers, event handlers, and dangerous resource locator schemes. Markup feature matching refers to the technical means of comparing input content with a predefined dangerous marker pattern library to detect attack features related to Hypertext Markup Language (HTML). Dangerous markers are HTML tags that may be used to carry malicious scripts or trigger abnormal behavior, such as tags for script, scalable vector graphics, frames, objects, embeddings, applets, basics, metadata, forms, indexes, styles, Extensible Markup Language (XML), examples, and scrolling text. Event handlers are event-triggered attributes bound to HTML elements, such as loading, click, mouse movement, and key press events. Dangerous resource locator schemes are Uniform Resource Locator (URL) prefixes that may be used to execute scripts or load malicious resources, such as pseudo-protocols like script protocol, script protocol, data text HTML, and data text XML. The marker feature analysis result refers to the attack judgment conclusion output based on the three-dimensional detection of dangerous markers, event handlers, and dangerous resource locator schemes.

[0055] The specific implementation process of this scheme includes: First, tag detection is performed on the preprocessed results to identify fourteen predefined dangerous tags and their variants (such as case obfuscation, tag attribute segmentation, tag closure omission, etc.), thereby determining whether malicious vectors are implanted from the tag structure dimension. Second, event handler detection is performed on the preprocessed results to identify 351 event handler attributes and their combination patterns with dangerous functions (such as warning, evaluation, confirmation, prompt, etc.), thereby determining whether script execution intent exists from the event trigger dimension. Third, dangerous resource locator scheme detection is performed on the preprocessed results to identify the appearance of pseudo-protocols such as script protocols and data text hypertext markup languages ​​in attribute values ​​(such as hyperlink references, sources, actions, etc.), thereby determining whether malicious content is introduced from the resource loading dimension. When at least one of the dangerous tags, event handlers, or dangerous resource locators is detected, a tag-layer cross-site scripting attack is determined, and the tag feature parsing result is obtained. Through the triple detection of dangerous tags, event handlers, and dangerous resource locators, the detection process covers the main attack paths of hypertext markup language injection, paying attention to both static tag structures and dynamic event triggering and resource introduction, achieving comprehensive interception of traditional cross-site scripting attack vectors.

[0056] Step S402: Perform scalable vector graphics and mathematical markup language-specific vector detection on the preprocessed results, identify embedded scripts and animation event injections, and obtain specific vector parsing results.

[0057] Specifically, this application identifies embedded scripts and animation event injections by performing Scalable Vector Graphics (Scalable Vector Graphics) and Mathematical Markup Language (MLML)-specific vector detection on the preprocessed results, thereby obtaining specific vector parsing results and achieving accurate coverage of MLML-specific injection vectors in cross-site scripting (XSS) attacks. Scalable Vector Graphics is a vector graphic format based on MLML that supports embedded scripts and event binding within graphic elements. Mathematical Markup Language (MLML) is a mathematical formula description format based on MLML, which also supports event handling and resource referencing. Specific vector detection refers to a technique for targeted screening of attack paths specific to certain MLML extension formats; embedded scripts refer to attack methods that directly introduce or execute script code through elements within Scalable Vector Graphics (such as scripts, foreignObjects, etc.); animation event injection refers to attack methods that use the event attributes (such as start, end, repeat, etc.) of Scalable Vector Graphics animation elements (such as animate, set, etc.) to trigger script execution or resource loading; specific vector parsing results refer to the attack judgment conclusions output based on MLML-specific attack path detection.

[0058] The specific implementation process of this scheme includes: 1) Scalable vector graphics structure detection of the preprocessed results, identifying scalable vector graphics tags and their internal elements, detecting embedded script patterns such as referencing external script resources through graphic elements, embedding Hypertext Markup Language content through foreignObject elements, and loading cross-domain graphic fragments through the href attribute of the use element, thereby determining whether script injection exists from the perspective of the scalable vector graphics carrier. 2) Mathematical Markup Language structure detection of the preprocessed results, identifying mathematical markup language tags and their nested combinations with scalable vector graphics, detecting behaviors such as introducing external resources or executing scripts through mathematical formula containers. 3) Animation event injection detection of the preprocessed results, identifying event attributes (such as start, end, etc.) of scalable vector graphics animation elements (such as animate, set, etc.), detecting script code or resource references bound in animation event handlers, thereby determining whether event-driven script execution exists from the perspective of animation triggering. When at least one of the embedded script or animation event injection is detected, a vector-level cross-site scripting attack is determined, and specialized vector parsing results are obtained. By using scalable vector graphics and mathematical markup language-specific vector detection, the detection process covers extended markup language attack paths that are easily missed by traditional hypertext markup language detection. This effectively counters attackers' bypass methods that utilize browsers' support for parsing vector graphics and mathematical formulas, achieving in-depth defense against the injection of vectors across the entire markup language spectrum.

[0059] Step S403: Perform byte pre-scanning on the preprocessing results, identify script code fragments, perform abstract syntax tree parsing on the script code fragments, extract dangerous function calls and dynamic access patterns, and obtain code semantic parsing results; the script attack parsing results include marker feature parsing results, special vector parsing results, and code semantic parsing results.

[0060] Specifically, this application performs byte pre-scanning on the preprocessed results to identify script code fragments, then performs abstract syntax tree parsing on the script code fragments to extract dangerous function calls and dynamic access patterns, obtaining code semantic analysis results. This enables a deep semantic understanding of obfuscated and transformed script code in cross-site scripting attacks. Byte pre-scanning refers to a lightweight pre-detection mechanism that quickly screens the raw byte stream for script code features (such as parentheses, dots, assignment operators, and identifier combinations). Script code fragments refer to input substrings identified as potentially script code by pre-scanning. Abstract syntax tree parsing is the process of converting script code into a tree-structured representation to reflect the code's syntactic hierarchy and execution logic. Dangerous function calls refer to script built-in or global function calls that may trigger malicious behavior (such as evaluation, warnings, setting timeouts, etc.). Dynamic access patterns refer to behaviors that dynamically access object properties or methods through square brackets or dots (such as dynamic window evaluation, document writing, etc.). Code semantic analysis results refer to the attack judgment conclusions output based on the dangerous patterns extracted at the abstract syntax tree level.

[0061] The specific implementation process of this scheme includes: performing byte pre-scanning on the preprocessed results to detect whether they contain function call characteristics (such as combinations of left and right parentheses), member access characteristics (such as dot connections), assignment characteristics (such as equal sign operations), and identifier characteristics (such as combinations of letters and numbers), thereby quickly identifying candidate fragments of suspected script code and avoiding initiating full abstract syntax tree parsing for non-script input. Then, abstract syntax tree parsing is performed on the candidate fragments, transforming the script code into a tree-like node structure. Node types include function call expressions (such as direct evaluation calls, warnings, and other dangerous functions), member call expressions (such as document writing, window evaluation, and other object member method calls), constructor expressions (such as instantiation of constructors for creating new functions and creating new asynchronous requests), assignment expressions (such as internal hypertext markup language assignment, positional assignment, and other sensitive attribute settings), and bracket dynamic access expressions (such as bracket string index access for dynamic window evaluation). Dangerous function calls and dynamic access patterns are extracted from the abstract syntax tree. When the above dangerous node types are detected, it is determined that there is a cross-site scripting attack at the code level, and the code semantic analysis result is obtained. The script attack parsing results include the marker feature parsing results, the special vector parsing results, and the code semantic parsing results. Thus, the outputs of the three-layer progressive detection together constitute complete script attack judgment evidence. It supports both single-layer independent detection output and multi-layer collaborative comprehensive judgment, providing modular and scalable code semantic evidence input for subsequent feature fusion layers.

[0062] By employing a two-stage processing approach of byte pre-scanning and abstract syntax tree parsing, the detection process ensures deep semantic understanding capabilities while filtering out a large amount of non-script input through a lightweight pre-detection mechanism, significantly reducing computational overhead. Simultaneously, through structured analysis at the abstract syntax tree level, the detection can identify script code processed by escape techniques such as string concatenation, variable obfuscation, and encoding transformation, effectively overcoming the limitations of traditional regular expression matching in detecting syntax-level obfuscation attacks.

[0063] In this way, by performing feature matching on the preprocessed results, dangerous markers, event handlers, and dangerous resource locator schemes are identified, resulting in marker feature parsing results. This intercepts traditional cross-site scripting (XSS) attack vectors at the Hypertext Markup Language (HTML) structural level. By performing Scalable Vector Graphics (Scalable Vector Graphics) and Mathematical Markup Language (MLML)-specific vector detection on the preprocessed results, embedded scripts and animation event injections are identified, resulting in specialized vector parsing results. This covers the attack paths unique to Scalable Vector Graphics and MLML from the dimension of extended markup language vectors. By performing byte pre-scanning on the preprocessed results to identify script code fragments, and then performing abstract syntax tree parsing on these fragments to extract dangerous function calls and dynamic access patterns, code semantic parsing results are obtained. This identifies obfuscated and transformed script attacks at the program semantic understanding level. This three-layer progressive detection architecture (marker layer, vector layer, and code layer) upgrades the detection process from traditional string feature matching to deep analysis at the structural and semantic levels, effectively countering attackers' advanced bypass techniques such as multi-layered code nesting, markup language transformation, and syntax tree obfuscation. Simultaneously, byte pre-scanning quickly filters non-script input, avoiding the initiation of complete abstract syntax tree parsing for irrelevant content, thus controlling computational overhead while ensuring detection depth. Furthermore, the results of the three layers of detection collectively constitute the script attack parsing result, requiring a single attack vector to simultaneously penetrate multiple layers of defense to escape detection, thus forming a defense-in-depth system. In summary, this application achieves a paradigm shift in cross-site script attack detection from surface feature recognition to deep semantic understanding through a three-layer progressive synergy of marker-layer feature matching, vector-layer specialized detection, and code-layer semantic understanding. This effectively overcomes the limitations of traditional regular expression matching in identifying advanced obfuscation and deformation attacks, significantly improving the comprehensiveness and reliability of script attack detection.

[0064] In some optional embodiments, pattern matching is performed on the preprocessing results to obtain matching results, including: Automata are built for different attack types. The preprocessing results are input into the automata so that the automata can scan based on a preset attack type pattern library. The attack types and matching locations that are hit are output in a preset priority order to obtain the matching results.

[0065] Specifically, this application constructs automata for various attack types, inputs preprocessing results into the automata, and enables the automata to scan based on a preset attack type pattern library. The automata then outputs the hit attack types and matching positions according to a preset priority order, thus obtaining the matching results. This achieves rapid parallel detection and priority determination of multiple Web attack types. Here, the automaton refers to a multi-pattern string matching engine built based on finite state automaton theory, capable of matching multiple preset patterns simultaneously in a single scan. Attack types refer to Web security threat categories such as log injection, command injection, path traversal, cross-site scripting, template injection, code execution, server request forgery, and external entity injection. The preset attack type pattern library is a set of malicious feature rules independently compiled for each attack type, containing typical payload fragments, variant forms, and bypass patterns for that attack type. The preset priority order refers to the output priority sequence pre-configured according to the false positive risk of the attack type; the lower the false positive risk, the higher the priority. The matching position refers to the starting offset and length information of the hit pattern in the preprocessing results; the matching result refers to the attack type determination, hit position, and confidence assessment output based on automaton scanning and priority sorting.

[0066] The specific implementation process of this scheme includes: constructing independent automata using the Aho-Corasick multi-mode automaton algorithm for various attack types. Each automaton has multiple built-in attack patterns corresponding to the attack type. These patterns are compiled and loaded from a preset attack type pattern library, allowing each automaton to be specifically optimized for the syntactic features of a particular attack type, avoiding interference between pattern rules of different attack types. The preprocessed results are input into their respective automata, enabling each automaton to scan the input content in parallel based on its built-in pattern library. Multiple pattern hits are detected simultaneously in a single traversal, thus improving the detection efficiency of multiple attack types. When multiple automata hit simultaneously, the hit attack types are sorted according to a preset priority order. The priority is determined by the false positive risk of the attack type (e.g., log injection attacks are configured with the highest priority, and template injection attacks with the lowest priority). The first hit attack type and its corresponding matching position are then output as the matching result. By constructing independent automata for each attack type and using a preset priority output mechanism, the detection process ensures both the independence and optimization space of each attack type detection, while avoiding decision conflicts when multiple types hit concurrently, achieving a simultaneous improvement in detection efficiency and judgment accuracy at the pattern matching layer.

[0067] In this way, by constructing automata for each attack type and inputting the preprocessed results into the automata, the automata scans based on a preset attack type pattern library, thus establishing an independent pattern matching channel for each attack type and avoiding interference between pattern rules of different attack types. Then, the hit attack types and matching positions are output according to a preset priority order to obtain the matching results. This allows for the priority output of the attack judgment with the highest confidence when multiple types are hit. This architecture design, which constructs independent automata for each attack type, allows each automaton to be specifically optimized for the syntactic features of specific attack types, avoiding the decrease in matching efficiency and increase in false positive rate caused by a single automaton handling too many patterns. Simultaneously, the preset priority order implements a first-win-stop output mechanism, quickly locking the highest priority result when multiple attack types are hit concurrently, avoiding redundant interference from low-priority matching in the decision-making process. Furthermore, the scanning method based on the preset attack type pattern library allows the detection rules to be maintained independently and dynamically updated, ensuring rapid response of the detection capability to new attack variants. In summary, this application achieves a simultaneous improvement in the detection efficiency and judgment accuracy of the pattern matching layer through the collaborative design of an independent automaton architecture and a priority output mechanism. It effectively overcomes the limitations of traditional single rule sets in scenarios with mixed attack types, such as rule conflicts and priority confusion, and provides highly reliable pattern matching evidence support for dual-layer fusion detection.

[0068] In some optional embodiments, the hit attack types and matching locations are output in a preset priority order to obtain matching results, including: The attack types detected by the automaton are sorted according to a preset priority, which is determined based on the false alarm risk of each attack type. When multiple attack types are hit, the first hit attack type and its corresponding matching position are output in priority order as the matching result.

[0069] Specifically, this application sorts the attack types hit by the automaton according to a preset priority, which is determined based on the false positive risk of each attack type. When multiple attack types are hit, the first hit attack type and its corresponding matching position are output in priority order as the matching result, thereby achieving efficient decision-making and conflict resolution of the pattern matching layer in scenarios with concurrent hits of multiple attack types. Here, the preset priority refers to the output order rules pre-configured during the automaton construction phase based on the inherent false positive characteristics of each attack type. The false positive risk refers to the probability assessment of the unexpected triggering of a specific attack type's pattern characteristics in a normal business scenario; the lower the false positive risk, the higher the confidence level. The first hit attack type refers to the high-priority attack judgment located at the beginning of the priority sequence after priority sorting; the matching position refers to the starting offset and length information of the hit pattern in the preprocessing result.

[0070] The specific implementation process of this scheme includes: In the automaton construction phase, priority weights are configured for each attack type. The priority weights are determined based on the false positive risk of the attack type—the attack type with the lowest false positive risk (such as log injection, which can be identified in a single match and rarely occurs in normal business) is assigned the highest priority; attack types with a relatively low false positive risk (such as cross-site scripting, external entities, and path traversal) are assigned the second highest priority; attack types with a medium false positive risk (such as command injection, code execution, and server request forgery) are assigned a medium priority; and attack types with the highest false positive risk (such as template injection, where template tags are easily triggered accidentally in normal business) are assigned the lowest priority, thus forming a preset priority sequence. In the detection phase, when multiple automata hit simultaneously, the hit attack types are sorted according to the preset priority sequence, with the attack judgment with the lowest false positive risk and the highest confidence level being output first. Then, the first hit attack type and its corresponding matching position are output in priority order as the matching result, and low-priority hit results are suppressed and no longer output. By using a priority ranking and first-win-stop output mechanism driven by false alarm risk, the detection process can quickly lock in the optimal judgment when multiple types of concurrent hits occur, avoiding redundant interference from low-confidence matching in the decision process, while reducing the downstream processing burden caused by repeated output of multiple types, thus achieving simultaneous optimization of the decision accuracy and computational efficiency of the pattern matching layer.

[0071] In this way, by sorting the attack types hit by the automaton according to a preset priority, and with the preset priority determined by the false positive risk of each attack type, attack types with high confidence and low false positive risk are given priority in judgment. Furthermore, when multiple attack types are hit, the first hit attack type and its corresponding matching position are output as the matching result in priority order, thus quickly locking in the optimal judgment in scenarios with multiple concurrent hits. This mechanism of determining priority based on the degree of false positive risk prioritizes attack types that can be determined in a single match, such as log injection, over attack types that are prone to false triggers, such as template injection, effectively reducing the interference of low-confidence matching on the final judgment. At the same time, the output strategy of stopping at the first win avoids the waste of computational resources and judgment conflicts caused by repeatedly judging the same attack payload for multiple types. In addition, the inverse correlation design between priority and false positive risk gives the output results of the pattern matching layer a natural confidence-level hierarchical characteristic, providing high-quality evidence input for subsequent differentiated weight fusion. In summary, this application achieves simultaneous optimization of the accuracy and computational efficiency of pattern matching layer decision-making through the collaborative design of priority ranking driven by false positive risk and the first-win-stop output mechanism. It effectively overcomes the limitations of traditional rule sets, which lack collaborative ranking and conflict resolution mechanisms, resulting in high false positive rates and significant performance losses, and significantly improves the detection reliability in scenarios with multiple types of concurrent attacks.

[0072] In some alternative embodiments, see Figure 5Step S103 involves fusing the parsing results and matching results according to attack type differential weights to obtain the detection results, specifically including: Step S501: Determine the matching weight based on the attack type corresponding to the matching result, and determine the position weight based on the parameter position corresponding to the preprocessing result.

[0073] Specifically, this application determines the matching weight based on the attack type corresponding to the matching result and the position weight based on the parameter position corresponding to the preprocessing result, thus providing a two-dimensional weight configuration basis for the differentiated weighted calculation of the feature fusion layer. The matching weight refers to the inherent weight coefficient configured based on the attack type hit by the pattern matching layer, reflecting the confidence level of a single match for that attack type. Attack types refer to Web security threat categories such as log injection, cross-site scripting, external entities, path traversal, command injection, code execution, server request forgery, and template injection. Parameter position refers to the location of HTTP request parameters in the request structure, including the query string, request body, cookies, request headers, and path. Position weight is an additive coefficient configured based on the risk level of the parameter position, reflecting the abnormality of attack payloads appearing in different positions.

[0074] The specific implementation process of this scheme includes: after the pattern matching layer outputs the matching result, parsing the attack type identifier corresponding to the matching result, determining the matching weight according to the preset attack type-weight mapping table, and configuring the mapping table differently according to the false positive risk of each attack type—the attack type with the lowest false positive risk (such as log injection) is configured with the highest matching weight (such as 1.0), the attack type with a relatively low false positive risk (such as cross-site scripting, external entities) is configured with the second highest matching weight (such as 0.7), the attack type with a medium false positive risk (such as path traversal) is configured with a medium matching weight (such as 0.7), the attack type with a high false positive risk (such as command injection, code execution, server request forgery) is configured with a low matching weight (such as 0.5), and the attack type with the highest false positive risk (such as template injection) is configured with the lowest matching weight (such as 0.3). This allows the matching contribution of high-confidence attack types to be strengthened in the fusion calculation, while the matching contribution of low-confidence attack types to be suppressed. Simultaneously, the parameter location identifiers corresponding to the preprocessing results are parsed, and the location weights are determined according to a preset location-weight mapping table. The location weights are configured based on the typical attack exposure surface and business sensitivity of the parameter location in the web application—for example, path locations are configured with higher weights because they are directly exposed to the URL and are often attack entry points; request body locations are configured with moderate weights because they are encoded and transmitted and involve complex business interactions; cookie locations are configured with higher weights because they involve session state; query string locations are configured with higher weights because they are visible and easily tampered with; and request header locations are configured with moderate weights because they are commonly used by automation tools. This allows attack evidence from high-risk locations to receive a boost in the fusion calculation, while attack evidence from low-risk locations is moderately suppressed. Through the dual-dimensional configuration of attack type matching weights and parameter location weights, the fusion score reflects both the inherent confidence characteristics of the attack itself and the degree of anomaly of the attack's location, achieving a dual adaptation of detection and judgment to attack type characteristics and attack entry point risk.

[0075] Step S502: Calculate the fusion score based on the matching weight and the position weight.

[0076] Specifically, this application calculates a fusion score based on matching weights and positional weights, thereby comprehensively quantifying the attack type confidence and parameter position risk level of the pattern matching layer into a unified judgment value. The fusion score refers to the final quantitative evaluation value after weighted integration of evidence from the syntax parsing layer and evidence from the pattern matching layer, used for subsequent threshold comparison and handling determination. Matching weights are weighting coefficients configured according to the inherent false positive risk of the attack type; positional weights are additive coefficients configured according to the parameter position risk level.

[0077] The specific implementation process of this scheme includes: First, determining the pattern matching layer score based on the product of the number of matches and the matching weight, combined with a preset upper limit. The preset upper limit is used to prevent a single attack payload from losing control of its score due to a large number of pattern hits. The pattern matching layer score is the smaller of the product of the number of matches and the matching weight and the preset upper limit, thus ensuring that the contribution of pattern matching increases linearly with the number of hits but is constrained by the upper limit. Then, the larger value between the parsing result and the pattern matching layer score is extracted as the initial fusion score, allowing the one with higher confidence between the syntax parsing layer and the pattern matching layer to dominate the initial decision, avoiding the dilution of high-confidence evidence by low-confidence evidence. Subsequently, a fusion score is calculated based on the initial fusion score and the position weights. The initial fusion score is multiplied or weighted and summed with the position weights corresponding to the parameter positions, thus giving additional bonuses to attack evidence from high-risk positions and moderately suppressing attack evidence from low-risk positions. Through the coordinated calculation of matching weights, position weights, and the fusion formula, the fusion score reflects both the pattern hit strength and semantic parsing depth of the attack payload itself, as well as the anomaly degree of the attack entry point, providing a comprehensive quantitative evaluation basis for subsequent threshold decisions.

[0078] Step S503: When both the parsing result and the matching result meet the valid conditions, apply cross-layer gain to the fusion score to obtain the fusion score after gain, which is used as the detection result.

[0079] Specifically, this application achieves a synergistic additive judgment under dual evidence confirmation from the syntax parsing layer and the pattern matching layer by applying a cross-layer gain to the fusion score when both the parsing result and the matching result meet the validity conditions, thus obtaining a post-gain fusion score as the detection result. Here, the parsing result refers to the attack judgment and confidence assessment output by the syntax parsing layer based on structured semantic analysis. The matching result refers to the attack type hit and location information output by the pattern matching layer based on automata scanning. The validity condition refers to the judgment state where the detection results of each layer reach a preset threshold, indicating that the layer has generated attack evidence with judgment value. The fusion score refers to the initial comprehensive evaluation value calculated based on the matching weight and the location weight. The cross-layer gain refers to the preset additive value superimposed on the fusion score when both layers of detection generate valid evidence, simulating the synergistic effect of "multi-source confirmation" in manual judgment. The post-gain fusion score refers to the final quantitative evaluation value after the cross-layer gain is superimposed; the detection result refers to the final output used for subsequent threshold comparison and disposal judgment.

[0080] The specific implementation process of this scheme includes: after calculating the fusion score, determining whether both the parsing result and the matching result meet the validity condition. The validity condition is that the detection result of each layer is greater than a preset validity threshold (e.g., 0.2), indicating that both the syntax parsing layer and the pattern matching layer have independently identified credible attack features. When both the parsing result and the matching result meet the validity condition, a preset gain value (e.g., 0.1) is applied to the fusion score, and the resulting fusion score is used as the detection result. This allows the attack payload with double verification to obtain a higher decision strength than a simple superposition of single layers, reflecting the synergistic effect of "1+1>2". When neither the parsing result nor the matching result meets the validity condition, the fusion score is directly used as the detection result without additional gain. Through the cross-layer gain mechanism, the detection system gives stronger decision strength to high-confidence attacks with double verification of syntax parsing and pattern matching, while avoiding the amplification of false alarms caused by single-layer misclicks, achieving refined differentiation and improved reliability of the fusion decision.

[0081] In this way, by determining the matching weight based on the attack type corresponding to the matching result and the position weight based on the parameter position corresponding to the preprocessing result, different attack types and different parameter positions can obtain differentiated contribution configurations in the fusion calculation. Then, a fusion score is calculated based on the matching weight and position weight, realizing a weighted synthesis of evidence from the syntax parsing layer and the pattern matching layer. When both the parsing result and the matching result meet the valid conditions, a cross-layer gain is applied to the fusion score, and the fusion score after gain is used as the detection result, thus triggering a collaborative enhancement mechanism when both layers of detection produce valid evidence. This dual configuration of attack type differentiated weights and parameter position weights allows the fusion process to perform refined weighting based on the inherent confidence characteristics of the attack type (e.g., configuring injection attacks with the highest weight and template injection attacks with the lowest weight) and the risk level of the parameter position (e.g., the attack risk of query strings and paths is higher than that of the request body), avoiding false positives or false negatives caused by a single threshold decision. Meanwhile, the cross-layer gain mechanism superimposes a preset gain value when both layers of detection are effective, simulating the synergistic effect of "multi-source confirmation" in manual judgment. This makes the fusion score higher than the simple sum of single-layer scores, thus improving the detection strength of high-confidence attacks. Furthermore, the post-gain fusion score serves as the final detection result output, providing collaboratively optimized comprehensive evidence for subsequent threshold decisions. In summary, this application, through the collaborative design of differentiated weight configuration and the cross-layer gain mechanism, achieves a deep fusion of syntax parsing accuracy and pattern matching coverage, effectively overcoming the limitation of traditional single-layer detection where accuracy and coverage cannot be simultaneously achieved, and significantly improving the overall reliability and adaptability of Web attack detection.

[0082] In some optional embodiments, a fusion score is calculated based on matching weights and location weights, including: The pattern matching layer score is determined based on the product of the number of matches and the matching weight, as well as a preset upper limit. The larger value between the parsing result and the pattern matching layer score is extracted as the initial fusion score; The fusion score is calculated based on the initial fusion score and the position weight.

[0083] Specifically, this application determines the pattern matching layer score by multiplying the number of matches by the matching weight and a preset upper limit. Then, it extracts the larger value between the parsing result and the pattern matching layer score as the initial fusion score. Finally, it calculates the fusion score based on the initial fusion score and the positional weight, thereby achieving refined comprehensive quantification of evidence from the syntax parsing layer and the pattern matching layer. Here, the number of matches refers to the number of pattern hits of the same attack type in the pattern matching layer; the matching weight is a weight coefficient configured according to the inherent false positive risk of the attack type. The preset upper limit is a threshold used to constrain the maximum value of the pattern matching layer score, preventing a single attack payload from losing control due to a large number of pattern hits. The pattern matching layer score is the quantified value of the pattern matching evidence after weighting by the number of matches and the upper limit constraint; the parsing result refers to the attack judgment and confidence assessment output by the syntax parsing layer based on structured semantic analysis. The initial fusion score is the intermediate fusion value using the higher confidence evidence from the syntax parsing layer and the pattern matching layer as a benchmark. The positional weight is an additive coefficient configured according to the risk level of the parameter position; the fusion score is the final comprehensive evaluation value after correction by the positional weight.

[0084] The specific implementation process of this scheme includes: First, calculating the product of the number of matches and the matching weight, comparing the product with a preset upper limit, and taking the smaller value as the pattern matching layer score. This ensures that the contribution of pattern matching increases linearly with the number of hits but is constrained by the upper limit, preventing attackers from triggering score inflation by constructing a large number of pattern features. Then, the larger value between the parsing result and the pattern matching layer score is extracted as the initial fusion score. This allows the party with higher confidence in the syntax parsing layer and the pattern matching layer to dominate the initial decision, avoiding the dilution and interference of low-confidence evidence on high-confidence evidence, and achieving a "stronger-dominated" fusion logic. Subsequently, the fusion score is calculated based on the initial fusion score and the position weight. The initial fusion score is multiplied or weighted and summed with the position weight corresponding to the parameter position. This gives additional bonuses to attack evidence from high-risk positions (such as paths and query strings) and moderately suppresses attack evidence from low-risk positions (such as the request body). Through the collaborative calculation of product upper limit constraint, larger value selection and position weight correction, the fusion score reflects both the pattern hit strength and semantic parsing depth of the attack payload itself, as well as the degree of anomaly of the attack entry point, providing a comprehensive quantitative evaluation basis for subsequent cross-layer gain and threshold decision.

[0085] In this way, by determining the pattern matching layer score based on the product of the number of matches and the matching weight, and a preset upper limit, the contribution of the pattern matching layer increases linearly with the number of hits but is constrained by the upper limit, preventing a single attack payload from losing control of its score due to a large number of pattern hits. Furthermore, the larger value between the parsing result and the pattern matching layer score is extracted as the initial fusion score, allowing the one with higher confidence between the syntax parsing layer and the pattern matching layer to dominate the initial decision, avoiding dilution interference from the low-confidence layer to the high-confidence layer. Subsequently, the fusion score is calculated based on the initial fusion score and the position weight, allowing the risk level of the parameter position to finely correct the final score. The above mechanism of calculating the product of the number of matches and the weight, combined with the upper limit constraint, ensures that the pattern matching layer score reflects both the hit strength of the attack payload and prevents score inflation. Simultaneously, the strategy of using the larger value as the initial fusion score ensures that superior evidence in the two-layer detection is not dragged down by inferior evidence, achieving a "stronger-dominated" decision logic. In addition, the superposition of position weights allows the same attack payload to produce differentiated final scores at different parameter positions (such as path and request body), adapting to the risk assessment needs of different positions. In summary, this application achieves refined fusion of evidence from the syntax parsing layer and the pattern matching layer through collaborative calculation of product upper limit constraint, selection of larger value and position weight correction. It effectively overcomes the limitations of traditional simple superposition or logical OR operation that leads to mutual dilution of evidence or amplification of false alarms, and significantly improves the accuracy and stability of fusion judgment.

[0086] In some optional embodiments, HTTP request parameters are obtained and subjected to multiple rounds of decoding and normalization to obtain preprocessed results, including: Extract parameters from the HTTP request to obtain the HTTP request parameters; The parameters are decoded in at most three rounds of iteration, sequentially performing address decoding, character encoding escape decoding, marker entity decoding, and encoded content decoding. The encoded content decoding includes verifying the printable character ratio of the decoding result. The decoding result is then subjected to case-sensitive processing to obtain the preprocessed result.

[0087] Specifically, this application extracts parameters from the HTTP request to obtain HTTP request parameters, and then performs up to three rounds of iterative decoding on the parameters, sequentially executing address decoding, character encoding escape decoding, token entity decoding, and encoded content decoding (where encoded content decoding includes verifying the printable character ratio of the decoding result). Finally, the decoded result is subjected to case-sensitive processing to obtain a preprocessed result, thereby providing a standardized and unobfuscated input basis for subsequent attack detection. The HTTP request parameters refer to the data units carried by the client when sending a request to the server, including the query string (i.e., the key-value pair parameter after the question mark in the Uniform Resource Locator), the request body (i.e., the form data or structured data transmitted in the request body), cookies (i.e., small text data stored by the server on the client for status tracking), request headers (i.e., metadata information transmitted in the request start line and header fields), and the path (i.e., the path segment for accessing the resource in the Uniform Resource Locator). Up to three rounds of iterative decoding means repeatedly performing decoding operations on the input content, with a maximum of three rounds, to prevent computational resource exhaustion caused by infinite loops. Address decoding refers to restoring the percent sign encoding format (e.g., restoring encoded characters in the %XX format to their original form). Character encoding escape decoding refers to restoring Unicode escape sequences (e.g., restoring escape characters in the \uXXXX format to their corresponding characters). Markup entity decoding refers to restoring Hypertext Markup Language entity references (e.g., restoring entities such as &, <, >, &#XXXX; to their corresponding characters). Encoded content decoding refers to decoding and restoring input that conforms to encoding characteristics (e.g., Base64 encoding format). Printable character ratio verification refers to calculating the ratio of the number of printable characters to the total number of characters after decoding. When the ratio is lower than a preset threshold (e.g., 0.85), decoding is considered a failure, thus preventing the misinterpretation of binary data as plaintext or computational resource exhaustion attacks caused by maliciously constructed excessively long encoded inputs. Case uniform processing refers to converting the decoding result to a uniform case format (e.g., converting all to lowercase) to eliminate interference from case distortion in subsequent detection.

[0088] The specific implementation process of this scheme includes: extracting parameters from the HTTP request, covering multiple attack entry points such as query strings, request bodies, cookies, request headers, and paths to ensure no targets are missed. Then, the parameters undergo up to three rounds of iterative decoding, sequentially executing address decoding, character encoding escape decoding, marker entity decoding, and encoded content decoding. The output of each round of decoding serves as the input for the next round, thus countering bypass techniques constructed by attackers through multi-layered encoding nesting (such as address encoding superimposed with character encoding escape, marker entity superimposed with Base64 encoding). During the encoded content decoding process, the proportion of printable characters in the decoding result is verified. When the proportion of printable characters in the decoding result falls below a preset threshold, decoding terminates and reverts to the previous round's result, thereby preventing computationally exhaustive attacks such as Base64 bombs and misjudgments of binary data. Finally, the decoded result is case-sensitively processed to obtain a preprocessed result. Through the collaborative design of hierarchical control of up to three rounds of iterative decoding, sequential decoding pipeline, and printable character ratio verification, the normalization process can not only cope with complex nested encoding confusion but also avoid infinite loops and resource exhaustion, providing a standardized and safe input foundation for subsequent syntax parsing and pattern matching.

[0089] In this way, by extracting parameters from HTTP requests, the HTTP request parameters are obtained, thus covering multiple attack entry points such as query strings, request bodies, cookies, request headers, and paths, ensuring that no targets are missed. The parameters are then decoded in up to three rounds of iteration, sequentially performing address decoding (i.e., restoring the percent sign encoding format), character encoding escape decoding (i.e., restoring the Unicode escape sequence), token entity decoding (i.e., restoring Hypertext Markup Language entities), and encoded content decoding. Encoded content decoding includes verifying the printable character ratio of the decoding result, thereby eliminating bypass techniques constructed by attackers using multi-layered encoding nesting (such as URL encoding superimposed with Unicode escape sequences and token entities). Simultaneously, printable character ratio verification prevents the misinterpretation of binary data as plaintext or the exhaustion of computational resources caused by maliciously constructed excessively long encoded inputs. Finally, the decoded result is case-sensitively processed to obtain a preprocessed result, thus eliminating interference from case distortion in subsequent detection. The aforementioned hierarchical control of up to three rounds of iterative decoding enables the decoding process to handle complex nested encodings while avoiding performance degradation caused by infinite loops. Simultaneously, the pipeline design that sequentially executes multiple decoding types ensures that each encoding feature is processed specifically at a particular stage, preventing restoration failures due to disordered decoding order. Furthermore, printable character ratio verification serves as a constraint on encoded content decoding, establishing a balance between decoding depth and security, and preventing computationally exhaustive attacks such as Base64 bombs. In summary, this application, through the collaborative design of multi-round iterative decoding, a sequential decoding pipeline, and printable character verification, achieves comprehensive elimination of encoding obfuscation and effective control of computational resources. It effectively overcomes the limitations of traditional single-layer decoding in recognizing multi-layered nested encoding bypasses and lacking resource protection mechanisms, providing a standardized and secure input foundation for subsequent syntax parsing and pattern matching.

[0090] In some optional embodiments, the method further includes: The blocking threshold is determined based on a preset sensitivity level, which includes high sensitivity, medium sensitivity, and low sensitivity. The blocking threshold is inversely related to the sensitivity level. When the detection result is greater than or equal to the blocking threshold, a blocking decision is output. When the detection result is less than the blocking threshold but greater than or equal to the log threshold, output a log decision. When the detection result is less than the log threshold, a release decision is output.

[0091] Specifically, this application determines the blocking threshold based on preset sensitivity levels, including high sensitivity, medium sensitivity, and low sensitivity, with the blocking threshold inversely correlated with the sensitivity level. When the detection result is greater than or equal to the blocking threshold, a blocking decision is output; when the detection result is less than the blocking threshold but greater than or equal to the log threshold, a logging decision is output; and when the detection result is less than the log threshold, a permission decision is output. This achieves dynamic adaptation of the detection strategy to the business's risk tolerance and provides three levels of refined handling output. The preset sensitivity level refers to the detection sensitivity level pre-configured according to the security protection requirements of the business scenario. High sensitivity is suitable for scenarios with strict security requirements (such as financial transactions and core data interfaces), while low sensitivity is suitable for scenarios prioritizing business continuity (such as content display and static resource access). The blocking threshold is the lower limit of the fusion score that triggers interception. The blocking threshold is inversely correlated with the sensitivity level; high sensitivity corresponds to a lower blocking threshold (e.g., 0.55), medium sensitivity corresponds to a medium blocking threshold (e.g., 0.65), and low sensitivity corresponds to a higher blocking threshold (e.g., 0.75), thus enabling differentiated handling strategies for the same attack payload in different scenarios. The log threshold refers to the lower limit of the fusion score (e.g., 0.3 by default) that triggers audit logging but allows the request to proceed. Blocking decision refers to the decision to terminate request processing and return an intercepted response; logging decision refers to the decision to allow the request to continue processing but log the detection event for subsequent audit analysis. Allowing decision refers to the decision to allow the request to proceed normally without additional logging.

[0092] The specific implementation process of this solution includes: In the system configuration phase, a preset sensitivity level is selected based on the security requirements of the business scenario. Sensitivity levels include high sensitivity, medium sensitivity, and low sensitivity. A corresponding blocking threshold is determined based on the selected level. The blocking threshold is inversely related to the sensitivity level—high sensitivity scenarios are configured with a lower blocking threshold (e.g., 0.55) to trigger interception even for low-risk attack payloads, achieving strict protection; medium sensitivity scenarios are configured with a medium blocking threshold (e.g., 0.65) to balance protection strength and business impact; and low sensitivity scenarios are configured with a higher blocking threshold (e.g., 0.75) to only intercept high-confidence attacks, prioritizing business continuity. In the detection execution phase, the fusion score (or post-gain fusion score) is compared with the blocking threshold. When the detection result is greater than or equal to the blocking threshold, the attack risk is determined to meet the interception standard, a blocking decision is output, and request processing is terminated. When the detection result is less than the blocking threshold but greater than or equal to the log threshold (e.g., 0.3), the attack risk is deemed noteworthy but does not meet the blocking standard. A log decision is output, allowing the request to continue but retaining audit logs. When the detection result is less than the log threshold, no significant attack risk is deemed, and a pass decision is output, allowing the request to pass normally. Through the inverse correlation configuration of sensitivity levels and blocking thresholds, and a three-tiered fine-grained handling mechanism, the detection system can dynamically adjust the protection strength according to business scenarios. This avoids attacks on high-value businesses due to overly lenient thresholds, while preventing low-value businesses from being affected by overly strict thresholds, achieving a balanced optimization of security protection and business continuity.

[0093] In this way, by determining the blocking threshold based on preset sensitivity levels—high, medium, and low—and with the blocking threshold inversely correlated with the sensitivity level, high-sensitivity scenarios correspond to lenient thresholds (easy to trigger blocking), while low-sensitivity scenarios correspond to strict thresholds (difficult to trigger blocking), achieving dynamic adaptation between the detection strategy and the business's risk tolerance. Furthermore, when the detection result is greater than or equal to the blocking threshold, a blocking decision is output; when it is less than the blocking threshold but greater than or equal to the logging threshold, a logging decision is output; and when it is less than the logging threshold, a permission decision is output, thus forming a three-tiered, refined decision output: blocking, logging, and permission. This inverse correlation between sensitivity level and blocking threshold design allows for differentiated handling strategies for the same attack payload in different business scenarios, avoiding over-blocking of high-value businesses or insufficient protection for low-value businesses with a rigid, one-size-fits-all threshold. Simultaneously, the three-tiered decision output mechanism upgrades the detection system from a binary blocking / permission approach to a flexible handling system that includes an intermediate state of logging, ensuring real-time blocking of high-risk attacks, retaining audit traceability capabilities for medium-risk attacks, and ensuring seamless passage of normal traffic. Furthermore, the configurable design with preset sensitivity levels allows security policies to be flexibly adjusted according to business needs, enabling dynamic switching of protection strength without modifying the underlying detection logic. In summary, this application achieves a balanced optimization of detection sensitivity and business continuity through the collaborative design of sensitivity-driven reverse threshold configuration and a three-tiered flexible decision mechanism. This effectively overcomes the limitations of traditional fixed-threshold detection strategies, which suffer from insufficient adaptability to different business scenarios and overly rigid handling methods, significantly improving the flexibility and maintainability of Web attack detection.

[0094] See Figure 6 , Figure 6 This is a schematic diagram of the overall process of the Web attack detection method in this embodiment. The process includes: HTTP request parameters being sent from the client to the Web application firewall as the original input data source for the entire detection process. The parameters include at least one of the following: query string, request body, cookie, request header, and path, covering all possible attack entry points in the Web request.

[0095] HTTP request parameters first enter the normalization layer (Layer 0) for multiple rounds of decoding and normalization to eliminate the interference of encoding obfuscation on subsequent detection. Specifically, the following operations are performed: URL decoding: restore the percent sign encoding format (e.g., restore %XX encoded characters to their original characters); Unicode decoding: restoring Unicode escape sequences (e.g., restoring \uXXXX format characters to their corresponding characters); HTML entity decoding: restoring Hypertext Markup Language entity references (such as restoring &, <, etc. to their corresponding characters); Base64 decoding: Decodes input that conforms to Base64 encoding characteristics and verifies the printable character ratio of the decoding result (to prevent binary data from being misinterpreted as plaintext or from being attacked by a Base64 bomb). Convert to lowercase: Perform case-consistent processing on the decoded results to eliminate interference from case distortion in subsequent detection.

[0096] The normalization layer employs a maximum of three rounds of iterative decoding, with the output of each round serving as the input for the next. This counters attackers' attempts to bypass the normalization layer using multi-layered encoding nesting (e.g., URL encoding overlaid with Unicode escaping, HTML entities overlaid with Base64 encoding). Simultaneously, printable character ratio verification prevents computational resource exhaustion attacks. After processing by the normalization layer, a preprocessed result is obtained, providing a standardized and unobfuscated input foundation for subsequent detection.

[0097] The preprocessing results are fed into the parsing layer (Layer 1) in parallel, where high-precision structured semantic analysis is performed for various attack types, including the following six independent detectors: (1) SQL state machine The preprocessed results are subjected to a structured scan to track the depth of quotation mark nesting (the opening and closing levels of single quotes, double quotes, and backticks) and the contextual relationships of query language keywords (recording the order of keyword appearance and combination relationships). Based on the depth of quotation mark nesting and contextual relationships, structured anomaly patterns such as quotation mark imbalance, union queries, Boolean tautology, comment injection, conditional comments, stacked queries, time-based blind injection, system table access, file operations, command execution, and backtick injection are identified to obtain structured parsing results.

[0098] (2) XSS three-layer detection Multi-layer script attack vector detection is performed on the preprocessed results to identify three layers of dangerous operation patterns: Tag layer: Perform tag feature matching to identify dangerous tags (such as script, svg, etc.), event handlers (such as onload, onclick, etc.) and dangerous resource locator schemes (such as pseudo-protocols such as javascript:), and obtain the tag feature parsing results; Vector layer: Performs scalable vector graphics and mathematical markup language-specific vector detection, identifies embedded scripts and animation event injections (such as SVG animate onbegin, MathML href, etc.), and obtains specific vector parsing results; Code layer: Perform byte pre-scanning to identify script code fragments, then perform abstract syntax tree parsing to extract dangerous function calls (such as eval, alert, etc.) and dynamic access patterns (such as window["eval"], etc.) to obtain code semantic parsing results; The results of script attack analysis include the above-mentioned marker feature analysis results, special vector analysis results, and code semantic analysis results.

[0099] (3) Shell injection The preprocessed results are subjected to command delimiter detection (positioning semicolons, pipe characters, logical connectors, etc.) and system command matching (compared with a predefined system command library) to identify the syntactic structure of command concatenation or command substitution and obtain the command injection parsing results.

[0100] (4) SSTI template injection The preprocessed results are subjected to template syntax tag matching (identifying syntax symbols of various template engines) and sensitive object access detection (identifying sensitive object calls such as operating system interfaces, process management, and runtime execution) to obtain template injection parsing results.

[0101] (5) Log4Shell The preprocessed results are subjected to variable substitution simulation (simulating the substitution behavior of the target system's variable parsing engine, restoring obfuscated variants such as case conversion, character selection, and environment variable reading layer by layer) and nested structure detection (identifying the recursive structure of multi-level variable references) to obtain the configuration injection parsing results.

[0102] (6) NoSQL injection The preprocessed results are subjected to database operator anomaly detection to identify abnormal occurrences of operators such as conditional statements, greater than, not equal to, and regular expressions in unconventional contexts, thereby obtaining the database injection parsing results.

[0103] The parsing results include at least one of the following: structured parsing results, script attack parsing results, command injection parsing results, template injection parsing results, configuration injection parsing results, and database injection parsing results.

[0104] The preprocessing results are simultaneously fed into the pattern matching layer (Layer 2). Aho-Corasick multi-mode automata are constructed for each attack type (one independent automaton for each attack type), and scanning is performed based on a pre-defined attack type pattern library. Log4Shell automaton: Detects various JNDI variants (such as ladp, rmi, corba, etc.); RCE automaton: detects commands on both Linux and Windows platforms (such as certutil, bitsadmin, wmic, etc.). Path traversal automata: detect path traversal features (such as .. / , ..\, UNC paths, ADS data streams, etc.); XSS automaton: detects a complete set of cross-site script vectors containing scalable vector graphics / mathematical markup language vectors; SSTI automaton: detects syntax tags for various template engines; Code execution automaton: detects dangerous APIs in multiple languages ​​including Java, PHP, Python, and Node. SSRF automaton: detects intranet protocols, address ranges, and cloud service provider metadata endpoints; XXE automaton: Detects DTD / ENTITY keywords and Billion Laughs entity expansion.

[0105] Each automaton performs multi-pattern matching on the preprocessed results based on its built-in pattern library. When multiple automata hit simultaneously, they output the first hit attack type and its corresponding matching position in a preset priority order (the priority order is determined based on the false alarm risk of the attack type, such as Log4Shell being the highest and SSTI being the lowest), thus obtaining the matching result.

[0106] The parsing results from the syntax parsing layer and the matching results from the pattern matching layer are fed into the feature fusion layer (Layer 3) for differential weight fusion based on attack type, outputting the final detection result (confidence 0.0~1.0): Differentiated weighting: The matching weight is determined based on the attack type corresponding to the matching result (the lower the false positive risk, the higher the weight), and the position weight is determined based on the parameter position (query string, request body, cookie, request header, path) corresponding to the preprocessing result. Fusion score calculation: The pattern matching layer score is determined based on the product of the number of matches and the matching weight (constrained by a preset upper limit). The larger value between the parsing result and the pattern matching layer score is taken as the initial fusion score. Then, the fusion score is calculated based on the initial fusion score and the position weight. Cross-layer gain: When both the parsing result and the matching result meet the valid conditions (both are greater than the preset valid threshold), a cross-layer gain (preset gain value) is applied to the fusion score to obtain the fusion score after gain, which is used as the final detection result.

[0107] The detection results output by the feature fusion layer enter the final decision stage: The blocking threshold is determined based on a preset sensitivity level (high sensitivity / medium sensitivity / low sensitivity) (the higher the sensitivity, the lower the threshold, showing an inverse correlation); when the detection result is greater than or equal to the blocking threshold, a blocking (BLOCK) decision is output, terminating the request processing; when the detection result is less than the blocking threshold but greater than or equal to the log threshold, a logging (LOG) decision is output, allowing the request to continue but retaining audit records; when the detection result is less than the log threshold, a passing (PASS) decision is output, allowing the request to pass normally.

[0108] The entire architecture adopts a pipeline + parallel processing design. Layer 0 executes multiple rounds of decoding sequentially, Layer 1 and Layer 2 process in parallel, and Layer 3 executes fusion decision sequentially. This optimizes processing performance while ensuring detection accuracy, achieving a balance between detection rate, accuracy, and performance.

[0109] The following describes an apparatus embodiment of this application, which can be used to execute the Web attack detection method in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the Web attack detection method described above.

[0110] This disclosure also provides a web attack detection device 700, such as... Figure 7 As shown, it includes: Normalization module 701 is used to obtain HTTP request parameters and perform multi-round decoding and normalization processing to obtain preprocessed results; The processing module 702 is used to perform syntax parsing and pattern matching on the preprocessed results to obtain parsing results and matching results. The syntax parsing includes performing structured semantic analysis for various attack types. The structured semantic analysis includes at least one of state machine-based semantic analysis, abstract syntax tree-based semantic analysis, syntax feature tag-based semantic analysis, and rule substitution simulation-based semantic analysis. The pattern matching includes constructing automata for various attack types and performing multi-type pattern matching on the preprocessed results based on the automata. The fusion module 703 is used to fuse the parsing results and matching results according to the attack type differential weight to obtain the detection results.

[0111] In some optional embodiments, the processing module 702 performs syntax parsing on the preprocessing result to obtain the parsing result, including: The preprocessed results are subjected to a structured scan to track the depth of quotation mark nesting and the contextual association of keywords in the query language. Based on the depth of quotation mark nesting and contextual association, structured anomaly patterns are identified to obtain structured parsing results. Multi-layer script attack vector detection is performed on the preprocessed results to identify dangerous operation patterns at the tag layer, vector layer, and code layer, and to obtain script attack parsing results. The preprocessed results are subjected to command delimiter detection and system command matching to obtain command injection parsing results. The preprocessed results are subjected to template syntax tag matching and sensitive object access detection to obtain template injection parsing results. The preprocessed results are subjected to variable substitution simulation and nested structure detection to obtain the configuration injection parsing results; Perform database operator anomaly detection on the preprocessed results to obtain the database injection parsing results; The parsing results include at least one of the following: structured parsing results, script attack parsing results, command injection parsing results, template injection parsing results, configuration injection parsing results, and database injection parsing results.

[0112] In some optional embodiments, the processing module 702 performs a structured scan on the preprocessed results, tracks the depth of quotation mark nesting and the contextual association of query language keywords, identifies structured anomaly patterns based on the quotation mark nesting depth and contextual association, and obtains structured parsing results, including: Scan the preprocessing results and count the nesting depth of single quotes, double quotes, and backticks to obtain the quote depth status; Record the query language keywords encountered during the scanning process and their order of appearance to obtain the keyword context association; Based on the quote depth state and keyword context association, identify at least one of the following: quote imbalance, union query, Boolean tautology, comment injection, conditional comment, stacked query, time blind injection, system table access, file operation, command execution, and backtick injection, and obtain structured parsing results.

[0113] In some optional embodiments, the processing module 702 performs multi-layer script attack vector detection on the preprocessed results, identifies dangerous operation patterns at the tag layer, vector layer, and code layer, and obtains script attack parsing results, including: The preprocessed results are subjected to feature matching to identify hazard markers, event handlers, and hazard resource locator schemes, resulting in the marker feature parsing results. The preprocessed results are subjected to scalable vector graphics and mathematical markup language-specific vector detection to identify embedded scripts and animation event injection, and specific vector parsing results are obtained. The preprocessed results are pre-scanned to identify script code fragments. The script code fragments are then parsed using an abstract syntax tree to extract dangerous function calls and dynamic access patterns, resulting in code semantic analysis results. The results of script attack analysis include the results of marker feature analysis, the results of special vector analysis, and the results of code semantic analysis.

[0114] In some optional embodiments, the processing module 702 performs pattern matching on the preprocessing result to obtain a matching result, including: Automata are built for different attack types. The preprocessing results are input into the automata so that the automata can scan based on a preset attack type pattern library. The attack types and matching locations that are hit are output in a preset priority order to obtain the matching results.

[0115] In some optional embodiments, the processing module 702 outputs the hit attack types and matching locations in a preset priority order to obtain matching results, including: The attack types detected by the automaton are sorted according to a preset priority, which is determined based on the false alarm risk of each attack type. When multiple attack types are hit, the first hit attack type and its corresponding matching position are output in priority order as the matching result.

[0116] In some optional embodiments, the fusion module 703 fuses the parsing results and matching results according to attack type differential weights to obtain detection results, including: The matching weight is determined based on the attack type corresponding to the matching result, and the position weight is determined based on the parameter position corresponding to the preprocessing result. The fusion score is calculated based on matching weights and location weights; When both the parsing result and the matching result meet the valid conditions, a cross-layer gain is applied to the fusion score to obtain the gained fusion score, which is then used as the detection result.

[0117] In some optional embodiments, the fusion module 703 calculates a fusion score based on matching weights and position weights, including: The pattern matching layer score is determined based on the product of the number of matches and the matching weight, as well as a preset upper limit. The larger value between the parsing result and the pattern matching layer score is extracted as the initial fusion score; The fusion score is calculated based on the initial fusion score and the position weight.

[0118] In some optional embodiments, the normalization module 701 obtains the HTTP request parameters and performs multiple rounds of decoding and normalization processing to obtain a preprocessed result, including: Extract parameters from the HTTP request to obtain the HTTP request parameters; The parameters are decoded in at most three rounds of iteration, sequentially performing address decoding, character encoding escape decoding, marker entity decoding, and encoded content decoding. The encoded content decoding includes verifying the printable character ratio of the decoding result. The decoding result is then subjected to case-sensitive processing to obtain the preprocessed result.

[0119] In some optional embodiments, the fusion module 703 is further configured to: The blocking threshold is determined based on a preset sensitivity level, which includes high sensitivity, medium sensitivity, and low sensitivity. The blocking threshold is inversely related to the sensitivity level. When the detection result is greater than or equal to the blocking threshold, a blocking decision is output. When the detection result is less than the blocking threshold but greater than or equal to the log threshold, output a log decision. When the detection result is less than the log threshold, a release decision is output.

[0120] The acquisition, storage, and application of any type of information, such as user personal information, involved in the technical solutions disclosed herein comply with relevant laws and regulations and do not violate public order and good morals.

[0121] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0122] Figure 8 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0123] like Figure 8 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0124] Multiple components in device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 808, such as various types of monitors, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0125] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as web attack detection methods. For example, in some embodiments, the web attack detection method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps described above may be performed. Alternatively, in other embodiments, the computing unit 801 may be configured to perform web attack detection methods by any other suitable means (e.g., by means of firmware).

[0126] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0127] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to the processor or controller of a general-purpose computer, special-purpose computer, or other programmable web attack detection device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0128] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0129] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0130] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0131] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0132] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0133] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for detecting web attacks, wherein, The method includes: Obtain the HTTP request parameters and perform multiple rounds of decoding and normalization to obtain the preprocessed result; The preprocessed results are subjected to syntax parsing and pattern matching to obtain parsing results and matching results. The syntax parsing includes structured semantic analysis for various attack types. The structured semantic analysis includes at least one of state machine-based semantic analysis, abstract syntax tree-based semantic analysis, syntax feature tagging-based semantic analysis, and rule substitution simulation-based semantic analysis. The pattern matching includes constructing automata for various attack types and performing multi-type pattern matching on the preprocessed results based on the automata. The parsing results and the matching results are fused together according to the attack type differential weights to obtain the detection results.

2. The method according to claim 1, wherein, The step of parsing the preprocessed result to obtain the parsing result includes: The preprocessed results are subjected to a structured scan to track the nesting depth of quotation marks and the contextual association of keywords in the query language. Based on the nesting depth of quotation marks and the contextual association, structured anomaly patterns are identified to obtain structured parsing results. The preprocessed results are subjected to multi-layer script attack vector detection to identify dangerous operation patterns at the marker layer, vector layer, and code layer, thereby obtaining script attack parsing results. The preprocessed results are subjected to command delimiter detection and system command matching to obtain command injection parsing results; The preprocessed results are subjected to template syntax tag matching and sensitive object access detection to obtain template injection parsing results; The preprocessed results are subjected to variable substitution simulation and nested structure detection to obtain configuration injection parsing results; The preprocessed results are subjected to database operator anomaly detection to obtain database injection parsing results; The parsing results include at least one of the following: the structured parsing results, the script attack parsing results, the command injection parsing results, the template injection parsing results, the configuration injection parsing results, and the database injection parsing results.

3. The method according to claim 2, wherein, The preprocessed results are subjected to a structured scan, which tracks the depth of quotation mark nesting and the contextual association of query language keywords. Based on the depth of quotation mark nesting and the contextual association, structured anomaly patterns are identified to obtain structured parsing results, including: Scan the preprocessing results and count the nesting depth of single quotes, double quotes, and backticks to obtain the quote depth status; Record the query language keywords encountered during the scanning process and their order of appearance to obtain the keyword context association; Based on the quote depth state and the context association with the keyword, identify at least one of the following: quote imbalance, union query, Boolean tautology, comment injection, conditional comment, stacked query, time blind injection, system table access, file operation, command execution, and backtick injection, and obtain the structured parsing result.

4. The method according to claim 2, wherein, The preprocessed results are subjected to multi-layer script attack vector detection to identify dangerous operation patterns at the marker layer, vector layer, and code layer, resulting in script attack parsing results, including: The preprocessed results are subjected to feature matching to identify hazard markers, event handlers, and hazard resource locator schemes, resulting in the feature parsing results. The preprocessed results are subjected to scalable vector graphics and mathematical markup language-specific vector detection to identify embedded scripts and animation event injection, and specific vector parsing results are obtained. The preprocessed results are subjected to byte pre-scanning to identify script code fragments. The script code fragments are then parsed using an abstract syntax tree to extract dangerous function calls and dynamic access patterns, resulting in code semantic parsing results. The script attack parsing results include the marker feature parsing results, the special vector parsing results, and the code semantic parsing results.

5. The method according to claim 1, wherein, The step of performing pattern matching on the preprocessed result to obtain the matching result includes: Automata are constructed for various attack types, and the preprocessing results are input into the automata so that the automata scans based on a preset attack type pattern library. The attack types and matching locations that are hit are output in a preset priority order to obtain the matching results.

6. The method according to claim 5, wherein, The process of outputting the hit attack types and matching locations according to a preset priority order to obtain the matching results includes: The attack types detected by the automaton are sorted according to a preset priority, which is determined based on the false alarm risk of the attack type. When multiple attack types are hit, the first hit attack type and its corresponding matching position are output in priority order as the matching result.

7. The method according to claim 1, wherein, The step of fusing the parsing results and the matching results according to attack type differential weights to obtain the detection results includes: The matching weight is determined based on the attack type corresponding to the matching result, and the position weight is determined based on the parameter position corresponding to the preprocessing result. A fusion score is calculated based on the matching weight and the location weight; When both the parsing result and the matching result meet the valid conditions, a cross-layer gain is applied to the fusion score to obtain the post-gain fusion score, which is used as the detection result.

8. The method according to claim 7, wherein, The calculation of the fusion score based on the matching weight and the position weight includes: The pattern matching layer score is determined based on the product of the number of matches and the matching weight, as well as a preset upper limit. The larger value between the parsing result and the pattern matching layer score is extracted as the initial fusion score; The fusion score is calculated based on the initial fusion score and the position weight.

9. The method according to claim 1, wherein, The process of obtaining HTTP request parameters and performing multiple rounds of decoding and normalization to obtain preprocessed results includes: Extract parameters from the HTTP request to obtain the HTTP request parameters; The parameters are decoded in up to three rounds of iteration, sequentially performing address decoding, character encoding escape decoding, marker entity decoding, and encoded content decoding. The encoded content decoding includes verifying the printable character ratio of the decoding result. The decoding result is then subjected to case-sensitive processing to obtain the preprocessed result.

10. The method according to any one of claims 1 to 9, wherein, The method further includes: A blocking threshold is determined based on a preset sensitivity level, wherein the sensitivity level includes high sensitivity, medium sensitivity, and low sensitivity, and the blocking threshold is inversely correlated with the sensitivity level. When the detection result is greater than or equal to the blocking threshold, a blocking determination is output; When the detection result is less than the blocking threshold and greater than or equal to the log threshold, output a log recording decision; When the detection result is less than the log threshold, a release decision is output.

11. A web attack detection device, wherein, The device includes: The normalization module is used to obtain HTTP request parameters and perform multiple rounds of decoding and normalization to obtain preprocessed results. The processing module is used to perform syntax parsing and pattern matching on the preprocessed results to obtain parsing results and matching results. The syntax parsing includes performing structured semantic analysis for various attack types. The structured semantic analysis includes at least one of state machine-based semantic analysis, abstract syntax tree-based semantic analysis, syntax feature tag-based semantic analysis, and rule substitution simulation-based semantic analysis. The pattern matching includes constructing automata for various attack types and performing multi-type pattern matching on the preprocessed results based on the automata. The fusion module is used to fuse the parsing results and the matching results according to the attack type differential weights to obtain the detection results.

12. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method of any one of claims 1-10.

13. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-10.

14. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-10.

Images