Method and device for automatically reconstructing stateful Web attack preposed step sequence

Abstract

The invention particularly relates to a method and device for automatically reconstructing a stateful Web attack front step sequence, and the method comprises the steps: receiving a final attack request; based on the final attack request, constructing a target state portrait, and based on the target state portrait, calculating a state distance between the current application state and the target state; determining a shortest path of the target state portrait based on a preset data-driven guide model and the state distance, and generating a candidate request sequence by using a preset operation sequence generation engine based on the shortest path; and based on a preset comprehensive score function, evaluating the difference between the rear-end state after executing the candidate request sequence and the target state portrait to obtain a comprehensive score of the candidate request sequence, and when the comprehensive score meets a preset condition, taking the candidate request sequence as a request sequence corresponding to the comprehensive score. Therefore, the problems that automatic reconstruction of the stateful Web attack sequence is difficult, multi-step vulnerability verification efficiency is low, attack investigation depends on manpower and the like are solved.

Description

Technical Field

[0001] This application relates to the field of computer security technology, and in particular to a method and apparatus for automatically reconstructing the sequence of pre-attack steps in a stateful Web attack. Background Technology

[0002] Modern web applications have evolved into complex and highly stateful systems. However, this complexity also introduces new attack surfaces; therefore, a core and pressing question is: how can we automatically and efficiently reconstruct the complete sequence of preceding state constructs, given only the final attack request? In related technologies, there has been extensive research on automated web application testing for this task. One type of work involves coverage-guided grey-box fuzzers, which excel at expanding code execution paths. To improve efficiency, researchers have proposed targeted fuzzers, focusing fuzzing on predefined, potentially dangerous code locations within web applications. Another more relevant category of work focuses on fuzzing sequences of RESTful API (Representational State Transfer API) calls, attempting to discover deeper vulnerabilities by generating longer request sequences. Some of these methods are data-driven, assuming that longer sequences are more likely to trigger defects; others rely on manually annotated API (Application Programming Interface) specifications or infer API dependencies through keyword matching and REST (Representational State Transfer) semantics.

[0003] However, the methods of related technologies still have significant shortcomings in terms of exploiting the final attack state, understanding existing backend values, and robustness under non-ideal REST designs, which urgently need to be addressed. Summary of the Invention

[0004] This application provides a method and apparatus for automatically reconstructing the sequence of pre-attack steps in a stateful web attack, in order to solve problems such as the difficulty in automatically reconstructing stateful web attack sequences, the low efficiency of multi-step vulnerability verification, and the reliance on manual investigation for attack investigation.

[0005] The first aspect of this application provides a method for automatically reconstructing the pre-attack sequence of a stateful web attack, comprising the following steps: Receive the final attack request; Based on the final attack request, a target state profile is constructed, and based on the target state profile, the state distance between the current application state and the target state is calculated. The shortest path to the target state profile is determined based on a preset data-driven guidance model and the state distance, and a candidate request sequence is generated based on the shortest path using a preset running sequence generation engine. Based on a preset comprehensive scoring function, the difference between the backend state after executing the candidate request sequence and the target state profile is evaluated to obtain a comprehensive score for the candidate request sequence. When the comprehensive score meets a preset condition, the candidate request sequence is taken as the request sequence corresponding to the comprehensive score.

[0006] Optionally, constructing the target state profile based on the final attack request includes: A lightweight probe is injected into a critical lifecycle point of the target web application framework, and based on the lightweight probe, the complete call sequence of the final attack request is isolated. File dependencies and database dependencies are extracted from the complete call sequence, and the file dependencies and database dependencies are normalized into a tabular representation to form the target state profile.

[0007] Optionally, before determining the shortest path to the target state profile based on the preset guidance model and the state distance, the method further includes: Construct an API dependency graph and a parameter source association model; The preset data-driven guidance model is obtained based on the API dependency graph and the parameter source association model.

[0008] Optionally, the construction parameters are derived from the association model, including: Retrieve multiple request parameters and multiple data source locations; The historical values ​​of each of the request parameters are collected to form a first value set, and the historical values ​​of each of the data source locations are collected to form a second value set; Calculate the Jaccard similarity between the first set of values ​​and the second set of values, and determine the association score between each request parameter and each data source location based on the Jaccard similarity; Based on the association score, the multiple data source locations are sorted to obtain a list of data source locations, and the parameter source association model is determined based on the list of data source locations.

[0009] Optionally, the construction of the API dependency graph includes: Based on the request parameters, calculate the direct data flow dependencies and indirect data flow dependencies between APIs; The direct data flow dependency and the indirect data flow dependency are probabilistically fused to obtain the API succession probability, and the API dependency graph is constructed based on the API succession probability.

[0010] Optionally, the preset comprehensive scoring function is: ; in, The overall score for the candidate request sequence. for The weight parameters, As a state distance reward, for The weight parameters, To cover the bonus rewards, for The weight parameters, Rewards are given for response value ranges.

[0011] A second aspect of this application provides an apparatus for automatically reconstructing the sequence of pre-attack steps in a stateful web attack, comprising: The receiving module is used to receive the final attack request; The calculation module is used to construct a target state profile based on the final attack request, and to calculate the state distance between the current application state and the target state based on the target state profile. The generation module is used to determine the shortest path of the target state profile based on the preset data-driven guidance model and the state distance, and to generate a candidate request sequence based on the shortest path using a preset running sequence generation engine. The evaluation module is used to evaluate the difference between the backend state after executing the candidate request sequence and the target state profile based on a preset comprehensive scoring function, and obtain a comprehensive score for the candidate request sequence. When the comprehensive score meets a preset condition, the candidate request sequence is used as the request sequence corresponding to the comprehensive score.

[0012] Optionally, the computing module is specifically used for: A lightweight probe is injected into a critical lifecycle point of the target web application framework, and based on the lightweight probe, the complete call sequence of the final attack request is isolated. File dependencies and database dependencies are extracted from the complete call sequence, and the file dependencies and database dependencies are normalized into a tabular representation to form the target state profile.

[0013] Optionally, before determining the shortest path to the target state profile based on the preset guidance model and the state distance, the generation module is further configured to: Construct an API dependency graph and a parameter source association model; The preset data-driven guidance model is obtained based on the API dependency graph and the parameter source association model.

[0014] Optionally, the generation module is specifically used for: Retrieve multiple request parameters and multiple data source locations; The historical values ​​of each of the request parameters are collected to form a first value set, and the historical values ​​of each of the data source locations are collected to form a second value set; Calculate the Jaccard similarity between the first set of values ​​and the second set of values, and determine the association score between each request parameter and each data source location based on the Jaccard similarity; Based on the association score, the multiple data source locations are sorted to obtain a list of data source locations, and the parameter source association model is determined based on the list of data source locations.

[0015] Optionally, the generation module is specifically used for: Based on the request parameters, calculate the direct data flow dependencies and indirect data flow dependencies between APIs; The direct data flow dependency and the indirect data flow dependency are probabilistically fused to obtain the API succession probability, and the API dependency graph is constructed based on the API succession probability.

[0016] Optionally, the preset comprehensive scoring function is: ; in, The overall score for the candidate request sequence. for The weight parameters, As a state distance reward, for The weight parameters, To cover the bonus rewards, for The weight parameters, Rewards are given for response value ranges.

[0017] A third aspect of this application provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being configured to perform a method for automatically reconstructing a sequence of pre-attack steps for a stateful web attack as described in the above embodiments.

[0018] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the method for automatically reconstructing a sequence of pre-attack steps for a stateful web attack as described in the above embodiments.

[0019] A fifth aspect of this application provides a computer program product storing a computer program that, when executed by a processor, implements the method for automatically reconstructing a sequence of pre-attack steps for a stateful web attack as described in the above embodiments.

