An API security vulnerability dynamic detection method based on abnormal monitoring

Abstract

The application discloses an API security vulnerability dynamic monitoring method based on abnormal monitoring, and belongs to the technical field of computer security protection, which comprises the following steps: obtaining request layer data and response layer data of a target API, and generating a traffic data set; extracting behavior features from the traffic data set, and generating a behavior feature matrix; performing context awareness analysis on the behavior feature matrix, combining a business object mapping relationship to generate a vulnerability chain prediction result; analyzing vulnerability path nodes in the vulnerability chain prediction result, and generating temporary detection rules; using the temporary detection rules to perform real-time detection on subsequent API requests, and outputting a security detection result. The application adopts a traffic feature extraction, vulnerability chain prediction and self-adaptive rule generation mechanism, and can realize real-time threat interception and continuous optimization of security protection closed loop associated with business context.

Description

Technical Field

[0001] This invention relates to the field of computer security protection technology, and in particular to a dynamic detection method for API security vulnerabilities based on anomaly monitoring. Background Technology

[0002] Modern distributed systems widely use application programming interfaces (APIs) as the core channel for service interaction, and their security directly affects the stability of business systems. With the popularization of microservice architecture, the complexity of API calls is increasing daily, and traditional security protection methods based on fixed rule bases are facing new technical challenges.

[0003] Existing technologies primarily employ static rule matching and signature detection mechanisms, comparing API traffic patterns using a predefined attack signature database. Some solutions combine basic resource monitoring metrics to set fixed threshold alarms, or rely on manually configured business whitelists to filter normal traffic.

[0004] However, these traditional methods exhibit significant limitations in addressing modern API security challenges. Static rule bases struggle to adapt to dynamic combinations and changes in API parameters, leading to delays in detecting new vulnerabilities; resource consumption monitoring becomes disconnected from business logic, failing to distinguish between normal business peaks and malicious resource exhaustion attacks; and rules with fixed validity periods tend to generate a large amount of redundant historical rules, resulting in wasted system resources and decreased detection efficiency. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a dynamic API security vulnerability detection method based on anomaly monitoring. It employs traffic feature extraction, vulnerability chain prediction, and adaptive rule generation mechanisms to achieve a closed-loop security protection system that combines real-time threat interception with continuous optimization based on business context.

[0006] The above objectives can be achieved through the following approach:

[0007] A dynamic API security vulnerability detection method based on anomaly monitoring includes: acquiring request layer data and response layer data of the target API to generate a traffic dataset; extracting behavioral features from the traffic dataset to generate a behavioral feature matrix; performing context-aware analysis on the behavioral feature matrix and generating vulnerability chain prediction results by combining business object mapping relationships; parsing the vulnerability path nodes in the vulnerability chain prediction results to generate temporary detection rules; using the temporary detection rules to perform real-time detection on subsequent API requests and outputting security detection results.

[0008] Optionally, the generation of the behavioral feature matrix includes: extracting API request parameters from the traffic dataset, counting the frequency of occurrence of each parameter combination, and generating parameter combination entropy; extracting resource consumption indicators from the traffic dataset, calculating the slope of change in resource consumption rate, and generating resource consumption slope; parsing the call sequence between APIs from the traffic dataset, counting the co-occurrence of API calls, and calculating context dependency.

[0009] The parameter combination entropy, the resource consumption slope, and the context dependency are aggregated to generate a behavioral feature matrix.

[0010] Optionally, generating the vulnerability chain prediction result includes: mapping the abnormal parameter combination of the parameter combination entropy to a business object to generate a risk operation identifier; associating the historical operation records of the risk operation identifier with the risk operation identifier to calculate the risk weight; combining the resource consumption slope and the risk weight, and combining user historical behavior data and API call chain information to perform a comprehensive risk assessment and generate the vulnerability chain prediction result.

[0011] Optionally, generating temporary detection rules includes: extracting key detection elements of vulnerability path nodes from the vulnerability chain prediction results and constructing rule content; analyzing the time decay mechanism and calculating the validity period parameter; and combining the rule content and the validity period parameter to generate temporary detection rules.

[0012] Optionally, the calculation of the validity period parameter includes: monitoring the triggering frequency of the temporary detection rule to obtain triggering frequency data; extending the validity period parameter when the triggering frequency data exceeds a preset threshold; shortening the validity period parameter when the triggering frequency data is lower than the preset threshold; and automatically deleting the temporary detection rule when the validity period parameter reaches zero.

[0013] Optionally, the step of using the temporary detection rules to perform real-time detection on subsequent API requests includes: loading the temporary detection rules into a memory detection queue; performing rule matching on the received API requests to generate matching results; triggering a security response action when the matching result is high-risk; and recording the matching result and the security response action to generate a detection log.

[0014] Optionally, the triggering of the security response action includes: determining whether the high-risk API request triggers the connection blocking condition and generating a connection blocking instruction; executing the connection blocking instruction to disconnect the connection channel of the high-risk API request and generating a connection blocking event; parsing the session information of the high-risk API request, adding a session tag, and generating a session tag identifier; storing the complete traffic data of the high-risk API request, performing traffic replication, and generating traffic backup data.

[0015] Optionally, the method further includes: recording false alarm data in the security detection results and organizing them into a false alarm event set; analyzing the common feature patterns in the false alarm event set and generating a false alarm feature set; adjusting the prediction weight configuration of the context-aware analysis based on the false alarm feature set to obtain an optimized prediction weight configuration; and changing the generation method of the temporary detection rules according to the optimized prediction weight configuration.

