Attack verification method, device, equipment, readable storage medium and program product

Abstract

The present disclosure relates to an attack verification method, device, equipment, readable storage medium and program product, which comprises the following steps: obtaining a first digital twin of an application client and an attack script, running the attack script in the first digital twin of the first application client, and obtaining an execution stack and a DOM snapshot of the first digital twin when running the attack script. The execution stack and the DOM snapshot of the first digital twin when running the attack script can accurately verify the influence of the attack implemented by the attack script on the application client, thereby providing a basis for timely discovering and eliminating security vulnerabilities.

Description

Technical Field

[0001] This disclosure relates to the field of cybersecurity technology, and in particular to an attack verification method, apparatus, device, readable storage medium, and program product. Background Technology

[0002] With the widespread adoption of application clients, a large amount of business and user data interaction relies on these clients, making them a prime target for cyberattacks. Cyberattacks can trigger security risks and user trust crises. Conducting cyberattack verification can validate the impact of cyberattacks on application clients, providing a basis for timely detection and mitigation of security vulnerabilities. Therefore, how to verify the impact of cyberattacks on application clients is a technical problem that needs to be solved. Summary of the Invention

[0003] Therefore, it is necessary to provide an attack verification method, apparatus, device, readable storage medium, and program product that can verify the impact of network attacks on application clients in response to the above-mentioned technical problems.

[0004] In a first aspect, this disclosure provides an attack verification method, comprising: obtaining a first digital twin of an application client and an attack script; running the attack script in the first digital twin and obtaining the execution stack and a Document Object Model (DOM) snapshot of the first digital twin when running the attack script; and determining the impact of the attack implemented by the attack script on the first digital twin based on the execution stack and the DOM snapshot.

[0005] In some implementations, obtaining the first digital twin of the application client includes: obtaining data from the application client, the data including at least one of the following: DOM structure, code execution environment, user interaction data, and data traffic; and generating the first digital twin of the application client based on the data from the application client.

[0006] In some implementations, the attack script is used to describe the sequence of user behavior during the attack, the triggering conditions of the attack, the injection point, and the expected data flow of the attack.

[0007] In some implementations, determining the impact of the attack script's attack on the first digital twin based on the execution stack and the DOM snapshot includes: determining at least one of the following based on the execution stack: the injection point of the attack, the execution path, the sensitive data accessed, and the functions to be tampered with; determining the DOM elements affected by the attack based on the DOM snapshot; and using the at least one piece of information and the DOM elements as the impact of the attack on the first digital twin.

[0008] In some implementations, the method further includes: if, based on the impact of the attack on the first digital twin, it is determined that the application client has a security vulnerability, obtaining a context snapshot of the first digital twin during the execution of the attack script; inputting the context snapshot into a preset model, generating vulnerability remediation suggestions through the preset model; and remediating the vulnerability in the first digital twin based on the vulnerability remediation suggestions to obtain a second digital twin.

[0009] In some implementations, the context snapshot includes at least one of the following: the DOM structure of the first digital twin during the execution of the attack script, the execution stack, the state of the task queue, the attack script, and the execution path of the attack.

[0010] In some embodiments, the method further includes: running the attack script on the second digital twin and determining the impact of the attack implemented by the attack script on the second digital twin; and determining whether the security vulnerability has been patched based on the impact of the attack on the second digital twin.

[0011] In some embodiments, the method further includes: obtaining a script for a preset operation and a first function to be implemented by the preset operation target; running the script for the preset operation on the second digital twin and determining a second function implemented by the preset operation on the second digital twin; and determining the impact of the vulnerability fix on the functionality of the application client based on the first function and the second function.

[0012] In some implementations, the method further includes: obtaining a first performance parameter of the first digital twin and a second performance parameter of the second digital twin; and determining the impact of the vulnerability fix on the performance overhead of the application client based on the first performance parameter and the second performance parameter.

[0013] Secondly, this disclosure provides an attack verification device, comprising:

[0014] The first acquisition module is used to acquire the first digital twin of the application client, as well as the attack script.

[0015] The second acquisition module is used to run the attack script in the first digital twin and acquire the execution stack and document object model (DOM) snapshot of the first digital twin when running the attack script.

[0016] The first determining module is used to determine the impact of the attack implemented by the attack script on the first digital twin based on the execution stack and the DOM snapshot.

[0017] In some implementations, a first acquisition module is used to acquire data from the application client, the data including at least one of the following: DOM structure, code execution environment, user interaction data, and data traffic; and based on the data from the application client, to generate a first digital twin of the application client.

[0018] In some implementations, the attack script is used to describe the sequence of user behavior during the attack, the triggering conditions of the attack, the injection point, and the expected data flow of the attack.

[0019] In some implementations, a first determining module is configured to determine, based on the execution stack, at least one of the following: the injection point of the attack, the execution path, the sensitive data accessed, and the functions to be tampered with; determine the DOM elements affected by the attack based on the DOM snapshot; and use the at least one piece of information and the DOM elements as the impact of the attack on the first digital twin.

[0020] In some implementations, the attack verification device may further include:

[0021] The third acquisition module is used to acquire a context snapshot of the first digital twin when the attack script is running, if it is determined that the application client has a security vulnerability based on the impact of the attack on the first digital twin.

[0022] The generation module is used to input the context snapshot into a preset model and generate vulnerability remediation suggestions through the preset model.

[0023] The repair module is used to repair vulnerabilities in the first digital twin based on the vulnerability repair suggestions, so as to obtain a second digital twin.

