A method and system for detecting asset loss vulnerabilities

Abstract

This invention discloses a method and system for detecting asset loss vulnerabilities, belonging to the field of asset loss vulnerability detection technology. The method includes: identifying all user operation entry points based on labeled asset loss fields; generating automated test cases through online traffic recording, covering all combinations of operations on asset loss fields; and verifying the coverage of asset loss point defenses and discovering undefended asset loss vulnerabilities by replaying the automated test cases and modifying real data. This invention solves the problems of insufficient asset loss coverage and the inefficiency of manually compiling and writing test cases for asset loss vulnerability detection.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of capital loss vulnerability detection, in particular to a capital loss vulnerability detection method and system. BACKGROUND

[0002] With the rapid development of Internet business, the complexity of capital flow is increasing with the rapid development of business. The current industry capital loss prevention construction mainly relies on manual periodic analysis of capital loss scenarios to miss risk points, and conducts capital loss defense against the missed risk points found by manual analysis. In the face of the problem that relying on manual analysis cannot guarantee coverage, and incremental capital loss points cannot be covered in time, many companies in the industry have begun to explore capital loss attack and defense systems and rely on capital loss attack and defense to detect existing capital loss point vulnerabilities in real time. For capital loss vulnerability detection, each company is currently in the exploration and construction stage. The two main mature solutions are capital loss vulnerability detection based on rules and capital loss vulnerability detection based on capital loss fields, wherein one solution is capital loss vulnerability detection based on rules, as shown in Figure 1 The data for capital loss vulnerability detection based on rules is derived from the replication of online production environment data, which is relatively real. The data of the entire simulation and production environment is isolated, so it is lossless simulation. The solution mainly replicates online data for playback, tamper with online data to simulate the effectiveness of defense rules. Production data is mainly derived from Binlog or MQ messages on the line. The goal of the solution is to verify the effectiveness of the rules that have been deployed, but it cannot detect the coverage of capital loss, and the rule completeness is based on continuous manual business analysis to improve, which cannot be done without missing and cannot accurately assess the points that may be missed. As shown in Figure 2 Another solution is capital loss vulnerability detection based on tampered fields, which ensures the coverage of capital loss attacks by analyzing all capital loss fields. The solution attacks the business scenario by manually analyzing the business scenario to attack the capital loss field. The attack point is moved from the verification layer to the data source layer, and all verifications associated with the data table are indirectly executed in batches to decouple the attack and verification, ensure the objectivity of the simulation, and greatly improve the breadth and depth of the verification coverage. This solution also requires continuous business analysis, and the coverage cannot be effectively verified. SUMMARY

[0003] In view of the problems of relying on a large amount of manual analysis and the inability to check the coverage of the current solutions in the industry, the purpose of the present application is to provide a capital loss vulnerability detection technology to solve the problems of insufficient capital loss coverage and low efficiency of manual analysis and case detection.

[0004] In order to achieve the above technical purpose, the present application provides a capital loss vulnerability detection method, comprising the following steps:

[0005] Annotate the loss field of the business system, wherein the loss field represents the database table field in which the business system data stored in the MySQL database may cause the loss to occur;

[0006] With the link data, identify the traffic entry that changes all the annotated loss fields;

[0007] In an online environment, record and store the request data of the user initiated to the identified traffic entry;

[0008] According to the recorded online user request data, perform traffic data playback in an offline environment to isolate the real data of the online user and avoid the impact;

[0009] According to the online user traffic playback operation, initiate an interface call to all the identified traffic entries, and when the interface call initiates a change to the annotated loss field, tamper with the change data of the annotated loss field;

[0010] After tampering with the data, verify the loss through the business system, and when the loss verification is inconsistent, trigger a loss alarm information;

[0011] Record all the played back user traffic data and listen to the triggered loss alarm information.

[0012] Preferably, after annotating the loss field of the business system, incrementally annotate the newly added business database table field in the subsequent business requirement development process to ensure the coverage of the annotated loss field.

[0013] Preferably, when identifying the traffic entry that changes all the annotated loss fields, the link of all loss field changes is obtained at regular intervals, and the link is recursively searched based on the parent ID until the source link is found, the traffic entry information of the source link is analyzed, and the specific steps include:

[0014] a. Process the loss field according to the format of cluster-database-table-field;

[0015] b. According to the loss field information annotated by the user, group by database, calculate the link of the application according to the application information of the database connection, sample 100 links according to the SQL template dimension, parse the SQL information of the link into cluster-database-table-field-read-write type, and match with the annotated loss field information;

