SQL (Structured Query Language) injection detection method and device, equipment and storage medium

Abstract

The invention discloses an SQL (Structured Query Language) injection detection method and device, equipment and a storage medium. The method comprises the steps of obtaining a to-be-detected SQL statement; and for a target execution stage in the SQL statement execution process where the to-be-detected SQL statement is located, performing injection detection on the to-be-detected SQL statement in the target execution stage by adopting a target tangent matched with the target execution stage to obtain an injection detection result. According to the technical scheme, in the target execution stage in the SQL statement execution process where the to-be-detected SQL statement is located, the target tangent plane matched with the target execution stage is adopted to conduct injection detection on the to-be-detected SQL statement in the target execution stage, and therefore the injection detection result is obtained; the detection precision and the detection efficiency of the complex SQL injection attack can be obviously improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of database security, and in particular to a SQL injection detection method, device, equipment and storage medium. BACKGROUND

[0002] SQL injection attack is an attack method against databases. Attackers insert or "inject" SQL code into input fields of an application program, trying to manipulate the backend database server to execute unexpected commands. This attack takes advantage of the lack of user input validation in the application program, thereby bypassing normal security controls and achieving unauthorized access and operation of the database. By maliciously constructing input parameters to tamper with the logic of SQL statements, unauthorized access to the database is implemented. With the widespread popularity of web applications, the risk of SQL injection attacks is gradually increasing. Existing SQL injection defense methods mainly rely on input validation, parameterized queries, WAF and static detection technologies, but still have universal defects: the protection methods often require system modification and affect performance, real-time dynamic detection is difficult to achieve, compatibility between new and old systems is poor, overall protection efficiency and system running efficiency are difficult to balance, detection accuracy and efficiency are extremely low. Therefore, a SQL injection detection method is urgently needed to solve the above technical problems. SUMMARY

[0003] Therefore, the present application provides a SQL injection detection method, device, equipment and storage medium, which can significantly improve the detection accuracy and efficiency of complex SQL injection attacks.

[0004] According to an aspect of the present application, the present application embodiment provides a SQL injection detection method, the method comprising:

[0005] obtaining a to-be-detected SQL statement;

[0006] For a target execution stage in a SQL statement execution process in which the to-be-detected SQL statement is located, a target aspect matched with the target execution stage is used to perform injection detection on the to-be-detected SQL statement in the target execution stage, to obtain an injection detection result.

[0007] According to another aspect of the present application, the present application embodiment further provides a SQL injection detection device, the device comprising:

[0008] a statement acquisition module configured to obtain a to-be-detected SQL statement;

[0009] The injection detection module is configured to perform injection detection on the to-be-detected SQL statement in a target execution stage in an SQL statement execution flow of the to-be-detected SQL statement by using a target aspect matched with the target execution stage, and obtain an injection detection result.

[0010] According to another aspect of the present application, an electronic device is also provided, which comprises:

[0011] at least one processor; and

[0012] a memory in communication with the at least one processor; wherein

[0013] the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the SQL injection detection method according to any one of the embodiments of the present application.

[0014] According to another aspect of the present application, a computer readable storage medium is also provided, which stores computer instructions for enabling a processor to perform the SQL injection detection method according to any one of the embodiments of the present application.

[0015] According to another aspect of the present application, a computer program product is also provided, which comprises a computer program, and the computer program, when executed by a processor, implements the SQL injection detection method according to any one of the embodiments of the present application.

[0016] The technical effect of the present application is that, by performing injection detection on the to-be-detected SQL statement in a target execution stage in an SQL statement execution flow of the to-be-detected SQL statement by using a target aspect matched with the target execution stage, an injection detection result is obtained, which can significantly improve the detection accuracy and efficiency of complex SQL injection attacks.

[0017] It should be understood that the content described in this part is not intended to identify key or important features of the embodiments of the present application, nor to limit the scope of the present application. Other features of the present application will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative effort.

[0019] Figure 1 A flow chart of a SQL injection detection method provided by an embodiment of the present application is shown in FIG. 1.

[0020] Figure 2 Another flow chart of a SQL injection detection method provided by an embodiment of the present application is shown in FIG. 2.

[0021] Figure 3 An architecture diagram of an embedded mode operation provided by an embodiment of the present application is shown in FIG. 3.

[0022] Figure 4 An architecture diagram of a proxy mode operation provided by an embodiment of the present application is shown in FIG. 4.

[0023] Figure 5 A general operation flow chart of a SQL injection attack protection instance in an embedded mode provided by an embodiment of the present application is shown in FIG. 5.

[0024] Figure 6 A general operation flow chart of a SQL injection attack protection instance in a proxy mode provided by an embodiment of the present application is shown in FIG. 6.

[0025] Figure 7 Another flow chart of a SQL injection detection method provided by an embodiment of the present application is shown in FIG. 7.

[0026] Figure 8 A flow chart of a SQL injection detection method using an aspect in a SQL statement execution flow provided by an embodiment of the present application is shown in FIG. 8.

[0027] Figure 9 A general architecture diagram of a SQL injection detection method provided by an embodiment of the present application is shown in FIG. 9.

[0028] Figure 10 A structure block diagram of a SQL injection detection device provided by an embodiment of the present application is shown in FIG. 10.

[0029] Figure 11 A structure diagram of an electronic device provided by an embodiment of the present application is shown in FIG. 11. DETAILED DESCRIPTION

[0030] In order to make the personnel in the art better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should belong to the scope of protection of the present application.

[0031] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and in the above drawings are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not have to be limited to only those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0032] In an embodiment, Figure 1 A flowchart of a SQL injection detection method provided for an embodiment of the present application, the embodiment can be applicable to the case of injection detection and protection when accessing a database with a SQL statement. The method can be executed by a SQL injection detection device, which can be realized in the form of hardware and / or software, and can be configured in an electronic device.

[0033] As Figure 1 shown, the SQL injection detection method in the embodiment specifically includes the following steps:

[0034] S110, obtaining a to-be-detected SQL statement.

[0035] The to-be-detected SQL statement is a statement that may exist SQL injection attack. The to-be-detected SQL statement can be one to-be-detected SQL statement or multiple to-be-detected SQL statements. It can be understood that one or more to-be-detected SQL statements can be detected simultaneously.