[0024] In some implementations, the context snapshot includes at least one of the following: the DOM structure of the first digital twin during the execution of the attack script, the execution stack, the state of the task queue, the attack script, and the execution path of the attack.

[0025] In some implementations, the attack verification device may further include:

[0026] The second determining module is used to run the attack script on the second digital twin and determine the impact of the attack script on the second digital twin.

[0027] The third determining module is used to determine whether the security vulnerability has been patched based on the impact of the attack on the second digital twin.

[0028] In some implementations, the attack verification device may further include:

[0029] The fourth acquisition module is used to acquire the script of the preset operation and the first function implemented by the preset operation target.

[0030] The fourth determining module is used to run the script of the preset operation on the second digital twin and determine the second function implemented by the preset operation on the second digital twin.

[0031] The fifth determining module is used to determine the impact of the vulnerability fix on the functionality of the application client based on the first function and the second function.

[0032] In some implementations, the attack verification device may further include:

[0033] The fifth acquisition module is used to acquire the first performance parameters of the first digital twin and the second performance parameters of the second digital twin.

[0034] The sixth determining module is used to determine the impact of the vulnerability fix on the performance overhead of the application client based on the first performance parameter and the second performance parameter.

[0035] Thirdly, this disclosure also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method of any of the embodiments in the first aspect described above.

[0036] Fourthly, this disclosure also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any of the embodiments in the first aspect described above.

[0037] Fifthly, this disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the method of any of the embodiments in the first aspect described above.

[0038] The attack verification method, apparatus, device, readable storage medium, and program product disclosed herein obtain a first digital twin of an application client and an attack script, run the attack script in the first digital twin of the first application client, and obtain the execution stack and DOM snapshot of the first digital twin when running the attack script. By using the execution stack and DOM snapshot of the first digital twin when running the attack script, the impact of the attack script on the application client can be accurately verified, thereby providing a basis for timely discovery and elimination of security vulnerabilities. Attached Figure Description

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

[0040] Figure 1 This is a flowchart of an attack verification method provided in an embodiment of this disclosure;

[0041] Figure 2 This is a flowchart of a method for obtaining a digital twin of an application client according to an embodiment of this disclosure;

[0042] Figure 3 This is a flowchart of a security vulnerability remediation method provided in an embodiment of this disclosure;

[0043] Figure 4 This is a schematic diagram of a system architecture provided in an embodiment of this disclosure;

[0044] Figure 5 This is a schematic diagram of the structure of a device provided in an embodiment of this disclosure;

[0045] Figure 6 This is a schematic diagram illustrating the execution process of an application example of the attack verification method provided in this disclosure embodiment;

[0046] Figure 7 This is a schematic diagram illustrating the execution process of another application example of the attack verification method provided in this disclosure embodiment;

[0047] Figure 8 This is a schematic diagram of the structure of an attack verification device provided in an embodiment of this disclosure;

[0048] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this disclosure.

[0050] It should be noted that the terms "first," "second," etc., used in this disclosure may be used to describe various elements, but these elements are not limited by these terms. These terms are used only to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this disclosure, are intended to cover non-exclusive inclusion. The term "a plurality of" used in this disclosure refers to two or more. The term "and / or" used in this disclosure refers to one of the embodiments, or any combination of multiple embodiments.

[0051] Figure 1 This is a flowchart illustrating an attack verification method provided in an embodiment of this disclosure. The method can be executed by a computer device, as exemplarily. This computer device can be understood as any device with computing and processing capabilities, such as a personal computer, laptop computer, tablet computer, server, distributed computing node, etc., but is not limited to the devices listed herein. Figure 1 As shown, in some examples, the attack verification method provided in this disclosure embodiment may include the following steps.

[0052] In step S101, the first digital twin of the application client and the attack script are obtained.

[0053] The use of "first" in the designation of the first digital twin is solely for distinguishing different digital twins and has no other meaning.

[0054] The first digital twin of an application client can be understood as a real-time mapped virtual image of the application client built in digital space. The first digital twin can reflect the display and running status of the application client in real time and comprehensively.

[0055] In some implementations, the first digital twin can be constructed based on data from the application client. For example, Figure 2 This is a flowchart illustrating a method for obtaining a digital twin of an application client, as provided in an embodiment of this disclosure. Figure 2 As shown, in some implementations, the first digital twin of the application client can be obtained by the following method.

[0056] In step S201, data from the application client is obtained, including at least one of the following: DOM structure, code execution environment, user interaction data, and data traffic.

[0057] The DOM structure referred to in this disclosure may include a real DOM structure and a virtual DOM structure.

[0058] The code execution environment can be a JavaScript execution environment, a C language code execution environment, etc., but it is not limited to JavaScript execution environment and C language code execution environment.

[0059] User interaction data includes, but is not limited to, user actions on the application interface (such as input, clicks, scrolling, dragging, etc.) and the order of these actions.

[0060] Data traffic can include, but is not limited to, data generated on the application client (such as data content, data type, etc.) and data flow direction.

[0061] In some examples, lightweight, non-intrusive Hook injection techniques (e.g., via browser extensions or proxies) can be used to deeply intercept API calls to the DOM (such as document.createElement, element.appendChild, element.innerHTML, etc.) and updates to the virtual DOM during application client runtime. By capturing every dynamic change in the application client's render tree and DOM structure through Hook injection, the application client's DOM structure can be obtained.

