A method and apparatus for restoring call paths

Abstract

This application provides a method and apparatus for restoring call paths, applicable to the field of computer technology. In this method, a server receives, sequentially from a terminal device, the tracking information of multiple front-end events triggered in a front-end application. Then, for each front-end event, if it is a critical event, a tracking identifier is generated based on the tracking information. Additionally, a critical backend interface call is triggered, and backend logs associated with the critical backend interface call are recorded. The tracking identifier and backend logs are merged into a backend event node corresponding to the front-end event. Thus, based on the tracking information of multiple front-end events and the backend event nodes corresponding to critical events among them, the entire front-end and back-end interaction path can be restored, improving the completeness of call path restoration, correspondingly improving the accuracy of attack detection, and helping to accurately locate and resolve the location of attack behavior, optimizing system performance, and improving system stability.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and apparatus for restoring call paths. Background Technology

[0002] In the field of computer security technology, individuals often exploit security and logical vulnerabilities in front-end applications with transaction functions to attack various aspects of the business (such as tampering with amounts or stealing funds), causing losses to users and businesses.

[0003] The aforementioned attack methods, especially those based on logical vulnerabilities, typically lack obvious attack characteristics. Therefore, relevant technical measures are used to have business operations personnel extract useful information by combining it with backend logs, and then use this information to reconstruct the call paths and investigate security threats.

[0004] However, when sorting out data, the focus is on analyzing backend logs. The data obtained is often isolated. This isolated data lacks specific analysis of user behavior and makes it difficult to fully reconstruct the overall call path, thus affecting the accuracy of attack detection. Summary of the Invention

[0005] This application provides a method and apparatus for restoring call paths, which is used to fully restore the overall call path and improve the accuracy of attack detection.

[0006] On one hand, embodiments of this application provide a method for restoring call paths, applied to a server, the method comprising:

[0007] Receive the event tracking information of multiple front-end events triggered in the front-end application, which are sent sequentially by the terminal device.

[0008] For each front-end event, perform the following operations: if the front-end event is a critical event, generate a tracking identifier for the front-end event based on the event's event tracking information; and trigger a critical back-end interface call and record the back-end log associated with the critical back-end interface call; merge the tracking identifier and the back-end log into a back-end event node corresponding to the front-end event.

[0009] Based on the tracking information of the multiple front-end events and the back-end event nodes corresponding to the key events in the multiple front-end events, the target call path is restored.

[0010] On one hand, embodiments of this application provide a call path restoration device applied to a server, the device comprising:

[0011] The receiving module is used to receive the tracking information of multiple front-end events triggered in the front-end application, which are sent sequentially by the terminal device.

[0012] The processing module is used to perform the following operations for each front-end event: if the front-end event is a critical event, generate a tracking identifier for the front-end event based on the event's tracking information; trigger a back-end critical interface call and record the back-end log associated with the back-end critical interface call; and merge the tracking identifier and the back-end log into a back-end event node corresponding to the front-end event.

[0013] Optionally, the processing module is also used for:

[0014] After merging the tracking identifier and the background log into the background event node corresponding to the front-end event, the front-end event latency is determined based on the timestamp in the front-end event's event tracking information and the time when the key back-end interface is triggered.

[0015] If the front-end event latency exceeds a preset server latency threshold, an alarm event is generated.

[0016] Optionally, the processing module is specifically used for:

[0017] Upon receiving a service request packet from the terminal device, a critical backend interface call is triggered;

[0018] If there are front-end events and tracking identifiers associated with the business request package, then a business response package corresponding to the business request package is generated;

[0019] The request time of the business request packet, the business request packet, and the business response packet are recorded as background logs associated with the background key interface call.

[0020] Optionally, the processing module is also used for:

[0021] If no front-end event and tracing identifier are associated with the business request packet, an alarm event is generated.

[0022] Optionally, the processing module is specifically used for:

[0023] If there are front-end events and tracking identifiers associated with the business request package, the front-end event latency is determined based on the timestamp in the event's tracking information and the time when the backend key interface call is triggered.

[0024] If the front-end event latency is less than or equal to the preset server latency threshold, then a business response packet corresponding to the business request packet is generated.

[0025] Optionally, the processing module is also used for:

[0026] If there are front-end events and tracking identifiers associated with the business request package, the front-end event latency is determined based on the timestamp in the event's tracking information and the time when the backend key interface call is triggered.

