Processing method, device and equipment aiming at client application attack

Abstract

The embodiment of the invention discloses a processing method, device and equipment for client application attacks. According to the scheme, the method comprises the steps of collecting a user behavior burying point log and an interface traffic log corresponding to a client application; associating the user behavior burying point log with the interface traffic log based on a specified field to obtain an associated log, and performing risk session screening based on the associated log; performing risk feature identification based on the risk session, and determining a risk user; and performing section detection on the user data corresponding to the risk user, and executing a corresponding dynamic decision based on a detection result.

Description

Technical Field

[0001] This specification relates to the field of Internet technology, and in particular to methods, apparatus and devices for dealing with attacks against client applications. Background Technology

[0002] With the rapid development of mobile internet, client applications are facing increasingly serious security threats.

[0003] In some scenarios, clients may be attacked, leading to a series of consequences such as privacy data leaks, client hijacking, and financial losses. For example, attacks can be launched against clients using Hook technology. Hook technology is a programmatic interception technique whose core logic involves embedding "hooks" in the execution chain of the operating system and application, such as function calls, message passing, and event triggering. When the target behavior is triggered, the custom code of the hook is executed first, thereby achieving interception, tampering, hijacking, and expansion of actions.

[0004] By attacking the client using Hook technology, the normal front-end page access process can be bypassed, and the back-end application programming interface (API) can be called directly. This process usually only generates API traffic logs.

[0005] Traditional security detection solutions for client-side attacks typically involve post-incident analysis after a client-side attack has occurred, followed by addressing the specific issues. Furthermore, during this analysis, detection is usually based solely on rule matching of API traffic.

[0006] Therefore, more timely and accurate solutions are needed to deal with client application attacks. Summary of the Invention

[0007] This specification provides one or more embodiments of methods, apparatuses, devices, and storage media for handling client application attacks, in order to solve the following technical problem: the need for more timely and accurate handling solutions for client application attacks.

[0008] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows: This specification provides one or more embodiments of a method for handling client application attacks, including: Collect user behavior logs and API traffic logs corresponding to the client application; Based on specified fields, the user behavior tracking logs and the interface traffic logs are associated to obtain associated logs, and risk sessions are filtered based on the associated logs. Risk characteristics are identified based on the risky sessions to determine risky users; A cross-sectional analysis is performed on the user data corresponding to the risky users, and corresponding dynamic decisions are made based on the analysis results.

[0009] This specification provides one or more embodiments of a processing apparatus for client application attacks, comprising: The dual-stream log collection module collects user behavior tracking logs and interface traffic logs corresponding to the client application. The risk session filtering module associates the user behavior tracking logs and the interface traffic logs based on specified fields to obtain associated logs, and performs risk session filtering based on the associated logs. The risk user identification module identifies risk users based on the risk sessions; The dynamic decision execution module performs aspect detection on the user data corresponding to the risky user and executes corresponding dynamic decisions based on the detection results.

[0010] This specification provides one or more embodiments of a processing device for client application attacks, comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: Collect user behavior logs and API traffic logs corresponding to the client application; Based on specified fields, the user behavior tracking logs and the interface traffic logs are associated to obtain associated logs, and risk sessions are filtered based on the associated logs. Risk characteristics are identified based on the risky sessions to determine risky users; A cross-sectional analysis is performed on the user data corresponding to the risky users, and corresponding dynamic decisions are made based on the analysis results.

[0011] This specification provides one or more embodiments of a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows: Collect user behavior logs and API traffic logs corresponding to the client application; Based on specified fields, the user behavior tracking logs and the interface traffic logs are associated to obtain associated logs, and risk sessions are filtered based on the associated logs. Risk characteristics are identified based on the risky sessions to determine risky users; A cross-sectional analysis is performed on the user data corresponding to the risky users, and corresponding dynamic decisions are made based on the analysis results.

[0012] The above-described at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects: By linking user behavior tracking logs with API traffic logs, abnormal patterns of API calls without corresponding front-end behaviors can be detected in real time. This allows for accurate identification of risky sessions suspected of being Hook attacks, avoiding the limitations of detection from a single data source and improving the real-time performance and accuracy of attack identification.

[0013] By combining risk session screening, risk feature identification, and dynamic aspect detection, a closed-loop process is formed from risk discovery, analysis, to handling, enabling full monitoring and intervention of the attack chain and building a closed-loop defense system.

[0014] After identifying high-risk users, secondary confirmation is performed through cross-sectional detection, and hierarchical dynamic decisions are made based on the detection results. This avoids directly blocking normal users, helps to achieve a balance between security and user experience, and reduces false alarms and business impact.

[0015] By dynamically injecting detection logic into the business flow, security verification can be achieved without modifying the business code, improving the system's adaptability and response speed to new attack methods, and enhancing the initiative and adaptability of defense. Attached Figure Description

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