[0016] Optionally, the method of changing the generation of temporary detection rules includes: reducing the detection weight of relevant rules for high-frequency false alarm features to generate adjusted rule detection weights; evaluating the effective time range of the associated temporary detection rules and shortening the validity period parameter; extracting features for new attack patterns, increasing the generation priority weight of relevant rules, and generating higher priority rule generation weights; summarizing the adjusted rule detection weights, the validity period parameter, and the higher priority rule generation weights to generate a detection rule adjustment scheme, and updating the strategy library.

[0017] Based on the same inventive concept, this invention also provides a dynamic API security vulnerability detection system based on anomaly monitoring. The system includes: a traffic probe module for acquiring request-layer and response-layer data of the target API to generate a traffic dataset; a feature extraction module for extracting behavioral features from the traffic dataset to generate a behavioral feature matrix; a risk prediction module for performing context-aware analysis on the behavioral feature matrix and generating vulnerability chain prediction results by combining business object mapping relationships; a rule generation module for parsing vulnerability path nodes in the vulnerability chain prediction results to generate temporary detection rules; and a real-time detection module for using the temporary detection rules to perform real-time detection on subsequent API requests and output security detection results.

[0018] Compared with the prior art, the present invention has the following advantages:

[0019] This invention constructs a full-link dynamic monitoring mechanism, which generates a behavior feature matrix by collecting data from the request and response layers in real time, and accurately identifies abnormal behavior patterns by combining context-aware analysis, significantly improving the predictive ability of complex attack chains and effectively reducing the risk of missed detections caused by dynamic changes in the environment in traditional solutions.

[0020] An innovative business object mapping mechanism is introduced, which associates abnormal parameters at the technical layer with risk operation identifiers of business entities, and integrates historical behavior data and call chain information for comprehensive risk assessment. This enables in-depth correlation analysis between technical vulnerabilities and business scenarios, significantly reducing the false judgment rate.

[0021] An adaptive rule lifecycle management strategy is adopted, which dynamically adjusts the validity period of temporary detection rules based on a time decay mechanism, and intelligently expands and shrinks the validity period parameter according to the rule triggering frequency, thereby optimizing system resource utilization while ensuring continuous protection against high-risk vulnerabilities.

[0022] Establish a closed-loop optimization system for false alarm feedback. By analyzing the characteristics and patterns of false alarm events, adjust the prediction weight configuration in reverse and prioritize the generation of detection rules for new attack patterns, thereby forming a continuously evolving security protection capability.

[0023] 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 may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart illustrating a dynamic detection method for API security vulnerabilities based on anomaly monitoring, according to an embodiment of the present invention.

[0026] Figure 2 This is a radar chart of the API behavior feature matrix according to an embodiment of the present invention.

[0027] Figure 3 This is a time-series curve of the comprehensive risk score according to an embodiment of the present invention.

[0028] Figure 4 This is a heatmap showing the distance between the feature vectors of false alarm events in an embodiment of the present invention.

[0029] Figure 5 This is a schematic diagram of the structure of an API security vulnerability dynamic detection system based on anomaly monitoring, according to an embodiment of the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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.

[0031] Reference Figure 1 One embodiment of the present invention proposes a dynamic detection method for API security vulnerabilities based on anomaly monitoring. It adopts traffic feature extraction, vulnerability chain prediction and adaptive rule generation mechanism, which can realize a closed loop of real-time threat interception and continuous optimization of security protection based on business context.

[0032] The method described in this embodiment specifically includes:

[0033] Obtain request and response layer data from the target API to generate a traffic dataset;

[0034] Specifically, traffic probes capture end-to-end API interaction data, including request layer parameter values, timestamps, and response layer resource consumption metrics. The raw traffic logs are then integrated by time series and stored as a structured traffic dataset.

[0035] Extract behavioral features from the traffic dataset to generate a behavioral feature matrix;

[0036] Specifically, the combined rate of change of API parameters is calculated to generate parameter combination entropy, the rate of resource consumption is monitored to generate slope values, and API call dependencies are analyzed to generate context dependencies. These three are then normalized and aggregated into a behavioral feature matrix.

[0037] Context-aware analysis is performed on the behavioral feature matrix, and vulnerability chain prediction results are generated by combining the business object mapping relationship;

[0038] Specifically, abnormal parameter combinations are mapped to business objects to generate risk operation identifiers; historical operation records of these objects are associated to calculate risk weights; and a comprehensive risk score is calculated using a weighted formula, combining resource consumption slope, user behavior patterns, and API call chain information. If the score exceeds a threshold, the vulnerability chain prediction result is output. The vulnerability chain prediction result is a JSON object, formatted as follows:

[0039]

[0040]

[0041] Among them, path_nodes is the sequence of vulnerability path nodes. The subsequent rule generation module will parse these nodes and extract information such as identifier, node_type and critical_elements as rule content.

[0042] Parse the vulnerability path nodes in the vulnerability chain prediction results to generate temporary detection rules;

[0043] Specifically, key elements of vulnerability path nodes in the vulnerability chain prediction results are extracted to construct logical detection conditions; the validity period of the rules is calculated based on the time decay mechanism (the initial value is set as needed and dynamically adjusted according to the triggering frequency); and temporary rules are generated by combining the detection conditions and validity period parameters.

[0044] The temporary detection rules are used to perform real-time detection on subsequent API requests, and the security detection results are output.

[0045] Specifically, temporary rules are loaded into an in-memory hash table to form a detection queue. The received API requests are matched against the rules. If a high-risk match is found, blocking or alarm actions are triggered, and request details and response logs are recorded.

[0046] By accurately identifying complex attack chains through contextual analysis, the proactive defense capabilities against API security threats can be significantly improved, effectively reducing the risk of false positives and false negatives. Specifically, this method can adaptively generate temporary rules and dynamically match the vulnerability lifecycle, avoiding the lag of traditional static rule bases. Simultaneously, its real-time detection mechanism achieves millisecond-level response while ensuring high system throughput. The resulting continuously optimized security protection loop significantly enhances the system's ability to defend against unknown vulnerabilities.

