Database risk detection method and device, storage medium and terminal

Abstract

The invention discloses a database risk detection method and device, a storage medium and a terminal. In response to a database risk detection request triggered for the target access request, extracting a to-be-detected attack statement in the target access request through the large language model, and generating a to-be-detected vector of the to-be-detected attack statement; a target vector meeting a preset similar condition with the to-be-detected vector is inquired in a vector database, a target attack statement corresponding to the target vector is determined, and at least one vector corresponding to an attack statement used for executing the SQL injection attack is stored in the vector database; and outputting a query result corresponding to the target access request, wherein the query result comprises the target attack statement. When the detection request is triggered, the large language model extracts the to-be-detected attack statement, then the to-be-detected attack statement is vectorized through the vector model to generate the to-be-detected vector, the to-be-detected vector is compared with the vector corresponding to the attack statement in the database, and the result is obtained, so that the risk detection cost is reduced, and the detection accuracy is ensured.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a database risk detection method, device, storage medium and terminal. Background Art

[0002] Structured Query Language (SQL) is a common database query language. Based on the SQL language, a database attack method has emerged: SQL Injection (SQLi), in which attackers manipulate the backend database by inserting malicious SQL code into the input field of the application, thereby performing illegal operations on the database. Existing SQL injection detection methods can identify potential SQL injection attacks to a certain extent, but there are still many problems such as low detection rate and high false positives. Therefore, a database risk detection method is needed to cope with the increasingly complex challenges of network attacks and improve the security of the database. Summary of the invention

[0003] The present application provides a database risk detection method, device, storage medium and terminal to solve the problems of low detection rate and high false positive rate in the above-mentioned SQL injection detection method.

[0004] In a first aspect, an embodiment of the present application provides a database risk detection method, the method comprising:

[0005] In response to a database risk detection request triggered by a target access request, an attack statement to be detected in the target access request is extracted through a large language model, and a vector to be detected of the attack statement to be detected is generated;

[0006] Querying a target vector that satisfies a preset similarity condition with the vector to be detected in a vector database, and determining a target attack statement corresponding to the target vector, wherein the vector database stores at least one vector corresponding to an attack statement for executing an SQL injection attack and a mapping relationship between each attack statement and a corresponding vector;

[0007] Generate a query result corresponding to the target access request, and the query result includes a target attack statement.

[0008] In a second aspect, an embodiment of the present application provides a database risk detection device, the device comprising:

[0009] A vector generation module, configured to respond to a database risk detection request triggered by a target access request, extract an attack statement to be detected in the target access request through a large language model, and generate a vector to be detected for the attack statement to be detected;

[0010] A vector query module is used to query a target vector that meets a preset similarity condition with the vector to be detected in a vector database, and determine a target attack statement corresponding to the target vector. The vector database stores at least one vector corresponding to an attack statement for executing an SQL injection attack and a mapping relationship between each attack statement and the corresponding vector;

[0011] The result generation module is used to generate a query result corresponding to the target access request, and the query result includes a target attack statement.

[0012] In a third aspect, an embodiment of the present application provides a computer storage medium, wherein the computer storage medium stores a plurality of instructions, and the instructions are suitable for being loaded by a processor and executing the steps of the method.

[0013] In a fourth aspect, an embodiment of the present application provides a terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is suitable for being loaded by the processor and executing the steps of the method.

[0014] The beneficial effects brought about by the technical solutions provided by some embodiments of the present application include at least:

[0015] The present application provides a database risk detection method. In response to a database risk detection request triggered by a target access request, an attack statement to be detected in the target access request is extracted through a large language model, and a vector to be detected of the attack statement to be detected is generated; a target vector that meets a preset similarity condition with the vector to be detected is queried in a vector database, and a target attack statement corresponding to the target vector is determined, wherein the vector database stores at least one vector corresponding to an attack statement for executing an SQL injection attack and a mapping relationship between each attack statement and the corresponding vector; and a query result corresponding to the target access request is generated, wherein the query result includes the target attack statement. When a risk detection request for a target access request is triggered, the attack statement in the access request is first extracted through the large language model. The large language model identifies attack behaviors by analyzing the semantic features of the statements, and can respond to various attack methods more flexibly. This not only detects database risks in a timely and accurate manner, but also avoids the cost of training and maintaining special models. Furthermore, the extracted attack statement is vectorized to obtain its corresponding vector, and then some target vectors similar to the above vector are queried in the vector database. By comparing the similarity between the two, it is determined whether the extracted attack statement is an SQL injection attack statement. This vector comparison method can accurately distinguish normal SQL statements from malicious SQL injection attack statements, reducing the possibility of false positives and negatives. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present application 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 application. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

[0017] Figure 1 An exemplary system architecture diagram of a database risk detection method provided in an embodiment of the present application;

[0018] Figure 2 A schematic diagram of a process flow of a database risk detection method provided in an embodiment of the present application;

[0019] Figure 3 A schematic diagram of an interface of a database risk detection method provided in an embodiment of the present application;

[0020] Figure 4 A schematic diagram of a process flow of a database risk detection method provided in an embodiment of the present application;

[0021] Figure 5 A schematic diagram of a sample collection process in a database risk detection method provided in an embodiment of the present application;

[0022] Figure 6 A structural block diagram of a database risk detection device provided in an embodiment of the present application;