[0017] Figure 1 A flowchart illustrating a method for handling client application attacks provided in one or more embodiments of this specification; Figure 2 This is a flowchart illustrating the handling of a client application attack under one or more embodiments provided in this specification. Figure 3 This is a schematic diagram of a system architecture for handling client application attacks under one or more embodiments provided in this specification. Figure 4 A schematic diagram of a processing device for client application attacks provided in one or more embodiments of this specification; Figure 5This is a schematic diagram of the structure of a processing device for client application attacks provided for one or more embodiments of this specification. Detailed Implementation

[0018] This specification provides a method, apparatus, device, and storage medium for handling client application attacks.

[0019] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0020] Figure 1 This document illustrates a flowchart of a method for handling client application attacks, provided in one or more embodiments. This method can be applied to various business domains, such as application security testing, internet finance, e-commerce, instant messaging, gaming, and government services. The process can be executed by computing devices relevant to the domain (e.g., servers or smart mobile terminals for application security testing). Certain input parameters or intermediate results within the process can be manually adjusted to improve accuracy.

[0021] Figure 1 The process may include the following steps: S102: Collect user behavior logs and interface traffic logs corresponding to the client application.

[0022] A client application is a software program that runs on a user's local terminal device, interacts directly with the user, and performs specific functions. Its core characteristics are localized operation and direct user control. Compared to server applications, client applications are more vulnerable to software attacks, whether running locally or interacting with a server. In the embodiments of this specification, for ease of description, unless otherwise specified, "client" will be used to refer to a client application.

[0023] Figure 2 This is a flowchart illustrating the handling of attacks against client applications under one or more embodiments provided in this specification. User behavior log streams (LogHub) and interface traffic log streams (Gateway) are collected using a client software development kit (SDK).

[0024] User behavior tracking logs are log data that is recorded in a structured format by embedding tracking code at key user interaction nodes on the client side to collect specific user actions, scenario context, and state data during the use of the client.

[0025] Based on the embedded tracking code, when a user's active operation (such as clicking, swiping, or inputting) or passive event (such as page loading completion, pop-up display, or payment execution) is triggered, relevant data in the current scenario is collected. This data can be called user behavior tracking data, which includes not only the user's specific operation behavior but also the scenario context and state data.

[0026] By storing user behavior tracking data in time sequence, we obtain user behavior tracking logs, also known as user behavior tracking log streams. Table 1 shows the dimensions that user behavior tracking data can include. Of course, depending on actual needs, the dimensions in user behavior tracking data are not limited to those listed in Table 1 and can be adjusted accordingly.

[0027] Table 1. Dimensions of User Behavior Tracking Data

[0028] Interface traffic logs are structured logs that record data communication behaviors between systems (including between clients and servers, between clients, and between servers) through API interfaces, including key information such as request initiation, transmission process, and response results.

[0029] Based on API call behavior, relevant data (which can be called API traffic data) is recorded to trigger the API call, and then stored in a time-series log to obtain the API traffic log, also known as the API traffic log stream. Table 2 shows the dimensions that API traffic data can include. Of course, similar to the user behavior tracking data dimension table, the dimensions in API traffic data can also be adaptively adjusted according to different actual needs.

[0030] Table 2 Interface Traffic Data Dimension Table

[0031] Figure 3 This is a schematic diagram of a system architecture for handling client application attacks in one or more embodiments provided in this specification. Generally speaking, user behavior tracking logs are generated directly by the client, while interface traffic logs are generated by the API gateway. The corresponding logs are collected through interaction between the two.

[0032] S104: Based on the specified field, associate the user behavior tracking logs and the interface traffic logs to obtain associated logs, and perform risk session screening based on the associated logs.

[0033] When selecting a specific field, to ensure the accuracy of the association, it is usually advisable to choose a relevant field that is present in both user behavior logs and API traffic logs and can uniquely identify the user. For example, you can choose a user identifier field or a time window field as the specified field.

[0034] For the user identifier (user_id) field, users need to provide their own identifier when conducting business in order to execute the corresponding transaction. For example, when conducting payment transactions, users need to provide their account on the payment platform as their user identifier; similarly, when conducting gaming transactions, users need to log in to their game account as their user identifier. Furthermore, different users have different user identifiers, which can be used to identify high-risk users.

[0035] For the time window field, it can directly refer to the timestamp, or it can be composed of timestamps. The length of the time window can be determined based on the requirements and different business natures. For businesses with high traffic, the time window can be set to be relatively shorter. Data with timestamps within the time window can be used as the log data corresponding to the time window field.

[0036] At this point, for user behavior tracking logs and API traffic logs, log data with the same value in a specified field are combined to obtain associated logs. This combination operation can be called a two-stream join operation or a two-stream association operation, such as... Figure 3 As shown, it can be used by real-time computing engines such as Apache Flink to perform two-stream association operations within the Flink framework. Taking the user identifier field and time window field as an example, log data with identical values ​​for both the user identifier field and time window field are selected from the user behavior tracking logs and interface traffic logs (each row of data is treated as a single log data). Then, the two are combined into a single log data. For example, in one instance, the user behavior tracking logs are shown in Table 3 below: Table 3 Example of User Behavior Tracking Logs

[0037] The interface traffic logs are shown in Table 4 below: Table 4 Example of Interface Traffic Log