[0036] In the embodiment, one or more to-be-detected SQL statements corresponding to accessing a database are obtained in the process of accessing the database by a user terminal. In the execution process of accessing the database by the user terminal, the SQL statement usually goes through five stages, which can include a connection stage, an object construction stage, a SQL statement execution stage, an execution result processing stage of the SQL statement, and a resource release stage. The to-be-detected SQL statement needs to be obtained before the connection stage or the object construction stage.

[0037] S120, for a target execution stage in a SQL statement execution flow in which the to-be-detected SQL statement is located, using a target aspect matched with the target execution stage to perform injection detection on the to-be-detected SQL statement in the target execution stage, to obtain an injection detection result.

[0038] The target execution stage includes an object construction stage corresponding to the to-be-detected SQL statement and a statement execution stage. The object construction stage can include construction of a PreparedStatement or a Statement object. The statement execution stage is a stage of sending the SQL statement to the database through different execute methods, such as an executeQuery method, an executeUpdate method, and the like, and obtaining a result.

[0039] In this embodiment, the target aspect includes a tagging heterogeneous aspect and a label verification aspect. The object construction stage in the target execution stage can be matched with the tagging heterogeneous aspect in the target aspect, and the statement execution stage can be matched with the label verification aspect. It can be understood that the to-be-detected SQL statement in the object construction stage can be subjected to corresponding tagging operation processing by using the tagging heterogeneous aspect, and the to-be-detected SQL statement in the statement execution stage can be subjected to corresponding label verification processing by using the label verification aspect. It should be noted that the target aspect is a target aspect pre-constructed by AOP (Aspect-Oriented Programming, aspect-oriented programming). In this embodiment, AOP is a programming paradigm that aims to separate cross-cutting concerns from business logic and manage them uniformly in the form of an aspect. The target aspect is similar to a rule module that specifies the functions of different aspects and the timing or stage at which to intercept to execute the corresponding aspect functions.

[0040] In this embodiment, since the to-be-detected SQL statement is in each stage of the SQL statement execution flow, the SQL statement execution flow includes the connection stage, the object construction stage, the SQL statement execution stage, the execution result processing stage of the SQL statement, and the resource release stage, as described in the above embodiment. For different execution stages of the to-be-detected SQL statement, at least two target aspects pre-constructed can be used to perform injection detection and protection on the to-be-detected SQL statement in different execution stages. Since different target execution stages correspond to different target aspects, in the target execution stage of the SQL statement execution flow in which the to-be-detected SQL statement is located, a target aspect matched with the target execution stage is used to perform injection detection on the to-be-detected SQL statement in the target execution stage to obtain an injection detection result.

[0041] In the embodiment, the injection detection result is whether the SQL exists an injection attack. When the SQL injection detection is performed, the SQL statement to be detected may exist an SQL injection attack behavior or may not exist an SQL injection attack behavior. In the embodiment, when the SQL injection attack exists, an attacker inserts or "injects" an SQL code into an input field of an application maliciously, attempts to manipulate a backend database server to execute an unexpected command, bypasses normal security control measures, and realizes illegal access and operation on the database. At this time, there is a great risk. In order to prevent the attacker from bypassing the defense measures, the SQL statement to be detected needs to be detected.

[0042] In the embodiment, when the SQL injection detection is performed, the key words in the SQL statement to be detected can be dynamically added with labels by the labeled heterogeneous aspect in the object construction stage, so as to obtain corresponding label information. Based on this, the label information of the SQL statement to be detected to which the label information is added is checked by the label checking aspect in the SQL statement execution stage. Therefore, according to the checking result, it is determined whether the SQL injection behavior exists in the SQL statement to be detected in the target execution stage. In some embodiments, when the SQL statement accesses the database, URL analysis can be performed by crawling a URL address, and WAF identification can be performed on a website involved in the URL. Therefore, a feature processing plug-in is found according to the identification result, and the SQL injection detection is performed by the feature processing plug-in. In another embodiment, an initial SQL injection judgment statement of a user COOKIE value (data stored on a local terminal of the user) can be formed, the COOKIE value submitted by the user is intercepted and modified, and a final SQL injection judgment statement is generated by modifying the COOKIE value of the user. Therefore, the SQL injection detection is performed by the final SQL injection judgment statement. Of course, the SQL injection detection can also be performed by other manners, which is not limited in the embodiment.

[0043] The technical scheme of the embodiment of the application can detect the SQL injection attack in the target execution stage of the SQL statement execution flow of the SQL statement to be detected by using the target aspect matched with the target execution stage to detect the SQL injection attack of the SQL statement to be detected in the target execution stage, so as to obtain the injection detection result. The detection precision and the detection efficiency of the complex SQL injection attack can be significantly improved.

[0044] In an embodiment, the method further comprises:

[0045] In the life cycle of the SQL statement to be detected, the key data in the life cycle is recorded and stored in the form of a log for vulnerability analysis.

[0046] The key data at least includes: a to-be-detected SQL statement without adding target label information, a to-be-detected SQL statement after adding target label information, a SQL execution statement submitted to a target database, label generation time corresponding to each to-be-detected SQL, a label check result, and abnormal information corresponding to the label check result.

[0047] In the embodiment, the life cycle of the to-be-detected SQL statement includes a connection phase of accessing the database by the to-be-detected SQL statement, label addition in an object construction phase, label check and label destruction in a statement execution phase, and the entire process of the SQL execution statement submitted to the target database in the case of passing the label check.

[0048] In the embodiment, during the life cycle of the to-be-detected SQL statement, various information such as a record unprocessed SQL statement in the life cycle, a to-be-detected SQL statement after adding target label information, and a SQL statement finally submitted to the database is recorded, and key data is stored in the form of a log, which can be output to a file in a standard JSON format and support external system calling and analysis. For example, in a SQL injection attack, a boundary device (WAF, etc.) can only see request information, but the complete SQL statement recorded in the life cycle in the embodiment can provide a basis for advanced vulnerability analysis if the SQL injection causes a syntax error or other abnormal information of the server.

[0049] In an embodiment, the method further includes:

[0050] The target label information in each thread is managed by using a Thread Local tool class of Java.

[0051] The target label information in each thread is managed by using a Thread Local tool class of Java.