[0062] Obtaining the DOM structure of the application client through Hook injection technology can solve the problem of tracking virtual DOM updates, which is difficult with related technologies. By using the DOM structure obtained through Hook injection when generating the first digital twin of the application client, it is beneficial to ensure the consistency between the DOM structure of the first digital twin and the DOM structure of the application client, so that the first digital twin can achieve a consistent rendering state with the application client.

[0063] In other examples, a proxy mechanism can be used to capture data from the code's runtime environment. Take the JavaScript execution environment as an example. JavaScript's proxy and reflection mechanisms can be used to intercept and wrap global objects on the application client (such as window, document, fetch, XMLHttpRequest) and the application client's runtime environment to capture data such as function calls, variable state changes, event listener registration / triggers, and the sending and receiving of network requests. This data can be recorded and used to build the application client's JavaScript execution environment. It is crucial to ensure that the JavaScript code execution logic in the first digital twin is completely consistent with the real application client, including its impact on local storage, session management, etc.

[0064] In other examples, by monitoring asynchronous events and event queues such as Promise, setTimeout, and addEventListener, accurate modeling of complex user interaction events and data traffic can be achieved, yielding user interaction data and data traffic from the application client. Simultaneously, time series alignment and asynchronous state consistency guarantee mechanisms are employed to ensure that the first digital twin can accurately reproduce the temporal logic under multi-user interaction and multi-threaded operations (such as Web Workers), and to capture asynchronous attack behaviors (such as cross-time point data flow pollution in DOM-based XSS). The asynchronous state consistency guarantee mechanism refers to the technical mechanism used to maintain the synchronization of business states among multiple parties and avoid state divergences in asynchronous interaction scenarios. Its specific implementation can be set as needed, and this disclosure does not impose specific limitations.

[0065] In step S203, a first digital twin of the application client is generated based on the acquired application client data.

[0066] The method for generating the first digital twin based on data from the application client can be found in the related technologies on digital twin generation methods, and will not be elaborated here.

[0067] exist Figure 2 In this embodiment, by using technologies such as Hook injection and Proxy mechanism, it is possible to accurately capture the data of the application client (such as real DOM structure, virtual DOM structure, code execution environment, user interaction data, data traffic) and its dynamic changes, so as to achieve deep state binding between the digital twin and the real application client.

[0068] In some implementations, the attack script referred to in this disclosure can be understood as a client-side attack path description language (CAP-DL). This CAP-DL can be used to describe the sequence of user behaviors during an attack (such as input, click, scrolling, dragging), the triggering conditions of the attack (such as waiting for the appearance of a specific element in the display interface), the injection point of the attack, the expected data flow of the attack, and the content or code of the attack.

[0069] In some examples, this disclosure may provide a CAP-DL interpreter through which users can define attack scripts corresponding to different attacks. By running the attack scripts on a first digital twin of the application client, the attacks defined in the attack scripts can be simulated and reproduced. This transforms attack simulation from simple payload injection into the simulation of complex attack scenarios that are reproducible, traceable, and structured for analysis.

[0070] In step S103, the attack script is run in the first digital twin, and the execution stack and DOM snapshot of the first digital twin when running the attack script are obtained.

[0071] In some examples, an independent script execution sandbox can be built within the first digital twin to load and run the attack script. At predetermined data collection points during the attack script's execution, information from the execution stack can be obtained by constructing an Error object. A DOM snapshot can be generated by cloning the Document Object Model. By associating the execution stack and DOM snapshot collected at the same time, the attack's runtime status data can be retained. Of course, this is merely an example illustrating the methods for obtaining the execution stack and DOM snapshot during the attack script's runtime, and not the only possible approach.

[0072] In step S105, based on the execution stack and DOM snapshot of the first digital twin when it runs the attack script, the impact of the attack script on the first digital twin is determined.

[0073] In this initial embodiment, the execution stack records the call chain of the attack script, and the DOM snapshot records the user interface changes. Based on the execution stack, the injection point, execution path, accessed sensitive data (such as cookies and LocalStorage), and information about the functions tampered with by the attack script can be determined. By comparing the DOM snapshot at the time of the attack with a DOM snapshot before or before the attack, the DOM elements affected by the attack can be identified. The information determined based on the execution stack (such as at least one of the injection point, execution path, accessed sensitive data, and tampered functions), and the DOM elements affected by the attack identified based on the DOM snapshot, can be considered as the impact of the attack on the first digital twin.

[0074] In some implementations, embodiments of this disclosure can also render the visual changes to the user interface caused by the attack in real time through the first digital twin during the attack execution process. The impact on the first digital twin can also be visualized. For example, the DOM elements affected by the attack can be highlighted in real time, and the propagation path of the data flow can be displayed in animation (e.g., the process of malicious data flowing from URL (Uniform Resource Locator) parameters to DOM elements).

[0075] according to Figure 1 and Figure 2In this embodiment of the present disclosure, by obtaining a first digital twin of the application client and an attack script, the attack script is run in the first digital twin of the first application client. The execution stack and DOM snapshot of the first digital twin during the execution of the attack script are obtained. Through the execution stack and DOM snapshot of the first digital twin during the execution of the attack script, the impact of the attack script on the application client can be accurately verified, thus providing a basis for timely discovery and elimination of security vulnerabilities. Based on a deep synchronization mechanism using Hook injection and Proxy, a high-fidelity mapping of complex dynamic behaviors of the application client is achieved, solving the problem of front-end application client state synchronization in digital twin technology. By introducing CAP-DL and visualizing the impact on the first digital twin, it is beneficial to structurally define, accurately reproduce, and intuitively analyze complex attacks (especially asynchronous and time-related attacks), improving the intuitiveness and depth of attack verification.