[0038] By confirming the user ID and time window, the first and second rows of business data in Table 3 and the first and second rows of business data in Table 4 are related to each other. However, the third row of business data in Table 3 and the third row of business data in Table 4 are not related. They may be related to other business data not shown in the table, or the business data may be a separate business data. In this case, the association logs shown in Table 5 can be obtained through association.

[0039] Table 5 Example of a related log table

[0040] Specifically, the sections from "Interface Timestamp" to "Client IP Address" for "U67890" and from "Event Tracking Timestamp" to "Application Version Number" for "U45678" are left blank because no corresponding data was collected or the data is not reflected in the table. The relevant data for "U12345" is then linked.

[0041] Of course, before performing the dual-stream association operation, field standardization preprocessing can be performed to unify the format of the user identifier field and the time window field, and to distinguish and process conflicting fields between the two. This will not be elaborated on here.

[0042] For log data in the associated logs, session data where user behavior characteristics do not match interface traffic characteristics are identified as risky sessions. Session data here refers to relevant data generated within a continuous time window (or bound by a session identifier) ​​based on the same user identifier. This relevant data consists of user behavior sequences, interface call sequences, and other content contained in the associated logs.

[0043] Hook attacks on clients often bypass the normal front-end page access process and directly call the back-end application programming interface (API). This process usually only generates API traffic logs and generates little or no user behavior.

[0044] Therefore, session data where user behavior characteristics do not match interface traffic characteristics are considered risky sessions, indicating a potential risk of attack. For example, session data with corresponding traffic data in the interface traffic characteristics but without detected relevant user behavior characteristics, or where the user behavior characteristics are insufficient to support the traffic data, are considered mismatched session data and thus risky sessions.

[0045] S106: Based on the risk session, identify risk characteristics and determine risky users.

[0046] A risky session indicates that a user may pose a risk during a single session, but it is difficult to directly determine whether the user corresponding to that session is at risk. For example, when a user buys goods on an e-commerce platform and completes the payment transaction, although they only click the "Submit Order" button once in a single session, and the user behavior log only records one user action, due to network fluctuations, multiple API calls are triggered, resulting in multiple traffic records in the API traffic log. This mismatch leads to the session being judged as a risky session.

[0047] Based on this, user behavior characteristics and interface traffic characteristics are determined through log data in risk sessions. User behavior characteristics refer to the relevant features that represent user behavior, extracted from user behavior tracking logs or user behavior tracking data in related logs. For example, features can be extracted from the data in Table 3 above, or from the corresponding fields in Table 5.

[0048] Interface traffic features refer to a set of structured data dimensions extracted from interface traffic logs or related logs to describe the interface call patterns and operational status. These features reflect the communication patterns, request attributes, and response results of the system interfaces. For example, they can be extracted from the data in Table 4 above, or from the corresponding fields in Table 5.

[0049] If anomalies are found in the independent risk identification of user behavior characteristics and interface traffic characteristics, or if the associated characteristics do not match, then the corresponding user is identified as a risk user. For example... Figure 2 and Figure 3 As shown, the risk analysis engine pre-sets various possible risk scenarios, which can then be identified based on extracted user behavior features and interface traffic features.

[0050] The first scenario involves abnormal user behavior characteristics. This means independently identifying risks in user behavior patterns and discovering significant deviations from normal patterns, indicating potential risk. This process involves serializing user behaviors to obtain user trajectories, which can then be used for risk analysis. For example, taking an e-commerce platform as an example, if a user's behavior pattern shows that they bypassed the homepage and search page, directly accessed the order page via external links, submitted multiple orders within a short period, and used widely spaced delivery addresses, while also alternating between different bank cards for payment, then this user's purchasing pattern differs significantly from that of a typical user, thus suggesting potential risk.

[0051] The second scenario involves anomalies in the interface traffic characteristics. This means conducting independent risk identification on the interface traffic characteristics and discovering abnormal interface request patterns (e.g., abnormal frequency or abnormal parameters), indicating potential risk. For example, in the payment confirmation interface of a payment platform, a payment request is received from a user with a payment amount of "-100" yuan in the parameters, and the format of the corresponding order field is not the platform's standard format; or, a user's payment requests are too frequent, with multiple payment requests received from them within a short period of time, and each payment request corresponding to a different product ID. In these cases, it can be considered that the user may pose a risk.

[0052] The third scenario involves user behavior characteristics and API traffic characteristics showing no anomalies when judged independently, but a mismatch after identifying related features. This is similar to the judgment logic of risky sessions, but their detection targets and scope differ. For example, an e-commerce platform's order submission API might be called multiple times by a single user within a short period, but the client-side event logs do not detect related user behaviors such as "viewing product details pages" or "adding items to cart," leading to the conclusion that there is no match between the two.

[0053] For the first and second scenarios mentioned above, detection can be performed directly using the corresponding features. However, for the third scenario, it is necessary to generate associated features before detection.

[0054] Specifically, based on the user identifier field in the risk session, the risk session is grouped by user. Generally speaking, each user identifier represents one user. At this time, session data with the same user identifier are selected and grouped into a single group.