[0023] Figure 7 A schematic diagram of the structure of a terminal provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the features and advantages of the present application more obvious and easy to understand, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0025] When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0026] As a powerful database query language, SQL allows users to query and update data in a flexible way, realize the automation of data processing, and thus improve the efficiency and accuracy of data management. Therefore, it has a wide application base in database systems. However, the flexibility of SQL statements increases the risk of injection attacks. By inserting malicious SQL code in the input field, attackers can bypass the security check of the application, manipulate the background database, steal, tamper with data, or perform other illegal operations. The existing SQL injection detection methods are mainly rule-based or traditional machine learning detection. Among them, the rule-based detection method detects by matching common keywords in SQL injection attacks. Since the rules are pre-defined, when matching keywords are detected, the database can respond quickly to prevent potential SQL injection attacks. This method is intuitive and easy to understand and implement. The detection method based on traditional machine learning can automatically learn the characteristics of SQL injection attacks by training models, so as to adapt to different attack modes to a certain extent. With sufficient training data, the detection method based on traditional machine learning can achieve risk detection of SQL injection attacks.

[0027] However, as network attack methods continue to evolve and become more complex, attackers can bypass rule-based detection by deforming the attack statements (payload) of SQL injection attacks (such as replacing spaces, mixing uppercase and lowercase letters, etc.); and due to the complexity and diversity of SQL statements, rule-based detection methods may misjudge legitimate SQL statements as attack statements, resulting in unnecessary alarms and misoperations. At the same time, in traditional machine learning-based detection methods, in order to maintain the detection capability of the model, it is necessary to continuously collect black and white samples and retrain the model, which greatly increases the maintenance cost and may cause performance fluctuations in the model during the update process due to deviations in the quantity and quality of training data, thereby affecting the risk detection capability of the model. Therefore, the existing SQL injection detection methods cannot effectively deal with all attack modes, resulting in a lag in database security protection.

[0028] Therefore, an embodiment of the present application provides a database risk detection method to solve the above-mentioned technical problem of insufficient database security protection.

[0029] See also Figure 1 , Figure 1 An exemplary system architecture diagram of a database risk detection method provided in an embodiment of the present application.

[0030] like Figure 1As shown, the system architecture may include a terminal 101, a network 102, and a server 103. The network 102 is used to provide a medium for a communication link between the terminal 101 and the server 103. The network 102 may include various types of wired communication links or wireless communication links, for example, the wired communication link includes an optical fiber, a twisted pair, or a coaxial cable, and the wireless communication link includes a Bluetooth communication link, a Wireless-Fidelity (Wi-Fi) communication link, or a microwave communication link.

[0031] The terminal 101 can interact with the server 103 through the network 102 to receive messages from the server 103 or send messages to the server 103, or the terminal 101 can interact with the server 103 through the network 102 to receive messages or data sent by other users to the server 103. The terminal 101 can be hardware or software. When the terminal 101 is hardware, it can be various electronic devices, including but not limited to smart watches, smart phones, tablet computers, laptop portable computers and desktop computers. When the terminal 101 is software, it can be installed in the electronic devices listed above, which can be implemented as multiple software or software modules (for example: used to provide distributed services), or it can be implemented as a single software or software module, which is not specifically limited here.

[0032] In an embodiment of the present application, the terminal 101 first responds to a database risk detection request triggered by a target access request, extracts the attack statement to be detected in the target access request through a large language model, and generates a target vector to be detected for the attack statement to be detected; then, the terminal 101 queries a vector database for a target vector that meets a preset similarity condition with the vector to be detected, and determines a target attack statement corresponding to the target vector, wherein the vector database stores at least one vector corresponding to an attack statement for executing an SQL injection attack; finally, the terminal 101 outputs a query result corresponding to the target access request, and the query result includes the target attack statement.

[0033] The server 103 may be a business server that provides various services. It should be noted that the server 103 may be hardware or software. When the server 103 is hardware, it may be implemented as a distributed server cluster consisting of multiple servers, or it may be implemented as a single server. When the server 103 is software, it may be implemented as multiple software or software modules (for example, for providing distributed services), or it may be implemented as a single software or software module, which is not specifically limited here.

[0034] Alternatively, the system architecture may not include the server 103. In other words, the server 103 may be an optional device in the embodiments of this specification. That is, the method provided in the embodiments of this specification may be applied to a system structure that only includes the terminal 101, and the embodiments of this application do not limit this.

[0035] It should be understood that Figure 1 The number of terminals, networks and servers in the figure is only for illustration and any number of terminals, networks and servers may be used according to implementation requirements.

[0036] See also Figure 2 , Figure 2 A flowchart of a database risk detection method provided in an embodiment of the present application. The execution subject of the embodiment of the present application can be a terminal that executes database risk detection, a processor in the terminal that executes the database risk detection method, or a database risk detection service in the terminal that executes the database risk detection method. For the convenience of description, the specific execution process of the database risk detection method is introduced below by taking the execution subject being the processor in the terminal as an example.

[0037] like Figure 2 As shown, the database risk detection method may at least include:

[0038] S202 . In response to a database risk detection request triggered by a target access request, extract attack statements to be detected in the target access request through a large language model, and generate a vector to be detected of the attack statements to be detected.

[0039] Alternatively, as a core system for storing and managing data, the database is usually accessed through specific access requests. These requests may come from users, applications, or other components, which interact with the database by sending access requests containing required operations and data information. SQL injection attacks are an attack method that bypasses normal security control mechanisms by constructing malicious SQL statements to illegally access or tamper with database content. These malicious SQL statements are usually embedded in access requests input by users or generated by applications. Therefore, obtaining access requests to the database and conducting in-depth analysis of them can directly obtain the original information of the interaction between users or applications and the database, which is an important means of identifying and preventing SQL injection attacks.

