Network request risk detection method, system and server

Abstract

The application provides a network request risk detection method, system and server, and relates to the field of network request risk detection. The method performs feature fusion on an injection keyword matching result, a network request parameter statistical result and a network request character vectorization result corresponding to to-be-detected data, dynamically optimizes continuous features in the fused feature data, and realizes accurate detection of SQL injection risks in a network request process through a lightweight classifier.

Description

Technical Field

[0001] This invention relates to the field of network request risk detection, and in particular to a network request risk detection method, system, and server. Background Technology

[0002] During the execution of network requests, attackers often construct and insert malicious SQL code snippets into the application's input interfaces (such as URL parameters, HTTP request headers, etc.) to carry out network attacks. If SQL injection is not adequately verified and processed during the network request process, the malicious code injected by the attacker may be mistakenly regarded as a legitimate SQL instruction by the backend server, which may lead to a series of network security problems such as unauthorized data access, data tampering, and denial of service.

[0003] Existing technologies typically use predefined static rule bases for matching when dealing with SQL injection during network requests. However, this approach suffers from poor detection results due to the limitations of static matching and issues such as encoding distortion. Furthermore, using syntax trees to analyze SQL injection suffers from poor compatibility with multiple database syntaxes. When using feature engineering, machine learning, and large language models for SQL injection risk monitoring, there are generally problems such as high computational overhead, high false positive rates, and poor real-time performance. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a network request risk detection method, system and server. The method performs feature fusion on the injection keyword matching results, network request parameter statistical results and network request character vectorization results corresponding to the data to be detected, and dynamically optimizes the continuous features in the fused feature data. Then, it achieves accurate detection of SQL injection risks in the network request process through a lightweight classifier, thereby solving the above-mentioned problems existing in the SQL injection detection process of the prior art.

[0005] In a first aspect, embodiments of the present invention provide a network request risk detection method, the method comprising:

[0006] The network request data is acquired, and after encoding and converting the network request data using preset sample data, the corresponding data to be detected is obtained.

[0007] Based on the injection keyword matching results, network request parameter statistics, and network request character vectorization results of the data to be detected, feature data corresponding to the data to be detected is extracted.

[0008] Based on the feature data, the continuous feature group corresponding to the data to be detected is determined. After scaling the continuous feature group according to the ratio feature corresponding to the feature data, the feature merged data corresponding to the feature data is obtained.

[0009] The attack risk probability corresponding to the feature-merged data is determined using a pre-trained decision tree-based classifier.

[0010] The attack risk probability is updated based on the latency ratio data and structure call data corresponding to the data to be detected.

[0011] The attack risk level corresponding to the data to be detected is determined by the updated attack risk probability.

[0012] Optionally, the step of acquiring network request data, encoding and converting the network request data using preset sample data, and obtaining the data to be detected corresponding to the network request data includes:

[0013] After obtaining network request data based on real-time traffic data and historical log data, the corresponding cached data is determined.

[0014] Determine whether the cached data contains the network request data based on the MD5 hash value corresponding to the network request data.

[0015] If the cached data does not contain network request data, then the encoding conversion rules and text specification rules corresponding to the network request data are determined based on the sample data corresponding to the decision tree base classifier during the training phase.

[0016] After encoding and converting the network request data using encoding conversion rules and text specification rules, the corresponding data to be detected is obtained.

[0017] Optionally, if the cached data contains network request data, the method further includes:

[0018] Determine if the cached data contains expired data;

[0019] If the cached data contains expiration information, the attack risk level corresponding to the data to be detected is determined based on the cached data.

[0020] Optionally, the step of extracting feature data corresponding to the data to be detected based on the injection keyword matching results, network request parameter statistics, and network request character vectorization results includes:

[0021] The matching results of SQL injection keywords, special characters, and length features of the data to be detected are used to extract the rule feature data corresponding to the data to be detected;

[0022] Statistical feature data corresponding to the data to be detected is extracted by using the statistical results of the URL structure, number of parameters, and character type distribution of the data to be detected;

[0023] Extract language feature data corresponding to the data to be detected using the character vectorization results of the data to be detected;

[0024] The feature data corresponding to the data to be detected is determined based on rule feature data, statistical feature data, and language feature data.

[0025] Optionally, the step of determining the continuous feature group corresponding to the data to be detected based on the feature data, and scaling the continuous feature group according to the ratio feature corresponding to the feature data to obtain the feature merged data corresponding to the feature data includes:

[0026] Continuous feature groups are determined based on continuous feature data in statistical feature data and linguistic feature data, and discrete feature groups corresponding to the data to be detected are determined based on discrete feature data in rule feature data and statistical feature data.

[0027] The synthetic minority oversampling algorithm is used to obtain the ratio features corresponding to the language feature data, and the ratio features are used to scale the continuous feature group to the same scale as the discrete feature group.

[0028] After merging the scaled continuous feature groups with the discrete feature groups, we obtain the merged feature data corresponding to the feature data.

[0029] Optionally, the step of determining the attack risk probability corresponding to the feature-merged data using a pre-trained decision tree-based classifier includes:

[0030] Obtain the trained Adaboost decision tree base classifier and input the feature merged data into the Adaboost decision tree base classifier;

[0031] The attack risk probability corresponding to the feature merging data is determined based on the output of the Adaboost decision tree base classifier; the attack risk probability is calculated using the following formula:

[0032] ;

[0033] in, Probability of attack risk; This represents the mixed feature vector corresponding to the feature merging data; Number of base classifiers; These are the classifier weights; The output of the base classifier.

[0034] Optionally, the step of updating the attack risk probability based on the latency ratio data corresponding to the data to be detected and the structure call data includes:

[0035] Obtain the network request instruction corresponding to the data to be detected, and determine whether the key field corresponding to the network request instruction contains the preset blind injection keyword;

[0036] If yes, then the latency ratio data is determined based on the baseline measurement parameters and latency measurement parameters corresponding to the blind injection keywords, and the attack risk probability is updated according to the first update strategy corresponding to the latency ratio data; if no, then the structure call data is determined based on the interface call data and SQL structure data corresponding to the data to be detected, and the attack risk probability is updated according to the second update strategy corresponding to the structure call data.

[0037] Optionally, after determining the attack risk level corresponding to the data to be detected through the updated attack risk probability, the method further includes:

[0038] The attack risk level and the data to be detected are saved to the cache data.

[0039] Secondly, the present invention provides a network request risk detection system, the system comprising:

[0040] The data preprocessing module is used to acquire network request data, and after encoding and converting the network request data using preset sample data, obtain the data to be detected corresponding to the network request data.

[0041] The feature extraction module is used to extract feature data corresponding to the data to be detected based on the injection keyword matching results, network request parameter statistics, and network request character vectorization results.

