SQL statement exception detection method and device and nonvolatile storage medium

Abstract

The application discloses a kind of SQL statement exception detection method, device and nonvolatile storage medium.Therein, the method includes: receiving the SQL statement text to be detected;Based on the preset SQL language rule, the SQL statement text is analyzed, and syntax analysis tree is determined;By depth-first traversal to the syntax analysis tree, structural features are extracted, and structural string is obtained;Hash value corresponding to structural string is calculated;Hash value is compared with the preset SQL structure feature set, and comparison result is obtained;In the case where comparison result is passed, based on the preset semantic detection rule, traverse syntax analysis tree, identify the exception in SQL statement text, and obtain exception detection result.The present application solves the technical problems that the current SQL statement exception detection is relatively complex, the accuracy is low by regular matching detection directly, and it is difficult to find abnormal or variant statements when there are more statements.

Description

Technical Field

[0001] This invention relates to the field of SQL statement detection technology, and more specifically, to a method, apparatus, and non-volatile storage medium for detecting SQL statement anomalies. Background Technology

[0002] Currently, SQL code text detection using regular expression matching has low accuracy. Furthermore, the complex structure of SQL statements—while other high-level programming languages ​​typically have a single, complete command line—can result in hundreds of lines of complex nested structures. In big data scenarios, the large number of statements makes it difficult to detect anomalies or mutations, leading to lower security.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a method, apparatus, and non-volatile storage medium for detecting SQL statement anomalies, thereby at least solving the technical problems of current SQL statement anomaly detection, such as complex statements, low accuracy of direct detection through regular expression matching, and difficulty in detecting abnormal or mutated statements when there are many statements.

[0005] According to one aspect of the present invention, an SQL statement anomaly detection method is provided, comprising: receiving an SQL statement text to be detected; analyzing the SQL statement text based on preset SQL language rules to determine a syntax analysis tree, wherein the syntax analysis tree includes a first node representing a syntax category and a second node representing a lexical unit; extracting structural features by performing a depth-first traversal of the syntax analysis tree to obtain a structure string; calculating the hash value corresponding to the structure string; comparing the hash value with a preset SQL structure feature set to obtain a comparison result; if the comparison result is successful, traversing the syntax analysis tree based on preset semantic detection rules to identify anomalies in the SQL statement text and obtain an anomaly detection result, wherein the comparison result is indicated by the presence of a hash value in the SQL structure feature set.

[0006] Optionally, based on preset SQL language rules, the SQL statement text is analyzed to determine a syntax tree, including: segmenting the SQL statement text into words based on preset SQL language rules to obtain multiple lexical units, wherein the lexical units include at least one of the following: keywords, identifiers, constants, operators, parameter placeholders, and comments; inputting the multiple lexical units into a preset SQL syntax analyzer to output the syntax parsing corresponding to the SQL statement text, wherein the syntax parsing includes syntax categories; and generating a syntax tree based on the multiple lexical units and the syntax parsing.

[0007] Optionally, by performing a depth-first traversal of the parsing tree, structural features are extracted to obtain a structural string, including: sequentially identifying the category names corresponding to nodes in the parsing tree in a depth-first order from the root node to the leaf node, and removing the semantic content in the nodes to obtain a new parsing tree, wherein the category names corresponding to the nodes include the grammar category name corresponding to the first node and the lexical unit type corresponding to the second node; and concatenating the nodes in the new parsing tree into a string in a depth-first order to obtain the structural string.

[0008] Optionally, it also includes: generating an alarm event based on the SQL statement text if the comparison result is unsuccessful; and sending the alarm event back to the target account.

[0009] Optionally, it also includes: receiving the audit results from the target account based on the alarm event feedback; and if the audit result indicates that the SQL statement text is normal, adding the structure string and hash value to the SQL structure feature set.

[0010] Optionally, when the semantic detection rules include multiple rules, based on the preset semantic detection rules, the syntax analysis tree is traversed to identify anomalies in the SQL statement text and obtain anomaly detection results, including: obtaining the risk weight values ​​corresponding to each of the multiple rules; traversing multiple nodes in the syntax analysis tree, selecting the corresponding rule from the multiple rules for detection based on the type of the node, and obtaining the detection results corresponding to each of the multiple nodes; determining the target risk value corresponding to each of the multiple nodes based on the detection results corresponding to each of the multiple nodes and the risk weight values ​​corresponding to each of the multiple rules; and determining the anomaly detection results based on the target risk values ​​corresponding to each of the multiple nodes.

[0011] According to another aspect of the present invention, an SQL statement anomaly detection device is also provided, comprising: a receiving module for receiving SQL statement text to be detected; an analysis module for analyzing the SQL statement text based on preset SQL language rules to determine a syntax analysis tree, wherein the syntax analysis tree includes a first node representing a syntax category and a second node representing a lexical unit; an extraction module for extracting structural features by performing a depth-first traversal of the syntax analysis tree to obtain a structure string; a calculation module for calculating a hash value corresponding to the structure string; a comparison module for comparing the hash value with a preset SQL structure feature set to obtain a comparison result; and an identification module for identifying anomalies in the SQL statement text by traversing the syntax analysis tree based on preset semantic detection rules when the comparison result is successful, thereby obtaining an anomaly detection result, wherein the comparison result is obtained by indicating that the SQL structure feature set includes a hash value.

[0012] According to another aspect of the present invention, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored program, wherein, when the program is running, the device where the non-volatile storage medium is located is controlled to execute any of the above-described SQL statement anomaly detection methods.

