SQL (Structured Query Language) risk check method and device based on semantic analysis

Abstract

The invention relates to the technical field of database security, and discloses a semantic analysis-based SQL (Structured Query Language) risk check method and device, and the method comprises the following steps: analyzing based on an input SQL statement to obtain a standardized SQL statement; constructing an abstract syntax tree according to the standardized SQL statement; extracting key semantic information according to the abstract syntax tree; obtaining a risk assessment result according to the key semantic information; and recording an audit log according to the risk assessment result. Compared with the technical problem that a traditional auditing system mainly depends on pattern matching of basic rules, and potential safety risks cannot be accurately recognized when complex SQL statements are processed, especially under the condition that multi-layer nesting and dynamic construction are included, due to the fact that the efficient semantic analysis technology and the risk assessment algorithm are combined for use, the safety risk assessment method and device have the advantages that the safety risk assessment efficiency is improved, and the safety risk assessment efficiency is improved. Therefore, the occurrence of security events is effectively avoided, the accuracy and efficiency of SQL risk check are improved, and then the security of the database is ensured.

Description

Technical Field

[0001] The present invention relates to the field of database security technology, and in particular to a SQL risk checking method, device, equipment and computer program product based on semantic analysis. Background Art

[0002] At present, the SQL risk inspection mechanism relies more on traditional audit tools and database logs, and security audits are usually implemented by collecting and analyzing the data provided by these tools and logs. Although this audit logic meets basic security requirements, it is insufficient in terms of real-time and accuracy when dealing with complex and carefully designed SQL injection or data leakage attacks. For example, when it is necessary to accurately locate and monitor a specific database or sensitive data in real time, the existing technology cannot fully meet such high-precision and real-time requirements. In addition, the SQL risk inspection system of the prior art mainly relies on traditional pattern matching and rule inspection methods to identify potential security threats, and lacks the application of combining advanced semantic analysis technology with security rule design and risk assessment algorithms. However, when the structure of the target SQL statement is complex or contains dynamically generated queries, this audit method that relies on traditional methods will lead to the inability to guarantee the security risk identification effect, thereby affecting the timeliness and accuracy of the audit. Therefore, there is an urgent need for a method that can still achieve high-precision and real-time SQL risk inspection when the structure of the target SQL statement is complex or contains dynamically generated queries, so as to ensure the security of the database. Summary of the invention

[0003] In view of the above-mentioned technical deficiencies, the main purpose of the present invention is to provide a SQL risk checking method, apparatus, device and computer program product based on semantic analysis, aiming to solve the technical problem that the prior art mainly relies on pattern matching based on basic rules and cannot accurately identify potential security risks when processing complex SQL statements, especially those containing multiple layers of nesting and dynamic construction.

[0004] In order to solve the above technical problems, the present invention adopts the following technical solutions: The present invention provides a SQL risk checking method based on semantic analysis.

[0005] Preferably, the method comprises:

[0006] Remove interference information from the input SQL statement, and standardize the SQL statement after removing the interference information to obtain a standardized SQL statement;

[0007] Decompose the standardized SQL statement to obtain a Token sequence, and perform syntax parsing according to the Token sequence to obtain an abstract syntax tree;

[0008] Extracting core elements from the abstract syntax tree to construct a semantic vector, and obtaining key semantic information according to the semantic vector;

[0009] After obtaining the risk assessment result based on the key semantic information, the audit log is recorded.

[0010] Preferably, in step S40, the step of obtaining risk assessment results from key semantic information and recording audit logs includes:

[0011] Based on key semantic information, the preset database operation mode is processed to generate intermediate data;

[0012] Perform weighted analysis on the intermediate data and calculate the probability of risk events, and generate a risk assessment report based on the calculation results of the probability of risk events.

[0013] Preferably, in step S40, the step of recording an audit log after the key semantic information obtains the risk assessment result further includes:

[0014] Classify risk events based on risk assessment results;

[0015] Define log levels based on categorized risk events and generate audit logs based on the defined log levels.

[0016] Preferably, after step S40, the method further includes:

[0017] Performing real-time interception based on the risk assessment results;

[0018] The audit log is updated according to the real-time interception results of the execution.

[0019] Preferably, the interference information in step S10 includes annotation content, blank characters, special characters and non-semantically related symbols.

[0020] Preferably, according to the SQL risk checking method based on semantic analysis according to claim 1, it is characterized in that the interference information in step S10 includes comment content, blank characters, special characters and non-semantically related symbols.