[0076] In some embodiments, the existence of a security vulnerability in the application client can be determined based on the impact of an attack on the first digital twin. For example, if an attack script steals sensitive data or tamperes with client functions, the application client is determined to have a security vulnerability. Conversely, if the sensitive data access or function tampering behavior of the attack script is intercepted, the application client is determined not to have a security vulnerability. If a security vulnerability is determined to exist in the application client, this disclosure also provides a corresponding vulnerability remediation solution.

[0077] Example, Figure 3 This is a flowchart of a security vulnerability remediation method provided in an embodiment of this disclosure. Figure 3 As shown, in some embodiments, the security vulnerabilities can be patched using the following methods.

[0078] In step S301, if a security vulnerability is determined in the application client based on the impact of the attack on the first digital twin, a context snapshot of the first digital twin during the execution of the attack script is obtained.

[0079] In some embodiments of this disclosure, when a security vulnerability is discovered in a simulated attack, the first digital twin captures a Twin-Runtime Context Snapshot of the first digital twin when the attack occurs. This context snapshot can be understood, for example, as a structured data packet and includes at least one of the following: the DOM structure of the first digital twin during the execution of the attack script, the execution stack, the state of the task queue, the attack script, and the execution path of the attack.

[0080] The first digital twin's DOM structure during the attack script's execution represents the DOM tree structure at the time of the attack. The execution stack represents the call stack (e.g., JavaScript call stack, but not limited to JavaScript call stack) at the time the vulnerability is discovered. This call stack indicates the specific code location where the vulnerability occurred. The task queue state includes the state of the task queue corresponding to asynchronous events in the first digital twin at the time the vulnerability is discovered. The attack execution path marks the flow of malicious data from the input point to the rendering point or function execution point.

[0081] In step S303, the context snapshot of the first digital twin during the execution of the attack script is input into a preset model, and vulnerability remediation suggestions are generated through the preset model.

[0082] The preset model mentioned in this embodiment can be trained based on any model (e.g., a large oracle model, but not limited to a large language model), taking a snapshot of the context when the digital twin is attacked as input and vulnerability remediation suggestions as output. The training method of this model can be found in the model training methods in related technologies, and will not be repeated here.

[0083] It is worth noting that, unlike existing technologies that generate general remediation suggestions based on static code snippets or fuzz test results, the embodiments of this disclosure can utilize the powerful code understanding and reasoning capabilities of a preset model, combined with a context snapshot of the digital twin when it is attacked, to generate customized remediation suggestions. For example, based on a DOM structure snapshot, the preset model can accurately locate a specific input box and generate targeted input cleanup function code; or based on the execution path of the attack, it can generate suggestions for modifying the data processing logic for that execution path, etc.

[0084] In addition, in some examples, the vulnerability remediation suggestions output by embodiments of this disclosure can also be structured. For example, they may include problematic code snippets, suggested remediation code, code insertion locations (such as file paths, line numbers, etc.), and credibility scores and side effect risk assessments of the remediation solutions.

[0085] In step S305, based on the vulnerability remediation recommendations, the vulnerability of the first digital twin is remediated to obtain the second digital twin.

[0086] For example, in some embodiments, the fix code can be inserted at the corresponding insertion point based on the fix code and insertion location carried in the fix suggestion, thus completing the fix for the vulnerability. Of course, this is only an example of a vulnerability fix method, and not the only one.

[0087] according to Figure 3In this embodiment, when a security vulnerability exists in the application client, a context snapshot of the first digital twin during the execution of the attack script is obtained. The context snapshot is then input into a preset model, and vulnerability remediation suggestions are generated through the preset model. This approach combines the dynamic running state reflected in the context snapshot with the semantic understanding capability of the model, thereby improving the remediation suggestions in terms of their relevance and accuracy.

[0088] For example, in some embodiments, after completing the vulnerability repair of the first digital twin based on the vulnerability repair recommendations and obtaining the second digital twin, the repair effect of the vulnerability repair recommendations can be evaluated from multiple dimensions.

[0089] For example, in some implementations, after patching the vulnerability based on the vulnerability patching recommendations and obtaining the second digital twin, the attack script that ran during the attack simulation can be re-run on the second digital twin using the same methods as during the attack simulation. This allows for the determination of the attack script's impact on the second digital twin. Based on this impact, it can be determined whether the security vulnerability has been patched, such as whether access to sensitive data was blocked or modifications to functionality were rejected. Specifically, if access to sensitive data was blocked and modifications to functionality were rejected, the security vulnerability is considered patched. Otherwise, it is determined that the security vulnerability has not been patched.

[0090] For example, in other implementations, a functional compatibility assessment of the patched application client can be performed based on the second digital twin. For instance, in some examples, a script for a preset operation (such as clicking, swiping, or dragging) and the first function to be implemented by that preset operation can be obtained. The script for the preset operation is then run on the second digital twin, simulating the preset operation on the second digital twin. Simultaneously, a second function implemented by the preset operation on the second digital twin is determined. The first and second functions include information such as function type, function execution logic, interface response during function execution, and rendering state. By comparing the first and second functions, the impact of the vulnerability patch on the application client's functionality can be determined. This includes whether new functions have been introduced, whether functional anomalies have occurred, and whether the user interface has been affected.

