Identification of injection risk during data acquisition

Abstract

The present application provides a method and system for identifying an injection risk during data acquisition, a device, and a medium. The method comprises: acquiring call stack information corresponding to a data acquisition service, wherein the call stack information is recorded, in the process of executing the data acquisition service, for a function used for executing the data acquisition service; and performing risk identification on the basis of the call stack information to obtain an identification result, wherein the identification result is used for indicating whether an injection risk exists in the process of executing the data acquisition service.

Description

Identify risks during data collection Technical Field

[0001] This specification relates to one or more embodiments in the field of information security technology, and in particular to a method, system, device and medium for identifying injection risks during data collection. Background Technology

[0002] As terminal applications offer increasingly diverse services, they also face growing security threats, particularly injection attacks targeting the data collection process. Injection attacks can tamper with the data collected, severely impacting subsequent operations and decisions. For example, in facial recognition payment scenarios, by altering the facial data collected by the terminal to resemble another user's, it's possible to steal resources from that user's account, causing financial losses.

[0003] Currently, most protective measures against security threats focus on data transmission security and data storage security. While these measures do improve system security to some extent, they often fail to effectively address security vulnerabilities in the data collection process within applications, resulting in poor security. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide the following technical solutions.

[0005] According to a first aspect of one or more embodiments of this specification, a method for identifying injection risks during data acquisition is proposed. The method includes: obtaining call stack information corresponding to a data acquisition service, wherein the call stack information is call stack information recorded for functions used to execute the data acquisition service during the execution of the data acquisition service; performing risk identification based on the call stack information to obtain an identification result, wherein the identification result is used to indicate whether there is an injection risk during the execution of the data acquisition service.

[0006] According to a second aspect of one or more embodiments of this specification, a system for identifying injection risks during data acquisition is proposed. The system includes a client and a server. The client is configured to record call stack information for functions used to perform the data acquisition service during the execution of the data acquisition service, and send the call stack information to the server. The server is configured to receive the call stack information, perform risk identification based on the call stack information, and obtain an identification result, the identification result being used to indicate whether there is an injection risk during the execution of the data acquisition service.

[0007] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in the first aspect by executing the executable instructions.

[0008] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first aspect.

[0009] According to a fifth aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as described in the first aspect.

[0010] As can be seen from the above embodiments, this specification records the call stack information of the function used to perform the data acquisition business during the execution of the data acquisition business, thereby identifying whether there is an injection risk during the execution of the data acquisition business. In this way, the identification result can be referenced when performing a series of operations and decisions based on the acquired data, which can avoid injection attacks from having a serious impact on subsequent operations and decisions, and improve the security of the system.

[0011] Since the call stack is a stack structure formed by function calls during program execution, recording the function call order and parameters, injection attacks will leave specific traces in the call stack. Therefore, analyzing the call stack can accurately determine whether injection risks exist. Furthermore, combining the solutions provided in this manual with other protective measures against security threats can cover the entire data lifecycle, cope with more complex and ever-changing security environments, and provide users with more secure and reliable security. Attached Figure Description

[0012] Figure 1 is a schematic diagram of the architecture of an injection risk identification service system provided in an exemplary embodiment.

[0013] Figure 2 is a flowchart of a method for identifying injection risks during data acquisition, provided by an exemplary embodiment.

[0014] Figure 3 is a flowchart of an exemplary embodiment of a method for identifying risks injected during the data acquisition process that only requires monitoring a subset of functions.

[0015] Figure 4 is a flowchart of a method for performing face recognition services provided in an exemplary embodiment.

[0016] Figure 5 is a flowchart of a method for identifying injected risks during data collection provided by an exemplary embodiment of an injection risk identification service system.

[0017] Figure 6 is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0018] Figure 7 is a block diagram of an exemplary embodiment of a device for identifying risks injected during data acquisition. Detailed Implementation

[0019] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0020] This section provides explanations of the relevant terms.

[0021] Injection attack: The act of illegally inserting malicious code or data into a system by tampering with or manipulating the data transmission process through technical means.

[0022] Function call stack information: During program execution, the stack structure formed by function calls records the order of function calls and parameters.

[0023] Face recognition SDK: A software development kit for implementing face recognition functionality on mobile devices.

[0024] As terminal applications offer increasingly diverse services, they also face growing security threats, particularly injection attacks targeting the data collection process. Injection attacks can tamper with the data collected, severely impacting subsequent operations and decisions. For example, in facial recognition payment scenarios, by altering the facial data collected by the terminal to resemble another user's, it's possible to steal resources from other users' accounts (such as funds, points, vouchers, gift cards, etc.), causing them financial losses.

[0025] However, current security measures primarily focus on data transmission and data storage security. For example, they involve encrypting transmitted or stored data using encryption algorithms and employing SSL (Secure Sockets Layer) / TLS (Transport Layer Security) protocols to ensure the security of data transmission links. While these measures do improve system security to some extent, they often fail to effectively address security vulnerabilities in the application's internal data collection process. The transmission and storage of forged or tampered data can severely impact subsequent operations and decisions, resulting in poor security.

[0026] Based on this, this specification provides a protective measure for the data acquisition process, which can determine whether there is an injection risk during the execution of data acquisition services. In this way, the next operation can be performed based on whether there is an injection risk during the execution of data acquisition services, so as to avoid injection attacks from seriously affecting a series of subsequent operations and decisions and improve the security of the system.

[0027] In implementation, the call stack information corresponding to the data acquisition business is first obtained. This call stack information is the call stack information recorded for the function used to execute the data acquisition business during the execution of the data acquisition business. Then, risk identification is performed based on the call stack information to obtain the identification result. This identification result is used to indicate whether there is injection risk during the execution of the data acquisition business.

[0028] In the above technical solution, by recording the call stack information of the function used to perform the data acquisition business during the execution of the data acquisition business, it is possible to identify whether there is an injection risk during the execution of the data acquisition business. In this way, the identification result can be referenced when performing a series of operations and decisions based on the acquired data, which can avoid injection attacks from having a serious impact on subsequent operations and decisions, thereby improving the security of the system.

[0029] Since the call stack information is a stack structure formed by function calls during program execution, recording the function call order and parameters, when an injection attack occurs, the injection attack will leave specific traces in the call stack information. Therefore, analyzing the call stack information can accurately determine whether there is an injection risk.