[0047] Optionally, the generated behavioral feature matrix includes:

[0048] Extract API request parameters from the traffic dataset, count the frequency of occurrence of each parameter combination, and generate parameter combination entropy;

[0049] Specifically, the first step is to obtain the traffic dataset for the target API. This dataset contains request-layer data and response-layer data. The request-layer data includes API parameter values ​​and timestamps, while the response-layer data includes resource consumption metrics such as CPU utilization or memory usage. To calculate the rate of change of API parameter combinations, it is necessary to extract parameter combinations from all API requests in the traffic dataset. A parameter combination refers to the combination of multiple parameter values ​​in the same request. The frequency of occurrence of each parameter combination is then calculated, and its probability p is determined. i ,in Count i Let be the number of occurrences of the i-th parameter combination, and N be the total number of requests. Next, the entropy H of the parameter combination is calculated using the information entropy formula:

[0050] H=-∑p i log2(p i ),

[0051] Where ∑ represents the summation over all possible combinations of parameters, log2 is the logarithm to the base 2, and p i Obtained from statistical flow datasets, the H value reflects the diversity of parameter combinations, and abnormally high values ​​indicate that the parameter combinations are unstable.

[0052] Extract resource consumption indicators from the traffic dataset, calculate the slope of the change in resource consumption rate, and generate a resource consumption slope.

[0053] Specifically, when monitoring changes in resource consumption rate, the resource consumption y and corresponding timestamp t are extracted from the response layer data of the traffic dataset. The resource consumption y is expressed as a percentage, such as CPU utilization. The resource consumption slope k is calculated using a linear regression method, with the following formula:

[0054]

[0055] Among them, t j For the j-th time point, y j This corresponds to the amount of resources consumed. and These are the average values ​​of time points and resource consumption, respectively. n is the number of data points. The average value is calculated from the traffic dataset using a sliding window. The slope k represents the trend of resource consumption rate, with a positive value indicating accelerated consumption.

[0056] Parse the call sequences between APIs from the traffic dataset, count the co-occurrence of API calls, and calculate the context dependency.

[0057] Specifically, when analyzing API call dependencies, the API call sequence in the traffic dataset is parsed to identify the call relationships between APIs, such as API A calling API B; the number of call events is counted, and the context dependency D is calculated using the formula: Here, count(API A and API B) represents the number of times API A calls API B, and count(API A) represents the total number of times API A is called. These values ​​are obtained through log analysis. The D value quantifies the dependency strength, with a high value indicating a strong association.

[0058] The parameter combination entropy, the resource consumption slope, and the context dependency are aggregated to generate a behavioral feature matrix.