[0040] Optionally, in a feasible embodiment, in order to protect the database from security threats such as unauthorized access and data leakage, the database management system is internally configured with a mechanism for identifying and responding to potential security risks, such as automatically identifying potential database risks through IP address list, access frequency restriction, keyword filtering, etc. When the database receives an access request (target access request), if the request triggers a preset risk detection mechanism (such as an access request from an IP address in a blacklist, frequent access from a specific IP address, a request containing a specific keyword, etc.), a database risk detection request for the access request is automatically triggered.

[0041] Optionally, in another feasible embodiment, when using the database, users may find some abnormal or suspicious access requests. In this case, users should be allowed to upload suspicious target access requests as an additional data source to provide more comprehensive information for database risk detection. Through the user upload mechanism, information that is not covered by the preset risk detection mechanism can be fed back to the database management system in a timely manner, which helps to timely discover and deal with potential security risks. Figure 3 The interface diagram of a database risk detection method provided by an embodiment of the present application is shown, wherein the "Input HTTP request" module is a control provided for users to upload target access requests by themselves. When the user finds a suspicious access request, the user can input the access request into the input bar below the module and trigger a database risk detection request for the input access request by clicking the "Analysis" button below.

[0042] Optionally, in addition to allowing users to upload suspicious target access requests by themselves, when users find certain attack statements, they can also trigger a detection request by directly uploading the attack statement. In this case, the large language model does not need to perform additional work to extract the attack statement, which improves the efficiency of data processing. Figure 3 Taking the interface schematic diagram of a database risk detection method provided in an embodiment of the present application as an example, the "input payload" module is a control provided for users to upload attack statements by themselves. When the user finds a suspicious attack statement, the attack statement can be entered into the input bar below the module, and a database risk detection request for the entered attack statement can be triggered by clicking the "judgment" button below.

[0043] Alternatively, SQL injection attacks are often not just simple keyword stacking, but contain complex semantic structures. For example, some seemingly harmless words combined together may constitute SQL injection attacks in a specific context. The large language model has a deep understanding of complex contexts through deep learning technology and large-scale data training, which enables it to capture subtle semantic features, thereby accurately grasping the contextual information in SQL statements and accurately identifying potential SQL injection attacks. Therefore, the large language model can be used to process database access requests to identify SQL injection attacks.

[0044] Optionally, in the specific identification process, since the target access request may contain a large amount of non-critical information, such as normal data queries, reasonable user operations, etc., directly using a large language model to fully parse the target access request may consume a lot of computing resources and time, and malicious SQL injection attack information may also be submerged in a large amount of non-critical information. Based on this, the SQL statements in the target access request can be deeply parsed through a large language model to extract key attack statements (payload), that is, those that may pose a threat or attack, so as to more efficiently identify potential security risks. By extracting the attack statements in the target access request, the characteristics of the attack behavior can be more accurately identified, thereby improving the accuracy of detection.

[0045] Furthermore, the extracted attack statements often contain complex semantic information, which is difficult to accurately capture through simple string matching or keyword filtering. In order to further improve the accuracy of risk detection, it is also possible to consider processing attack statements through vectorization technology, by converting attack statements into mathematical representations that can be efficiently and accurately processed and understood by computers, and evaluating the similarity between each vector to determine the semantic similarity therein, thereby more accurately identifying attack behaviors. Based on this, after extracting the attack statements in the target access request, that is, the attack statements to be detected, through the large language model, the above-mentioned attack statements to be detected are vectorized through the preset vector model to generate the corresponding vector to be detected, ensuring that the generated vector can accurately reflect the semantic characteristics of the attack statements to be detected, and providing strong support for subsequent vector matching and risk identification.

[0046] S204, searching the vector database for a target vector that meets a preset similarity condition with the vector to be detected, and determining a target attack statement corresponding to the target vector.

[0047] Optionally, a vector database is pre-set, which stores vectors corresponding to attack statements for executing SQL injection attacks and mapping relationships between attack statements and corresponding vectors. After the vector to be detected corresponding to the attack statement to be detected is generated by the vector model, some target vectors with high similarity to the vector to be detected can be queried in the pre-set vector database. By comparing the similarity between the vector to be detected and the target vector, a more intuitive query result can be provided, which is convenient for subsequent risk analysis and security decision-making.

[0048] Optionally, although similarity calculation, classification and other operations can be performed more conveniently through the vector form, improving the speed and accuracy of data processing, since the vector data exists in the form of mathematical representation, this abstractness makes it difficult to directly understand the semantics behind it. Therefore, after querying the target vector that is most similar to the vector to be detected through the vector method, it is necessary to determine the target attack statement corresponding to each target vector through the mapping relationship between each attack statement and the vector in the vector database, so as to facilitate user understanding, so that the user can directly perform manual review to further analyze and determine whether the detected attack statement really poses a threat, and take corresponding measures to defend, so as to ensure the accuracy and reliability of the detection results.

[0049] S206: Generate a query result corresponding to the target access request, where the query result includes a target attack statement.

[0050] Optionally, after finding the target attack statement that is highly similar to the attack statement to be detected, the query result of this database risk detection request can be generated and displayed. In this process, in addition to directly listing the target attack statement, detailed information related to the target attack statement can also be provided, such as attack intensity assessment, potential hazard analysis, etc. This information can provide users with a more comprehensive basis for risk assessment, help users to more comprehensively understand the nature of the attack statement in the current target access request and the possible risks, and help users make the next decision. Figure 3 Taking the interface schematic diagram of a database risk detection method provided in an embodiment of the present application as an example, the "Analysis Result" module on the right side of the interface is the query result display area for risk detection.