[0030] Furthermore, combining the solutions provided in this manual with other protective measures against security threats can cover the entire data lifecycle, cope with more complex and ever-changing security environments, and provide users with more secure and reliable security protection.

[0031] The method for identifying input risks during data collection provided in this manual can be applied to any data collection scenario. This manual does not limit this method, but only provides illustrative examples below.

[0032] For example, it can be applied to scenarios involving the collection of physiological characteristic data.

[0033] Among them, physiological characteristic data can be physiological characteristic data used for identity management, such as facial data, fingerprint data, and iris data, or physiological characteristic data used for health management, such as heart rate, blood pressure, blood oxygen saturation, and body temperature. This manual does not limit the physiological characteristic data.

[0034] When collecting physiological characteristic data for identity management through data collection services, malicious users may inject malicious code or data into the data collection service program to tamper with the collected physiological characteristic data and conduct illegal identity management. By using the method for identifying injection risks during the data collection process provided in this manual, it is possible to identify whether injection risks exist during the execution of the data collection service. If injection risks exist, the collected physiological characteristic data may have been tampered with, and the collected physiological characteristic data can be determined to be invalid. Therefore, identity management based on this physiological characteristic data will not be conducted, or any identity management based on this physiological characteristic data will be deemed invalid. This avoids illegal identity management based on forged or tampered physiological characteristic data, thereby improving the security of identity management.

[0035] During the collection of physiological characteristic data for identity verification, malicious merchants may inject malicious code or data into the data collection process to tamper with the collected physiological characteristic data, making users believe they are unhealthy and thus deceiving them into purchasing corresponding products. By using the method for identifying injection risks during data collection provided in this manual, it is possible to identify whether injection risks exist during the execution of the data collection process. If injection risks exist, the collected physiological characteristic data may be forged or tampered with. Displaying the identification results to users can prevent them from being deceived by malicious merchants.

[0036] For example, it can be applied to environmental data collection scenarios.

[0037] Taking environmental data captured by a camera as an example, malicious individuals may inject malicious code or data into the camera to tamper with the captured environmental data in order to prevent illegal activities from being recorded. By using the risk identification methods provided in this manual during data collection, it is possible to promptly detect whether the environmental data captured by the camera has been tampered with, resolve the problem quickly, and improve the security of the camera.

[0038] It should be noted that the data acquisition service in this specification can be a service that only collects data, or a service that not only collects data but also processes the collected data. For example, the data acquisition service could be a facial recognition service, which can collect facial data, identify whether the collected facial data is a complete face, instruct the user to perform actions such as blinking or turning their head, and determine whether the user has completed the action based on the collected facial data.

[0039] The following provides an example of the application scenarios for facial recognition services.

[0040] During facial recognition, malicious users may forge facial data, using injection attacks to replace the facial data captured by the camera with forged data. Alternatively, malicious users may use photos of the target face for facial recognition, and when the client instructs the user to blink or turn their head, the malicious user may use injection attacks to tamper with the photo data captured by the client to simulate the effects of blinking or turning their head. Or, malicious users may inject attacks into the facial feature recognition function of the facial recognition service, falsely reporting the presence of a face when it does not exist, falsely reporting that the captured face has performed an action when it has not, or falsely reporting that the captured face is the target face when it is not the target face.

[0041] If the method for injecting risks during the data collection process provided in this manual is used, risk identification can be performed based on the call stack information recorded by the function used to perform the face recognition service during the execution of the face recognition service. The identification result indicates whether there is an injection risk during the execution of the face recognition service. In this way, no matter at which stage of the face recognition process a malicious user launches an injection attack, it can be detected, thus improving the security of face recognition.

[0042] It should be noted that this manual is only an illustrative description of the application scenarios of the method for identifying input risks during the data collection process, and does not limit it.

[0043] In one illustrated embodiment, the method for injecting risks during the identification data collection process provided in this specification is implemented by an electronic device. This electronic device can be a mobile terminal such as a mobile phone, tablet, PDA (Personal Digital Assistants), or wearable device (such as smart glasses, smartwatches, etc.), and this specification does not limit its scope to this type.

[0044] For example, when an electronic device performs a data acquisition service, it records call stack information for the function used to perform the data acquisition service during the process. Based on the call stack information, it performs risk identification and obtains the identification result. The identification result is used to indicate whether there is an injection risk during the execution of the data acquisition service.

[0045] In another illustrated embodiment, the method for identifying risks injected during data collection provided in this specification is implemented by a server. This server can be a physical server containing a single host, or it can be a virtual server hosted within a host cluster.

[0046] For example, the server obtains the call stack information corresponding to the data acquisition service. This call stack information is the call stack information recorded for the function used to execute the data acquisition service during the execution of the data acquisition service. Based on the call stack information, risk identification is performed to obtain the identification result. This identification result is used to indicate whether there is an injection risk during the execution of the data acquisition service.

[0047] In another embodiment shown, the subject of the method for identifying risks injected during data acquisition provided in this specification is a system for identifying risks injected during data acquisition, which may be the system shown in Figure 1.

[0048] Figure 1 is a schematic diagram of the architecture of a system for identifying injection risks during data collection, provided by an exemplary embodiment. As shown in Figure 1, the system may include a server (e.g., server 11) and clients (e.g., electronic devices 12). The number of clients can be several.

[0049] Electronic device 12 can be a mobile phone, a PDA (Personal Digital Assistant), or other electronic devices. Of course, mobile phones and PDAs are only some types of electronic devices that users can use. In reality, users can obviously also use electronic devices such as tablets, laptops, and wearable devices (such as smart glasses and smartwatches), etc., and this specification does not limit this to any particular type. During operation, electronic device 12 can run client-side programs of the target application to implement the relevant functions of the target application. The target application can be any application with data acquisition capabilities; of course, the target application can also have other functions, such as data processing, data transmission, and data storage functions. This specification does not limit the functions of the target application. For example, the target application can be a facial recognition application, a payment application, an e-commerce application, etc.

[0050] For example, when the electronic device 12 runs a program for injecting risk identification applications, it can act as a client for those applications. Similarly, when the electronic device 12 runs a program for data acquisition applications, it can act as a client for those applications. Likewise, when the electronic device 12 runs a program for face recognition applications, it can act as a client for those applications.

[0051] The client-side application of the target application can be launched and run on the electronic device 12. This client-side program can be a native application installed on the terminal. For example, the solution provided in this specification is applicable to clients that integrate a face recognition SDK.

