A real-time SQL injection detection method based on depth separable convolution

Abstract

The application relates to a real-time SQL injection detection method based on a deep separable convolution, which comprises the following steps: extracting valid fields from the HTTP request and assigning weights to the valid fields; performing density feature extraction on each valid field in parallel based on a precompiled SQL attack regular expression to obtain density-aware features corresponding to the valid fields; inputting any density-aware feature into a cache for query; if a hit is obtained, taking the corresponding value in the cache as a prediction label of the corresponding valid field; otherwise, performing inference on the density-aware feature through a DSCNN model to output a prediction label of the corresponding valid field; calculating a risk score of the HTTP request based on the prediction label of the valid field and the corresponding assigned weight; and determining that the HTTP request is an SQL risk when the risk score exceeds a preset threshold. The method significantly improves the SQL injection attack detection speed and system throughput capacity, and reduces resource consumption.

Description

Technical Field

[0001] This application relates to the technical field of SQL injection attack detection methods, and in particular to a real-time SQL injection detection method based on depthwise separable convolution. Background Technology

[0002] In today's cybersecurity environment, timely and accurate identification and defense against SQL injection attacks has become a crucial task. Current methods using convolutional neural networks and recurrent neural networks to detect SQL injection can achieve high accuracy. However, existing deep learning models still have shortcomings in real-time performance, computational overhead, and adaptability, making them difficult to truly intercept access in practice. Specific shortcomings are as follows:

[0003] 1. Currently, common methods still employ character-level encoding, automatic state machines, or token-based encoding to process the string in the request character by character or word by word. When the length of the string to be detected is long, the model consumes a lot of computing resources during the encoding stage, resulting in decreased detection efficiency and making it difficult to achieve real-time interception of access requests in real-world scenarios.

[0004] 2. During the model inference stage, detection models, such as convolutional neural networks and recurrent neural networks, typically require 10-100 milliseconds for a single inference iteration. When detecting HTTP requests, the variable length of HTTP requests significantly reduces detection efficiency, impacting real-time detection capabilities and ultimately leading to excessively high request latency.

[0005] 3. Currently, the commonly used approach is still full-scale inspection, which involves performing phased sequential analysis on all fields and content of the request. While this approach is comprehensive, it leads to a large amount of redundant computation in real-world applications with large-scale concurrent access, increasing system resource consumption and further exacerbating latency issues in real-time inspection. Summary of the Invention

[0006] Therefore, it is necessary to provide a real-time SQL injection detection method based on depthwise separable convolution to solve the problems of slow detection speed, low system throughput, and high resource consumption in existing deep learning detection technologies. This method includes:

[0007] S1: Obtain real-time HTTP requests, extract valid fields from the HTTP requests, and assign weights to the valid fields;

[0008] S2: Based on the pre-compiled SQL attack regular expression, density features are extracted in parallel for each valid field to obtain the density-aware features corresponding to each valid field;

[0009] S3: Input any density-aware feature into the cache for querying. If a match is found, take the corresponding value in the cache as the predicted label of the corresponding valid field. Otherwise, pass the density-aware feature through the DSCNN model for inference and output the predicted label of the corresponding valid field.

[0010] S4: Calculate the risk score of the HTTP request based on the predicted labels of the valid fields and the corresponding assigned weights; when the risk score exceeds a preset threshold, the HTTP request is determined to be an SQL risk.

[0011] Preferably, valid fields are extracted from the HTTP request, and weights are assigned to the valid fields, including:

[0012] Step 1: Parse the HTTP request into JSON format data containing headers, URL, and body;

[0013] Step 2: Extract the fields from the JSON data whose keys are headers, url, and body;

[0014] Step 3: Filter out empty fields and single-digit fields from all fields to obtain several valid fields;

[0015] Step 4: Assign weights to valid fields based on the security importance of the key values ​​corresponding to the valid fields.

[0016] Preferably, in S2, parallelism includes:

[0017] Initialize the thread pool by creating a fixed-size thread pool based on the number of CPU cores;

[0018] Create an independent density feature extraction task for each valid field; when the number of valid fields is greater than the thread pool size, perform the density feature extraction task only after the thread is idle.

