A multi-model cooperative web application security detection method and system

Abstract

The application discloses a kind of multi-model collaborative Web application security detection method and system.The method will current request parallel input three analysis pipelines: baseline pipeline is based on the first abnormal probability of unsupervised model output;Large language model pipeline constructs request key field as prompt word input large language model, and the output probability for multiple attack categories is aggregated as the second abnormal probability by joint probability formula;Behavior pipeline calculates behavior indicators to request source in sliding time window to obtain the third abnormal probability.Three abnormal probabilities are weighted and fused according to the dynamic weight positively correlated with the detection performance of each pipeline, and the integrated threat assessment value is compared with the decision threshold to make interception or release decision.The application effectively solves the defects of feature processing solidification, single model dimension and lack of dynamic adaptive ability, significantly improves the detection accuracy and real-time performance of unknown threats.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, specifically relating to a multi-model collaborative web application security detection method and system. Background Technology

[0002] With the rapid development of internet technology, web applications have become the primary carriers for providing services across various industries, including government, finance, and e-commerce, making their security paramount. However, because web applications are directly exposed to public networks, they are highly vulnerable to hacker attacks, facing diverse security threats such as SQL injection, cross-site scripting (XSS), and command injection. Currently, web application security detection mainly relies on signature-based rule matching and feature extraction based on machine learning models. However, existing technologies have three limitations, resulting in insufficient detection accuracy and a lack of adaptability.

[0003] First, the fixed feature processing flow leads to insufficient detection capabilities for novel attacks. Existing machine learning-based detection solutions rely on pre-defined feature engineering processes, and the extracted feature sets are fixed before model deployment, making it difficult to effectively identify and extract key features of novel or complex variant attacks. When attackers employ novel attack techniques such as obfuscation coding, split injection, and semantic deformation, the fixed lexical and syntactic feature extraction flow often fails to capture the semantic intent of the attack, creating detection blind spots. The root cause of this problem is that existing solutions lack an analysis mechanism capable of understanding the deep semantics of requests, resulting in insufficient generalization ability to novel attack patterns.

[0004] Second, single-model detection is limited in scope, and there is a lack of effective multi-model collaboration mechanisms. Existing detection schemes typically rely on a single type of detection model, or simply stack multiple models in a sequential "funnel" manner. Due to the inherent limitations of their underlying principles, each model can only cover a limited number of detection dimensions: statistical unsupervised models excel at detecting requests that deviate structurally from normal patterns, but they are insufficient in recognizing carefully constructed semantic attack payloads; rule-matching methods have high accuracy in recognizing known attack features, but they cannot detect abnormal behavior of the requester. The lack of effective collaborative fusion mechanisms between different models means that the detection results of each model are isolated, making it difficult to form a complementary and comprehensive judgment, ultimately resulting in a difficulty in simultaneously reducing both false positive and false negative rates.

[0005] Third, the model employs offline training and static deployment, lacking the ability to dynamically adapt to the online environment. Existing models are deployed online in a fixed state after training, and their detection capabilities are strongly tied to the historical data distribution at the time of deployment. As business functions iterate, user access behavior evolves, and attack methods continuously upgrade, the normal pattern of online traffic constantly shifts. Staticly deployed models cannot detect this shift, nor can they transform allowed online traffic into continuously optimized training data. When model updates are needed, manual intervention is often required to recollect data, retrain completely, and deploy the model again, resulting in delayed update cycles and the risk of performance degradation during the update process, failing to guarantee the model's continuous protection effectiveness.

[0006] Due to the limitations mentioned above, existing web application security detection technologies struggle to simultaneously achieve high levels of accuracy, multi-dimensional collaborative capabilities, and adaptive updates when facing continuously evolving attack threats. Therefore, it is necessary to provide a multi-model collaborative web application security detection scheme to address these technical challenges. Summary of the Invention

[0007] The purpose of this invention is to address the shortcomings of the aforementioned background technology and provide a multi-model collaborative web application security detection method and system. By constructing a three-layer dynamic evaluation architecture that integrates an unsupervised baseline model, a semantic analysis model based on a large language model, and real-time behavioral indicators, and by employing a weighted fusion algorithm, it achieves real-time and accurate calculation of security threat probability, thereby effectively detecting potential web application threats.

[0008] The technical solution adopted in this invention is: a multi-model collaborative web application security detection method, comprising: Acquire real-time web request data streams and historical normal business log data, wherein the real-time web request data stream includes several current requests; For the current request in the real-time Web request data stream, the current request is input in parallel into the baseline anomaly detection pipeline, the large language model semantic analysis pipeline, and the real-time behavior indicator analysis pipeline; In the baseline anomaly detection pipeline, based on an unsupervised anomaly detection model pre-trained with the historical normal business log data, a first anomaly probability reflecting the degree of deviation of the current request from the normal pattern reflected by the historical normal business log data is obtained. In the semantic analysis pipeline of the large language model, key fields are extracted from the current request and prompt words are constructed based on the key fields; the prompt words are input into the large language model to obtain the attack probabilities output by the large language model for various known attack categories; a second anomaly probability is obtained based on the attack probabilities, the second anomaly probability reflecting the possibility that the current request has at least one of the various known attack categories, and the second anomaly probability does not decrease as any of the attack probabilities increases; In the real-time behavior indicator analysis pipeline, the request source of the current request is obtained, and based on the statistical information of the real-time web request data stream within the sliding time window, the behavior indicator of the request source within the sliding time window is calculated, and a third anomaly probability is obtained based on the behavior indicator. The first anomaly probability, the second anomaly probability, and the third anomaly probability are weighted and fused to obtain a comprehensive threat assessment value; wherein, the weights used in the weighted fusion are dynamically adjusted based on the detection performance of each pipeline in the past detection cycle, and the weight corresponding to each pipeline is positively correlated with the detection performance of that pipeline; The comprehensive threat assessment value is compared with a decision threshold: when the comprehensive threat assessment value is not less than the decision threshold, the current request is determined to be a threat request and an interception or alert action is executed; when the comprehensive threat assessment value is less than the decision threshold, the current request is determined to be a normal request and is allowed. The interception action is implemented by returning a status code or by issuing interception rules to the upstream Web application firewall.

[0009] The resource usage metrics of the computing nodes running the large language model semantic analysis pipeline are continuously monitored. When the resource usage metrics exceed a preset threshold, the weights used in the weighted fusion are adjusted or the processing of some current requests by the large language model semantic analysis pipeline is skipped.

[0010] In the above technical solution, the baseline anomaly detection pipeline obtains the first anomaly probability in the following manner: Extract multi-dimensional features from the current request. These multi-dimensional features include at least two of the following: character hierarchy features, statistical distribution features, and path structure features. The character hierarchy features include at least one of the following: frequency of special characters or density of SQL keywords in the current request. The statistical distribution features include at least one of the following: string length, information entropy, or proportion of numeric characters in the current request. The path structure features include at least one of the following: URL path depth or abnormal arrangement of request parameters in the current request. The unsupervised anomaly detection model is an isolated forest model; the isolated forest model is obtained through offline training based on the historical normal business log data. The multi-dimensional features are input into the isolated forest model, the average path length of the multi-dimensional features on each isolated tree in the isolated forest model is calculated, and the average path length is normalized to the first anomaly probability.

[0011] In the above technical solution, the large language model semantic analysis pipeline processes the current request and obtains the second anomaly probability in the following manner: Extracting key fields from the current request to construct the prompt word specifically involves: the key fields including fields from the URL portion, request header portion, and request body portion of the current request; filling each field in the key fields into the padding position corresponding to the portion to which the field belongs in a preset structured prompt word template to obtain the prompt word; the structured prompt word template includes padding positions for filling fields in the URL portion, padding positions for filling fields in the request header portion, padding positions for filling fields in the request body portion, and an instruction text portion instructing the large language model to perform security risk analysis on the filled fields and output the attack probability according to the various known attack categories; The prompt words are input into the large language model to obtain the attack probabilities output by the large language model for the various known attack categories respectively; The second anomaly probability is calculated using the following formula: Where P2 is the second anomaly probability. The large language model outputs the attack probability for the i-th attack category among the various known attack categories, and the product operation in the formula covers all of the various known attack categories; The known attack categories include at least: SQL injection, cross-site scripting, command injection, path traversal, file inclusion, server-side request forgery, XML external entity injection, and deserialization attacks.

[0012] In the above technical solution, the real-time behavior indicator analysis pipeline also meets the following limitations: The source of the current request is the source IP address corresponding to the current request; The behavioral metrics include at least two of the following: the request frequency anomaly of the request source, the access sequence anomaly of the request source, and the reputation score of the request source. The length of the sliding time window is 1 to 10 minutes; The request frequency anomaly is obtained by comparing the request frequency of the request source within the sliding time window with the average request frequency of the request source within a historical long time window; The access sequence anomaly degree is calculated based on the edit distance between the URL sequence accessed by the request source within the sliding time window and the preset normal business access sequence pattern.

[0013] In the above technical solution, the weighted fusion also satisfies the following limitations: The comprehensive threat assessment value is calculated according to the following formula: ; Where S is the comprehensive threat assessment value; P1, P2, and P3 are the first anomaly probability, the second anomaly probability, and the third anomaly probability, respectively; α, β, and γ are the weights corresponding to P1, P2, and P3, respectively, and α, β, and γ satisfy... ; The weights α, β, and γ are determined by the detection performance of each channel over past detection periods, whereby the detection performance includes at least one of precision, recall, and F1 score. The weights α, β, and γ satisfy the following condition: the higher the detection performance of a channel, the larger the weight value corresponding to that channel; and the weights α, β, and γ are normalized to ensure that... .