[0042] The feature merging module is used to determine the continuous feature group corresponding to the data to be detected based on the feature data, and to scale the continuous feature group according to the ratio feature corresponding to the feature data to obtain the feature merged data corresponding to the feature data.

[0043] The attack risk probability determination module is used to determine the attack risk probability corresponding to the feature-merged data using a trained decision tree-based classifier.

[0044] The attack risk probability update module is used to update the attack risk probability based on the latency ratio data and structure call data corresponding to the data to be detected.

[0045] The risk level acquisition module is used to determine the attack risk level corresponding to the data to be detected based on the updated attack risk probability.

[0046] Thirdly, embodiments of the present invention also provide a server, including a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the steps of the network request risk detection method provided in the first aspect.

[0047] Fourthly, embodiments of the present invention also provide a storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the steps of the network request risk detection method provided in the first aspect.

[0048] This invention provides a network request risk detection method, system, and server. In detecting SQL injection risks during network requests, the method first acquires network request data, encodes and converts the network request data using preset sample data, and obtains the data to be detected. Then, it extracts feature data corresponding to the data to be detected based on the injection keyword matching results, network request parameter statistics, and network request character vectorization results. Subsequently, it determines continuous feature groups corresponding to the data to be detected based on the feature data, and scales these continuous feature groups according to the ratio features, obtaining merged feature data. Then, it uses a trained decision tree-based classifier to determine the attack risk probability corresponding to the merged feature data. Next, it updates the attack risk probability based on the latency ratio data and structure call data corresponding to the data to be detected. Finally, it determines the attack risk level corresponding to the data to be detected based on the updated attack risk probability. This method fuses features from the injection keyword matching results, network request parameter statistics, and network request character vectorization results corresponding to the data to be detected, and dynamically optimizes the continuous features in the fused feature data. A lightweight classifier is then used to accurately detect SQL injection risks during network requests.

[0049] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0050] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0051] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0052] Figure 1A flowchart illustrating a network request risk detection method provided in an embodiment of the present invention;

[0053] Figure 2 A flowchart of step S101 of a network request risk detection method provided in an embodiment of the present invention;

[0054] Figure 3 This is a flowchart of a caching mechanism in a network request risk detection method provided in an embodiment of the present invention;

[0055] Figure 4 A flowchart of step S102 of a network request risk detection method provided in an embodiment of the present invention;

[0056] Figure 5 A flowchart of step S103 of a network request risk detection method provided in an embodiment of the present invention;

[0057] Figure 6 A flowchart of step S104 of a network request risk detection method provided in an embodiment of the present invention;

[0058] Figure 7 A flowchart of step S105 of a network request risk detection method provided in an embodiment of the present invention;

[0059] Figure 8 This is a flowchart illustrating the process of updating the attack risk probability using a first update strategy in a network request risk detection method provided by an embodiment of the present invention.

[0060] Figure 9 This is a flowchart illustrating the process of updating the attack risk probability using a second update strategy in a network request risk detection method provided by an embodiment of the present invention.

[0061] Figure 10 A flowchart illustrating another network request risk detection method provided in this embodiment of the invention;

[0062] Figure 11 This is a schematic diagram of the structure of a network request risk detection system provided in an embodiment of the present invention;

[0063] Figure 12 This is a schematic diagram of another network request risk detection system provided in an embodiment of the present invention;

[0064] Figure 13 This is a schematic diagram of the structure of a server provided in an embodiment of the present invention.

[0065] icon:

[0066] 1110 - Data Preprocessing Module; 1120 - Feature Extraction Module; 1130 - Feature Merging Module; 1140 - Attack Risk Probability Determination Module; 1150 - Attack Risk Probability Update Module; 1160 - Risk Level Acquisition Module;

[0067] 101 - Processor; 102 - Memory; 103 - Bus; 104 - Communication interface. Detailed Implementation

[0068] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0069] To facilitate understanding of this embodiment, a network request risk detection method disclosed in this embodiment of the invention will first be described in detail, such as... Figure 1 As shown, the method includes:

[0070] Step S101: Obtain network request data, and after encoding and converting the network request data using preset sample data, obtain the data to be detected corresponding to the network request data.

[0071] First, raw request data from the target network environment is collected. This data typically includes the request URL, request method (GET / POST, etc.), request header information (such as Referer, Content-Type), request parameters, and request body content. Because the raw data formats are diverse (potentially containing text, special symbols, structured parameters, etc.), encoding conversion is performed based on pre-defined sample data. This pre-defined sample data contains numerous labeled normal and abnormal request cases, serving to provide unified data conversion rules (e.g., converting text parameters to numerical encoding, mapping special characters to specific identifiers). Through this conversion, the raw network request data is standardized into uniformly formatted data that can be directly used for subsequent analysis, avoiding the impact of data format differences on detection accuracy.

[0072] Step S102: Extract the feature data corresponding to the data to be detected based on the injection keyword matching results, network request parameter statistics, and network request character vectorization results.

[0073] Based on the data to be detected obtained in step S101, features are extracted from three key dimensions, as follows:

[0074] Keyword injection matching is a rule-based feature extraction process. It uses a pre-defined attack feature library (containing typical keywords for attacks such as SQL injection, XSS, and command injection) to match whether there are suspicious keywords in the data to be detected, and outputs the matching results (such as the number of matches and the matching location).

[0075] Request parameter statistics is a statistical feature extraction process. By quantitatively analyzing the parameters in the request, including the total number of parameters, the character length of a single parameter, the proportion of empty parameters, and the frequency of special symbols (such as single quotes and semicolons), abnormal features at the parameter level (such as parameter lengths that far exceed the normal range) are captured.

[0076] Character vectorization is a vectorized feature extraction process that uses natural language processing techniques (such as Word2Vec and TF-IDF) to convert character sequences in a request (such as URL paths and request body text) into low-dimensional vectors, thereby representing the semantic features of character combinations in a quantitative way (such as unexpected character combinations that may imply malicious intent).

[0077] Finally, by integrating the analysis results from the above three dimensions, feature data that can comprehensively reflect the risk attributes of the data to be tested is formed.

[0078] Step S103: Determine the continuous feature group corresponding to the data to be detected based on the feature data, and scale the continuous feature group according to the ratio feature corresponding to the feature data to obtain the feature merged data corresponding to the feature data.

[0079] From the feature data extracted in step S102, continuous numerical features (such as parameter length, frequency of special symbols, vector dimension values, etc.) are selected to form continuous feature groups. Since continuous feature samples are imbalanced and prone to noise amplification, scaling is required using the corresponding ratio features. For example, SMOTE (Synthetic Minority Over-sampling Technique) can be used to address the sample imbalance problem in continuous feature groups, while StandardScaler can standardize and scale the samples. The samples can be analyzed using TF-IDF (term frequency–inverse document frequency) to obtain corresponding ratio features. Based on these ratios, standardization or normalization methods are used to adjust the continuous feature groups to a uniform numerical scale. Finally, the scaled continuous feature groups are integrated with non-continuous features (such as Boolean results from keyword matching) to form merged feature data.