[0013] According to another aspect of the present invention, a computer device is also provided, the computer device including a processor, the processor being configured to run a program, wherein the program executes any of the above-described SQL statement anomaly detection methods during runtime.

[0014] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements any of the above-described SQL statement anomaly detection methods.

[0015] In this embodiment of the invention, an SQL statement anomaly detection method is adopted. This method involves receiving the SQL statement text to be detected; analyzing the SQL statement text based on preset SQL language rules to determine a syntax analysis tree, where the syntax analysis tree includes a first node representing the syntax category and a second node representing the lexical unit; extracting structural features by performing a depth-first traversal of the syntax analysis tree to obtain a structure string; calculating the hash value corresponding to the structure string; comparing the hash value with a preset SQL structure feature set to obtain a comparison result; if the comparison result is successful, traversing the syntax analysis tree based on preset semantic detection rules to identify anomalies in the SQL statement text, obtaining an anomaly detection result. The comparison result, by representing the SQL structure feature set including the hash value, achieves the purpose of separating and independently detecting the syntactic structure and semantic content of the SQL statement, thereby improving the accuracy and security of SQL statement anomaly detection. This solves the technical problems of current SQL statement anomaly detection methods, such as the low accuracy of direct detection through regular expression matching when the statement is complex, and the difficulty in detecting anomalies or variant statements when there are many statements. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0017] Figure 1 A hardware structure block diagram of a computer terminal for implementing an SQL statement anomaly detection method is shown.

[0018] Figure 2 This is a flowchart illustrating the SQL statement anomaly detection method provided according to an embodiment of the present invention;

[0019] Figure 3 This is a schematic diagram of the process of constructing a syntax analysis tree according to an optional embodiment of the present invention;

[0020] Figure 4 This is a schematic diagram of an SQL statement anomaly detection method provided by an optional embodiment of the present invention;

[0021] Figure 5 This is a structural block diagram of an SQL statement anomaly detection device provided according to an embodiment of the present invention. Detailed Implementation

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

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] According to an embodiment of the present invention, a method embodiment for detecting SQL statement anomalies is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0025] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing an SQL statement anomaly detection method is shown. Figure 1As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0026] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0027] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the SQL statement anomaly detection method in this embodiment of the invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the SQL statement anomaly detection method of the aforementioned application. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0028] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0029] Figure 2 This is a flowchart illustrating the SQL statement anomaly detection method provided according to an embodiment of the present invention, as shown below. Figure 2 As shown, the method includes the following steps:

[0030] Step S202: Receive the SQL statement text to be tested.

[0031] In this step, the SQL statement text comes from various scenarios, including but not limited to: SQL string literals embedded in the application source code, SQL script files (such as .sql files) written by database administrators, SQL query statements generated by low-code platforms or visual drag-and-drop tools, SQL fragments dynamically concatenated from API interfaces, SQL execution statements captured in database connection pools or middleware logs, SQL statements in ETL data processing tasks, and SQL statements ultimately generated and sent to the database through an ORM framework. Regardless of whether the SQL statement is in plain text form, parameterized placeholders (such as ?, $1), or nested in a programming language string concatenation expression, the complete SQL statement is used as input to ensure the originality and completeness of the detection.

[0032] Step S204: Based on preset SQL language rules, analyze the SQL statement text to determine the syntax analysis tree, wherein the syntax analysis tree includes a first node representing the syntax category and a second node representing the lexical unit.

[0033] In this step, the statement text can first be segmented based on SQL language rules, and then the SQL language parser built based on the ANTLR syntax analysis tool can be called to parse the SQL statement text.

[0034] The received SQL statement text is taken as input and decomposed into lexical units (tokens) by the lexer, such as keywords, identifiers, operators, constants, and placeholders. Then, the parser identifies the grammatical structure according to grammatical rules, constructing a complete parse tree. This parse tree contains two types of nodes:

[0035] The first node: Internal nodes that represent syntax categories, such as "SELECT_STATEMENT", "WHERE_CLAUSE", "JOIN_CLAUSE", "SUBQUERY", "AGGREGATE_FUNCTION", etc.

[0036] The second node represents the leaf nodes of the lexical unit, such as "IDENTIFIER", "NUMBER", "STRING_LITERAL", "PARAMETER", and "OPERATOR".

[0037] A syntax tree can accurately reflect the syntactic hierarchy of an SQL statement, facilitating subsequent structural feature extraction and anomaly detection.

[0038] Figure 3 This is a schematic diagram of the process of constructing a syntax tree according to an optional embodiment of the present invention, such as... Figure 3 As shown, the Lexer is the lexical analyzer, responsible for combining characters into words or lexical symbols / tokens. The Parser is the syntax parser, responsible for analyzing and processing the input lexical symbols, identifying the structure of the sentence, and constructing the corresponding parse tree. The parse tree records the process by which the parser identifies the structure of the input sentence and the various components of the sentence structure; the internal nodes of the parse tree are phrase names, and the leaf nodes are the input lexical symbols. A sentence is a linear combination of lexical symbols, essentially a serialization of the leaf nodes during the depth-first traversal of the parse tree.

[0039] Step S206: Extract structural features by performing a depth-first traversal of the parsing tree to obtain the structural string.