[0027] If the front-end event latency exceeds a preset server latency threshold, an alarm event is generated.

[0028] Optionally, the processing module is also used for:

[0029] After merging the tracking identifier with the background log into the background event node corresponding to the front-end event, the tracking identifier is marked as invalid.

[0030] The restore module is used to restore the target call path based on the tracking information of the multiple front-end events and the back-end event nodes corresponding to the key events in the multiple front-end events.

[0031] Optionally, the restore module is specifically used for:

[0032] Based on the tracking information of the multiple front-end events, a front-end call path is constructed, wherein the tracking information of each front-end event is a front-end event node in the front-end call path;

[0033] For each key event among the multiple front-end events, based on the front-end event node corresponding to the key event in the front-end call path, the corresponding back-end event node is added to obtain the target call path.

[0034] Optionally, the restore module is also used for:

[0035] After reconstructing the target call path based on the tracking information of the multiple front-end events and the back-end event nodes corresponding to the key events in the multiple front-end events, logical vulnerabilities in the front-end application are detected based on the target call path.

[0036] On one hand, embodiments of this application provide a computer device, including:

[0037] Memory, used to store program instructions;

[0038] The processor is used to call the program instructions stored in the memory and execute the steps of the above-mentioned call path restoration method according to the obtained program.

[0039] On one hand, embodiments of this application provide a computer-readable storage medium including computer-readable instructions, which, when read and executed by a computer, cause the computer to perform the steps of the above-described call path restoration method.

[0040] On one hand, embodiments of this application provide a computer program product, including a computer program stored on a computer-readable storage medium, the computer program including program instructions, which, when executed by a computer device, cause the computer device to perform the steps of the above-described call path restoration method.

[0041] In this embodiment, by associating front-end events with tracking identifiers and business request packets and determining the latency of front-end events, the difference between the latency in the previous period and the preset server latency threshold is judged, quickly locating attack behaviors targeting security vulnerabilities and generating alarm events. In addition, this application is not limited to security issues caused by security vulnerabilities. By obtaining the front-end call path and associating and adding back-end event nodes corresponding to key events based on the front-end event nodes corresponding to key events, the front-end and back-end interaction paths are clarified, the target call path is restored, and combined with attack characteristics, logical vulnerabilities in front-end applications are detected, maintaining user data security, which is conducive to protecting the system from various potential attacks and improving the system's robustness. Attached Figure Description

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

[0043] Figure 1 A system architecture diagram provided for an embodiment of the present invention;

[0044] Figure 2 A flowchart illustrating a method for restoring a call path provided in an embodiment of the present invention;

[0045] Figure 3 A schematic diagram of a target call path provided in an embodiment of the present invention;

[0046] Figure 4 A flowchart illustrating a method for restoring a call path provided in an embodiment of the present invention;

[0047] Figure 5 This is a schematic diagram of a call path restoration device provided in an embodiment of the present invention;

[0048] Figure 6 This is a schematic diagram of a computer device structure provided in an embodiment of the present invention. Detailed Implementation

[0049] To make the objectives, technical solutions, and beneficial effects of this application 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 application.

[0050] For ease of understanding, the terms used in the embodiments of this invention are explained below.

[0051] The following is a brief introduction to the system architecture diagram used in the technical solutions of this application. It should be noted that the system architecture diagram described below is only for illustrating the embodiments of this application and is not intended to limit the scope of the application.

[0052] refer to Figure 1 This is a system architecture diagram applicable to embodiments of this application. The system architecture includes at least a terminal device 101 and a server 102. The terminal device 101 is pre-installed with a front-end application with transaction functions. The terminal device 101 can be a smartphone, smartwatch, tablet, laptop, etc., but is not limited to these.

[0053] Server 102 is the backend server for the frontend application. It can record the logs generated by the frontend application to the local file system or a remote log server for collecting, storing and managing backend logs.

[0054] Server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms, but it is not limited to these.

[0055] The method in this embodiment can be interactively executed by terminal device 101 and server 102. In this embodiment, terminal device 101 and server 102 can communicate directly or indirectly through one or more networks. This network can be a wired network or a wireless network; for example, a wireless network can be a mobile cellular network or a Wireless-Fidelity (WIFI) network, or other possible networks. This embodiment does not limit the types of networks used.

