Information loss vulnerability detection method and system

Abstract

The invention discloses an information loss vulnerability detection method and system, and relates to the technical field of information loss vulnerability detection, and the method comprises the steps: finding entrances of all user operations based on a labeled information loss field, generating an automatic use case through an online traffic recording mode, covering all combinations of information loss field operations, and carrying out information loss field detection. And the coverage degree of deployment of resource loss points is verified and resource loss vulnerabilities which are not subjected to deployment are found by playing back automatic use cases and tampering real data. The problems of insufficient information loss coverage and low efficiency of detecting information loss vulnerabilities by manually combing and compiling use cases are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of asset damage vulnerability detection, and in particular to an asset damage vulnerability detection method and system. Background Art

[0002] Internet businesses are developing rapidly, and the complexity of capital flows is increasing day by day along with the rapid development of businesses. The current industry's asset loss prevention construction mainly relies on manual regular sorting of asset loss scenarios, which easily miss risk points, and deploys asset loss defenses for the manually sorted missed risk points. Faced with the problem that relying on manual sorting cannot guarantee coverage, and that incremental asset loss points cannot be covered in a timely manner, many companies in the industry have begun to explore asset loss attack and defense systems, and rely on asset loss attack and defense to detect existing asset loss point vulnerabilities in real time. Regarding the detection of asset loss vulnerabilities, various companies are currently in the exploration and construction stage. The more mature ones mainly use two solutions: rule-based asset loss vulnerability detection and asset loss vulnerability detection based on asset loss fields. Among them, one solution is rule-based asset loss vulnerability detection, such as Figure 1 As shown, the data for rule-based asset loss vulnerability detection comes from the replication of online production environment data, and the data is relatively real; the entire drill is isolated from the data in the production environment, so it is a lossless drill. The solution mainly replicates online data for playback, and exercises the effectiveness of deployment rules by tampering with online data. Production data mainly comes from online Binlog or MQ messages. The goal of the solution is to verify the effectiveness of deployed rules, and it cannot detect the coverage of asset losses. At the same time, the perfection of the verification rules is based on continuous manual business combing to improve, and it is impossible to achieve complete omissions and it is impossible to make accurate assessments of possible omissions. Figure 2 As shown, another solution is field tampering-based asset damage vulnerability detection. This approach ensures asset damage attack coverage by combing through all asset damage fields and manually combing through business scenarios to target asset damage fields. This attack method, based on scenario and source data dimensions, shifts the attack entry point from the verification layer to the data source layer, indirectly batch-running all checks associated with the data table. This decouples attack and verification, ensuring realistic and objective drills while significantly improving the breadth and depth of verification coverage. This solution also requires continuous business review, and coverage cannot be effectively verified. Summary of the Invention

[0003] In view of the problems that the current solutions in the industry rely on a lot of manual combing and the coverage cannot be checked, the purpose of the present invention is to provide a data damage vulnerability detection technology, which aims to solve the problems of insufficient data damage coverage and the inefficiency of manually combing and writing use cases to detect data damage vulnerabilities.

[0004] To achieve the above technical objectives, this application provides a method for detecting asset damage vulnerabilities, including the following steps: Mark the data loss fields of the business system. The data loss fields refer to the database table fields in the MySQL database where the business system data is stored and may cause data loss. Using link data, identify traffic entry points that have changed all marked loss fields; In the online environment, the request data initiated by users for identified and marked traffic entrances is recorded and stored; Based on the recorded online user request data, traffic data is replayed in the offline environment to isolate the real online user data to avoid impact; Based on the online user traffic playback operation, an interface call is initiated for all identified and marked traffic entries. When the interface call initiates a change to the marked damaged field, the changed data of the marked damaged field is tampered with; After data tampering, the business system will conduct asset damage verification. If there is any inconsistency in the asset damage verification, an asset damage alarm will be triggered. All replayed user traffic data is recorded and triggered asset loss alarm information is monitored.

[0005] Preferably, after the asset loss fields of the business system are marked, in the subsequent business requirement development process, incremental marking is performed on the newly added business database table fields to ensure the coverage of the asset loss field marking.