[0055] Based on the time window field in the risk sessions, risk sessions within a single group are sequentially correlated to obtain the risk session group corresponding to the current user. However, to ensure the independence of the analysis of a user's individual business execution and to prevent the failure to promptly detect risks associated with multiple actions of a single user when analyzed together, the time difference within the time window of a single group can be limited. For example, if the time difference between two consecutive risk sessions exceeds a preset value, they are separated and analyzed as two independent risk session groups.

[0056] By combining user behavior features and interface traffic features, associated features can be generated. During the combination, the two can be directly spliced ​​together, so that features in the same time window are spliced ​​together.

[0057] For associated features, based on their corresponding business attributes, it is determined whether the associated features contain internal logical anomalies. Business attributes refer to the attributes contained within the business scenario (e.g., e-commerce, payment, login) corresponding to user behavior features and interface traffic features, used to describe that business scenario. These attributes may include business identifiers, business rule constraints, and common business patterns. Anomaly detection methods may include using a rule engine, pre-setting business rules through fields such as common business patterns, and considering internal logical anomalies as present when associated features do not conform to these business rules; or pre-training a corresponding machine learning model using historical data to identify whether associated features contain internal logical anomalies.

[0058] If a mismatch exists, it indicates a mismatch between the user behavior features and the interface traffic features. Compared to analyzing the matching relationship between user behavior features and interface traffic features as two separate features, combining them allows for feature fusion, which facilitates the discovery of deeper features and helps improve the accuracy of anomaly analysis.

[0059] S108: Perform cross-sectional detection on the user data corresponding to the risky user, and execute corresponding dynamic decisions based on the detection results.

[0060] Specifically, for high-risk users, their corresponding user data is obtained. For example... Figure 3 As shown, after a risky user is detected, the user data is transmitted asynchronously to the client-side security aspect module in real time via a message queue, using methods such as Kafka. The client-side security aspect module can receive the corresponding user data and perform aspect detection. This user data can include multiple dimensions to reflect the client's current security status from different perspectives. For example, it may include runtime environment data and user behavior characteristics.

[0061] Based on security benchmarks established when risky users interact with client applications, multi-dimensional real-time detection is performed using user data. These security benchmarks can be reflected in multiple dimensions. For example, the supply of Hook technology often requires tampering with the client's normal operating environment characteristics (e.g., memory layout, library loading, API call stack, code integrity). Therefore, runtime environment data can be used to determine if the client has been attacked by Hook technology. Furthermore, user behavior patterns can be further identified through user behavior characteristics to determine if there are any anomalies. Compared to the judgment during risky user identification, this behavior pattern judgment, by incorporating more dimensions of user data, makes the judgment more accurate. Additionally, relevant code can be obtained to verify the integrity and signature validity of the core code of the risky user's client (e.g., DEX library, IPA library, SO library, etc.), thereby identifying whether the code has been tampered with or replaced. Furthermore, proactive monitoring can be performed on certain sensitive operations (e.g., payment operations, login operations, password modification operations), even if the user is not a risky user, corresponding detection and analysis actions can be taken.

[0062] Based on the risk level of the detection results, corresponding dynamic management decisions are made for users at risk. Different risk levels can be set according to different detection results. Since real-time detection corresponds to multiple dimensions, and each dimension may have separate detection results, the detection results of each dimension are referred to as sub-detection results, and the sub-detection results of all dimensions are combined into a complete detection result.

[0063] For each dimension of real-time detection, the corresponding sub-detection results are used to determine the attack behavior confidence level. Attack behavior refers to the attack actions taken by the risky user when using the client application, while attack behavior confidence level represents the probability that the risky user will launch an attack behavior under the current detection dimension. The higher the attack behavior confidence level, the higher the probability.

[0064] During the detection process, the security benchmark for determining risky users when using the client application includes multiple detection dimensions. These detection dimensions may include those mentioned above, such as determining whether the user is attacked by Hook technology through runtime environment data and determining whether there are any abnormalities in the user's behavior patterns.

[0065] For each detection dimension, its corresponding detection benchmark is determined. For example, for the detection dimension corresponding to runtime environment data, standard environment characteristics under various operating systems and application versions can be used as the detection benchmark; for the detection dimension corresponding to user behavior patterns, frequency distributions and time-series feature intervals corresponding to user behavior patterns under one or more common methods can be pre-set as the detection benchmark; for the integrity of core code, the detection benchmark can be the officially released hash value, signature certificate fingerprint, etc.; and for sensitive operations, detection benchmarks can be set based on different sensitive operations and corresponding standard characteristics.

[0066] Based on user data, at least a portion of the data related to the detection dimension is selected to determine the feature distance between it and the detection benchmark. For example, for runtime environment data, environmental data from user data can be primarily acquired; for user behavior patterns, user behavior tracking data can be primarily acquired; for core code, relevant code data can be primarily acquired; and for sensitive operations, data related to the operation can be filtered from the above data. The feature distance can be calculated using cosine distance for each time window, and the average of the cosine distances of all time windows is taken to obtain the final feature distance.