[0056] The following is based on Figure 1 The system architecture shown in this application provides a flowchart of a method for restoring a call path, as illustrated in this embodiment. Figure 2 As shown, the process of this method is executed by the server and includes the following steps:

[0057] Step 201: Receive the event tracking information of multiple front-end events triggered in the front-end application, which are sent sequentially by the terminal device.

[0058] Specifically, front-end events refer to various interactive actions that occur on the user interface of a front-end application, such as clicking a button, entering text, moving the mouse, etc. Corresponding front-end tracking points can be set for each front-end event.

[0059] The tracking information for front-end events includes: timestamp, device attributes, user attributes, event attributes, channel attributes, and an end flag. Device attributes include terminal device ID, terminal device model, IP address, network status, etc.; user attributes include user ID, user type, etc.; event attributes include action type, such as browsing, input, click, etc.; channel attributes include channel parameters, such as third-party APP, mini-program, etc.; the end flag is used to indicate whether the front-end tracking is the end of its tracking period.

[0060] Specifically, the event tracking information is transmitted to the server after being encrypted with a public key.

[0061] Step 202: For each front-end event, execute the following steps 2021-2023 respectively:

[0062] Step 2021: If the front-end event is a critical event, then generate a tracking identifier for the front-end event based on the event's event tracking information.

[0063] Specifically, multiple front-end events include critical events and non-critical events. Critical events are those that can trigger calls to critical backend interfaces, while non-critical events are those that cannot. A front-end event tracking identifier is a unique identifier that allows tracking and associating front-end events. Through the tracking identifier, the call path of the front-end event can be constructed.

[0064] For example, in a front-end application with shopping functionality, the front-end event of a user browsing a product page is not considered a critical event; however, the front-end event of a user clicking to make a payment is a critical event that can trigger key back-end API calls.

[0065] Step 2022: Trigger the call to the key backend interface and record the backend log associated with the call to the key backend interface.

[0066] Specifically, critical backend interfaces refer to the Application Programming Interfaces (APIs) on the server used to respond to important business requests from the frontend application. They provide the core functions and services of the frontend application and are frequently called during its use. The stability of critical backend interfaces affects the overall stability and reliability of the system. For example, when a payment click event is triggered in a frontend application with shopping functionality, the server's payment-related APIs will be called to implement the payment function.

[0067] In some embodiments, after triggering a critical backend interface call and recording the associated backend logs, the frontend event latency is determined based on the timestamp in the frontend event's event tracking information and the time the critical backend interface call was triggered. If the frontend event latency exceeds a preset server latency threshold, an alarm event is generated.

[0068] Specifically, if the front-end event latency exceeds the preset server latency threshold, it indicates a potential situation where an attacker intercepts business request packets, tampers with the data, and resends the packets (i.e., a replay attack risk). This causes a delay in triggering critical backend interface calls (i.e., increased front-end event latency), thus requiring the generation of an alarm event. If the front-end event latency is less than or equal to the preset server latency threshold, it can be considered safe, and no alarm event needs to be generated.

[0069] For example, in a front-end application with payment functionality, when a user clicks to make a payment, the terminal device sends front-end event tracking information to the server. The server generates a tracking identifier for the front-end event based on this tracking information and sends a business request packet. An attacker intercepts the business request packet, alters the payment amount within it, and resends it to the server. Upon receiving the business request packet (i.e., triggering a critical backend interface call), the server records the backend log related to the call and determines the front-end event latency based on the timestamp in the front-end event tracking information and the time the critical backend interface call was triggered. Because the business request packet was intercepted and the payment amount was altered, the front-end event latency exceeds the preset server latency threshold, thus generating an alarm event.

[0070] In this embodiment of the application, judging whether the front-end event delay has timed out enables the system to investigate attack behavior more efficiently, protects user data security, and improves system stability.

[0071] In some embodiments, when the server receives a service request packet sent by the terminal device, it triggers a background key interface call; if there are front-end events and tracking identifiers associated with the service request packet, it generates a service response packet corresponding to the service request packet; the request time of the service request packet, the service request packet, and the service response packet are recorded as background logs associated with the background key interface call.

[0072] When the server receives a business request packet sent by the terminal device, it triggers a critical backend interface call; if there is no frontend event or tracing identifier associated with the business request packet, an alarm event is generated.