[0006] Preferably, when identifying the traffic entry that changes all the marked asset and loss fields, periodically obtain the links that change all the asset and loss fields, and recursively search based on the parent ID of the link until the source link is found, and parse the traffic entry information of the source link, specifically including the following steps: a. Process the asset loss field in the format of cluster-database-table-field; b. Based on the user-annotated asset loss field information, the system groups the data by database and calculates the application links based on the application information connected to the database. 100 links are sampled according to the SQL template dimensions. The SQL information of the links is parsed into cluster-database-table-field-read / write type, and then matched with the annotated asset loss field information. c. For the links that match in step b, query their link sources, record the traffic entry, the application that executes the SQL, and the data loss field, and summarize the association between the traffic entry and the data loss field; d. If the identified traffic entry is a new entry, the traffic entry information is recorded and stored; if the identified traffic entry has been recorded and stored in the past, it is discarded and no longer recorded repeatedly.

[0007] Preferably, when recording and storing the request data initiated by the user for the identified and marked traffic entrance, all traffic entrances and the downstream full-link data of the traffic entrance are recorded and stored, wherein the recorded and stored data includes the input parameter information, output parameter information and request header information of the traffic entrance.

[0008] Preferably, when recording and storing, hash sampling, recording and storage are performed according to the last digit of the user ID.

[0009] Preferably, when performing traffic replay, a unique traffic ID tag is generated for each traffic data through traffic replay, and is transmitted to the downstream sub-link through the specific field x_trace_id, so as to be associated with the traffic entry data according to the ID during the final business side asset loss verification; wherein, traffic replay means simulating the initiation of a user call to the traffic entry in an offline environment, and the input parameter information is the input parameter information of the real online user traffic entry recorded and stored.

[0010] Preferably, when replaying traffic, if it is a traffic entry of the Http interface class, simulate sending an Http interface request, and replace the request header and request input parameters with the recorded request header and request input parameters of the Http interface, and add the x_trace_id field in the request header. The field data is the generated unique traffic ID tag; If the traffic entry is a scheduled task, the traffic will be replayed in order based on the recorded traffic entry sequence, based on the recording task parameters. When executing a scheduled task, a unique traffic ID is added to the execution link and transparently transmitted to the downstream.

[0011] Preferably, when data tampering is performed, by intercepting the SQL execution request, the SQL is matched according to the configured tampering conditions and tampering parameters, and after matching, the data is replaced according to the tampering parameters, and finally the SQL is executed, wherein the data tampering is performed in one or more of the following ways, including: Replace the specified value and directly tamper with the data to the specified value; Tamper with the amount and change the target value to a random value within the specified range; Tamper with the enumeration and change the target value to a non-current value within the valid range of the enumeration; Splice dirty data and add a specified string after the original value; Boolean negation, inverts the original value.

[0012] Preferably, when listening to the service system damage alarm message, whether there is the damage alarm message of the x_trace_id is judged through the x_trace_id, if yes, it indicates that the service side system has the damage field data tampering defense monitoring and can find out at the first time, and is not recorded as a damage vulnerability; if there is no corresponding alarm message corresponding to the user flow data of the x_trace_id, it indicates that the damage field data tampering of the user flow is not effectively monitored, and is recorded as a damage vulnerability.

[0013] The application also provides a damage vulnerability detection system for realizing the damage vulnerability detection method mentioned above, comprising: The marking module is used for marking the damage field of the business system, wherein the damage field represents the database table field of the business system data stored in the MySQL database, which may cause damage to occur; The identification module is used for identifying the traffic entry changing all the marked damage fields by means of link data; The recording module is used for recording and storing the request data of the user initiated to the identified traffic entry in the online environment; The playback module is used for playing back the traffic data in the offline environment according to the recorded online user request data, so as to isolate the online user real data and avoid the influence; The tampering module is used for initiating the interface call to all the marked traffic entries according to the online user traffic playback operation, and tampering the change data of the marked damage field when the interface call initiates the change to the marked damage field; The verification module is used for verifying the damage of the business system after the data tampering, and triggering the damage alarm information when the damage verification is inconsistent; The listening module is used for recording all the played back user traffic data and listening to the triggered damage alarm information.