[0040] In this step, a depth-first search (DFS) traversal is performed on the generated parsing tree, following the rule of "visiting the parent node first, then its child nodes in sequence, with left subtrees prioritized." During the traversal, the system extracts only two types of node type identifiers, ignoring all semantic content: for the first node (grammar category), its corresponding grammar category name is extracted; for the second node (lexical unit), its lexical unit type is extracted. All specific values ​​are discarded, including table names, field names, numeric values ​​(e.g., 100), strings (e.g., 'admin'), parameter values ​​(e.g., the actual value corresponding to '?'). All extracted type identifiers are concatenated sequentially according to the DFS access order, connected by a uniform delimiter, to form a unique structure string.

[0041] By stripping away the semantic content of SQL statements and retaining only their syntactic structural skeleton, the "structural invariance" of SQL statements is achieved. Regardless of how the statement is obfuscated through methods such as adding comments, adjusting line breaks, rewriting parameter order, replacing capitalization, or inserting spaces, as long as its syntactic structure remains fundamentally unchanged, the generated structure string will be completely consistent. This mechanism completely overcomes the false positives and false negatives caused by format differences in traditional detection methods based on regular expression matching or string comparison. It ensures that SQL statements with the same semantics but different syntax are identified as having the same pattern in the system, thus providing stable, reliable, and interference-resistant underlying support for subsequent whitelist comparison based on structure hashing, precise triggering of semantic rules, and structural anomaly identification for SQL injection attacks. Simultaneously, the compactness and uniqueness of the structure string significantly improve comparison efficiency and storage performance, laying a solid foundation for real-time detection and fingerprint database management of large-scale SQL statements.

[0042] Step S208: Calculate the hash value corresponding to the structure string.

[0043] In this step, the structure string generated in the previous step, which is concatenated from the syntax category and lexical unit type in a depth-first traversal order, is used as input. A deterministic, collision-resistant cryptographic hash algorithm (such as SHA-256) is used for one-way operation, outputting a unique hash value of fixed length. This process does not rely on any external parameters or random factors, ensuring that the hash results of the same structure string are completely consistent at any time and under any environment. The hash value serves as the "structural fingerprint" of the SQL statement, with a fixed length (e.g., SHA-256 generates a 64-bit hexadecimal string), possessing uniqueness, irreversibility, and tamper-resistance. This hash value does not contain any semantic information of the original SQL; it only represents the abstract form of its syntactic structure and is used for subsequent fast, efficient, and low-overhead accurate comparison with a pre-defined whitelist of legitimate SQL structures. Through this mechanism, the system can complete the structural similarity judgment of massive amounts of SQL statements within milliseconds, enabling rapid release of known compliant patterns and immediate interception of structurally abnormal statements, greatly improving detection efficiency and system throughput, while providing a technical foundation for building a scalable and reusable SQL fingerprint database.

[0044] Step S210: Compare the hash value with the preset SQL structure feature set to obtain the comparison result.

[0045] In this step, the hash value is compared with a preset set of SQL structure features to obtain the comparison result. This means that the system precisely matches the structure hash value calculated in the previous step with a locally maintained whitelist set of structure features constructed from historically valid SQL statements. This whitelist set consists of structure hash values ​​of SQL statements that have been manually reviewed or verified by the system over a long period of time as safe, standardized, and high-performance. It covers common and risk-free syntax structure patterns in various stages of development, testing, and operation and maintenance, such as standard queries, filtering with index conditions, and simple operations with parameterized binding. The comparison process is a pure numerical matching process, without semantic parsing or rule matching. It can be completed solely by judging the equality of hash values, resulting in extremely low computational overhead and a response time within milliseconds. If the current hash value exists in the whitelist, the comparison result is "passed," indicating that the syntax structure of the SQL statement belongs to a known security mode, and it can proceed to the next stage of semantic rule detection. If the hash value is not in the whitelist, the comparison result is "failed," and the system immediately determines that the SQL statement has a structural abnormality, which may contain unknown attack modes, illegal syntax structures, or high-risk writing. It directly triggers a high-risk alarm or performs blocking operations and skips subsequent semantic analysis to reduce the risk of false positives and improve detection efficiency.

[0046] Step S212: If the comparison result is successful, based on the preset semantic detection rules, traverse the syntax analysis tree, identify anomalies in the SQL statement text, and obtain anomaly detection results. The comparison result is characterized by including hash values ​​in the SQL structure feature set.

[0047] In this step, if the comparison result is satisfactory, it indicates that the syntax structure of the SQL statement already exists in the preset legal structure whitelist. That is, its basic structural form is a compliant mode known and recognized by the system, without obvious high-risk characteristics such as format obfuscation, structural tampering, or abnormal nesting. Only at this point will the anomaly detection process be initiated.

[0048] Based on a pre-defined semantic detection rule base, the original parsing tree is traversed again. However, this traversal no longer ignores semantic content; instead, it selectively visits node paths related to rule matching and performs semantic judgment based on the specific lexical values ​​carried by the nodes (such as field names, table names, operators, constant values, etc.). The semantic detection rule base contains multiple types of fine-grained rules, such as:

[0049] Performance-related rules: Check whether the WHERE clause uses a function on an indexed field (e.g., WHERE UPPER(name)='ABC'), whether a full table scan occurs (no valid index condition), and whether a SELECT statement is used. Check if the number of elements in the IN list exceeds the threshold, if there are multiple nested subqueries (more than three levels), and if any related fields are missing in the JOIN condition.

[0050] Security rules: Detect whether the query contains high-risk statements (such as DROP TABLE, EXEC, LOAD DATA), whether it accesses system metadata tables (such as information_schema, sysobjects), whether it uses dynamically concatenated table names or field names, and whether there are still traces of string concatenation in parameterized queries, etc.