[0052] Server 11 can be a physical server containing a single host, or it can be a virtual server hosted in a host cluster. During operation, server 11 can run server-side programs for the target application to implement its functions. For example, when server 11 runs a server-side program for an injection risk identification application, it can function as a corresponding injection risk identification service platform. Similarly, when server 11 runs a server-side program for a data acquisition application, it can function as a corresponding data acquisition service platform. Likewise, when server 11 runs a server-side program for a face recognition application, it can function as a corresponding face recognition service platform.

[0053] The service platform can interact with the client program of the target application running on the electronic device 12 to realize the functions of the target application. Regarding the network for interaction between the electronic device and the service platform, communication can be implemented using either wired or wireless networks, based on the communication methods supported by the corresponding electronic device. This specification does not impose any restrictions on this. For example, if the electronic device supports both wired and wireless communication, then wired or wireless networks can be used as needed; conversely, if the electronic device typically only supports wireless communication, then a wireless network can be used.

[0054] It should be noted that the method for identifying and injecting risks during the data collection process provided in this specification is implemented through cooperation between the client and the server. This specification does not limit which specific steps the client and the server perform, but only uses the following embodiments as examples for illustrative purposes.

[0055] In one illustrated embodiment, the client performs a data acquisition service and records call stack information during the process. The server performs risk identification on the call stack information recorded by the client to determine whether there is an injection risk during the execution of the data acquisition service. Specifically, the client records call stack information for the function used to perform the data acquisition service and sends this call stack information to the server. The server receives the call stack information, performs risk identification based on it, and obtains an identification result indicating whether there is an injection risk during the execution of the data acquisition service. In some embodiments, the server performs a next operation or decision based on the identification result. In other embodiments, the server sends the identification result to the client; the client receives the identification result and performs a next operation or decision based on it.

[0056] In another embodiment, the client performs a data acquisition operation, recording call stack information during the process. Based on this information, it performs risk identification to determine if injection vulnerabilities exist. The client then sends the identification result to the server, informing it of the potential injection risk and allowing backend technical personnel to update the client's program promptly, thus improving client-side security. Alternatively, the client sends the acquired data and identification result to the server, enabling the server to perform further operations based on the identification result, such as determining the data as invalid. The client, during the data acquisition process, records call stack information for the function used to perform the data acquisition, performs risk identification based on this information, obtains an identification result, and sends the result to the server; or, it sends the acquired data and the identification result to the server. The server receives the identification result, or receives both the data and the identification result.

[0057] In one illustrated implementation, when the client records call stack information during the execution of a data acquisition service, it only records the call stack information of a subset of functions. The call stack information includes the call stack information of the function to be monitored, as indicated by the monitoring indication information. In some embodiments, the server determines which part of the function is recorded. The client, in response to a start command for the data acquisition service, sends a monitoring indication retrieval request to the server. This request indicates the operating environment of the data acquisition service. The server receives the monitoring indication retrieval request, generates monitoring indication information based on the operating environment of the data acquisition service, and returns the monitoring indication information to the client based on the request. The function to be monitored is at least a subset of the functions used to execute the data acquisition service. The client receives the monitoring indication information and, during the execution of the data acquisition service, records call stack information for each function to be monitored based on the monitoring indication information.

[0058] In some embodiments, the client determines which part of the function is recorded. The client, in response to a data acquisition service initiation command, generates monitoring indication information based on the operating environment of the data acquisition service. During the execution of the data acquisition service, it records call stack information for each function to be monitored based on the monitoring indication information. The functions to be monitored are at least a portion of the functions used to execute the data acquisition service.

[0059] It should be noted that the monitoring indication information can be generated by the client or the server. This manual only uses the server-generated monitoring indication information as an example to illustrate the generation process of monitoring indication information. Since the process of the client generating monitoring indication information is similar to that of the server, it will not be described in detail here.

[0060] In one illustrated implementation, the server is configured to determine the risk level of the data acquisition service based on the operating environment of the data acquisition service; based on the risk level of the data acquisition service, it determines the monitoring indication information that matches the risk level from a plurality of alternative monitoring indication information, wherein the risk level corresponding to the plurality of alternative monitoring indication information is positively correlated with the number of functions to be monitored indicated.

[0061] In another embodiment shown, the server is configured to determine the risk level of the data collection service based on its operating environment; determine the number of functions to be monitored based on the risk level of the data collection service, thereby obtaining a monitoring quantity, wherein the monitoring quantity is positively correlated with the risk level; select the monitoring quantity of key functions from the key functions used to perform the data collection service as functions to be monitored; or, select the monitoring quantity of functions from the functions used to perform the data collection service in descending order of attack probability; or, select the monitoring quantity of functions from the functions used to perform the data collection service in descending order of importance as functions to be detected.

[0062] In another embodiment, the operating environment includes at least two environmental attributes: the currently logged-in account, device type, region, and application scenario. The server, based on these at least two environmental attributes, determines the monitoring strategy corresponding to each attribute, and merges the functions to be monitored corresponding to the determined monitoring strategies to obtain monitoring indication information.

[0063] Since the client only monitors a subset of functions, the monitored objects in two consecutive executions are not identical in order to avoid detecting functions susceptible to injection attacks. In one illustrated implementation, the call stack information is recorded for the specific functions used to perform the data collection operation, and the recorded objects for the call stack information corresponding to two consecutive executions of this data collection operation are not identical.

[0064] In one illustrated embodiment, the data collection service is used to collect physiological characteristic data required for identity management; the client or server is configured to determine that the collected physiological characteristic data is invalid or the identity management result based on the physiological characteristic data is invalid if the identification result indicates that there is an injection risk during the execution of the data collection service.

[0065] Figure 2 is a flowchart of a method for identifying injection risks during data acquisition, provided by an exemplary embodiment. The subject executing this method can be an electronic device, a server, or the system shown in Figure 1. As shown in Figure 2, the method includes steps S201 to S202.

[0066] Step S201: Obtain the call stack information corresponding to the data acquisition service. The call stack information is the call stack information recorded for the function used to execute the data acquisition service during the execution of the data acquisition service.

[0067] The data acquisition service can be a service that only collects data. For example, the data acquisition service can be a service that collects image data through a camera, or a service that collects sensor data through a sensor. Of course, it can also be a service that collects data through other acquisition methods. This specification does not limit this.