[0020] Therefore, this application embodiment constructs a target state profile based on the received final attack request, and calculates the state distance between the current application state and the target state based on the target state profile; determines the shortest path of the target state profile based on a preset data-driven guidance model and the state distance, and generates a candidate request sequence based on the shortest path using a preset execution sequence generation engine; evaluates the difference between the backend state after executing the candidate request sequence and the target state profile based on a preset comprehensive scoring function, and obtains a comprehensive score for the candidate request sequence. When the comprehensive score meets preset conditions, the candidate request sequence is used as the request sequence corresponding to the comprehensive score. This solves the problems of difficult automated reconstruction of stateful Web attack sequences, low efficiency of multi-step vulnerability verification, and reliance on manual attack investigation.

[0021] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0022] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a method for automatically reconstructing a sequence of pre-attack steps for a stateful web attack, according to an embodiment of this application. Figure 2 This is a schematic diagram of the target state profile of a method for automatically reconstructing a sequence of pre-attack steps in a stateful web attack, according to an embodiment of this application. Figure 3 This is a parameter-source association diagram of a method for automatically reconstructing a sequence of pre-attack steps in a stateful web attack, according to an embodiment of this application. Figure 4 This is a schematic diagram of API dependencies for a method for automatically reconstructing a sequence of pre-attack steps in a stateful web attack, according to an embodiment of this application. Figure 5 This is a schematic diagram of the overall architecture of a method for automatically reconstructing a sequence of pre-attack steps in a stateful web attack, according to an embodiment of this application. Figure 6 This is a schematic diagram of ablation experiment results for a method for automatically reconstructing the pre-attack sequence of a stateful web attack according to an embodiment of this application; Figure 7 This is a schematic diagram of the key final four steps of YApi RCE, a method for automatically reconstructing the pre-attack sequence of a stateful web attack according to an embodiment of this application. Figure 8 This is a timeline diagram illustrating the operation of a method for automatically reconstructing a sequence of pre-attack steps in a stateful web attack, according to an embodiment of this application. Figure 9 This is a schematic diagram illustrating the evolution of seed scores during the YApi reconstruction process of a method for automatically reconstructing a sequence of pre-attack steps in a stateful web attack, according to an embodiment of this application. Figure 10 This is a schematic diagram of the heuristic weight change result of a method for automatically reconstructing the sequence of pre-steps of a stateful web attack according to an embodiment of this application; Figure 11 Fusion hyperparameters for a method for automatically reconstructing the pre-attack sequence of a stateful web attack, according to an embodiment of this application. Schematic diagram illustrating the impact on TTV; Figure 12 This is a schematic diagram of an apparatus for automatically reconstructing the sequence of pre-attack steps in a stateful web attack, according to an embodiment of this application. Figure 13 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0023] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0024] Before introducing the method for automatically reconstructing the pre-attack sequence of a stateful web attack according to the embodiments of this application, let's briefly introduce the methods for automatically reconstructing the pre-attack sequence of a stateful web attack in related technologies.

[0025] Specifically, modern web applications have evolved into complex and highly stateful systems. However, this complexity also introduces new attack surfaces: many high-risk vulnerabilities are not triggered by a single, independent request, but rather by a multi-stage attack sequence. Attackers typically need to send a series of carefully crafted requests to gradually push the system into a specific, exploitable vulnerable state, and finally trigger the malicious payload with the last request. For example, an attacker might first exploit a privilege escalation vulnerability to modify system configuration, then upload a seemingly normal file through another API, and finally execute that file through a third request, thereby achieving remote code execution.

[0026] In these types of attack scenarios, security analysts relying on Intrusion Detection Systems (IDS) or forensic tools often only capture the final request in the attack chain that triggers the malicious payload. However, this request is merely the "tip of the iceberg." Lacking the preceding state construction process, analysts cannot successfully reproduce the attack chain in their local environment. This inability to fully reproduce the attack process severely hinders critical security tasks, including root cause analysis, patch verification, and the generation of accurate signature rules for future defenses. Therefore, a core and urgent question is: how can we automatically and efficiently reconstruct the complete preceding state construction sequence, given only the final attack request? In related technologies, automated web application testing has been extensively researched for this task. One type of work consists of coverage-guided grey-box fuzzers, which excel at expanding code execution paths but lack awareness of specific vulnerability targets (goal-blind). To improve efficiency, researchers have proposed targeted fuzzers, focusing fuzzing on predefined, potentially dangerous code locations within web applications. However, these tools target single code locations, rather than the complex application states required for multi-step attacks. They are designed to construct inputs that reach a code endpoint within a single request, but cannot reason about and generate sequences of states used to construct attack premises across multiple requests. Therefore, their efficiency remains limited in scenarios involving reconstructing stateful attack sequences. Another more relevant type of work focuses on fuzzing sequences of RESTful API calls, attempting to discover deeper vulnerabilities by generating longer request sequences. Some of these methods are data-driven, assuming longer sequences are more likely to trigger defects; others rely on manually annotated API specifications or infer API dependencies through keyword matching and REST semantics.

[0027] However, despite these advancements, fundamental limitations remain in addressing the research questions, including the following: Lack of goal orientation: The relevant sequence generation strategies—whether driven by sequence length, relying on manual annotation, or based on keyword heuristics—fail to utilize the crucial information of the final desired attack state. Their exploration resembles more of a blind search than guided path planning.

[0028] Stateless parameter generation: These methods typically populate parameter values ​​by learning from previous requests / responses, neglecting the importance of backend application state. In multi-step attack scenarios, many critical parameters (such as injected commands, specific resource IDs, etc.) should not be generated from scratch, but rather already exist in the database or file system. The real challenge is to locate and backtrack these correct, existing values ​​from the backend state and correctly associate them with the corresponding request parameters.

[0029] Reliance on rigid semantic assumptions: Some methods rely heavily on expert knowledge for annotation, which is both expensive and difficult to generalize; others rely on idealized REST design conventions to infer API dependencies, which often fail in practice because many real-world applications do not follow these specifications.

[0030] In summary, the methods of these technologies still have significant shortcomings in terms of utilizing the final attack state, understanding existing backend values, and robustness under non-ideal REST designs.

[0031] This application addresses the aforementioned problems by proposing a method for automatically reconstructing the pre-attack sequence of stateful web attacks. In this method, embodiments construct a target state profile based on the received final attack request, and calculate the state distance between the current application state and the target state based on the target state profile. The shortest path to the target state profile is determined based on a preset data-driven guidance model and the state distance, and a candidate request sequence is generated using a preset execution sequence generation engine based on the shortest path. A preset comprehensive scoring function evaluates the difference between the backend state after executing the candidate request sequence and the target state profile, obtaining a comprehensive score for the candidate request sequence. When the comprehensive score meets preset conditions, the candidate request sequence is used as the request sequence corresponding to the comprehensive score. This solves the problems of difficult automated reconstruction of stateful web attack sequences, low efficiency of multi-step vulnerability verification, and reliance on manual attack investigation.

[0032] Specifically, Figure 1 This is a flowchart illustrating a method for automatically reconstructing the sequence of pre-attack steps in a stateful web attack, as provided in an embodiment of this application.

[0033] like Figure 1As shown, the method for automatically reconstructing the sequence of pre-attack steps in a stateful web attack includes the following steps: In step S101, the final attack request is received. In this context, the final attack request refers to the last HTTP request in a multi-step stateful web attack chain that directly triggers the vulnerability or achieves the attack target.

[0034] Specifically, raw HTTP request data that has been proven to successfully trigger vulnerabilities are obtained from multiple secure data sources. The received requests must meet the basic characteristics of state dependency and triggerable vulnerabilities, laying a reliable data foundation for subsequent intelligent sequence reconstruction.