[0051] Resource abuse rules: Detect large result set queries that lack a LIMIT clause, repeatedly execute the same query, initiate database requests within a loop, or use ORDER BY on an unindexed field, resulting in a full sort, etc.

[0052] While traversing the syntax tree, the system matches paths according to the defined patterns (e.g., "a function call node exists under the WHERE child node, and its first child node is an identifier") to accurately locate illegal structures and record the triggering status of each matching rule. Each rule is associated with a preset risk weight. The system performs a weighted calculation based on the number and weight of the triggered rules to generate a comprehensive risk score, and classifies the risk level (e.g., low, medium, high) accordingly. Finally, it outputs a structured anomaly detection result that includes the anomaly type, specific trigger location, corresponding rule number, risk level, and optimization suggestions.

[0053] While ensuring structural compliance, the system precisely focuses on real risks at the semantic level, avoiding ineffective analysis of massive amounts of unstructured abnormal statements and significantly reducing computational overhead and false alarm rate. Furthermore, since semantic detection is triggered only after the structure whitelist is approved, a layered defense mechanism of "filter first, then analyze" is implemented, making the overall detection process both efficient and accurate. Ultimately, this achieves a comprehensive, proactive, and highly controllable identification capability against risks such as SQL injection, performance degradation, and unauthorized operations.

[0054] As an optional embodiment, based on preset SQL language rules, the SQL statement text is analyzed to determine a syntax parse tree, including: performing word segmentation on the SQL statement text based on preset SQL language rules to obtain multiple lexical units, wherein the lexical units include at least one of the following: keywords, identifiers, constants, operators, parameter placeholders, and comments; inputting the multiple lexical units into a preset SQL syntax analyzer to output the syntax parsing corresponding to the SQL statement text, wherein the syntax parsing includes syntax categories; and generating a syntax parse tree based on the multiple lexical units and the syntax parsing.

[0055] Optionally, a lexer can be invoked first to scan and segment the input SQL statement text character by character according to preset SQL language lexical rules, breaking the original text into a series of indivisible smallest syntactic units, i.e., lexical units. These lexical units include, but are not limited to: keywords (such as SELECT, FROM, WHERE, JOIN, ORDER BY, LIMIT, etc.), identifiers (such as user-defined names like table names, field names, aliases, etc.), constants (including integers, floating-point numbers, Boolean values, date and time literals, etc.), operators (such as =, <>, >, <, +, -, / , LIKE, IN, AND, OR, etc.), parameter placeholders (such as "?", "$1", ":param", etc., used for precompiled statements), and comments (including single-line comments and multi-line comments). During the segmentation process, the system automatically ignores irrelevant whitespace characters (spaces, tabs, newlines), but retains the semantics of the comments for subsequent analysis to determine whether they constitute malicious interference.

[0056] Subsequently, the aforementioned lexical unit sequence is input into a pre-defined SQL parser, which is built based on ANTLR or a similar compiler generation tool. The parser, based on a context-free grammar, performs syntactic structure identification and reduction on the lexical unit sequence, outputting the syntactic parsing result of the SQL statement. This result explicitly identifies the syntactic category of each substructure in the statement, such as "SELECT_STATEMENT", "PROJECTION_LIST", "FROM_CLAUSE", "WHERE_CLAUSE", "JOIN_CLAUSE", "SUBQUERY", "AGGREGATION_FUNCTION", and "ORDER_BY_CLAUSE", forming a logical mapping at the syntactic level.

[0057] Finally, based on the lexical unit sequence and the syntax parsing results, a structured parsing tree is constructed. The root node of this parsing tree represents the highest-level syntax category (e.g., SELECT_STATEMENT), internal nodes represent intermediate syntax structures (e.g., WHERE_CLAUSE, JOIN_CLAUSE), and leaf nodes correspond one-to-one with each token in the original lexical unit. The parent-child relationships between nodes strictly follow the nested structure of syntax rules, accurately reflecting the syntactic hierarchy and logical dependencies of the SQL statement. This parsing tree fully preserves the structural semantics of the statement, providing a precise tree-like data structure foundation for subsequent structural feature extraction, hash fingerprint generation, and semantic rule matching. It is the core data carrier for realizing the "structure-independent, semantically analyzable" detection capability of this invention.

[0058] As an optional implementation, a structural string is obtained by performing a depth-first traversal of the parsing tree and extracting structural features. This includes: sequentially identifying the category names corresponding to nodes in the parsing tree in a depth-first order from the root node to the leaf node, and removing the semantic content of the nodes to obtain a new parsing tree. The category names corresponding to the nodes include the grammar category name corresponding to the first node and the lexical unit type corresponding to the second node. The nodes in the new parsing tree are then concatenated into a string in a depth-first order to obtain the structural string.