[0073] Specifically, if the server receives a business request packet from a terminal device and triggers a critical backend interface call, but there is no frontend event or tracking identifier associated with the business request packet, it indicates that the critical backend interface call does not match the frontend event, which may pose a risk of direct packet sending or replay attacks.

[0074] Direct packet sending and replay attacks both target security vulnerabilities. In a normal system, users must interact with the front-end to send valid business request packets. Direct packet sending attempts to bypass this interaction step and send the request packets directly. Replay attacks involve attackers intercepting and resending previously intercepted business request packets to deceive the backend and gain unauthorized access. This type of attack can bypass user authentication, send malicious requests, or steal sensitive information, posing a threat to system security. Therefore, when direct packet sending or replay attacks are detected, it is determined that the current critical backend interface call is abnormal, thus generating an alert event.

[0075] In this embodiment, if the business request packet received by the server does not have associated front-end events and tracking identifiers, an alarm event is generated. This enables real-time monitoring of attacks targeting security vulnerabilities, reducing potential damage, protecting user information, and minimizing data leakage or tampering. Compared to existing technologies that issue alarms after a certain number of failures, this approach can locate and issue alarms more quickly. Furthermore, it allows for measures to be taken before the attack spreads, protecting other parts of the system, preventing system interruptions, and maintaining the continuity of the entire business process.

[0076] In some embodiments, when the server receives a service request packet sent by a terminal device, it triggers a backend key interface call. If a frontend event and tracking identifier exist associated with the service request packet, the server determines the frontend event latency based on the timestamp in the frontend event's event tracking information and the time when the backend key interface call was triggered. If the frontend event latency is less than or equal to a preset server latency threshold, a service response packet corresponding to the service request packet is generated. If the frontend event latency is greater than the preset server latency threshold, an alarm event is generated.

[0077] Specifically, if the front-end event latency exceeds the preset server latency threshold, it indicates a potential situation where an attacker intercepts business request packets, tampers with the data, and resends them (i.e., a replay attack risk). This would cause a delay in triggering critical backend interface calls (i.e., increased front-end event latency), ultimately exceeding the preset server latency threshold. In this case, an alarm event can be generated without responding to the business request packet. If the front-end event latency is less than or equal to the preset server latency threshold, it can be considered safe, and a business request packet can be generated directly.

[0078] For example, when a user makes a payment in the front-end application, an attacker intercepts the current business request packet, modifies the payment amount, and then resends the business request packet to the server. The server determines the front-end event latency based on the timestamp in the corresponding front-end event's tracking information and the time the business request packet was received (i.e., the time the critical backend interface was triggered). If the front-end event latency exceeds a preset server latency threshold, the server considers the current critical backend interface call to be abnormal and generates an alarm event.

[0079] In this embodiment of the application, judging whether the front-end event delay has timed out enables the system to investigate attack behavior more efficiently, protects user data security, and improves system stability.

[0080] Step 2023: Merge the tracking identifier and the backend log into a backend event node corresponding to the frontend event.

[0081] In some embodiments, after merging the tracking identifier and the background log into a background event node corresponding to the front-end event, the tracking identifier is marked as invalid. Alternatively, the tracking identifier can be directly recorded in the background log, and the background log can be used as the background event node corresponding to the front-end event; this application does not specifically limit this approach.

[0082] In this embodiment, when the tracking identifier and the background log are merged into a background event node corresponding to the front-end event, they are marked as invalid. This avoids the background log data from being confused due to the tracking identifier being used multiple times, and also ensures the uniqueness of the tracking information, thereby improving the accuracy of attack behavior monitoring.

[0083] Step 203: Based on the tracking information of multiple front-end events and the back-end event nodes corresponding to the key events in the multiple front-end events, restore the target call path.

[0084] In this embodiment, the server receives the event tracking information of multiple front-end events triggered in the front-end application, sequentially sent by the terminal device. Then, for each front-end event, if it is a critical event, a tracking identifier is generated based on the event's tracking information. Additionally, a critical backend interface call is triggered, and backend logs associated with the call are recorded. The tracking identifier and backend logs are merged into a backend event node corresponding to the front-end event. Thus, based on the tracking information of multiple front-end events and the backend event nodes corresponding to critical events, the entire front-end and back-end interaction path (i.e., the target call path) can be reconstructed, improving the completeness of the call path reconstruction, thereby increasing the accuracy of attack detection. Furthermore, when an attack occurs, it helps to accurately locate and resolve the attack, improving user experience, optimizing system performance, and enhancing system stability.