[0021] Preferably, the core elements in step S30 include: table name, field name, operation type and conditional statement.

[0022] Preferably, the SQL risk checking device based on semantic analysis includes:

[0023] The interference information removal and standardization module is used to remove interference information from the input SQL statement, and standardize the SQL statement after the interference information is removed to obtain a standardized SQL statement;

[0024] The Token decomposition and syntax parsing module is used to decompose the standardized SQL statement to obtain a Token sequence, and perform syntax parsing according to the Token sequence to obtain an abstract syntax tree;

[0025] A semantic vector construction module, used to extract core elements from the abstract syntax tree and then construct a semantic vector, and obtain key semantic information according to the semantic vector;

[0026] The risk assessment and audit log recording module is used to extract core elements from the abstract syntax tree and then construct a semantic vector, and obtain key semantic information according to the semantic vector.

[0027] The beneficial effect of the present invention is that compared with the traditional audit system that mainly relies on pattern matching based on basic rules, when processing complex SQL statements, especially those containing multi-layer nesting and dynamic construction, the technical problem of being unable to accurately identify potential security risks, this application effectively avoids the occurrence of security incidents through the combination of efficient semantic analysis technology, security rule design and risk assessment algorithm, thereby improving the accuracy and efficiency of SQL risk checks, thereby ensuring the security of the database. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0029] Figure 1 It is a flowchart of the first embodiment of the SQL risk checking method based on semantic analysis of the present invention. DETAILED DESCRIPTION

[0030] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0031] Embodiment 1: Figure 1 FIG. 1 is a flow chart of a first embodiment of a SQL risk checking method based on semantic analysis according to the present invention.

[0032] Step S10: removing interference information from the input SQL statement, and standardizing the SQL statement after the interference information is removed to obtain a standardized SQL statement;

[0033] It should be noted that SQL statements refer to query languages ​​used to define, operate, and control data in a database. They can be query statements (such as SELECT), update statements (such as UPDATE), or control statements (such as GRANT); standardized SQL statements refer to statements that have been cleaned and standardized. They can be statements with redundant spaces and comments removed, statements with keyword case converted, or reformatted statements to improve the accuracy and efficiency of subsequent parsing.

[0034] It is understandable that the standardization step is a crucial part of the SQL risk inspection process because it directly affects the quality of grammatical analysis and semantic parsing; standardization can generally include data cleaning and data standardization, and in order to better adapt to different SQL dialects and coding habits, the process of obtaining standardized SQL statements based on the input SQL statement analysis can be dynamically configured, for example, the standardization rules can be adjusted according to the database type (such as MySQL, Oracle); it can also be user-defined, for example, the user can specify specific standardization operations, such as ignoring certain specific SQL statements or keywords.

[0035] It should be understood that in order to better improve the efficiency and accuracy of standardization, the specific way to remove interference information can be to use regular expressions to match and remove SQL comments and non-functional blank characters. Taking the removal of SQL comments as an example, the formula is: ^\s*--.*$ (used to match line comments), where ^ represents the beginning of the line, \s* represents any number of blank characters, -- is the start mark of the SQL line comment, and .*$ represents any character after the comment until the end of the line. In addition, for block comments, the formula can be used: / \*[\s\S]*? \* / , where / \* and \* / represent the beginning and end of the block comment, respectively, and [\s\S] matches any character, including line breaks, until the first block comment end mark is encountered.

[0036] It should be understood that in order to better improve the consistency and accuracy of SQL statement processing, the specific steps of standardization processing can be:

[0037] (1) Remove comments: Use regular expressions to remove all types of comments from SQL statements, including single-line and multi-line comments.

[0038] (2) Remove unnecessary spaces: Delete unnecessary spaces and special characters in SQL statements, such as extra spaces, line breaks, and tabs, to keep the statements concise.

[0039] (3) Keyword capitalization: Convert all SQL keywords to uppercase to avoid errors caused by inconsistent uppercase and lowercase letters.

[0040] (4) Unified data formats: Unify the date, time, and numeric formats in SQL statements to ensure that the formats of all data types are consistent for easy processing and analysis.

[0041] (5) Replace synonyms: Replace synonyms and dialects in SQL statements with corresponding words in standard SQL syntax, such as replacing "delete" with "DELETE".

[0042] (6) Parameterized query: Convert hard-coded data values ​​in SQL statements into parameter form to enhance query security and reduce the risk of SQL injection.