[0059] Specifically, before the aggregation step, the parameter combination entropy H, resource consumption slope k, and context dependency D need to be normalized to eliminate dimensional differences. The normalization formula is x norm =(xx) min ) / (x max -x min ), where x norm Here are the normalized eigenvalues, where x represents each eigenvalue. min and x max The minimum and maximum values ​​in the traffic dataset are given; after normalization, the parameter combination entropy H is calculated. norm Resource consumption slope knorm and context dependency D norm Combined into a behavioral feature matrix M, matrix M is in row vector form [H norm ,k norm D norm [] represents the set of behavioral characteristics for each API instance. For example... Figure 2 As shown, the API instance exhibits a normalized feature distribution across three dimensions: parameter combination entropy, resource consumption slope, and context dependency, reflecting the technical concept of aggregating multidimensional behavioral features.

[0060] For example, in an order API detection scenario of an e-commerce system, the traffic dataset contains 1000 request data entries, with parameters including user_id and item_id. Resource consumption is measured by CPU utilization, and the dependency involves payment API calls. First, the frequency of occurrence of parameter combinations such as user_id=123 and item_id=456 is statistically analyzed, and the probability p is calculated. i (For example, if this combination appears 50 times and there are a total of 1000 requests, then p) i =0.05), substituting into the entropy formula H=-∑p i log2(p i We obtain H = 1.2; secondly, we extract the CPU utilization y and corresponding time t (in seconds) from the response data, and calculate the slope k in a 10-second window, for example, t = [1, 2, 3], y = [10%, 20%, 30%], and the mean. Then k = [(1-2)×(10-20)+(2-2)×(20-20)+(3-2)×(30-20)] / [(1-2)] 2 +(2-2) 2 +(3-2) 2

[10] ; Next, analyze the call logs and count the co-occurrence of the order API calling the payment API as 300 times, with a total of 400 calls to the order API. Therefore, the dependency D = 300 / 400 = 0.75; During normalization, assume H... min =0.5,H max =2.0,k min =-5,k max =15,D min =0,D max =1, calculate H norm =(1.2-0.5) / (2.0-0.5)=0.47,k norm =(10-(-5)) / (15-(-5))=0.75,D norm=0.75, and the aggregated behavioral feature matrix M = [0.47, 0.75, 0.75]. High-frequency abnormal combinations of user_id and item_id are captured through parameter combination entropy; resource consumption slope promptly reflects sudden CPU spikes; context dependency identifies payment call anomalies; and the overall feature matrix effectively supports subsequent vulnerability prediction. In real-world e-commerce environments, it can proactively defend against attacks such as fraudulent order placement or resource exhaustion vulnerabilities, improving system security while avoiding misjudgments caused by inconsistent feature dimensions.

[0061] Optionally, the generated vulnerability chain prediction result includes:

[0062] Map the abnormal parameter combinations of the parameter combination entropy to business objects to generate risk operation identifiers;

[0063] Specifically, firstly, the parameter combination entropy H and resource consumption slope k are obtained. Parameter combination entropy H represents the degree of abnormality in the diversity of API parameter combinations, and resource consumption slope k represents the trend of resource consumption rate changes. Next, abnormal parameter combinations in parameter combination entropy H are identified by setting a threshold, for example, when H exceeds a preset threshold such as 1.5, it is judged as abnormal. These abnormal parameter combinations, such as specific value pairs of user_id and item_id, are extracted from the traffic dataset. Then, the abnormal parameter combinations are mapped to business objects, which refer to the entities involved in the API, such as user accounts or orders. By querying the business database, the parameter values ​​are associated with specific object entities, such as user ID = 123, generating risk operation identifiers such as high-risk user operation identifiers. The business object mapping relationship can be established in the following way: First, the developers or operations personnel provide an initial configuration file, which defines the association between the API's key parameters (such as user_id, order_id) and their corresponding backend business entities (such as "user table", "order table") in JSON or XML format. Furthermore, this system can monitor updates to API documentation (such as Swagger / OpenAPI specifications), automatically parse the parameter descriptions and data models within them, and incrementally update this mapping relationship library.

[0064] Calculate the risk weight by associating the historical operation records with the aforementioned risk operation identifier;

[0065] Specifically, the historical operation records associated with the risk operation identifier, which refer to past operation events of the object extracted from the system log, such as login count or transaction frequency, are used to calculate the risk weight W, with the formula W = (f / f max )*c, where f represents the event frequency, which is the number of risk events in the historical record, such as the number of failed login attempts, obtained through log statistics; f maxrepresents the maximum frequency, which is the maximum value of this type of event in the log; c represents the severity coefficient, which is derived from the extraction and analysis of historical attack event data in the system security log. It is determined by statistically analyzing the degree of harm caused by different risk event types (such as failed login, abnormal parameter combinations) in actual attacks; the risk weight W is normalized to the range of 0 to 1 to represent the degree of risk.

[0066] By combining the resource consumption slope and the risk weight, along with user historical behavior data and API call chain information, a comprehensive risk assessment is conducted to generate vulnerability chain prediction results.

[0067] Specifically, the risk assessment combines resource consumption slope k, risk weight W, user historical behavior data, and API call chain information. User historical behavior data includes user activity patterns such as average request frequency, obtained from the user profile database. API call chain information refers to the sequence of API calls, such as the order API calling the payment API, parsed from call logs. When conducting a comprehensive risk assessment, all inputs are first normalized, as shown in the formula y. norm =(yy) min ) / (y max -y min ), where y represents k, W, user behavior score or call chain strength, y min and y max To find the minimum and maximum values ​​in the training dataset, user behavior scores are calculated based on historical data, such as the proportion of abnormal user operations, and call chain strength is calculated based on dependency D, such as call frequency. Then, the comprehensive risk formula S = α*k is applied. norm +β*W norm +γ*B norm +δ*D norm Where α, β, γ, and δ are weighting coefficients, initially set to 0.25, which can be determined through offline training. Specifically, a historical labeled dataset containing known normal traffic and attack traffic is collected. The comprehensive risk score S is used as the model output. The goal is to maximize the AUC (area under the ROC curve) or F1-score. Optimization algorithms (such as gradient descent and grid search) are used to automatically find the optimal set of weighting coefficients, while α+β+γ+δ=1 to ensure dimensional consistency; S is the comprehensive risk score, k norm W represents the normalized slope of resource consumption. norm B is the normalized risk weight. norm D is the normalized user behavior score. norm This represents the normalized call chain strength. Finally, based on S, a vulnerability chain prediction result is generated. A vulnerability chain refers to a potential attack path, such as an SQL injection chain. When S exceeds a threshold, the prediction result, such as a sequence of vulnerability path nodes, is output. Figure 3As shown, the comprehensive risk score changes dynamically over time, and when it exceeds the threshold, it is automatically judged as high risk, triggering the vulnerability chain prediction and response mechanism.

[0068] For example, in a bank system's transfer API detection scenario, the input parameter combination entropy H = 1.8 (abnormal, threshold 1.5), and the resource consumption slope k = 12 (indicating accelerated CPU consumption). First, abnormal parameter combinations such as from_account = 456 and to_account = 789 are identified, mapping the business objects to account IDs 456 and 789, generating a risk operation identifier for high-risk transfer operations. Historical operation records are correlated, and log queries reveal that this account has had 5 failed transfers in the past 24 hours (event frequency = 5), the system's maximum failed transfer frequency is 10, and the severity coefficient c = 1.2. The risk weight W = (5 / 10) * 1.2 = 0.6 is calculated. Combined with user historical behavior data, such as the user's average request frequency of 2 times / minute (score 0.4), and API call chain information such as the dependency D of the transfer API calling the verification API (call chain strength) = 0.8, normalization is assumed to be k. min =0,k max =20,W min =0,W max =1,B min =0,B max =1,D min =0,D max =1, thus obtaining k norm =12 / 20=0.6,W norm =0.6,B norm =0.4,D norm =0.8. The comprehensive risk formula S = 0.25 × 0.6 + 0.25 × 0.6 + 0.25 × 0.4 + 0.25 × 0.8 = 0.6. Exceeding the threshold of 0.5 generates a vulnerability chain prediction result, such as an account theft vulnerability path. High-risk transfer operations are accurately identified through business object mapping, and historical data weighting improves the reliability of risk assessment. The comprehensive model effectively predicts potential theft chains, proactively preventing fund security threats in actual banking systems while avoiding unreasonable risk scoring caused by unnormalized features.

[0069] Optionally, the generation of temporary detection rules includes:

[0070] Extract key detection elements from the vulnerability path nodes in the vulnerability chain prediction results and construct rule content;