[0014] In the above technical solution, the method further includes: determining the risk level of the security operation environment in which the Web application is located, wherein the risk level includes a high-risk level, a medium-risk level, and a low-risk level; the decision threshold dynamically takes one of the following values ​​according to the risk level: a first threshold is taken at the high-risk level; a second threshold is taken at the medium-risk level; a third threshold is taken at the low-risk level; the first threshold is less than the second threshold, and the second threshold is less than the third threshold.

[0015] In the above technical solution, after determining that the current request is a normal request and allowing it to proceed, the method further includes the following model self-evolution step: The second anomaly probability corresponding to the current request is compared with a preset poisoning filtering threshold. When the second anomaly probability is greater than the poisoning filtering threshold, the current request is discarded and not included in subsequent sample backflow. Otherwise, the current request is marked as a normal sample and fed back to the data warehouse, which stores the historical normal business log data. The current request is merged with the existing historical normal business log data in the data warehouse to form an expanded sample library. The poisoning filtering threshold is less than the decision threshold. Incremental model training will be initiated when any of the following triggering conditions are met: the time interval since the last incremental model training reaches a preset period threshold; or the number of normal samples added to the expanded sample library relative to the last incremental model training reaches a preset number threshold. Based on the expanded sample library, the unsupervised anomaly detection model is incrementally trained in a sandbox environment that is physically or logically isolated from the online analysis pipeline environment to generate candidate models. The bypass traffic obtained from the copy of the real-time Web request data stream is used as the verification traffic; the candidate model is verified in the sandbox environment using the verification traffic to obtain the false positive rate and true positive rate of the candidate model on the verification traffic; at the same time, the corresponding false positive rate and corresponding true positive rate of the currently used unsupervised anomaly detection model on the verification traffic are obtained. The candidate model replaces the currently used unsupervised anomaly detection model with a hot-swap mechanism without downtime if and only if the false positive rate of the candidate model is not greater than the corresponding false positive rate of the currently used unsupervised anomaly detection model, and the true positive rate of the candidate model is not less than the corresponding true positive rate of the currently used unsupervised anomaly detection model; otherwise, the currently used unsupervised anomaly detection model is retained and the candidate model is discarded. After the hot-swap without downtime, the online detection performance of the candidate model after the hot-swap is continuously monitored during a preset observation period. When the detection performance of the candidate model during the observation period decreases by more than a preset decay threshold relative to its detection performance in the sandbox environment, it is automatically rolled back to the currently used unsupervised anomaly detection model before the hot-swap.

[0016] In the above technical solution, the parallel input of the current request into the baseline anomaly detection pipeline, the large language model semantic analysis pipeline, and the real-time behavior indicator analysis pipeline includes: asynchronously distributing the current request to the baseline anomaly detection pipeline, the large language model semantic analysis pipeline, and the real-time behavior indicator analysis pipeline via a message queue; wherein, the baseline anomaly detection pipeline is deployed on a first computing resource, the large language model semantic analysis pipeline is deployed on a second computing resource, and the real-time behavior indicator analysis pipeline is deployed on a third computing resource; the first computing resource, the second computing resource, and the third computing resource are independent of each other; the second computing resource includes at least a graphics processor.

[0017] The above technical solution further includes a computing power adaptive control step: Continuously monitor the resource usage indicators of the computing nodes running the large language model semantic analysis pipeline. The resource usage indicators include at least one of the following: graphics processor memory usage, CPU utilization, and concurrent request processing rate per unit time. When the resource occupancy index exceeds a preset high water level threshold, at least one of the following dynamic controls is executed: (a) the weights corresponding to the large language model semantic analysis pipeline are reduced, and the weights corresponding to the other pipelines are increased proportionally while keeping the sum of the weights constant; (b) when the first anomaly probability output by the baseline anomaly detection pipeline for the current request is lower than a preset bypass threshold, the processing of the large language model semantic analysis pipeline for the current request is skipped, and the weighted fusion is performed only based on the first anomaly probability and the third anomaly probability according to the dynamically adjusted weights. When the resource usage index falls below the preset low water level threshold and remains stable for a preset time window, the weights are restored to be dynamically generated by the original weighted fusion mechanism, and the large language model semantic analysis pipeline resumes processing of all requests.

[0018] This invention provides a multi-model collaborative web application security detection system for implementing the method described in the above claims, the system comprising: The data acquisition module is configured to acquire real-time web request data streams and historical normal business log data, wherein the real-time web request data streams include several current requests; The parallel scheduling module is configured to input the current request in parallel into the baseline anomaly detection pipeline module, the large language model semantic analysis pipeline module, and the real-time behavior indicator analysis pipeline module for the current request in the real-time Web request data stream. The baseline anomaly detection pipeline module is configured to obtain a first anomaly probability reflecting the degree of deviation of the current request from the normal pattern reflected by the historical normal business log data, based on an unsupervised anomaly detection model pre-trained with the historical normal business log data. The large language model semantic analysis pipeline module is configured to extract key fields from the current request and construct prompt words based on the key fields, input the prompt words into the large language model to obtain the attack probabilities output by the large language model for multiple known attack categories, and obtain a second anomaly probability based on the attack probabilities. The second anomaly probability reflects the possibility that the current request has at least one of the multiple known attack categories, and the second anomaly probability does not decrease as any of the attack probabilities increases. The real-time behavior indicator analysis pipeline module is configured to obtain the request source of the current request, calculate the behavior indicator of the request source within the sliding time window based on the statistical information of the real-time Web request data stream within the sliding time window, and obtain a third anomaly probability based on the behavior indicator. The dynamic fusion decision module is configured to perform weighted fusion of the first anomaly probability, the second anomaly probability, and the third anomaly probability to obtain a comprehensive threat assessment value. The weights used in the weighted fusion are dynamically adjusted based on the detection performance of each pipeline in the past detection cycle, and the weight corresponding to each pipeline is positively correlated with the detection performance of that pipeline. The module is also configured to compare the comprehensive threat assessment value with a decision threshold. When the comprehensive threat assessment value is not less than the decision threshold, the current request is determined to be a threat request and an interception or alarm action is performed. When the comprehensive threat assessment value is less than the decision threshold, the current request is determined to be a normal request and is allowed. The offline training and update module is configured to perform the model self-evolution step; The computing power adaptive control module is configured to execute computing power adaptive control steps. The beneficial effects of this invention are as follows: The multi-model collaborative web application security detection method and system provided by this invention, by parallel integration of the baseline anomaly detection pipeline, the large language model semantic analysis pipeline, and the real-time behavioral indicator analysis pipeline, and by introducing dynamic weighted decision-making and model self-evolution mechanisms, fundamentally overcomes the limitations of existing technologies in terms of single feature dimensions, lack of model collaboration, and rigid static deployment. Overall, it achieves a synergistic improvement in detection accuracy, adaptability to unknown attacks, and continuous system availability. This invention integrates three complementary detection capabilities—structural feature analysis, semantic content understanding, and behavioral sequence monitoring—into a unified parallel architecture. These three capabilities mutually reinforce each other and are indispensable. Specifically, the baseline anomaly detection pipeline can detect requests with low latency that deviate significantly from normal patterns in structural dimensions such as characters, statistics, and paths; the large language model semantic analysis pipeline can understand the semantic intent of attack payloads and maintain a high level of awareness of new attacks that bypass rule detection, such as obfuscation encoding and semantic deformation; and the real-time behavioral indicator analysis pipeline, by focusing on the historical behavior dimension of the request source, can identify attack behaviors that are difficult to detect at the isolated request level, such as brute-force attacks and slow scanning. The synergy of the three channels makes it difficult for attackers to evade detection across the structural, semantic, and behavioral dimensions simultaneously, significantly reducing the overall false negative rate.

[0019] Furthermore, the parallel dispatching mechanism of this invention enables three pipelines to independently analyze the same request simultaneously without introducing serial waiting delays, ensuring the real-time response capability of the detection system in high-concurrency scenarios. The dynamic weighted fusion mechanism automatically assigns greater decision-making influence to the currently performing pipeline based on the historical detection performance of each pipeline, thus maintaining the optimal trade-off in fusion decisions across different business scenarios and attack modes, avoiding the performance degradation caused by scenario switching in fixed-weight schemes.

[0020] Furthermore, this invention enhances detection capabilities from two dimensions: the baseline anomaly detection pipeline and the large language model semantic analysis pipeline. Lexical features, statistical distribution features, and path structure features are incorporated into multi-dimensional feature engineering, and the isolated forest algorithm is used as the unsupervised anomaly detection model. This allows the baseline pipeline to establish a normal pattern baseline through offline training without relying on labeled samples, demonstrating strong detection capabilities for structured attacks, particularly effective against parameter filling and path traversal attack patterns. By filling the three key fields of the request URL, request headers, and request body into a structured prompt word template, the large language model is guided to output independent attack probabilities for various known attack categories. A joint probability formula is then used to aggregate the multi-label outputs into a single second anomaly probability. This design allows the large language model to fully leverage its semantic understanding capabilities, achieving semantic coverage of a broad range of attack categories, including 0-day attacks and unknown attack patterns, without requiring separate classifier training for each attack type. This significantly expands the system's detection boundaries for unknown attacks.

[0021] Furthermore, this invention improves the detection accuracy of the behavioral dimension. By calculating three behavioral indicators—request frequency anomaly, access sequence anomaly, and source reputation score—within a sliding time window, the abnormal behavior of the request source can be quantified and characterized from multiple complementary behavioral dimensions. This enables the system to have a strong ability to distinguish attack types that rely on behavioral pattern recognition, such as slow attacks, credential stuffing, and business logic privilege escalation.