[0059] Optionally, starting from the root node of the parsing tree, each node is recursively visited level by level in a depth-first traversal order. During the traversal, the system identifies the type of each node: if the node is an internal node, it corresponds to a grammar category, such as "SELECT_STATEMENT", "WHERE_CLAUSE", "JOIN_CLAUSE", "SUBQUERY", "AGGREGATE_FUNCTION", etc., and the system extracts the grammar category name of the node; if the node is a leaf node, it corresponds to a specific lexical unit, and the system extracts its lexical unit type, such as "IDENTIFIER", "NUMBER", "STRING_LITERAL", "PARAMETER", "OPERATOR", "KEYWORD", etc. During the extraction process, all semantic content can be completely removed, including table names, field names, numeric constants, string literals, parameter binding values, comment content, capitalization, spaces and newlines, and other information unrelated to the grammatical structure, retaining only the category name or lexical type identifier, thus forming a simplified parsing tree containing only structural semantics and no semantic content. Subsequently, the system sequentially concatenates the extracted syntax category names and lexical unit types of all nodes in the simplified parsing tree using a depth-first traversal, using a uniform delimiter (such as "|"), to form a continuous string consisting only of structural identifiers. This string is the structure string of the SQL statement. This structure string does not depend on the original SQL's writing format, naming conventions, or value content; it only reflects the topological form of its syntactic structure, thus achieving a structure-normalized expression for semantically equivalent but formally diverse SQL statements.

[0060] As an optional implementation, if the comparison result is unsuccessful, an alarm event is generated based on the SQL statement text; the alarm event is then sent back to the target account.

[0061] Optionally, if the comparison fails, the system determines that the structural fingerprint of the current SQL statement does not match any record in the preset legal SQL structure whitelist, indicating that the statement may have structural anomalies, potential injection attacks, unauthorized patterns, or inefficient writing risks. At this point, the system automatically triggers an alarm generation mechanism: based on the original SQL statement text, its corresponding syntax tree, the extracted structural string, the generated hash value, and the information of the whitelist entries that failed the comparison, a structured alarm event is constructed. This alarm event includes, but is not limited to, the following elements: the full text of the SQL statement, the statement source (such as application module, operation and maintenance terminal, visual editor ID), execution timestamp, user identity or caller identifier, structure hash value, anomaly type marker (such as "unknown structure," "high-risk pattern," "suspected injection," "non-compliant writing"), relevant syntax tree path fragments, and an explanation of the reason for the rule matching failure.

[0062] After being graded and evaluated by the system's internal policy engine, generated alarm events are automatically pushed to target accounts via a secure messaging channel according to preset alarm response policies. Target accounts include, but are not limited to, application security administrators, database operations and maintenance personnel, and the platform monitoring system. Push methods support multi-channel notifications, including SMS, email, automatically created events via the ticket system, or API callbacks to the operations and maintenance platform. The alarm information includes a clickable "Semantic Analysis Details" link, allowing security personnel to visually view the original SQL, syntax tree structure, structural string comparison differences, and suggested remediation solutions in the front-end interface, ensuring that alarms are traceable, analyzable, and manageable. This mechanism achieves proactive interception and closed-loop response to non-whitelisted SQL statements, significantly improving the timeliness of SQL security risk detection and the efficiency of collaborative handling, forming a complete protection chain of "detection—alarm—response—auditing."

[0063] As an optional implementation, the audit results of the target account based on the alarm event feedback are received; if the audit result shows that the SQL statement text is normal, the structure string and hash value are added to the SQL structure feature set.

[0064] Optionally, receive the audit results from the target account based on the alarm event feedback; if the audit result is "SQL statement text is normal", add the structure string and hash value corresponding to the SQL statement to the preset SQL structure feature set, specifically including the following operation process:

[0065] The system receives manual review feedback on alert events from target accounts (such as database administrators, security operations personnel, or application owners) through security audit interfaces or operations and maintenance confirmation platforms. Review feedback is submitted in structured data format, including the alert event ID, reviewer identifier, review timestamp, and a clear review conclusion (e.g., "confirmed as normal business statement," "false alarm," "allowed to whitelist," etc.). When the review conclusion is clearly "the SQL statement text is normal," the system automatically verifies the integrity and consistency of the SQL statement's structure string and hash value, ensuring it has not been tampered with and is consistent with the original analysis results. After successful verification, the system treats the structure string and its corresponding hash value as a new valid structure fingerprint record and writes it to a centralized SQL structure feature set (i.e., the whitelist database) in an append-only, non-overwrite manner. This set is implemented based on a high-performance key-value store (such as Redis Cluster or a distributed database), supporting high-concurrency reads and atomic writes to ensure data consistency in a multi-node environment.

[0066] To ensure the manageability and traceability of the whitelist database, metadata can be automatically associated with each new record, including: the original SQL statement (stored after anonymization), generation timestamp, reviewer's identity, application / system / environment identifier (e.g., "User Center Service - Production Environment"), and review basis remarks (e.g., "For historical report queries, stable structure, no injection risk"). New records will participate in the structural fingerprint comparison process for all subsequent SQL statements, ensuring that legitimate SQL statements with the same structure will no longer trigger false positives in the future. This mechanism achieves a closed-loop optimization capability, learning from false positives and evolving from human experience. This enables the system to have continuous adaptive and self-improving security detection capabilities, significantly reducing the false positive rate, improving operational efficiency and detection accuracy, and providing core support for building a dynamically evolving SQL security protection system.

[0067] As an optional embodiment, when the semantic detection rules include multiple rules, based on the preset semantic detection rules, the syntax analysis tree is traversed to identify anomalies in the SQL statement text and obtain anomaly detection results, including: obtaining the risk weight values ​​corresponding to each of the multiple rules; traversing multiple nodes in the syntax analysis tree, selecting the corresponding rule from the multiple rules for detection based on the type of the node, and obtaining the detection results corresponding to each of the multiple nodes; determining the target risk value corresponding to each of the multiple nodes based on the detection results corresponding to each of the multiple nodes and the risk weight values ​​corresponding to each of the multiple rules; and determining the anomaly detection results based on the target risk values ​​corresponding to each of the multiple nodes.