[0091] For example, in some other implementations, the impact of vulnerability remediation on application client performance can be determined by obtaining the first performance parameters of the first digital twin and the second performance parameters of the second digital twin. For instance, in some examples, performance parameters such as rendering performance (e.g., rendering speed) and resource consumption (e.g., memory usage, CPU utilization, network request latency) of the first and second digital twins can be monitored. The change in each performance indicator after remediation relative to before remediation can be calculated, and then, using pre-set weight values ​​for each performance indicator, the changes in each indicator can be weighted and summed to obtain the performance overhead of vulnerability remediation on the application client. Of course, this is merely an example and not the only possible solution.

[0092] Furthermore, if the vulnerability remediation suggestion generated by the preset model fails to fix the security vulnerability, or if the vulnerability remediation introduces new functional anomalies, or if the performance overhead of the vulnerability remediation on the application client is greater than or equal to the preset overhead threshold, the evaluation results of the remediation effect, evaluation indicators, and side effect data (such as information on new functional anomalies, decaying performance indicators, and information on unrepaired security vulnerabilities) are returned to the preset model. Based on the above evaluation results, evaluation indicators, and side effect data, as well as the context snapshot of the first digital twin when running the attack script, the preset model regenerates the remediation suggestion and re-executes the above remediation effect evaluation process until the evaluation is passed. Finally, the generated remediation suggestion is applied to the application client.

[0093] The embodiments disclosed herein can perform pre-simulation, evaluation, and feedback optimization of vulnerability remediation from dimensions such as vulnerability remediation results, functional compatibility, and performance overhead, which is conducive to improving the intelligence and automation level of vulnerability remediation.

[0094] Figure 4 This is a schematic diagram of a system architecture provided by an embodiment of this disclosure. For example... Figure 4 As shown, in some examples, there is a first device 410 and a second device 420.

[0095] The first device 410 includes an application client 411 and an update deployment module 412. The update deployment module receives update files or vulnerability remediation suggestions from the application client 411 and updates or remediates the application client 411 based on these suggestions.

[0096] The second device 420 includes a visualization interaction layer 421 and a digital twin system 422. The digital twin system 422 contains a digital twin (which can be understood as the first digital twin in the above embodiments) running an application client 411. The visualization interaction layer 421 is used to visualize relevant information of the digital twin system 422, such as the operating status of the digital twin in the digital twin system 422, the impact of attacks, vulnerability remediation suggestions, and the evaluation results of vulnerability remediation effects.

[0097] In some examples, the digital twin system 422 can have multiple functions, such as collecting data on the DOM structure, code execution environment, user interaction data, and data traffic of the application client 411 to create a digital twin of the application client 411; simulating attacks on the digital twin of the application client 411 to obtain a context snapshot of the digital twin during attack execution, and intelligently making vulnerability remediation suggestions based on the context snapshot; and providing feedback on vulnerability remediation through language, evaluation, and optimization based on preset multi-dimensional indicators. The vulnerability remediation suggestions finally generated by the digital twin system 422 are sent to the update and deployment module 412 in the first device 410. The update and deployment module 412 in the first device 410 then performs vulnerability remediation on the application client 411.

[0098] Example, Figure 5 This is a schematic diagram of the structure of a device provided in an embodiment of this disclosure. The device can be understood as follows: Figure 4 The second device in the embodiment. For example... Figure 5 As shown, in some examples, the digital twin system in the second device may include a data acquisition layer, a digital twin modeling layer, an intelligent decision-making layer, an interactive simulation and rehearsal layer, and a security policy deployment and reality feedback layer.

[0099] Among them, the data acquisition layer, as the foundation of the digital twin system, is responsible for collecting multi-source heterogeneous data in real time through lightweight, non-intrusive proxies or browser extensions, including DOM structure, code execution environment, user interaction data, data traffic, etc.

[0100] In some examples, the data acquisition layer can integrate Hook injection mechanisms, proxy mechanisms, user interaction data tracking functions, and data traffic monitoring functions. Among these, the Hook injection mechanism is used to obtain application client (e.g., ...) data. Figure 4 The application client (411) displays the real-time DOM structure. The proxy mechanism is used to obtain data about the application client's real-time code execution environment. User interaction data tracking is used to obtain user interaction data (such as user-submitted sequences). Data traffic monitoring is used to obtain data traffic data (such as data flow direction) on the application client.