[0014] The application discloses the following technical effects: The application is based on the online real, large and continuous user request full-link data and the marked damage field, finds all the damage traffic entries based on the link tracking data, and guarantees the coverage of all the damage field changes. Through the online large, real and continuous user request traffic data recording and playback, each damage field has comprehensive use case coverage, which guarantees that the damage detection coverage can be improved by triggering the damage defense alarm of the business system through the use case data tampering.

[0015] The application supports continuous drilling through the automatic online traffic recording and playback mode, and does not need to rely on a large number of manual operations to improve the efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0017] Figure 1 This is a schematic diagram of the execution logic of the rule-based asset damage vulnerability detection described in the background technology of the present invention; Figure 2 This is a schematic diagram of the execution logic of the asset damage vulnerability detection based on tampering fields described in the background technology of the present invention; Figure 3 Schematic diagram of the method principle of the present invention; Figure 4 It is a schematic flow chart of the method described in the present invention. DETAILED DESCRIPTION

[0018] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of this application.

[0019] like Figures 3-4 As shown, the present invention provides a technology for detecting asset damage vulnerabilities, which specifically includes the following processes: Step S10: First, annotate the business system's asset loss fields. Asset loss fields refer to database table fields in the MySQL database where business system data is stored that may cause asset loss, such as the deposit amount field, shipping amount field, and deposit refund field. After the initial full annotation of business asset loss fields, subsequent business requirements development processes will incrementally annotate newly added business database table fields by adding process steps in the technical solution review environment to ensure comprehensive coverage of asset loss field annotation.

[0020] Step S20: Based on all the asset loss fields marked in step S10, all traffic entries that have changed these asset loss fields are identified with the help of the link data stored in the full-link tracking system and stored in an independent storage medium. The key point to be solved in this step is how to identify all traffic entries that have changed the asset loss fields as comprehensively as possible. The full-link tracking system is a system that records the entire link information of all traffic entries from the initiation of the request to the final update of the database field, including the input parameter information, output parameter information, request header information, etc. of each traffic entry.

[0021] The key to achieving full-link tracking is that when the full-link tracking system reports link data at each traffic entrance, it generates a globally unique full-link ID: trace_id for each piece of data at each traffic entrance, and brings the trace_id to the downstream when the upstream calls the downstream and stores it as the parent link ID of the downstream link: parent_trace_id. By analogy, all child links and grandchild links under the trace_id can be found until the end link through the trace_id of the traffic entrance. Traffic entrances include various types of Http interfaces initiated by users from the App or Web end, and scheduled tasks within the system. The specific operation method for identifying traffic entrances with changed asset and loss fields is to find the links for all asset and loss field changes in the last 24 hours at regular intervals every day, and recursively search based on the parent ID (parent_trace_id) of the link until the source link is found, and parse the traffic entrance information of the source link. The steps are: a. Process the asset loss field in the format of cluster-database-table-field; b. Based on the user-annotated asset loss field information, the system groups the data by database and calculates the application links based on the application information connected to the database. 100 links are sampled according to the SQL template dimensions. The SQL information of the links is parsed into cluster-database-table-field-read / write type, and then matched with the annotated asset loss field information. c. Query the source of the matched links, record the traffic entry, the application that executes the SQL, and the data loss field, and summarize the relationship between the traffic entry and the data loss field.

[0022] d. If the identified traffic entry is a new one, the traffic entry information is recorded and stored. If the identified traffic entry is already recorded and stored, it is discarded and not recorded again. By automatically and regularly identifying and recording the traffic entry for the data loss field every day, the program continuously improves all traffic entries with changes to the data loss field, improving the coverage of traffic entry identification for the data loss field, and ultimately approaching 100% traffic entry coverage.