[0051] In an embodiment of the present application, a database risk detection method is provided. In response to a database risk detection request triggered by a target access request, an attack statement to be detected in the target access request is extracted through a large language model, and a vector to be detected of the attack statement to be detected is generated; a target vector that meets a preset similarity condition with the vector to be detected is queried in a vector database, and a target attack statement corresponding to the target vector is determined, wherein the vector database stores at least one vector corresponding to an attack statement for executing an SQL injection attack and a mapping relationship between each attack statement and the corresponding vector; a query result corresponding to the target access request is generated, and the query result includes the target attack statement. When a risk detection request for a target access request is triggered, the attack statement in the access request is first extracted through the large language model. The large language model identifies attack behaviors by analyzing the semantic features of the statements, and can respond to various attack methods more flexibly. This not only detects database risks in a timely and accurate manner, but also avoids the cost of training and maintaining special models. Furthermore, the extracted attack statement is vectorized to obtain its corresponding vector, and then some target vectors similar to the above vector are queried in the vector database. By comparing the similarity between the two, it is determined whether the extracted attack statement is an SQL injection attack statement. This vector comparison method can accurately distinguish normal SQL statements from malicious SQL injection attack statements, reducing the possibility of false positives and negatives.

[0052] See also Figure 4 , Figure 4 A flowchart of a database risk detection method provided in an embodiment of the present application.

[0053] like Figure 4 As shown, the database risk detection method may at least include:

[0054] S402: In response to a database risk detection request triggered by a target access request, determine whether there is a SQL injection attack risk in the target access request according to a prompt word indicating a large language model.

[0055] Optionally, since the target access request is only an access request suspected of having an SQL injection attack detected by the database management system or discovered by the user, there is a possibility of misjudgment. Therefore, in the process of extracting the attack statement to be detected, the large language model can first be used to judge whether there is a risk of SQL injection attack in the target access request, so as to provide a decision basis for the subsequent extraction of the attack statement to be detected. Specifically, the large language model can be guided to make corresponding judgments and processing by designing appropriate prompt words. These prompt words can contain a variety of contents such as background information, goals and tasks, and can clearly express the detection goals and processing methods, and guide the large language model to perform corresponding logical analysis and reasoning. In the judgment process, the large language model will parse and understand the SQL statements in the target access request based on these prompt words and the features and patterns of SQL injection attacks learned during the training process. If the SQL statement in the request matches the attack pattern learned by the model, then the model will judge that the request has a risk of SQL injection attack. By judging whether there is a potential SQL injection attack risk in the target access request, we can screen out the content in the target access request that actually poses a risk, which is conducive to the subsequent more targeted extraction and analysis of attack statements, thereby reducing unnecessary data processing work and improving the efficiency of risk detection.

[0056] S404: If yes, extract the attack statement to be detected corresponding to the SQL injection attack risk through the large language model, and generate a vector to be detected for the attack statement to be detected.

[0057] Optionally, when the large language model determines that there is indeed a risk of SQL injection attack in the target access request, the attack statement to be detected in the target access request is extracted, and its corresponding vector to be detected is further generated. Specifically, for step S404, please refer to the detailed record in step S202, which will not be repeated here.

[0058] S406 , respectively calculating the similarity between each vector in the vector database and the vector to be detected, and determining the first K vectors as target vectors in descending order of the similarities.

[0059] Optionally, after the attack statement to be detected in the target access request is converted into a vector to be detected, it is necessary to find a similar target vector in the vector database. This process can be achieved by calculating the similarity between vectors. By quantifying the similarity between the vector to be detected and each vector in the vector database, we can more intuitively evaluate the correlation between them. This correlation reflects the similarity between the attack statement to be detected and the known attack statements in terms of semantic features, structure, etc., and can further determine whether the statement to be detected poses a risk. If the similarity between the two is high, it means that the statement to be detected and the attack statement are similar in structure, features or intent, which means that the statement to be detected has a potential SQL injection attack risk.

[0060] Optionally, the stronger the correlation between the vector and the vector to be detected, that is, the higher the similarity, the more likely it is to constitute an SQL injection attack. Therefore, after calculating the similarity between each vector and the vector to be detected, the vectors are sorted in descending order of similarity, and the vector most likely to constitute an SQL injection attack is placed in front, so as to facilitate subsequent analysis and processing.

[0061] Alternatively, if all vectors are analyzed and compared in detail, it will not only consume a lot of computing resources, but also significantly reduce the speed of risk detection. Therefore, the top K vectors with the highest similarity can be screened out as target vectors, focusing on the vectors that are most likely to constitute SQL injection attacks, reducing the impact of noise data on the detection process, and thus greatly improving detection efficiency. When determining the top K target vectors, a K value that is too small may result in missed detections, that is, missing some potential similar attack statements; a K value that is too large will increase the complexity of subsequent processing. Therefore, the selection of the K value needs to be comprehensively considered based on the actual application scenario and performance requirements, and the K value should be dynamically adjusted based on the false alarm rate and missed alarm rate in the historical data, as well as the current system load, to balance the detection accuracy and detection efficiency.

[0062] S408: Compare the target similarity between each target vector and the vector to be detected with a preset similarity threshold.

[0063] Optionally, different application scenarios have different requirements for risk detection. Some scenarios may focus more on security and hope to reduce false positives and false negatives as much as possible; while some scenarios may focus more on detection efficiency and hope to identify risks as quickly as possible. Based on this, we can set a certain preset similarity threshold and adjust this similarity threshold according to different application scenarios and requirements to adapt to different detection requirements. By setting a reasonable preset similarity threshold, it can be determined whether the similarity between the vector to be detected and the target vector reaches the standard sufficient to be determined as a SQL injection attack. Specifically, after screening out some target vectors with high similarity to the vector to be detected, the similarity between each target vector and the vector to be detected, that is, the target similarity, is compared with the preset similarity threshold. If any target similarity is greater than or equal to the preset similarity threshold, we believe that there is a SQL injection attack; if each target similarity is lower than this threshold, the currently detected access request is considered safe.