[0043] (7) Normalized sorting and grouping: Normalize all sorting (ORDER BY) and grouping (GROUP BY) clauses to ensure that their order and format conform to predefined standards.

[0044] (8) Function and expression standardization: Standardize all functions and complex expressions used in SQL to ensure that they follow the same set of logic and format specifications.

[0045] The above is only a feasible implementation of step S10 provided in this embodiment, and this embodiment does not specifically limit the specific implementation of step S10. These methods are all intended to achieve the technical effect of enhancing the consistency and accuracy of SQL statement processing through different technical means, thereby achieving more effective security monitoring and data protection. Through these standardized processes, the system can more accurately identify and respond to potential security threats, while improving the processing efficiency of complex SQL queries and ensuring the stability and security of the database environment.

[0046] Step S20: Decompose the standardized SQL statement to obtain a Token sequence, and perform syntax analysis according to the Token sequence to obtain an abstract syntax tree;

[0047] It should be noted that the Abstract Syntax Tree (AST) is a tree-like data structure that is used to represent the grammatical structure of SQL statements. In this tree, each node represents a construction element in the SQL statement, such as a keyword, expression, function call, etc. The purpose of constructing the AST is to gain a deeper understanding of the semantic content of the SQL statement, so as to conduct more accurate security analysis and risk assessment.

[0048] It should be noted that the Token sequence refers to the decomposition of SQL statements into a series of basic units or symbols through the lexical analyzer. It can be keywords (such as SELECT, FROM, WHERE), operators (such as =, >, <), identifiers (such as table names and column names) or constants (such as numbers and strings).

[0049] It can be understood that the process of lexical analysis is to convert a continuous character stream into a symbol sequence with independent semantics, which lays the foundation for subsequent syntax parsing and ensures that the syntax parser can correctly understand and construct the structure of the SQL statement.

[0050] It should be understood that in order to better decompose SQL statements to adapt to complex query structures, the specific steps for decomposing to obtain a Token sequence can be: Tokens = lex(S), where lex is a lexical analysis function, S is an input standardized SQL statement, and Tokens is an output Token sequence; the specific steps for performing syntax parsing to obtain an abstract syntax tree can be: AST = parse(T), where parse is a syntax parsing function, T is an input Token sequence, and AST is an output abstract syntax tree.

[0051] It should be understood that in order to better support multiple SQL dialects and complex query structures, the process of building an abstract syntax tree requires the use of a highly flexible and configurable parser. For example, open source parsers such as ANTLR or custom parsers can be used, which can adjust the parsing strategy according to the grammatical rules of different database systems. In addition, the processing process will include an error recovery mechanism to ensure that even if a SQL statement with partial syntax errors is encountered, a valid AST can be built as much as possible.

[0052] The above are only feasible implementations of step S20 provided in this embodiment, and this embodiment does not specifically limit the specific implementation of step S20. These methods are all intended to analyze and deconstruct the components of SQL statements to more deeply understand their structure and intent, thereby achieving more effective security auditing and performance optimization.

[0053] Step S30: extracting core elements from the abstract syntax tree to construct a semantic vector, and obtaining key semantic information according to the semantic vector;

[0054] It should be noted that core elements refer to the main parts that constitute SQL statements, which can be table names, field names, operation types (such as SELECT, INSERT), and conditional expressions (such as conditions in the WHERE clause); semantic vectors refer to the conversion of these core elements into a numerical or symbolic representation, which can be a feature vector, an encoded sequence, or an input vector for pattern recognition and machine learning.

[0055] It can be understood that the process of extracting and transforming these core elements into semantic vectors is key to understanding the intent and structure of SQL statements, providing data support for further security analysis and risk assessment.

[0056] It should be noted that key semantic information covers important components of SQL statements, including but not limited to table names, column names, operation types (such as SELECT, INSERT, UPDATE, DELETE), conditional expressions, and join types. This information is essential for understanding the intent of SQL operations, conducting risk assessments, and implementing security policies. Extracting this information is done by parsing each node of the abstract syntax tree, each of which represents a specific grammatical structure in the SQL statement.

[0057] It can be understood that the extraction of key semantic information not only helps identify potential security risks, such as unauthorized data access or data tampering attempts, but also helps optimize audit strategies, such as automatically adjusting the focus and accuracy of the audit through the recognition of specific patterns.

[0058] It should be understood that in order to better extract information from the abstract syntax tree and convert it into a format that is easy to analyze, the specific steps of constructing a semantic vector based on the extracted core elements can be: V = vectorize(Elements), where vectorize is a function that converts the extracted core elements (ElementsElements) into a vector V, which may include feature hashing and one-hot encoding.