[0101] The digital twin modeling layer is used to build digital twins that are consistent with the state of application clients (e.g., Figure 4 The digital twin of the application client 411 in the application. It processes data from the data acquisition layer, and implements real-time consistency between the digital twin and the real application client's DOM structure (including the real DOM structure and the virtual DOM structure), code execution environment, rendering state, user interaction data, and data flow.

[0102] For example, in some cases, the digital twin modeling layer may include data cleaning and standardization functions, DOM high-fidelity modeling functions, virtual DOM deep modeling functions, asynchronous event tracking functions, code execution environment reconstruction functions, real-time state consistency maintenance functions, rendering state synchronization functions, and digital twin modeling functions.

[0103] The data cleaning and standardization functions are used to clean and normalize the data collected by the data acquisition layer. The DOM high-fidelity modeling function is used to model the real DOM structure collected by the data acquisition layer. The virtual DOM deep modeling function is used to model the virtual DOM structure collected by the data acquisition layer. The asynchronous event tracing function is used to identify user behavior sequences based on user interaction data collected by the data acquisition layer. The code execution environment reconstruction function is used to reconstruct the application client's code execution environment based on the code execution environment collected by the data acquisition layer. The real-time state consistency maintenance function is used to time-align the data collected by the data acquisition layer. The rendering state synchronization function is used to monitor the rendering state of the digital twin and the rendering state of the real application client to ensure consistency between the two. The digital twin modeling function is used to build a digital twin of the application client based on the execution results of the functions in the digital twin modeling layer.

[0104] The intelligent decision-making layer relies on an artificial intelligence model. Its core function is to receive and analyze the context snapshot of the digital twin during the execution of the attack script and output vulnerability remediation suggestions. This layer integrates a vulnerability database and a threat intelligence database. The vulnerability database stores information on discovered security vulnerabilities. The threat intelligence database contains information on discovered cyberattacks. The intelligent decision-making layer can generate targeted attack payloads and propose structured, code-level remediation suggestions.

[0105] For example, in some implementations, the intelligent decision-making layer integrates a model-driven engine, snapshot analysis functionality, a vulnerability and threat intelligence database, payload generation functionality, and structured decision output functionality. The snapshot analysis function parses and extracts features from the context snapshot of the digital twin, inputting the extracted features into the model-driven engine. The model-driven engine then drives the model to generate vulnerability remediation suggestions based on the features extracted by the snapshot analysis function. The structured decision data function generates structured remediation suggestions based on the vulnerability remediation suggestions output by the model-driven engine. The vulnerability and threat intelligence database stores information on discovered security vulnerabilities and network attacks. The payload generation function generates attack payloads based on the information in the vulnerability and threat intelligence database.

[0106] The interactive simulation and pre-playback layer is used to build a highly realistic simulation environment in the digital twin system. This layer provides a graphical interface, supports injection attacks via CAP-DL or manual operation, and can simulate and test the repair suggestions generated by the model. The repair effect is verified through a multi-dimensional quantitative evaluation system (security, functionality, performance).

[0107] For example, in some examples, the interactive simulation and pre-playing layer can integrate a high-fidelity simulation environment, CAP-DL-based attack injection functionality, manual operation-based attack input functionality, a graphical user interface, a remediation pre-playing function, an attack simulation function, and a remediation effect evaluation function. Specifically, the CAP-DL-based attack injection function receives and parses attack scripts input in CAP-DL format. The manual operation-based attack input function receives and parses attack payloads input manually. The remediation pre-playing function is used to pre-play the remediation schemes in the vulnerability remediation recommendations on the digital twin. The attack simulation function is used to run attack scripts on the digital twin to simulate attacks. The remediation effect evaluation function is used to evaluate the remediation effect of the remediation scheme. The graphical user interface visualizes the impact of the attack and the remediation effect evaluation results for the user.

[0108] The security policy deployment and feedback layer is used to automatically deploy the verified best remediation solutions (such as code patches and CSP (Content Security Policy) rules) to application clients through preset pipelines, and to feed back the effect data of the application client deployment to the digital twin, forming a continuously optimized intelligent defense closed loop.

[0109] For example, in some implementations, the security policy deployment and feedback layer can integrate a CI (Continuous Integration) / CD (Continuous Deployment) pipeline, including automated deployment, code patch generation, feedback data collection, effect monitoring and evaluation, CSP rule update, and closed-loop optimization. Specifically, the code patch generation function generates corresponding code patches based on the final optimal remediation recommendation. The automated deployment function calls the CI / CD pipeline to deploy the code patches to the application client. The CSP rule update function updates the CSP rules based on the final optimal remediation recommendation. The feedback data collection function receives effect data from the application client after the remediation is performed. The effect monitoring and evaluation function evaluates the actual remediation effect based on the effect data from the application client (the method can be found in the section related to remediation recommendation effect evaluation in the aforementioned embodiments). The closed-loop optimization function feeds back the evaluation results from the effect monitoring and evaluation function to the intelligent decision layer, enabling the intelligent decision layer to optimize and train the model based on the evaluation results.

[0110] See also Figure 5 ,like Figure 5 The second device shown includes a visualization and interaction layer that provides a high-performance graphical interface. This interface may include a DOM tree view, highlighted data flow during the attack, a dynamic demonstration of attack path propagation and changes, and real-time rendering of the user interface. It also includes an overview of security vulnerabilities detected based on the attack script, a control interface for the attack simulation process allowing users to start or pause the attack, a dashboard for multi-dimensional assessment data of remediation recommendations, and a platform for viewing these recommendations.

[0111] Figure 6 This is a schematic diagram illustrating the execution process of an application example of the attack verification method provided in this disclosure. Figure 6 The application client mentioned in Nakamoto's disclosure is specifically a web client. For example... Figure 6 As shown, in this example, the digital twin system captures DOM operations and virtual DOM updates on the web client through Hook injection technology to obtain the DOM structure of the web client; it intercepts the JavaScript runtime environment through a proxy mechanism; it obtains user interaction data and data traffic data through task queue monitoring; and then, based on the DOM structure of the web client, the JavaScript runtime environment, and the user interaction data and data traffic, it establishes a digital twin of the web client (which can be understood as the first digital twin in the aforementioned embodiment).

[0112] After creating a digital twin of the web client, users can input attack scripts via CAP-DL. Upon receiving the attack script, the digital twin system simulates the attack on the digital twin and, through execution stack tracing and DOM snapshot analysis, identifies and visualizes data such as the affected DOM elements and the attack execution path. Based on the information about the affected DOM elements and the attack execution path, an attack analysis report is generated and visualized.

[0113] Figure 7 This is a schematic diagram illustrating the execution process of another application example of the attack verification method provided in this disclosure. For example... Figure 7 As shown, in some application examples, when an attack script is run in the digital twin of the application client (such as the first digital twin in the aforementioned embodiment) and a security vulnerability is detected, a context snapshot of the digital twin during the execution of the attack script is obtained. The context snapshot is input into a preset model, which generates multiple vulnerability remediation suggestions. For each vulnerability remediation suggestion, its remediation effect is evaluated across multiple dimensions, including remediation results, functional compatibility, and performance overhead, and the suggestion with the best evaluation result is selected. If the best evaluation result meets the criteria, the vulnerability remediation suggestion with the best evaluation result is executed. If the best evaluation result does not meet the criteria, the evaluation result and other data are fed back to the preset model, and a new vulnerability remediation suggestion is generated using the preset model. This process continues until a vulnerability remediation suggestion with a satisfactory evaluation result is obtained.

[0114] It is worth noting that the solutions provided in this disclosure can be applied to various scenarios that require application client security protection. These include, but are not limited to, the following scenarios.

[0115] Web Application Security Testing and Development: In the development process of various web applications, the solutions disclosed in this embodiment can serve as core tools. Developers and security teams can accurately reproduce complex attack chains through CAP-DL, intuitively view the attack effects, and verify the effectiveness and compatibility of remediation solutions before code release.

[0116] Mobile application client security assessment: Build a digital twin of the mobile application client, simulate attacks targeting WebView, local storage, API (Application Programming Interface) calls, assess risks, and provide targeted remediation suggestions.

[0117] Front-end supply chain security management: To address issues such as malicious NPM (Node Package Manager) packages and tampered CDN (Content Delivery Network) scripts, a digital twin of the front-end is constructed to simulate the propagation path and visual impact after malicious code injection, and suggestions for component replacement or security configuration are provided accordingly.

[0118] User behavior anomaly detection and anti-fraud: Construct a digital twin of user interaction flow, and accurately identify abnormal behaviors caused by automated scripts, bots, etc. through visual playback and anomaly detection, to support anti-fraud efforts.

[0119] UI (User Interface) / UX (User Experience) security compliance verification: During the design and development phases, simulated attacks are used to verify whether the UI / UX design conforms to security best practices (such as preventing clickjacking) and to ensure the security of interface interactions.

[0120] As can be seen from the foregoing embodiments of this disclosure, the embodiments of this disclosure can achieve at least the following technical effects.

[0121] Achieving high-fidelity, real-time, and dynamic visualization of front-end application clients: Through a deep state binding mechanism based on Hook injection and Proxy, this disclosure can accurately reconstruct the complex architecture and dynamic operation of front-end application clients, providing security teams with a real-time, dynamic, and high-fidelity view of the front-end security posture, helping them to fully grasp the risk status faced by application clients.

[0122] Significantly enhances the intuitiveness and in-depth analysis capabilities of application client threat simulation: By introducing the Client Attack Path Description Language (CAP-DL), this disclosure enables the simulation of client attack chains that are both forward-looking and interactive, and can be structured and reproducible. It also visually demonstrates the specific impact of attacks on the user interface and functionality using pre-defined visualization methods. This will bring an intuitive and traceable experience to application client security testing.

[0123] Intelligent detection, code-level remediation, and optimization of application client security vulnerabilities: By analyzing context snapshots of attack scripts running on digital twins using artificial intelligence models, intelligent code-level remediation suggestions can be generated. Combined with remediation scheme simulations based on multi-dimensional quantitative evaluation, the efficiency and accuracy of remediation can be significantly improved, selecting the optimal remediation solution without affecting the actual user experience.

[0124] This disclosure establishes an automated, closed-loop application client security defense system: It streamlines the entire process from "high-fidelity modeling" to "attack simulation," "intelligent remediation," "pre-performance verification," and finally "policy deployment," forming an intelligent closed-loop defense system. This reduces the need for manual operation. By performing attack simulation and pre-performance verification on a simulated digital twin, it effectively avoids the negative impacts that might result from operational errors in a real production environment, significantly reducing the cost and risk of application client security operations.

[0125] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this disclosure.

[0126] Based on the same inventive concept, this disclosure also provides an attack verification apparatus for implementing the attack verification method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more attack verification apparatus embodiments provided below can be found in the limitations of the attack verification method described above, and will not be repeated here.

[0127] Figure 8 This is a schematic diagram of the structure of an attack verification device provided in an embodiment of this disclosure. Figure 8 As shown, the attack verification device 800 provided in this embodiment may include:

[0128] The first acquisition module 801 is used to acquire the first digital twin of the application client and the attack script.

[0129] The second acquisition module 802 is used to run the attack script in the first digital twin and acquire the execution stack and document object model (DOM) snapshot of the first digital twin when running the attack script.

[0130] The first determining module 803 is used to determine the impact of the attack implemented by the attack script on the first digital twin based on the execution stack and the DOM snapshot.

[0131] In some implementations, the first acquisition module 801 is used to acquire data from the application client, the data including at least one of the following: DOM structure, code execution environment, user interaction data, and data traffic; and generate a first digital twin of the application client based on the data from the application client.

[0132] In some implementations, the attack script is used to describe the sequence of user behavior during the attack, the triggering conditions of the attack, the injection point, and the expected data flow of the attack.

[0133] In some implementations, the first determining module 803 is configured to determine at least one of the following information based on the execution stack: the injection point of the attack, the execution path, the sensitive data accessed, and the functions to be tampered with; determine the DOM elements affected by the attack based on the DOM snapshot; and use the at least one piece of information and the DOM elements as the impact of the attack on the first digital twin.

[0134] In some implementations, the attack verification device may further include:

[0135] The third acquisition module is used to acquire a context snapshot of the first digital twin when the attack script is running, if it is determined that the application client has a security vulnerability based on the impact of the attack on the first digital twin.

[0136] The generation module is used to input the context snapshot into a preset model and generate vulnerability remediation suggestions through the preset model.

[0137] The repair module is used to repair vulnerabilities in the first digital twin based on the vulnerability repair suggestions, so as to obtain a second digital twin.

[0138] In some implementations, the context snapshot includes at least one of the following: the DOM structure of the first digital twin during the execution of the attack script, the execution stack, the state of the task queue, the attack script, and the execution path of the attack.

[0139] In some implementations, the attack verification device may further include:

[0140] The second determining module is used to run the attack script on the second digital twin and determine the impact of the attack script on the second digital twin.

[0141] The third determining module is used to determine whether the security vulnerability has been patched based on the impact of the attack on the second digital twin.

[0142] In some implementations, the attack verification device may further include:

[0143] The fourth acquisition module is used to acquire the script of the preset operation and the first function implemented by the preset operation target.

[0144] The fourth determining module is used to run the script of the preset operation on the second digital twin and determine the second function implemented by the preset operation on the second digital twin.

[0145] The fifth determining module is used to determine the impact of the vulnerability fix on the functionality of the application client based on the first function and the second function.

[0146] In some implementations, the attack verification device may further include:

[0147] The fifth acquisition module is used to acquire the first performance parameters of the first digital twin and the second performance parameters of the second digital twin.

[0148] The sixth determining module is used to determine the impact of the vulnerability fix on the performance overhead of the application client based on the first performance parameter and the second performance parameter.

[0149] Each module in the aforementioned attack verification device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0150] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data from digital twins of application clients. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements an attack verification method.