[0016] c. For the link that can be matched in step b, query the link source, record the traffic entry, the application that executes the SQL, and the loss field, and summarize the association relationship between the traffic entry and the loss field;

[0017] d. For the identified traffic entry that is a new entry, record the traffic entry information; for the identified traffic entry that is a historical entry that has been recorded, discard and do not record again.

[0018] Preferably, when recording and storing the request data initiated by the user for the identified annotated traffic entry, all traffic entries and the downstream full-link data of the traffic entry are recorded and stored, wherein the recorded and stored data includes the entry parameter information, the exit parameter information and the request header information of the traffic entry.

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

[0020] Preferably, when performing traffic playback, a unique traffic ID marker is generated for each piece of traffic data through traffic playback, and is transmitted to the downstream sub-link through a specific field x_trace_id, which is used to associate the traffic entry data according to the ID when verifying the final business side loss; wherein traffic playback means simulating the user's call to the traffic entry in an offline environment, and the entry parameter information is the entry parameter information of the recorded online real user traffic entry.

[0021] Preferably, when performing traffic playback, if it is an Http interface type traffic entry, an Http interface request is simulated, and the request header and the 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 generated unique traffic ID marker.

[0022] If it is a timing task type traffic entry, on the premise of recording the task parameters, the playback traffic is performed in sequence based on the recorded traffic entry sequence.

[0023] When executing the timing task, a unique traffic ID marker is added to the execution link and transmitted to the downstream.

[0024] Preferably, when performing data tampering, the execution request of the SQL is intercepted, the SQL is matched according to the configured tampering conditions and tampering parameters, after matching, the data replacement is performed according to the tampering parameters, and finally the SQL is executed, wherein the data tampering is performed by one or more of the following methods, including:

[0025] Replace the specified value, and directly tamper the data to the specified value;

[0026] Tamper the amount, and tamper the target value to a random value within a specified range;

[0027] Tamper the enumeration, and tamper the target value to a non-current value within the valid range of enumeration;

[0028] Splice dirty data, splice a specified string after the original value;

[0029] Boolean negation, the original value is negated.

[0030] Preferably, when listening to the service system asset loss alarm message, whether there is the asset loss alarm message of the x_trace_id is judged through the x_trace_id, if yes, it indicates that the asset loss field data tampering of the service side system to the user traffic is monitored and can be found at the first time, and is not recorded as an asset loss vulnerability; if there is no corresponding alarm message corresponding to the user traffic data of the x_trace_id, it indicates that the asset loss field data tampering of the user traffic is not effectively monitored, and is recorded as an asset loss vulnerability.

[0031] The application also provides an asset loss vulnerability detection system for realizing the asset loss vulnerability detection method.

[0032] The labeling module is used for labeling the asset loss field of the business system, wherein the asset loss field represents a database table field of the business system data stored in the MySQL database, which can cause asset loss to occur.

[0033] The identification module is used for identifying the traffic entry for changing all the labeled asset loss fields by means of link data.

[0034] The recording module is used for recording and storing the request data of the user for the identified traffic entry in an online environment.

[0035] The playback module is used for playing back the traffic data 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.

[0036] The tampering module is used for initiating the interface call to all the labeled traffic entries according to the online user traffic playback operation, and tampering with the change data of the labeled asset loss field when the interface call initiates the change to the labeled asset loss field.

[0037] The verification module is used for verifying the asset loss through the business system after the data tampering, and triggering the asset loss alarm information when the asset loss verification is inconsistent.

[0038] The listening module is used for recording all the played back user traffic data and listening to the triggered asset loss alarm information.

[0039] The application discloses the following technical effects:

[0040] The application is based on online real, large and continuous user request full-link data and labeled asset loss field, finds all asset loss traffic entrances based on link tracking data, and guarantees all traffic entrance coverage of asset loss field changes. Through online large, real and continuous user request traffic data recording playback, each asset loss field has comprehensive use case coverage, which guarantees that the asset loss detection coverage can be improved through use case data tampering to trigger business system asset loss defense alarm.

[0041] The application supports continuous drilling through automatic online traffic recording playback, without relying on a large number of manual operations to improve efficiency. DETAILED DESCRIPTION

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0043] Figure 1 is an execution logic diagram of the rule-based asset loss vulnerability detection described in the background art of the present application;

[0044] Figure 2 is an execution logic diagram of the asset loss vulnerability detection based on tampered fields described in the background art of the present application;

[0045] Figure 3 is a method principle diagram described in the present application;

[0046] Figure 4 is a method flow diagram described in the present application. DETAILED DESCRIPTION