[0067] The attack behavior confidence level corresponding to the detection dimension is obtained based on the feature distance, and a sub-detection result corresponding to the detection dimension is generated. Generally speaking, the smaller the feature distance, the closer the detection dimension is to the preset detection benchmark, and the lower the probability of the corresponding attack behavior, and the lower the attack behavior confidence level; conversely, the larger the feature distance, the higher the attack behavior confidence level.

[0068] After obtaining the attack behavior confidence of each sub-detection result, if the attack behavior confidence of a single sub-detection result exceeds the first preset threshold, or if the attack behavior confidence corresponding to the joint analysis result of multiple sub-detection results exceeds the second preset threshold, then the detection result is determined to indicate the existence of attack behavior, and corresponding interception actions are performed on the risky user.

[0069] If the confidence level of an attack behavior in a single sub-detection result exceeds the first preset threshold, it indicates that there is a high probability that an attack behavior exists in a certain detection dimension. In this case, the final detection result is directly determined to be an attack behavior, and the user is blocked. The user is not allowed to access the server for a certain period of time or is not allowed to do so. The user's account is also frozen or banned as needed.

[0070] The joint analysis of multiple sub-detection results refers to the process where, when no single sub-detection result has an attack behavior confidence score exceeding a first preset threshold, the attack behavior confidence scores of multiple sub-detection results are weighted and summed using preset weights to determine whether a second preset threshold has been reached. Generally, the first preset threshold represents the judgment criterion on a single dimension, while the second preset threshold represents the judgment criterion on an overall scale, considering more comprehensive factors. Therefore, the second preset threshold is lower than the first preset threshold, thus identifying a situation where, although there is no particularly outstanding single sub-detection result, multiple sub-detection results exhibit suspicious activity.

[0071] Otherwise, appropriate verification and continuous monitoring actions are performed on risky users. For example, verification can be conducted by issuing mobile phone verification codes or human-machine verification. Based on the detection results, a user profile of the risky user is generated; this profile can be generated using corresponding user data and detection results. The risky user is continuously monitored within an observation window (e.g., set to 30 seconds). Of course, for risky users confirmed to have engaged in attack behavior, a corresponding user profile can also be generated and updated.

[0072] like Figure 2 and Figure 3 As shown, user profiles can also be updated based on user data obtained through continuous observation of user actions. Over a future period, the risky user will be continuously monitored, and their user profile updated accordingly, thus providing a basis for rapid identification of subsequent risky users.

[0073] By linking user behavior tracking logs with API traffic logs, abnormal patterns of API calls without corresponding front-end behaviors can be detected in real time. This allows for accurate identification of risky sessions suspected of being Hook attacks, avoiding the limitations of detection from a single data source and improving the real-time performance and accuracy of attack identification.

[0074] By combining risk session screening, risk feature identification, and dynamic aspect detection, a closed-loop process is formed from risk discovery, analysis, to handling, enabling full monitoring and intervention of the attack chain and building a closed-loop defense system.

[0075] After identifying high-risk users, secondary confirmation is performed through cross-sectional detection, and hierarchical dynamic decisions are made based on the detection results. This avoids directly blocking normal users, helps to achieve a balance between security and user experience, and reduces false alarms and business impact.

[0076] By dynamically injecting detection logic into the business flow, security verification can be achieved without modifying the business code, improving the system's adaptability and response speed to new attack methods, and enhancing the initiative and adaptability of defense.