[0071] Specifically, vulnerability path nodes are obtained from the vulnerability chain prediction results. Vulnerability path nodes represent key steps or entities in a potential attack path. Key detection elements are extracted, including abnormal parameter combinations, resource consumption patterns, or API call dependencies, which are obtained by parsing the attribute data of vulnerability path nodes. Rule content is constructed, which consists of logical judgment statements, such as determining a risk if a request parameter contains a specific value.

[0072] Analyze the time decay mechanism and calculate the validity period parameters;

[0073] Specifically, we analyze the time decay mechanism, which refers to the decreasing validity of a rule over time; we calculate the validity period parameter T using the formula T = T0 * e -λt Where T0 is the initial validity period preset value, such as 3600 seconds, which is dynamically configured according to the risk level library of the business object. This risk level library is pre-calculated and generated by the average response cycle of historical vulnerability events; λ is the decay factor, which is related to the average life cycle of the attack type targeted by the rule, and can be obtained by analyzing the duration distribution of similar historical attack events; t is the time difference from the start of rule generation, calculated in real time in seconds; T represents the remaining validity period.

[0074] By combining the rule content and the validity period parameter, a temporary detection rule is generated.

[0075] Specifically, by combining the rule content and validity period parameters, a temporary detection rule is generated. The rule includes detection conditions and validity period metadata.

[0076] For example, in a refund API detection scenario of an online payment system, the vulnerability chain prediction result indicates that the vulnerability path node is a high-risk user ID = 888; the key detection element extracted is user ID = 888 and resource consumption slope k > 8; the rule content is constructed to trigger a high-risk alarm when user_id = 888 and k > 8 in the API request. The initial validity period T0 = 1200 seconds, the decay factor λ = 0.0005 (calculated based on the average validity period data of rules in the past three months), and when the time difference t = 0 seconds, T = 1200 × e is calculated. 0 =1200. Combine and generate temporary detection rules. Accurately locate high-risk user behavior through key detection elements, and automatically adjust the rule validity period through a time decay mechanism. In a real payment environment, this effectively prevents attacks such as malicious refunds, while avoiding invalid rules from occupying system resources for a long time, thus improving overall security response efficiency.

[0077] Optionally, the calculation of the validity period parameter includes:

[0078] Monitor the triggering frequency of the temporary detection rule to obtain triggering frequency data;

[0079] Specifically, first, the current validity period parameter T is obtained from the temporary detection rule; then, the trigger frequency of this rule is monitored in real time. The trigger frequency refers to the number of times the rule is successfully matched per unit time, which is obtained through detection log statistics, with a calculation period of a fixed time window, such as 5 minutes; thus, the trigger frequency data f is obtained. c The unit is times per minute.

[0080] When the trigger frequency data exceeds a preset threshold, the validity period parameter is extended;

[0081] Specifically, the preset high and low thresholds are f respectively. high and f low The frequency is set by the system administrator based on historical experience. When the trigger frequency data f... c Greater than f high When the expiry date is reached, the validity period parameter is extended proportionally, and the extension formula is T. new =T old *(1+Δ), where T new For the adjusted new validity period parameter, T old The original validity period parameter before adjustment is given, and Δ is the extension coefficient, which is set to 0.2 by default and determined through experimental data.

[0082] When the trigger frequency data is lower than a preset threshold, the validity period parameter is shortened;

[0083] Specifically, when the trigger frequency data f c Less than f low When the expiration date is shortened proportionally, the shortening formula is T. new =T old *(1-Δ), where the shortening coefficient Δ and the lengthening coefficient have the same value. The adjusted validity period parameter must satisfy the minimum boundary constraint T. min = 300 seconds.

[0084] When the validity period parameter is zero, the temporary detection rule is automatically deleted.

[0085] Specifically, when the validity period parameter drops to 0, the temporary detection rule is automatically deleted from the memory detection queue.

[0086] For example, in the waybill query API detection scenario of a logistics system, the initial validity period T of a certain temporary detection rule is... old =1000s, preset high threshold f high =10 times / minute, low threshold f low = 2 times / minute. The trigger frequency within the monitoring window reaches 15 times / minute (exceeding f). high If the validity period is extended (T), then the validity period will be extended. new =1000×(1+0.2)=1200 seconds; the trigger frequency for the next cycle drops to 1 time / minute (below f). lowIf ), then shorten to T. new =1200×(1-0.2)=960 seconds; it continued to not trigger until T. new After multiple attenuation cycles to zero, the system automatically deletes the rule. For high-frequency triggers, the validity period is automatically extended to ensure continuous protection against critical vulnerabilities; for low-frequency triggers, the validity period is shortened to release system resources. Rule deletion to zero avoids the accumulation of invalid rules. This method significantly improves detection efficiency and reduces maintenance burden in actual logistics systems.

[0087] Optionally, the step of using the temporary detection rule to perform real-time detection on subsequent API requests includes:

[0088] Load the temporary detection rules into the memory detection queue;

[0089] Specifically, the temporary detection rules are first loaded into the memory detection queue. The memory detection queue is a set of rules that reside in memory. It uses a hash table structure to store key-value pairs of rule IDs and rule content to ensure high-speed access.

[0090] Perform rule matching on the received API requests and generate matching results;

[0091] Specifically, rule matching is performed on each received API request. Rule matching involves traversing all rules in the memory detection queue and comparing the request parameters, resource consumption slope, and API call chain information with the rule conditions one by one. If the request characteristics meet any rule condition, the match is considered successful, and a matching result is generated and marked as high-risk; otherwise, it is marked as low-risk.

[0092] When the matching result is high-risk, a security response action is triggered;

[0093] Specifically, when the matching result is high-risk, a security response action is triggered, which includes preset operations such as blocking the connection or issuing an alarm notification.

[0094] Record the matching results and the security response actions to generate a detection log.