[0019] Preferably, the method also includes setting a task timeout control parameter, which directly determines that the HTTP request is an SQL risk when the processing time of any density feature extraction task exceeds the task timeout control parameter.

[0020] Preferably, the pre-compiled SQL attack regular expressions include symbol matching patterns, SQL keyword matching patterns, UNION keyword matching patterns, logical operator matching patterns, function matching patterns, and special character matching patterns.

[0021] Preferably, density feature extraction for any valid field includes:

[0022] Step 1: Match the text in the valid field using any matching pattern and count the matches to obtain the corresponding match count;

[0023] Step 2: Calculate the density factor of the corresponding matching pattern based on the match count and the length of the valid field, and determine the length penalty factor based on the length of the valid field;

[0024] Step 3: Calculate the overall risk score based on the density factor and corresponding preset weight of each matching pattern; calculate the standardized risk score based on the overall risk score and the length penalty factor.

[0025] Step 4: Based on the match count or the length of the valid field for each matching pattern, calculate the complexity score, number of state transitions, text length, total number of suspicious patterns, symbol density, SQL keyword density, UNION keyword density, and logical operator density respectively.

[0026] Step 5: Concatenate the overall risk score, standardized risk score, complexity score, number of state transitions, text length, total number of suspicious patterns, symbol density, SQL keyword density, UNION keyword density, and logical operator density to obtain the density-aware features of the effective fields.

[0027] The preferred formula for calculating the standardized risk score is:

[0028] ;

[0029] ; ;

[0030] ; ;

[0031] ;

[0032] in, Represents standardized risk scores. Indicates the overall risk score. This indicates taking the minimum value. Represents the length penalty factor. Indicates the first Risk contribution of various matching patterns Indicates the first Density factor of matching patterns Indicates the first Preset weights for each matching pattern Indicates the first Match count for each matching pattern This indicates taking the maximum value. Represents a length function. Indicates a valid field. This represents the pattern matching function. Indicates the first Matching patterns.

[0033] The preferred formula for calculating density-perceived features is:

[0034] ;

[0035] ; ;

[0036] ; ;

[0037] ; ; ; ;

[0038] in, Density-aware features representing valid fields, This indicates a splicing operation. Indicates the complexity score. Indicates the number of state transitions. Indicates text length. Indicates the total number of suspicious patterns. Represents symbol density, Indicates SQL keyword density. Indicates the keyword density of UNION. Indicates the density of logical operators. This represents the total match count of the matching pattern. This represents the match count of the symbol matching pattern. This represents the match count of the SQL keyword matching pattern. This indicates the match count of the UNION keyword matching pattern. This represents the match count of the pattern matched by the logical operator. This represents the scaling factor.

[0039] Preferably, any key-value pair in the cache includes: a key with the density-aware feature of the effective field and a value with the predicted label of the corresponding effective field inferred by the previous DSCNN model;

[0040] The cache is used to maintain an index table that records the most recent access time of each key-value pair. When the storage capacity of the cache reaches a preset limit, the least accessed key-value pair is identified according to the index table and deleted from the cache.

[0041] Preferably, the formula for calculating the risk score of an HTTP request is:

[0042] ;

[0043] in, This indicates the risk score of the HTTP request. Indicates the number of valid fields. Indicates the first Predicted labels for each valid field. Indicates the first Weights assigned to each valid field.

[0044] Beneficial effects: This method significantly improves the detection speed of SQL injection attacks and the system throughput, while reducing resource consumption. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a flowchart of a real-time SQL injection detection method based on depthwise separable convolution in an embodiment of this application.

[0047] Figure 2 This is a schematic diagram of the structure of the DSCNN model in the embodiments of this application. Detailed Implementation

[0048] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the specific embodiments of this application are described in detail below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of this application. Therefore, this application is not limited to the specific embodiments disclosed below.

[0049] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0050] like Figure 1 As shown, this embodiment provides a real-time SQL injection detection method based on depthwise separable convolution, including:

[0051] S1: Obtain real-time HTTP requests, extract valid fields from the HTTP requests, and assign weights to the valid fields.