[0077] In one or more embodiments of this specification, when it is determined that there is an anomaly in the independent risk identification of user behavior characteristics, it may be that the user behavior characteristics of the risky user are indeed abnormal, or it may be due to some objective reasons (such as the user's network failure, the user's unfamiliarity with the new device, the user's unfamiliarity with the business activities involved, the newly launched business activities being linked with external platforms, etc.), which makes the risky user actually misjudged.

[0078] Based on this, and through communication with the client application, physical sensors installed on the terminal device corresponding to the client application are used to collect physical behavior data of users at risk. For smart mobile devices, physical behavior data may include acceleration, gyroscope, and gravity sensors; for desktop devices, physical behavior data may include mouse movement trajectories and keyboard input intervals.

[0079] Normally, continuous collection of this physical behavior data may cause application lag. Therefore, physical behavior data collection should only be carried out after an anomaly is identified in the independent risk identification of user behavior characteristics and after obtaining the user's consent for permissions through communication with the client application.

[0080] Features corresponding to physical behavior data are added to user behavior features, and independent risk identification is then performed again based on these added user behavior features. Real user operations are accompanied by various physical sensor signals, while automated attacks lack such signals. For example, the mouse movement trajectory of a normal user is usually non-uniform, paused, and irregular, while the mouse movement of a script is often uniform, without pauses, and a straight trajectory. Furthermore, for mobile devices, the accelerometer of a normal user's handheld device will show slight fluctuations, while emulators will not. By adding features corresponding to physical behavior data, the accuracy of risk user identification can be increased.

[0081] In one or more embodiments of this specification, when performing corresponding verification actions and continuous observation actions against risky users, the reason why the risky user is low may be because he does not have any attack behavior, or because he has hidden his attack behavior, so that he is not fully detected.

[0082] Based on this, during subsequent continuous monitoring, the security benchmarks for high-risk users are dynamically adjusted. For example, relevant values ​​in the security benchmarks may be adjusted, or the weights of multiple security benchmarks may be adjusted. This dynamic adjustment bypasses the static security benchmark detection process, making it less susceptible to repeated probing and adaptation of defense rules.

[0083] Based on communication with the client application, the built-in environment change engine in the client application is triggered. This engine adjusts at least some client interface elements corresponding to the session data of the at-risk user according to preset rules. The environment change engine is pre-built into the client and does not start during normal operation; it only starts after a command is sent from the server.

[0084] The environment modification engine can uniquely change the interaction pattern or communication mode between the client and server each time by modifying at least some client interface elements (such as the call order of some interfaces, interface element IDs, communication protocol field names, etc.). When the client is executing normally, it can adjust the client interface elements based on the execution actions of the environment modification engine. The server and client can share an algorithm that dynamically generates change rules based on session keys or seeds, and can verify the changes in real time during the interaction, so that the interaction can continue normally. However, when the client is hijacked or engages in attack behavior, the attack behavior often follows a recognized static pattern and usually does not change accordingly with the changes in the environment modification engine. Therefore, the server can identify the attack behavior. Alternatively, for some attack behaviors that can change with changes in client interface elements, it is difficult to predict the change pattern. Therefore, the change of attack behavior still has a lag and can be detected by the server.

[0085] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figure 4 , Figure 5 As shown.

[0086] Figure 4 This specification provides a schematic diagram of a processing apparatus for client application attacks, according to one or more embodiments. The apparatus includes: The dual-stream log collection module 402 collects user behavior tracking logs and interface traffic logs corresponding to the client application. The risk session filtering module 404 associates the user behavior tracking logs and the interface traffic logs based on a specified field to obtain associated logs, and performs risk session filtering based on the associated logs. The risk user identification module 406 identifies risk users based on the risk session; The dynamic decision execution module 408 performs aspect detection on the user data corresponding to the risky user and executes corresponding dynamic decisions based on the detection results.

[0087] Optionally, based on specified fields, the risk session screening module 404 determines that the specified fields include a user identifier field and a time window field; For the user behavior tracking logs and the interface traffic logs, log data with the same field value in the specified field are combined to obtain associated logs; For the log data in the associated logs, session data where user behavior characteristics do not match interface traffic characteristics are identified as risky sessions.

[0088] Optionally, the risk user determination module 406 determines the corresponding user behavior characteristics and interface traffic characteristics through log data in the risk session; If it is determined that there are anomalies in the independent risk identification of the user behavior characteristics and the interface traffic characteristics, or if the associated characteristics do not match, then the corresponding user is regarded as a risk user.

[0089] Optionally, the risk user determination module 406 groups the risk sessions into user groups based on the user identifier field in the risk sessions, and associates the risk sessions in a single group in a time sequence based on the time window field in the risk sessions to obtain the risk session group corresponding to the current user. The user behavior features and the interface traffic features are combined to generate associated features; For the associated features, determine whether there are internal logical anomalies based on their corresponding business attributes; If such a mismatch exists, it is determined that the correlation features between the user behavior features and the interface traffic features do not match.

[0090] Optionally, the risk user determination module 406 collects physical behavior data corresponding to the risk user based on communication with the client application and through physical sensors installed on the terminal device corresponding to the client application. The features corresponding to the physical behavior data are added to the user behavior features, and independent risk identification is performed again using the added user behavior features.

[0091] Optionally, the dynamic decision execution module 408 acquires the corresponding user data for the risky user; Based on the security benchmarks of the risky users when using the client application, multi-dimensional real-time detection is performed based on the user data; Based on the risk level of the detection results, corresponding dynamic management decisions are made for the risky users.

[0092] Optionally, the dynamic decision execution module 408 determines the confidence level of the attack behavior corresponding to the sub-detection results corresponding to the real-time detection of each dimension. If the confidence level of an attack behavior in a single sub-detection result exceeds the first preset threshold, or if the confidence level of an attack behavior corresponding to the joint analysis result of multiple sub-detection results exceeds the second preset threshold, then the detection result is determined to indicate the presence of an attack behavior, and corresponding interception actions are performed on the risky user. Otherwise, perform corresponding verification actions and continuous monitoring actions on the risky users.

[0093] Optionally, the dynamic decision execution module 408 determines multiple detection dimensions included in the security benchmark when the risky user uses the client application; For each detection dimension, determine its corresponding detection benchmark; Based on the user data, at least a portion of the data related to the detection dimension is selected, the feature distance between the data and the detection benchmark is determined, and the attack behavior confidence corresponding to the detection dimension is obtained based on the feature distance, and the sub-detection result corresponding to the detection dimension is generated.

[0094] Optionally, the dynamic decision execution module 408 dynamically adjusts the security benchmark corresponding to the risky user; Based on the communication with the client application, the built-in environment change engine in the client application is triggered, so that at least some client interface elements corresponding to the session data of the risky user are adjusted according to a preset rule through the environment change engine.

[0095] Optionally, the dynamic decision execution module 408 generates a user profile of the at-risk user based on the detection results; The user profile is updated based on the user data obtained from the continuous observation actions.

[0096] Figure 5 This specification provides a schematic diagram of a processing device for client application attacks, as shown in one or more embodiments. The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: Collect user behavior logs and API traffic logs corresponding to the client application; Based on specified fields, the user behavior tracking logs and the interface traffic logs are associated to obtain associated logs, and risk sessions are filtered based on the associated logs. Risk characteristics are identified based on the risky sessions to determine risky users; A cross-sectional analysis is performed on the user data corresponding to the risky users, and corresponding dynamic decisions are made based on the analysis results.

[0097] Based on the same idea, one or more embodiments of this specification also provide a non-volatile computer storage medium corresponding to the above method, storing computer-executable instructions, wherein the computer-executable instructions are configured as follows: Collect user behavior logs and API traffic logs corresponding to the client application; Based on specified fields, the user behavior tracking logs and the interface traffic logs are associated to obtain associated logs, and risk sessions are filtered based on the associated logs. Risk characteristics are identified based on the risky sessions to determine risky users; A cross-sectional analysis is performed on the user data corresponding to the risky users, and corresponding dynamic decisions are made based on the analysis results.

[0098] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0099] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0100] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0101] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0102] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of a computer program product implemented 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.