[0022] Furthermore, the invention's further refinement of the dynamic weight generation method has yielded significant engineering benefits. By using the k-th power of the F1 score as the unnormalized weight and then normalizing it, not only is a positive correlation between the weight and detection performance ensured, but the adjustment of the enhancement factor k also enables a controllable amplification of pipeline performance differences. This allows pipelines with superior performance to gain a significantly greater influence in the fusion decision-making process, thereby improving the overall discriminative power of the comprehensive threat assessment value against the true threat level.

[0023] Furthermore, this invention endows the decision threshold with the ability to dynamically adjust according to the risk level of the security operation environment. This enables the system to improve detection sensitivity and prioritize security during high-risk periods with a lower threshold, while reducing the false positive rate and minimizing interference with operation and maintenance during off-peak or maintenance periods with a higher threshold. This achieves dynamic adaptation of detection strategies to business scenarios and avoids performance imbalances in different scenarios caused by fixed threshold schemes.

[0024] Furthermore, the self-evolutionary closed-loop model of this invention is the core means to overcome the limitations of static deployment, and its technical effects are reflected in three aspects. First, the anti-poisoning filtering mechanism effectively prevents attackers from poisoning the sample library by constructing low-scoring malicious requests by setting an intermediate zone between the decision threshold and the poisoning filtering threshold, thus ensuring the security of the self-evolutionary closed loop itself. Second, the dual-index sandbox verification mechanism based on bypass real-time traffic requires that the false positive rate of the candidate model is not greater than that of the current model and the true positive rate is not less than that of the current model, ensuring that each model update strictly meets the premise of no performance degradation in both dimensions, so that the model self-evolution process can only optimize and not degrade the overall detection performance. Third, the no-downtime hot replacement and observation period rollback mechanism together ensure that the model update has zero impact on business continuity. Even if performance decline occurs after hot replacement, the system can automatically roll back to the previous version within the preset observation period, forming a complete security guarantee network.

[0025] Furthermore, this invention amplifies the engineering value of parallel architecture through message queues and heterogeneous computing resource deployment. Deploying the large language model semantic analysis pipeline independently on computing resources including GPUs enables large language model inference to fully utilize the high parallel computing power of GPUs, significantly reducing single-inference latency. The introduction of message queues completely decouples the three pipelines at the physical deployment level, ensuring that load fluctuations in any pipeline do not affect the normal operation of other pipelines, thus improving the system's overall resilience and scalability under traffic surge scenarios.

[0026] Furthermore, the adaptive computing power control mechanism of this invention solves the resource contention problem of large language model inference under high concurrency loads. By monitoring the physical resource indicators of computing nodes in real time, the weight of the large language model semantic analysis pipeline is dynamically reduced or its processing of low-risk requests is selectively skipped when resources exceed the high-water mark threshold, and automatically restored after resources fall back, forming an adaptive control closed loop with hysteresis characteristics. This mechanism ensures that the system prioritizes overall service availability under high-load scenarios at an acceptable cost of detection performance, avoiding the extreme situation where the entire-link detection capability collapses due to the exhaustion of large language model inference resources.

[0027] Furthermore, this invention solidifies all the above-mentioned technical effects into a modular architecture with clear functional boundaries. The modules cooperate with each other through clear interfaces and data flows, which facilitates independent deployment, horizontal scaling and operation and maintenance management under modern software engineering frameworks such as cloud-native and containerization, providing a system-level guarantee for the stable realization of the above-mentioned technical effects in engineering practice. Attached Figure Description

[0028] Figure 1 The overall architecture diagram of the multi-model collaborative web application security detection method and system provided in this embodiment of the invention; Figure 2 A flowchart of multi-model parallel analysis provided in an embodiment of the present invention; Figure 3 This is a flowchart of dynamic weighted fusion and decision-making provided in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating model updating and self-optimization provided in an embodiment of the present invention. Detailed Implementation

[0029] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments to facilitate a clear understanding of the present invention, but these descriptions do not constitute a limitation on the present invention.

[0030] Example 1 like Figure 1 As shown, this embodiment provides a multi-model collaborative web application security detection method. The method is executed sequentially according to steps S1 to S9 below, and a parallel mechanism is introduced when executing steps S4 to S6 (corresponding to...). Figure 2 The multi-model parallel analysis process shown in the diagram, after executing step S9, the system enters a continuously running self-evolution and computing power adaptive loop (corresponding to...). Figure 4 (The model update and self-optimization process is shown).

[0031] Step S1: Obtain Web application log data, which includes real-time Web request data streams and historical normal business log data. The real-time Web request data stream includes several current requests. For example... Figure 1 As shown in the upper left section, the real-time web request data stream is continuously acquired from the web application's external service port by a network packet capture module or proxy module deployed at the web application's entry point. The real-time web request data stream contains several current requests, each carrying raw data including the URL, request headers, and request body. The historical normal business log data is stored in... Figure 1 In the data warehouse shown, the historical normal business log data is compiled from security-confirmed request samples. This security confirmation can be achieved through manual review and annotation, accumulation of long-term business operation experience, and the compilation of request samples confirmed as normal by other security detection tools. In addition to the aforementioned real-time web request data stream and historical normal business log data, this step S1 also acquires system historical log metrics as the data foundation for subsequent behavioral analysis. These system historical log metrics include, but are not limited to, time-series data used for behavioral pattern analysis, such as source IP access frequency sequences, access volume sequences for each URL, distribution sequences of HTTP method types, and distribution sequences of response status codes.

[0032] The current request in the real-time Web request data stream obtained in step S1 needs to be standardized before being input into subsequent analysis pipelines to ensure that the data received by each subsequent pipeline has a consistent format and encoding. Therefore, step S2 is executed, corresponding to... Figure 1 The processing performed by the "Data Acquisition and Preprocessing Module" in the middle.

[0033] Step S2 involves performing standardized preprocessing on the current request in the real-time Web request data stream to obtain normalized request data. This standardized preprocessing specifically includes the following steps: parsing the current request according to RFC 7230 to RFC 7235 standards, separating the request line (including HTTP method, URL, and HTTP version), request header fields, and request body content; decoding any multiple URL encodings (including %xx encoding, Unicode encoding, HTML entity encoding, etc.) that may exist in the URL to prevent attackers from bypassing detection through multiple encoding methods; unifying the decoded characters to a preset encoding (such as UTF-8) and removing invisible and control characters from the request; performing structured parsing on request bodies with different Content-Types such as application / json, application / x-www-form-urlencoded, and multipart / form-data to obtain a unified key-value pair representation; and optionally removing business fields irrelevant to security analysis to reduce the computational load of subsequent analysis. After completing the standardized preprocessing, the current request is converted into normalized request data and sent to step S3.

[0034] After obtaining the normalized request data, this embodiment employs a multi-pipeline parallel asynchronous analysis architecture, simultaneously inputting the normalized request data into three independently running analysis pipelines to evaluate the current request from three complementary dimensions: structure, semantics, and behavior. Therefore, step S3 is executed. Figure 1 Central and Figure 2 As shown at the top, the normalization request data is received by the parallel scheduling module of the multi-model parallel analysis pipeline group and distributed to three parallel analysis pipelines.

[0035] Step S3: For the current request in the real-time Web request data stream, the current request is input in parallel into the baseline anomaly detection pipeline, the large language model semantic analysis pipeline, and the real-time behavior indicator analysis pipeline, so that the three pipelines process the current request simultaneously. In a preferred embodiment, the parallel input of the current request into the three pipelines is specifically achieved by asynchronously distributing the current request to the baseline anomaly detection pipeline, the large language model semantic analysis pipeline, and the real-time behavior indicator analysis pipeline via a message queue. The message queue can be any mainstream message middleware such as Apache Kafka, RabbitMQ, Apache Pulsar, or RocketMQ. The distribution method can be either sending to three independent topics (the data acquisition and preprocessing module sends copies of the same normalized request data to three different topics, and the three pipelines subscribe to their respective topics) or using a single topic with multiple consumer groups (the data acquisition and preprocessing module sends normalized request data to a single topic, and the three pipelines act as three independent consumer groups, consuming messages from the same topic). The asynchronous message queue distribution method decouples the three pipelines. Changes in the processing rate of any pipeline (such as fluctuations in the inference latency of a large language model on the GPU) will not block the operation of other pipelines. In the event of a sudden surge in request traffic, messages to be processed are cached through the message queue to avoid pipeline overload leading to request loss.

[0036] Furthermore, in a preferred embodiment of this example, the baseline anomaly detection pipeline is deployed on a first computing resource, the large language model semantic analysis pipeline is deployed on a second computing resource, and the real-time behavior indicator analysis pipeline is deployed on a third computing resource. The first, second, and third computing resources are independent of each other, and the second computing resource includes at least a graphics processing unit (GPU). Specifically, the first computing resource is typically configured as a multi-core CPU server cluster, suitable for tree-based parallel computing of isolated forest models; the second computing resource is typically configured as a GPU server cluster, including at least one or more GPUs (typical GPUs include data center-grade GPUs such as NVIDIA A100, H100, and L40S, or consumer-grade GPUs such as RTX 4090 clusters can also be used), and the high parallel computing capability of GPUs is key to the inference performance of large language models; the third computing resource is typically configured as a memory computing or stream processing cluster (e.g., Apache Flink, Apache Spark Streaming, Apache Storm, etc.), suitable for efficiently maintaining sliding time windows and real-time aggregation computing.