[0085] In some embodiments, the server constructs a front-end call path based on the tracking information of multiple front-end events, wherein the tracking information of each front-end event is a front-end event node in the front-end call path; for each key event among the multiple front-end events, based on the front-end event node corresponding to the key event in the front-end call path, the corresponding back-end event node is added to obtain the target call path.

[0086] Specifically, the tools deployed on the server that can build front-end call paths can be Urchin Tracking Manager (UTM), which collects data on user access behavior and user behavior paths on the web or app; or Super Position Model (SPM), which is an identifier for locating content and can collect user behavior log data at specific locations on the interface on the web and app (i.e., front-end applications).

[0087] By using UTM or SPM to construct the front-end call path based on the tracking information of multiple front-end events, and then adding the corresponding back-end event nodes of key events on the front-end call path to obtain the target call path.

[0088] refer to Figure 3 In the payment scenario, event tracking points are set for each front-end event in the front-end application. The front-end events triggered in sequence in the front-end application are: "Mobile / Account Input" event, "Click to Get Verification Code" event, "Verification Code / Password Input" event, "Login Click" event, "Face Verification" event, "Product Page View" event, "Payment Click" event, "Payment Password / Face Verification" event, and "Transaction Success Page" event.

[0089] When each front-end event is triggered, the front-end application sends the encrypted event tracking information to the server. The tracking information corresponding to the following events is as follows: "Mobile Phone / Account Input" event 1, "Click to Get Verification Code" event 2, "Verification Code / Password Input" event 3, "Login Click Event" event 4, "Face Verification Event" event 5, "Product Page Browsing" event 6, "Payment Click" event 7, "Payment Password / Face Verification" event 8, and "Transaction Success Page" event 9.

[0090] The event tracking information for each front-end event includes: timestamp, device attributes, user attributes, event attributes, channel attributes, and end marker.

[0091] When a front-end event is a critical event, the server receives the business request packet for the critical event, triggers the critical API (i.e., the backend critical interface call), and then generates a tracking identifier for the critical event based on the event's tracking information. It also records the backend log associated with the critical API. The backend log includes the tracking identifier, the business request packet, and the business response packet. The tracking identifier and the backend log are then merged into the backend event node corresponding to the front-end event. For example, among the multiple front-end events described above, "Click to get verification code" is a critical event. After the server receives the business request packet for this critical event (i.e., request packet 1), it generates a tracking identifier 1 corresponding to the "Click to get verification code" event based on the tracking information 2 of the "Click to get verification code" event, triggers the corresponding critical API on the server, obtains the verification code, and then generates a business response packet (i.e., response packet 1) based on the verification code. Tracking identifier 1, request packet 1, and response packet 1 are recorded as the backend log of the critical API, and the obtained backend log is used as the backend event node corresponding to the "Click to get verification code" event.

[0092] It should be noted that among the various front-end events described above, the "login click event," "face verification event," "payment click," and "payment password / face verification" are also key events. For these key events, the back-end event nodes can also be obtained using the methods described above, which will not be repeated here. Of course, the event tracking information differs for different front-end events, and the tracking identifiers corresponding to different key events also differ.

[0093] Finally, the tracking information of each front-end event is treated as a front-end event node. These multiple front-end event nodes are then concatenated sequentially according to their respective timestamps to obtain the front-end call path. For each key event corresponding to a front-end event node in the front-end call path, this front-end event node is connected to its associated back-end event node to obtain the target call path.

[0094] In some embodiments, the server reconstructs the target call path based on the tracking information of multiple front-end events and the background time nodes corresponding to key events in the multiple front-end events, and then detects logical vulnerabilities in the front-end application based on the target call path.

[0095] In this embodiment, combining front-end events and back-end events to form a front-end and back-end interaction path helps to analyze user behavior more comprehensively, effectively defend against complex attacks, and improve the stability and reliability of the system.

[0096] To better explain the embodiments of this application, the following describes a method for restoring a call path provided by the embodiments of this application, using an attack detection scenario as an example. The process of this method is as follows: Figure 1 The server execution shown includes the following steps, such as: Figure 4 As shown:

[0097] Step 401: The server receives the tracking information of multiple front-end events triggered in the front-end application, which are sent sequentially by the terminal device.