[0059] It should be understood that in order to better utilize these vectors for security and business logic analysis, the specific steps of obtaining key semantic information according to the constructed semantic vectors may be: Info = analyze (V), where analyze is an analysis function that uses machine learning or statistical methods to extract key semantic information Info from the semantic vector V;

[0060] For example, cluster analysis can be used to discover common query patterns. The specific implementation steps can be:

[0061] (1) First, extract features from the abstract syntax tree (AST) of each SQL statement. These features may include:

[0062] Operation type (such as SELECT, UPDATE, DELETE)

[0063] Number and type of tables

[0064] The type and number of columns and conditional expressions used

[0065] Use of literals and variables

[0066] (2) Feature vectorization

[0067] Converting the extracted features into numerical vectors involves:

[0068] One-hot encode operation type and table type

[0069] Normalize the number of columns and conditional expressions

[0070] Count the frequency of literal values

[0071] (3) Initialize K-means algorithm

[0072] Select K random feature vectors as the initial cluster centers. The K value here needs to be determined based on the diversity of the data and audit requirements.

[0073] (4) Allocation and Update Cycle

[0074] Assignment: For each SQL feature vector, calculate its distance from all cluster centers and assign it to the nearest cluster center.

[0075]

[0076] Update: Update the center of each cluster to be the mean of all vectors in the cluster.

[0077]

[0078] (5) Anomaly Detection:

[0079] Use distance or density-based methods in anomaly detection technology to identify SQL queries that do not conform to regular patterns, which may indicate potential risks. Let v be the input feature vector and model be the trained machine learning model. The key information I can be obtained through the following formula: I = model(v), where model selects a specific algorithm based on the actual application scenario.

[0080] The above are only feasible implementations of step S30 provided in this embodiment, and this embodiment does not specifically limit the specific implementation of step S30. These methods are all aimed at extracting and analyzing the core elements of SQL statements, constructing semantic vectors, and using these vectors for in-depth risk assessment and pattern recognition, thereby achieving a comprehensive understanding of the intent and structure of SQL statements and improving the accuracy and efficiency of SQL risk checks.

[0081] Step S40: After obtaining the risk assessment result according to the key semantic information, an audit log is recorded;

[0082] It should be noted that the risk assessment results are determined by specific security rules or risk assessment models based on key semantic information extracted from SQL statements, such as data access mode, operation type, and database objects involved. These rules or models assess the security risks that SQL statements may bring, such as unauthorized access, data leakage, or potential SQL injection attacks.

[0083] It is understandable that risk assessment involves not only detecting possible illegal operations or attack attempts, but also the impact assessment on database operations, such as the potential impact of a certain SQL statement on database performance or the threat to data integrity. This comprehensive assessment helps the audit system provide more accurate security recommendations and response measures.

[0084] It should be noted that recording audit logs is a key component of the audit process, which involves not only formalizing risk assessment results into log entries, but also including the execution details of relevant SQL statements, timestamps, user information, and any relevant warning or error messages. These logs provide necessary documentation support for subsequent security analysis, compliance audits, and possible legal proceedings.

[0085] It is understandable that the detailed records of audit logs enable organizations to trace back and examine database activities at specific points in time or events, thereby responding promptly to any potential security incidents. In addition, these logs can also be used to generate security reports and conduct long-term security trend analysis to help improve existing security policies.

[0086] It should be understood that in order to better optimize the risk assessment process, it may be necessary to combine the current application scenario and the specific optimization algorithm. For example, in the database scenario of maintaining a large e-commerce platform, the platform contains multiple important database tables such as user information, order records, inventory management, etc. The security of the platform is of paramount importance. Any unauthorized access, data leakage or SQL injection attack may lead to serious consequences. The specific implementation steps can be:

[0087] 1. Feature extraction and vectorization

[0088] In this scenario, the system needs to analyze thousands of SQL statements every day. These SQL statements range from simple SELECT queries to complex multi-table JOIN and UPDATE operations. The following features can be extracted from these SQL statements:

[0089] Operation type: such as SELECT, INSERT, UPDATE, DELETE.

[0090] Table name: the table involved, such as Users, Orders, Inventory.

[0091] Conditional expressions: such as conditions in the WHERE clause, especially those involving sensitive information (such as user passwords and credit card information).

[0092] Access patterns: such as whether a large number of records were accessed, or whether attempts were made to modify data in batches.