[0037] After the current request is input into the three pipelines in parallel through step S3, the three pipelines simultaneously execute the following steps S4, S5, and S6, respectively, corresponding to... Figure 2 The internal processing is performed by three parallel analysis pipelines.

[0038] Step S4, as follows Figure 2 As shown in the left-hand pipeline, in the baseline anomaly detection pipeline, based on an unsupervised anomaly detection model pre-trained with the historical normal business log data, a first anomaly probability reflecting the degree of deviation of the current request from the normal pattern reflected by the historical normal business log data is obtained. This step S4 is further decomposed into the following sub-steps: first, extract multi-dimensional features from the current request; then, limit the unsupervised anomaly detection model; finally, input the multi-dimensional features into the unsupervised anomaly detection model to obtain the first anomaly probability. The preferred implementation of each sub-step is as follows.

[0039] In the sub-step of extracting multi-dimensional features, as a preferred embodiment of this example, the extracted multi-dimensional features include at least two types of features reflecting the character hierarchy features, statistical distribution features, and path structure features of the current request. In the best embodiment, the multi-dimensional features simultaneously include all three types of features. Specifically, the character hierarchy features include at least one of the frequency of special characters or the density of SQL keywords in the current request. The frequency of special characters is calculated by dividing the number of occurrences of typical attack payload characters such as single quotes, double quotes, semicolons, left and right angle brackets, question marks, hash symbols, backslashes, and percent signs in the request parameters by the total number of characters in the request. The density of SQL keywords is calculated by dividing the number of occurrences of SQL keywords and comment characters such as SELECT, UNION, INSERT, UPDATE, DELETE, DROP, EXEC, –, / * * / in the request by the total number of characters in the request. The statistical distribution characteristics include at least one of the following in the current request: string length, information entropy, or proportion of numeric characters. The string length includes the URL path length, total URL parameter length, length of each parameter value, length of each field in the request header, and request body length. The information entropy is the Shannon information entropy of the request parameter values ​​(according to the formula...). Calculation, where For characters The frequency of occurrence in the request), the proportion of numeric characters is the percentage of numeric characters in the total number of characters in the request. The path structure features include at least one of the URL path depth or the abnormal arrangement degree of the request parameter position in the current request. The URL path depth is the number of " / " separators in the URL path. The abnormal arrangement degree of the request parameter position is obtained by aggregating the parameter name order, the missing status of required parameters, and the matching degree of parameter values ​​with expected types (such as integers, emails, UUIDs) in the current request according to a preset weighting method.

[0040] In a preferred embodiment of the unsupervised anomaly detection model, the unsupervised anomaly detection model is an isolated forest model, which is trained offline based on the historical normal business log data. The offline training is performed in a training environment physically or logically isolated from the online analysis pipeline environment. In the preferred embodiment, the training parameters of the isolated forest model are configured as follows: the number of isolated trees (n_estimators) is 100 to 200, the number of samples per isolated tree (max_samples) is 256, and the training dataset contains at least 100,000 securely verified historical normal business log data entries. The basic principle of the isolated forest model is that, since anomalous data is usually scarce and its distribution differs significantly from normal data, the path length for anomalous data to be isolated (reaching a leaf node) in a randomly generated binary tree (isolated tree) is often short. By constructing a large number of isolated trees to form an isolated forest and calculating the average path length of the sample to be tested on each tree in the forest, it can be determined whether the sample is anomaly.

[0041] In the sub-step of obtaining the first anomaly probability, the multi-dimensional features are input into the isolated forest model, the average path length h̄(x) of the multi-dimensional features on each isolated tree in the isolated forest model is calculated, and then the average path length is normalized to the first anomaly probability according to the following formula. ; Where c(n) is the normalization factor for the average search path length of a binary search tree containing n samples, c(n) = 2·H(n-1) - 2(n-1) / n, H(i) is the harmonic number, and n is the number of training samples for the isolated tree. The first anomaly probability P1 ranges from [0, 1]. The closer P1 is to 1, the more abnormal the current request is; the closer it is to 0, the closer the current request is to the normal mode.

[0042] While the baseline anomaly detection pipeline outputs the first anomaly probability P1 according to step S4 above, the large language model semantic analysis pipeline executes step S5 in parallel, corresponding to... Figure 2 Intermediate pipe.

[0043] Step S5, as follows Figure 2As shown in the intermediate pipeline, in the semantic analysis pipeline of the large language model, key fields are extracted from the current request and prompt words are constructed based on the key fields; the prompt words are input into the large language model to obtain the attack probabilities output by the large language model for various known attack categories; a second anomaly probability is obtained based on the attack probabilities, the second anomaly probability reflecting the possibility that the current request contains at least one of the various known attack categories, and the second anomaly probability does not decrease as any of the attack probabilities increases. This step S5 is further decomposed into the following sub-steps: extracting key fields and constructing prompt words, inputting into the large language model to obtain attack probabilities, and calculating the second anomaly probability. The preferred implementation of each sub-step is as follows.

[0044] In the sub-step of extracting key fields and constructing prompt words, as a preferred embodiment of this example, the key fields include fields from the URL part, request header part, and request body part of the current request; each field in the key fields is filled into the fill position corresponding to the part to which the field belongs in the preset structured prompt word template to obtain the prompt word.

[0045] Specifically, the URL portion includes URL path and URL query parameters; the request header portion includes User-Agent, Referer, Cookie, Content-Type, Authorization, etc.; and the request body portion includes JSON or form-formatted key-value pairs, fields from a multipart form, etc. The structured prompt template includes padding for the URL portion fields, padding for the request header portion fields, padding for the request body portion fields, and an instruction text portion instructing the large language model to perform security risk analysis on the entered fields and output the attack probabilities according to the various known attack categories.

[0046] In the preferred embodiment of this example, the exemplary structured prompt template used is: "You are a senior web security expert. Please analyze whether the following HTTP request contains security risks, and output the probability that the request belongs to each of the specified attack categories, where the probability is a floating-point number between 0 and 1. Request URL: {URL}. Request Header: {Header}. Request Parameters: {Params}. Please strictly follow the following JSON format to output the attack probability for each known attack category, and do not output any other explanatory text: {'SQL Injection': <probability>, 'Cross-Site Scripting': <probability>,...}."

[0047] The prompt template explicitly requires the large language model to output strictly in JSON format and without any other explanatory text. This is to facilitate the subsequent programmatic parsing of the large language model's output. It should be noted that the prompt template is merely an example. Those skilled in the art can adjust the template according to the characteristics of the specific large language model used, the supported languages, the required output format, etc., and all such adjustments should be included within the scope of protection of this invention.

[0048] In the sub-step of obtaining attack probabilities from the input large language model, the constructed prompt words are input into the large language model for deep semantic parsing to obtain the attack probabilities output by the large language model for each of the various known attack categories. The large language model can be any large language model with multilingual understanding and instruction following capabilities, such as Alibaba's Tongyi Qianwen, Zhipu ChatGLM, Baidu Wenxin Yiyan, or DeepSeek. It can be deployed either using a model service provider's API or locally.

[0049] For the raw output of the large language model, this embodiment employs the following parsing and robustness processing: First, it attempts to parse the raw output using a standard JSON parser. If the parsing is successful and contains probability fields for all expected attack categories, then the attack probabilities in the raw output are directly used as... If parsing fails (e.g., the large language model outputs non-pure JSON content containing explanatory text), then key-value pairs in the form of "attack category name: numeric" are extracted from the original output using regular expression matching as the attack probability. If the above extraction still fails or a certain attack category is missing, then the attack probability of the missing category will be... The value is set to zero, and the request is retried once to the large language model. If the retry still fails, the current request is downgraded (i.e., only the results of the baseline anomaly detection pipeline and the real-time behavior indicator analysis pipeline are weighted and fused) and an alarm log is recorded for operation and maintenance analysis. This parsing and robustness processing ensures the availability of the large language model semantic analysis pipeline when the output of the large language model is unstable.

[0050] In a preferred embodiment of this invention, the known attack categories include at least SQL injection, cross-site scripting (XSSRF), command injection, path traversal, file inclusion, server-side request forgery (SSRF), XML external entity injection (XXE), deserialization, template injection (SSTI), LDAP injection, NoSQL injection, XPath injection, HTTP request smuggling, HTTP response splitting, cross-site request forgery (CSRF), open redirection, brute-force attack or credential stuffing, business logic privilege escalation, file upload attack, API abuse, information leakage, authentication flaw exploitation, session fixation, known client component vulnerability exploitation, zero-day attacks, and unknown attack patterns. It should be noted that the present invention does not impose strict limitations on the specific number and composition of attack categories. Those skilled in the art can flexibly expand or tailor the attack category set according to the business characteristics of the deployed web application and the threat scenarios it faces. Typical embodiments can adopt a classification granularity of 10 to 30 categories. Too few categories will lead to insufficient detection coverage, while too many categories will increase the output complexity of the large language model and reduce inference stability.

[0051] In the sub-step of calculating the second anomaly probability, the attack probabilities output by the large language model for the various known attack categories are obtained. Then, the second anomaly probability is calculated according to the following formula. Where P2 is the second anomaly probability. The large language model outputs the attack probability for the i-th attack category among the various known attack categories. The product operation in the formula covers all of the various known attack categories (in the best implementation of the 25 attack categories, the product operation ranges from i to 25).