[0068] Optionally, a corresponding risk weight value can be set for each rule. For each node, a suitable detection rule is first selected based on the node's type and the detection is performed to determine the node's anomaly type. After traversing all nodes, the detection results for each node can be obtained. Then, the target risk value for each node is calculated. Based on the target risk value, the degree of anomaly of the SQL statement text can be determined. Specifically, first, the basic risk weight value associated with the semantic detection rule matching the current node type is obtained; second, the basic risk weight value is adjusted by a correction coefficient based on the node's structural position in the parsing tree and its context (such as whether it is located deep within a subquery nest, whether it involves sensitive data fields, etc.) to reflect its potential harm in the overall SQL execution logic; finally, the corrected risk weight value is used as the target risk value for the node. If the detection result shows that the node has high-risk anomaly characteristics, the preset highest risk threshold is directly assigned as the target risk value; if the detection result shows no anomaly or only a low-risk warning, the corresponding risk value is proportionally calculated based on the severity level of the anomaly type.

[0069] Figure 4 This is a schematic diagram of an SQL statement anomaly detection method provided by an optional embodiment of the present invention, such as... Figure 4 As shown, it includes:

[0070] For database systems that do not support SQL firewalls, direct access to the database via traditional interactive interfaces such as command line, JDBC, and ODBC is prohibited, and all database operations are forced to be initiated through a unified operations and maintenance platform. An SQL syntax analysis and semantic detection plugin is integrated into the operations and maintenance platform to perform structured analysis and risk identification on every SQL statement submitted through the platform. For database systems that support SQL firewalls, an SQL syntax analysis and semantic detection plugin is deployed at the request interception layer of the SQL firewall, embedding detection capabilities into the firewall's execution chain. For low-code visual SQL generation scenarios for business users, the front-end SQL generation logic is optimized, generating statement structures based on security template constraints to avoid performance degradation or high-risk syntax. After the final SQL statement is generated on the low-code platform, the SQL syntax analysis and semantic detection plugin is invoked to extract structural fingerprints and verify compliance of the generated statement; statements that fail the checks are rejected and an exception is displayed.

[0071] The above steps solve the problem that traditional regular expression matching methods cannot handle complex statement structures. The detection process is adaptable to various scenarios. Based on the constructed syntax analysis tree, it performs whitelist matching and anomaly detection, and also improves the security of SQL execution.

[0072] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0073] Through the above description of the embodiments, those skilled in the art can clearly understand that the SQL statement anomaly detection method according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0074] According to embodiments of the present invention, an SQL statement anomaly detection apparatus for implementing the above-described SQL statement anomaly detection method is also provided. Figure 5 This is a structural block diagram of the SQL statement anomaly detection device provided according to an embodiment of the present invention, such as... Figure 5 As shown, the SQL statement anomaly detection device includes: a receiving module 502, an analysis module 504, an extraction module 506, a calculation module 508, a comparison module 510, and an identification module 512. The SQL statement anomaly detection device will be described below.

[0075] The receiving module 502 is used to receive the SQL statement text to be detected.

[0076] Analysis module 504 is used to analyze SQL statement text based on preset SQL language rules and determine a syntax analysis tree, wherein the syntax analysis tree includes a first node representing the syntax category and a second node representing the lexical unit.

[0077] Extraction module 506 is used to extract structural features and obtain structural strings by performing a depth-first traversal of the parsing tree.

[0078] The calculation module 508 is used to calculate the hash value corresponding to the structure string.

[0079] The comparison module 510 is used to compare the hash value with a preset set of SQL structure features to obtain the comparison result.

[0080] The identification module 512 is used to identify anomalies in the SQL statement text by traversing the syntax analysis tree based on preset semantic detection rules when the comparison result is passed, and to obtain anomaly detection results. The comparison result is characterized by including hash values ​​in the SQL structure feature set.

[0081] It should be noted that the receiving module 502, analysis module 504, extraction module 506, calculation module 508, comparison module 510, and identification module 512 mentioned above correspond to steps S202 to S212 in the embodiments. Multiple modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should also be noted that the above modules, as part of the device, can run in the computer terminal 10 provided in the embodiments.

[0082] Embodiments of the present invention may provide a computer device. Optionally, in this embodiment, the computer device may be located in at least one of a plurality of network devices in a computer network. The computer device includes a memory and a processor.

[0083] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the SQL statement anomaly detection method and apparatus in this embodiment of the invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the aforementioned SQL statement anomaly detection method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0084] The processor can access information and applications stored in memory via a transmission device to perform the following steps: receiving the SQL statement text to be detected; analyzing the SQL statement text based on preset SQL language rules to determine a syntax tree, wherein the syntax tree includes a first node representing the syntax category and a second node representing the lexical unit; extracting structural features by performing a depth-first traversal of the syntax tree to obtain a structure string; calculating the hash value corresponding to the structure string; comparing the hash value with a preset SQL structure feature set to obtain a comparison result; if the comparison result is successful, traversing the syntax tree based on preset semantic detection rules to identify anomalies in the SQL statement text and obtain an anomaly detection result, wherein the comparison result is indicated by the presence of a hash value in the SQL structure feature set.