[0068] Data acquisition services can also include not only data acquisition but also processing of the acquired data. For example, such a data acquisition service could be a facial recognition service, which collects facial data, identifies whether the collected facial data is a complete face, instructs the user to perform actions such as blinking or turning their head, and determines whether the user has completed the action based on the collected facial data. Another example is an iris recognition service, which collects iris data and determines whether the collected iris data matches specified iris data. Of course, this data acquisition service can also be other services that collect and process the collected data; this specification does not limit this to any specific type.

[0069] There can be one or more functions used to perform data acquisition operations. The number of functions can be determined by the actual business needs. This manual does not limit the number of functions used to perform data acquisition operations.

[0070] Call stack information is a stack structure formed by function calls during program execution, recording the call order and parameters of the functions. The call stack information corresponding to data acquisition operations is a stack structure formed by function calls during the execution of data acquisition operations, recording the call order and parameters of the functions used to execute that data acquisition operation.

[0071] Step S202: Based on the call stack information, risk identification is performed to obtain the identification result, which is used to indicate whether there is injection risk in the process of data collection.

[0072] Since the call stack information corresponding to the data acquisition service records the call order and parameters of the functions used to execute the data acquisition service, when an injection attack occurs, the injection attack will leave specific traces in the call stack information. Therefore, analyzing the call stack information can accurately determine whether there is an injection risk.

[0073] In the above technical solution, by recording the call stack information of the function used to perform the data acquisition business during the execution of the data acquisition business, it is possible to identify whether there is an injection risk during the execution of the data acquisition business. In this way, the identification result can be referenced when performing a series of operations and decisions based on the acquired data, which can avoid injection attacks from having a serious impact on subsequent operations and decisions, thereby improving the security of the system.

[0074] Since the call stack information is a stack structure formed by function calls during program execution, recording the function call order and parameters, when an injection attack occurs, the injection attack will leave specific traces in the call stack information. Therefore, analyzing the call stack information can accurately determine whether there is an injection risk.

[0075] Furthermore, combining the solutions provided in this manual with other protective measures against security threats can cover the entire data lifecycle, cope with more complex and ever-changing security environments, and provide users with more secure and reliable security protection.

[0076] It should be noted that the method for identifying injection risks during data acquisition provided in this specification can record call stack information for all functions used to perform data acquisition operations, thus more accurately identifying the existence of injection risks; alternatively, it can record call stack information for only some functions used to perform data acquisition operations, thereby reducing computational load and preventing the identification of injection risks from affecting the normal operation of the business. Next, this specification will exemplarily illustrate a scheme that records call stack information only for some functions used to perform data acquisition operations, using the embodiment shown in Figure 3.

[0077] Figure 3 is a flowchart of a method for identifying risks injected during data acquisition that only requires monitoring a subset of functions, provided by an exemplary embodiment. The method can be executed by an electronic device or the system shown in Figure 1. As shown in Figure 3, the method includes steps S301 to S303.

[0078] Step S301: Generate monitoring indication information. The monitoring indication information is determined based on the operating environment of the data acquisition service. The monitoring indication information is used to indicate the function to be monitored. The function to be monitored includes at least a portion of the functions used to execute the data acquisition service.

[0079] In this specification, the monitoring indication information indicates that the function to be monitored is at least a portion of the functions used to perform the data acquisition service. When the risk level of the data acquisition service's operating environment is very high, the function to be monitored can be all the functions used to perform the data acquisition service; otherwise, the function to be monitored is a portion of the functions used to perform the data acquisition service. To reduce the chance of injection risks going undetected, this specification generates monitoring indication information based on the operating environment of the data acquisition service. This allows the monitoring indication information to more accurately indicate functions that may be vulnerable to injection attacks, reducing computational load and enabling more precise identification of injection risks.

[0080] The monitoring indication information is used to indicate the function to be monitored. In some embodiments, the monitoring indication information includes the function name of the function to be monitored. When there are multiple functions to be monitored, the monitoring indication information may include a list of function names, which includes the function names of the multiple functions to be monitored. Of course, the monitoring indication information may also include a set of function names, which includes the function names of the multiple functions to be monitored. This specification is only an illustrative example of the content of the monitoring indication information and does not limit it. The monitoring indication information can also indicate the function to be monitored in any data format.

[0081] The operating environment of a data acquisition service may include a software operating environment, a hardware operating environment, or both; this specification does not limit this. In some embodiments, the operating environment includes at least one of the following: the currently logged-in account, device type, region, and application scenario.

[0082] The currently logged-in account can indicate the software's operating environment. The server can determine whether an account is malicious based on its historical behavior data. If an account is malicious, the client logging in with that account may have been compromised by malicious injection attacks. Therefore, the security of the data collection service's operating environment can be estimated based on the currently logged-in account.

[0083] The device type can be a device model, such as various models of mobile phones. It can also be a type of device, such as mobile phones, tablets, wearable devices, etc. Different models or types of devices may run different operating systems, resulting in different software operating environments for data collection operations. This can lead to different functions being vulnerable to injection attacks. Therefore, based on the device type, the functions to be monitored can be more accurately identified, allowing the client to accurately identify injection risks even when monitoring only certain functions.

[0084] Furthermore, different models or types of equipment have different hardware operating environments, resulting in differences in data processing capabilities. Therefore, based on the equipment type, more monitoring functions can be determined for equipment with high data processing capabilities, and fewer monitoring functions can be determined for equipment with low data processing capabilities.

[0085] In some embodiments, the running versions of the same application may differ in different regions. This results in clients in different regions calling different functions when performing data collection operations. Therefore, the function to be monitored can be more accurately determined based on the region. Of course, different regions may have other differences besides the running version. This specification does not limit this; the differences caused by different regions should be taken into account to determine the monitoring indication information accordingly.

[0086] The application scenario of a data acquisition service refers to the specific context in which the service is applied. This scenario is determined by the processing required on the acquired data. For example, if facial recognition is needed, the application scenario would be facial recognition. Similarly, if data needs to be categorized, the application scenario would be categorization. Based on the application scenario, the probability of malicious users injecting attacks into the data acquisition service can be analyzed, as can the potential targets of such attacks. Therefore, by defining the application scenario, the functions to be monitored can be more accurately identified, allowing the client to accurately identify injection risks even when monitoring only certain functions.