[0052] Traditional HTTP field extraction typically divides the detection process into header and body phases, processing fields sequentially according to each phase. Furthermore, traditional methods perform coarse-grained detection on all fields without differentiating risk weights for each. Considering the demands of high concurrency in HTTP requests and the requirement for varying attack weights for different fields, this embodiment employs fine-grained decomposition to extract fields and assigns weights to different fields to improve the detection effectiveness of SQL attacks.

[0053] Specifically, valid fields are extracted from the HTTP request, and weights are assigned to these valid fields, including:

[0054] Step 1: Parse the HTTP request into JSON format data containing headers, URL, and body, and standardize the format for subsequent processing;

[0055] Step 2: Extract the fields from the JSON data whose keys are headers, url, and body;

[0056] Step 3: Since empty fields and meaningless single-digit fields may occupy thread pool and cache resources later, empty fields and single-digit fields are filtered out from all fields to obtain several valid fields;

[0057] Step 4: Assign weights to valid fields based on the security importance of the corresponding key values. For example, the security importance order of key values ​​is url > body > headers.

[0058] Optionally, the weight of valid fields in the URL can be set to... The weight of valid fields belonging to the body can be set to The weight of valid fields belonging to headers can be set to .

[0059] First, HTTP request parsing preserves the semantic structure of the HTTP protocol, maintaining the integrity of the information. Second, field classification extraction allows for parallel detection of various fields, shortening the detection time compared to traditional serial detection. Furthermore, it can allocate security weights based on the characteristics of different fields, improving detection accuracy. Finally, field validity filtering avoids meaningless detection of empty fields and reduces the resource consumption of thread pools and caches.

[0060] S2: Based on the pre-compiled SQL attack regular expression, density features are extracted in parallel for each valid field to obtain the density-aware features corresponding to each valid field.

[0061] Traditional parallel detection scheduling modules typically use algorithms such as First-Come, First-Served (FCFS) or Shortest Job First (SJF) for task scheduling. To improve detection efficiency, this embodiment uses FCFS for scheduling, sets up a fixed-size thread pool, and implements a timeout degradation strategy to ensure the system can still function normally in abnormal situations.

[0062] Optional, parallel processing includes:

[0063] The thread pool is initialized by creating a fixed-size thread pool based on the number of CPU cores. In this embodiment, the thread pool size is set to 8 to balance concurrency and resource consumption.

[0064] Create an independent density feature extraction task for each valid field; when the number of valid fields is greater than the thread pool size, perform the density feature extraction task only after the thread is idle.

[0065] Optionally, to prevent a single density feature extraction task from dragging down the entire detection process, a task timeout control parameter (e.g., set to 20ms) is also included. If the processing time of any density feature extraction task exceeds the task timeout control parameter, the HTTP request is directly determined to be an SQL risk to ensure the availability of the system.

[0066] First, compared to the serial processing of traditional SQL detection methods, parallel detection scheduling can better utilize multi-core CPUs for detection, reducing detection time. Moreover, this parallel approach can also be adapted to GPU detection after modification. Second, using a fixed thread pool and timeout degradation strategy can ensure system stability and keep detection latency within an acceptable range. The degradation strategy is beneficial for overall risk control when performing source tracing analysis on HTTP requests, thus improving the system's detection efficiency.

[0067] In this embodiment, the pre-compiled SQL attack regular expression includes symbol matching pattern, SQL keyword matching pattern, UNION keyword matching pattern, logical operator matching pattern, function matching pattern, and special character matching pattern.

[0068] In traditional SQL attack detection methods, rule matching is the most common approach. This typically involves accumulating scores from matched rules to determine if an attack has occurred. However, this method requires matching a large number of rules, resulting in low efficiency and false positives in long texts. This embodiment proposes a fast density-aware algorithm to extract multidimensional features of SQL attacks. First, pattern matching is used to count and determine risk scores. Then, density factors and length penalty factors are calculated based on text length to extract risk features and pattern count features. Finally, these features are concatenated to calculate the density-aware features.

[0069] Specifically, density feature extraction for any valid field includes:

[0070] Step 1: Match the text in the valid field using any matching pattern and count the matches. The corresponding match count is calculated as follows:

[0071] ;

[0072] in, Indicates the first Match count for each matching pattern Indicates a valid field. This represents the pattern matching function. Indicates the first Matching patterns.

[0073] Step 2: Calculate the density factor of the corresponding matching pattern based on the match count and the length of the valid field, and determine the length penalty factor based on the length of the valid field. The calculation formula is as follows:

[0074] ;

[0075] ;

[0076] in, Indicates the first Density factor of matching patterns Represents the length penalty factor. Indicates the first Match count for each matching pattern This indicates taking the maximum value. Represents a length function. Indicates a valid field.

[0077] Step 3: Calculate the overall risk score based on the density factor and corresponding preset weights of each matching pattern; calculate the standardized risk score based on the overall risk score and the length penalty factor; the formula for calculating the standardized risk score is:

[0078] ;

[0079] ; ;

[0080] in, Represents standardized risk scores. Indicates the overall risk score. This indicates that the minimum value is taken (to prevent the risk of a single matching pattern from being too high). Represents the length penalty factor. Indicates the first Risk contribution of various matching patterns Indicates the first Density factor of matching patterns Indicates the first Preset weights for each matching pattern.

[0081] The six matching modes—symbol matching mode, SQL keyword matching mode, UNION keyword matching mode, logical operator matching mode, function matching mode, and special character matching mode—have preset weights of 0.2, 0.3, 0.4, 0.35, 0.3, and 0.15, respectively, and can be optimized and set based on actual data testing.

[0082] Step 4: Based on the match count or the length of the valid field for each matching pattern, calculate the complexity score, number of state transitions, text length, total number of suspicious patterns, symbol density, SQL keyword density, UNION keyword density, and logical operator density; the calculation formulas include:

[0083] ; ;

[0084] ; ;

[0085] ; ; ; ;

[0086] in, Indicates the complexity score. Indicates the number of state transitions. Indicates text length. Indicates the total number of suspicious patterns. Represents symbol density, Indicates SQL keyword density. Indicates the keyword density of UNION. Indicates the density of logical operators. This indicates the number of different matching patterns detected. This represents the total match count of the matching pattern. This represents the average number of state transitions across all matching patterns. This represents the match count of the symbol matching pattern. This represents the match count of the SQL keyword matching pattern. This indicates the match count of the UNION keyword matching pattern. This represents the match count of the pattern matched by the logical operator. This represents the scaling factor (e.g., 10).

[0087] Step 5: Concatenate the overall risk score, standardized risk score, complexity score, number of state transitions, text length, total number of suspicious patterns, symbol density, SQL keyword density, UNION keyword density, and logical operator density to obtain the density-aware features of the effective fields. The formula for calculating the density-aware features is:

[0088] ;

[0089] in, Density-aware features representing valid fields, This indicates a splicing operation. Indicates the complexity score. Indicates the number of state transitions. Indicates text length. Indicates the total number of suspicious patterns. Represents symbol density, Indicates SQL keyword density. Indicates the keyword density of UNION. The density of logical operators is represented by the above feature extraction algorithm, which has low complexity, high speed, and can effectively detect SQL attacks.

[0090] First, compared to traditional rule-based matching and state machine matching, this method uses fewer rules for matching, improving detection speed and reducing rule maintenance costs. Second, this embodiment proposes a density-aware feature extraction method, which improves detection performance in the global detection dimension by using risk score features and pattern density features, and improves computational efficiency by using simple formulas. Finally, by introducing density factors and length penalty factors, the method optimizes the problem of false positives for long texts, reducing false positives and improving the detection efficiency of long texts.

[0091] S3: Input any density-aware feature into the cache for querying. If a match is found, take the corresponding value in the cache as the predicted label of the corresponding valid field. Otherwise, pass the density-aware feature through the DSCNN model for inference and output the predicted label of the corresponding valid field.