[0085] Optionally, the processor may also execute program code that performs the following steps: Analyzing SQL statement text based on preset SQL language rules to determine a syntax tree, including: performing word segmentation on the SQL statement text based on preset SQL language rules to obtain multiple lexical units, wherein the lexical units include at least one of the following: keywords, identifiers, constants, operators, parameter placeholders, and comments; inputting the multiple lexical units into a preset SQL syntax analyzer and outputting the syntax parsing corresponding to the SQL statement text, wherein the syntax parsing includes syntax categories; and generating a syntax tree based on the multiple lexical units and the syntax parsing.

[0086] Optionally, the processor may also execute program code with the following steps: extracting structural features by performing a depth-first traversal of the parsing tree to obtain a structural string, including: sequentially identifying the category names corresponding to nodes in the parsing tree in a depth-first order from the root node to the leaf node, and removing the semantic content in the nodes to obtain a new parsing tree, wherein the category names corresponding to the nodes include the grammar category name corresponding to the first node and the lexical unit type corresponding to the second node; concatenating the nodes in the new parsing tree into a string in a depth-first order to obtain a structural string.

[0087] Optionally, the processor may also execute program code that performs the following steps: if the comparison result is unsuccessful, generate an alarm event based on the SQL statement text; and send the alarm event back to the target account.

[0088] Optionally, the processor may also execute program code that performs the following steps: receiving the audit results from the target account based on the alarm event feedback; and adding the structure string and hash value to the SQL structure feature set if the audit result indicates that the SQL statement text is normal.

[0089] Optionally, the processor may also execute program code with the following steps: when the semantic detection rules include multiple rules, based on the preset semantic detection rules, traverse the syntax analysis tree, identify anomalies in the SQL statement text, and obtain anomaly detection results, including: obtaining the risk weight values ​​corresponding to each of the multiple rules; traversing multiple nodes in the syntax analysis tree, selecting the corresponding rule from the multiple rules for detection based on the type of the node, and obtaining the detection results corresponding to each of the multiple nodes; determining the target risk value corresponding to each of the multiple nodes based on the detection results corresponding to each of the multiple nodes and the risk weight values ​​corresponding to each of the multiple rules; and determining the anomaly detection results based on the target risk values ​​corresponding to each of the multiple nodes.

[0090] This invention provides a method for detecting SQL statement anomalies. The method involves receiving the SQL statement text to be detected; analyzing the SQL statement text based on preset SQL language rules to determine a syntax analysis tree, wherein the syntax analysis tree includes a first node representing the grammatical category and a second node representing the lexical unit; extracting structural features by performing a depth-first traversal of the syntax analysis tree to obtain a structure string; calculating the hash value corresponding to the structure string; comparing the hash value with a preset set of SQL structural features to obtain a comparison result; if the comparison result is successful, traversing the syntax analysis tree based on preset semantic detection rules to identify anomalies in the SQL statement text, thus obtaining an anomaly detection result. This method achieves the goal of separating and independently detecting the grammatical structure and semantic content of SQL statements, thereby improving the accuracy and security of SQL statement anomaly detection. It also solves the technical problems of current SQL statement anomaly detection methods, such as low accuracy of direct detection through regular expression matching when the statements are complex, and difficulty in detecting anomalies or variant statements when there are many statements.

[0091] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a non-volatile storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0092] Embodiments of the present invention also provide a non-volatile storage medium. Optionally, in this embodiment, the aforementioned non-volatile storage medium can be used to store the program code executed by the SQL statement anomaly detection method provided in the above embodiments.

[0093] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0094] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: receiving the SQL statement text to be detected; analyzing the SQL statement text based on preset SQL language rules to determine a syntax analysis tree, wherein the syntax analysis tree includes a first node representing a syntax category and a second node representing a lexical unit; extracting structural features by performing a depth-first traversal of the syntax analysis tree to obtain a structure string; calculating the hash value corresponding to the structure string; comparing the hash value with a preset SQL structure feature set to obtain a comparison result; if the comparison result is successful, traversing the syntax analysis tree based on preset semantic detection rules to identify anomalies in the SQL statement text and obtain an anomaly detection result, wherein the comparison result is obtained by representing that the SQL structure feature set includes a hash value.

[0095] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: analyzing SQL statement text based on preset SQL language rules to determine a syntax analysis tree, including: performing word segmentation on the SQL statement text based on preset SQL language rules to obtain multiple lexical units, wherein the lexical units include at least one of the following: keywords, identifiers, constants, operators, parameter placeholders, and comments; inputting the multiple lexical units into a preset SQL syntax analyzer to output the syntax parsing corresponding to the SQL statement text, wherein the syntax parsing includes syntax categories; and generating a syntax analysis tree based on the multiple lexical units and the syntax parsing.

[0096] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: extracting structural features by performing a depth-first traversal of the parsing tree to obtain a structural string, including: sequentially identifying the category names corresponding to nodes in the parsing tree in a depth-first order from the root node to the leaf node, and removing the semantic content in the nodes to obtain a new parsing tree, wherein the category names corresponding to the nodes include the grammar category name corresponding to the first node and the lexical unit type corresponding to the second node; concatenating the nodes in the new parsing tree into a string in a depth-first order to obtain a structural string.

[0097] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: generating an alarm event based on the SQL statement text if the comparison result is unsuccessful; and sending the alarm event back to the target account.

[0098] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: receiving the audit result from the target account based on the alarm event feedback; and adding the structure string and hash value to the SQL structure feature set if the audit result indicates that the SQL statement text is normal.