[0052] In the embodiment, in the object construction phase, each to-be-detected SQL statement adds corresponding target label information by using the labeled heterogeneous aspect, and because there are multiple target label information corresponding to the to-be-detected SQL statements, in order to facilitate the isolation of each thread and ensure label consistency, the target label information in each thread can be managed by using a Thread Local tool class of Java. In the embodiment, the Thread Local tool class is a class for creating thread local variables in Java, which provides a space-time trade-off way to solve thread safety problems. Through ThreadLocal, each thread has its own independent variable copy, thereby avoiding competition and blocking between threads and improving concurrent performance.

[0053] In an embodiment,Figure 2 Another SQL injection detection flow diagram provided by an embodiment of the application is shown in the figure. Based on the above embodiments, after the SQL injection detection method obtains the injection detection result, the target execution stage in the SQL statement execution flow and the target aspect matched with the target execution stage can be encapsulated to obtain the corresponding portable file, and the target deployment mode corresponding to the portable file is determined based on the application scenario.

[0054] As shown in the figure, the SQL injection detection method in the embodiment can specifically include the following steps: Figure 2

[0055] S210, obtaining a to-be-detected SQL statement.

[0056] S220, for the target execution stage in the SQL statement execution flow where the to-be-detected SQL statement is located, using the target aspect matched with the target execution stage to perform injection detection on the to-be-detected SQL statement in the target execution stage to obtain an injection detection result.

[0057] S230, encapsulating the target execution stage in the SQL statement execution flow and the target aspect matched with the target execution stage to obtain a corresponding portable file.

[0058] The portable file can be understood as a JAR package executable file or an EXE file and various forms of executable files. The JAR package is a compression file format for packaging multiple Java class files and their related resources (such as images, configuration files, texts, etc.) together. Its main function is to integrate multiple files of a Java application into one file for distribution, execution, storage and transmission, which can be directly loaded and run by JVM, and is usually used to encapsulate Java applications or Java class libraries.

[0059] In the embodiment, the target execution stage in the SQL statement execution flow and the target aspect matched with the target execution stage can be encapsulated into a JAR package in the form of an executable file using a preset programming language. The JAR package is deployed in different modes according to different scenarios, so that the deployed JAR package can be used for SQL injection detection and protection in different modes.

[0060] S240, determining the target deployment mode corresponding to the portable file based on the application scenario; wherein the target deployment mode includes an embedded mode and a proxy mode.

[0061] The application scenario can include a scenario requirement where the operation source code of the user terminal accessing the target database can be obtained, and a scenario requirement where the operation source code of the user terminal accessing the target database cannot be obtained. ​

[0062] In the embodiment, whether the portable file is in the embedded mode or the proxy mode can be determined according to different scenarios in which the operation source code can be acquired. If the operation source code of the user terminal accessing the target database can be acquired, the embedded mode is adopted; if the operation source code of the user terminal accessing the target database cannot be acquired, the proxy mode is adopted. It can be understood that, in the embodiment, the embedded mode needs to modify the original application program and embed it; the proxy mode does not need to modify the original application program and directly intercepts and enhances the behavior of the JDBC connection.

[0063] In an embodiment, the target deployment mode corresponding to the portable file is determined according to the application scenario, including: in the case where the operation source code of the user terminal accessing the target database is acquired, the target deployment mode is determined as the embedded mode, and the portable file is introduced into the operation source code in the form of a lib package file; in the case where the operation source code of the user terminal accessing the target database is not acquired, the target deployment mode is determined as the proxy mode, and the portable file is operated as an independent project through the proxy mechanism.

[0064] It can be understood that the embedded mode is suitable for the scenario in which the operation source code can be acquired. In the development stage, the user can directly introduce the present solution into the application program in the form of a lib package file, and realize seamless integration of dynamic tagging and detection logic through the AOP mechanism. The lib package is a directory for storing library files in Java, and the library files in the directory are usually Java class files (.class files) or Java archive files (.jar files) that have been compiled. They contain some commonly used classes, methods and functions, which can be referenced and used by other Java programs. In the embodiment, the proxy mode is suitable for the scenario in which the program is running or the source code cannot be acquired. The proxy mechanism of the Java Agent is used to dynamically inject the interception logic into the target application program. The proxy mode does not need to modify the original application program, directly intercepts and enhances the behavior of the JDBC connection, and thus realizes real-time detection and protection of SQL injection attacks.

[0065] S250, deploying the portable file according to the target deployment mode, so as to use the portable file to perform injection detection on the acquired SQL statement to be detected.

[0066] In the embodiment, the portable file can be deployed into the corresponding application software or the running environment according to the target deployment mode, and the deployed portable file is used to perform injection detection on the acquired SQL statement to be detected.

[0067] The technical solution in the embodiment can meet diversified application scene requirements by having both source code direct integration (embedded mode) and Java Agent dynamic injection (proxy mode) flexible configurations, and can provide comprehensive support for deep integration and flexible deployment.

[0068] For better understanding of the specific detection logic under the embedded mode and the proxy mode, Figure 3 An embedded mode running architecture schematic diagram is provided for an embodiment of the application, Figure 4 An embedded mode running architecture schematic diagram is provided for an embodiment of the application, for better understanding of the SQL injection attack protection instance under the embedded mode, and the SQL injection attack protection instance under the proxy mode, Figure 5 An embedded mode running architecture schematic diagram is provided for an embodiment of the application, Figure 6 An embedded mode running architecture schematic diagram is provided for an embodiment of the application.

[0069] As shown in Figure 3 The embedded mode is suitable for scenarios in which source code can be operated. The user can directly introduce the scheme in the form of a lib package file into the application, and realize seamless integration of dynamic tagging and detection logic through the AOP mechanism. As shown in Figure 5 Under the embedded mode, the first step is to install the dependency, that is, to introduce the Jar package executable file packaged by the method as the project dependency in the application, and to test through starting the project to ensure that the project has successfully loaded the Jar package. This step includes the following steps:

[0070] a1, Jar package introduction. The construction tool used is Maven, and first, the pom.xml file needs to be modified, and <dependencies>Add dependency information in the tag and copy the Jar package file to the corresponding directory of the local maven repository. If the project itself does not use Maven for dependency management, similar methods can be used for dependency introduction, such as the original Java project, which can be added to the lib library through the configuration of Project Settings->Libararies, and the Jar package can be successfully loaded when the project starts.