[0098] Step 402: For each front-end event, execute the following steps 4021-4027 respectively.

[0099] Specifically, steps 4021-4027 can be executed for each front-end event whose event tracking information is received, or steps 4021-4027 can be executed for each front-end event after receiving event tracking information for multiple front-end events. This application does not make any specific limitations on this.

[0100] Step 4021: If the front-end event is a critical event, then generate a tracking identifier for the front-end event based on the event's event tracking information.

[0101] Step 4022: When a service request packet is received from the terminal device, a key backend interface call is triggered.

[0102] Step 4023: Determine whether there are any front-end events and tracking identifiers associated with the business request package. If they exist, proceed to step 4024; otherwise, proceed to step 4027.

[0103] Step 4024: Record the request time, business request packet, and business response packet of the business request packet as background logs associated with the backend key interface calls.

[0104] Step 4025: Determine the front-end event latency based on the timestamp in the front-end event tracking information and the time when the key back-end interface is triggered.

[0105] Step 4026: Determine whether the front-end event latency is less than or equal to the preset server latency threshold. If yes, end the process; otherwise, proceed to step 4027.

[0106] Step 4027: The server generates an alarm event.

[0107] For example, if an attacker attempts to log in multiple times, the first time the login button is clicked, a front-end event is triggered and tracking information is generated. This tracking information is encrypted with a public key and uploaded to the server, generating a tracking identifier for the front-end event. Simultaneously with the triggering of the front-end event, a business request packet is sent to the server. The attacker intercepts the business request packet and performs a brute-force attack on the account password.

[0108] For the first brute-force event (i.e. the first time the account and password are entered), the server matches the front-end event and tracking identifier associated with the business request packet. Based on the timestamp in the front-end event's embedded information and the time when the (business request packet) triggers the back-end key interface call, the front-end event latency is determined. If the latency of the front-end event exceeds the preset server latency threshold, it is considered that the current back-end key interface call is abnormal, and an alarm event is generated.

[0109] When an attacker performs a second brute-force attack (i.e., enters the username and password a second time), if there are no front-end events or tracking identifiers associated with the business request packet on the server, it is considered a direct packet sending behavior, and an alarm event is generated. Once more than 3 alarm events occur, the current account or IP address will be banned.

[0110] In this embodiment of the application, attack behavior monitoring is performed by combining the tracking information of front-end events. Compared with the conventional monitoring scheme that only issues an alert after a certain number of failures, this approach can locate attack behavior and issue an alert more quickly, thereby reducing user losses.

[0111] Step 403: Based on the tracking information of multiple front-end events, construct the front-end call path, where the tracking information of each front-end event is a front-end event node in the front-end call path.

[0112] Step 404: For each key event among multiple front-end events, based on the front-end event node corresponding to the key event in the front-end call path, associate and add the corresponding back-end event node to obtain the target call path.

[0113] Step 405: Detect logical vulnerabilities in the front-end application based on the target call path.

[0114] In this embodiment, by associating front-end events with tracking identifiers and business request packets to determine the latency of front-end events, and judging the difference between the latency in the previous period and the preset server latency threshold, attack behaviors targeting security vulnerabilities can be quickly located and alarm events can be generated. Furthermore, this application obtains the front-end call path and adds corresponding back-end event nodes based on the front-end event nodes corresponding to key events, clarifying the front-end and back-end interaction path, realizing the reconstruction of the target call path, and combining attack characteristics to detect logical vulnerabilities in the front-end application, maintaining user data security, and helping to protect the system from various potential attacks, thereby improving the system's robustness.

[0115] Based on the same technical concept, this application provides a schematic diagram of a call path restoration structure, such as... Figure 5 As shown, the data balancing device 500 includes:

[0116] The receiving module 501 is used to receive the tracking information of multiple front-end events triggered in the front-end application, which are sent sequentially by the terminal device.

[0117] The processing module 502 is configured to perform the following operations for each front-end event: if the front-end event is a critical event, generate a tracking identifier for the front-end event based on the event's tracking information; trigger a back-end critical interface call and record the back-end log associated with the back-end critical interface call; and merge the tracking identifier and the back-end log into a back-end event node corresponding to the front-end event.

[0118] Optionally, the processing module 502 is also used for:

[0119] After merging the tracking identifier and the background log into the background event node corresponding to the front-end event, the front-end event latency is determined based on the timestamp in the front-end event's event tracking information and the time when the key back-end interface is triggered.