[0080] Step S104: Use the trained decision tree-based classifier to determine the attack risk probability corresponding to the feature merging data.

[0081] The pre-trained decision tree-based classifier (such as AdaBoost, Random Forest, or XGBoost) is invoked, and the feature merging data obtained in step S103 is input into this classifier. This classifier, through learning from historical labeled data (including samples of normal and attack requests), has developed a stable risk judgment logic (e.g., judging the risk probability corresponding to feature combinations through feature node splitting rules). The attack risk probability output by the classifier (value 0-1) represents the initial probability that the data to be detected is an attack request; the higher the value, the greater the suspicion of risk.

[0082] Step S105: Update the attack risk probability based on the latency ratio data and structure call data corresponding to the data to be detected.

[0083] To overcome the limitations of static feature analysis, two types of dynamic behavioral data are introduced to correct the initial risk probability. The latency ratio data corresponds to the time-based blind SQL injection verification process. By determining whether the network request data contains blind SQL injection keywords, the latency ratio is calculated to characterize whether a time-based blind SQL injection attack has occurred, thereby updating the attack risk probability. The structure call data corresponds to internal API calls and legitimate SQL structures. Internal API calls, legitimate SQL structures, and illegitimate SQL structures each correspond to different attack risk probabilities.

[0084] By integrating dynamic behavioral characteristics, the initial risk probability is updated to a comprehensive risk value that better reflects the actual scenario.

[0085] Step S106: Determine the attack risk level corresponding to the data to be detected by using the updated attack risk probability.

[0086] Based on the updated attack risk probability and the pre-defined risk level classification rules for the business scenario, the final risk level of the data to be detected is determined. For example, less than 0.4 is "low risk", 0.4 to 0.7 is "medium risk", and greater than 0.7 is "high risk". By clearly outputting the risk level, network security personnel are provided with intuitive decision-making basis, enabling precise control over risky requests.

[0087] Optionally, step S101 involves acquiring network request data, encoding and converting the network request data using preset sample data, and then obtaining the data to be detected corresponding to the network request data. Figure 2 As shown, it includes:

[0088] Step S201: After obtaining network request data based on real-time traffic data and historical log data, determine the cached data corresponding to the network request data.

[0089] Network request data is obtained from two core data sources: real-time traffic data (such as dynamic data like HTTP / HTTPS requests and API calls currently being transmitted over the network) and historical log data (such as past request records stored in server logs and firewall logs). By integrating these two types of data, current and historical network request scenarios can be covered, ensuring data comprehensiveness. After obtaining the network request data, the corresponding cached data can be located. Cached data refers to the stored collection of previously processed network request data and transformation results (usually stored in memory or disk cache in key-value pairs). Its purpose is to avoid duplicate processing of repeated requests and improve overall detection efficiency.

[0090] Step S202: Determine whether the cached data contains network request data based on the MD5 hash value corresponding to the network request data.

[0091] To quickly determine whether the currently acquired network request data already exists in the cache, the MD5 hash value corresponding to the network request data (including complete information such as request URL, parameters, and request body) is calculated. Input data of arbitrary length is converted into a hash result of fixed length (128 bits). The probability of different input data generating the same hash value is extremely low, so it can be used as a "unique identifier" for request data.

[0092] By comparing the MD5 hash value of the current request data with the hash value stored in the cache, it is determined whether the cache already contains the request data: if the hash values ​​match, it means that it is a duplicate request and the processing result in the cache can be directly called; if they do not match, the subsequent encoding conversion process needs to be entered.

[0093] Step S203: If the cached data does not contain network request data, then determine the encoding conversion rules and text specification rules corresponding to the network request data based on the sample data corresponding to the decision tree base classifier during the training phase.

[0094] When the cached data does not contain the data for the current network request (i.e., the hash value does not match), encoding conversion rules and text specification rules need to be defined for that request data. These rules are not randomly generated, but are determined based on the sample data used by the decision tree base classifier during the training phase.

[0095] The training sample data contains a large number of labeled normal / abnormal request cases and has been preprocessed according to a unified standard (such as data type conversion, format standardization, etc.). Therefore, the rules for the current request must be consistent with the preprocessing rules of the sample data. Specifically, encoding conversion rules are used to convert non-numerical data (such as text parameters, string identifiers) into numerical or vector data that the model can recognize (for example, mapping request methods such as "GET" and "POST" to numerical values ​​such as "1" and "2"); text standardization rules are used to unify text format (such as removing extra spaces, converting uppercase letters to lowercase, standardizing the representation of special symbols, etc.) to avoid deviations in subsequent feature extraction due to format differences.

[0096] Step S204: After encoding and converting the network request data using encoding conversion rules and text specification rules, the data to be detected corresponding to the network request data is obtained.

[0097] After determining the encoding conversion rules and text standardization rules, specific conversion operations are performed on the current network request data. Specifically, by applying the encoding conversion rules, unstructured / semi-structured data (such as URL paths and request header fields) in the request is converted into structured numerical values ​​or vectors; by applying the text standardization rules, the text content in the request is standardized (such as removing redundant spaces in parameter values) to eliminate formatting noise.

[0098] After the above transformation, the original network request data is processed into "data to be detected" with a uniform format that meets the model input requirements, laying the foundation for subsequent feature extraction and risk detection.

[0099] Optionally, if the cached data contains network request data, the method further includes: determining whether the cached data contains expiration data; if the cached data contains expiration data, determining the attack risk level corresponding to the data to be detected based on the cached data. The specific process described above is as follows: Figure 3 As shown, the HTTP request is identified using real-time traffic data or historical logs. After calculating the HTTP request using MD5 hash, it is determined whether a cache exists. If so, the validity period is checked. If a validity period exists, the attack risk level corresponding to the data to be detected is directly determined based on the cached data. If there is no validity period or no cache exists, further calculation is required.

[0100] Optionally, step S102, which extracts feature data corresponding to the data to be detected based on the injection keyword matching results, network request parameter statistics, and network request character vectorization results, is as follows: Figure 4 As shown, it includes:

[0101] Step S401: Extract the rule feature data corresponding to the data to be detected by using the matching results of SQL injection keywords, special characters and length features of the data to be detected.

[0102] After performing data decoding, cleaning, and truncation on the data to be detected, the keywords, special characters, and length features of the SQL injection are processed and statistically analyzed before feature matching and extraction are performed to obtain the rule feature data corresponding to the data to be detected.