[0071] a2, start the test. After refreshing the project, start and check the start log to ensure that the Jar package has been successfully loaded.

[0072] The second step is to load the protection measures. This step will load the core injection detection aspect code and apply it to the project. The specific steps are as follows:

[0073] b1, configuration file parsing. Since the Java project in this embodiment is based on the Mybatis framework to realize interaction with the database, the project's own configuration file will be loaded first when Mybatis is initialized (the configuration file mybatis-config.xml is parsed through the build method of SqlSessionFactoryBuilder).

[0074] b2, interceptor instantiation. Load the interceptor information in the encapsulated package SQL-agent JAR package, and instantiate two interceptors through reflection (this is the specific implementation of the two aspects in the scheme description in this scenario).

[0075] b3, interceptor construction. MyBatis will put all the instantiated and configured interceptors into an interceptor chain (InterceptorChain). The interceptor chain is an implementation of the responsibility chain pattern, which allows multiple interceptors to be executed in order. Through this step, the execution order of the two interceptors is controlled to ensure the normal operation of the protection measures.

[0076] b4, interceptor application. When Mybatis executes SQL statements, it will pass through the interceptor chain to deliver the request. Therefore, when a SQL injection attack occurs, the SQL statement carrying the attack information will be intercepted and processed by the interceptor written through the chain, and the attack will be blocked. Take a precompiled SQL injection attack as an example. This attack mainly uses the precompiled feature of the Mybatis framework, which can perform semantic analysis deception on multiple protection methods and ultimately bypass the protection, but through the deployed JAR package, it can be successfully identified and blocked by the protection measures.

[0077] The third step is to comprehensively test the deployed Jar package program to ensure that its function and performance meet the expectations, which can include:

[0078] c1, Functionality testing: Through regression testing, verify whether the Jar package program can correctly perform its intended functions. Especially for critical functions, more rigorous testing is required to ensure that it does not affect normal operation.

[0079] c2, Performance testing: Although security is the primary consideration, performance is also an important measure in some scenarios. Through performance benchmarking, determine the running efficiency of the program in different scenarios, and optimize the tag algorithm according to the test results.

[0080] c3, Security verification: Use static analysis tools and dynamic testing tools to verify the security of the program. By simulating attack scenarios, verify the effectiveness of the protection measures. For example, you can use test scripts, Postman, Burp Suite and other tools to simulate various types of SQL injection attacks, and observe whether the protection measures can successfully defend against these attacks.

[0081] As shown in Figure 4 , the proxy mode: suitable for scenarios where the program is running or the source code cannot be obtained. This solution dynamically injects interception logic into the target application program through the proxy mechanism of Java Agent. The proxy mode does not require any modification to the original application program, directly intercepts and enhances the behavior of JDBC connection, thereby realizing real-time detection and protection against SQL injection attacks. As shown in Figure 6 , in the proxy mode, for websites that cannot obtain source code or are already running, this embodiment applies the detection and protection method based on the proxy mode supported by this method. When using the proxy mode, no source code-level modification is required for the source program. Only the startup command needs to be modified to load the Agent proxy program packaged by this method. This embodiment will directly describe the packaged WAR package example project (also containing SQL execution scenarios) in detail.

[0082] The first step is to configure the run, that is, when starting the Java application program, specify the path of the Agent JAR file through the command line parameter -javaagent. If the application program itself is a JAR package, the startup command can be modified directly. In this embodiment, the application program of the proxy is a WAR package, so the startup command of the Tomcat container it depends on needs to be modified. After the configuration is completed, the application can be started, and the running log is checked to confirm whether the proxy program has been successfully loaded.

[0083] The second step is to load the protection measures, since the proxy mode is used at this time, the core logic is implemented in the Agent proxy program, and the main steps are as follows:

[0084] d1, Aspect instantiation. By defining and instantiating two intercepting aspects in the premain method of the Agent agent program, the two core stages of the application's processing of SQL statements are intercepted.

[0085] d2, Strategy loading. Using the Advice aspect, the corresponding protection logic is injected into the two intercepting aspects. This step uses the bytecode manipulation library to manipulate the bytecode of the proxied application class to insert proxy logic.

[0086] d3, Attack protection. When the example project is started, the protection strategies in the Agent agent program are also loaded. When the source program is subjected to a SQL injection attack, the Agent agent program will intercept the SQL execution process and apply the protection algorithm to block the attack, achieving protection for the proxied program. Similarly, using the precompiled injection attack as an example, the attack request is successfully identified and blocked by the protection measures. Like the embedded mode, the proxy mode can also handle some scenarios that traditional methods cannot defend against, and is more flexible in use scenarios, greatly simplifying the steps.

[0087] The third step is to conduct a comprehensive test of the program to ensure that its functionality and performance meet expectations, which can include:

[0088] e1, Functionality testing: Through regression testing, verify whether the program can correctly perform its intended functions. In particular, for critical function modules, more rigorous testing is required to ensure that the method does not affect the normal operation of the program.

[0089] e2, Performance testing: Although security is the primary consideration, performance is also an important measure in some scenarios. Through performance benchmarking, determine the running efficiency of the program in different scenarios, and optimize the tag algorithm based on the test results.

[0090] e3, Security verification: Use static analysis tools and dynamic testing tools to verify the security of the program. By simulating attack scenarios, verify the effectiveness of the protection measures. For example, you can use tools such as test scripts, Postman, Burp Suite, etc. to simulate various types of SQL injection attacks and observe whether the protection measures can successfully defend against these attacks.

[0091] e4, Exception verification: Since the Agent agent runs independently of the source program, exception verification is required to prevent Agent crashes from affecting the source program. This is usually done from network exceptions, system resource exceptions, configuration exceptions, etc., and appropriate fault tolerance mechanisms are added.

[0092] In an embodiment, Figure 7 A flowchart of another SQL injection detection method provided by an embodiment of the present application is shown in FIG. 7. The embodiment is based on the above-mentioned embodiments, and further refines the injection detection result by performing injection detection on the target execution stage of the SQL statement execution flow of the to-be-detected SQL statement using a target aspect that matches the target execution stage.

[0093] As shown in FIG. 7, the SQL injection detection method in the embodiment can include the following steps: Figure 7

[0094] S710, obtaining a to-be-detected SQL statement.