[0064] S410: If there is at least one target similarity greater than or equal to a preset similarity threshold, it is determined that there is a SQL injection attack in the target access request, and a corresponding attack confirmation result is generated in the query result.

[0065] Optionally, after comparison, if there is at least one target similarity greater than or equal to a preset similarity threshold, then we believe that the vector to be detected has a high similarity with a vector corresponding to an attack statement in the vector database, which indicates that there is a SQL injection attack in the target access request. At this time, an attack confirmation result can be generated in the query result, and this confirmation result can include information such as risk level and possible SQL injection attack type, so as to help users quickly understand the risk situation and take corresponding security measures.

[0066] S412: If the similarities of each target are less than the preset similarity threshold, it is determined that there is no SQL injection attack in the target access request, and a corresponding security result is generated in the query result.

[0067] Optionally, when the comparison shows that the similarities of each target are less than the preset similarity threshold, it is considered that the vector to be detected does not have sufficient similarity with the vector corresponding to any attack statement in the vector database, so it can be determined that there is no SQL injection attack in the target access request. At this time, a security result needs to be generated. This result can be a simple confirmation message indicating that the target access request is safe and no risk of SQL injection attack is detected; it can also include other relevant information, such as detection time, etc., to facilitate subsequent security audits and tracing.

[0068] S414: Determine the target attack statement corresponding to the target vector, and generate a query result corresponding to the target access request.

[0069] Optionally, after determining the target vector, it is necessary to determine the target attack statement corresponding to each target vector through the mapping relationship between each attack statement and the vector in the vector database, and further generate and display the query result of this database risk detection request. Figure 2 The detailed description in the illustrated embodiments will not be repeated here.

[0070] In an embodiment of the present application, a database risk detection method is provided, which first determines whether there is a SQL injection attack risk in the target access request through a prompt word instructing a large language model, and then extracts the attack statement when it is confirmed that there is a SQL injection attack risk. This targeted extraction and analysis of attack statements reduces unnecessary data processing work, thereby improving the efficiency of risk detection. By calculating the similarity between each vector and the vector to be detected and sorting them, the target vectors with the highest similarity are quantitatively screened out and the target vectors are subsequently analyzed, which not only provides a more intuitive processing process, but also saves computing resources. Further, the target similarity between the target vector determined above and the vector to be detected is compared with a preset similarity threshold. According to the comparison result, it can be more accurately determined whether there is a SQL injection attack in the target access request, avoiding the false positive or false negative problem that may be caused by making a judgment based on similarity sorting alone, and improving the accuracy of detection.

[0071] See also Figure 5 , Figure 5 A schematic diagram of a sample collection process in a database risk detection method provided in an embodiment of the present application.

[0072] like Figure 5 As shown, the database risk detection method may at least include:

[0073] S502: In response to an attack statement collection request triggered by at least one sample access request, extract original attack statements in each sample access request through a large language model.

[0074] Optionally, the vectors corresponding to the attack statements stored in the vector database actually constitute a comparison benchmark, representing known attack patterns and behavioral characteristics. By comparing the similarity between the vectors in the vector database and the vectors to be detected corresponding to the attack statements to be detected in the target access request, it can be determined whether there is an SQL injection attack in the current access request. In order to have sufficient comparison benchmarks during risk detection and improve the accuracy of detection results, a sufficient number of attack statements and their corresponding vectors need to be stored in the vector database. By collecting and uploading samples corresponding to attack statements, the content in the vector database can be enriched to include more attack patterns and characteristics.

[0075] Optionally, the sample access requests may come from a variety of channels, such as network traffic monitoring devices such as Web Application Firewall (WAF), Intrusion Prevention System (IPS) or Network Data Recorder (NDR), which can capture and record HTTP request logs, and collect suspicious access requests that may contain SQL injection attacks as sample access requests to be further analyzed and processed. When the user triggers an attack statement collection request for each sample access request, the collected sample access requests are used to extract attack statements through a large language model to obtain a sample set of original attack statements.

[0076] S504: Perform data cleaning on each original attack statement to obtain at least one attack statement for executing a SQL injection attack.

[0077] Optionally, the original attack statements extracted by the large language model may contain misjudgments, repetitions, similarities, etc. In order to obtain a more accurate set of attack statements, data cleaning is also required to obtain accurate attack statements, that is, to determine the attack statements used to perform SQL injection attacks. Specifically, the original attack statements can be clustered and deduplicated, the collected multiple original attack statements can be grouped, and the repeated content in each group can be removed, leaving only the unique attack statement; on the basis of clustering and deduplication, those attack statements that are not exactly the same but have similar functions or effects can be further identified and removed; non-SQL injection attack content can also be removed, etc.

[0078] S506. Vectorize each attack statement according to a preset vector model to obtain a vector corresponding to each attack statement, and store the vector in a vector database. The vector model is also used to generate a vector to be detected for the attack statement to be detected.

[0079] Optionally, after collecting and cleaning the attack statements used to perform SQL injection attacks, the method of the embodiment of the present application will vectorize each attack statement according to a preset vector model to convert the attack statement into a vector representation, thereby facilitating subsequent similarity calculations and query comparisons. In specific implementations, qwen or other similar vector models can be used to vectorize attack statements, as long as they have strong text understanding and generation capabilities, can capture semantic information and contextual relationships in the text, and convert text data into vector representations with rich semantic information. The embodiment of the present application does not limit the specific type of the vector model.