[0099] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: when the semantic detection rules include multiple rules, based on the preset semantic detection rules, traversing the syntax analysis tree, identifying anomalies in the SQL statement text, and obtaining anomaly detection results, including: obtaining the risk weight values ​​corresponding to each of the multiple rules; traversing multiple nodes in the syntax analysis tree, selecting the corresponding rule from the multiple rules for detection based on the type corresponding to the node, and obtaining the detection results corresponding to each of the multiple nodes; determining the target risk value corresponding to each of the multiple nodes based on the detection results corresponding to each of the multiple nodes and the risk weight values ​​corresponding to each of the multiple rules; and determining the anomaly detection results based on the target risk values ​​corresponding to each of the multiple nodes.

[0100] Embodiments of the present invention also provide a computer program product, including a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it can: receive SQL statement text to be detected; analyze the SQL statement text based on preset SQL language rules to determine a syntax analysis tree, wherein the syntax analysis tree includes a first node representing a syntax category and a second node representing a lexical unit; extract structural features by performing a depth-first traversal of the syntax analysis tree to obtain a structure string; calculate the hash value corresponding to the structure string; compare the hash value with a preset SQL structure feature set to obtain a comparison result; if the comparison result is successful, traverse the syntax analysis tree based on preset semantic detection rules to identify anomalies in the SQL statement text and obtain an anomaly detection result, wherein the comparison result is indicated by the presence of a hash value in the SQL structure feature set.

[0101] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0102] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0103] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0104] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0105] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0106] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0107] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for detecting SQL statement anomalies, characterized in that, include: Receive the text of the SQL statement to be tested; Based on preset SQL language rules, the SQL statement text is analyzed to determine a syntax analysis tree, wherein the syntax analysis tree includes a first node representing the syntax category and a second node representing the lexical unit; By performing a depth-first traversal of the parse tree, structural features are extracted to obtain the structural string; Calculate the hash value corresponding to the structure string; The hash value is compared with a preset set of SQL structure features to obtain the comparison result; If the comparison result is successful, based on the preset semantic detection rules, the syntax analysis tree is traversed to identify anomalies in the SQL statement text and obtain an anomaly detection result. The comparison result is characterized by the inclusion of the hash value in the SQL structural feature set.

2. The method according to claim 1, characterized in that, The process of analyzing the SQL statement text based on preset SQL language rules to determine the syntax tree includes: Based on preset SQL language rules, the SQL statement text is segmented to obtain multiple lexical units, wherein the lexical units include at least one of the following: keywords, identifiers, constants, operators, parameter placeholders, and comments; The plurality of lexical units are input into a preset SQL syntax analyzer, which outputs the syntax parsing corresponding to the SQL statement text, wherein the syntax parsing includes syntax categories; The syntax analysis tree is generated based on the multiple lexical units and the syntax parsing.

3. The method according to claim 1, characterized in that, The process of extracting structural features by performing a depth-first traversal of the parsing tree to obtain a structural string includes: Following a depth-first order from the root node to the leaf node, the category names corresponding to the nodes in the parsing tree are identified sequentially, and the semantic content in the nodes is removed to obtain a new parsing tree. The category names corresponding to the nodes include the grammar category name corresponding to the first node and the lexical unit type corresponding to the second node. The nodes in the new parsing tree are concatenated into a string according to the depth-first order to obtain the structure string.

4. The method according to claim 1, characterized in that, Also includes: If the comparison result is unsuccessful, an alarm event is generated based on the SQL statement text; The alarm event will be reported to the target account.

5. The method according to claim 4, characterized in that, Also includes: Receive the audit results from the target account based on the alarm event; If the audit result indicates that the SQL statement text is normal, the structure string and the hash value are added to the SQL structure feature set.

6. The method according to any one of claims 1 to 5, characterized in that, When the semantic detection rules include multiple rules, the step of traversing the syntax analysis tree based on the preset semantic detection rules to identify anomalies in the SQL statement text and obtain anomaly detection results includes: Obtain the risk weight value corresponding to each of the multiple rules; Traverse multiple nodes in the parsing tree, select the corresponding rule from the multiple rules based on the type of the node, and obtain the detection result corresponding to each of the multiple nodes; Based on the detection results corresponding to each of the multiple nodes and the risk weight values ​​corresponding to each of the multiple rules, the target risk value corresponding to each of the multiple nodes is determined. The anomaly detection result is determined based on the target risk value corresponding to each of the multiple nodes.

7. An SQL statement anomaly detection device, characterized in that, include: The receiving module is used to receive the text of the SQL statement to be detected; The analysis module is used to analyze the SQL statement text based on preset SQL language rules and determine the syntax analysis tree, wherein the syntax analysis tree includes a first node representing the syntax category and a second node representing the lexical unit; The extraction module is used to extract structural features by performing a depth-first traversal of the parsing tree to obtain a structural string; The calculation module is used to calculate the hash value corresponding to the structure string; The comparison module is used to compare the hash value with a preset set of SQL structure features to obtain the comparison result; The identification module is used to identify anomalies in the SQL statement text based on preset semantic detection rules when the comparison result is passed, and to obtain an anomaly detection result, wherein the comparison result is characterized by the inclusion of the hash value in the SQL structural feature set.

8. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, it controls the device where the non-volatile storage medium is located to execute the SQL statement anomaly detection method according to any one of claims 1 to 6.

9. A computer device, characterized in that, include: Memory and processor The memory stores computer programs; The processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, the processor performs the SQL statement anomaly detection method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the SQL statement anomaly detection method according to any one of claims 1 to 6.

Images