[0095] S720, in the object construction stage, dynamically adding a label to a sensitive keyword in the to-be-detected SQL statement using a labeled heterogeneous aspect to obtain corresponding label information, so as to form a corresponding heterogeneous SQL statement.

[0096] The labeled heterogeneous aspect can be understood as an aspect that adds different labels to sensitive keywords in each to-be-detected SQL statement. The sensitive keyword can be understood as a default keyword that constitutes the SQL syntax. For example, in a select statement, select and from in select from a list are sensitive keywords.

[0097] In the embodiment, in the object construction stage of the SQL statement execution flow in which the to-be-detected SQL statement is located, the labeled heterogeneous aspect is used to intercept the construction process of the PreparedStatement or Statement object. First, the sensitive keywords in the to-be-detected SQL statement are identified, and the identified sensitive keywords are matched. If a match is found, the matched sensitive keywords are dynamically labeled to form corresponding label information. The addition of the label information forms the corresponding heterogeneous SQL statement. In the embodiment, the sensitive keywords include SQL default keywords such as SELECT, INSERT, UPDATE, and DELETE, and can also include sensitive words that are often contained in actual attack requests as templates.

[0098] In an embodiment, S720 can include S7201 to S7204.

[0099] S7201, identifying the sensitive keywords respectively corresponding to each to-be-detected SQL statement.

[0100] ​In the embodiment, the corresponding sensitive keywords are first identified from the to-be-detected SQL statements. There can be multiple sensitive keywords in one to-be-detected SQL statement, and each to-be-detected SQL statement corresponds to one or more sensitive keywords. The corresponding label information is different for different to-be-detected SQL statements, which can be understood as that each to-be-detected SQL statement corresponds to unique label information; the corresponding label information is the same for different sensitive keywords in the same to-be-detected SQL statement. For example, two sensitive keywords are identified in the first to-be-detected SQL statement, and the corresponding label information of the two sensitive keywords is the same; three sensitive keywords are identified in the second to-be-detected SQL statement, and the corresponding label information of the three sensitive keywords is the same, but the label information corresponding to each to-be-detected SQL statement is unique, that is, the label information corresponding to the two sensitive keywords in the first to-be-detected SQL statement is different from the label information corresponding to the three sensitive keywords in the second to-be-detected SQL statement.

[0101] S7202, for the respective sensitive keywords corresponding to each to-be-detected SQL statement, the sensitive keywords are matched with the keywords contained in the preset keyword list.

[0102] The preset keyword list is a list of a set of related sensitive keywords set in advance according to requirements, and the keyword list includes multiple sensitive keywords.

[0103] In the embodiment, one or more sensitive keywords respectively identified in each to-be-detected SQL statement are matched with the keywords set in advance in the preset keyword list. If the identified sensitive keywords can be found in the preset keyword list, the corresponding label information corresponding to the sensitive keywords can be generated by the corresponding label generation algorithm, and the label information and the sensitive keywords are bound. Of course, if there is no match, the unmatched sensitive keywords are discarded.

[0104] S7203, in the case of matching, the corresponding target label information of the sensitive keywords respectively contained in each to-be-detected SQL statement is dynamically generated based on the preset label generation algorithm, the target label information is bound to the corresponding to-be-detected SQL statement, and the to-be-detected SQL statement and the corresponding target label information are stored in the preset label library.

[0105] The target label information can be understood as the label information added by the sensitive keywords in the to-be-detected SQL statement. The sensitive keywords contained in the same to-be-detected SQL statement correspond to the same unique label information. The sensitive keywords contained in different to-be-detected SQL statements correspond to different target label information.

[0106] In this embodiment, the preset label generation algorithm can include SHA-256 hash, universally unique identifier (UUID), Base64, and unique identification generation algorithm based on timestamp, and the like. Among them, SHA-256 is an algorithm in the SHA-2 hash function family, which outputs a fixed-length hash value of 256 bits through calculation. UUID is a 128-bit identifier, which is usually represented by 32 hexadecimal digits, used for object identification in networks or databases, unique identification information or resources in distributed computing environments, and unique file name generation scenarios. Base64 is an encoding method based on 64 printable characters to represent binary data, commonly used in situations where text data needs to be processed, and is also one of the most common encoding methods for transmitting 8-bit byte codes on the network.

[0107] In this embodiment, if the sensitive keywords can match the keywords contained in the preset keyword list, the corresponding target label information of the sensitive keywords contained in each to-be-detected SQL statement can be dynamically generated by using SHA-256 hash, universally unique identifier (UUID), and unique identification generation algorithm based on timestamp, the target label information is bound to the corresponding to-be-detected SQL statement, and the to-be-detected SQL statement and the corresponding target label information are stored in the preset label library. It can be understood that a unique label is dynamically generated for the keywords of each to-be-detected SQL statement to ensure that the label is bound to the SQL context.

[0108] S7204, in the case of not matching, the unmatched sensitive keywords are discarded.

[0109] In this embodiment, if the sensitive keywords do not match the keywords contained in the preset keyword list, the unmatched sensitive keywords are discarded.

[0110] S730, in the statement execution phase, the labeled heterogeneous SQL statement is checked by using the label verification aspect, and whether the to-be-detected SQL statement in the target execution phase exists SQL injection behavior is determined according to the result of the check.

[0111] In the embodiment, the statement execution stage is the SQL statement execute stage. Under normal circumstances, in the stage, different execute methods, such as the executeQuery, executeUpdate and the like, can be used to send SQL statements to a database and obtain results. In the embodiment, the statement execution stage is intercepted by the label checking aspect, and before the execution of the statement execution stage, the label checking aspect performs label checking on the target label information of the heterogeneous SQL statement added in the object construction stage, so that it is determined whether the to-be-detected SQL statement in the statement execution stage has the SQL injection behavior according to the label checking result.

[0112] In an embodiment, S730 can include S7301 to S7304.

[0113] S7301, obtaining the target label information bound by each heterogeneous SQL statement during the object construction stage label generation from a preset label library.

[0114] The preset label library is used to store the label information dynamically added by the sensitive keywords in the to-be-detected SQL statement in the object construction stage.

[0115] In the embodiment, in the statement execution stage, the target label information bound by each heterogeneous SQL statement during the object construction stage label generation is obtained from the preset label library.