[0120] If the front-end event latency exceeds a preset server latency threshold, an alarm event is generated.

[0121] Optionally, the processing module 502 is specifically used for:

[0122] Upon receiving a service request packet from the terminal device, a critical backend interface call is triggered;

[0123] If there are front-end events and tracking identifiers associated with the business request package, then a business response package corresponding to the business request package is generated;

[0124] The request time of the business request packet, the business request packet, and the business response packet are recorded as background logs associated with the background key interface call.

[0125] Optionally, the processing module 502 is also used for:

[0126] If no front-end event and tracing identifier are associated with the business request packet, an alarm event is generated.

[0127] Optionally, the processing module 502 is specifically used for:

[0128] If there are front-end events and tracking identifiers associated with the business request package, the front-end event latency is determined based on the timestamp in the event's tracking information and the time when the backend key interface call is triggered.

[0129] If the front-end event latency is less than or equal to the preset server latency threshold, then a business response packet corresponding to the business request packet is generated.

[0130] Optionally, the processing module 502 is also used for:

[0131] If there are front-end events and tracking identifiers associated with the business request package, the front-end event latency is determined based on the timestamp in the event's tracking information and the time when the backend key interface call is triggered.

[0132] If the front-end event latency exceeds a preset server latency threshold, an alarm event is generated.

[0133] Optionally, the processing module 502 is also used for:

[0134] After merging the tracking identifier with the background log into the background event node corresponding to the front-end event, the tracking identifier is marked as invalid.

[0135] The restoration module 503 is used to restore the target call path based on the tracking information of the multiple front-end events and the back-end event nodes corresponding to the key events in the multiple front-end events.

[0136] Optionally, the restore module 503 is specifically used for:

[0137] Based on the tracking information of the multiple front-end events, a front-end call path is constructed, wherein the tracking information of each front-end event is a front-end event node in the front-end call path;

[0138] For each key event among the multiple front-end events, based on the front-end event node corresponding to the key event in the front-end call path, the corresponding back-end event node is added to obtain the target call path.

[0139] Optionally, the restore module 503 is also used for:

[0140] After reconstructing the target call path based on the tracking information of the multiple front-end events and the back-end event nodes corresponding to the key events in the multiple front-end events, logical vulnerabilities in the front-end application are detected based on the target call path.

[0141] In this embodiment, attack behavior monitoring is performed by combining front-end event tracking information. Compared to conventional monitoring solutions that only issue alerts after a certain number of failures, this approach can locate and alert on attack behaviors more quickly, reducing user losses. By associating front-end events with tracking identifiers and business request packets and determining the latency of front-end events, the difference between the latency in the previous period and a preset server latency threshold is determined, allowing for rapid identification of attacks targeting security vulnerabilities and generating alert events. Furthermore, this application is not limited to security issues caused by security vulnerabilities. By obtaining the front-end call path and associating back-end event nodes corresponding to key events with the front-end event nodes corresponding to key events, the front-end and back-end interaction paths are clarified, enabling the reconstruction of the target call path. Combined with attack characteristics, logical vulnerabilities in front-end applications are detected, maintaining user data security and helping to protect the system from various potential attacks, thus improving system robustness.

[0142] Based on the same technical concept, embodiments of this application provide a computer device, which can be... Figure 1 The server shown is as follows: Figure 6 As shown, it includes at least one processor 601 and a memory 602 connected to at least one processor. In this embodiment, the specific linking medium between the processor 601 and the memory 602 is not limited. Figure 6 Taking the connection between the processor 601 and the memory 602 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc.

[0143] In this embodiment of the application, the memory 602 stores instructions executed by at least one processor 601. By executing the instructions stored in the memory 602, at least one processor 601 can perform the steps of the above-described call path restoration method.

[0144] The processor 601 is the control center of the computer device, capable of connecting various parts of the computer device via various interfaces and lines. It restores the call path by running or executing instructions stored in the memory 602 and accessing data stored in the memory 602. Optionally, the processor 601 may include one or more processing modules. The processor 601 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601. In some embodiments, the processor 601 and the memory 602 may be implemented on the same chip; in other embodiments, they may be implemented on separate chips.

[0145] Processor 601 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0146] Memory 602, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 602 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 602 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer device, but is not limited thereto. In the embodiments of this application, memory 602 may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0147] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the above-described call path restoration method.