[0035] In step S102, a target state profile is constructed based on the final attack request, and the state distance between the current application state and the target state is calculated based on the target state profile.

[0036] In this context, the target state profile refers to a complete snapshot of the state constructed by dynamically analyzing the final attack request, extracting and structuring all backend persistent data that the successful execution directly depends on, and representing a specific description of the ideal backend state that the attacker attempts to construct through a preceding sequence to trigger the final vulnerability. State distance is a metric used to quantify the degree of difference between the current application state and the target state profile.

[0037] Specifically, by dynamically analyzing system calls (syscalls) of the final request, the precise data dependencies on the backend database and file system are extracted, thereby constructing a target state profile. This target state profile clarifies the fuzz tester's ultimate goal. Based on this, a novel state distance metric based on bipartite graph minimum weight matching is proposed. State distance can accurately quantify the difference between the current state and the target state, providing clear navigation signals for the fuzz tester.

[0038] Optionally, in some embodiments, constructing a target state profile based on the final attack request includes: injecting lightweight probes into key lifecycle points of the target web application framework; isolating the complete call sequence of the final attack request based on the lightweight probes; extracting file dependencies and database dependencies from the complete call sequence; and normalizing the file dependencies and database dependencies into a tabular representation to form a target state profile.

[0039] Understandably, lightweight probes are injected at key lifecycle points in the web application framework to record events marked with unique request IDs. These markers deterministically partition the global system call log, precisely isolating the complete system call sequence belonging only to the final request. This sequence provides a complete record of all underlying activities triggered by the request. After obtaining the corresponding system call sequence, its dependencies on file and database reads are further extracted, specifically including: File dependencies: analyzing file-related system calls (e.g., openat, read) to identify the file path requested and the specific content retrieved. Database dependencies: Extracting database dependencies is more complex, involving cross-host associations between the application server and the database server. We first identify relevant network connections (based on quadruple / quintuple pairs) and their active time windows from the request's system call sequence; then, we correlate this information with the database server logs to locate the specific worker process; finally, by examining the records written to the database query log by this worker process, we extract the actually executed SELECT queries and their returned result sets.

[0040] Furthermore, such as Figure 2 As shown, Figure 2 This is a schematic diagram of the target state profile of a method for automatically reconstructing the pre-attack sequence of a stateful web attack according to an embodiment of this application. The final output is a structured target state profile. To facilitate unified state measurement, all extracted dependencies are normalized into a common tabular representation: database dependencies are retained in the original (table_name, row_data) format; file dependencies are abstracted into a conceptual `files` table, using a row structure of (filename, content). For example, a file dependency can be represented as (table: "files", row: {"filename": " / etc / config.xml", "content": " <user> admin< / user> This isomorphism process allows the target state to be viewed as a set of tables and rows, and provides a unified data model for subsequent state distance calculations. That is, it uses general methods such as bipartite graph matching to measure state differences, thereby providing a clear and quantifiable target for the fuzz tester.

[0041] In step S103, the shortest path to the target state profile is determined based on the preset data-driven guidance model and state distance, and a candidate request sequence is generated based on the shortest path using a preset running sequence generation engine.

[0042] The preset data-driven guidance model refers to a set of probabilistic models and relationship graphs constructed in the offline stage by automatically analyzing the historical normal traffic logs, database snapshots and execution trajectories of the target web application's final attack requests. This set is used to intelligently guide the fuzzy test search process in the online stage.

[0043] Specifically, this embodiment utilizes a pre-defined data-driven guidance model as the core knowledge base, and then enters the execution phase through a target-oriented fuzzing engine (a pre-defined execution sequence generation engine). The pre-defined execution sequence generation engine formulates the reconstruction task as an iterative search problem, with the goal of finding a request sequence in the application's state space that leads to the target state portrait. Its execution is driven by a continuous fuzzy loop, which orchestrates core modules for guided sequence mutation and state-guided seed evaluation to systematically explore the application's state space.

[0044] Furthermore, the fuzzy loop iteratively selects seed sequences using a power scheduler. The selected seeds are mutated via guided sequence mutation to obtain candidate sequences, which are then executed in an isolated environment. The execution results of the candidate sequences are evaluated by the proposed state-guided evaluation module. Simulated annealing is then employed to determine whether to add the candidate to the seed pool, thus achieving a balance between exploitation and exploration.

[0045] Furthermore, sequence variation occurs through the seed sequence. Then, a carefully crafted new request is added to generate candidate sequences. The construction process consists of two steps: first, selecting the most promising API for the next step; second, accurately populating the request parameters for that API.

[0046] To avoid the combinatorial explosion problem caused by blind API selection, a multi-heuristic strategy is introduced to score and rank candidate APIs. For the current sequence... With a certain candidate API Its scoring integrates three types of information: API statistical relationships, potential contributions to the target state, and immediate parameter satisfiability. (Comprehensive score) Defined as a weighted product of three complementary heuristic functions: ; in, The hyperparameters are used to adjust the importance of each heuristic. Three types of heuristics are as follows: 1) Transition Heuristic This heuristic measures the candidates. In the current sequence The statistical probability of subsequent calls answers the question: "Given the existing call sequence, what is the probability of executing (b) next?". This relies on the API dependency graph and uses an exponential decay function to assign decreasing weights to historical calls, thus amplifying the impact of recent operations. ; in, From the API dependency graph arrive The edge weights (i.e., transition probabilities). This is the decay factor. This design ensures that the generated sequence is more likely to follow common call patterns and backend state access relationships that actually occur in normal traffic.

[0047] 2) Goal-oriented heuristic ( This heuristic is used to evaluate candidate APIs. The potential contribution to bringing the current state closer to the final target state effectively guides the exploration towards a path that can bridge the gap between the current state and the target state. The calculation process is as follows: First, by comparing the current sequence The generated set of states Target state profile Determine the set of missing state entities. Secondly, identify the target API set. That is, all APIs capable of writing to (creating or modifying) these missing state entities. Finally, for any candidate API... Its potential is defined as the potential to emerge from the API dependency graph. To any target The probability of the maximum probability path: ; in, Indicates from arrive The probability of the path with the highest probability (i.e., the maximum value of the product of the weights of the edges on the path).

[0048] To efficiently solve this maximum product path problem, a common logarithmic transformation is used: the edge weights are... Mapping as cost This transforms the maximum product path problem into an equivalent shortest path problem. Subsequently, on the reverse graph, with the target node set... Run Dijkstra's algorithm once from the starting point to calculate the shortest path distance from each API to the target set. If implemented using a binary heap, the time complexity of this single Dijkstra's algorithm is O(log n). ,in For the number of API nodes, The number of edges is given, and this complexity makes the method acceptablely efficient in online fuzzing scenarios.

[0049] 3) Usability heuristic ( This heuristic is used to perform a critical feasibility pre-check before selecting an API, in order to estimate candidate APIs. Whether execution can be successfully performed in the current context. Its purpose is to avoid exploring APIs whose parameters cannot be satisfied and are destined to be invalid. The calculation method is: for each parameter of the candidate API... Determine whether a high-confidence value can be filled in from a currently available data source: ; Single parameter Satisfactionability is defined as: ; in, Indicates the execution sequence The set of all currently available data source locations; Jaccard similarity in an offline association model; weighting function This is used to prioritize data sources that are more context-sensitive (such as previous responses or target state profiles) relative to the initial general corpus.

[0050] Therefore, by jointly evaluating these three types of heuristics, we can select APIs that simultaneously possess statistical reasonableness, goal orientation, and immediate executability, thereby achieving efficient and accurate sequence reconstruction. The candidate request sequence inherits legitimate call patterns learned from normal traffic and precisely targets the specific data requirements for constructing the state needed for the attack, thus transforming the blind mutation of traditional fuzzing into an efficient target state construction process guided by precise state feedback.

[0051] In step S104, based on a preset comprehensive scoring function, the difference between the backend state after executing the candidate request sequence and the target state profile is evaluated to obtain the comprehensive score of the candidate request sequence. When the comprehensive score meets the preset conditions, the candidate request sequence is used as the request sequence corresponding to the comprehensive score.

[0052] Optionally, in some embodiments, the preset comprehensive scoring function is: ; in, The overall score for the candidate request sequence. for The weight parameters, As a state distance reward, for The weight parameters, To cover the bonus rewards, for The weight parameters, Rewards are given for response value ranges.

[0053] The pre-defined comprehensive scoring function refers to a standardized evaluation model used in the fuzzy testing process to quantitatively assess the overall quality and potential of each candidate request sequence.

[0054] Specifically, to quantitatively evaluate each new candidate sequence, a state-guided evaluation mechanism is adopted. This mechanism uses a comprehensive scoring function (a pre-defined comprehensive scoring function) to combine the proposed state distance index with traditional exploratory indices, thereby providing feedback signals for the search that are both goal-oriented and avoid getting trapped in local optima.

[0055] Furthermore, state distance is used to quantify the current state. Target state profile The gap between them is modeled as the minimum transformation cost required to transform the current state into the target state. To this end, a weighted complete bipartite graph is constructed. Among them, the set of nodes on one side Represents all data entities (database rows or files) in the current state, and the set on the other side. This represents the entities in the target state. All state entities have been standardized to a "table-row" format. For each pair of nodes... and There exists an edge with weight. Indicates the entity Convert to entity The cost. The cost calculation rules are as follows: Entities of the same type: If and If the data belongs to the same table, the transformation cost is the sum of the differences in the corresponding fields. Define a field-level distance function. For numeric types, the value is the absolute difference; for strings, it's the normalized Levenshtein distance; for Boolean / enumerated types, equality is 0 and inequality is 1. Formalized as: .

[0056] Different types of entities: If and If they belong to different tables, they are considered not to be directly convertible and are modeled as deletions. and create Assign a large penalty constant controlled by a hyperparameter. After the graph is constructed, calculate the total weight of the minimum weight perfect matching in the bipartite graph, denoted as: This value represents the cost required to match the current state entity to the target state entity in the "most cost-effective" way. This problem can be solved efficiently in polynomial time using the Hungarian algorithm or minimum-cost maximum flow.

[0057] While state distance is the dominant metric, relying solely on it can easily lead to local optima. To strike a balance between goal-oriented and exploratory approaches, a comprehensive scoring function is used, integrating state-aware metrics with traditional fuzzy testing incentives. The pre-defined comprehensive scoring function includes... , , This is a weighted hyperparameter used to balance the importance of various metrics. State distance reward ( This is a core component, used to reward sequences that bring the current state closer to the target state. It is defined as an exponential function of the previously calculated state distance: ;in, It is a scaling factor. Coverage gain bonus ( The response value range reward is a classic incentive in fuzzing, used to reward the discovery of new code execution paths (such as new basic blocks or edges), thereby promoting a broader exploration of the application's logic space. It encourages the discovery of new internal application states, that is, it rewards sequences that produce previously unobserved values ​​in the response (such as new error codes, unique object / record identifiers).

[0058] Subsequently, the comprehensive score of the candidate request sequence is compared with preset conditions (usually a dynamic threshold or a comparison with the historical best score). If the preset conditions are met, and the state after execution enables the final attack request to be successfully triggered, it is determined that the complete attack chain has been successfully reconstructed, and the corresponding request sequence is taken as the final output.

[0059] It should be noted that after selecting an API, its parameters must be filled with semantically correct values. The state-driven parameter sourcing mechanism transforms this problem from "generating values" to "sourcing values," that is, intelligently extracting values ​​from all accessible states in the system and treating the target state profile as the highest priority data source.

[0060] Specifically, this mechanism relies on a three-tier corpus system, prioritizing value sources based on contextual relevance and target orientation: 1) Local Corpus: consisting of the current sequence ( 1) **Context-sensitive and real-time data:** Parsed from the response body of the executed request. 2) **Target Corpus:** Target state profiles extracted offline. These values ​​are crucial for the success of the final attack and therefore have high priority. 3) **Initial Corpus:** Global static corpus containing general data collected from normal traffic, database snapshots, etc., used as a fallback.