[0116] S7302, obtaining the current label information bound by each heterogeneous SQL statement, comparing the target label information with the current label information to obtain a comparison result, and taking the comparison result as a checking result.

[0117] The current label information refers to the current label information bound by each heterogeneous SQL statement in the statement execution stage. Since the current label information can be tampered, the target label information bound by each to-be-detected SQL statement during the object construction stage label generation is compared with the current label information, so that it can be known whether the tampering occurs.

[0118] In the embodiment, in the statement execution stage, the current label information bound by each to-be-detected SQL statement is obtained, and the current label information is compared with the target label information bound by each heterogeneous SQL statement during the object construction stage label generation. If the label information of the two is consistent, it is determined that the label checking passes, indicating that there is no SQL injection behavior. If the label information of the two is inconsistent, it is determined that the label checking does not pass, indicating that there is the SQL injection behavior.

[0119] S7303, if the result of the verification is consistent, it is determined that the label verification is passed, and the target label information bound by the heterogeneous SQL statement is removed before the statement execution of the heterogeneous SQL statement.

[0120] In the embodiment, if the current label information is consistent with the target label information bound by each heterogeneous SQL statement when the label is generated in the object construction stage, the label verification is passed, there is no SQL injection attack behavior, and the subsequent statement execute can be performed, the SQL statement is sent to the database and the result is obtained. It should be noted that in the embodiment, the target label information bound by the heterogeneous SQL statement is removed before the statement execute of the heterogeneous SQL statement, so as to ensure that the SQL statement content is consistent with the original input. It can be understood that the bound label is destroyed before the statement execute, and the cracking difficulty is increased.

[0121] S7304, if the result of the verification is inconsistent, it is determined that the label verification is not passed, and the heterogeneous SQL statement that fails the verification is determined as a statement of potential SQL injection behavior.

[0122] In the embodiment, if the current label information is consistent with the target label information bound by each heterogeneous SQL statement when the label is generated in the object construction stage, it is determined that the label verification is not passed, there is a SQL injection attack behavior, and the heterogeneous SQL statement that fails the verification is determined as a statement of potential SQL injection behavior.

[0123] The above technical solution in the embodiment adds a label to the sensitive keyword in the to-be-detected SQL statement in the object construction stage by using the labeled heterogeneous aspect, adds the label information in real time, checks the label information of the to-be-detected SQL statement by using the label verification aspect in the statement execution stage, and determines whether the to-be-detected SQL statement in the target execution stage has a SQL injection behavior according to the result of the checking, so as to realize the label heterogeneous processing of the SQL statement. This process strictly follows the principle of "one label one use", greatly enhances the complexity and difficulty of the cracking attempt, does not interfere with the normal interaction between the application program and the database, and further improves the detection accuracy and detection efficiency of the complex SQL injection attack.

[0124] In one embodiment, in order to facilitate a better understanding of the processing flow of the SQL injection detection method and the binding of the SQL execution process in JDBC (Java DataBase Connectivity, using the Java language to operate the database), this embodiment first describes the execution flow, and dynamically adds tags to SQL keywords in the Statement construction phase (phase 2) of the normal execution process to realize SQL statement isomerization (aspect 1), and verifies and clears the tags in the SQL execution phase (phase 3) (aspect 2), and then performs the normal SQL statement execution phase, result processing phase and resource release phase. Figure 8 A schematic diagram of a process for using aspects to perform injection detection in a SQL statement execution process is provided in accordance with an embodiment of the present invention.

[0125] In this embodiment, the heterogeneous stage: intercepts the Statement construction process, first identifies and matches the sensitive keywords in the SQL statement, and if a match is found, dynamically adds a unique label to each keyword to achieve labeled heterogeneity of the SQL statement.

[0126] In this embodiment, the verification phase intercepts the execute method before the SQL statement is executed and compares the tags in the SQL statement with the target tag information bound to each SQL statement to be tested when the tags were generated during the object construction phase. If the tag is missing or tampered with, it is determined to be a potential SQL injection behavior. If the verification passes, the tag is removed before execution to ensure that the SQL statement content is consistent with the original input.

[0127] like Figure 8 As shown, during the execution of the JDBC source code, the SQL statement of the normal SQL statement execution process in the prior art usually goes through the following main stages:

[0128] f1. Connection phase: The first step in a Java program interacting with a database using JDBC. This involves loading the appropriate JDBC driver and establishing a connection to the database. This step requires providing the database URL (Uniform Resource Locator), username, and password.

[0129] f2. Statement Construction Phase: Constructing a PreparedStatement or Statement object. Typically, PreparedStatement objects are most commonly constructed in website applications. Once a SQL statement is precompiled, it is stored in a PreparedStatement object. This precompiled SQL statement can then be efficiently executed multiple times without recompiling each time. This significantly improves SQL statement execution efficiency.

[0130] f3, SQL statement execution phase: send SQL statements to the database through different execute methods, such as executeQuery, executeUpdate, etc., and get the results.

[0131] f4, result processing phase: process the execution results of the SQL statement. For example, for a query statement, a ResultSet object containing the query results is returned after execution, and then the result set can be traversed in the Java program to obtain specific data.

[0132] f5, resource release phase: this phase is the last phase of the execution process, used to close the ResultSet, Statement and Connection objects to release database resources, thereby preventing resource leakage.

[0133] In an embodiment, in order to better understand the overall architecture of the SQL injection detection method, Figure 9 An overall architecture diagram of a SQL injection detection method is provided for an embodiment of the present application. As shown in Figure 9 SQL protection: in the key stages of the Statement construction phase and the statement execution phase of SQL, heterogeneous SQL statements are realized by dynamically adding tags and tag verification, which covers the attack scene while ensuring the transparency of interaction with the database. Tag management: in the key stages of the Statement construction phase and the statement execution phase of SQL, unique tags are generated by presetting the tag algorithm, and after the subsequent tag verification is passed, the tags are removed before the statement execution, the tags are destroyed, and the tags are passed in the thread to ensure the consistency of the tags in the concurrent scene. Scene adaptation: according to the scene parameters, the corresponding class files are automatically loaded and the project is packaged, which supports source integration packaging and Agent agent packaging respectively, corresponding to two running modes. Log storage: record the key data in the life cycle, and store the key data in the form of logs for vulnerability analysis. The information transmission relationship can be described as shown in Table 1.