[0148] Based on the same inventive concept, embodiments of this application provide a computer program product, including a computer program stored on a computer-readable storage medium. The computer program includes program instructions, which, when executed by a computer device, cause the computer device to perform the steps of the above-described call path restoration method.

[0149] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0150] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations 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, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0151] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0152] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0153] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for restoring a call path, applied to a server, characterized in that, include: Receive the event tracking information of multiple front-end events triggered in the front-end application, which are sent sequentially by the terminal device. For each front-end event, perform the following operations: If the front-end event is a critical event, generate a tracking identifier for the front-end event based on the event's event tracking information; In addition, triggering key backend interface calls and recording backend logs associated with the key backend interface calls; merging the tracking identifier and the backend logs into a backend event node corresponding to the frontend event; Based on the tracking information of the multiple front-end events and the back-end event nodes corresponding to the key events in the multiple front-end events, the target call path is restored; Based on the timestamp in the event tracking information and the time when the key backend interface is triggered, the event latency is determined. If the front-end event latency exceeds a preset server latency threshold, an alarm event is generated.

2. The method as described in claim 1, characterized in that, The triggering of key backend interface calls and the recording of backend logs associated with those calls include: Upon receiving a service request packet from the terminal device, a critical backend interface call is triggered; If there are front-end events and tracking identifiers associated with the business request package, then a business response package corresponding to the business request package is generated; The request time of the business request packet, the business request packet, and the business response packet are recorded as background logs associated with the background key interface call.

3. The method as described in claim 2, characterized in that, Also includes: If no front-end event and tracing identifier are associated with the business request packet, an alarm event is generated.

4. The method as described in claim 2, characterized in that, If a front-end event and tracking identifier are associated with the business request package, a business response package corresponding to the business request package is generated, including: If there are front-end events and tracking identifiers associated with the business request package, the front-end event latency is determined based on the timestamp in the event's tracking information and the time when the backend key interface call is triggered. If the front-end event latency is less than or equal to the preset server latency threshold, then a business response packet corresponding to the business request packet is generated.

5. The method as described in claim 2, characterized in that, Also includes: If there are front-end events and tracking identifiers associated with the business request package, the front-end event latency is determined based on the timestamp in the event's tracking information and the time when the backend key interface call is triggered. If the front-end event latency exceeds a preset server latency threshold, an alarm event is generated.

6. The method as described in claim 1, characterized in that, After merging the tracking identifier and the background log into the background event node corresponding to the front-end event, the method further includes: Mark the tracking identifier as invalid.

7. The method as described in any one of claims 1 to 6, characterized in that, The process of reconstructing the target call path based on the tracking information of the multiple front-end events and the back-end event nodes corresponding to the key events in the multiple front-end events includes: Based on the tracking information of the multiple front-end events, a front-end call path is constructed, wherein the tracking information of each front-end event is a front-end event node in the front-end call path; For each key event among the multiple front-end events, based on the front-end event node corresponding to the key event in the front-end call path, the corresponding back-end event node is added to obtain the target call path.

8. The method as described in claim 7, characterized in that, After restoring the target call path based on the tracking information of the multiple front-end events and the back-end event nodes corresponding to the key events among the multiple front-end events, the method further includes: Based on the target call path, detect logical vulnerabilities in the front-end application.

9. A device for restoring call paths, applied to a server, characterized in that, include: The receiving module is used to receive the tracking information of multiple front-end events triggered in the front-end application, which are sent sequentially by the terminal device. The processing module is used to perform the following operations for each front-end event: if the front-end event is a critical event, then generate a tracking identifier for the front-end event based on the event's data entry information; In addition, triggering key backend interface calls and recording backend logs associated with the key backend interface calls; merging the tracking identifier and the backend logs into a backend event node corresponding to the frontend event; The restoration module is used to restore the target call path based on the tracking information of the multiple front-end events and the back-end event nodes corresponding to the key events in the multiple front-end events; Based on the timestamp in the event tracking information and the time when the key backend interface is triggered, the event latency is determined. If the front-end event latency exceeds a preset server latency threshold, an alarm event is generated.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, It stores a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the method according to any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes a computer program stored on a computer-readable storage medium, the computer program including program instructions that, when executed by a computer device, cause the computer device to perform the steps of the method as described in any one of claims 1-8.

Images