[0093] These features are converted into feature vectors after one-hot encoding and standardization for use in subsequent risk assessment models.

[0094] 2. Model training and prediction

[0095] By analyzing historical data, a machine learning model, such as RandomForest, can be trained to identify characteristic patterns of SQL injection attacks. For example:

[0096] SQL injection risk: The system found a SQL statement that contained a dynamically concatenated SQL string and did not use parameterized queries. This pattern may indicate an attempt to perform a SQL injection attack, and the model will mark the statement as high risk.

[0097] Unauthorized data access: A common user launches a complex SQL query to access all records in the user information table instead of just his own data. The system can identify this abnormal behavior and mark it as high risk.

[0098] The model predicts these feature vectors to derive the risk level of each SQL statement.

[0099] 3. Risk assessment results and feedback

[0100] In actual operation, the system not only performs real-time evaluation based on the model's prediction results, but also combines the current database status. For example, if a SQL statement is executed when the database load is high, it may affect performance. The system can automatically adjust the evaluation threshold, mark such statements as medium risk, and recommend postponing execution.

[0101] 4. Audit log records

[0102] The system records all SQL statements and their evaluation results in the audit log. For example:

[0103] Timestamp: 2024-08-26 14:35:21

[0104] User information: User ID 12345

[0105] SQL statement: SELECT*FROM Users WHERE user_id='admin';

[0106] Risk level: High

[0107] Warning message: Potential SQL injection attack, query contains dynamically concatenated SQL string.

[0108] These logs can generate security reports regularly, and when a security incident occurs, administrators can quickly locate the root cause of the problem by querying the logs. For example, if the system discovers multiple abnormal query patterns one day, by backtracking the audit logs, the administrator can find the source of these queries and take necessary measures.

[0109] 5. Long-term trend analysis

[0110] By clustering the data in the audit log, the system can discover common query patterns and abnormal behaviors. For example, the system may identify certain high-frequency queries as normal business operations, while certain low-frequency and complex queries may indicate potential security threats. Through this trend analysis, the system can automatically adjust security policies and gradually improve the accuracy of risk detection.

[0111] In the second embodiment, the key semantic information in step S40 obtains risk assessment results and records audit logs, including:

[0112] Based on key semantic information, the preset database operation mode is processed to generate intermediate data;

[0113] Perform weighted analysis on the intermediate data and calculate the probability of risk events, and generate a risk assessment report based on the calculation results of the probability of risk events.

[0114] It should be noted that the preset database operation mode refers to a set of standard operation modes defined by the system based on the previous database operation history and security policies. These modes include normal operations and known risky operation modes, such as batch reading of user data, frequent modification of important table structures, etc. Key semantic information is extracted from SQL statements. This information, such as table name, operation type, conditional expression, etc., will be used as the basis for matching with the preset database operation mode. During the matching process, the system will identify whether the SQL statement matches a known operation mode, thereby generating intermediate data. The intermediate data may include the name of the matching operation mode, the database objects involved, the frequency and scope of the operation, etc.

[0115] It should be understood that the generated intermediate data provides a basis for subsequent risk assessment. By matching the pattern of SQL statements, the risk category of the operation can be preliminarily determined. If the intermediate data shows that the operation is highly matched with a known high-risk pattern, the system will focus on this operation in subsequent risk assessments.

[0116] It should be noted that weighted analysis is the process of assigning different weights to various risk factors in the intermediate data. For example, access to sensitive tables (such as user information tables) may have a higher weight, while frequent query operations may also be assigned a higher weight. The system calculates the risk event probability of each operation based on the sensitivity, operation frequency, historical data, etc. of different operations; the risk event probability is a numerical result of the system's assessment of the security issues that may be caused by a certain SQL operation. Based on this probability, the system can generate a risk assessment report more accurately. If the probability exceeds a certain threshold, the system may mark the operation as high risk and explain in detail the source of the risk and possible consequences in the report.

[0117] It should be understood that the generated risk assessment report includes not only the risk probability of the SQL statement, but also the context information of the operation, such as execution time, user identity, historical operation records, etc. This information provides administrators with a more comprehensive perspective to help them make accurate security decisions. In addition, these assessment results will be recorded in the audit log for use in future security analysis and trend prediction.

[0118] In the third embodiment, step S40 records the audit log after the key semantic information obtains the risk assessment result, and also includes:

[0119] Classify risk events based on risk assessment results;

[0120] Define log levels based on categorized risk events;