[0103] Specifically, it can call a pre-defined SQL injection keyword feature library to accurately match the request parameters and request body of the data to be tested, recording the number, position, and matching degree of the matched keywords. Special character matching focuses on detecting whether the request contains high-risk special characters (such as single quotes "'", semicolons ";", comment characters "--", backslashes "\", etc.). These characters are often used to construct injection attack payloads. The matching results include the type of special character, its frequency of occurrence, and its distribution position in the parameters. Length feature matching calculates the length of key fields in the request (such as parameter values ​​and request body text) and compares it with the length distribution threshold of historical normal requests (e.g., the normal parameter length of an interface is usually 5-20 characters; if the current parameter length is 500 characters, an anomaly is triggered), outputting features such as whether the length exceeds the limit and the proportion of exceeding the limit.

[0104] By integrating the above three types of matching results, rule feature data is formed. These features are mainly used to capture explicit risks that conform to known attack rules.

[0105] Step S402: Extract the statistical feature data corresponding to the data to be detected using the statistical results of the URL structure, number of parameters, and character type distribution of the data to be detected.

[0106] After URL parsing and parameter separation of the data to be detected, the URL structure, number of parameters, and character type distribution are analyzed and statistically processed before feature matching and extraction are performed to obtain the statistical feature data corresponding to the data to be detected. Specifically, this may involve URL structure statistics (path length, number of " / " separators in the path), parameter entropy values ​​(information entropy calculated based on parameter values), character type distribution (proportion of numbers, letters, and spaces), frequency of specific symbols, and SQL specific pattern marking, etc.

[0107] In real-world scenarios, URL structure statistics need to analyze the URL's hierarchical depth, whether it contains abnormal paths (such as unexpected ".. / " directory traversal symbols), and the matching degree between domain names and subdomains (such as whether it is a spoofed phishing domain name), and output statistical values ​​such as the number of levels, abnormal path identifiers, and domain name matching scores.

[0108] The parameter count process can count the total number of GET request parameters (key-value pairs after "?" in the URL) and POST request parameters (key-value pairs in the request body), calculate the deviation rate from the historical average number of parameters of the same interface, and record the proportion of empty parameters (values ​​of null or empty strings).

[0109] Character type distribution statistics categorize all characters in the request by type (letters, numbers, special symbols, control characters, etc.), calculate the proportion of each type, and count the occurrence frequency of high-frequency abnormal characters. This can be specifically represented by entropy calculation, as shown in the following formula:

[0110] ;

[0111] in, This is the information entropy value; The number of distinct characters in the parameter; For the parameter of the first One character; For characters The probability of occurrence.

[0112] Step S403: Extract the language feature data corresponding to the data to be detected using the character vectorization results of the data to be detected.

[0113] After text normalization of the data to be detected, feature matching and extraction are performed using the character vectorization results of the data to be detected, thereby obtaining the language feature data corresponding to the data to be detected. Specifically, TF-IDF can be used to vectorize characters, and the n-gram algorithm (1-4 dimension combination) can be used to extract key features. In a specific scenario, the maximum number of features in the character set n-gram is 1000.

[0114] Step S404: Determine the feature data corresponding to the data to be detected based on rule feature data, statistical feature data and language feature data.

[0115] To achieve a comprehensive characterization of network request risks, the three types of feature data extracted in the first three steps need to be integrated to form the final feature data. The integrated feature data simultaneously covers known attack rules, statistical patterns in request structures, and semantic features of characters, providing a comprehensive and accurate input foundation for subsequent risk probability calculations.

[0116] Optionally, step S103 involves determining the continuous feature group corresponding to the data to be detected based on the feature data, scaling the continuous feature group according to the ratio feature corresponding to the feature data, and then obtaining the feature merged data corresponding to the feature data. Figure 5 As shown, it includes:

[0117] Step S501: Determine continuous feature groups based on continuous feature data in statistical feature data and language feature data, and determine discrete feature groups corresponding to the data to be detected based on discrete feature data in rule feature data and statistical feature data.

[0118] To achieve targeted feature processing, it is necessary to first divide the feature data extracted in step S102 into continuous feature groups and discrete feature groups. Continuous feature groups are selected from statistical and linguistic feature data. These features are variables with numerical continuity and can take any value within a certain range. Examples include statistical features such as "average parameter length," "proportion of special characters," and "request delay time"; and linguistic features such as "values ​​of each dimension of the character vector" and "semantic similarity score." These features are then integrated to form continuous feature groups.

[0119] Discrete feature groups are discrete feature data selected from regular feature data and statistical feature data. These features are variables that do not have continuous numerical values ​​and are usually represented as classification labels, Boolean values, or finite enumeration values. For example, regular features include "whether it matches SQL injection keywords (0 / 1)" and "whether it contains high-risk special characters (0 / 1)"; statistical features include "request method type (GET=1, POST=2, PUT=3)" and "parameter quantity level (few / medium / many, corresponding to 0 / 1 / 2)". These features are integrated to form discrete feature groups.

[0120] Grouping allows for differentiated processing strategies based on the different characteristics of the two types of features (continuous features are greatly affected by the units of measurement, while discrete features are mostly category identifiers), laying the foundation for subsequent feature scaling and fusion.

[0121] Step S502: Use the synthetic minority oversampling algorithm to obtain the ratio features corresponding to the language feature data, and use the ratio features to scale the continuous feature group to the same scale as the discrete feature group.

[0122] To eliminate the scale difference between continuous and discrete feature groups, the continuous feature groups need to be scaled using ratio features. Specifically, the ratio features are obtained using the Synthetic Minority Oversampling (SMOTE) algorithm to calculate the ratio features corresponding to the language feature data. Originally used to address imbalanced sample problems, SMOTE here synthesizes representative "normal / abnormal feature samples" based on language feature data (such as semantic features of character vectors). By comparing the feature distribution of the synthesized samples with that of the original samples, the "ratio of abnormal features to total features" (such as the proportion of semantically abnormal vector dimensions, the occurrence rate of high-risk character combinations, etc.) is calculated, i.e., the "ratio feature".

[0123] Scaling of continuous feature groups is based on ratio features, scaling the values ​​of continuous feature groups to the same scale as discrete feature groups (usually the [0,1] interval). For example, if the maximum value of a discrete feature is 3 (e.g., the number of parameters), a scaling factor is calculated using ratio features to proportionally map the original values ​​of continuous features (e.g., parameter length 100) to values ​​between 0 and 3. If the discrete features are Boolean values ​​between 0 and 1, a normalization (Min-Max) method is used to compress the continuous features to the [0,1] interval. The core purpose of scaling is to ensure that continuous and discrete features are comparable in magnitude, preventing a particular type of feature from dominating model judgments due to excessively large values.

[0124] Step S503: After merging the scaled continuous feature group with the discrete feature group, the feature merged data corresponding to the feature data is obtained.

[0125] After scaling the continuous feature group, it needs to be integrated with the discrete feature group into a unified feature set, i.e., feature merged data. This data includes both normalized continuous and discrete features, which preserves the original information of the features and eliminates scale differences. This provides high-quality input for the subsequent decision tree-based classifier and improves the accuracy of risk detection.

[0126] Optionally, step S104, which uses the trained decision tree-based classifier to determine the attack risk probability corresponding to the feature-merged data, is as follows: Figure 6 As shown, it includes:

[0127] Step S601: Obtain the trained Adaboost decision tree classifier and input the feature merging data into the Adaboost decision tree classifier.

[0128] First, obtain the Adaboost decision tree base classifier that has been trained. This classifier is not a single decision tree, but an ensemble model built on the "Adaptive Boosting (Adaboost)" algorithm. Its core consists of multiple "weak decision trees" (such as shallow CART trees), and its training process has obvious "adaptive" characteristics.

[0129] During the training phase, the weights of all samples (including labeled samples of normal requests and attack requests) are initialized first, and the first weak decision tree is trained based on the initial weights. Each subsequent weak decision tree focuses on samples that were misclassified by the preceding model (by increasing the weight of misclassified samples and decreasing the weight of correct samples), gradually optimizing the ability to identify "hard-to-classify samples" (such as variant attack requests). Finally, each weak decision tree obtains a "confidence weight" based on its own classification accuracy (the higher the accuracy, the larger the weight, and the stronger the impact on the final result).

[0130] After obtaining the trained classifier, the feature merged data processed in step S103 is input into the model. At this time, it is necessary to ensure that the format of the feature data is completely matched with the input format during model training: for example, the feature dimension (such as a 178-dimensional feature vector) and the numerical range (such as the [0,1] interval) must be consistent with the training samples. This is the core purpose of feature scaling and merging in the previous steps, to avoid abnormal model output due to incompatible inputs.

[0131] Step S602: Determine the attack risk probability corresponding to the feature merging data based on the output of the Adaboost decision tree base classifier.

[0132] The output of the Adaboost decision tree base classifier is not a single result, but rather a "weighted voting result" of multiple weak decision trees. This result needs to be further converted into an attack risk probability. In the initial judgment process of a single weak decision tree, each tree merges data based on the input features and independently outputs a "class judgment" for the request (usually binary: "normal request" is denoted as 0, and "attack request" as 1), along with its "local confidence score" (reflecting the tree's level of confidence in the current judgment). In the weighted fusion process across multiple trees, the "confidence weights" assigned to each tree during training are used to weight and sum the class judgments of all weak decision trees. For example, if a classifier contains 10 weak decision trees, of which 8 trees judge "attack request" (total confidence weight is 0.7) and 2 trees judge "normal request" (total confidence weight is 0.3), then the weighted sum is (weight contribution of 8 trees) - (weight contribution of 2 trees) = 0.7 - 0.3 = 0.4 (the specific calculation logic needs to be combined with the loss function set during model training).

[0133] When the result is normalized to a risk probability, the weighted summation result is mapped to the [0,1] interval to obtain the final "attack risk probability". For example, the sigmoid function can be used to convert the summation result (such as a value between -1 and 1) into a probability value of 0-1. The closer the value is to 1, the higher the probability that the request is an attack request; the closer it is to 0, the more likely it is a normal request.

[0134] In addition, in some scenarios, the probability will be fine-tuned by combining the "uncertainty" of the model output (such as when there is a large divergence in the judgment of multiple trees, the confidence weight distribution is relatively dispersed): for example, if the degree of divergence exceeds the preset threshold (such as the standard deviation of the weight is greater than 0.2), the "confidence" of the final probability will be appropriately reduced, and subsequent steps may need to combine dynamic behavioral features (such as the delay ratio) for further verification.

[0135] The final output attack risk probability will serve as the core basis for subsequent steps (risk probability update, risk level determination), and its accuracy directly depends on the Adaboost ensemble model's comprehensive learning ability of multi-dimensional features.

[0136] In real-world scenarios, the probability of an attack risk is calculated using the following formula:

[0137] ;

[0138] in, Probability of attack risk; This represents the mixed feature vector corresponding to the feature merging data; Number of base classifiers; These are the classifier weights; The output of the base classifier.

[0139] Optionally, step S105, which updates the attack risk probability based on the latency ratio data and structure call data corresponding to the data to be detected, is as follows: Figure 7 As shown, it includes:

[0140] Step S701: Obtain the network request instruction corresponding to the data to be detected, and determine whether the key field corresponding to the network request instruction contains the preset blind injection keyword.

[0141] First, extract the network request instructions corresponding to the data to be detected (including operation instructions in the request parameters, function call statements in the request body, such as SQL query statements, API operation commands, etc.), and focus on the "key fields" in the instructions. These fields are usually the core carriers of attack instructions, such as the "query" parameter in SQL requests and the "action" field in API calls.

[0142] Then, a pre-defined "blind injection keyword library" is used to match and detect key fields. Blind injection keywords are a typical feature of blind injection attacks (injection methods that infer attack results by observing indirect information such as response latency and page changes), and commonly include:

[0143] SQL blind injection keywords: such as "WAITFOR DELAY '0:0:5'" (force database delayed response), "SLEEP(5)" (trigger delay function), "BENCHMARK(1000000,MD5('test'))" (create delay through extensive computation), etc.; other protocol blind injection keywords: such as "$where: 'sleep (5)'" in NoSQL blind injection, "ping -c5" in command injection (create delay through system commands), etc.

[0144] The core purpose of the detection is to determine whether the current request has the potential to be attacked through "delayed feedback", so as to provide a basis for selecting different risk probability update strategies in the future.

[0145] Step S702: If yes, determine the delay ratio data based on the baseline measurement parameters and delay measurement parameters corresponding to the blind injection keywords, and update the attack risk probability according to the first update strategy corresponding to the delay ratio data; if no, determine the structure call data based on the interface call data and SQL structure data corresponding to the data to be detected, and update the attack risk probability according to the second update strategy corresponding to the structure call data.

[0146] Based on the blind injection keyword detection results in step S701, the attack risk probability is updated in two cases to ensure that the correction logic matches the risk characteristics of the request.

[0147] Scenario 1: Contains blind injection keywords, then updates are based on latency ratio data (first update strategy). When a key field is detected to contain blind injection keywords, it indicates that the request may transmit attack results through latency differences. The degree of latency anomaly needs to be quantified using "latency ratio data," and the first update strategy should be applied. The calculation of latency ratio data is achieved through baseline time measurement and injection latency measurement. The baseline measurement parameter refers to the average response latency of normal requests of the same type (such as the same interface and the same operation type) (obtained through historical data statistics, for example, the average normal response latency of a query interface is 200ms); the latency measurement parameter refers to the actual response latency of the current request to be detected (e.g., the response latency of a request detecting blind injection keywords is 3000ms). In this case, the latency ratio data = latency measurement parameter / baseline measurement parameter (in the example above, 3000 / 200 = 15, meaning the latency is 15 times the normal level).

[0148] By setting a delay ratio threshold (e.g., 2.5 times), when the delay ratio exceeds the threshold, the probability is set to 1.0; if the delay ratio does not exceed the threshold, the original probability is maintained. The specific process described above is as follows: Figure 8 As shown, this enables the time-based blind injection verification process.

[0149] Scenario 2: If blind injection keywords are not included, risk correction is performed based on the update of the structure call data (second update strategy). Specifically, as follows... Figure 9 As shown, the probability weights are adjusted based on the internal API and the valid SQL statement. If it is determined to be an internal API call, the probability is set to 0.4; if it is not an internal API call, it is determined whether it is a valid SQL structure. If it is, the probability is set to 0.3; otherwise, the original probability is maintained.

[0150] Optionally, after determining the attack risk level corresponding to the data to be detected based on the updated attack risk probability, the method further includes: saving the attack risk level and the data to be detected to cached data. Figure 10 The flowchart above shows another method for detecting network request risks. The core method of the flowchart is as follows:

[0151] 1. HTTP requests: Real-time traffic data or historical logs;

[0152] 2. Does a cache exist? If it does, return the result directly; otherwise, perform the calculation.

[0153] 3. Data preprocessing: The text to be processed is converted into a suitable and standardized format (specific operations such as simplifying URL encoding, retaining key characters, merging spaces, standardizing length, etc.).

[0154] 4. Rule-based feature extraction: SQL injection keyword detection library, special character detection, and length feature processing;

[0155] 5. Statistical feature extraction: URL structure statistics (path length, number of " / " separators in the path), parameter entropy value (information entropy calculated based on parameter values), character type distribution (proportion of numbers, letters, and spaces), frequency of specific symbols, SQL specific pattern marking, etc.

[0156] 6. TF-IDF: Character set n-gram, maximum number of features 1000;

[0157] 7. Feature concatenation and vector blending: Regular features + statistical features + TF-IDF;

[0158] 8. Feature Grouping: Based on whether the samples are continuous, they are divided into continuous feature groups and discrete feature groups. The continuous portion of TF-IDF + statistical features (such as the proportion of numeric characters) is grouped into continuous feature groups; the discrete portion of regular features + statistical features (such as the number of path levels) is grouped into discrete feature groups.

[0159] 9. Model training phase: SMOTE is used to address the imbalance of continuous samples (TF-IDF, ratio feature in statistical features); StandardScaler is used to standardize and scale continuous samples (TF-IDF, ratio feature in statistical features).

[0160] 10. Adaboost Strong Classifier: The base classifiers are decision trees with a maximum depth of 8, 150 base classifiers, and a learning rate of 0.9; the parameter settings here are as follows: the optimal parameter combination is determined by grid search (GridSearchCV): the decision tree depth max_depth is set to 8: to balance the risk of overfitting and the feature capture ability; the number of base classifiers is set to 150: the minimum number of iterations required to validate accuracy > 99.5%;

[0161] 11. Output SQL Injection Probability: Outputs the attack probability, ranging from 0 to 1;

[0162] 12. Time-based blind injection verification: Calculate the delay ratio based on whether the blind injection keyword is included, and then verify the time-based blind injection attack.

[0163] 13. Risk Correction: Adjust probability weights based on internal API and valid SQL statements;

[0164] 14. Risk Level Output: Output different SQL injection attack levels based on the risk probability.

[0165] In the above process, the SQL injection keywords (36 dimensions, including uppercase and lowercase variations) specifically involved in rule feature extraction and statistical features are as follows: [

[0167] "SELECT", "UNION", "INSERT", "DELETE", "DROP", "OR 1=1", "--", ";", "EXEC", "XP_CMDSHELL",

[0168] "XP_FILEEXIST", "WAITFOR", "SHUTDOWN", "TRUNCATE", "HAVING", "SLEEP","BENCHMARK", "LOAD_FILE",

[0169] "VERSION()", "DATABASE()", "INFORMATION_SCHEMA", "WAITFOR DELAY", "CHAR(", "CONCAT", "PG_SLEEP",

[0170] "OR '1'='1'", "OR \"1\"=\"1\"", "OR `1`=`1`", "IF(", "CASE WHEN", "UPDATEXML", "EXTRACTVALUE",

[0171] "GET_LOCK", "REGEXP_LIKE", "SUBSTR", "SUBSTRING" ]

[0173] The enhanced features (12 dimensions) are as follows:

[0174] 1. Time-based blind injection keywords (SLEEP, WAITFOR, BENCHMARK, PG_SLEEP, GET_LOCK) are counted with a weight of 4.

[0175] 2. Total frequency of occurrence of keywords in time-based blind keyword injection

[0176] 3. Does it include keywords for arbitrary time-based blind injection?

[0177] 4. Does it contain tautological conditions (e.g., OR 1=1, OR '1'='1')?

[0178] 5. Does it contain comment characters (--, #, / *);

[0179] 6. Whether it is an internal API call (including QUERY= or / DATA?);

[0180] 7. Does it include both SELECT and FROM?

[0181] 8. Does it include both INSERT and INTO?

[0182] 9. Request the total number of characters;

[0183] 10. Is the length greater than 200 characters?

[0184] 11. Is the length less than 10 characters?

[0185] 12. Number of words after being separated by spaces.

[0186] The statistical characteristics (20 dimensions) are as follows:

[0187] 1. URL path length (e.g., the number of characters in the / product part);

[0188] 2. The number of ' / ' characters in the path;

[0189] 3. Number of path levels (number of segments separated by ' / ');

[0190] 4. The number of query parameters (e.g., ?id=1&name=a has 2 parameters);

[0191] 5. Information entropy of parameter values ​​(measures randomness);

[0192] 6. Coefficient of variation (standard deviation / mean) of parameter value length;

[0193] 7. Percentage of numeric characters;

[0194] 8. Proportion of alphabetic characters;

[0195] 9. Percentage of spaces;

[0196] 10. Percentage of special symbols (excluding numbers, letters, and spaces);

[0197] 11. = Number of times it appears;

[0198] 12. % frequency of occurrence;

[0199] 13. (Number of occurrences;)

[0200] 14. Number of occurrences;

[0201] 15. Does it contain / *! (a MySQL-specific comment)?

[0202] 16. Does it contain || (logical OR substitution operator)?

[0203] 17. Does it contain @@ (global variable prefix)?

[0204] 18. Does it contain a UNION?

[0205] 19. Does it include WHERE?

[0206] 20. Does it contain VALUES?

[0207] The TF-IDF features (1000 dimensions) are as follows:

[0208] TF-IDF semantic analysis core parameter TfidfVectorizer (

[0209] analyzer="char", # Character-level analysis

[0210] ngram_range=(1, 4), # Combinations of 1-4 metacharacters (e.g., "SE", "LEC", "ECT")

[0211] max_features=1000, # Limit to the top 1000 most important features

[0212] min_df=0.001, # Ignore low-frequency character combinations with an occurrence rate of <0.1%.

[0213] max_df=0.7 # Ignore high-frequency, general-purpose character combinations with an occurrence rate >70% )

[0215] The calculation of the SMOTE-optimized continuous feature samples (TF-IDF and proportional features in statistical features) involved is achieved through the following formula:

[0216] ;

[0217] in, For the optimized sample; This is a minority class sample; The K nearest neighbors are randomly selected. These are uniformly distributed random numbers, ranging from 0 to 1.

[0218] The decision function of the AdaBoost strong classifier is: ;

[0219] ;in, The base classifiers' predicted values ​​are represented by T; T represents the number of base classifiers. The weights are those of the base classifier; Let be the weighted error rate of the t-th base classifier.

[0220] Risk classification rules are implemented using the following formula:

[0221] ;

[0222] In the above formula: for The SQL injection attack risk level of the sample; Output the probability of SQL injection attacks for the strong classifier.

[0223] The network request risk detection method described above involves accessing HTTP request data (real-time traffic / historical logs), loading sample data, and preprocessing the data. Then, it performs hybrid feature extraction based on three types of features (rule-based features, statistical features, and TF-IDF features). Next, it uses the SMOTE algorithm to generate synthetic samples, and then uses a decision tree as the base classifier for AdaBoost ensemble learning to output attack probabilities. Finally, it outputs tiered alerts based on the attack probabilities. This method can quickly identify HTTP requests embedding SQL injection and generate tiered alerts. Through three major innovations—three types of feature extraction (rule-based + statistical + semantic), dynamic sample optimization (feature space SMOTE), and lightweight ensemble learning (AdaBoost)—it solves the problems of real-time performance, generalization, and deployment cost in SQL injection detection.

[0224] Corresponding to the above embodiments of the network request risk detection method, this invention also provides a network request risk detection system, such as... Figure 11 As shown, the system includes:

[0225] The data preprocessing module 1110 is used to acquire network request data, and after encoding and converting the network request data using preset sample data, obtain the data to be detected corresponding to the network request data.

[0226] The feature extraction module 1120 is used to extract feature data corresponding to the data to be detected based on the injection keyword matching results, network request parameter statistics results, and network request character vectorization results of the data to be detected.

[0227] The feature merging module 1130 is used to determine the continuous feature group corresponding to the data to be detected based on the feature data, and to scale the continuous feature group according to the ratio feature corresponding to the feature data to obtain the feature merged data corresponding to the feature data.

[0228] The attack risk probability determination module 1140 is used to determine the attack risk probability corresponding to the feature merging data using a trained decision tree-based classifier.

[0229] The attack risk probability update module 1150 is used to update the attack risk probability based on the latency ratio data and structure call data corresponding to the data to be detected.

[0230] The risk level acquisition module 1160 is used to determine the attack risk level corresponding to the data to be detected based on the updated attack risk probability.

[0231] Specifically, such as Figure 12 The diagram shows another network request risk detection system. The caching module caches the output results based on the HTTP request content to avoid redundant calculations. The data acquisition and preprocessing module receives HTTP request data and performs URL encoding conversion and text normalization by loading sample data (normal and attack samples).

[0232] The three feature extractor modules extract rule features, statistical features, and TF-IDF features. The rule feature extractor matches SQL injection keywords and performs special character statistics. The statistical feature extractor analyzes the URL structure, the number of parameters, and the distribution of character types (the proportion of numbers / letters / symbols). Finally, the TF-IDF feature extractor vectorizes characters and uses an n-gram algorithm (1-4 dimension combination) to extract key features.

[0233] The sample optimization module addresses sample imbalance (such as a high number of normal requests and a low number of SQL injection attacks) through SMOTE. It outputs synthetic data after feature extraction to balance the ratio of normal to attack samples.

[0234] The ensemble learning decision evaluation module uses a decision tree with a maximum depth of 8 as the base classifier for the Adaboost classifier, iteratively trains 150 base classifiers, and sets the learning rate to 0.9.

[0235] Time-based blind injection verification module: Calculates the delay ratio based on whether the blind injection keyword is included, and then verifies the time-based blind injection attack.

[0236] The risk correction module adjusts probability weights based on internal APIs and valid SQL statements.

[0237] The risk classification output module outputs the risk classification status of the input HTTP request data, which can be categorized as high, medium, low, or information level.

[0238] As can be seen from the above network request risk detection system, the system performs feature fusion on the injection keyword matching results, network request parameter statistics results, and network request character vectorization results corresponding to the data to be detected. After dynamically optimizing the continuous features in the fused feature data, a lightweight classifier is used to accurately detect SQL injection risks in the network request process.

[0239] The network request risk detection system provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned network request risk detection method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned network request risk detection method embodiment.

[0240] This embodiment also provides a server, the structural diagram of which is shown below. Figure 13 As shown, the device includes a processor 101 and a memory 102; wherein the memory 102 is used to store one or more computer instructions, which are executed by the processor to implement the steps of the network request risk detection method described above.

[0241] Figure 13 The server shown also includes a bus 103 and a communication interface 104. The processor 101, the communication interface 104, and the memory 102 are connected via the bus 103.

[0242] The memory 102 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. The bus 103 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 13 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0243] The communication interface 104 is used to connect to at least one user terminal and other network units through a network interface, and to send encapsulated IPv4 packets or IPv4 packets to the user terminal through the network interface.

[0244] Processor 101 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 101 or by instructions in software form. The processor 101 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 102. The processor 101 reads the information in memory 102 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0245] This invention also provides a storage medium storing a computer program, which, when executed by a processor, performs the steps of the network request risk detection method described in the foregoing embodiments.

[0246] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, devices, and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

[0248] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0250] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for detecting network request risks, characterized in that, The method includes: Obtain network request data, and after encoding and converting the network request data using preset sample data, obtain the data to be detected corresponding to the network request data; Based on the injection keyword matching results, network request parameter statistics, and network request character vectorization results corresponding to the data to be detected, feature data corresponding to the data to be detected is extracted. Based on the feature data, a continuous feature group corresponding to the data to be detected is determined. After scaling the continuous feature group according to the ratio feature corresponding to the feature data, the feature merged data corresponding to the feature data is obtained. The attack risk probability corresponding to the feature merging data is determined using a pre-trained decision tree-based classifier; the decision tree-based classifier is the Adaboost decision tree-based classifier; the attack risk probability is calculated using the following formula: ； in, The probability of the attack risk; This refers to the mixed feature vector corresponding to the feature-merged data; Number of base classifiers; These are the classifier weights; The output of the base classifier; The attack risk probability is updated based on the latency ratio data and structure call data corresponding to the data to be detected; The attack risk level corresponding to the data to be detected is determined by the updated attack risk probability. The steps for extracting feature data corresponding to the data to be detected based on the injection keyword matching results, network request parameter statistics, and network request character vectorization results include: The rule feature data corresponding to the data to be detected is extracted by using the matching results of SQL injection keywords, special characters and length features of the data to be detected; Statistical feature data corresponding to the data to be detected is extracted using statistical results of the URL structure, number of parameters, and character type distribution of the data to be detected; The language feature data corresponding to the data to be detected is extracted using the character vectorization result of the data to be detected; The feature data corresponding to the data to be detected is determined based on the rule feature data, the statistical feature data, and the language feature data; The steps of determining the continuous feature group corresponding to the data to be detected based on the feature data, scaling the continuous feature group according to the ratio feature corresponding to the feature data, and obtaining the feature merged data corresponding to the feature data include: The continuous feature group is determined based on the continuous feature data in the statistical feature data and the language feature data, and the discrete feature group corresponding to the data to be detected is determined based on the discrete feature data in the rule feature data and the discrete feature data in the statistical feature data; The ratio feature corresponding to the language feature data is obtained by using a synthetic minority oversampling algorithm, and the continuous feature group is scaled to the same scale as the discrete feature group using the ratio feature; After merging the scaled continuous feature group with the discrete feature group, the feature merged data corresponding to the feature data is obtained; The step of updating the attack risk probability based on the latency ratio data and structure call data corresponding to the data to be detected includes: Obtain the network request instruction corresponding to the data to be detected, and determine whether the key field corresponding to the network request instruction contains a preset blind injection keyword; If yes, then the latency ratio data is determined based on the baseline measurement parameters and latency measurement parameters corresponding to the blind injection keyword, and the attack risk probability is updated according to the first update strategy corresponding to the latency ratio data; if no, then the structure call data is determined based on the interface call data and SQL structure data corresponding to the data to be detected, and the attack risk probability is updated according to the second update strategy corresponding to the structure call data.

2. The network request risk detection method according to claim 1, characterized in that, The steps of acquiring network request data, encoding and converting the network request data using preset sample data, and obtaining the data to be detected corresponding to the network request data include: After obtaining the network request data based on real-time traffic data and historical log data, the cached data corresponding to the network request data is determined. Determine whether the cached data contains the network request data based on the MD5 hash value corresponding to the network request data. If the cached data does not contain the network request data, then the encoding conversion rules and text specification rules corresponding to the network request data are determined based on the sample data corresponding to the decision tree base classifier during the training phase. After encoding and converting the network request data using the encoding conversion rules and the text specification rules, the data to be detected corresponding to the network request data is obtained.

3. The network request risk detection method according to claim 2, characterized in that, If the cached data contains the network request data, the method further includes: Determine whether the cached data contains expiration date data; If the cached data contains the expiration date data, then the attack risk level corresponding to the data to be detected is determined based on the cached data.

4. The network request risk detection method according to claim 1, characterized in that, The step of determining the attack risk probability corresponding to the feature merging data using a pre-trained decision tree-based classifier includes: Obtain the trained Adaboost decision tree base classifier and input the feature merged data into the Adaboost decision tree base classifier; The attack risk probability corresponding to the feature merging data is determined based on the output of the Adaboost decision tree-based classifier.

5. The network request risk detection method according to claim 2, characterized in that, After determining the attack risk level corresponding to the data to be detected based on the updated attack risk probability, the method further includes: The attack risk level and the data to be detected are saved to the cache data.

6. A network request risk detection system, characterized in that, The system includes: The data preprocessing module is used to acquire network request data, and after encoding and converting the network request data using preset sample data, obtain the data to be detected corresponding to the network request data. The feature extraction module is used to extract feature data corresponding to the data to be detected based on the injection keyword matching results, network request parameter statistics results, and network request character vectorization results corresponding to the data to be detected. The feature merging module is used to determine the continuous feature group corresponding to the data to be detected based on the feature data, and to scale the continuous feature group according to the ratio feature corresponding to the feature data to obtain the feature merged data corresponding to the feature data. The attack risk probability determination module is used to determine the attack risk probability corresponding to the feature merging data using a pre-trained decision tree-based classifier; the decision tree-based classifier is the Adaboost decision tree-based classifier; the attack risk probability is calculated using the following formula: ； in, The probability of the attack risk; This refers to the mixed feature vector corresponding to the feature-merged data; Number of base classifiers; These are the classifier weights; The output of the base classifier; The attack risk probability update module is used to update the attack risk probability based on the latency ratio data and the structure call data corresponding to the data to be detected. The risk level acquisition module is used to determine the attack risk level corresponding to the data to be detected based on the updated attack risk probability. The feature extraction module is further configured to: extract rule feature data corresponding to the data to be detected using the matching results of SQL injection keywords, special characters, and length features of the data to be detected; extract statistical feature data corresponding to the data to be detected using the statistical results of the URL structure, number of parameters, and character type distribution of the data to be detected; extract language feature data corresponding to the data to be detected using the character vectorization results of the data to be detected; and determine the feature data corresponding to the data to be detected based on the rule feature data, the statistical feature data, and the language feature data. The feature merging module is further configured to: determine the continuous feature group based on the continuous feature data in the statistical feature data and the language feature data, and determine the discrete feature group corresponding to the data to be detected based on the discrete feature data in the rule feature data and the statistical feature data; obtain the ratio feature corresponding to the language feature data using a synthetic minority oversampling algorithm, and scale the continuous feature group to the same scale as the discrete feature group using the ratio feature; merge the scaled continuous feature group with the discrete feature group to obtain the feature merged data corresponding to the feature data; The attack risk probability update module is further configured to: obtain the network request instruction corresponding to the data to be detected, determine whether the key field corresponding to the network request instruction contains a preset blind injection keyword; if so, determine the latency ratio data based on the benchmark measurement parameters and latency measurement parameters corresponding to the blind injection keyword, and update the attack risk probability according to the first update strategy corresponding to the latency ratio data; if not, determine the structure call data based on the interface call data and SQL structure data corresponding to the data to be detected, and update the attack risk probability according to the second update strategy corresponding to the structure call data.

7. A server, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the steps of the network request risk detection method according to any one of claims 1 to 5.

Images