[0052] The joint probability formula is based on the probability theory principle of "at least one event occurs," meaning that if the current request belonging to the i-th type of attack is considered as an independent event, then the probability that the current request belongs to at least one of the known attack categories is 1 minus the probability that none of the events occur. This aggregation method has the following characteristics: when all... When all values ​​are zero, P2 is zero (consistent with the semantics of no attack indication); when any When the value is one, P2 is one (meeting the semantics of at least one attack determining that it has occurred); and any Increasing the value of P2 does not decrease the value of P2 (which aligns with the intuition that risk only increases).

[0053] While the large language model semantic analysis pipeline outputs the second anomaly probability P2 according to step S5, the real-time behavior indicator analysis pipeline executes step S6 in parallel, corresponding to... Figure 2 The pipe on the right.

[0054] Step S6, as follows Figure 2 As shown in the right-hand pipeline, in the real-time behavior indicator analysis pipeline, the request source of the current request is obtained. Based on the statistical information of the real-time Web request data stream within the sliding time window, the behavior indicator of the request source within the sliding time window is calculated, and a third anomaly probability is obtained based on the behavior indicator. This step S6 is further decomposed into the following sub-steps: determining the request source, maintaining the sliding time window, calculating the behavior indicator, and obtaining the third anomaly probability. The preferred implementation of each sub-step is as follows.

[0055] In the sub-step of determining the request source, as a preferred embodiment of this example, the request source of the current request is the source IP address corresponding to the current request. In other embodiments, the request source can also be other identifiable entity identifiers, such as the user ID of a logged-in user, the client browser fingerprint, the session ID, etc.

[0056] In the sub-step of maintaining the sliding time window, the real-time behavior indicator analysis pipeline maintains a sliding time window, which slides forward continuously over time, retaining key statistical information of all web requests within a recent period. As a preferred embodiment, the window length of the sliding time window is 1 to 10 minutes; in the optimal embodiment, the window length is 5 minutes. The selection of the sliding time window length requires a trade-off between two aspects: a window that is too short (less than 30 seconds) results in insufficient statistical samples, poor stability in the calculation of indicators such as frequency and sequence, and a higher risk of misjudgment; a window that is too long (greater than 30 minutes) leads to a greater delay in the detection response to abnormal behavior, giving attackers a longer window to launch attacks.

[0057] In the sub-step of calculating behavioral indicators, as a preferred embodiment of this example, the calculated behavioral indicators include at least two of the following: the request frequency anomaly of the request source, the access sequence anomaly of the request source, and the reputation score of the request source. In the best embodiment, the behavioral indicators include all three. The request frequency anomaly is obtained by comparing the request frequency of the request source within the sliding time window with the average request frequency of the request source within a historical long-term window.

[0058] Specifically: First, calculate the number of requests from the request source within the last 5 minutes and record it as follows: Then, calculate the average number of requests from the request source within a 5-minute window each day over the past 7 days, and record it as... The standard deviation of the same period is denoted as Next, calculate the z-score value. , Where ε is a small positive number to prevent the denominator from being zero (typically 1), and finally the z-score is mapped to the interval [0, 1] using the following sigmoid normalization function to obtain the request frequency anomaly score: , in The temperature coefficient (typically 3) is used as the normalization function to ensure that the larger the z-value, the closer the request frequency anomaly is to 1, and the closer the z-value is to 0, the closer the request frequency anomaly is to 0.5. The access sequence anomaly is calculated based on the edit distance between the URL sequence accessed by the request source within the sliding time window and the preset normal service access sequence pattern.

[0059] Specifically: First, maintain one or more preset normal business access sequence patterns (for example, "login → browse products → add to cart → place order → pay" is a typical normal sequence pattern in an e-commerce platform). Then, extract the URL sequence accessed by the request source within the last 5 minutes and record it as follows: Then calculate the above The most similar preset normal sequence pattern The Levenshtein edit distance between them is denoted as Finally, the edit distance is mapped to the [0, 1] interval using the following normalization function to obtain the access sequence anomaly degree: , The edit distance ratio is obtained by dividing the edit distance by the maximum of the lengths of the two sequences, and then truncated to a maximum of 1. The reputation score of the request source is based on a comprehensive evaluation of the source IP address corresponding to the request source based on multiple dimensions. These dimensions include, but are not limited to, whether the IP is a Tor exit node, proxy node, or VPN node; whether the geographical location of the IP matches the business coverage of the target web application; whether the IP has a history of attack behavior on the web application; and whether the IP is on a public threat intelligence blacklist (such as AbuseIPDB, AlienVault OTX, etc.). The reputation score can be obtained by querying external threat intelligence services, internal blacklists, geographical location databases, etc. The typical value is in the range of [0, 1], and the closer the value is to 1, the worse the reputation of the IP (the more suspicious it is).

[0060] In the sub-step of obtaining the third anomaly probability, the above-mentioned at least two behavioral indicators are aggregated according to a preset aggregation rule to obtain the third anomaly probability P3. In a preferred embodiment of this example, P3 is calculated as follows: ; In another preferred embodiment of this example, ,in .

[0061] Thus, through the parallel execution of steps S4, S5, and S6, the baseline anomaly detection pipeline, the large language model semantic analysis pipeline, and the real-time behavior indicator analysis pipeline respectively output the first anomaly probability P1, the second anomaly probability P2, and the third anomaly probability P3. These three anomaly probabilities reflect the security risk of the current request from three complementary dimensions: structural features, semantic content, and behavioral sequence. However, no single dimension is sufficient to independently make the final detection decision. Therefore, step S7 is executed to perform a weighted fusion of the three probabilities, corresponding to... Figure 3 The dynamic weighted fusion and decision-making process is shown.

[0062] Step S7, as follows Figure 3 As shown in the upper part, the first anomaly probability, the second anomaly probability, and the third anomaly probability are weighted and fused to obtain a comprehensive threat assessment value. The weights used in the weighted fusion are dynamically adjusted based on the detection performance of each pipeline in the past detection cycle, and the weight corresponding to each pipeline is positively correlated with the detection performance of that pipeline. This step S7 is further decomposed into two sub-steps: the calculation of the comprehensive threat assessment value and the dynamic generation of weights. The preferred implementation of each sub-step is as follows.

[0063] In the sub-step of calculating the comprehensive threat assessment value, as a preferred embodiment of this invention, the comprehensive threat assessment value is calculated according to the following formula: Where S is the comprehensive threat assessment value, P1, P2, and P3 are the first anomaly probability, the second anomaly probability, and the third anomaly probability, respectively, and α, β, and γ are the weights corresponding to P1, P2, and P3, respectively, and α, β, and γ satisfy the following condition: In the preferred embodiment of this example, the default initial value of the weight is configured as follows: The design considerations for this default initial value are as follows: the large language model semantic analysis pipeline possesses the strongest semantic understanding capability and the ability to detect novel attacks, and therefore is given a larger weight; the baseline anomaly detection pipeline and the real-time behavior indicator analysis pipeline provide complementary information in both structural features and behavioral sequences, and therefore are given the second largest weight. It should be noted that this invention does not strictly limit the specific values ​​of the weights, and those skilled in the art can flexibly configure and adjust them according to the business characteristics of the deployed web application and the detection performance of each pipeline in actual deployment.

[0064] In the sub-step of dynamically generating the weights, the weights α, β, and γ are determined by the detection performance of each pipeline in the past detection period. The detection performance includes at least one of precision, recall, and F1 score. The weights α, β, and γ satisfy the following: the higher the detection performance of a pipeline, the larger the weight value corresponding to that pipeline, and the weights α, β, and γ are normalized so that α + β + γ = 1.

[0065] Specifically, the dynamic generation of the weights is performed as follows: every fixed time interval (e.g., every hour) or after detecting a certain number of requests (e.g., every 10,000 requests), the detection performance of each pipeline in the past detection cycle is statistically analyzed. Specifically, requests whose true attributes (threat / normal) have been determined through manual review or post-verification are compared with the judgment outputs of each pipeline, and the precision, recall, and F1 score of each pipeline are calculated. In a preferred embodiment of this example, the weights are generated using a power-of-k normalization method for F1, that is, the unnormalized weight of each pipeline is calculated as the power of the F1 score of that pipeline. (where k is a preset enhancement factor and k is not less than 1), and then the unnormalized weights of each pipeline are normalized to obtain α, β, and γ, i.e. , , .

[0066] The performance differences between different pipelines can be amplified by raising the weight to the power of k: when k=1, it is a linear normalization, and the weight of each pipeline is proportional to F1; when k>1, the pipeline with a higher F1 receives a significantly greater weight than the pipeline with a lower F1 (typically, k ranges from 1 to 3). To avoid drastic fluctuations in weights between adjacent detection periods, an exponential moving average can be applied to the newly generated weights and the weights of the previous period, i.e. Where ρ is the smoothing coefficient (typically 0.3 to 0.5). Besides the k-th power normalization of F1 mentioned above, those skilled in the art can also use other normalization methods that achieve "higher detection performance equals higher weight" as equivalent implementations of the present invention, such as accuracy-based normalization. Normalization based on recall rate Weighted F-score-based normalization and Softmax-based normalization (where τ is the temperature coefficient), etc., and all such equivalent embodiments should be included within the scope of protection of this invention.

[0067] After obtaining the comprehensive threat assessment value S through step S7, S needs to be compared with a preset decision threshold to make a final threat / normal determination. Therefore, step S8 is executed, corresponding to... Figure 3 The threshold determination module is shown in the lower half.