[0080] It should be noted that, whether in the sample collection stage or in the detection stage, in order to ensure the consistency of the representation of the same or similar attack statements in the vector space, the vector model used to convert the attack statement into a vector representation in the sample collection stage will also be used to generate the vector to be detected for the attack statement to be detected in the detection stage. Using the same vector model for vector conversion and detection can ensure the accuracy of the detection results, which helps to reduce false positives and false negatives.

[0081] Optionally, after obtaining the vectors corresponding to each attack statement, the method of the embodiment of the present application will store these vectors in a vector database specifically used for storing and retrieving vector data. This vector database can support efficient vector similarity calculation and retrieval operations. When storing vectors, the mapping relationship between the vectors and the corresponding attack statements will also be stored in the vector database, so that in the subsequent retrieval process, the corresponding attack statement can be quickly found according to the vector, which is convenient for further analysis and processing. In the specific implementation, the open source Milvus or other similar vector databases can be selected as the storage platform. As long as it can meet the storage and retrieval requirements of large-scale vector data, the embodiment of the present application does not limit the specific type of the vector database.

[0082] S508: In response to an attack statement upload request triggered by a user for the attack statement to be uploaded, generate a vector to be uploaded corresponding to the attack statement to be uploaded, and store the vector to be uploaded and the mapping relationship between the vector to be uploaded and the attack statement to be uploaded in a vector database.

[0083] Optionally, new SQL injection attack methods emerge in an endless stream, and a large model trained in advance may not always be able to detect some new forms of SQL injection attacks. Therefore, the method in the embodiment of the present application also allows users to upload some attack statements that the model has not discovered. These attack statements uploaded by users can be used as new sample data to enrich the sample library, so as to help the risk detection system to have a more comprehensive understanding of various attack modes and improve detection capabilities.

[0084] Specifically, when a user wants to submit a specific attack statement to be added to the database as a supplementary sample, he can directly enter the relevant attack statement to be uploaded and trigger the attack statement upload request. The method of the embodiment of the present application will first receive and parse the attack statement uploaded by the user, and can pre-process it, which may include removing irrelevant characters, formatting text, etc., to ensure the accuracy of the attack statement. Then, the attack statement uploaded by the user is vectorized using a preset vector model (such as a qwen vector model) to obtain the vector to be uploaded corresponding to the attack statement to be uploaded. This step converts the attack statement into a vector representation in a multidimensional space for subsequent similarity calculation and retrieval. Finally, the generated vector to be uploaded and the mapping relationship between it and the attack statement to be uploaded are stored in the vector database. When there is a subsequent risk detection requirement, the attack statement uploaded by the user and its corresponding vector can be used as a known attack statement for detection.

[0085] For example, Figure 3 Taking the interface schematic diagram of a database risk detection method provided by an embodiment of the present application as an example, the "input payload" module is a control provided to users for uploading attack statements into the library. When the user needs to upload an attack statement into the library, the attack statement can be entered into the input bar below the module, and an attack statement upload request for the entered attack statement can be triggered by clicking the "submit to library" button below.

[0086] In an embodiment of the present application, a database risk detection method is provided, which extracts attack statements from each sample access request through a large language model, performs certain data cleaning processing on the extracted original attack statements to obtain attack statements for executing SQL injection attacks, and then vectorizes each attack statement according to a preset vector model, and finally stores the vectors corresponding to each attack statement in a vector database. This process of storing known attack statements and their vectors in a vector database provides sufficient comparison samples for risk detection, which helps to improve the accuracy of the detection results. At the same time, by allowing users to upload attack statements to submit supplementary samples for storage, users can adjust the comparison samples in the vector database according to specific security needs, thereby improving the detection capabilities of the risk detection system.

[0087] See also Figure 6 , Figure 6 This is a structural block diagram of a database risk detection device provided in an embodiment of the present application. Figure 6 As shown, the database risk detection device 600 includes:

[0088] The vector generation module 610 is used to respond to the database risk detection request triggered by the target access request, extract the attack statement to be detected in the target access request through the large language model, and generate the vector to be detected of the attack statement to be detected;

[0089] A vector query module 620 is used to query a target vector that meets a preset similarity condition with the vector to be detected in a vector database, and determine a target attack statement corresponding to the target vector. The vector database stores at least one vector corresponding to an attack statement for executing an SQL injection attack and a mapping relationship between each attack statement and the corresponding vector.

[0090] The result generation module 630 is used to generate a query result corresponding to the target access request, and the query result includes a target attack statement.

[0091] Optionally, the vector generation module 610 is further used to determine whether there is a SQL injection attack risk in the target access request based on the prompt word indication large language model; if so, extract the attack statement to be detected corresponding to the SQL injection attack risk through the large language model.

[0092] Optionally, the vector query module 620 is further used to respectively calculate the similarity between each vector in the vector database and the vector to be detected, and determine the first K vectors as target vectors in descending order of the similarities, where K is a positive integer.

[0093] Optionally, the database risk detection device 600 also includes: a similarity comparison module, which is used to compare the target similarity between each target vector and the vector to be detected with a preset similarity threshold after the vector query module 620 determines that the first K vectors are target vectors in order of similarities from high to low; if there is at least one target similarity greater than or equal to the preset similarity threshold, it is determined that there is an SQL injection attack in the target access request, and a corresponding attack confirmation result is generated in the query result; if each target similarity is less than the preset similarity threshold, it is determined that there is no SQL injection attack in the target access request, and a corresponding security result is generated in the query result.