[0061] Furthermore, based on this hierarchical structure, candidate APIs are... Fill a parameter The process is probabilistic. The probability of a particular value being selected is related to its inherent relevance to that parameter and the priority of its source corpus. Regarding the source location... candidate values Its overall score is defined as: ; in, Jaccard similarity in the offline association model reflects the type matching between this parameter and the source; weight function Indicates the priority level of the corpus, and: Instead of greedily selecting the highest-scoring item, a probability sampling strategy is employed when choosing values: the combined scores of all candidate values ​​are normalized into a probability distribution, and then sampling is performed according to this distribution. Specifically, the selected values... The probability is: This "roulette wheel" approach to selection favors high scores while retaining the opportunity to explore other possibilities, thus helping to avoid getting stuck in local optima.

[0062] Optionally, in some embodiments, before determining the shortest path to the target state profile based on a preset guidance model and state distance, the method further includes: constructing an API dependency graph and a parameter source association model; and obtaining a preset data-driven guidance model based on the API dependency graph and the parameter source association model.

[0063] Among them, the API Dependency Graph is used to model the successive probabilities between APIs, thereby overcoming the reliance on rigid semantic assumptions. Addressing the challenge of parameter imputation, the Parameter-Source Correlation Model is used to identify the possible sources of parameter values.

[0064] Understandably, to guide the fuzz tester, two types of data-driven models are built from normal traffic logs and database snapshots: parameter-source association model and API dependency graph.

[0065] Optionally, in some embodiments, constructing a parameter source association model includes: obtaining multiple request parameters and multiple data source locations; collecting historical values ​​of each request parameter to form a first value set, and collecting historical values ​​of each data source location to form a second value set; calculating the Jaccard similarity between the first value set and the second value set, and determining the association score between each request parameter and each data source location based on the Jaccard similarity; sorting the multiple data source locations based on the association score to obtain a data source location list, and determining the parameter source association model based on the data source location list.

[0066] Understandably, accurately populating request parameters is a core challenge in reconstructing attack sequences—many parameter values ​​depend on context and cannot be generated from scratch. To address this, a basic parameter-source association model was built to quantitatively answer: "For a given API request parameter, from which data source and field is its value most likely to come?" First, a unified concept of Data Source Position is defined, referring to any location that can generate or store data. This mainly includes API response fields (such as the email field in the GET / users / {id} response) and database columns (such as the session_token column in the users table). Model construction is carried out in two steps: unified collection of value sets and correlation score calculation.

[0067] Specifically, the unified collection of value sets includes offline analysis of normal traffic logs and database snapshots. For each request parameter... , with each data source location Each value set is formed by collecting all historically observed values. (First value set) and (Second value set).

[0068] Furthermore, the association score calculation includes using Jaccard similarity to measure the parameters. Location of source The strength of the correlation between them, such as Figure 3 As shown, Figure 3 This is a parameter-source correlation diagram illustrating a method for automatically reconstructing the pre-attack sequence of a stateful web attack according to an embodiment of this application; intuitively, high overlap of value sets suggests a possible data flow relationship between them. The correlation score is defined as: ; For any request parameter, the model returns a list of data source locations sorted by score, and the output is a quantified model (parameter source association model), which is the cornerstone of the subsequent state-driven parameter sourcing mechanism and provides key input for building a higher-level API dependency graph.