[0068] Step S8, as follows Figure 3 The lower part shows the comparison between the comprehensive threat assessment value and the decision threshold: when the comprehensive threat assessment value is not less than the decision threshold, the current request is determined to be a threat request and an interception or alarm action is performed; when the comprehensive threat assessment value is less than the decision threshold, the current request is determined to be a normal request and is allowed. Specifically, the interception action is to directly block the request and return a 4xx or 5xx status code to the client; the alarm action is to allow the request to pass but send an alarm notification to the security operations platform for further manual review. In the preferred embodiment of this example, the default value of the decision threshold is configured as θ=0.5. The design consideration for this threshold is that the comprehensive threat assessment value S ranges from [0, 1]. Taking 0.5 as the boundary can ensure that "at least half of the evidence points to a threat" before interception is performed, and can also maintain high sensitivity in new and unknown attack scenarios. It should be noted that the present invention does not strictly limit the specific value of the decision threshold. Those skilled in the art can flexibly configure and adjust it according to the business characteristics of the deployed web application and the required detection sensitivity.

[0069] As a preferred embodiment of this invention, the decision threshold can be dynamically adjusted according to the risk level of the security operation environment in which the web application is located. The risk level is determined based on a comprehensive assessment of the following factors: time factors (important business periods such as e-commerce promotions, holidays, and major events usually require stricter detection), threat intelligence factors (external threat intelligence reports on the latest attack trends, disclosure of relevant zero-day vulnerabilities, and attack incidents suffered by peers in the industry), business factors (core business systems such as payment systems and user management systems require stricter detection, while auxiliary businesses such as static resources and marketing activity pages can be appropriately relaxed), and historical attack factors (web applications that have recently been attacked can be included in the high-risk level for a period of time).

[0070] The risk levels are divided into three tiers: high risk, medium risk, and low risk. This can be achieved through automatic rules (based on weighted scores of the aforementioned factors) or through manual operation and maintenance settings. Under the high risk level, the decision threshold is a first threshold; under the medium risk level, the decision threshold is a second threshold; and under the low risk level, the decision threshold is a third threshold. The first threshold is less than the second threshold, and the second threshold is less than the third threshold. In the preferred implementation of this embodiment, the first threshold is 0.3, the second threshold is 0.5, and the third threshold is 0.7. Typical application scenarios include: during peak financial promotion periods (high risk level), a first threshold of 0.3 is used to increase detection sensitivity, triggering interception even with weak threat indications; during normal business hours (medium risk level), a second threshold of 0.5 is used, employing the default threshold; during off-peak business periods or planned maintenance periods (low risk level), a third threshold of 0.7 is used to increase the threshold and reduce interference from false alarms in operation and maintenance. Dynamic switching of risk levels can be triggered through scheduled tasks, external threat intelligence subscriptions, and manual operation and maintenance interfaces.

[0071] After determining the threat / normality of the current request in step S8, this embodiment does not stop there for requests deemed normal and allowed to proceed. Instead, it utilizes these allowed traffic flows to construct a self-evolving closed loop for the model, enabling it to continuously adapt to business changes. Therefore, step S9 is executed, corresponding to... Figure 4 The model update and self-optimization process is shown.

[0072] Step S9, as follows Figure 4 As shown, after determining that the current request is a normal request and allowing it, the model self-evolution step is executed. This step S9 is further decomposed into five sub-steps: anti-poisoning filtering, triggering incremental training, sandbox training and verification, dual-index hot replacement, and observation period rollback. The five sub-steps are executed in sequence, and the preferred implementation of each sub-step is as follows.

[0073] In the sub-step of the anti-poisoning filtering, considering that the closed loop of "automatic labeling of allow requests → feedback sample library" itself brings a potential attack surface (attackers can construct requests that are below the decision threshold but have malicious intent, causing them to be incorrectly judged as normal and enter the sample library, thus poisoning the training data of the baseline anomaly detection model), this embodiment introduces an anti-poisoning filtering mechanism.

[0074] Specifically, the second anomaly probability corresponding to the current request is compared with a preset poisoning filtering threshold. When the second anomaly probability is greater than the poisoning filtering threshold, the current request is discarded and not included in subsequent sample backflow; otherwise, the current request is marked as a normal sample and fed back to the data warehouse (the data warehouse stores the historical normal business log data). The current request is then merged with the existing historical normal business log data in the data warehouse to form an expanded sample library. The poisoning filtering threshold is strictly less than the decision threshold.

[0075] In the preferred embodiment of this example, when the decision threshold is 0.5, the poisoning filter threshold is 0.3, thus creating a "allow but not learn" intermediate zone between [0.3, 0.5). Even if a request is ultimately allowed, it will not enter the sample backflow as long as the second anomaly probability output by its large language model semantic analysis pipeline exceeds the poisoning filter threshold. This anti-poisoning filter mechanism reuses the large language model semantic analysis pipeline already running in the system without introducing an additional anti-poisoning model, realizing that the detection path is also the protection path; it specifically targets the attack surface of the self-evolving closed loop rather than general prompt word disinfection; and it creates an intermediate zone of allowing but not learning between the decision threshold and the poisoning filter threshold.

[0076] In the sub-step of triggering incremental training, incremental training is initiated when either of the following triggering conditions is met: first, the time interval since the last incremental training reaches a preset period threshold; second, the number of normal samples added to the expanded sample library relative to the last incremental training reaches a preset quantity threshold. In the preferred embodiment of this example, the preset period threshold is 24 hours, and the preset quantity threshold is between 10,000 and 100,000 samples (the specific value depends on the traffic scale of the web application). This dual-trigger mechanism ensures that even in low-traffic scenarios, the model can be updated on time (every 24 hours) to avoid long-term cumulative drift; and in high-traffic or sudden attack scenarios, the model can be updated immediately after the sample size reaches the target to quickly respond to business changes.

[0077] In the sub-step of sandbox training and validation, based on the expanded sample library, the unsupervised anomaly detection model is incrementally trained in a sandbox environment physically or logically isolated from the online analysis pipeline environment to generate candidate models. Considering that the native form of the isolated forest algorithm does not support strictly online incremental learning, this embodiment adopts one of the following two methods to implement the incremental training: First, full retraining: Based on the expanded full sample library, a complete isolated forest model is reconstructed (its training parameters are the same as the original isolated forest model), and the reconstructed isolated forest model is used as a candidate model; Second, isolated forest expansion algorithm: An isolated forest expansion algorithm with incremental learning capability is used (e.g., iForestASD adaptive sliding data isolated forest algorithm, or RRCF RobustRandom Cut Forest algorithm, or replacing older isolated trees in the original isolated forest with isolated trees constructed based on newly added samples according to a preset ratio), and the updated isolated forest model is used as a candidate model. Those skilled in the art can flexibly choose any of the above methods or their variations as equivalent implementations of the present invention based on factors such as computing resources, training time, and model continuity. In the best implementation, the first method, full retraining, is adopted because it is simple to implement and the training time is still controllable at the level of hundreds of thousands of samples (typically taking several minutes to tens of minutes).

[0078] After incremental training to obtain candidate models, bypass traffic copied from the real-time Web request data stream is used as verification traffic (this bypass traffic can be copied from the real-time Web request data stream through methods such as port mirroring (SPAN), network splitter (TAP), and message queue replication). The candidate models are then verified in the sandbox environment using this verification traffic to obtain the false positive rate (FPR) and true positive rate (TPR) of the candidate models on the verification traffic. Simultaneously, the corresponding FPR and TPR of the currently used unsupervised anomaly detection model on the verification traffic are also obtained. It should be noted that the true attributes (threat or normal) of each request on the verification traffic are obtained by using the combined judgment results of the baseline anomaly detection pipeline, the large language model semantic analysis pipeline, and the real-time behavioral indicator analysis pipeline on the verification traffic as pseudo-labels, supplemented by manual sampling correction, to meet the ground truth labeling requirements for FPR and TPR calculations.

[0079] In the dual-index hot replacement sub-step, the candidate model replaces the currently used unsupervised anomaly detection model with a hot replacement without downtime if and only if the false positive rate of the candidate model is not greater than the corresponding false positive rate of the currently used unsupervised anomaly detection model, and the true positive rate of the candidate model is not less than the corresponding true positive rate of the currently used unsupervised anomaly detection model; otherwise, the currently used unsupervised anomaly detection model is retained and the candidate model is discarded. The non-disruptive hot replacement can be implemented in any of the following ways: First, parallel dual-model operation with traffic switching (the online system simultaneously loads two isolated forest models, old and new, and gradually switches the requests to be detected to the new model through routing configuration, i.e., canary release); Second, atomic replacement of model handles (in memory, the isolated forest model handle referenced by the baseline anomaly detection pipeline is replaced from the old model to the new model in an atomic operation, and the old model is released after all processing requests are completed); Third, blue-green deployment (maintaining two sets of baseline anomaly detection pipelines, blue and green, the new model is first deployed to the backup green environment, and after the traffic is switched through the load balancer, the original primary blue environment becomes the new backup). The hot replacement process does not require stopping the operation of the online analysis pipeline, and the real-time detection of business requests is unaffected, achieving "zero business interruption" model updates. Deployment is only allowed when the candidate model does not degrade in both the false positive rate and true positive rate dimensions. This specific interpretation of "performance not lower than the original model" ensures that model updates only optimize and do not degrade the overall detection performance.

[0080] In the rollback sub-step during the observation period, after the no-downtime hot-swap, the online detection performance of the candidate model after the hot-swap is continuously monitored within a preset observation period. When the detection performance of the candidate model during the observation period decreases by more than a preset decay threshold relative to its detection performance in the sandbox environment, it is automatically rolled back to the currently used unsupervised anomaly detection model before the hot-swap. In the preferred embodiment of this example, the preset observation period is 24 to 72 hours, and the preset decay threshold is 5 percentage points (e.g., FPR increases by more than 5 percentage points or TPR decreases by more than 5 percentage points). The rollback process also adopts the no-downtime hot-swap method. After the rollback, the system records the reasons for failure (such as inconsistency between sandbox verification traffic and real traffic distribution, newly emerging attack patterns not covered by the sandbox, etc.) for reference in the next incremental training.