[0151] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present disclosure and does not constitute a limitation on the computer device to which the present disclosure is applied. A specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0152] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the methods of any of the above embodiments.

[0153] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the methods of any of the above embodiments.

[0154] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods of any of the above embodiments.

[0155] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0156] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, databases, or other media used in the embodiments provided in this disclosure can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this disclosure may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this disclosure may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

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

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

Claims

1. An attack verification method characterized by, The method includes: Obtain the first digital twin of the application client, as well as the attack script; The attack script is run in the first digital twin, and the execution stack and document object model (DOM) snapshot of the first digital twin when the attack script is run are obtained. Based on the execution stack and the DOM snapshot, the impact of the attack implemented by the attack script on the first digital twin is determined.

2. The method of claim 1, wherein, The process of obtaining the first digital twin of the application client includes: Obtain data from the application client, the data including at least one of the following: DOM structure, code execution environment, user interaction data, and data traffic; Based on the data from the application client, a first digital twin of the application client is generated.

3. The method of claim 1, wherein, The attack script is used to describe the user behavior sequence during the attack, the attack triggering conditions, the injection point, and the expected data flow of the attack.

4. The method according to claim 1, characterized in that, The step of determining the impact of the attack script's attack on the first digital twin based on the execution stack and the DOM snapshot includes: Based on the execution stack, at least one of the following information is determined: the injection point of the attack, the execution path, the sensitive data accessed, and the functions to be tampered with; Based on the DOM snapshot, the DOM elements affected by the attack are determined; The at least one piece of information and the DOM element are considered as the impact of the attack on the first digital twin.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: If, based on the impact of the attack on the first digital twin, it is determined that the application client has a security vulnerability, a context snapshot of the first digital twin is obtained when the attack script is running. The context snapshot is input into a preset model, and vulnerability remediation suggestions are generated through the preset model. Based on the vulnerability remediation suggestions, the vulnerability of the first digital twin is remediated to obtain the second digital twin.