[0087] For example, when the data acquisition service is facial recognition, injecting attacks into this facial recognition service could bring significant benefits to malicious users. Therefore, the probability of malicious users injecting attacks into this facial recognition service is relatively high. Furthermore, to achieve their goals, malicious users might inject attacks into the functions that acquire camera data or the functions that recognize facial features. Therefore, based on the application scenario, the functions that acquire camera data and the functions that recognize facial features can be identified as the functions to be monitored.

[0088] In one illustrated implementation, a pre-configured mapping between the runtime environment and monitoring strategies is established. Subsequently, after acquiring the runtime environment, the corresponding monitoring strategy can be directly obtained based on that environment, and monitoring indication information can be generated based on the monitoring strategy. The monitoring strategy indicates which functions to monitor, how many functions to monitor, or how many functions within a specified set of functions to monitor. The specified functions can be critical functions, functions vulnerable to injection attacks, functions of high importance, etc. This specification does not limit the specified functions or the monitoring strategy.

[0089] In some embodiments, the operating environment includes the currently logged-in account, and the correspondence between the operating environment and the monitoring policy includes the correspondence between risk levels and monitoring policies. This correspondence includes multiple risk levels and the monitoring policy corresponding to each risk level. The process of generating monitoring indication information includes: obtaining a monitoring policy that matches the risk level of the currently logged-in account from the correspondence between risk levels and monitoring policies; determining the function to be monitored based on the monitoring policy; and generating monitoring indication information based on the determined function to be monitored.

[0090] The risk level of the currently logged-in account can be calculated in real time, retrieved from local memory, or retrieved from the memory of other devices, such as from historical data on the server. This manual does not limit this.

[0091] In some embodiments, the operating environment includes device types, and the correspondence between the operating environment and the monitoring strategy includes the correspondence between device types and the monitoring strategy. The process of generating monitoring indication information includes: obtaining a monitoring strategy that matches the device type in the operating environment from the correspondence between device types and monitoring strategies; determining the function to be monitored based on the monitoring strategy; and generating monitoring indication information based on the determined function to be monitored.

[0092] In some embodiments, the operating environment includes the region to which it belongs, and the correspondence between the operating environment and the monitoring strategy includes the correspondence between the region and the monitoring strategy. The process of generating monitoring indication information includes: obtaining the monitoring strategy matching the region from the correspondence between the region and the monitoring strategy; determining the function to be monitored based on the monitoring strategy; and generating monitoring indication information based on the determined function to be monitored.

[0093] In some embodiments, the operating environment includes application scenarios, and the correspondence between the operating environment and monitoring strategies includes the correspondence between application scenarios and monitoring strategies. The process of generating monitoring indication information includes: obtaining a monitoring strategy that matches the application scenario included in the operating environment from the correspondence between application scenarios and monitoring strategies; determining the function to be monitored based on the monitoring strategy; and generating monitoring indication information based on the determined function to be monitored.

[0094] In some embodiments, the operating environment includes at least two environmental attributes among the current login account, device type, region, and application scenario. The process of generating monitoring indication information includes: determining the monitoring strategies corresponding to the at least two environmental attributes based on the at least two environmental attributes included in the operating environment; and merging the monitoring functions corresponding to the at least two determined monitoring strategies to obtain monitoring indication information.

[0095] The correspondence between the operating environment and monitoring strategies includes at least two correspondences between environmental attributes and monitoring strategies. For example, the correspondence between the operating environment and monitoring strategies may include: risk level, equipment type, region, and application scenario. When determining the monitoring strategies corresponding to the at least two environmental attributes included in the operating environment, this can be done based on the correspondence between the operating environment and monitoring strategies.

[0096] For example, the operating environment includes the current login account and device type. Based on the correspondence between risk level and monitoring strategy and the correspondence between device type and monitoring strategy, a first monitoring strategy corresponding to the risk level of the current login account and a second monitoring strategy corresponding to the device type of the data acquisition service are determined. The monitoring function corresponding to the first monitoring strategy and the monitoring function corresponding to the second monitoring strategy are determined. The monitoring function corresponding to the two monitoring strategies is combined to obtain the monitoring indication information.

[0097] In some embodiments, the correspondence between the operating environment and the monitoring strategy is not static. In practical applications, injection attacks are constantly evolving. Therefore, technicians will continuously update the monitoring strategy based on changes in injection attacks, or they will use a neural network model to continuously update the monitoring strategy based on changes in injection attacks.

[0098] In another embodiment, multiple monitoring indications are pre-configured. Suitable monitoring indications can be selected from these pre-configured indications based on the operating environment of the data acquisition service. The generation process of the monitoring indications includes: determining the risk level of the data acquisition service based on its operating environment; and determining the monitoring indication that matches the risk level from multiple candidate monitoring indications based on that risk level. The risk level corresponding to the multiple candidate monitoring indications is positively correlated with the number of functions to be monitored; that is, the higher the risk level, the more functions need to be monitored.

[0099] The risk level of a data acquisition service can be determined based on its operating environment, either by calculation using a neural network model or by the correspondence between the operating environment and the risk level. This manual does not specify how to determine the risk level of a data acquisition service based on its operating environment.

[0100] The multiple alternative monitoring indications can be based on experience, configured by technical personnel, or determined by a neural network model; this specification does not limit the specific methods used. In some embodiments, the multiple alternative monitoring indications will prioritize the most important functions used to perform data acquisition operations. For example, the alternative monitoring indication with the lowest risk level indicates the most important function; the alternative monitoring indication with the second lowest risk level indicates both the most important and the second most important functions; and so on.

[0101] In another illustrated embodiment, the number of functions to be monitored can be determined based on the operating environment of the data acquisition service, and this number of functions can be selected from the functions used to perform the data acquisition service as the functions to be monitored. In some embodiments, to ensure that the selected functions have monitoring value, they can be selected from the key functions used to perform the data acquisition service. The process of generating monitoring indication information includes: determining the risk level of the data acquisition service based on the operating environment of the data acquisition service; determining the number of functions to be monitored based on the risk level of the data acquisition service, obtaining a monitoring quantity, wherein the monitoring quantity is positively correlated with the risk level; selecting the key functions to be monitored from the key functions used to perform the data acquisition service as the key functions to be monitored; and generating monitoring indication information for the data acquisition service based on the selected key functions to be monitored.

[0102] Critical functions refer to those functions in the application that are essential for implementing core business logic and ensuring system stability and security. These critical functions can be pre-configured locally on the device and retrieved directly from the local machine when determining monitoring indication information. Alternatively, they can be configured on other devices and retrieved from those devices when determining monitoring indication information.