[0069] Optionally, in some embodiments, constructing an API dependency graph includes: calculating the direct data flow dependencies and indirect data flow dependencies between APIs based on request parameters; performing probability fusion of the direct and indirect data flow dependencies to obtain API succession probabilities, and constructing an API dependency graph based on the API succession probabilities.

[0070] Understandably, for efficient navigation, fuzz testers need to understand the logical succession relationships of API calls. Methods in related technologies often rely on idealized REST semantics, an assumption that is often fragile in real-world applications. To overcome this problem, a purely data-driven API dependency graph was constructed. This graph is a directed weighted graph. :node Represents API endpoints; directed edges express arrive Possible secondary relationships; weights This quantifies the possibility of such secondary dependencies. The core API insight is that dependencies between APIs are primarily manifested through two types of channels—direct data flow (the response of one API becomes the input of another API request) and indirect data flow mediated by backend state. As shown in Figure 4, Figure 4 This is a schematic diagram of API dependencies for a method for automatically reconstructing the sequence of pre-attack steps in a stateful web attack, according to an embodiment of this application; the API dependency graph construction process integrates both types of signals.

[0071] Direct Flow Dependency. This dependency corresponds to a typical "chained call" scenario. It is measured using a parameter-source association model. From... arrive Data stream similarity is defined as: any response field of (u) Any request parameter with (v) Maximum correlation score between them: ; Subsequently, for each The scores are normalized to obtain the transition probability of its direct data stream. .

[0072] Indirect Flow Dependency. This dependency corresponds to an API communicating asynchronously with backend state. Normal traffic is analyzed to obtain the set of state entities written by each API. With the collection of state entities to be read .from arrive The strength of the dependency is defined as the size of the intersection of the two: ; Similarly, normalizing the scores yields the state-based indirect transition probabilities. .

[0073] Probability fusion. Finally, through adjustable hyperparameters. By fusing the two types of signals, the final edge weights, i.e., the overall API successor probability, are obtained: ; By simultaneously modeling the two-layer relationship between direct data flow and state-mediated data flow, we can more accurately characterize the API call succession patterns in the real environment, enabling subsequent goal-oriented fuzz testing to have higher navigability and convergence efficiency.

[0074] To facilitate those skilled in the art to further understand the method for automatically reconstructing the pre-attack sequence of stateful web attacks according to the embodiments of this application, the following is combined with... Figures 5 to 11 The embodiments shown will be described in detail.

[0075] Specifically, the core objective of this application's embodiments is to automatically reconstruct the pre-state construction sequence of a stateful attack, given only the final request. To this end, a target-oriented fuzzing framework has been designed. For example... Figure 5 As shown, Figure 5 This is a schematic diagram of the overall architecture of a method for automatically reconstructing the pre-attack sequence of a stateful web attack, according to one embodiment of this application. The overall architecture consists of two main stages: an offline guidance generation stage and an online goal-oriented fuzzing engine. In the offline stage, the execution trace of the final attack and normal application traffic are analyzed at once to construct three key guidance models, which are used to guide the subsequent online fuzzer.

[0076] The online fuzz tester is driven by an offline-built guided model and uses an iterative loop to continuously generate and mutate request sequences (i.e., seeds) through "Guided Sequence Mutation." This mutation process includes two key stages: multi-heuristic API selection: when selecting the next API to add, this strategy comprehensively considers three factors: the transition probability on the API dependency graph, the path potential to reach the target state, and the immediate satisfiability of the parameters on the selected path, thus making an intelligent selection; state-driven parameter sourcing: this mechanism traces and extracts parameter values ​​from previous responses, target state profiles, and the initial corpus based on the parameter source association model to populate the parameters of the selected API.

[0077] The resulting sequence will be executed in an isolated environment, and its quality will be evaluated by a state-guided seed evaluation module. The core of this evaluation is a novel state distance metric: a bipartite graph is constructed between the current state and the target state, and the minimum weighted matching cost is calculated as the distance. This distance is combined with traditional metrics (such as code coverage) to obtain a composite score, which is then used by a simulated annealing scheduler to update the seed pool.

[0078] Thus, through the closed loop of mutation-execution-evaluation, the gap between the target state and the target state can be systematically narrowed until the complete attack chain is successfully reconstructed.

[0079] Furthermore, let's illustrate the problem of reconstructing a stateful attack using a real-world stateful remote code execution (RCE) vulnerability. This exploit requires two steps: first, a malicious server-side template injection (SSTI) payload is written to a template in the database via a POST request; second, a seemingly harmless GET request to the homepage triggers RCE (Remote Code Execution) when the corrupted template is rendered. If analysts only capture this final, seemingly harmless GET request, the critical challenge is how to reconstruct the preceding request steps used to construct the state.

[0080] This application's targeted design transforms this blind exploration into a guided pathfinding problem, including: constructing a target state profile; firstly, dynamically analyzing the final attack request (GET / index.php). By tracing its system calls, its dependencies on backend data are accurately identified—for example, the database query SELECT * FROM cms_layout_templates WHERE id=10. More importantly, the specific content read from this line is extracted—i.e., the tainted SSTI payload. This "tainted database line" is captured and constitutes the target state profile, thus clarifying the reconstruction target. Secondly, target-oriented sequence generation; this target guides the entire reconstruction process. The API selection strategy prioritizes APIs that can write to the cms_layout_templates table (i.e., interfaces used for editing templates); subsequently, the parameter sourcing mechanism directly traces the required SSTI payload from the target state profile and populates it into the parameters of the preceding request.

[0081] The target-oriented method of this application's embodiments is remarkably effective. In experiments, it not only reconstructs the attack sequence of the CVE in an average of less than three minutes, but also discovers a shorter and better attack path than the publicly available Proof-of-Concept (PoC), demonstrating its ability to efficiently navigate and optimize path discovery in the state space.

[0082] Therefore, this application, for the first time, systematically formalizes the critical security task of reconstructing the attack pre-sequence into an automated, target-oriented fuzzing problem and proposes a complete solution framework. This application designs a precise guidance mechanism centered on state distance. This mechanism automatically constructs a target state profile by analyzing system calls and innovatively employs bipartite graph minimum weight matching to quantify state distance, thereby providing reliable navigation signals for efficient exploration in complex web environments. This application implements a state-driven sequence generation engine. This engine combines a data-driven API dependency graph with an intelligent planning algorithm for efficient API selection; and introduces a novel parameter tracing mechanism that can trace back and extract parameter values ​​from the backend state, thereby reconstructing the attacker's original information flow.

[0083] It should be noted that this application embodiment can also provide a brief overview of the threat model for the method of automatically reconstructing the pre-attack sequence of a stateful web attack. The objective of this application embodiment is to study multi-step, stateful web attacks, where attackers send a series of HTTP requests to alter the persistent backend state of an application (e.g., file system, database), thereby creating preconditions for the final malicious payload request. The task is to automatically reconstruct this pre-attack request sequence given only the final request.