[0081] Thus, steps S1 to S9 complete a full multi-model collaborative web application security detection process and a self-evolving closed loop. However, considering the high inference cost of the semantic analysis pipeline of large language models (especially in high QPS scenarios), this embodiment also provides a computing power adaptive control mechanism, namely step S10, which dynamically adapts computing resources while ensuring detection accuracy.

[0082] Step S10: Continuously monitor the resource usage metrics of the computing nodes running the large language model semantic analysis pipeline. These metrics include at least one of the following: GPU memory usage, CPU utilization, and concurrent request processing rate per unit time. Monitoring can be achieved using tools such as Prometheus, Grafana, ELK Stack, and monitoring services from various cloud vendors. The sampling frequency can be configured from 1 to 10 seconds.

[0083] When the resource occupancy index exceeds a preset high-water level threshold, at least one of the following dynamic controls is executed. First, weight reduction: the weight β corresponding to the large language model semantic analysis pipeline is reduced, and the weights α and γ corresponding to the other pipelines are proportionally increased while maintaining the sum of all weights unchanged. For example, the default α=0.3, β=0.4, γ=0.3; under the high-water level, it can be adjusted to α=0.4, β=0.2, γ=0.4, making the fusion decision rely more on the outputs of the baseline anomaly detection pipeline and the real-time behavior indicator analysis pipeline. Second, large language model semantic analysis pipeline skipping: for current requests where the first anomaly probability output by the baseline anomaly detection pipeline for the current request is lower than a preset bypass threshold (i.e., requests that the baseline pipeline has strongly determined to be normal), the processing of the large language model semantic analysis pipeline for the current request is skipped, and the weighted fusion is performed only based on the first anomaly probability and the third anomaly probability according to the dynamically adjusted weights. For example, the bypass threshold can be set to 0.2, meaning that requests with an anomaly probability below 0.2 determined by the baseline pipeline will directly skip the semantic analysis pipeline of the large language model. Through these two controls, the inference load of the large language model can be reduced by 50% to 80% in high-water scenarios, maintaining the service availability of the overall pipeline.

[0084] When the resource usage index falls below the preset low watermark threshold and remains stable for a preset time window, the weights are restored to their original dynamic generation mechanism as described in step S7, and the large language model semantic analysis pipeline resumes processing all requests. The stable time window setting avoids frequent switching caused by repeated jumps between high and low watermarks in the resource usage index; a typical value is 1 to 5 minutes. To further avoid frequent high / low watermark switching, this embodiment employs a hysteresis threshold design: the high watermark threshold is greater than the low watermark threshold. For example, the high watermark threshold for GPU memory usage is 85%, and the low watermark threshold is 70%. Degradation is only triggered when the usage exceeds 85%, and recovery only occurs when the usage falls below 70% and remains stable for a time window. No switching occurs within the 70% to 85% range.

[0085] This concludes the complete description of the multi-model collaborative web application security detection method in this embodiment. The method continuously runs in a loop, performing real-time detection and decision-making for each current request through steps S1 to S9, continuously optimizing the model through the self-evolution closed loop in step S9, and ensuring service availability under high load scenarios through the adaptive control of computing power in step S10.

[0086] To illustrate the beneficial effects of this embodiment, the following comparative example is given based on the publicly available CSIC 2010 v2 HTTP dataset (the data is exemplary, and those skilled in the art can obtain the corresponding actual values ​​according to specific scenarios): Single isolated forest scheme (no large language model semantic analysis pipeline, no real-time behavior indicator analysis pipeline): Accuracy approximately 0.87, Precision approximately 0.85, Recall approximately 0.82, F1 approximately 0.83, FPR approximately 0.15; Single large language model semantic analysis scheme (no baseline anomaly detection pipeline, no real-time behavior indicator analysis pipeline): Accuracy approximately 0.91, Precision approximately 0.92, Recall approximately 0.88, F1 approximately 0.90, FPR approximately 0.08; Three-pipeline parallel plus static The weighted (α=β=γ=1 / 3) scheme has an accuracy of approximately 0.95, precision of approximately 0.94, recall of approximately 0.93, F1 score of approximately 0.93, and FPR of approximately 0.06. The scheme using three parallel pipelines with dynamic weights (F1 raised to the power of k) in this embodiment has an accuracy of approximately 0.97, precision of approximately 0.96, recall of approximately 0.96, F1 score of approximately 0.96, and FPR of approximately 0.04. The scheme with all features in this embodiment (dynamic weights, self-evolving closed loop, and anti-poisoning) has an accuracy of approximately 0.98, precision of approximately 0.97, recall of approximately 0.97, F1 score of approximately 0.97, and FPR of approximately 0.03. It can be seen that compared to a single model, this embodiment, through multi-pipeline collaboration and dynamic fusion, improves accuracy by approximately 7 to 11 percentage points, F1 score by approximately 7 to 14 percentage points, and reduces FPR by more than 10 percentage points. Compared to the static weighted multi-model scheme, the dynamic weight mechanism further reduces FPR by approximately 2 percentage points.

[0087] Example 2 This embodiment provides a multi-model collaborative web application security detection system. The system includes a data acquisition module, a parallel scheduling module, a baseline anomaly detection pipeline module, a large language model semantic analysis pipeline module, a real-time behavior indicator analysis pipeline module, a dynamic fusion decision module, a model offline training and update module, and a computing power adaptive control module.

[0088] The data acquisition module is configured to execute steps S1 and S2 as described in Embodiment 1. The parallel scheduling module is configured to execute step S3 as described in Embodiment 1. The baseline anomaly detection pipeline module is configured to execute step S4 as described in Embodiment 1. The large language model semantic analysis pipeline module is configured to execute step S5 as described in Embodiment 1. The real-time behavior indicator analysis pipeline module is configured to execute step S6 as described in Embodiment 1. The dynamic fusion decision module is configured to execute steps S7 and S8 as described in Embodiment 1. The offline training and update module is configured to execute step S9 as described in Embodiment 1. The adaptive computing power control module is configured to execute step S10 as described in Embodiment 1. The specific processing flow, preferred implementation method, and best implementation method of each module are described in the relevant descriptions of the corresponding steps in Embodiment 1, and will not be repeated here.

[0089] The system's modules can be implemented using a unified microservice architecture, with each module deployed as an independent service in a containerized manner (e.g., based on Docker and Kubernetes). Asynchronous communication between modules is achieved through message queues (Kafka, etc.), unified monitoring is provided by Prometheus and Grafana, and log aggregation is performed using the ELK Stack. This results in a highly available, horizontally scalable, and easy-to-maintain engineering deployment. Alternatively, the system's modules can be stored as computer programs on at least one non-volatile computer-readable storage medium. When at least one processor executes the computer program, it implements the functions configured for each module. The non-volatile computer-readable storage medium includes, but is not limited to, hard disks, solid-state drives, flash memory, ROM, EPROM, EEPROM, CD-ROM, DVD-ROM, and any other storage medium capable of long-term storage of computer programs.

[0090] The above description of the embodiments is provided to enable those skilled in the art to understand and apply the present invention. It will be apparent to those skilled in the art that various modifications can be made to the above embodiments, and the general principles described herein can be applied to other embodiments without creative effort. Therefore, the present invention is not limited to the above embodiments, and any improvements and modifications made to the present invention by those skilled in the art based on the disclosure thereof should be within the scope of protection of the present invention.

[0091] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

Claims

1. A multi-model collaborative web application security detection method, characterized in that, include: Acquire real-time web request data streams and historical normal business log data, wherein the real-time web request data stream includes several current requests; For the current request in the real-time Web request data stream, the current request is input in parallel into the baseline anomaly detection pipeline, the large language model semantic analysis pipeline, and the real-time behavior indicator analysis pipeline; In the baseline anomaly detection pipeline, based on an unsupervised anomaly detection model pre-trained with the historical normal business log data, a first anomaly probability reflecting the degree of deviation of the current request from the normal pattern reflected by the historical normal business log data is obtained. In the semantic analysis pipeline of the large language model, key fields are extracted from the current request and prompt words are constructed based on the key fields; The prompt word is input into a large language model to obtain the attack probability output by the large language model for each of the multiple known attack categories; a second anomaly probability is obtained based on the attack probability, the second anomaly probability reflecting the possibility that the current request has at least one of the multiple known attack categories, and the second anomaly probability does not decrease as any of the attack probabilities increases; In the real-time behavior indicator analysis pipeline, the request source of the current request is obtained, and based on the statistical information of the real-time web request data stream within the sliding time window, the behavior indicator of the request source within the sliding time window is calculated, and a third anomaly probability is obtained based on the behavior indicator. The first anomaly probability, the second anomaly probability, and the third anomaly probability are weighted and fused to obtain a comprehensive threat assessment value; wherein, the weights used in the weighted fusion are dynamically adjusted based on the detection performance of each pipeline in the past detection cycle, and the weight corresponding to each pipeline is positively correlated with the detection performance of that pipeline; The comprehensive threat assessment value is compared with the decision threshold: when the comprehensive threat assessment value is not less than the decision threshold, the current request is determined to be a threat request and an interception or alarm action is performed. When the comprehensive threat assessment value is less than the decision threshold, the current request is determined to be a normal request and is allowed.