[0103] For example, when selecting a key function for monitoring quantity from the key functions used to perform data acquisition operations, the selection can be random or according to certain selection rules. For instance, the key function selected this time may not be exactly the same as the key function selected last time. This "not exactly the same" could mean partially the same, partially different, or completely different.

[0104] Since injection attacks typically target critical functions, selecting functions to be monitored from among the critical functions makes it easier to detect injection attacks and improves the accuracy of injection risk identification.

[0105] It should be noted that this specification only uses the monitoring of some key functions as an example to illustrate the monitoring indication information. In another embodiment, the monitoring indication information indicates the key functions used to perform the data acquisition business, that is, all key functions of the data acquisition business are monitored.

[0106] In some embodiments, to ensure that the selected functions have monitoring value, functions with a higher probability of being attacked can be selected based on their attack probability. The process of generating monitoring indication information includes: determining the risk level of the data acquisition service based on its operating environment; determining the number of functions to be monitored based on the risk level, obtaining a monitoring quantity, where the monitoring quantity is positively correlated with the risk level; selecting the number of functions to be monitored from those used to perform the data acquisition service, in descending order of attack probability; and generating monitoring indication information for the data acquisition service based on the selected monitoring functions.

[0107] The functions used to perform data acquisition operations are arranged in descending order of attack probability. These functions can be empirical values, configured by technical personnel, or determined by a neural network model. This manual does not impose any restrictions on this.

[0108] For example, when selecting a number of functions to be monitored from those used to perform data collection operations, arranged in descending order of attack probability, the selection can be random or based on certain rules. For instance, the selected functions may not be entirely the same as those selected previously. This "not entirely the same" could mean partially identical, partially different, or completely different.

[0109] Because the above method for generating monitoring indication information prioritizes functions with a high probability of being attacked, it can more accurately identify the functions to be monitored, enabling the client to accurately identify injection risks even when monitoring only some functions.

[0110] In other embodiments, to ensure that the selected functions have monitoring value, important functions can be selected according to their importance. The process of generating monitoring indication information includes: determining the risk level of the data acquisition service based on its operating environment; determining the number of functions to be monitored based on the risk level, obtaining a monitoring quantity that is positively correlated with the risk level; selecting the functions to be monitored from those used to perform the data acquisition service in descending order of importance; and generating monitoring indication information for the data acquisition service based on the selected monitoring functions.

[0111] The functions used to perform data acquisition operations are arranged in descending order of importance. They can be empirical values, configured by technical personnel, or determined by a neural network model. This manual does not limit the specific functions used in this regard.

[0112] For example, when selecting functions for monitoring from those used to perform data collection operations in descending order of importance, the selection can be random or based on certain rules. For instance, the selected function may not be entirely the same as the previously selected function. This "not entirely the same" could mean partially the same, partially different, or completely different.

[0113] Since the consequences of injection attacks on highly important functions are more severe, the aforementioned method for generating monitoring indications prioritizes monitoring highly important functions. If an injection attack is launched on a highly important function, some traces of the attack will be recorded in the call stack information during the function's execution. Subsequently, it is possible to identify whether a highly important function has been injected. Based on the identification results, a series of subsequent operations and decisions can be executed to avoid the serious consequences caused by injection attacks on highly important functions, thereby improving system security.

[0114] In one illustrated implementation, the call stack information is the call stack information recorded for a portion of the functions used to perform the data acquisition operation. To allow for more flexible monitoring of the data acquisition operation, the monitoring objects for two consecutive monitoring operations can be different; that is, the record objects corresponding to the call stack information for two consecutive execution processes of the data acquisition operation are not entirely the same. The record object is the function used to perform the data acquisition operation. For example, after determining the function to be monitored in the current monitoring process, the monitoring indication information from the previous monitoring process is obtained. Based on the monitoring indication information from the previous monitoring process, the function to be monitored in the current monitoring process is updated so that the function to be monitored in the current monitoring process is not entirely the same as the function to be monitored in the previous monitoring process. The monitoring indication information for the current monitoring process is then generated based on the function to be monitored in the current monitoring process.

[0115] It should be noted that this specification only uses the example of determining monitoring indication information based on the operating environment of a data acquisition service to illustrate the process of determining monitoring indication information. In another embodiment, the function to be monitored indicated by the monitoring indication information is a key function used to execute the data acquisition service; that is, during the execution of the data acquisition service, call stack information is recorded for all key functions used to execute the data acquisition service. In yet another embodiment, the function to be monitored indicated by the monitoring indication information can be randomly determined or determined based on other information; this specification does not limit this.

[0116] For example, if the monitoring function indicated by the monitoring instruction information is randomly determined, the monitoring functions indicated by two adjacent monitoring instruction information are not exactly the same. That is, the record objects targeted by the call stack information corresponding to two adjacent execution processes of the data acquisition business are not exactly the same.

[0117] Step S302: During the execution of the data acquisition service, based on the monitoring indication information, the call stack information is recorded for each function to be monitored.

[0118] Since the monitoring indication information indicates that the function to be monitored may be a partial function used to perform data acquisition operations, an aspect component can be used to generate the call stack information of that partial function during implementation. For example, since the aspect component can define how and when to apply specific behaviors to the target object, it can define the recording of the call stack information of the function to be monitored during the execution of the data acquisition operation. After the data acquisition operation starts, the aspect component can obtain the monitoring indication information, determine the function to be monitored based on this information, and record the call stack information of the function to be monitored.

[0119] Step S303: Based on the call stack information, risk identification is performed to obtain the identification result. The identification result is used to indicate whether there is an injection risk during the execution of the data collection service.

[0120] Since the call stack information corresponding to the data acquisition service records the call order and parameters of the functions used to execute the data acquisition service, when an injection attack occurs, the injection attack will leave specific traces in the call stack information. Therefore, analyzing the call stack information can accurately determine whether there is an injection risk.

[0121] In one illustrated implementation, risk identification based on call stack information to obtain identification results includes: for each function to be monitored, obtaining the abnormal features of each function to be monitored, and querying whether there are corresponding abnormal features in the call stack information of each function to be monitored; if there are corresponding abnormal features in the call stack information of any function to be monitored, a first identification result is generated, which indicates that there is an injection risk in the process of executing the data collection service; if there are no corresponding abnormal features in the call stack information of each function to be monitored, a second identification result is generated, which indicates that there is no injection risk in the process of executing the data collection service.