[0092] Traditional SQL detection methods either fail to use caching, directly detecting large amounts of duplicate content and requests, or use the original content as the key for caching, where subtle differences can cause cache invalidation and waste significant memory. Therefore, this embodiment uses extracted density-aware features as the key and the model inference result as the value, ensuring that the same features can hit the same cache item and avoiding secondary model inference.

[0093] Optionally, any key-value pair in the cache includes: a key with the density-aware feature of the effective field and a value with the predicted label of the corresponding effective field inferred by the previous DSCNN model;

[0094] The cache is used to maintain an index table that records the most recent access time of each key-value pair. Whenever a key-value pair is accessed or written, the system updates the access time information of that key-value pair.

[0095] Without an eviction policy, the cache may grow indefinitely, leading to memory overflow. Therefore, this embodiment uses an LRU eviction policy to update the cache, ensuring the controllability and efficiency of system memory usage. Specifically, when the cache storage capacity reaches a preset limit, the least accessed key-value pair is identified according to the index table and deleted from the cache to free up storage space for new inference results.

[0096] Caching allows for extensive use of historical calculation results, avoids duplicate detections, reduces redundant calculations, and greatly improves detection efficiency.

[0097] Traditional deep learning networks typically have a large number of parameters, high memory consumption, and slow inference speed, posing a significant bottleneck in real-time SQL attack detection. Therefore, this embodiment introduces a Depthwise Separable Convolutional Neural Network (DSCNN) for inference. By using depthwise separable convolutional layers, redundant operations in convolutional computation are reduced, thereby improving detection speed and reducing memory consumption.

[0098] like Figure 2 As shown, the workflow of the DSCNN model includes:

[0099] First, the density-aware feature F is input into the L-layer depthwise separable convolutional computation module, and after the [missing information]... Depthwise convolution and pointwise convolution are used to extract spatial features and perform channel fusion operations to obtain the feature representation of the layer. Subsequently, the updated node representation is obtained through an average pooling layer. Finally, the output is obtained by passing through a fully connected layer and a sigmoid activation function.

[0100] Specifically, the detailed process includes:

[0101] Step 1: Calculation of depthwise separable convolutional layers: Input features Joint representation of spatial and channel features is achieved through depthwise convolution and pointwise convolution. The formula for depthwise convolution is:

[0102] ;

[0103] in, Indicates the position of depthwise convolution. ,aisle The output at that location, Indicates the first Layer depth can separate the output of convolutional layers. Indicates output The Middle line, number The column elements, where K represents the kernel size (set to 3 in this embodiment) and C represents the number of channels (set to 1 in this embodiment). The trainable matrix representing a depthwise convolution. Represents a trainable matrix The Middle line, number Column elements, The bias matrix represents the depthwise convolution. Represents the bias matrix The Middle Each element.

[0104] The formula for pointwise convolution is:

[0105] ;

[0106] in, This indicates that pointwise convolution occurs at position... ,aisle The output at that location, This represents a trainable matrix for pointwise convolution. Represents a trainable matrix The Middle line, number Column elements, This represents the bias matrix for pointwise convolution. Represents the bias matrix The Middle Each element.

[0107] Then, the ReLU activation function is calculated, as follows:

[0108] ;

[0109] in, Indicates the first Layer depth can separate the output of convolutional layers. This represents the ReLU activation function.

[0110] Using the output of the (L-1)th depth separable convolutional layer as the input of the Lth depth separable convolutional layer, and repeating step one, the output of the Lth depth separable convolutional layer can be calculated. .

[0111] Step 2: Calculate the average pooling layer and output the convolution. The input is fed into an average pooling layer, where it is averaged across all spatial locations to obtain a compact global feature representation. The calculation formula is:

[0112] ;

[0113] in, This indicates an average calculation.

[0114] Step 3: Classification layer output; convert global features The input is fed into a fully connected layer, and the final predicted label is obtained through the Sigmoid activation function. The calculation formula is as follows:

[0115] ;

[0116] in, Indicates the predicted label, This represents the Sigmoid activation function. Indicates the weights of the fully connected layer. This indicates the bias of the fully connected layer.

[0117] Optionally, a network classification model with L=2 layers of separable convolutions can be used for computation.