2. The method according to claim 1, characterized in that, The baseline anomaly detection pipeline obtains the first anomaly probability in the following manner: Extract multi-dimensional features from the current request, the multi-dimensional features including at least two of the following: character-level features, statistical distribution features, and path structure features reflecting the current request; The character hierarchy feature includes at least one of the frequency of special characters or the density of SQL keywords in the current request; the statistical distribution feature includes at least one of the string length, information entropy, or proportion of numeric characters in the current request; the path structure feature includes at least one of the URL path depth or the degree of abnormal arrangement of request parameter positions in the current request. The unsupervised anomaly detection model is an isolated forest model; the isolated forest model is obtained through offline training based on the historical normal business log data. The multi-dimensional features are input into the isolated forest model, the average path length of the multi-dimensional features on each isolated tree in the isolated forest model is calculated, and the average path length is normalized to the first anomaly probability.

3. The method according to claim 1, characterized in that, The large language model semantic analysis pipeline processes the current request and obtains the second anomaly probability in the following manner: Extracting key fields from the current request to construct the prompt word specifically involves: the key fields including fields from the URL part, request header part, and request body part of the current request; filling each field in the key fields into the fill position corresponding to the part to which the field belongs in a preset structured prompt word template to obtain the prompt word; The structured prompt template includes padding for filling in URL fields, padding for filling in request header fields, padding for filling in request body fields, and instruction text that instructs the large language model to perform security risk analysis on the filled fields and output the attack probability according to the various known attack categories. The prompt words are input into the large language model to obtain the attack probabilities output by the large language model for the various known attack categories respectively; The second anomaly probability is calculated using the following formula: Where P2 is the second anomaly probability. The large language model outputs the attack probability for the i-th attack category among the various known attack categories, and the product operation in the formula covers all of the various known attack categories; The known attack categories include at least: SQL injection, cross-site scripting, command injection, path traversal, file inclusion, server-side request forgery, XML external entity injection, and deserialization attacks.

4. The method according to claim 1, characterized in that, The real-time behavioral metrics analysis pipeline also meets the following requirements: The source of the current request is the source IP address corresponding to the current request; The behavioral metrics include at least two of the following: the request frequency anomaly of the request source, the access sequence anomaly of the request source, and the reputation score of the request source. The length of the sliding time window is 1 to 10 minutes; The request frequency anomaly is obtained by comparing the request frequency of the request source within the sliding time window with the average request frequency of the request source within a historical long time window; The access sequence anomaly degree is calculated based on the edit distance between the URL sequence accessed by the request source within the sliding time window and the preset normal business access sequence pattern.

5. The method according to claim 1, characterized in that, The weighted fusion also satisfies the following limitations: The comprehensive threat assessment value is calculated according to the following formula: ； Where S is the comprehensive threat assessment value; P1, P2, and P3 are the first anomaly probability, the second anomaly probability, and the third anomaly probability, respectively; α, β, and γ are the weights corresponding to P1, P2, and P3, respectively, and α, β, and γ satisfy... ; The weights α, β, and γ are determined by the detection performance of each channel over past detection periods, whereby the detection performance includes at least one of precision, recall, and F1 score. The weights α, β, and γ satisfy the following condition: the higher the detection performance of a channel, the larger the weight value corresponding to that channel; and the weights α, β, and γ are normalized to ensure that... .

6. The method according to claim 1, characterized in that, The method further includes: determining the risk level of the security operation environment in which the Web application is located, the risk level including high risk level, medium risk level and low risk level; the decision threshold dynamically takes one of the following values ​​according to the risk level: a first threshold under the high risk level; a second threshold under the medium risk level; a third threshold under the low risk level; the first threshold is less than the second threshold, and the second threshold is less than the third threshold.

7. The method according to claim 1, characterized in that, After determining that the current request is a normal request and allowing it to proceed, the method further includes the following model self-evolution step: The second anomaly probability corresponding to the current request is compared with a preset poisoning filtering threshold. When the second anomaly probability is greater than the poisoning filtering threshold, the current request is discarded and not included in subsequent sample backflow. Otherwise, the current request is marked as a normal sample and fed back to the data warehouse, which stores the historical normal business log data. The current request is merged with the existing historical normal business log data in the data warehouse to form an expanded sample library. The poisoning filtering threshold is less than the decision threshold. Incremental model training will be initiated when any of the following triggering conditions are met: the time interval since the last incremental model training reaches a preset period threshold; or the number of normal samples added to the expanded sample library relative to the last incremental model training reaches a preset number threshold. Based on the expanded sample library, the unsupervised anomaly detection model is incrementally trained in a sandbox environment that is physically or logically isolated from the online analysis pipeline environment to generate candidate models. The bypass traffic obtained from the copy of the real-time Web request data stream is used as the verification traffic; the candidate model is verified in the sandbox environment using the verification traffic to obtain the false positive rate and true positive rate of the candidate model on the verification traffic; at the same time, the corresponding false positive rate and corresponding true positive rate of the currently used unsupervised anomaly detection model on the verification traffic are obtained. The candidate model replaces the currently used unsupervised anomaly detection model with a hot-swap mechanism without downtime if and only if the false positive rate of the candidate model is not greater than the corresponding false positive rate of the currently used unsupervised anomaly detection model, and the true positive rate of the candidate model is not less than the corresponding true positive rate of the currently used unsupervised anomaly detection model; otherwise, the currently used unsupervised anomaly detection model is retained and the candidate model is discarded. After the hot-swap without downtime, the online detection performance of the candidate model after the hot-swap is continuously monitored during a preset observation period. When the detection performance of the candidate model during the observation period decreases by more than a preset decay threshold relative to its detection performance in the sandbox environment, it is automatically rolled back to the currently used unsupervised anomaly detection model before the hot-swap.

8. The method according to claim 1, characterized in that, The step of inputting the current request into the baseline anomaly detection pipeline, the large language model semantic analysis pipeline, and the real-time behavior indicator analysis pipeline in parallel includes: asynchronously distributing the current request to the baseline anomaly detection pipeline, the large language model semantic analysis pipeline, and the real-time behavior indicator analysis pipeline via a message queue; wherein, the baseline anomaly detection pipeline is deployed on a first computing resource, the large language model semantic analysis pipeline is deployed on a second computing resource, and the real-time behavior indicator analysis pipeline is deployed on a third computing resource; the first computing resource, the second computing resource, and the third computing resource are independent of each other; the second computing resource includes at least a graphics processor.

9. The method according to claim 1, characterized in that, The method also includes a computing power adaptive control step: Continuously monitor the resource usage indicators of the computing nodes running the large language model semantic analysis pipeline. The resource usage indicators include at least one of the following: graphics processor memory usage, CPU utilization, and concurrent request processing rate per unit time. When the resource occupancy index exceeds a preset high water level threshold, at least one of the following dynamic controls is executed: (a) the weights corresponding to the large language model semantic analysis pipeline are reduced, and the weights corresponding to the other pipelines are increased proportionally while keeping the sum of the weights constant; (b) when the first anomaly probability output by the baseline anomaly detection pipeline for the current request is lower than a preset bypass threshold, the processing of the large language model semantic analysis pipeline for the current request is skipped, and the weighted fusion is performed only based on the first anomaly probability and the third anomaly probability according to the dynamically adjusted weights. When the resource usage index falls below the preset low water level threshold and remains stable for a preset time window, the weights are restored to be dynamically generated by the original weighted fusion mechanism, and the processing of all requests by the large language model semantic analysis pipeline is restored.

10. A multi-model collaborative web application security detection system, characterized in that, The system for implementing the method according to any one of claims 1-9 comprises: The data acquisition module is configured to acquire real-time web request data streams and historical normal business log data, wherein the real-time web request data streams include several current requests; The parallel scheduling module is configured to input the current request in parallel into the baseline anomaly detection pipeline module, the large language model semantic analysis pipeline module, and the real-time behavior indicator analysis pipeline module for the current request in the real-time Web request data stream. The baseline anomaly detection pipeline module is configured to obtain a first anomaly probability reflecting the degree of deviation of the current request from the normal pattern reflected by the historical normal business log data, based on an unsupervised anomaly detection model pre-trained with the historical normal business log data. The large language model semantic analysis pipeline module is configured to extract key fields from the current request and construct prompt words based on the key fields, input the prompt words into the large language model to obtain the attack probabilities output by the large language model for multiple known attack categories, and obtain a second anomaly probability based on the attack probabilities. The second anomaly probability reflects the possibility that the current request has at least one of the multiple known attack categories, and the second anomaly probability does not decrease as any of the attack probabilities increases. The real-time behavior indicator analysis pipeline module is configured to obtain the request source of the current request, calculate the behavior indicator of the request source within the sliding time window based on the statistical information of the real-time Web request data stream within the sliding time window, and obtain a third anomaly probability based on the behavior indicator. The dynamic fusion decision module is configured to perform weighted fusion of the first anomaly probability, the second anomaly probability, and the third anomaly probability to obtain a comprehensive threat assessment value. The weights used in the weighted fusion are dynamically adjusted based on the detection performance of each pipeline in the past detection cycle, and the weight corresponding to each pipeline is positively correlated with the detection performance of that pipeline. The module is also configured to compare the comprehensive threat assessment value with a decision threshold. When the comprehensive threat assessment value is not less than the decision threshold, the current request is determined to be a threat request and an interception or alarm action is performed. When the comprehensive threat assessment value is less than the decision threshold, the current request is determined to be a normal request and is allowed. The offline training and update module is configured to perform the model self-evolution step; The computing power adaptive control module is configured to execute computing power adaptive control steps.

Images