[0095] Specifically, the matching results and triggered security response actions are recorded to generate detection logs. The detection logs include timestamps, request IDs, rule IDs, matching results, and response action types, and are stored in a disk database.

[0096] For example, in the scenario of API detection for appointment registration in a medical system, a memory detection queue loads three temporary rules: rule R1 detects abnormal parameter combinations, rule R2 monitors sudden changes in resource slope, and rule R3 verifies the integrity of the call chain. Upon receiving an appointment registration request Req2024, its parameters user_id = test, resource slope k = 9.2, and the call chain containing a payment API are extracted. The matching process is as follows: rule R1 detects that user_id = test matches the characteristics of the abnormal parameter library; rule R2 satisfies the condition k > 8; rule R3 verifies that the payment API call is missing. The overall matching result is determined to be high-risk, triggering security response actions including blocking the request connection and sending an SMS alert to the administrator, logging the time as 2024-05-20 10:00, request ID as Req2024, triggering rules R1 / R2, and response action code as 103. Through the implementation of the memory queue, this invention can identify malicious test accounts conducting resource exhaustion attacks at millisecond speeds. The accuracy of the judgment is improved by applying multiple rules for cross-validation. In addition, the complete logs provide a crucial chain of evidence for the security audit of the medical system, effectively preventing the malicious occupation of registration service resources.

[0097] Optionally, the triggering of the security response action includes:

[0098] Determine whether a high-risk API request triggers a connection blocking condition and generate a connection blocking instruction.

[0099] Specifically, first, API requests with high-risk matching results are obtained, and it is determined whether the request triggers connection blocking conditions. Connection blocking conditions include preset rules such as the occurrence of specific parameter combinations or excessive resource consumption. The condition list is obtained by querying the security policy library. If any blocking condition is met, a connection blocking command is generated. This command is a system-level operation command.

[0100] Execute the connection blocking instruction to disconnect the connection channel of the high-risk API request and generate a connection blocking event;

[0101] Specifically, when executing a connection blocking instruction, the kernel is triggered to send a TCP-RST packet via the operating system's Socket API, disconnecting the network connection channel corresponding to the request and generating a connection blocking event containing a timestamp and connection ID.

[0102] Parse the session information of the high-risk API request, add session tags, and generate session tag identifiers;

[0103] Specifically, the session information of high-risk API requests is parsed, including the session ID and user token, which are extracted from the request header; a session tag is added, which is a risk level identifier such as "malicious_risk", and a session tag identifier is generated.

[0104] Store the complete traffic data of the high-risk API requests, perform traffic replication, and generate traffic backup data.

[0105] Specifically, store complete traffic data of high-risk API requests, including request headers and request bodies, perform traffic replication operations, generate traffic backup data, and save it to a secure storage area.

[0106] For example, in an e-commerce payment API detection scenario, a high-risk request is a payment operation with user_id = attacker & amount = 10000. The connection blocking condition is met (single transaction amount exceeds the limit of 5000); a connection blocking command is generated and executed, disconnecting the user's TCP connection and recording the connection blocking event ID-E1002. The session information is parsed to obtain session_id = SESS789, and a session tag "financial_risk" is added, generating the identifier RISK-SESS789. The entire request header and JSON request body "user":"attacker","amount":10000" are copied, and a traffic backup file is generated. E 1002.dat. By instantly blocking large-scale fraudulent transactions to prevent financial losses, session tagging prioritizes subsequent requests for review, and traffic backup provides complete electronic evidence for financial crime investigations, the multi-layered protection mechanism significantly enhances the transaction security of e-commerce platforms.

[0107] Optionally, the method further includes:

[0108] Record the false alarm data in the security detection results and compile them into a set of false alarm events;

[0109] Specifically, firstly, false alarm data is extracted from the security detection results. False alarm data refers to normal API request records that are incorrectly judged as high-risk. Then, a set of false alarm events is formed. This set stores false alarm event entries in chronological order. Each entry contains request parameters, resource consumption value, and detection rule ID.

[0110] Analyze the common characteristics and patterns in the set of false alarm events to generate a set of false alarm features;

[0111] Specifically, when analyzing common features and patterns in a set of false alarm events, a feature clustering algorithm is used to calculate the distance between feature vectors. Where x i and y i Feature values ​​representing two false alarm events, such as parameter combination entropy or resource slope, are extracted from false alarm event entries. When d is less than a similarity threshold, they are grouped into the same category, generating a false alarm feature set. This set contains high-frequency false alarm features such as specific parameter combinations or resource fluctuation ranges. Figure 4As shown, the smaller the distance, the darker the color, indicating that the two events are more similar in features.

[0112] Based on the false positive feature set, the prediction weight configuration of the context-aware analysis is adjusted to obtain the optimized prediction weight configuration.

[0113] Specifically, the prediction weight configuration of context-aware analysis is adjusted based on the false positive feature set. The prediction weight configuration refers to the weight coefficients α, β, γ, and δ of the comprehensive risk formula S. The weight items involved in each false positive feature are reduced. For example, if a feature is associated with the resource consumption slope k, the β value is reduced proportionally. The adjustment amount Δβ = -0.1*q, where q is the frequency of feature occurrence, which is obtained from the false positive feature set. The optimized prediction weight configuration is then obtained.

[0114] The generation method of temporary detection rules is changed according to the optimized prediction weight configuration.

[0115] Specifically, the generation method of temporary detection rules is changed according to the new weight configuration, so that the rule generation process prioritizes avoiding high-frequency false alarm features.