[0047] In order to make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, not all embodiments. The components of the embodiments of the present application described and shown in the drawings herein 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 claimed present application, but only represents 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 creative labor are within the scope of protection of the present application.

[0048] As Figures 3-4As shown, the present application provides a capital loss vulnerability detection technology, specifically including the following processes:

[0049] Step S10: First, the capital loss field of the business system is labeled. The capital loss field refers to the database table field in which the business system data is stored in the MySQL database, which may cause capital loss to occur, such as the down payment amount field, the freight amount field, the down payment refund field, etc. in the business system. After the first full business capital loss field labeling, in the subsequent business requirement development process, by adding a process step in the technical scheme review environment, incremental labeling is performed on the newly added business database table field to ensure the coverage of the capital loss field labeling.

[0050] Step S20: Based on all the capital loss fields labeled in step S10, all traffic entries that change these capital loss fields are identified with the link data stored in the full-link tracking system and stored in a separate storage medium. The key point that needs to be solved in this step is how to identify all traffic entries that change the marked capital loss fields as completely as possible. The full-link tracking system is a system that records the full-link information of all traffic entries from the request initiation to the final update of the database field, including the parameter information, output parameter information, request header information, etc. of each traffic entry.

[0051] The key to implementing full-link tracking is that the full-link tracking system generates a globally unique full-link ID: trace_id for each piece of data of each traffic entry when reporting link data on each traffic entry, and carries the trace_id to the downstream as the parent link ID: parent_trace_id of the downstream link when calling the downstream, and recursively finds all child links and grandchild links under the trace_id until the end link through the trace_id of the traffic entry. The traffic entry includes various Http interfaces initiated by the user from the App or Web end, and the timing scheduling task inside the system. The specific operation mode of identifying the traffic entry that changes the capital loss field is to find all links that change the capital loss field within the last 24 hours every day, and recursively find the source link based on the parent ID (parent_trace_id) of the link until the source link is found, and analyze the traffic entry information of the source link, the steps are as follows:

[0052] a. Process the capital loss field according to the cluster-database-table-field format;

[0053] b. According to the user-labeled capital loss field information, group by database, calculate the link of the application according to the application information connected by the database, sample 100 links according to the SQL template dimension, parse the SQL information of the link into cluster-database-table-field-read-write type, and match with the labeled capital loss field information;

[0054] c. Matched link, query link source, record traffic entry, execute SQL application and capital loss field, and summarize the association between traffic entry and capital loss field.

[0055] d. For the identified traffic entry that is a new entry, record and store the traffic entry information; for the identified traffic entry that is a historical record, discard and do not record repeatedly. Through the automatic timing of the program every day, the identification record of the capital loss field traffic entry is continuously improved, all the traffic entries of the capital loss field are changed, and the coverage of the capital loss field traffic entry identification is finally approached to 100%.

[0056] Step S30: Based on all the traffic entries identified in step S20, the online environment records and stores the request data of all the traffic entries initiated by the user. The reason for recording the user request data in the online environment is to isolate the influence on the real request data of the online user in the subsequent data playback tampering and checking in the QA (offline) environment. In the real business scenario and micro-service system architecture, after the user initiates a request at the traffic entry, subsequent calls between multiple levels of services will be generated, each call will generate a multi-level sub-link under the traffic entry.

[0057] In order to ensure that the multi-level sub-link under the traffic entry can be completely played back in series and the capital loss field can be finally modified when playing back in the QA (offline) environment, all traffic entries and downstream full-link data of the traffic entry also need to be recorded and stored during traffic recording.

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

[0059] Traffic recording is performed by system configuration, including configuration of the entry interface for traffic recording, recording time period, storage duration of recorded data, etc. Considering the pressure on the online system, when recording the online user traffic, the user ID tail number can be used for hash sampling recording and storage. After the system is configured and started, automatic recording and storage of the traffic entry are realized. Through continuous recording and storage of online user traffic, the coverage of capital loss field change scenarios under different business scenarios, gray user groups or branch conditions for each traffic entry is continuously improved.

[0060] Step S40: Based on the online user request data recorded in step S30, the traffic data is played back in the QA (offline) environment to isolate the real data of the online user and avoid the influence. Traffic data playback refers to simulating the user's call to the traffic entry in the QA environment, and the input parameter information is the input parameter information of the online real user traffic entry recorded and stored.

[0061] The flow data playback will actually initiate interface calls, MQ message sending, and timing task execution in the QA environment, thereby triggering interface calls of the full link of the flow entrance, and finally triggering changes to the loss field related to the flow entrance.