[0134] Table 1: Information relationship description

[0135]

[0136] In an embodiment, Figure 10 A structure block diagram of a SQL injection detection device is provided for an embodiment of the present application. The system is suitable for the case of injection detection and protection when accessing the database through SQL statements. The device can be realized by hardware / software. It can be configured in an electronic device to realize a SQL injection detection method in an embodiment of the present application.

[0137] As Figure 10 The device comprises a statement acquisition module 1010 and an injection detection module 1020.

[0138] The statement acquisition module 1010 is configured to acquire a to-be-detected SQL statement.

[0139] The injection detection module 1020 is configured to, for a target execution stage in an SQL statement execution flow in which the to-be-detected SQL statement is located, perform injection detection on the to-be-detected SQL statement in the target execution stage by using a target aspect matched with the target execution stage, to obtain an injection detection result.

[0140] According to the embodiment of the application, the injection detection module performs injection detection on the to-be-detected SQL statement in the target execution stage by using the target aspect matched with the target execution stage, so as to obtain the injection detection result, which can significantly improve the detection accuracy and detection efficiency of complex SQL injection attacks.

[0141] In an embodiment, the device further comprises:

[0142] a packaging module configured to package the target execution stage in the SQL statement execution flow and the target aspect matched with the target execution stage, to obtain a corresponding portable file;

[0143] a deployment module configured to determine a target deployment mode corresponding to the portable file based on an application scenario; the target deployment mode comprises an embedded mode and a proxy mode.

[0144] a detection module configured to deploy the portable file into a corresponding application software according to the target deployment mode, to perform injection detection on the acquired to-be-detected SQL statement by using the portable file.

[0145] In an embodiment, the deployment module comprises:

[0146] a first deployment unit configured to, in a case where operation source code for accessing a target database by a user end is acquired, determine that the target deployment mode is the embedded mode, and introduce the portable file into the operation source code in the form of a lib package file.

[0147] a second deployment unit configured to, in a case where the operation source code for accessing the target database by the user end is not acquired, determine that the target deployment mode is the proxy mode, and operate the portable file as an independent project through a proxy mechanism.

[0148] In an embodiment, the target execution stage comprises an object construction stage and a statement execution stage corresponding to the SQL statement to be detected; and the target aspect comprises a tag-based heterogeneous aspect and a tag verification aspect.

[0149] Correspondingly, the injection detection module 1020 comprises:

[0150] a tag adding unit, configured to add tags to sensitive keywords in the SQL statement to be detected in the object construction stage to obtain corresponding tag information, so as to form a corresponding heterogeneous SQL statement.

[0151] a tag verification unit, configured to verify the tag information of the heterogeneous SQL statement to which the tag information is added in the statement execution stage, and determine whether the SQL statement to be detected in the target execution stage has a SQL injection behavior according to a result of the verification.

[0152] In an embodiment, the tag adding unit comprises:

[0153] a keyword identification subunit, configured to identify sensitive keywords corresponding to each of the SQL statements to be detected;

[0154] a matching subunit, configured to perform keyword matching between each of the sensitive keywords and keywords contained in a preset keyword list according to the sensitive keywords corresponding to each of the SQL statements to be detected;

[0155] a tag generation subunit, configured to, in a matching case, dynamically generate corresponding target tag information for each of the sensitive keywords contained in the SQL statement to be detected based on a preset tag generation algorithm, bind the target tag information to the corresponding SQL statement to be detected, and store the SQL statement to be detected and the corresponding target tag information in a preset tag library; wherein the sensitive keywords contained in the same SQL statement to be detected correspond to the same unique tag information.

[0156] a discard processing subunit, configured to, in a non-matching case, discard the non-matching sensitive keywords.

[0157] In an embodiment, the tag verification unit comprises:

[0158] a tag information acquisition subunit, configured to acquire target tag information bound to each of the heterogeneous SQL statements in the object construction stage from a preset tag library;

[0159] The comparison subunit is configured to obtain current label information bound by each of the heterogeneous SQL statements, compare the target label information with the current label information to obtain a comparison result, and take the comparison result as a result of the verification.

[0160] The first verification result determination subunit is configured to determine that the label verification is passed if the result of the verification is consistent, and remove the target label information bound by the heterogeneous SQL statement before execution of the heterogeneous SQL statement.

[0161] The second verification result determination subunit is configured to determine that the label verification is not passed if the result of the verification is inconsistent, and determine the heterogeneous SQL statement that fails in the verification as a statement of potential SQL injection behavior.

[0162] In an embodiment, the device further comprises:

[0163] The recording module is configured to record key data in a life cycle of the to-be-detected SQL statement, and store the key data in the form of a log for vulnerability analysis.

[0164] The key data at least includes: the to-be-detected SQL statement without the target label information, the to-be-detected SQL statement after the target label information is added, the SQL execution statement submitted to the target database, the label generation time corresponding to each of the to-be-detected SQL statements, the label verification result, and the abnormal information corresponding to the label verification result.

[0165] In an embodiment, the device further comprises:

[0166] The label management module is configured to manage the target label information in each thread by using a Thread Local tool class of Java, wherein one thread represents a processing process of one to-be-detected SQL statement, and each to-be-detected SQL statement corresponds to unique target label information.

[0167] In an embodiment, the target aspect is a target aspect pre-constructed by aspect-oriented programming (AOP).

[0168] The SQL injection detection device provided in the embodiments of the present application can execute the SQL injection detection method provided in any of the embodiments of the present application, and has the corresponding function modules and beneficial effects of the execution method.

[0169] In an embodiment, Figure 11 A structural diagram of an electronic device is provided for embodiments of the present application. The electronic device 10 is intended to represent various forms of digital computers, such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, wearable devices (e.g., headsets, glasses, watches, etc.), and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not intended to limit implementations of the applications described and / or claimed in this document.

[0170] As shown in Figure 11 The electronic device 10 includes at least one processor 11, and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., connected to the at least one processor 11 in communication, where the memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes according to the computer programs stored in the read-only memory (ROM) 12 or loaded into the random access memory (RAM) 13 from the storage unit 18. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0171] A plurality of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunications networks.

[0172] The processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 performs various methods and processes described above, such as the SQL injection detection method.