[0023] Step S30: Based on all traffic inlets identified in step S20, the online environment records and stores user request data for all marked traffic inlets. This recording of user request data in the online environment is necessary to facilitate subsequent data playback and verification in the QA (offline) environment, isolating any impact on the actual online user request data. In real-world business scenarios and microservices system architectures, after a user initiates a request at a traffic inlet, multiple layers of service calls are subsequently made. Each call generates multiple layers of sub-links within that traffic inlet.

[0024] To ensure that the multi-level sub-links under the traffic entry can be fully replayed in series during subsequent playback in the QA (offline) environment and that the asset loss field can be modified, all traffic entry points and the downstream full-link data of the traffic entry must also be recorded and stored during traffic recording.

[0025] The recorded and stored data includes the input parameter information, output parameter information, and request header information (if any) of the traffic entrance.

[0026] Traffic recording is performed through system configuration, including the entry interface for traffic recording, recording time period, and storage duration of recorded data. Considering the pressure on online systems, when recording online user traffic, hash sampling and recording storage are performed based on the last digit of the user ID. Once the system is configured and recording is enabled, automatic recording and storage of traffic entry points is achieved. By continuously recording and storing online user traffic, the coverage of each traffic entry point for asset loss field changes in different business scenarios, grayscale user groups, or branch conditions is continuously improved.

[0027] Step S40: Based on the online user request data recorded in step S30, traffic data is replayed in the QA (offline) environment to isolate the actual online user data and prevent impact. Traffic data replay refers to simulating a user initiating a call to the traffic entry in the QA environment, where the input parameter information is the recorded and stored input parameter information of the actual online user traffic entry.

[0028] Traffic data playback will actually initiate interface calls, MQ message sending, and scheduled task execution in the QA environment, thereby triggering full-link interface calls for the traffic entry, and ultimately triggering changes to the asset loss fields related to the traffic entry.

[0029] The traffic data playback is different according to different traffic entrances, but a unique traffic ID mark is generated for each piece of traffic data during traffic playback, and is transmitted to the downstream sub-link through a specific field (x_trace_id) for association with the traffic entrance data according to the ID during final business side asset loss checking and verification. If the traffic entrance is an Http interface, an Http interface request is simulated, the request header and request parameter are replaced with the recorded request header and request parameter of the Http interface, and the x_trace_id field is added to the request header, and the field data is the unique traffic ID mark; if the traffic entrance is a timing task, the playback traffic is performed in sequence based on the traffic entrance sequence recorded during the recording in step S30; and the unique traffic ID mark is added to the execution link during execution of the timing task, and is transmitted to the downstream.

[0030] Step S50: Based on the online user traffic playback operation in step S40, interface calls to all marked traffic entrances are initiated, and when the interface call initiates a change to the marked asset loss field, the change data marked as the asset loss field is tampered with, for example, the freight field is changed to 1000, and 1000 is tampered with to 500.

[0031] There are several ways to implement data tampering: 1. Replace the specified value, and directly tamper the data with the specified value; 2. Tamper with the amount, and tamper the target value with a random value within a specified range; 3. Tamper with the enumeration, and tamper the target value with other values (not the current value) within the enumeration valid range; 4. Concatenate dirty data, concatenate a specified string after the original value; 5. Boolean negation, negate the original value.

[0032] In the process of actually implementing the present application, the tampering method needs to be selected according to the actual data type of the asset loss field.

[0033] The technical solution for tampering with data is to intercept the execution request of SQL, match the SQL according to the tampering conditions and tampering parameters configured during the attack, replace the data according to the tampering parameters after matching, and finally execute the SQL.

[0034] Step S60: When the asset loss field change is triggered based on the online user traffic playback in step S50, the data of the real asset loss field change is tampered with in the manner described in step S50, and the data tampering will trigger the asset loss checking and verification logic of the business system.