[0103] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will 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 and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0104] 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.

[0105] 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.

[0106] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0107] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0108] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0109] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0110] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0111] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0112] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0113] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for handling client application attacks, comprising: Collect user behavior logs and API traffic logs corresponding to the client application; Based on specified fields, the user behavior tracking logs and the interface traffic logs are associated to obtain associated logs, and risk sessions are filtered based on the associated logs. Risk characteristics are identified based on the risky sessions to determine risky users; A cross-sectional analysis is performed on the user data corresponding to the risky users, and corresponding dynamic decisions are made based on the analysis results.

2. The method as described in claim 1, wherein the user behavior tracking logs and the interface traffic logs are associated based on a specified field to obtain associated logs, and risk session filtering is performed based on the specified field, specifically including: The specified fields include the user identifier field and the time window field; For the user behavior tracking logs and the interface traffic logs, log data with the same field value in the specified field are combined to obtain associated logs; For the log data in the associated logs, session data where user behavior characteristics do not match interface traffic characteristics are identified as risky sessions.

3. The method as described in claim 1, wherein risk feature identification is performed based on the risk session to determine risky users, specifically including: By using the log data in the risk session, the corresponding user behavior characteristics and interface traffic characteristics can be determined. If it is determined that there are anomalies in the independent risk identification of the user behavior characteristics and the interface traffic characteristics, or if the associated characteristics do not match, then the corresponding user is regarded as a risk user.

4. The method as described in claim 3, wherein determining the mismatch between the correlation features of the user behavior features and the interface traffic features specifically includes: Based on the user identifier field in the risk session, the risk session is grouped by user, and based on the time window field in the risk session, the risk sessions in a single group are time-series correlated to obtain the risk session group corresponding to the current user. The user behavior features and the interface traffic features are combined to generate associated features; For the associated features, determine whether there are internal logical anomalies based on their corresponding business attributes; If such a mismatch exists, it is determined that the correlation features between the user behavior features and the interface traffic features do not match.

5. The method of claim 3, after determining that there is an anomaly in the independent risk identification of the user behavior characteristics, the method further includes: Based on communication with the client application, physical behavior data corresponding to the risky user is collected through physical sensors installed on the terminal device corresponding to the client application. The features corresponding to the physical behavior data are added to the user behavior features, and independent risk identification is performed again using the added user behavior features.

6. The method as described in claim 1, wherein facet detection is performed on the user data corresponding to the risky user, and corresponding dynamic decisions are executed based on the detection results, specifically including: For the aforementioned high-risk users, obtain their corresponding user data; Based on the security benchmarks of the risky users when using the client application, multi-dimensional real-time detection is performed based on the user data; Based on the risk level of the detection results, corresponding dynamic management decisions are made for the risky users.

7. The method as described in claim 6, wherein based on the risk level in the detection results, corresponding dynamic management decisions are made for the risky users, specifically including: For the sub-detection results corresponding to the real-time detection of each dimension, determine the confidence level of the corresponding attack behavior; If the confidence level of an attack behavior in a single sub-detection result exceeds the first preset threshold, or if the confidence level of an attack behavior corresponding to the joint analysis result of multiple sub-detection results exceeds the second preset threshold, then the detection result is determined to indicate the presence of an attack behavior, and corresponding interception actions are performed on the risky user. Otherwise, perform corresponding verification actions and continuous monitoring actions on the risky users.