[0062] The flow data playback has different implementation manners according to different flow entrances, but a unique flow ID mark is generated for each piece of flow data during flow playback, and is transmitted to the downstream sub-link through a specific field (x_trace_id), which is used to associate the flow entrance data according to the ID during final business-side loss checking and verification. If the flow 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 flow ID mark. If the flow entrance is a timing task, the flow is played back in order based on the flow entrance order recorded during step S30 on the premise of recording the task parameters. The execution link is marked with a unique flow ID mark during the execution of the timing task, and is transmitted to the downstream.

[0063] Step S50: Based on the online user flow playback operation of step S40, interface calls to all marked flow entrances are initiated, and when the interface call changes the marked loss field, the change data of the marked loss field is tampered with, for example, the freight field is changed to 1000, and 1000 is tampered with to 500.

[0064] The data tampering can be implemented in the following ways:

[0065] 1. Replace the specified value, and directly tamper the data with the specified value;

[0066] 2. Tamper with the amount, and tamper the target value with a random value in the specified range;

[0067] 3. Tamper with the enumeration, and tamper the target value with other values (not the current value) in the enumeration valid range;

[0068] 4. Concatenate dirty data, concatenate a specified string after the original value;

[0069] 5. Boolean negation, negate the original value.

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

[0071] The technical solution of tampering with data is achieved by intercepting the execution request of SQL, matching the SQL according to the tampering condition and tampering parameter configured during the attack, replacing the data according to the tampering parameter after matching, and finally executing the SQL.

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

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

[0074] Step S70: Based on the user traffic playback in step S50 and the tampering of the capital loss field change, and the capital loss checking and verification logic of the business system in step S60, all the playback user traffic data is recorded, and the business system capital loss alarm message sent in step S60 is listened to. Through x_trace_id, it is determined whether there is a capital loss alarm message of the x_trace_id. If there is, it means that the capital loss field data tampering of the user traffic by the business side system is monitored and can be discovered at the first time, and is not recorded as a capital loss vulnerability. If there is no corresponding alarm message corresponding to the user traffic data of the corresponding x_trace_id, it means that the capital loss field data tampering of the user traffic is not effectively monitored, and is recorded as a capital loss vulnerability.

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

[0076] In order to realize the above method process, the present application also designs a capital loss vulnerability detection system, comprising:

[0077] The annotation module is used for annotating the capital loss field of the business system, wherein the capital loss field represents the database table field of the business system data stored in the MySQL database, which may cause the occurrence of capital loss.

[0078] An identification module is configured to identify, by means of the link data, a traffic entry that changes all the marked loss fields;

[0079] A recording module is configured to record and store, in an online environment, user-initiated request data for the identified marked traffic entry;

[0080] A playback module is configured to play back, in an offline environment, traffic data according to the recorded online user request data, so as to isolate the online user real data and avoid affecting the online user real data;

[0081] A tampering module is configured to initiate an interface call for all the marked traffic entries according to the online user traffic playback operation, and tamper with the change data of the marked loss field when the interface call initiates a change to the marked loss field;

[0082] A verification module is configured to perform loss checking and verification through a business system after the data tampering, and trigger a loss alarm information when the loss checking and verification is inconsistent;

[0083] A monitoring module is configured to record all the played back user traffic data and monitor the triggered loss alarm information.

[0084] The present application is described with reference to flowcharts and / or block diagrams of the method, device (system) and computer program product according to embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows 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 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 computer or other programmable data processing device produce a device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in one flow or multiple flows and / or blocks Figure 1 The functions specified in one flow or multiple flows and / or blocks

[0085] In the description of the present application, it should be understood that the terms "first", "second" are only used for description purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first", "second" can explicitly or implicitly include one or more of the features. In the description of the present application, the meaning of "multiple" is two or more, unless otherwise specifically limited.

[0086] Obviously, many modifications and variations of the present application are possible in light of the above teachings. It is, therefore, to be understood that within the scope of the appended claims and their equivalents, the application can be practiced otherwise than as specifically described.

Claims