[0173] In some embodiments, the SQL injection detection method can be implemented as a computer program tangibly embodied in a computer readable storage medium, e.g., storage unit 18. In some embodiments, parts or all of the computer program can be loaded and / or installed onto electronic device 10 via, e.g., ROM 12 and / or communication unit 19. When the computer program is loaded onto RAM 13 and executed by processor 11, one or more steps of the above-described SQL injection detection method can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the SQL injection detection method by other means, e.g., with the aid of firmware.

[0174] Various implementations of the systems and techniques described above can be realized in digital electronic circuitry, integrated circuitry, specially designed application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0175] Computer programs used to implement the methods of the application can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the computer program, when executed, can implement the functions / acts specified in the flowcharts and / or block diagrams.

[0176] In the context of the present application, a computer-readable storage medium can be a tangible medium that can contain or store computer programs for use by or in connection with an instruction execution system, apparatus, or device. Computer-readable storage media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of a machine-readable storage medium will include one or more lines of a program of instructions in a transitory signal, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0177] To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the electronic device. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0178] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0179] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system, to solve the defects of large management difficulty and weak business scalability in traditional physical host and VPS service.

[0180] It should be understood that the various forms of flow shown above can be used to reorder, add or delete steps. For example, each step described in the present application can be executed in parallel, sequentially or in a different order, as long as the desired results of the technical solutions of the present application can be achieved, which is not limited herein.

[0181] The above detailed description does not constitute a limitation on the protection scope of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present application shall be included in the protection scope of the present application.< / dependencies>

Claims

1. A SQL injection detection method, characterized in that: The method comprises: Get the SQL statement to be tested; For the target execution phase in the SQL statement execution process where the SQL statement to be detected is located, injection detection is performed on the SQL statement to be detected in the target execution phase using a target aspect that matches the target execution phase to obtain an injection detection result.

2. The method according to claim 1, characterized in that The method further comprises: Encapsulating the target execution phase in the SQL statement execution process and the target aspect matching the target execution phase to obtain a corresponding portable file; Determining a target deployment mode corresponding to the portable file based on an application scenario; wherein the target deployment mode includes: an embedded mode and a proxy mode; The portable file is deployed according to the target deployment mode, so as to use the deployed portable file to perform injection detection on the acquired SQL statement to be detected.

3. The method according to claim 2, characterized in that The determining of the target deployment mode corresponding to the portable file based on the application scenario includes: In the case of obtaining the operation source code for the user terminal to access the target database, determining that the target deployment mode is the embedded mode, and introducing the portable file into the operation source code in the form of a lib package file; In the case that the operation source code for the user terminal to access the target database is not obtained, the target deployment mode is determined to be the proxy mode, and the portable file is run as an independent project through the proxy mechanism.

4. The method according to claim 1, wherein The target execution phase includes: the object construction phase and the statement execution phase corresponding to the SQL statement to be detected; the target aspect includes: the labeling heterogeneous aspect and the label verification aspect; Accordingly, for the target execution stage in the SQL statement execution process where the SQL statement to be detected is located, injection detection is performed on the target execution stage in the SQL statement execution process using a target aspect that matches the target execution stage, and injection detection results are obtained, including: In the object construction phase, the labeling heterogeneous aspect is used to dynamically add labels to the sensitive keywords in the SQL statement to be detected to obtain corresponding label information to form a corresponding heterogeneous SQL statement; During the statement execution phase, the label verification aspect is used to verify the label information of the heterogeneous SQL statement to which the label information is added, and based on the verification result, it is determined whether there is SQL injection behavior in the SQL statement to be detected in the target execution phase.

5. The method according to claim 4, characterized in that The step of dynamically adding labels to sensitive keywords in the SQL statement to be detected using the labeled heterogeneous aspect to obtain corresponding label information includes: Identify the sensitive keywords corresponding to each of the SQL statements to be detected; For each sensitive keyword corresponding to each of the SQL statements to be detected, keyword matching is performed on each of the sensitive keywords with keywords included in a preset keyword list; In the event of a match, dynamically generate corresponding target tag information for each sensitive keyword contained in each of the SQL statements to be detected based on a preset tag generation algorithm, bind the target tag information to the corresponding SQL statement to be detected, and store the SQL statement to be detected and the corresponding target tag information in a preset tag library; wherein, sensitive keywords contained in the same SQL statement to be detected correspond to the same unique tag information; In the event of a mismatch, the mismatched sensitive keywords will be discarded.

6. The method according to claim 4, characterized in that The step of using the tag verification aspect to verify tag information on the heterogeneous SQL statement with the tag information added, and determining whether there is SQL injection behavior in the heterogeneous SQL statement in the target execution phase based on the verification result, includes: Acquire target tag information bound to each of the heterogeneous SQL statements when generating tags in the object construction phase from a preset tag library; Obtaining current label information bound to each of the heterogeneous SQL statements, comparing the target label information with the current label information to obtain a comparison result, and using the comparison result as a verification result; If the verification results are consistent, it is determined that the tag verification is passed, and before the heterogeneous SQL statement is executed, the target tag information bound to the heterogeneous SQL statement is removed; If the verification results are inconsistent, it is determined that the tag verification fails, and the heterogeneous SQL statement that fails the verification is determined as a statement of potential SQL injection behavior.

7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: During the life cycle of the SQL statement to be detected, key data within the life cycle is recorded and stored in the form of logs for vulnerability analysis; Among them, the key data includes at least: the SQL statement to be tested without adding the target tag information, the SQL statement to be tested after adding the target tag information, the SQL execution statement submitted to the target database, the label generation time corresponding to each of the SQL statements to be tested, the label verification result, and the abnormal information corresponding to the label verification result.

8. A SQL injection detection device, characterized in that: The device comprises: Statement acquisition module, used to obtain the SQL statement to be tested; The injection detection module is used to perform injection detection on the SQL statement to be detected in the target execution stage in the SQL statement execution process where the SQL statement to be detected is located, using a target aspect that matches the target execution stage to obtain an injection detection result.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor. The computer program is executed by the at least one processor so that the at least one processor can perform the SQL injection detection method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the SQL injection detection method according to any one of claims 1 to 7 when executed.

11. A computer program product, characterized in that The computer program product comprises a computer program, which, when executed by a processor, implements the SQL injection detection method according to any one of claims 1 to 7.

Images