[0122] The abnormal features can be an outlier, an outlier field of a certain type, or a feature vector extracted by a neural network model. This specification does not limit the abnormal features.

[0123] In some embodiments, to more accurately identify risks in call stack information, anomaly features are continuously updated. These anomaly features can be updated by technical personnel or automatically. For example, the server can obtain call stack information from multiple clients, perform feature aggregation on the call stack information from multiple clients, determine discrete features, and use these discrete features as anomaly features. This allows for timely detection of new injection attacks, further improving system security.

[0124] It should be noted that after obtaining the recognition result, further operations or decisions can be made based on the recognition result. Taking the identity management scenario as an example, the data collection service is used to collect the physiological feature data required for identity management. The method also includes: if the recognition result shows that there is an injection risk in the process of performing the data collection service, then the collected physiological feature data is determined to be invalid or the identity management result based on the physiological feature data is invalid.

[0125] Identity management can be identity recognition, for example, identifying whether the current user is the target user; it can also be identity registration, for example, registering an account for the current user; or it can be identity authorization, for example, authorizing a user to access which resources and what operations they can perform on those resources. For example, an authorized user can use the resources in the corresponding account. This specification does not limit the scope of identity management.

[0126] When the identification results indicate that there is an injection risk during the data collection process, the collected physiological feature data may have been tampered with. Using this collected physiological feature data for identity management could seriously impact user information security or property security. Therefore, the collected physiological feature data is deemed invalid, thus preventing identity management based on it. Alternatively, the identity management results made based on the physiological feature data are deemed invalid, preventing tampered physiological feature data from seriously impacting user information security or property security and improving system security.

[0127] Next, this specification will use the face recognition service as an example to illustrate the method of identifying risks injected during the data collection process.

[0128] As shown in Figure 4, the user initiates face recognition on the client side. The client executes the face recognition service to capture facial images. During the image capture process, call stack information is recorded for the key functions used to execute this face recognition service. Furthermore, the face recognition service also processes the captured facial images. For example, it checks whether the captured image includes a complete face. If the captured image does not include a complete face, the user is prompted to move so that the client can capture a complete face. Additionally, the face recognition service can prompt the user to blink or turn their head, determining whether the user has performed these actions based on the captured facial images. Therefore, the key functions used to execute this face recognition service include not only functions for acquiring camera data but also functions for facial feature recognition.

[0129] The client uploads the recorded call stack information to the server. The server then analyzes this call stack information to determine if any abnormal features are detected. If abnormal features are detected, an injection risk is identified, further access based on the facial recognition result is denied to the client, and the corresponding log is logged. If no abnormal features are detected, further access based on the facial recognition result is granted to the client.

[0130] In the above technical solution, by recording the call stack information of the function used to perform the data acquisition business during the execution of the data acquisition business, it is possible to identify whether there is an injection risk during the execution of the data acquisition business. In this way, the identification result can be referenced when performing a series of operations and decisions based on the acquired data, which can avoid injection attacks from having a serious impact on subsequent operations and decisions, thereby improving the security of the system.

[0131] Since the call stack information is a stack structure formed by function calls during program execution, recording the function call order and parameters, when an injection attack occurs, the injection attack will leave specific traces in the call stack information. Therefore, analyzing the call stack information can accurately determine whether there is an injection risk.

[0132] Furthermore, combining the solutions provided in this manual with other protective measures against security threats can cover the entire data lifecycle, cope with more complex and ever-changing security environments, and provide users with more secure and reliable security protection.

[0133] Figure 5 is a flowchart of a method for identifying injection risks during data acquisition, provided by an exemplary embodiment. The system shown in Figure 1 can be the implementer of this method. As shown in Figure 5, the method includes steps S501 to S502.

[0134] In step S501, during the execution of the data acquisition service, the client records the call stack information for the function used to execute the data acquisition service and sends the call stack information to the server.

[0135] In one illustrated implementation, during the execution of a data acquisition service, the client records call stack information for all functions used to perform the data acquisition service.

[0136] In another embodiment shown, during the execution of data acquisition services, the client records call stack information for the functions used to perform the data acquisition services.

[0137] In some embodiments, during the execution of data acquisition services, the client records call stack information for certain functions used to perform the data acquisition services, including: during the execution of data acquisition services, the client records call stack information for key functions used to perform the data acquisition services. In another embodiment, during the execution of data acquisition services, the client records call stack information for each function to be monitored based on monitoring indication information.

[0138] The monitoring indication information can be generated by the client itself or obtained from the server. The generation process of the monitoring indication information can refer to step S301 above, and will not be repeated here. Only the interaction method of the client obtaining the monitoring indication information from the server will be illustrated.

[0139] In some embodiments, the method further includes: the client responding to the start command of the data acquisition service by sending a monitoring indication acquisition request to the server, the monitoring indication acquisition request being used to indicate the operating environment of the data acquisition service; the server receiving the monitoring indication acquisition request, generating monitoring indication information based on the operating environment of the data acquisition service, and returning the monitoring indication information to the client based on the monitoring indication acquisition request; the client receiving the monitoring indication information, and recording call stack information for each function to be monitored based on the monitoring indication information during the execution of the data acquisition service.

[0140] In step S502, the server receives the call stack information, performs risk identification based on the call stack information, and obtains the identification result. The identification result is used to indicate whether there is an injection risk during the execution of the data collection service.

[0141] Step S502 is similar to step S303, and can be referred to step S303. It will not be described in detail here.

[0142] After receiving the recognition result, the server can perform further operations or decisions based on the recognition result; or, it can send the recognition result to the client so that the client can perform further operations or decisions based on the recognition result. The specific situation can be configured according to business needs, and this manual does not limit it.

[0143] It should be noted that this specification only uses the embodiment shown in Figure 5 as an example to illustrate the cooperation between the client and the server in completing the risk injection method during the identification data collection process. It does not limit the specific steps executed by the client and server during this process. In another embodiment, the client performs risk identification based on the call stack information, obtains the identification result, and sends the identification result to the server; alternatively, the client sends the collected data and the identification result to the server.

[0144] In the above technical solution, by recording the call stack information of the function used to perform the data acquisition business during the execution of the data acquisition business, it is possible to identify whether there is an injection risk during the execution of the data acquisition business. In this way, the identification result can be referenced when performing a series of operations and decisions based on the acquired data, which can avoid injection attacks from having a serious impact on subsequent operations and decisions, thereby improving the security of the system.