1. A method of detecting a cyber vulnerability, the method comprising: The method comprises the following steps: annotating a loss field of a business system, wherein the loss field represents a database table field in which business system data is stored in a MySQL database and which may cause a loss to occur; identifying a traffic entry that changes all the annotated loss fields by means of link data; recording and storing request data of a user for the identified traffic entry in an online environment; playing back traffic data in an offline environment according to the recorded online user request data to isolate real online user data and avoid affecting the online environment; initiating an interface call to all the identified traffic entries according to the online user traffic playback operation, and tampering with change data of the annotated loss field when the interface call initiates a change to the annotated loss field; after the data tampering, performing loss checking and verification through the business system, and triggering a loss alarm when the loss checking and verification do not match; recording all the played back user traffic data and monitoring the triggered loss alarm; when the traffic entry that changes all the annotated loss fields is identified, the link of all the loss field changes is obtained at regular intervals, and the link of the source is found recursively based on the parent ID of the link until the source link is found, the traffic entry information of the source link is analyzed, and the method comprises the following steps: a. processing the loss field according to the format of cluster-database-table-field; b. grouping the loss field information annotated by the user according to the database, calculating the link of the application according to the application information connected by the database, sampling 100 links according to the SQL template dimension, parsing the SQL information of the link into cluster-database-table-field-read-write type, and matching the annotated loss field information; c. for the link that can be matched in step b, querying the link source, recording the traffic entry, the application that executes the SQL, and the loss field, and summarizing the association between the traffic entry and the loss field; d. if the identified traffic entry is a new entry, record and store the traffic entry information; if the identified traffic entry is a historical entry that has been recorded and stored, discard it and do not record it again; when the request data of the user for the identified traffic entry is recorded and stored, all the traffic entries and the downstream full-link data of the traffic entries are recorded and stored, wherein the recorded and stored data includes the parameter information, the response information and the request header information of the traffic entry; when the recording and storing is performed, the user ID tail number is hashed and sampled for recording and storing; when the traffic playback is performed, a unique traffic ID is generated for each traffic data by the traffic playback, and is transmitted to the downstream sub-link through a specific field x_trace_id, which is used to associate the ID to the traffic data during the final business side loss checking and verification; wherein the traffic playback represents simulating the user's call to the traffic entry in the offline environment, and the parameter information is the parameter information of the online real user traffic entry recorded and stored.

2. The loss vulnerability detection method of claim 1, wherein: After the capital loss field of the business system is labeled, the newly added business database table field is incrementally labeled in the subsequent business requirement development process to ensure the coverage of the capital loss field labeling.

3. The capital loss vulnerability detection method of claim 1, wherein: When the traffic playback is performed, if the traffic entry is an Http interface type, an Http interface request is simulated, and the request header and request parameter are replaced with the recorded request header and request parameter of the Http interface, and an x_trace_id field is added to the request header, and the field data is the generated unique traffic ID mark; If the traffic entry is a timing task type, based on the recorded traffic entry sequence during recording, the playback traffic is performed in sequence on the premise of recording task parameters; When the timing task is executed, the execution link is marked with a unique traffic ID mark, which is transmitted to the downstream.

4. The capital loss vulnerability detection method of claim 3, wherein: When data tampering is performed, the execution request of the SQL is intercepted, the SQL is matched according to the tampering condition and the tampering parameter, the data replacement is performed according to the tampering parameter after the matching, 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, directly tamper the data to the specified value; tamper the amount, tamper the target value to a random value within a specified range; tamper the enumeration, tamper the target value to a non-current value within the enumeration valid range; concatenate dirty data, concatenate a specified string after the original value; Boolean negation, the original value is negated.

5. The capital loss vulnerability detection method of claim 4, wherein: When the business system capital loss alarm message is monitored, the x_trace_id is used for association to determine whether there is a capital loss alarm message of the x_trace_id, if there is, it means that the capital 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 capital loss vulnerability; if there is no corresponding alarm message corresponding to the x_trace_id of the user traffic data, it means that the capital loss field data tampering of the user traffic is not effectively monitored, and is recorded as a capital loss vulnerability.

6. A system for detecting a vulnerability for a cyber attack, for implementing a method for detecting a vulnerability for a cyber attack according to claim 1, characterized in that, including: a labeling module configured to label a capital loss field of a business system, wherein the capital loss field represents a database table field of the business system data stored in a MySQL database, which may cause capital loss to occur; an identification module configured to identify, by means of link data, a traffic entry that changes all the labeled capital loss fields; a recording module configured to record and store, in an online environment, request data of the identified traffic entry initiated by a user; a playback module 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 affecting the real data; a tampering module configured to initiate an interface call to all the labeled traffic entries according to the online user traffic playback operation, and tamper the changed data of the labeled capital loss fields when the interface call changes the labeled capital loss fields. The verification module is configured to perform capital loss checking and verification through the business system after data tampering, and trigger capital loss alarm information when the capital loss checking and verification is inconsistent. The listening module is configured to record all the played back user traffic data and listen to the triggered capital loss alarm information.

Images