[0118] The classification model based on depthwise separable convolution significantly reduces computational cost and parameter count by separating channel-wise and pointwise convolutions, while maintaining the feature extraction capabilities of convolutional neural networks. With the combination of global average pooling and fully connected layers, it achieves efficient and lightweight classification results, substantially improving detection speed and reducing memory usage.

[0119] S4: Calculate the risk score of the HTTP request based on the predicted labels of the valid fields and the corresponding assigned weights; when the risk score exceeds a preset threshold (e.g., 0.5), the HTTP request is determined to be an SQL risk.

[0120] Specifically, the formula for calculating the risk score of an HTTP request is:

[0121] ;

[0122] in, This indicates the risk score of the HTTP request. Indicates the number of valid fields. Indicates the first Predicted labels for each valid field. Indicates the first Weights assigned to each valid field.

[0123] The real-time SQL injection detection method based on depthwise separable convolution provided in this embodiment has the following beneficial effects:

[0124] 1. Traditional deep learning-based detection still employs character-level encoding, automatic state machines, or token-based encoding to process strings in requests character by character or word by word. Furthermore, when the string to be detected is long, the model consumes significant computational resources during the encoding phase, leading to decreased detection efficiency and making it difficult to achieve real-time interception of access requests in real-world scenarios.

[0125] In this method, the encoding method is abandoned, and instead a small number of pre-compiled regular expressions are used to achieve efficient extraction of request features, which greatly improves the detection speed and reduces the cost of rule maintenance. Then, a density-aware feature extraction method is proposed. By using risk score features and pattern density features, the detection effect is improved in the dimension of global detection. Furthermore, the problem of false positives for long texts is optimized by introducing density factors and length penalty factors.

[0126] 2. Problems with inference efficiency in existing deep learning models. During the model inference phase, detection models, such as convolutional neural networks and recurrent neural networks, typically require 10-100 milliseconds for a single inference iteration. When detecting HTTP requests, the variable length of HTTP requests significantly reduces detection efficiency, impacting real-time detection capabilities and ultimately leading to excessively high request latency.

[0127] This method employs a classification model based on depthwise separable convolutions. By separating the computation of channel-wise convolutions from pointwise convolutions, the computational cost and parameter count are significantly reduced, while maintaining the feature extraction capabilities of the convolutional neural network. With the combined use of global average pooling and fully connected layers, efficient and lightweight classification results are achieved, resulting in a substantial improvement in detection speed and a reduction in memory usage.

[0128] 3. Existing SQL detection methods generally still employ a full-scale detection approach, which involves performing phased sequential analysis on all fields and content of the request. While this approach offers comprehensive coverage, it introduces a significant amount of redundant computation in real-world applications with large-scale concurrent access. This increases system resource consumption and further exacerbates latency issues in real-time detection.

[0129] This method combines parallel detection scheduling and cache checking to optimize detection efficiency. Parallel detection scheduling makes better use of multi-core CPUs for detection, reducing detection time. Moreover, this parallel approach is also adaptable to GPU detection. Using a fixed thread pool and timeout degradation strategy ensures system stability and keeps detection latency within an acceptable range. Caching allows for extensive use of historical calculation results, avoiding duplicate detection and significantly improving detection efficiency.

[0130] 4. Experiments show that the real-time SQL injection detection method based on depthwise separable convolution in this embodiment can achieve good results in the classification task of SQL attack detection, improve detection efficiency, and reduce the latency of HTTP request response.