[0084] Specifically, the analysis in this application is based on a post-mortem audit scenario and the following assumptions: Input availability: It is assumed that the analyst possesses the HTTP request that was successfully triggered in the attack chain and can obtain the low-level execution logs generated during the execution of that final request, such as syscall traces. This assumption is consistent with the premise of many intrusion detection and attack investigation efforts. State persistence: The attack types of interest are those whose preceding steps leave observable, persistent artifacts (e.g., writes to the file system or database) on the backend. The success of the final attack request depends on reading the previously manipulated persistent state. Trusted environment: It is assumed that the environment is trustworthy, and the operating system provides reliable audit logs; the logging mechanism itself, as well as the normal traffic logs used for modeling, all belong to a Trusted Computing Base (TCB), a common standard assumption in log-based analysis. Scope of application: Focuses on reconstructing attack sequences that initiate and modify persistent backend states through external HTTP requests. The following scenarios are outside the scope of this work: attacks involving only transient states (e.g., in-memory states), non-application layer exploits (e.g., exploits of underlying network or hardware vulnerabilities), attacks not aimed at modifying backend state (e.g., denial-of-service attacks, side-channel attacks), and insider threats. This scope definition is consistent with existing research on stateful Web security analysis. Therefore, this application implements a prototype with over 9000 lines of code (Python). This implementation is a self-consistent framework designed to address two key engineering challenges: ensuring a scalable, isolated test execution environment, and handling the dynamic nature of modern web applications.

[0085] Scalable and isolated execution environment: To ensure state isolation and support high-throughput testing, a pool of pre-warmed Docker containers is utilized. Each candidate sequence is executed in an independent, clean container instance, which is then destroyed after execution. This model ensures that each test starts from a pure initial state, thus avoiding interference between tests. Handling dynamic application state: To address the issue of volatile values ​​such as session IDs and CSRF tokens, a symbolic reference mechanism is employed. The framework stores placeholders (e.g., ...) in the sequence.<req1.response.body.csrf_token> Instead of specific values, the runtime agent is responsible for extracting and parsing the correct, up-to-date values ​​from the current execution context during replay, ensuring sequence replayability and robustness. Automated attack verification and determination unit: To automatically confirm whether reconstruction was successful, the system uses the state produced after executing the candidate sequence as context to run the final attack request. It is verified using predefined indicators (e.g., the appearance of a specific string like uid=0 (root) in the final response, or a anticipated malicious change in the backend status such as uploading a webshell). This determiner can reliably identify when the target state is reached and complete the attack reconstruction.

[0086] Furthermore, embodiments of this application can also be used to experimentally verify the method for automatically reconstructing the sequence of pre-attack steps in a stateful web attack.

[0087] Specifically, to evaluate in real-world scenarios, a benchmark suite containing 13 vulnerabilities was constructed, as shown in Table 1, which details the benchmark suite and its complexity metrics. Eleven of these are publicly disclosed, high-impact CVEs / CNVDs, originating from commonly used open-source web applications. These vulnerabilities were selected based on two criteria: 1) they are stateful and require a multi-step sequence to exploit; 2) they can be reproduced in a stable Docker environment—many of which are adapted from the Vulhub project. To further test generalization capabilities and facilitate direct comparison with related work, three multi-step attack scenarios from the original MINER and VOAPI papers were also included. Table 1 lists the complexity metrics for each benchmark (including the number of APIs, the number of parameters, and the type of corpus used for parameter attribution).

[0088] Table 1

[0089] Baseline Comparison: The embodiments of this application are compared with two advanced web application fuzzers: PREDATOR (a targeted fuzzer for PHP applications) and MINER (a sequence generation fuzzer for RESTful APIs). For reproducibility and engineering practice reasons, several related works were not included in the comparison: NAUTILUS requires extensive manual annotation; despite multiple attempts and communication with the authors, VOAPI could not be reproduced; ATROS deployment relies on VM kernel modules, making configuration complex; the source code for WDFUZZ is unavailable and therefore cannot be reproduced. All experiments were run in isolated, post-use reset Docker container groups, with test servers equipped with AMD Ryzen 9 7950X (16 cores) processors and 32GB of memory.

[0090] Furthermore, the evaluation in this application uses success rate, path length, and time-to-vulnerability (TTV) as metrics to measure effectiveness and efficiency, and directly compares them with baseline tools. On the benchmark suite, a 100% success rate was achieved, successfully reconstructing all 13 stateful attack sequences, as shown in Tables 2 and 3. Table 2 compares effectiveness and efficiency (Time-to-Vulnerability), and Table 3 compares performance under previous benchmarks.

[0091] Table 2

[0092] Table 3

[0093] Furthermore, all reconstructions were completed within 20 minutes. Notably, in 5 out of 13 use cases, shorter attack paths than those documented in publicly available literature were discovered. For example, for a GitLab vulnerability, it compressed the original UI-based 6-step workflow into a direct 2-step API attack (see Table 3). Details of all optimized paths are shown below, revealing more efficient attack paths than those documented in relevant technologies in five benchmark use cases. This indicates that the method can identify the minimum request sequence required to reach a vulnerable state, often by bypassing steps that are oriented towards manual processes but are not essential to the backend logic, thus achieving path compression.

[0094] A comparison was made with PREDATOR and MINER, which were "enhanced" (provided with all the necessary complex attack payloads). As shown in Table 2, these blind-oriented tools perform poorly when dealing with sequence complexity: MINER can only solve the two simplest two-step attacks, while PREDATOR fails in its applicable multi-step scenarios. Neither can reconstruct any attacks involving three or more steps and cannot effectively handle data dependencies between requests.

[0095] For benchmarks from previous work (Table 3), comparing the TTV with the values ​​reported in the original paper, all three vulnerabilities were successfully reproduced. Although the TTV was longer on the two VOAPI benchmarks, this was mainly due to the experimental methodology: to ensure the verifiability of the reconstruction results, the runtime environment was forcibly reset before each execution (for heavyweight applications such as GitLab, each reset takes approximately 85 seconds), an overhead that increases the overall execution time. This design trade-off resulted in stricter reproducibility and enabled the discovery of better two-step attack paths.

[0096] Furthermore, to quantitatively assess the contribution of each core component, ablation experiments were conducted in this application embodiment. Three downgraded versions were constructed, disabling one key mechanism each time and reverting to a simpler, more traditional baseline strategy: NoDist: replacing the state distance metric used for seed evaluation with traditional fuzzing feedback (i.e., using only code coverage and new value range discovery). NoSelect: replacing multi-heuristic API selection with uniform random selection from all available APIs. NoSource: replacing priority-driven state parameter sourcing with random sampling from the initial corpus without priority weights. On three representative vulnerabilities, the above three variants were compared with the full version with a 6-hour timeout limit. As... Figure 6 As shown, Figure 6 This is a schematic diagram of ablation experiment results for a method for automatically reconstructing the pre-attack sequence of a stateful web attack according to an embodiment of this application. The full version significantly outperforms all downgraded variants in all cases.

[0097] Removing state distance feedback: The fuzzer becomes almost completely target-blind. TTV increases significantly across all benchmarks, with performance degradation ranging from 3.2x (CVE-2016-9086) to 14.3x (CVE-2023-5002). Removing heuristic API selection: Search efficiency drops drastically due to fallback to random exploration. This version is 3.8x to 6.4x slower than the full version, demonstrating the critical importance of API selection strategy. Removing state-driven parameter sourcing: The impact is most severe. Due to the inability to generate semantically correct requests, this version times out directly in two of the three benchmarks, with a performance degradation of over 123x (6183.5 seconds vs. 50.4 seconds) on CVE-2016-9086.

[0098] In summary, the ablation experiments clearly demonstrate that the three core designs—state distance guidance, multi-heuristic API selection, and state-driven parameter tracing—are all indispensable and work together to support efficient attack sequence reconstruction capabilities.

[0099] Further, a case study on long-chain attacks uses the complex YApi unauthorized remote code execution (RCE) vulnerability as an example. This vulnerability requires chaining user registration, project creation, and script injection to illustrate a guided search process. The public Proof-of-Concept (PoC) requires 8 steps to complete the exploit, while experiments consistently revealed shorter paths (average 6 steps, shortest 5 steps), with an average reconstruction time of 234.4 seconds. This optimization comes from identifying and bypassing redundant requests; for example, certain unnecessary login calls are determined to be omnipotent—because the registration process automatically completes the login. Figure 7 As shown, Figure 7 This diagram illustrates the four key final steps of YApi RCE, a method for automatically reconstructing the pre-attack sequence of a stateful web attack, according to an embodiment of this application. It shows the four final key steps and their data dependencies.