8. The method as described in claim 7, based on the security benchmarks of the at-risk user when using the client application, performs multi-dimensional real-time detection according to the user data, specifically including: The security baseline for determining the risky user's use of the client application includes multiple detection dimensions; For each detection dimension, determine its corresponding detection benchmark; Based on the user data, at least a portion of the data related to the detection dimension is selected, the feature distance between the data and the detection benchmark is determined, and the attack behavior confidence corresponding to the detection dimension is obtained based on the feature distance, and the sub-detection result corresponding to the detection dimension is generated.

9. The method of claim 6, after performing the corresponding verification action and continuous observation action on the risky user, the method further includes: The security benchmark corresponding to the risky user is dynamically adjusted. Based on the communication with the client application, the built-in environment change engine in the client application is triggered, so that at least some client interface elements corresponding to the session data of the risky user are adjusted according to a preset rule through the environment change engine.

10. The method of claim 7, after performing the corresponding verification action and continuous observation action on the risky user, the method further includes: Based on the detection results, a user profile of the at-risk user is generated; The user profile is updated based on the user data obtained from the continuous observation actions.

11. A processing apparatus for client application attacks, comprising: The dual-stream log collection module collects user behavior logs and interface traffic logs corresponding to the client application. The risk session filtering module associates the user behavior tracking logs and the interface traffic logs based on specified fields to obtain associated logs, and performs risk session filtering based on the associated logs. The risk user identification module identifies risk users based on the risk sessions; The dynamic decision execution module performs aspect detection on the user data corresponding to the risky user and executes corresponding dynamic decisions based on the detection results.

12. The apparatus of claim 11, wherein, based on a specified field, the risk session screening module determines that the specified field includes a user identifier field and a time window field; For the user behavior tracking logs and the interface traffic logs, log data with the same field value in the specified field are combined to obtain associated logs; For the log data in the associated logs, session data where user behavior characteristics do not match interface traffic characteristics are identified as risky sessions.

13. The apparatus of claim 11, wherein the risk user determination module determines the corresponding user behavior characteristics and interface traffic characteristics through log data in the risk session; If it is determined that there are anomalies in the independent risk identification of the user behavior characteristics and the interface traffic characteristics, or if the associated characteristics do not match, then the corresponding user is regarded as a risk user.

14. The apparatus of claim 13, wherein the risk user determination module groups the risk sessions into user groups based on the user identifier field in the risk sessions, and sequentially associates the risk sessions in a single group based on the time window field in the risk sessions to obtain the risk session group corresponding to the current user; The user behavior features and the interface traffic features are combined to generate associated features; For the associated features, determine whether there are internal logical anomalies based on their corresponding business attributes; If such a mismatch exists, it is determined that the correlation features between the user behavior features and the interface traffic features do not match.

15. The apparatus of claim 13, wherein the risk user determination module, based on communication with the client application, collects physical behavior data corresponding to the risk user through physical sensors installed on the terminal device corresponding to the client application; The features corresponding to the physical behavior data are added to the user behavior features, and independent risk identification is performed again using the added user behavior features.

16. The apparatus of claim 11, wherein the dynamic decision execution module acquires user data corresponding to the risky user; Based on the security benchmarks of the risky users when using the client application, multi-dimensional real-time detection is performed based on the user data; Based on the risk level of the detection results, corresponding dynamic management decisions are made for the risky users.

17. The apparatus of claim 16, wherein the dynamic decision execution module determines the confidence level of the attack behavior corresponding to the sub-detection results corresponding to the real-time detection of each dimension; If the confidence level of an attack behavior in a single sub-detection result exceeds the first preset threshold, or if the confidence level of an attack behavior corresponding to the joint analysis result of multiple sub-detection results exceeds the second preset threshold, then the detection result is determined to indicate the presence of an attack behavior, and corresponding interception actions are performed on the risky user. Otherwise, perform corresponding verification actions and continuous monitoring actions on the risky users.

18. The apparatus of claim 17, wherein the dynamic decision execution module determines multiple detection dimensions included in the security baseline when the risky user uses the client application; For each detection dimension, determine its corresponding detection benchmark; Based on the user data, at least a portion of the data related to the detection dimension is selected, the feature distance between the data and the detection benchmark is determined, and the attack behavior confidence corresponding to the detection dimension is obtained based on the feature distance, and the sub-detection result corresponding to the detection dimension is generated.

19. The apparatus of claim 16, wherein the dynamic decision execution module dynamically adjusts the security benchmark corresponding to the risky user; Based on the communication with the client application, the built-in environment change engine in the client application is triggered, so that at least some client interface elements corresponding to the session data of the risky user are adjusted according to a preset rule through the environment change engine.

20. The apparatus of claim 17, wherein the dynamic decision execution module generates a user profile of the at-risk user based on the detection results; The user profile is updated based on the user data obtained from the continuous observation actions.

21. A processing device for client application attacks, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: Collect user behavior logs and API traffic logs corresponding to the client application; Based on specified fields, the user behavior tracking logs and the interface traffic logs are associated to obtain associated logs, and risk sessions are filtered based on the associated logs. Risk characteristics are identified based on the risky sessions to determine risky users; A cross-sectional analysis is performed on the user data corresponding to the risky users, and corresponding dynamic decisions are made based on the analysis results.

Images