[0116] For example, in a video platform's bullet screen API detection scenario, 20 false positive events were identified in the security detection results. A common characteristic was the simultaneous occurrence of the parameter combination `user_type=3` and `content_length>1000`. Analysis showed that this feature appeared 15 times in the false positive set. When adjusting the prediction weight configuration, this feature was associated with the parameter combination entropy weight α, and the calculated Δα = -0.1 × 15 = -1.5, optimizing the original α = 0.25 to 0.10 (lower limit 0.05). When generating temporary detection rules based on the new weights, the combination condition containing `user_type=3` and `content_length>1000` was automatically avoided. This method effectively solves the problem of false positives for long bullet screens from VIP users. The optimized weight configuration significantly improves the normal user experience while maintaining the ability to detect real attacks such as spam vulnerabilities, achieving a precise balance between security protection and business smoothness.

[0117] Optionally, the method for changing the generation of temporary detection rules includes:

[0118] The detection weights of the rules related to high-frequency false alarm features are reduced to generate adjusted rule detection weights.

[0119] Specifically, the first step is to obtain the optimized prediction weight configuration and the set of false positive features. The detection weights of the rules related to high-frequency false positive features are reduced. High-frequency false positive features refer to features in the false positive feature set that appear more than a threshold, such as 10 times. The relevant rules are temporary detection rules that include these features. The detection weight refers to the calculated weight value W during rule matching. rule The initial value is 1.0; the reduction formula is W.new =W old *(1-η*freq), where η is the weighting coefficient (default 0.1), which is derived from the analysis and statistics of historical false alarm events and is used to quantify the influence of high-frequency false alarm features on rule weights; freq is the frequency of the feature in the false alarm set, which is obtained by statistically analyzing the false alarm feature set and generating the adjusted rule detection weights.

[0120] Evaluate the effective time range of the associated temporary detection rules and shorten the validity period parameter;

[0121] Specifically, the effective period of the temporary detection rule is evaluated; the effective period refers to the time during which the rule may be effective after its generation. When shortening the validity period parameter, the original validity period T is reduced proportionally, using the formula: T new =T old *ρ, where ρ is the shortening factor (default 0.7), determined based on system resource utilization monitoring data and historical rule trigger efficiency analysis.

[0122] Feature extraction is performed for novel attack patterns to increase the priority weight of related rule generation and generate higher priority rule generation weights.

[0123] Specifically, for attack features marked as appearing for the first time in the past 30 days (i.e., new attack patterns) in the security threat intelligence database, the system first parses the threat intelligence entries, extracts key attack feature identifiers (such as specific vulnerability exploit code snippets, malicious URL patterns, abnormal parameter combinations, etc.), and standardizes them before storing them in a dynamic feature fingerprint database. Secondly, the extracted standardized features are matched in real-time with the feature database of the rule generation module. When a currently generated or pending temporary rule is detected to contain these new feature fingerprints, it is determined that the rule is related to a new attack pattern. Then, for the matched relevant rules, based on the severity of the associated new attack features, their rule generation priority weight is increased. The initial generation priority weight P is 1.0, and the increase formula is P... new =P old +σ*severity, where P new Generate priority weights for the improved rules; P old Generate priority weights for the original rules; σ is the priority coefficient with a default of 0.2, which is set by combining the severity score from the external threat intelligence database and internal security incident response experience; severity is the attack severity score obtained from the threat intelligence database.

[0124] The adjusted rule detection weights, validity period parameters, and higher priority rule generation weights are summarized to generate a detection rule adjustment scheme, and the strategy library is updated.

[0125] Specifically, the adjusted rule detection weights, validity period parameters, and rule generation weights are summarized to construct a detection rule adjustment scheme. This scheme is a structured data object, and the original configuration is overwritten by incremental writing when updating the strategy library.

[0126] For example, in the file upload API detection scenario of a cloud storage system, a high-frequency false positive characteristic is that the file type text_size > 10MB, and the frequency freq = 12. The relevant rule R001 has the original detection weight W. old =1.0, calculate W new =1.0×(1-0.1×12)=-0.2. Rule R002 originally had a validity period T. old =1800 seconds, shortened T new =1800 × 0.7 = 1260 seconds. The new attack features an encrypted ransomware header, severity = 0.9, and new rule P. new =1.0 + 0.2 × 0.9 = 1.18. After the adjustment scheme is written into the policy library, the system prioritizes the detection of encrypted file headers when generating rules. This method can effectively reduce the false positive rate of large text files, shorten the life cycle of expired rules, improve the rule generation speed for new ransomware attacks by 40%, and comprehensively optimize the accuracy and timeliness of cloud storage security protection.

[0127] Based on the same inventive concept, such as Figure 5 As shown, the present invention also provides a dynamic API security vulnerability detection system based on anomaly monitoring, the system comprising:

[0128] The traffic probe module is used to obtain request layer data and response layer data of the target API and generate a traffic dataset;

[0129] The feature extraction module is used to extract behavioral features from the traffic dataset and generate a behavioral feature matrix;

[0130] The risk prediction module is used to perform context-aware analysis on the behavioral feature matrix and generate vulnerability chain prediction results by combining the business object mapping relationship.

[0131] The rule generation module is used to parse the vulnerability path nodes in the vulnerability chain prediction results and generate temporary detection rules;

[0132] The real-time detection module is used to perform real-time detection on subsequent API requests using the temporary detection rules and output security detection results.

[0133] It should be noted that the electrical connections between the various units described above do not necessarily represent direct or indirect connections. Any indirect connection method can be applied to the embodiments of the present invention as long as it achieves the purpose of the present invention. The above descriptions are merely exemplary embodiments of the present invention and should not be construed as limiting the scope of the present invention.

[0134] All equivalent changes and modifications made in accordance with the teachings of this invention are still within the scope of this invention. Those skilled in the art will readily conceive of other embodiments of this invention upon considering the specification and the disclosure of practical truth. This application is intended to cover any variations, uses, or adaptations of this invention that follow the general principles of this invention and include common knowledge or conventional techniques in the art not described herein.