[0035] The loss checking and verification logic of the business system has different implementation manners based on different business systems, such as upstream and downstream data comparison, bypass verification, and the like, and the implementation logic is determined by the business system according to the business characteristics, and is not within the implementation range of the system, and therefore is not described in detail. According to the agreement of each business system, when the loss checking and verification is inconsistent, a loss alarm information is triggered, and the alarm information is sent to a designated message queue through an MQ message, and the traffic ID (i.e., the x_trace_id transmitted in step S40) of the loss exception is recorded in the MQ message.

[0036] Step S70: Based on the user traffic playback performed in step S50 and the loss checking and verification logic of the business system in step S60, the tampering of the loss field is recorded, and the business system loss alarm message sent in step S60 is listened to, and whether there is a loss alarm message of the x_trace_id is determined through association by the x_trace_id, if yes, it is indicated that the loss field data tampering of the user traffic performed by the business side system is monitored and can be found at the first time, and is not recorded as a loss vulnerability; if there is no corresponding alarm message corresponding to the user traffic data of the x_trace_id, it is indicated that the loss field data tampering of the user traffic is not effectively monitored, and is recorded as a loss vulnerability.

[0037] The application finds all user operation entrances based on the annotated loss fields, generates automatic use cases through online traffic recording, covers all combinations of loss field operations, and verifies the coverage of the loss point monitoring and finds the loss vulnerabilities that are not monitored through playback of the automatic use cases and tampering of the real data.

[0038] In order to realize the above-mentioned method process, the application also designs a loss vulnerability detection system, comprising: An annotation module is configured to annotate the loss fields of the business system, wherein the loss field represents a database table field of the business system data stored in the MySQL database, which may cause the loss to occur; An identification module is configured to identify the traffic entrance for changing all annotated loss fields by means of link data; A recording module is configured to record and store the request data of the user for the identified annotated traffic entrance in an online environment; A playback module is configured to perform traffic data playback in an offline environment according to the recorded online user request data, so as to isolate the real data of the online user and avoid the influence; The tampering module is used to initiate an interface call to all marked traffic entries based on the online user traffic playback operation. When the interface call initiates a change to the marked asset-damaged field, the changed data of the marked asset-damaged field is tampered with; The verification module is used to verify data damage through the business system after data tampering. If there is any inconsistency in the verification, an alarm message will be triggered; The monitoring module is used to record all replayed user traffic data and monitor the triggered asset loss alarm information.

[0039] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0040] In the description of the present invention, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of the technical features indicated. Therefore, a feature specified as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, "plurality" means two or more, unless otherwise specifically defined.

[0041] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A method for detecting asset loss vulnerabilities, characterized in that: The following steps are involved: Marking the data loss fields of the business system, wherein the data loss fields represent the database table fields in the MySQL database where the business system data is stored and that may cause data loss; Using link data, identify traffic entry points that have changed all marked loss fields; In the online environment, the request data initiated by users for identified and marked traffic entrances is recorded and stored; Based on the recorded online user request data, traffic data is replayed in the offline environment to isolate the real online user data to avoid impact; Based on the online user traffic playback operation, an interface call is initiated for all identified and marked traffic entries. When the interface call initiates a change to the marked damaged field, the changed data of the marked damaged field is tampered with; After data tampering, the business system will conduct asset damage verification. If there is any inconsistency in the asset damage verification, an asset damage alarm will be triggered. All replayed user traffic data is recorded and triggered asset loss alarm information is monitored.

2. The method for detecting asset damage vulnerabilities according to claim 1, wherein: After marking the asset loss fields of the business system, in the subsequent business requirements development process, incremental marking is performed on the newly added business database table fields to ensure the coverage of the asset loss field marking.

3. The asset loss vulnerability detection method according to claim 2, characterized in that: When identifying a traffic entry that changes all marked data loss fields, periodically obtain the links where all data loss fields are changed, and recursively search based on the parent ID of the link until the source link is found, and parse the traffic entry information of the source link. Specifically, the following steps are included: a. Process the asset loss field in the format of cluster-database-table-field; b. Based on the user-annotated asset loss field information, the system groups the data by database and calculates the application links based on the application information connected to the database. 100 links are sampled according to the SQL template dimensions. The SQL information of the links is parsed into cluster-database-table-field-read / write type, and then matched with the annotated asset loss field information. c. For the links that match in step b, query their link sources, record the traffic entry, the application that executes the SQL, and the data loss field, and summarize the association between the traffic entry and the data loss field; d. If the identified traffic entry is a new entry, the traffic entry information is recorded and stored; if the identified traffic entry has been recorded and stored in the past, it is discarded and no longer recorded repeatedly.