6. The method according to claim 5, characterized in that, The context snapshot includes at least one of the following: The first digital twin includes the DOM structure, execution stack, task queue state, attack script, and attack execution path during the execution of the attack script.

7. The method according to claim 5, characterized in that, The method further includes: Run the attack script on the second digital twin and determine the impact of the attack script on the second digital twin; Based on the impact of the attack on the second digital twin, determine whether the security vulnerability has been patched.

8. The method according to claim 5 or 7, characterized in that, The method further includes: Obtain the script for the preset operation, and the first function to be achieved by the preset operation target; Run the script of the preset operation on the second digital twin, and determine the second function implemented by the preset operation on the second digital twin; Based on the first function and the second function, determine the impact of the vulnerability fix on the functionality of the application client.

9. The method according to claim 5 or 7, characterized in that, The method further includes: Obtain the first performance parameters of the first digital twin and the second performance parameters of the second digital twin; Based on the first performance parameter and the second performance parameter, determine the impact of the vulnerability fix on the performance overhead of the application client.

10. An attack verification device, characterized in that, include: The first acquisition module is used to acquire the first digital twin of the application client and the attack script; The second acquisition module is used to run the attack script in the first digital twin and acquire the execution stack and document object model (DOM) snapshot of the first digital twin when running the attack script. The first determining module is used to determine the impact of the attack implemented by the attack script on the first digital twin based on the execution stack and the DOM snapshot.

11. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images