[0100] Furthermore, to present a more granular process, this application embodiment also analyzes a representative run that found a 5-step path (including a 4-step prerequisite sequence) within 160 seconds. For example... Figure 8 As shown, Figure 8This is a timeline diagram illustrating the operation of a method for automatically reconstructing the pre-attack sequence of a stateful web attack according to an embodiment of this application, showing a 160-second timeline (reconstructing a YAPI attack). Each point marks the time when a key state construction request was successfully inserted into the sequence, indicating the moment when the embodiment of this application successfully constructed a valid prefix for the final attack sequence. The process is not linear but rather presents a pattern of alternating exploration phases for rapid breakthroughs. For example, the initial 43 seconds are primarily for exploration, followed by the construction of the first POST / api / user / reg request. Subsequently, at 76 seconds and 80 seconds, POST / api / project / add and POST / api / plugin / advmock / save are discovered relatively quickly, because the state space is rapidly narrowed as the acquired state information is constrained and guided.

[0101] This guided convergence is driven by a state distance metric, such as... Figure 9 As shown, Figure 9 This diagram illustrates the evolution of seed scores during the YApi reconstruction process of a method for automatically reconstructing the pre-attack sequence of a stateful web attack, according to an embodiment of this application. Each point represents a newly generated candidate sequence, and the distinct phased transitions demonstrate a guided convergence process towards the target state, with scores reflecting the degree of proximity to the target state. The dark purple curve depicts the "best to date" score, which only increases when a better sequence is discovered. The graph exhibits a step-like upward pattern: each score transition corresponds to a key breakthrough in the attack chain. For example, creating the necessary user entity causes the best score to jump from the baseline of 0.8 to 3.9; subsequent item creation and script injection bring significant jumps to 9.1 and finally 10.9, respectively, marking the discovery of the complete pre-attack sequence.

[0102] Therefore, to illustrate the synergistic effect of the various guidance mechanisms, this application embodiment breaks down a key mutation step in detail. This step occurs after a user is successfully created via POST / api / user / reg, pushing the best score to date to 3.9. Goal-oriented heuristics ( The system determines that creating a project is a critical prerequisite, thus driving the selection mechanism to rank the correct API POST ` / api / project / add` as the 3rd candidate out of 18, with an allocation probability of 8.3%. Once the API is selected, the parameter sourcing mechanism is triggered to populate the API. The mechanism accurately traces the source of this value to the basepath field of the project table in the target state profile and assigns it the highest probability (40.4%). The successful execution of this guiding request boosted the best score to date from 3.9 to 9.1, prompting the scheduler to prioritize this sequence and quickly guide the search toward the complete solution.

[0103] To verify robustness, embodiments of this application also evaluated the sensitivity to key hyperparameters. The analysis focused on the heuristic weighting parameters used in API selection. ) and API dependency graph fusion factor .

[0104] Specifically, such as Figure 10 As shown, Figure 10 This diagram illustrates the results of heuristic weight changes in a method for automatically reconstructing the pre-attack sequence of a stateful web attack, according to an embodiment of this application. Each sub-diagram shows the TTV (Total Television Value) trend when changing the other two weights while keeping one weight constant, thus demonstrating the relative importance of each heuristic. The embodiment of this application demonstrates good robustness, successfully discovering vulnerabilities in all tests. Although the goal-oriented heuristic... ,Depend on The weighted average has the greatest impact—increasing its weight usually reduces TTV—but over-reliance on any single heuristic leads to performance degradation, highlighting the necessity of a balancing strategy. More importantly, the fluctuations in these TTVs are only on the order of minutes, significantly smaller than the multi-order-of-magnitude differences observed in ablation experiments, demonstrating that the embodiments of this application are not highly sensitive to these weighting parameters.