Claims

1. A dynamic detection method for API security vulnerabilities based on anomaly monitoring, characterized in that, The method includes: Obtain request and response layer data from the target API to generate a traffic dataset; The behavioral feature matrix is ​​generated by extracting behavioral features from the traffic dataset. This includes: extracting API request parameters from the traffic dataset, calculating the frequency of each parameter combination, and generating parameter combination entropy; extracting resource consumption metrics from the traffic dataset, calculating the slope of resource consumption rate change, and generating a resource consumption slope; parsing the API call sequence from the traffic dataset, calculating the co-occurrence count of API calls, and calculating context dependency; and aggregating the parameter combination entropy, the resource consumption slope, and the context dependency to generate the behavioral feature matrix. Context-aware analysis is performed on the behavioral feature matrix, and vulnerability chain prediction results are generated by combining the business object mapping relationship. This includes: mapping the abnormal parameter combination of the parameter combination entropy to the business object to generate a risk operation identifier; associating the historical operation records of the risk operation identifier to calculate the risk weight; and combining the resource consumption slope and the risk weight, along with user historical behavior data and API call chain information, to perform a comprehensive risk assessment and generate vulnerability chain prediction results. Parse the vulnerability path nodes in the vulnerability chain prediction results to generate temporary detection rules; The temporary detection rules are used to perform real-time detection on subsequent API requests, and the security detection results are output.

2. The method for dynamic detection of API security vulnerabilities based on anomaly monitoring according to claim 1, characterized in that, The temporary detection rules include: Extract key detection elements from the vulnerability path nodes in the vulnerability chain prediction results and construct rule content; Analyze the time decay mechanism and calculate the validity period parameters; By combining the rule content and the validity period parameter, a temporary detection rule is generated.

3. The method for dynamic detection of API security vulnerabilities based on anomaly monitoring according to claim 2, characterized in that, The calculation validity period parameters include: Monitor the triggering frequency of the temporary detection rule to obtain triggering frequency data; When the trigger frequency data exceeds a preset threshold, the validity period parameter is extended; When the trigger frequency data is lower than a preset threshold, the validity period parameter is shortened; When the validity period parameter is zero, the temporary detection rule is automatically deleted.

4. The method for dynamic detection of API security vulnerabilities based on anomaly monitoring according to claim 1, characterized in that, The step of using the temporary detection rules to perform real-time detection on subsequent API requests includes: Load the temporary detection rules into the memory detection queue; Perform rule matching on the received API requests and generate matching results; When the matching result is high-risk, a security response action is triggered; Record the matching results and the security response actions to generate a detection log.

5. The method for dynamic detection of API security vulnerabilities based on anomaly monitoring according to claim 4, characterized in that, The actions that trigger the security response include: Determine whether a high-risk API request triggers a connection blocking condition and generate a connection blocking instruction. Execute the connection blocking instruction to disconnect the connection channel of the high-risk API request and generate a connection blocking event; Parse the session information of the high-risk API request, add session tags, and generate session tag identifiers; Store the complete traffic data of the high-risk API requests, perform traffic replication, and generate traffic backup data.

6. The method for dynamic detection of API security vulnerabilities based on anomaly monitoring according to claim 1, characterized in that, Also includes: Record the false alarm data in the security detection results and compile them into a set of false alarm events; Analyze the common characteristics and patterns in the set of false alarm events to generate a set of false alarm features; Based on the false positive feature set, the prediction weight configuration of the context-aware analysis is adjusted to obtain the optimized prediction weight configuration. The generation method of temporary detection rules is changed according to the optimized prediction weight configuration.

7. The method for dynamic detection of API security vulnerabilities based on anomaly monitoring according to claim 6, characterized in that, The method of changing the generation of temporary detection rules includes: The detection weights of the rules related to high-frequency false alarm features are reduced to generate adjusted rule detection weights. Evaluate the effective time range of the associated temporary detection rules and shorten the validity period parameter; Feature extraction is performed for novel attack patterns to increase the priority weight of related rule generation and generate higher priority rule generation weights. The adjusted rule detection weights, validity period parameters, and higher priority rule generation weights are summarized to generate a detection rule adjustment scheme, and the strategy library is updated.

8. A dynamic API security vulnerability detection system based on anomaly monitoring, applied to the dynamic API security vulnerability detection method based on anomaly monitoring as described in any one of claims 1-7, characterized in that, The system includes: The traffic probe module is used to obtain request layer data and response layer data of the target API and generate a traffic dataset; The feature extraction module is used to extract behavioral features from the traffic dataset and generate a behavioral feature matrix. This includes: extracting API request parameters from the traffic dataset, calculating the frequency of occurrence of each parameter combination, and generating parameter combination entropy; extracting resource consumption indicators from the traffic dataset, calculating the slope of the resource consumption rate change, and generating a resource consumption slope; parsing the call sequence between APIs from the traffic dataset, calculating the co-occurrence count of API calls and calculating context dependency; and aggregating the parameter combination entropy, the resource consumption slope, and the context dependency to generate a behavioral feature matrix. The risk prediction module is used to perform context-aware analysis on the behavioral feature matrix and generate vulnerability chain prediction results by combining business object mapping relationships. This includes: mapping abnormal parameter combinations of the parameter combination entropy to business objects to generate risk operation identifiers; associating the historical operation records of the risk operation identifiers to calculate risk weights; and combining the resource consumption slope and the risk weights with user historical behavior data and API call chain information to perform a comprehensive risk assessment and generate vulnerability chain prediction results. The rule generation module is used to parse the vulnerability path nodes in the vulnerability chain prediction results and generate temporary detection rules; The real-time detection module is used to perform real-time detection on subsequent API requests using the temporary detection rules and output security detection results.

Images