[0094] Optionally, the database risk detection device 600 also includes: an attack statement collection module, which is used to respond to an attack statement collection request triggered by at least one sample access request, extract the original attack statement in each sample access request through a large language model; perform data cleaning on each original attack statement to obtain at least one attack statement for executing an SQL injection attack.

[0095] Optionally, the database risk detection device 600 also includes: an attack statement vectorization module, which is used to perform data cleaning on each original attack statement in the attack statement collection module to obtain attack statements for executing SQL injection attacks, and then vectorize each attack statement according to a preset vector model to obtain a vector corresponding to each attack statement, and store the vector in a vector database. The vector model is also used to generate a vector to be detected for the attack statement to be detected.

[0096] Optionally, the database risk detection device 600 also includes: an attack statement uploading module, which is used to respond to an attack statement upload request triggered by a user for the attack statement to be uploaded, generate a vector to be uploaded corresponding to the attack statement to be uploaded, and store the mapping relationship between the vector to be uploaded and the attack statement to be uploaded in the vector database.

[0097] In an embodiment of the present application, a database risk detection device is provided, wherein a vector generation module is used to respond to a database risk detection request triggered for a target access request, extract the attack statement to be detected in the target access request through a large language model, and generate a vector to be detected for the attack statement to be detected; a vector query module is used to query a target vector that meets a preset similarity condition with the vector to be detected in a vector database, determine the target attack statement corresponding to the target vector, and the vector database stores at least one vector corresponding to an attack statement for executing an SQL injection attack and a mapping relationship between each attack statement and the corresponding vector; a result generation module is used to generate a query result corresponding to the target access request, and the query result includes the target attack statement. When a risk detection request for a target access request is triggered, the vector generation module first extracts the attack statement in the access request through a large language model, and then further vectorizes the extracted attack statement to obtain its corresponding vector. The application of the large language model is to identify attack behaviors by analyzing the semantic features of the statement, and can respond to a variety of attack methods more flexibly, which can detect database risks in a timely and accurate manner while also avoiding the cost of training and maintaining special models. Next, the vector query module searches for some target vectors similar to the above vectors in the vector database, and determines whether the extracted attack statement has SQL injection attack by comparing the similarity between the two. Finally, the result generation module generates the detected results. This vector calculation method can more accurately distinguish normal SQL statements from malicious SQL injection attacks, reducing the possibility of false positives and false negatives.

[0098] An embodiment of the present application further provides a computer storage medium, which can store multiple instructions, and the instructions are suitable for being loaded by a processor and executing the steps of any method in the above embodiments.

[0099] See also Figure 6, Figure 6 A schematic diagram of the structure of a terminal provided in an embodiment of the present application. Figure 6 As shown, the terminal 600 may include: at least one terminal processor 601 , at least one network interface 604 , a user interface 603 , a memory 605 , and at least one communication bus 602 .

[0100] The communication bus 602 is used to realize the connection and communication between these components.

[0101] The user interface 603 may include a display screen (Display) and a camera (Camera), and the optional user interface 603 may also include a standard wired interface and a wireless interface.

[0102] The network interface 604 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).

[0103] Among them, the terminal processor 601 may include one or more processing cores. The terminal processor 601 uses various interfaces and lines to connect various parts in the entire terminal 600, and executes various functions and processes data of the terminal 600 by running or executing instructions, programs, code sets or instruction sets stored in the memory 605, and calling data stored in the memory 605. Optionally, the terminal processor 601 can be implemented in at least one hardware form of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), and programmable logic array (Programmable Logic Array, PLA). The terminal processor 601 can integrate one or a combination of a central processing unit (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU) and a modem. Among them, the CPU mainly processes the operating system, user interface and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the terminal processor 601, and it can be implemented separately through a chip.

[0104] Among them, the memory 605 may include a random access memory (Random Access Memory, RAM) and may also include a read-only memory (Read-Only Memory, ROM). Optionally, the memory 605 includes a non-transitory computer-readable storage medium. The memory 605 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 605 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 605 may also be optionally at least one storage device located away from the aforementioned terminal processor 601. As Figure 6 As shown, the memory 605 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a database risk detection program.

[0105] exist Figure 6 In the terminal 600 shown, the user interface 603 is mainly used to provide an input interface for the user and obtain the data input by the user; and the terminal processor 601 can be used to call the database risk detection program stored in the memory 605, and specifically perform the following operations:

[0106] In response to a database risk detection request triggered by a target access request, an attack statement to be detected in the target access request is extracted through a large language model, and a vector to be detected of the attack statement to be detected is generated;

[0107] Querying a target vector that meets a preset similarity condition with the vector to be detected in a vector database, and determining a target attack statement corresponding to the target vector, wherein the vector database stores at least one vector corresponding to an attack statement for executing an SQL injection attack and a mapping relationship between each attack statement and a corresponding vector;

[0108] Generate a query result corresponding to the target access request, and the query result includes a target attack statement.

[0109] In some embodiments, when the terminal processor 601 extracts the attack statements to be detected in the target access request through the large language model, it specifically performs the following steps: judging whether there is a SQL injection attack risk in the target access request based on the prompt word indication large language model; if so, extracting the attack statements to be detected corresponding to the SQL injection attack risk through the large language model.

[0110] In some embodiments, when the terminal processor 601 executes a query in a vector database for a target vector that meets a preset similarity condition with the vector to be detected, it specifically performs the following steps: respectively calculate the similarity between each vector in the vector database and the vector to be detected, and determine the first K vectors as target vectors in descending order of the similarities, where K is a positive integer.