[0121] Generates audit logs according to the defined log level.

[0122] It should be noted that risk event classification may include low risk, medium risk and high risk events. This helps determine which events need priority attention. The definition of log levels is set according to the severity of the risk, such as information, warning, error and severe levels, to facilitate subsequent log analysis and event response. The generation of audit logs includes recording key event details, such as timestamps, executed SQL statements, operating users, accessed database tables and other relevant context information.

[0123] It is understandable that: through the implementation of this approach, the audit system is able to provide appropriate logging and response levels for each type of risk event, thereby ensuring that critical information is not overlooked and that appropriate security measures can be taken based on the risk level.

[0124] It should be understood that in order to better respond to and manage potential risks in the database, the specific steps for defining log levels according to classified risk events can be:

[0125] (1) Assess the potential impact and likelihood of each risk event.

[0126] (2) Map risk events to corresponding log levels to ensure that more serious risks receive higher attention.

[0127] (3) Apply standardized rules to automate this process to reduce human errors and speed up response time.

[0128] (4) Regularly review and adjust classification standards and log level definitions to adapt to new security threats and business needs.

[0129] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A SQL risk checking method based on semantic analysis, characterized in that: The method comprises the following steps: Step S10: removing interference information from the input SQL statement, and standardizing the SQL statement after removing the interference information to obtain a standardized SQL statement; Step S20: Decompose the standardized SQL statement to obtain a Token sequence, and perform syntax analysis according to the Token sequence to obtain an abstract syntax tree; Step S30: extracting core elements from the abstract syntax tree to construct a semantic vector, and obtaining key semantic information according to the semantic vector; Step S40: After obtaining the risk assessment result according to the key semantic information, an audit log is recorded.

2. The SQL risk checking method based on semantic analysis according to claim 1, characterized in that: In step S40, the step of obtaining risk assessment results according to the key semantic information and recording audit logs includes: Based on key semantic information, the preset database operation mode is processed to generate intermediate data; Perform weighted analysis on the intermediate data and calculate the probability of risk events, and generate a risk assessment report based on the calculation results of the probability of risk events.

3. The SQL risk checking method based on semantic analysis according to claim 1, characterized in that: In step S40, the step of recording an audit log after obtaining a risk assessment result according to the key semantic information further includes: Classify risk events based on risk assessment results; Define log levels based on categorized risk events; Generates audit logs according to the defined log level.

4. The SQL risk checking method based on semantic analysis according to claim 1, characterized in that: After step S40, the method further includes: Performing real-time interception based on the risk assessment results; The audit log is updated according to the real-time interception results of the execution.

5. The SQL risk checking method based on semantic analysis according to claim 1, characterized in that: The interference information in step S10 includes annotation content, blank characters, special characters and non-semantically related symbols.

6. The SQL risk checking method based on semantic analysis according to claim 1, characterized in that: The Token sequence in step S20 includes: keyword tokens, operator tokens and text tokens.

7. The SQL risk checking method based on semantic analysis according to claim 1, characterized in that: The core elements in step S30 include: table name, field name, operation type and conditional statement.

8. A SQL risk checking device based on semantic analysis, characterized in that: The SQL risk checking device based on semantic analysis includes: The interference information removal and standardization module is used to remove interference information from the input SQL statement, and standardize the SQL statement after the interference information is removed to obtain a standardized SQL statement; The Token decomposition and syntax parsing module is used to decompose the standardized SQL statement to obtain a Token sequence, and perform syntax parsing according to the Token sequence to obtain an abstract syntax tree; A semantic vector construction module, used to extract core elements from the abstract syntax tree to construct a semantic vector, and obtain key semantic information according to the semantic vector; The risk assessment and audit log recording module is used to extract core elements from the abstract syntax tree and then construct a semantic vector, and obtain key semantic information according to the semantic vector.

9. A SQL risk checking device based on semantic analysis, characterized in that: The SQL risk checking device based on semantic analysis includes: A memory, a processor, and a SQL risk checking program based on semantic analysis stored in the memory and executable on the processor, wherein the SQL risk checking program based on semantic analysis, when executed by the processor, implements a SQL risk checking method based on semantic analysis as described in any one of claims 1 to 7.

10. A computer program product, characterized in that The computer program product comprises a SQL risk checking program based on semantic analysis, and when the SQL risk checking program based on semantic analysis is executed by a processor, the SQL risk checking method based on semantic analysis as claimed in any one of claims 1 to 7 is implemented.

Images