4. The asset loss vulnerability detection method according to claim 3, characterized in that: When recording and storing the request data for the identified and marked traffic entrance initiated by the user, all traffic entrances and the downstream full-link data of the traffic entrance are recorded and stored, wherein the recorded and stored data includes the input parameter information, output parameter information and request header information of the traffic entrance.

5. The asset loss vulnerability detection method according to claim 4, characterized in that: When recording and storing, hash sampling and recording storage are performed according to the last digit of the user ID.

6. The asset loss vulnerability detection method according to claim 5, characterized in that: When performing the traffic replay, a unique traffic ID tag is generated for each traffic data through traffic replay, and is transparently transmitted to the downstream sub-link through the specific field x_trace_id, so as to be associated with the traffic entry data according to the ID during the final business side asset loss verification; wherein, the traffic replay means simulating the initiation of a user call to the traffic entry in an offline environment, and the input parameter information is the input parameter information of the recorded and stored online real user traffic entry.

7. The asset loss vulnerability detection method according to claim 6, characterized in that: When replaying the traffic, if it is a traffic entry of the Http interface class, simulate sending an Http interface request, and replace the request header and request input parameters with the recorded request header and request input parameters of the Http interface, and add the x_trace_id field in the request header. The field data is the generated unique traffic ID tag; If the traffic entry is a scheduled task, the traffic will be replayed in order based on the recorded traffic entry sequence, based on the recording task parameters. When executing a scheduled task, a unique traffic ID is added to the execution link and transparently transmitted to the downstream.

8. The method for detecting asset damage vulnerabilities according to claim 7, wherein: When data tampering is performed, the SQL execution request is intercepted and the conditions are matched according to the configured tampering conditions and tampering parameters. After matching, the data is replaced according to the tampering parameters and finally the SQL is executed. Data tampering is performed in one or more of the following ways, including: Replace the specified value and directly tamper with the data to the specified value; Tamper with the amount and change the target value to a random value within the specified range; Tamper with the enumeration and change the target value to a non-current value within the valid range of the enumeration; Splice dirty data and add a specified string after the original value; Boolean negation, inverts the original value.

9. The asset loss vulnerability detection method according to claim 8, characterized in that: When monitoring the business system's data damage alarm message, the x_trace_id is used for correlation to determine whether there is a data damage alarm message for the x_trace_id. If so, it means that the business-side system has deployed monitoring for the data damage field data tampering of the user traffic and can discover it immediately, and it is not recorded as a data damage vulnerability. If there is no corresponding alarm message for the user traffic data corresponding to the x_trace_id, it means that the data damage field data tampering of the user traffic has not been effectively monitored and deployed, and it is recorded as a data damage vulnerability.

10. A data loss vulnerability detection system, used to implement the data loss vulnerability detection method according to claim 1, characterized in that: include: A marking module is used to mark the data loss fields of the business system, wherein the data loss fields represent the database table fields in the MySQL database where the business system data is stored and which may cause data loss; An identification module, used to identify traffic inlets that have changed all marked loss fields using link data; The recording module is used to record and store the request data initiated by users for identified and marked traffic entrances in the online environment; The playback module is used to replay traffic data in an offline environment based on recorded online user request data to isolate the real online user data and avoid impact; The tampering module is used to initiate an interface call to all marked traffic entries based on the online user traffic playback operation. When the interface call initiates a change to the marked asset-damaged field, the changed data of the marked asset-damaged field is tampered with; The verification module is used to verify data damage through the business system after data tampering. If there is any inconsistency in the verification, an alarm message will be triggered; The monitoring module is used to record all replayed user traffic data and monitor the triggered asset loss alarm information.

Images