[0111] In some embodiments, after determining the first K vectors as target vectors in order of similarities from high to low, the terminal processor 601 further specifically performs the following steps: comparing the target similarity between each target vector and the vector to be detected with a preset similarity threshold; if there is at least one target similarity greater than or equal to the preset similarity threshold, it is determined that there is a SQL injection attack in the target access request, and a corresponding attack confirmation result is generated in the query result; if each target similarity is less than the preset similarity threshold, it is determined that there is no SQL injection attack in the target access request, and a corresponding security result is generated in the query result.

[0112] In some embodiments, the terminal processor 601 further specifically performs the following steps: in response to an attack statement collection request triggered by at least one sample access request, extracting the original attack statements in each sample access request through a large language model; performing data cleaning on each original attack statement to obtain at least one attack statement for executing a SQL injection attack.

[0113] In some embodiments, after performing data cleaning on each original attack statement to obtain an attack statement for executing an SQL injection attack, the terminal processor 601 further specifically performs the following steps: vectorizing each attack statement according to a preset vector model to obtain a vector corresponding to each attack statement, and storing the vector in a vector database. The vector model is also used to generate a vector to be detected for the attack statement to be detected.

[0114] In some embodiments, the terminal processor 601 further specifically performs the following steps: in response to an attack statement upload request triggered by a user for an attack statement to be uploaded, generate a vector to be uploaded corresponding to the attack statement to be uploaded, and store the mapping relationship between the vector to be uploaded and the attack statement to be uploaded in a vector database.

[0115] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0116] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0117] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The above computer program product includes one or more computer instructions. When the above computer program instructions are loaded and executed on a computer, the above process or function according to the embodiment of this specification is generated in whole or in part. The above computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The above computer instructions can be stored in a computer-readable storage medium or transmitted by the above computer-readable storage medium. The above computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The above computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, data center, etc. that contains one or more available media integrated. The above-mentioned available media can be magnetic media (for example, floppy disks, hard disks, tapes), optical media (for example, digital versatile discs (DVD)), or semiconductor media (for example, solid state drives (SSD)), etc.

[0118] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described action sequence, because according to the present application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0119] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0120] The above is a description of a database risk detection method, device, storage medium and terminal provided in the present application. For technicians in this field, according to the ideas of the embodiments of the present application, there may be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A database risk detection method, characterized in that: The method comprises: In response to a database risk detection request triggered by a target access request, extracting an attack statement to be detected in the target access request through a large language model, and generating a vector to be detected for the attack statement to be detected; Querying a target vector that satisfies a preset similarity condition with the vector to be detected in a vector database, and determining a target attack statement corresponding to the target vector, wherein the vector database stores at least one vector corresponding to an attack statement for executing an SQL injection attack and a mapping relationship between each attack statement and a corresponding vector; Generate a query result corresponding to the target access request, wherein the query result includes the target attack statement.

2. The method according to claim 1, characterized in that: The extracting the attack statement to be detected in the target access request by using the large language model includes: Instructing the large language model to determine whether there is a SQL injection attack risk in the target access request according to the prompt word; If so, the attack statement to be detected corresponding to the SQL injection attack risk is extracted through the large language model.

3. The method according to claim 1, characterized in that The step of searching the vector database for a target vector that satisfies a preset similarity condition with the vector to be detected includes: The similarities between each vector in the vector database and the vector to be detected are calculated respectively, and the first K vectors are determined as target vectors in descending order of the similarities, where K is a positive integer.

4. The method according to claim 3, characterized in that: After determining the first K vectors as target vectors in descending order of similarity, the method further includes: Comparing the target similarity between each target vector and the vector to be detected with a preset similarity threshold; If there is at least one target similarity greater than or equal to the preset similarity threshold, it is determined that there is a SQL injection attack in the target access request, and a corresponding attack confirmation result is generated in the query result; If the similarities of each target are less than the preset similarity threshold, it is determined that there is no SQL injection attack in the target access request, and a corresponding security result is generated in the query result.

5. The method according to claim 1, characterized in that The method further comprises: In response to an attack statement collection request triggered by at least one sample access request, extracting original attack statements in each sample access request through a large language model; Data cleaning is performed on each original attack statement to obtain at least one attack statement for executing the SQL injection attack.

6. The method according to claim 5, characterized in that After performing data cleaning on each original attack statement to obtain an attack statement for executing the SQL injection attack, the method further includes: Each attack statement is vectorized according to a preset vector model to obtain a vector corresponding to each attack statement, and the vector is stored in a vector database. The vector model is also used to generate a vector to be detected for the attack statement to be detected.

7. The method according to claim 1, characterized in that The method further comprises: In response to an attack statement upload request triggered by a user for an attack statement to be uploaded, a vector to be uploaded corresponding to the attack statement to be uploaded is generated, and the vector to be uploaded and a mapping relationship between the vector to be uploaded and the attack statement to be uploaded are stored in a vector database.

8. A database risk detection device, characterized in that: The device comprises: A vector generation module, used to respond to a database risk detection request triggered by a target access request, extract an attack statement to be detected in the target access request through a large language model, and generate a vector to be detected for the attack statement to be detected; A vector query module, used to query a target vector that meets a preset similarity condition with the vector to be detected in a vector database, and determine a target attack statement corresponding to the target vector, wherein the vector database stores at least one vector corresponding to an attack statement for executing an SQL injection attack and a mapping relationship between each attack statement and a corresponding vector; The result generating module is used to generate a query result corresponding to the target access request, wherein the query result includes the target attack statement.

9. A computer storage medium, characterized in that The computer storage medium stores a plurality of instructions, and the instructions are suitable for being loaded by a processor and executing the steps of the method according to any one of claims 1 to 7.

10. A terminal, characterized in that: The method comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method according to any one of claims 1 to 7 when executing the program.

Images