[0105] Furthermore, embodiments of this application also analyze the fusion factor. Used to balance data stream signals ( ) and status change signals As shown in Figure 11, Figure 11 Fusion hyperparameters for a method of automatically reconstructing the pre-attack sequence of a stateful web attack, as described in one embodiment of this application. A diagram illustrating the impact on TTV. Used to balance data stream probabilities ( ) and state change probability ( The results show that when the two types of signals are integrated together (e.g., ), with the best performance; while the fusion strategy ( The performance of the method consistently outperforms that relying solely on a single signal, but continues to be poor. This verifies the correctness of the complementary dependent signal fusion design. Performance fluctuations are very small within this optimal range, further highlighting the stability of the embodiments of this application. Furthermore, the embodiments of this application also observed that other more standard hyperparameters (such as the decay rate in the transfer heuristic, seed score combination weights, etc.) have extremely weak impacts on performance; therefore, standard default values ​​were used in the evaluation.

[0106] Therefore, this application proposes a novel framework for automatically reconstructing the sequence of pre-attack steps in stateful Web attacks. By formalizing the attack reproduction problem as a target-oriented fuzzing task, it systematically overcomes the inherent limitations of traditional methods. Its core innovations include: a method for constructing a target state profile based on system call analysis; a state distance navigation system based on minimum weight binary matching; and a sequence generation engine supported by a data-driven API dependency graph and a state-driven parameter tracing mechanism. These technologies enable reverse reasoning from the "effect" of the final attack, thereby efficiently discovering its "cause." In benchmark tests containing 13 real vulnerabilities, experimental results show that it significantly outperforms existing methods in both success rate and efficiency, stably reconstructing complex attack chains up to 8 steps long, and discovering attack chains superior to publicly available paths in 5 of the test cases. This provides an effective solution to the critical security requirement of automated attack reproduction and opens up new research directions for state-aware Web security analysis.

[0107] The method for automatically reconstructing the pre-attack sequence of stateful web attacks proposed in this application involves constructing a target state profile based on the received final attack request, and calculating the state distance between the current application state and the target state based on the target state profile. The shortest path to the target state profile is determined based on a preset data-driven guidance model and the state distance, and a candidate request sequence is generated using a preset execution sequence generation engine based on the shortest path. A comprehensive scoring function is used to evaluate the difference between the backend state after executing the candidate request sequence and the target state profile, obtaining a comprehensive score for the candidate request sequence. When the comprehensive score meets preset conditions, the candidate request sequence is used as the request sequence corresponding to the comprehensive score. This solves the problems of difficult automated reconstruction of stateful web attack sequences, low efficiency of multi-step vulnerability verification, and reliance on manual attack investigation.

[0108] Next, referring to the accompanying drawings, an apparatus for automatically reconstructing the sequence of pre-attack steps for a stateful web attack, according to an embodiment of this application, is described.

[0109] Figure 12 This is a block diagram of an apparatus for automatically reconstructing the sequence of pre-attack steps in a stateful web attack, according to an embodiment of this application.

[0110] like Figure 12 As shown, the apparatus 1000 for automatically reconstructing the sequence of pre-attack steps of a stateful web attack includes: a receiving module 100, a calculation module 200, a generation module 300, and an evaluation module 400.

[0111] The system includes: a receiving module 100 for receiving the final attack request; a calculation module 200 for constructing a target state profile based on the final attack request and calculating the state distance between the current application state and the target state based on the target state profile; a generation module 300 for determining the shortest path of the target state profile based on a preset data-driven guidance model and the state distance, and generating a candidate request sequence based on the shortest path using a preset execution sequence generation engine; and an evaluation module 400 for evaluating the difference between the backend state after executing the candidate request sequence and the target state profile based on a preset comprehensive scoring function, obtaining a comprehensive score for the candidate request sequence, and using the candidate request sequence as the request sequence corresponding to the comprehensive score when the comprehensive score meets preset conditions.

[0112] Optionally, the computing module 200 is specifically used to: inject lightweight probes into key lifecycle points of the target web application framework; based on the lightweight probes, isolate the complete call sequence of the final attack request; extract file dependencies and database dependencies from the complete call sequence; and normalize the file dependencies and database dependencies into a tabular representation to form a target state profile.

[0113] Optionally, before determining the shortest path to the target state profile based on the preset guidance model and state distance, the generation module 300 is also used to: construct an API dependency graph and a parameter source association model; and obtain a preset data-driven guidance model based on the API dependency graph and the parameter source association model.

[0114] Optionally, the generation module 300 is specifically used for: obtaining multiple request parameters and multiple data source locations; collecting historical values ​​of each request parameter to form a first value set, and collecting historical values ​​of each data source location to form a second value set; calculating the Jaccard similarity between the first value set and the second value set, and determining the association score between each request parameter and each data source location based on the Jaccard similarity; sorting the multiple data source locations based on the association score to obtain a list of data source locations, and determining the parameter source association model based on the list of data source locations.

[0115] Optionally, the generation module 300 is specifically used to: calculate the direct data flow dependencies and indirect data flow dependencies between APIs based on the request parameters; perform probability fusion of the direct data flow dependencies and indirect data flow dependencies to obtain the API follow-up probabilities, and construct an API dependency graph based on the API follow-up probabilities.

[0116] Optionally, the preset comprehensive scoring function is: ; in, The overall score for the candidate request sequence. for The weight parameters, As a state distance reward, for The weight parameters, To cover the bonus rewards, for The weight parameters, Rewards are given for responses within a certain range.

[0117] It should be noted that the foregoing explanation of the method embodiment for automatically reconstructing the pre-step sequence of a stateful web attack also applies to the apparatus for automatically reconstructing the pre-step sequence of a stateful web attack in this embodiment, and will not be repeated here.

[0118] According to the apparatus for automatically reconstructing the pre-attack sequence of a stateful web attack proposed in this application, the apparatus constructs a target state profile based on the received final attack request, and calculates the state distance between the current application state and the target state based on the target state profile; determines the shortest path of the target state profile based on a preset data-driven guidance model and the state distance, and generates a candidate request sequence based on the shortest path using a preset execution sequence generation engine; evaluates the difference between the backend state after executing the candidate request sequence and the target state profile based on a preset comprehensive scoring function, and obtains a comprehensive score for the candidate request sequence; when the comprehensive score meets a preset condition, the candidate request sequence is used as the request sequence corresponding to the comprehensive score. This solves the problems of difficulty in automatically reconstructing stateful web attack sequences, low efficiency of multi-step vulnerability verification, and reliance on manual attack investigation.

[0119] Figure 13 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: The memory 1301, the processor 1302, and the computer program stored on the memory 1301 and executable on the processor 1302.

[0120] When the processor 1302 executes the program, it implements the method for automatically reconstructing the pre-attack sequence of stateful web attacks provided in the above embodiments.

[0121] Furthermore, electronic devices also include: Communication interface 1303 is used for communication between memory 1301 and processor 1302.

[0122] The memory 1301 is used to store computer programs that can run on the processor 1302.

[0123] The memory 1301 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage.

[0124] If the memory 1301, processor 1302, and communication interface 1303 are implemented independently, then the communication interface 1303, memory 1301, and processor 1302 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 13 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0125] Optionally, in a specific implementation, if the memory 1301, processor 1302, and communication interface 1303 are integrated on a single chip, then the memory 1301, processor 1302, and communication interface 1303 can communicate with each other through an internal interface.

[0126] The processor 1302 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0127] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for automatically reconstructing a sequence of pre-attack steps for a stateful web attack.

[0128] This application also provides a computer program product that stores a computer program that, when executed by a processor, implements the above-described method for automatically reconstructing a sequence of pre-attack steps for a stateful web attack.

[0129] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

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

[0131] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0132] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0133] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

Claims

1. A method for automatically reconstructing the sequence of pre-attack steps in a stateful Web attack, characterized in that, Includes the following steps: Receive the final attack request; Based on the final attack request, a target state profile is constructed, and based on the target state profile, the state distance between the current application state and the target state is calculated. The shortest path to the target state profile is determined based on a preset data-driven guidance model and the state distance, and a candidate request sequence is generated based on the shortest path using a preset running sequence generation engine. Based on a preset comprehensive scoring function, the difference between the backend state after executing the candidate request sequence and the target state profile is evaluated to obtain a comprehensive score for the candidate request sequence. When the comprehensive score meets a preset condition, the candidate request sequence is taken as the request sequence corresponding to the comprehensive score.

2. The method according to claim 1, characterized in that, The construction of the target state profile based on the final attack request includes: A lightweight probe is injected into a critical lifecycle point of the target web application framework, and based on the lightweight probe, the complete call sequence of the final attack request is isolated. File dependencies and database dependencies are extracted from the complete call sequence, and the file dependencies and database dependencies are normalized into a tabular representation to form the target state profile.

3. The method according to claim 1, characterized in that, Before determining the shortest path to the target state profile based on the preset guidance model and the state distance, the following steps are also included: Construct an API dependency graph and a parameter source association model; The preset data-driven guidance model is obtained based on the API dependency graph and the parameter source association model.

4. The method according to claim 3, characterized in that, The construction parameters are derived from the associated model, including: Retrieve multiple request parameters and multiple data source locations; The historical values ​​of each of the request parameters are collected to form a first value set, and the historical values ​​of each of the data source locations are collected to form a second value set; Calculate the Jaccard similarity between the first set of values ​​and the second set of values, and determine the association score between each request parameter and each data source location based on the Jaccard similarity; Based on the association score, the multiple data source locations are sorted to obtain a list of data source locations, and the parameter source association model is determined based on the list of data source locations.

5. The method according to claim 3, characterized in that, The construction of the API dependency graph includes: Based on the request parameters, calculate the direct data flow dependencies and indirect data flow dependencies between APIs; The direct data flow dependency and the indirect data flow dependency are probabilistically fused to obtain the API succession probability, and the API dependency graph is constructed based on the API succession probability.

6. The method according to claim 1, characterized in that, The preset comprehensive scoring function is: ； in, The overall score for the candidate request sequence. for The weight parameters, As a state distance reward, for The weight parameters, To cover the bonus rewards, for The weight parameters, Rewards are given for response value ranges.

7. An apparatus for automatically reconstructing the sequence of pre-attack steps in a stateful Web attack, characterized in that, include: The receiving module is used to receive the final attack request; The calculation module is used to construct a target state profile based on the final attack request, and to calculate the state distance between the current application state and the target state based on the target state profile. The generation module is used to determine the shortest path of the target state profile based on the preset data-driven guidance model and the state distance, and to generate a candidate request sequence based on the shortest path using a preset running sequence generation engine. The evaluation module is used to evaluate the difference between the backend state after executing the candidate request sequence and the target state profile based on a preset comprehensive scoring function, and obtain a comprehensive score for the candidate request sequence. When the comprehensive score meets a preset condition, the candidate request sequence is used as the request sequence corresponding to the comprehensive score.

8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the method for automatically reconstructing a sequence of pre-attack steps for a stateful web attack as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by a processor to implement the method for automatically reconstructing the sequence of pre-attack steps for a stateful web attack as described in any one of claims 1-6.

10. A computer program product, said computer program product storing a computer program, characterized in that, When executed by a processor, the program implements the method for automatically reconstructing the sequence of pre-attack steps for a stateful web attack as described in any one of claims 1-6.

Images