[0131] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0132] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A real-time SQL injection detection method based on depthwise separable convolution, characterized in that, include: S1: Obtain real-time HTTP requests, extract valid fields from the HTTP requests, and assign weights to the valid fields, including: Step 1: Parse the HTTP request into JSON format data containing headers, URL, and body; Step 2: Extract the fields from the JSON data whose keys are headers, url, and body; Step 3: Filter out empty fields and single-digit fields from all fields to obtain several valid fields; Step 4: Assign weights to valid fields based on the security importance of the key values ​​corresponding to the valid fields; S2: Density feature extraction is performed in parallel on each valid field based on pre-compiled SQL attack regular expressions to obtain the density-aware features corresponding to each valid field; the pre-compiled SQL attack regular expressions include symbol matching patterns, SQL keyword matching patterns, UNION keyword matching patterns, logical operator matching patterns, function matching patterns, and special character matching patterns; density feature extraction for any valid field includes: Step 1: Match the text in the valid field using any matching pattern and count the matches to obtain the corresponding match count; Step 2: Calculate the density factor of the corresponding matching pattern based on the match count and the length of the valid field, and determine the length penalty factor based on the length of the valid field; Step 3: Calculate the overall risk score based on the density factor and corresponding preset weight of each matching pattern; calculate the standardized risk score based on the overall risk score and the length penalty factor. Step 4: Based on the match count or the length of the valid field for each matching pattern, calculate the complexity score, number of state transitions, text length, total number of suspicious patterns, symbol density, SQL keyword density, UNION keyword density, and logical operator density respectively. Step 5: Concatenate the overall risk score, standardized risk score, complexity score, number of state transitions, text length, total number of suspicious patterns, symbol density, SQL keyword density, UNION keyword density, and logical operator density to obtain the density-aware features of the effective fields; S3: Input any density-aware feature into the cache for querying. If a match is found, take the corresponding value in the cache as the predicted label of the corresponding valid field. Otherwise, pass the density-aware feature through the DSCNN model for inference and output the predicted label of the corresponding valid field. The cache is used to maintain an index table that records the most recent access time of each key-value pair. Any key-value pair in the cache includes: the density-aware feature of the valid field as the key and the predicted label of the corresponding valid field inferred by the DSCNN model in the past as the value. S4: Calculate the risk score of the HTTP request based on the predicted labels of the valid fields and the corresponding assigned weights; when the risk score exceeds a preset threshold, the HTTP request is determined to be an SQL risk.

2. The real-time SQL injection detection method according to claim 1, characterized in that, In S2, parallelism includes: Initialize the thread pool by creating a fixed-size thread pool based on the number of CPU cores; Create an independent density feature extraction task for each valid field; when the number of valid fields is greater than the thread pool size, perform the density feature extraction task only after the thread is idle.

3. The real-time SQL injection detection method according to claim 2, characterized in that, It also includes setting task timeout control parameters. If the processing time of any density feature extraction task exceeds the task timeout control parameters, the HTTP request will be directly determined to be an SQL risk.

4. The real-time SQL injection detection method according to claim 1, characterized in that, The formula for calculating the standardized risk score is: ； ； ； ； ； ； in, Represents standardized risk scores. Indicates the overall risk score. This indicates taking the minimum value. Represents the length penalty factor. Indicates the first Risk contribution of various matching patterns Indicates the first Density factor of matching patterns Indicates the first Preset weights for each matching pattern Indicates the first Match count for each matching pattern This indicates taking the maximum value. Represents a length function. Indicates a valid field. This represents the pattern matching function. Indicates the first Matching patterns.

5. The real-time SQL injection detection method according to claim 4, characterized in that, The formula for calculating density-perceived features is: ； ； ； ； ； ； ； ； ； in, Density-aware features representing valid fields, This indicates a splicing operation. Indicates the complexity score. Indicates the number of state transitions. Indicates text length. Indicates the total number of suspicious patterns. Represents symbol density, Indicates SQL keyword density. Indicates the keyword density of UNION. Indicates the density of logical operators. This represents the total match count of the matching pattern. This represents the match count of the symbol matching pattern. This represents the match count of the SQL keyword matching pattern. This indicates the match count of the UNION keyword matching pattern. This represents the match count of the pattern matched by the logical operator. This represents the scaling factor.

6. The real-time SQL injection detection method according to claim 1, characterized in that, When the storage capacity of the cache reaches the preset limit, the least accessed key-value pair is identified according to the index table and deleted from the cache.

7. The real-time SQL injection detection method according to claim 1, characterized in that, The formula for calculating the risk score of an HTTP request is: ； in, This indicates the risk score of the HTTP request. Indicates the number of valid fields. Indicates the first Predicted labels for each valid field. Indicates the first Weights assigned to each valid field.

Images