[0145] Since the call stack information is a stack structure formed by function calls during program execution, recording the function call order and parameters, when an injection attack occurs, the injection attack will leave specific traces in the call stack information. Therefore, analyzing the call stack information can accurately determine whether there is an injection risk.

[0146] Furthermore, combining the solutions provided in this manual with other protective measures against security threats can cover the entire data lifecycle, cope with more complex and ever-changing security environments, and provide users with more secure and reliable security protection.

[0147] Figure 6 is a schematic structural diagram of a device provided in an exemplary embodiment. Referring to Figure 6, at the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile memory 610, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 602 reads the corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0148] Please refer to Figure 7. The device for identifying injection risks during data acquisition can be applied to the device shown in Figure 6 to achieve the technical solution of this specification. The device for identifying injection risks during data acquisition may include: an acquisition unit 701, used to acquire call stack information corresponding to the data acquisition service; the call stack information is the call stack information recorded for the function used to perform the data acquisition service during the execution of the data acquisition service; and an identification unit 702, used to perform risk identification based on the call stack information and obtain an identification result, which indicates whether injection risks exist during the execution of the data acquisition service.

[0149] In one illustrated embodiment, the call stack information includes the call stack information of the function to be monitored, as indicated by the monitoring indication information, which is determined based on the operating environment of the data acquisition service; wherein, the function to be monitored includes at least a portion of the functions used to perform the data acquisition service.

[0150] In one embodiment shown, the process of generating monitoring indication information includes: determining the risk level of the data acquisition service based on the operating environment of the data acquisition service; and determining the monitoring indication information that matches the risk level from multiple candidate monitoring indication information based on the risk level of the data acquisition service, wherein the risk level corresponding to the multiple candidate monitoring indication information is positively correlated with the number of functions to be monitored indicated.

[0151] In one illustrated embodiment, the process of generating monitoring indication information includes: determining the risk level of the data acquisition service based on its operating environment; determining the number of functions to be monitored based on the risk level of the data acquisition service, obtaining a monitoring quantity, wherein the monitoring quantity is positively correlated with the risk level; selecting the key functions to be monitored from the key functions used to perform the data acquisition service; or, selecting the functions to be monitored from the functions used to perform the data acquisition service in descending order of attack probability; or, selecting the functions to be monitored from the functions used to perform the data acquisition service in descending order of importance; and generating monitoring indication information for the data acquisition service based on the selected monitoring functions.

[0152] In one illustrated implementation, the operating environment includes at least two environmental attributes among the current login account, device type, region, and application scenario; the process of generating monitoring indication information includes: determining the monitoring strategies corresponding to the at least two environmental attributes based on the at least two environmental attributes included in the operating environment; and merging the monitoring functions corresponding to the at least two determined monitoring strategies to obtain monitoring indication information.

[0153] In one illustrated implementation, the call stack information is the call stack information recorded for a portion of the functions used to perform the data acquisition service, and the record objects corresponding to the call stack information of two adjacent execution processes of the data acquisition service are not exactly the same.

[0154] In one illustrated embodiment, the data collection service is used to collect physiological characteristic data required for identity management. The apparatus further includes a determination unit, which determines that the collected physiological characteristic data or the identity management result based on the physiological characteristic data is invalid if the identification result indicates that there is an injection risk during the execution of the data collection service.

[0155] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0156] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0157] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

Claims

1. A method for identifying injection risks during data collection, the method comprising: Obtain the call stack information corresponding to the data acquisition service. The call stack information is the call stack information recorded for the function used to execute the data acquisition service during the execution of the data acquisition service. Risk identification is performed based on the call stack information to obtain identification results, which are used to indicate whether there is injection risk during the execution of the data collection service.

2. The method according to claim 1, wherein the call stack information includes the call stack information of the function to be monitored indicated by the monitoring indication information, and the monitoring indication information is determined based on the operating environment of the data acquisition service; wherein, The function to be monitored includes at least a portion of the functions used to perform the data acquisition service.

3. The method according to claim 2, wherein the process of generating the monitoring indication information includes: Based on the operating environment of the data acquisition service, determine the risk level of the data acquisition service; Based on the risk level of the data acquisition service, monitoring indication information matching the risk level is determined from multiple alternative monitoring indication information. The risk level corresponding to the multiple alternative monitoring indication information is positively correlated with the number of functions to be monitored indicated.

4. The method according to claim 2, wherein the process of generating the monitoring indication information includes: Based on the operating environment of the data acquisition service, determine the risk level of the data acquisition service; Based on the risk level of the data acquisition service, the number of functions that need to be monitored is determined, and the number of monitoring functions is obtained. The number of monitoring functions is positively correlated with the risk level. From the key functions used to perform the data collection service, select the key function for the number of monitoring points as the function to be monitored; or, in order of attack probability from high to low, select the function for the number of monitoring points as the function to be monitored from the functions used to perform the data collection service; or, in order of importance from high to low, select the function for the number of monitoring points as the function to be monitored from the functions used to perform the data collection service. Based on the selected function to be monitored, monitoring indication information for the data acquisition service is generated.

5. The method according to claim 2, wherein the operating environment includes at least two environmental attributes from the following: current login account, device type, region, and application scenario; The process of generating the monitoring indication information includes: Based on at least two environmental attributes included in the operating environment, determine the monitoring strategies corresponding to each of the at least two environmental attributes; The monitoring functions corresponding to at least two identified monitoring strategies are merged to obtain the monitoring indication information.

6. The method according to claim 1, wherein the call stack information is the call stack information recorded for a portion of the functions used to execute the data acquisition service, and the record objects corresponding to the call stack information of two adjacent execution processes of the data acquisition service are not completely the same.

7. The method according to claim 1, wherein the data collection service is used to collect physiological characteristic data required for identity management, and the method further includes: If the identification result indicates that there is an injection risk during the execution of the data collection service, then the collected physiological feature data is determined to be invalid or the identity management result based on the physiological feature data is invalid.

8. A system for identifying injection risks during data collection, the system comprising a client and a server; The client is used to record call stack information for the function used to perform the data acquisition business during the execution of the data acquisition business, and send the call stack information to the server. The server is used to receive the call stack information, perform risk identification based on the call stack information, and obtain an identification result. The identification result is used to indicate whether there is an injection risk during the execution of the data collection service.

9. An electronic device, comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1-7 by executing the executable instructions.

10. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-7.

Images