Risk control data acquisition method and device, electronic equipment and medium

Abstract

The embodiment of the invention provides a risk control data acquisition method and device, electronic equipment and a medium, and relates to the technical field of computers.The method comprises the steps that in response to a login request for a mailbox application, a request identifier of the login request is acquired to serve as a target request identifier, and first risk control data corresponding to the login request is acquired; collecting a log of a proxy server used by the mailbox application, obtaining a request identifier and second risk control data recorded in the log, and obtaining a first corresponding relationship; the second risk control data is non-encrypted risk control data having the same function as the encrypted risk control data; determining third risk control data matched with the target request identifier from the second risk control data according to the first corresponding relationship; determining encrypted risk control data according to the third risk control data; and combining the first risk control data and the encrypted risk control data to obtain risk control data of the mailbox application. By applying the technical scheme of the embodiment of the invention, the risk control data can be obtained under the condition of avoiding an encryption technology.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device and medium for acquiring risk control data. Background Technology

[0002] As a core communication tool for businesses and individuals, email carries sensitive data, identity credentials, and other critical information, and has long faced multiple threats such as account theft and data breaches. Therefore, building a real-time, dynamic email risk control system to accurately identify and block risks such as abnormal logins and data leaks has become a key component of modern enterprise security architecture.

[0003] In related technologies, email risk control systems generally rely on in-depth real-time analysis of risk control data. Specifically, this involves collecting data such as login status codes, device fingerprints, client addresses, and account identifiers as risk control data. Then, a risk control feature database is built based on this data, and risk control strategies are determined based on the features in the database. However, in practical applications, some risk control data is sensitive, and email systems use encryption technologies to encrypt sensitive data. This creates a conflict between the encryption settings in email systems and the acquisition of risk control data, making it difficult to obtain the data and thus hindering risk control of the email account. Therefore, how to obtain risk control data while bypassing encryption technologies has become a pressing technical problem to be solved. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, electronic device, and medium for acquiring risk control data, so as to acquire risk control data while bypassing encryption technology. The specific technical solution is as follows:

[0005] In a first aspect of this application, a method for acquiring risk control data is provided, the method comprising:

[0006] In response to a login request for an email application, the request identifier of the login request is obtained as the target request identifier, and the first risk control data corresponding to the login request is obtained, wherein the first risk control data is unencrypted risk control data;

[0007] Logs from the proxy server used by the email application are collected to obtain the request identifier and second risk control data recorded in the logs, and a first correspondence is obtained; the second risk control data is: unencrypted risk control data with the same function as encrypted risk control data; the first correspondence is: the correspondence between the recorded request identifier and the second risk control data;

[0008] Based on the first correspondence, determine the third risk control data that matches the target request identifier from the second risk control data;

[0009] The encrypted risk control data is determined based on the third risk control data;

[0010] The first risk control data and the encrypted risk control data are combined to obtain the risk control data of the email application.

[0011] In some embodiments, determining the encrypted risk control data based on the third risk control data includes:

[0012] According to the preset mapping relationship, the third risk control data is mapped to encrypted risk control data.

[0013] In some embodiments, determining the encrypted risk control data based on the third risk control data includes:

[0014] The third risk control data is used as encrypted risk control data.

[0015] In some embodiments, obtaining the account identifier of the account requested to log in by the login request and obtaining the first risk control data corresponding to the login request includes:

[0016] The hijacking script collects the logs of the proxy server used by the email application, obtains the request identifier and the fourth risk control data recorded in the logs, and obtains the second correspondence relationship, which is: the correspondence relationship between the recorded request identifier and the fourth risk control data.

[0017] Based on the second correspondence, the first risk control data that matches the target request identifier is determined from the fourth risk control data.

[0018] In some embodiments, the method further includes:

[0019] Obtain the link protocol used by the email application;

[0020] The step of obtaining the request identifier of the login request as the target request identifier and obtaining the first risk control data corresponding to the login request includes:

[0021] If the cost of obtaining encrypted risk control data based on the link protocol used by the email application is greater than a preset threshold, then the request identifier of the login request is obtained as the target request identifier, and the first risk control data corresponding to the login request is obtained; wherein, the cost of obtaining encrypted risk control data represents: the difficulty of obtaining encrypted risk control data, or the time required to obtain encrypted risk control data;

[0022] If the cost of obtaining encrypted risk control data based on the link protocol used by the email application is not greater than a preset threshold, then a hijacking script is used to collect the logs of the proxy server used by the email application, and the fifth risk control data and encrypted risk control data recorded in the logs are obtained, as well as the third correspondence relationship is obtained. The third correspondence relationship is: the correspondence between the recorded fifth risk control data and the encrypted risk control data.

[0023] Based on the third correspondence, the fifth risk control data and the encrypted risk control data that have a corresponding relationship are merged to obtain the risk control data of the email application.

[0024] In some embodiments, after merging the first risk control data and the encrypted risk control data to obtain the risk control data of the email application, the method further includes:

[0025] Risk control statistics are performed based on the risk control data of the email application to obtain risk control statistics results;

[0026] A risk control feature library is constructed based on the aforementioned risk control statistics.

[0027] In a second aspect of this application, a risk control data acquisition device is also provided, the device comprising:

[0028] The first acquisition module is used to respond to a login request for an email application, acquire the request identifier of the login request as a target request identifier, and acquire the first risk control data corresponding to the login request, wherein the first risk control data is unencrypted risk control data.

[0029] The second acquisition module is used to collect logs from the proxy server used by the email application, obtain the request identifier and the second risk control data recorded in the logs, and obtain a first correspondence relationship; the second risk control data is: unencrypted risk control data with the same function as encrypted risk control data; the first correspondence relationship is: the correspondence between the recorded request identifier and the second risk control data;

[0030] The first determining module is used to determine, based on the first correspondence, third risk control data that matches the target request identifier from the second risk control data;

[0031] The second determining module is used to determine encrypted risk control data based on the third risk control data;

[0032] The merging module is used to merge the first risk control data and the encrypted risk control data to obtain the risk control data of the email application.

[0033] In some embodiments, the second determining module,

[0034] Specifically, it is used to map the third risk control data into encrypted risk control data according to a preset mapping relationship.

[0035] In some embodiments, the second determining module,

[0036] The third risk control data is used as encrypted risk control data.

[0037] In some embodiments, the first acquisition module includes:

[0038] The submodule is used to collect logs from the proxy server used by the email application using a hijacking script, obtain the request identifier and fourth risk control data recorded in the logs, and obtain a second correspondence relationship, which is the correspondence relationship between the recorded request identifier and the fourth risk control data.

[0039] The determination submodule is used to determine, based on the second correspondence, the first risk control data that matches the target request identifier from the fourth risk control data.

[0040] In some embodiments, the apparatus further includes:

[0041] The third acquisition module is used to acquire the link protocol used by the email application;

[0042] The first acquisition module includes:

[0043] The first acquisition submodule is used to acquire the request identifier of the login request as the target request identifier and acquire the first risk control data corresponding to the login request if the cost of acquiring encrypted risk control data based on the link protocol used by the email application is greater than a preset threshold; wherein, the cost of acquiring encrypted risk control data represents: the difficulty of acquiring encrypted risk control data, or the time required to acquire encrypted risk control data;

[0044] The second acquisition submodule is used to collect the logs of the proxy server used by the email application using a hijacking script if the cost of acquiring encrypted risk control data based on the link protocol used by the email application is not greater than a preset threshold, thereby obtaining the fifth risk control data and encrypted risk control data recorded in the logs, and obtaining a third correspondence relationship, wherein the third correspondence relationship is: the correspondence relationship between the recorded fifth risk control data and the encrypted risk control data.

[0045] The merging submodule is used to merge the fifth risk control data and encrypted risk control data that have a corresponding relationship according to the third correspondence relationship, so as to obtain the risk control data of the email application.

[0046] In some embodiments, the apparatus further includes:

[0047] The statistics module is used to perform risk control statistics based on the risk control data of the email application after merging the first risk control data and the encrypted risk control data to obtain the risk control data of the email application, and to obtain the risk control statistics results.

[0048] The module is used to construct a risk control feature library based on the risk control statistics results.

[0049] In a third aspect of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0050] Memory, used to store computer programs;

[0051] The processor, when executing a program stored in memory, implements any of the risk control data acquisition methods described above.

[0052] In another aspect of this application, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements any of the risk control data acquisition methods described above.

[0053] In another aspect of this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the risk control data acquisition methods or risk control feature library construction methods described above.

[0054] The technical solution provided in this application embodiment, in response to a login request for an email application, obtains the request identifier of the login request as the target request identifier, and obtains the first risk control data corresponding to the login request, wherein the first risk control data is unencrypted risk control data; collects logs from the proxy server used by the email application, obtains the request identifier and the second risk control data recorded in the logs, and obtains a first correspondence relationship; the second risk control data is: unencrypted risk control data with the same function as encrypted risk control data; the first correspondence relationship is: the correspondence between the recorded request identifier and the second risk control data; based on the first correspondence relationship, determines the third risk control data matching the target request identifier from the second risk control data; determines encrypted risk control data based on the third risk control data; and merges the first risk control data and the encrypted risk control data to obtain the risk control data of the email application.

[0055] Understandably, the first and second risk control data obtained above are unencrypted risk control data and are not limited by encryption technology. Furthermore, encrypted risk control data in related technologies has the same function as the second risk control data. Therefore, in this embodiment, third risk control data matching the target request identifier is determined from the second risk control data, and this third risk control data is used to replace the encrypted risk control data. Based on this, merging the encrypted risk control data determined from the third risk control data with the first risk control data yields the risk control data for the email application. Therefore, by applying the risk control data acquisition method provided in this embodiment, and by using unencrypted risk control data with the same function as the encrypted risk control data to replace the encrypted risk control data, risk control data can be obtained while circumventing encryption technology. Attached Figure Description

[0056] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0057] Figure 1 This is a first schematic diagram of a risk control data acquisition method provided in an embodiment of this application;

[0058] Figure 2 This is a second schematic diagram of the risk control data acquisition method provided in the embodiments of this application;

[0059] Figure 3 A detailed schematic diagram of step S24 provided in the embodiments of this application;

[0060] Figure 4 This is a third schematic diagram of the risk control data acquisition method provided in the embodiments of this application;

[0061] Figure 5 This is a first schematic diagram of the risk control statistics system provided in the embodiments of this application;

[0062] Figure 6 This is a second schematic diagram of the risk control statistics system provided in the embodiments of this application;

[0063] Figure 7 This is a third schematic diagram of the risk control statistics system provided in the embodiments of this application;

[0064] Figure 8 A schematic diagram of a risk control data acquisition device provided in an embodiment of this application;

[0065] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0066] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0067] The risk control data acquisition method provided in this application is applied to electronic devices, such as desktop computers, portable computers, and smart mobile terminals.

[0068] The risk control data acquisition method provided in this application embodiment will be described in detail below through specific examples:

[0069] See Figure 1 , Figure 1 A first schematic diagram of the risk control data acquisition method provided in this application embodiment includes the following steps:

[0070] Step S11: In response to the login request for the email application, obtain the request identifier of the login request as the target request identifier, and obtain the first risk control data corresponding to the login request. The first risk control data is unencrypted risk control data.

[0071] Step S12: Collect the logs of the proxy server used by the email application, obtain the request identifier and the second risk control data recorded in the logs, and obtain the first correspondence relationship; the second risk control data is: unencrypted risk control data with the same function as encrypted risk control data; the first correspondence relationship is: the correspondence between the recorded request identifier and the second risk control data;

[0072] Step S13: Based on the first correspondence, determine the third risk control data that matches the target request identifier from the second risk control data;

[0073] Step S14: Determine the encrypted risk control data based on the third-party risk control data;

[0074] Step S15: Merge the first risk control data and the encrypted risk control data to obtain the risk control data for the email application.

[0075] The technical solution provided in this application embodiment, in response to a login request for an email application, obtains the request identifier of the login request as the target request identifier, and obtains the first risk control data corresponding to the login request, wherein the first risk control data is unencrypted risk control data; collects logs from the proxy server used by the email application, obtains the request identifier and the second risk control data recorded in the logs, and obtains a first correspondence relationship; the second risk control data is: unencrypted risk control data with the same function as encrypted risk control data; the first correspondence relationship is: the correspondence between the recorded request identifier and the second risk control data; based on the first correspondence relationship, determines the third risk control data matching the target request identifier from the second risk control data; determines encrypted risk control data based on the third risk control data; and merges the first risk control data and the encrypted risk control data to obtain the risk control data of the email application.

[0076] Understandably, the first and second risk control data obtained above are unencrypted risk control data and are not limited by encryption technology. Furthermore, encrypted risk control data in related technologies has the same function as the second risk control data. Therefore, in this embodiment, third risk control data matching the target request identifier is determined from the second risk control data, and this third risk control data is used to replace the encrypted risk control data. Based on this, the encrypted risk control data determined from the third risk control data and the first risk control data are merged to obtain the risk control data for the email application. Therefore, by applying the risk control data acquisition method provided in this embodiment, and by using unencrypted risk control data with the same function as the encrypted risk control data to replace the encrypted risk control data, risk control data can be obtained without encryption technology.

[0077] In step S11 above, the email application can be in the form of a client application, webmail, etc. The target request identifier is the request identifier of the login request initiated by the email application in response to the user's login operation when the user logs in; for example, when the user opens the login interface of the email application, enters the username and password and clicks the login button, the email application generates a login request in response to the user's click on the login button, and the target request identifier is the request identifier of this login request.

[0078] The first risk control data corresponding to the above login request can specifically be: the account identifier of the account requested to log in, the client address of the client to which the email application belongs, and the transmission channel identifier of the transmission channel used by the email application. For ease of description, they are referred to as: target account identifier, target client address, and target transmission channel identifier, respectively.

[0079] The target account identifier is the account identifier of the account requested in the target login request. For example, if the target login request requests account 1, then the target account identifier is the identifier of account 1. The target client address is the client address of the client to which the email application belongs. It can also be understood as the address of the terminal device used by the user to access the email application. For example, if email application 1 is installed on desktop computer 1, and the user logs into their email account through email application 1 on desktop computer 1, and email application 1 initiates a login request in response to the user's login operation, then when this login request is the target login request, the target client address is the address of desktop computer 1. The target transmission channel refers to the transmission channel identifier of the transmission channel used by the email application.

[0080] It should be noted that the aforementioned first risk control data is unencrypted risk control data, and the specific form of the aforementioned first risk control data is merely illustrative and does not serve as a limitation.

[0081] In some embodiments, in response to a login request for an email application, an electronic device can use a hijacking script to collect logs from the proxy server used by the email application, obtain the request identifier and fourth risk control data recorded in the logs, and obtain a second correspondence between the request identifier and the fourth risk control data. Then, based on the second correspondence, the first risk control data matching the target request identifier is determined from the fourth risk control data.

[0082] The hijacking script can be a Lua hijacking script, a Python hijacking script, a shell hijacking script, etc. The fourth risk control data includes the first risk control data. Simply put, electronic devices can use hijacking scripts to collect logs from the proxy server used by email applications, obtaining the risk control data corresponding to the request identifiers of different login requests recorded in the logs. This data is collectively referred to as the fourth risk control data, while the first risk control data is the risk control data corresponding to the target request identifier within the fourth risk control data.

[0083] For example, the electronic device can obtain the fourth risk control data corresponding to the request identifier 1 of login request 1 recorded in the log, which can be represented as (request identifier 1, account identifier 1, client address 1, transmission channel identifier 1), the risk control data corresponding to the request identifier 2 of login request 2 can be represented as (request identifier 2, account identifier 2, client address 2, transmission channel identifier 2), and the risk control data corresponding to the request identifier 1 of login request 3 can be represented as (request identifier 3, account identifier 3, client address 3, transmission channel identifier 3).

[0084] Meanwhile, the logs of the proxy server used by the email application record the correspondence between the request identifier and the fourth risk control data (the second correspondence).

[0085] Continuing the previous example, the second correspondence can be the correspondence between request identifier, account identifier, client address, and transmission channel identifier. When an electronic device uses a hijacking script to hijack the request identifier, account identifier, client address, and transmission channel identifier, it will also hijack the correspondence between them. Here, the correspondence between request identifier, account identifier, client address, and transmission channel identifier means that the request identifier, account identifier, client address, and transmission channel identifier are for the same login request. Specifically, "request identifier, account identifier, client address, and transmission channel identifier for the same login request" can be understood as follows: the request identifier is the identifier of the login request; the account identifier is the identifier of the account requested by the login request; the transmission channel identifier is the identifier of the transmission channel used by the email application to which the login request belongs; and the client address is the client address of the client to which the email application to which the login request belongs.

[0086] Then, the electronic device can determine the first risk control data that matches the target request identifier from the fourth risk control data based on the second correspondence.

[0087] Continuing the previous example, based on the second correspondence and the fourth risk control data, we can obtain the following data: (Request Identifier 1, Account Identifier 1, Client Address 1, Transmission Channel Identifier 1), (Request Identifier 2, Account Identifier 2, Client Address 2, Transmission Channel Identifier 2), and (Request Identifier 3, Account Identifier 3, Client Address 3, Transmission Channel Identifier 3). Assuming the target request identifier is Request Identifier 1, and since there is a correspondence between Request Identifier 1, Account Identifier 1, Client Address 1, and Transmission Channel Identifier 1, we can use Account Identifier 1 as the target account identifier, Client Address 1 as the target client address, and Transmission Channel Identifier 1 as the target transmission channel identifier. The target account identifier, target client address, and target transmission channel identifier can be used as the first risk control data.

[0088] It should be noted that the request identifier is not part of the risk control data. Therefore, in related technologies, when using hijacking scripts to collect logs from the proxy server used by the email application, the request identifier is generally not collected. However, in this embodiment, the reason for hijacking the request identifier is to associate the first risk control data with the third risk control data obtained subsequently. This process will be described in detail later.

[0089] In other embodiments, in response to a login request for an email application, the electronic device can also use a hijacking script to directly query and hijack the request identifier of the login request and the first risk control data corresponding to the login request from the logs of the proxy server. This includes information such as the account identifier of the account requested to log in, the client address of the client to which the email application that initiated the login request belongs, and the transmission channel identifier of the transmission channel used by the email application that initiated the login request. Thus, the request identifier hijacked by the electronic device becomes the target request identifier, the account identifier becomes the target account identifier, the client address becomes the target client address, and the transmission channel identifier becomes the target transmission channel identifier. This allows for direct hijacking and acquisition of the first risk control data without needing to determine the first risk control data from the fourth risk control data based on a corresponding relationship.

[0090] For example, in response to a login request for an email application, the electronic device uses a hijacking script to query and hijack the request identifier of the login request in the logs of the proxy server. The request identifier is called request identifier 1, the account identifier of the account requested by the login request is account identifier 1, the client address of the client to which the email application that initiated the login request belongs is client address 1, and the transmission channel identifier of the transmission channel used by the email application that initiated the email login request is transmission channel identifier 1. Then, request identifier 1 is the target request identifier, account identifier 1 is the target account identifier, client address 1 is the target client address, and transmission channel identifier 1 is the transmission channel identifier, which means that the first risk control data is directly obtained.

[0091] In step S12 above, the electronic device collects the logs of the proxy server used by the email application, obtains the request identifier and the second risk control data recorded in the logs, and obtains the second correspondence between the recorded request identifier and the second risk control data.

[0092] The second risk control data mentioned above is also unencrypted risk control data. Unlike the first risk control data, the second risk control data is unencrypted risk control data that has the same function as the encrypted risk control data.

[0093] For example, encrypted risk control data may include login status codes and device fingerprints. Since these are sensitive data, related technologies encrypt them. Secondary risk control data may include response status codes and user agent information. Login status codes provide the success or failure status of the login request for email risk control, and response status codes also reflect the success or failure status of the login request. Device fingerprints reflect the device information of the client to which the email application that initiated the login request belongs, and user agent information also reflects the device information of the client to which the email application that initiated the login request belongs.

[0094] It should be noted that the specific form of the aforementioned second risk control data is merely illustrative and does not constitute a limitation.

[0095] Understandably, the logs of the proxy server used by the email application record the request identifier and the second risk control data, as well as the correspondence between the request identifier and the second risk control data.

[0096] Taking the second risk control data, which includes response status codes and user agent information, as an example, the electronic device can obtain the second risk control data corresponding to request identifier 1 of login request 1 recorded in the log, which can be represented as (request identifier 1, response status code 1, user agent information 1), the second risk control data corresponding to request identifier 2 of login request 2 can be represented as (request identifier 2, response status code 2, user agent information 2), and the second risk control data corresponding to request identifier 1 of login request 3 can be represented as (request identifier 1, response status code 3, user agent information 3).

[0097] At the same time, the log also records the correspondence between the request identifier and the second risk control data (the first correspondence).

[0098] Continuing the previous example, the first correspondence can be the correspondence between the request identifier, response status code, and user agent information. When collecting request identifiers, response status codes, and user agent information recorded in the electronic device's logs, the correspondence between them will also be collected. Here, the correspondence between the request identifier, response status code, and user agent information means that the request identifier, response status code, and user agent information are for the same login request. Specifically, for the same login request, the request identifier is the identifier of the login request, the response status code indicates whether the login request was successful, and the user agent information indicates the device information of the client to which the login request belongs.

[0099] The request identifier is the identifier for the login request; the response status code indicates whether the login request was successful, that is, whether the login operation to which the login request belongs was successful. For example, taking a response status code of 400 as success and a response status code of 401 as failure, in response to a user's login operation, the email application initiates a login request. If the intercepted login request has a response status code of 400, it indicates that the login request was successful, meaning the user successfully logged in; if the intercepted login request has a response status code of 401, it indicates that the login request failed, meaning the user did not successfully log in. User agent information is used to represent the device information of the client to which the email application belongs, including device type, operating system type, email application version, etc.

[0100] In step S13 above, based on the first correspondence determined in step S12 above, the electronic device determines the third risk control data that matches the target request identifier from the second risk control data.

[0101] Specifically, after the electronic device collects the request identifier and the second risk control data, as well as the first correspondence between the request identifier and the second risk control data, it can determine the third risk control data that matches the target request identifier from the second risk control data.

[0102] Continuing the previous example, based on the first correspondence and the second risk control data, we can obtain the following data: (Request Identifier 1, Response Status Code 1, User Agent Information 1), (Request Identifier 2, Response Status Code 2, User Agent Information 2), and (Request Identifier 3, Response Status Code 3, User Agent Information 3). Assuming the target request identifier is Request Identifier 1, and since there is a correspondence between Request Identifier 1, Response Status Code 1, and User Agent Information 1, we can use Response Status Code 1 as the target response status code and User Agent Information 1 as the target user agent information. The target response status code and the target user agent information can be used as the third risk control data.

[0103] In step S14 above, the electronic device can determine the encrypted risk control data based on the third risk control data.

[0104] Since the third risk control data is determined from the second risk control data, which is unencrypted risk control data with the same function as encrypted risk control data, the third risk control data is also unencrypted risk control data with the same function as encrypted risk control data. Therefore, electronic devices can use the third risk control data to replace encrypted risk control data.

[0105] In some embodiments, electronic devices may map third-party risk control data to encrypted risk control data according to a preset mapping relationship.

[0106] The status values ​​of third-party risk control data and encrypted risk control data may not correspond completely. Therefore, a mapping relationship between third-party risk control data and encrypted risk control data can be established in advance. Based on the preset mapping relationship, the third-party risk control data can be mapped to encrypted risk control data.

[0107] For example, when the encrypted risk control data is a login status code and the third encrypted risk control data is a response status code, the login status code and the response status code have the same function and can both reflect the success or failure status of the login request.

[0108] Login status codes have only two values: one indicating successful login and the other indicating login failure. Response status codes have hundreds of values, all of which can reflect the success or failure of a login request. However, these hundreds of values ​​can provide more detailed explanations of the reasons for successful or failed login.

[0109] Therefore, electronic devices can pre-establish a mapping relationship between various status values ​​of response status codes and two status values ​​of login status codes. Based on this pre-defined mapping relationship, response status codes are mapped to login status codes, thus realizing the mapping of third-party risk control data to encrypted risk control data.

[0110] In this embodiment, the reason for mapping based on the mapping relationship is to ensure the reusability of risk control data, when the state values ​​of the third risk control data and the encrypted risk control data may not correspond completely. By mapping the relationship, the third risk control data and the encrypted risk control data can be completely matched. In this way, whether the risk control data is obtained by the risk control data acquisition method of this embodiment or by the risk control data acquisition method in the prior art, they can be matched, thus realizing the reuse of risk control data.

[0111] In some embodiments, electronic devices can directly use third-party risk control data as encrypted risk control data.

[0112] The status values ​​of third-party risk control data and encrypted risk control data may correspond completely, so third-party risk control data can be directly used as encrypted risk control data.

[0113] For example, when the encrypted risk control data is a device fingerprint and the third encrypted risk control data is user agent information, the login status code and the response status code have the same function, both reflecting the device information of the client to which the email application that initiated the login request belongs.

[0114] The status values ​​of device fingerprints and user agent information are completely correlated. Therefore, electronic devices can directly use the response status code as the login status code, which enables the determination of encrypted risk control data based on third-party risk control data.

[0115] In step S15 above, it can be understood that, based on step S11 above, the electronic device obtains the first risk control data corresponding to the target request identifier. Based on steps S12-S14 above, the electronic device obtains the third risk control data corresponding to the target request identifier, and determines the encrypted risk control data based on the third risk control data. Based on this, the first risk control data and the encrypted risk control data are merged to obtain the risk control data for the email application.

[0116] It's easy to understand that the first risk control data is determined based on the target request identifier, the third risk control data is also determined based on the target request identifier, and the encrypted risk control data is determined based on the third risk control data. Merging the first risk control data and the encrypted data is essentially merging them using the target request identifier.

[0117] For example, the target request identifier is Request Identifier 1. The determined first risk control data is (Account Identifier 1, Client Address 1, Transmission Channel Identifier 1), and the determined third risk control data is (Response Status Code 1, User Agent Information 1). That is, Request Identifier 1 corresponds to Account Identifier 1, Client Address 1, and Transmission Channel Identifier 1, and also corresponds to Response Status Code 1 and User Agent Information 1. Response Status Code 1 replaces the login status code, and User Agent Information 1 replaces the device fingerprint. Based on Request Identifier 1, Account Identifier 1, Client Address 1, Transmission Channel Identifier 1, Response Status Code 1, and User Agent Information 1 are merged to obtain the risk control data for the email application. The descriptions of the login status code and device fingerprint can be found below. Figure 3 The contents of that document will not be repeated here.

[0118] Corresponding to the above Figure 1 In some embodiments, in response to a login request for an email application, the electronic device also obtains the link protocol used by the email application and determines whether the cost of obtaining encrypted risk control data based on the link protocol used by the email application exceeds a preset threshold. If the cost of obtaining encrypted risk control data based on the link protocol used by the email application exceeds the preset threshold, then execution is performed. Figure 1 The example shown is to perform steps S11-S15 as described above.

[0119] If the cost of obtaining encrypted risk control data based on the link used by the email application is not greater than a preset threshold, then the hijacking script is used to collect the logs of the proxy server used by the email application to obtain the fifth risk control data and encrypted risk control data, as well as the third correspondence between the fifth risk control data and the encrypted risk control data. Then, based on the third correspondence, the fifth risk control data and the encrypted risk control data that have a corresponding relationship are merged to obtain the risk control data of the email application.

[0120] The cost of obtaining encrypted risk control data based on the link protocol used by the email application can be understood as the difficulty of obtaining login status codes and device fingerprints, or the time required to obtain them. The preset threshold is set by the user based on actual circumstances. Simply put, if the cost of obtaining encrypted risk control data based on the link protocol used by the email application exceeds the preset threshold, then the link protocol is generally considered encrypted; otherwise, it is considered unencrypted.

[0121] In some embodiments, links where the cost of acquiring encrypted risk control data exceeds a preset threshold include EWS and autodiscover. See the description in step S21 below for details.

[0122] Specifically, through the following Figure 2 and Figure 3The example shown illustrates the link selection risk control data collection method used by the email application.

[0123] See Figure 2 , Figure 2 A second schematic diagram of the risk control data acquisition method provided in the embodiments of this application may include the following steps:

[0124] Step S21: In response to a login request for the email application, obtain the link protocol used by the email application;

[0125] Step S22: Determine whether the cost of obtaining encrypted risk control data based on the link protocol used by the email application is greater than a preset threshold;

[0126] If yes, proceed to step S23; otherwise, proceed to step S24.

[0127] Step S23: Use a hijacking script to collect the first risk control data; collect the logs of the proxy server used by the email application to obtain the third risk control data; determine the encrypted risk control data based on the third risk control data, merge the first risk control data and the encrypted risk control data to obtain the risk control data of the email application.

[0128] Step S24: Use the hijacking script to collect the logs of the proxy server used by the email application, obtain the fifth risk control data and encrypted risk control data, and obtain the third correspondence relationship. Based on the third correspondence relationship, merge the fifth risk control data and encrypted risk control data that have a corresponding relationship to obtain the risk control data of the email application.

[0129] The third correspondence is the correspondence between the recorded fifth risk control data and the encrypted risk control data.

[0130] In the technical solution provided in this application embodiment, it is understood that when it is difficult to obtain encrypted risk control data based on the link used by the email application, the first risk control data and the third risk control data are obtained, the encrypted risk control data is determined based on the third risk control data, and the first risk control data and the encrypted risk control data are merged to obtain the risk control data of the email application. In this way, when it is difficult to obtain encrypted risk control data based on the link used by the email application, the third encrypted data with the same function as the encrypted risk control data can be used to replace the encrypted risk control data to obtain the risk control data of the email application.

[0131] When the link protocol used by the email application makes it not difficult to obtain encrypted risk control data, encrypted risk control data reflects more information about risk control compared to third-party risk control data. This allows for a more comprehensive risk control feature database within the email application's risk control system. Therefore, when the link protocol used by the email application makes it not difficult to obtain encrypted risk control data, the corresponding fifth-party risk control data and encrypted risk control data are merged to obtain the email application's risk control data. This improves the accuracy and completeness of the obtained risk control data.

[0132] In step S21 above, in response to a login request for the email application, the link used by the email application is obtained. The link used by the email application can be understood as the type of channel used to log in via the email application.

[0133] Specifically, when logging in using a third-party email application or mobile device such as a tablet or phone, the email application typically uses ActiveSYNIC; when logging in using a browser, the email application uses OWA; when logging in using Outlook, the email application mostly uses OA, and in some cases uses EWS; when logging in using email software on some mobile devices, the email application also uses EWS; and when Outlook loads a configuration file, the email application uses AutoDiscover.

[0134] In step S22 above, after determining the link used by the email application, the electronic device determines whether the link used by the email application is EWS or autodiscover. If the link used by the email application is EWS or autodiscover, it indicates that encrypted risk control data cannot be obtained without bypassing encryption technology, and the subsequent step S23 needs to be executed. If the link used by the email application is not EWS or autodiscover, it indicates that encrypted risk control data can be obtained without bypassing encryption technology, and the subsequent step S24 can be executed.

[0135] In step S23 above, the process of collecting the first risk control data using the LUA hijacking script can be found in the description of step S11 above. The process of collecting logs from the proxy server used by the email application to obtain the third risk control data, and determining the encrypted risk control data based on the third risk control data, can be found in the descriptions of steps S12 and S14 above. The process of merging the first risk control data and the encrypted risk control data to obtain the risk control data for the email application can be found in the description of step S15 above.

[0136] In step S24 above, the logs of the proxy server used by the email application are collected using the LUA hijacking script to obtain the fifth risk control data and the encrypted risk control data, as well as the third correspondence between the fifth risk control data and the encrypted risk control data. Based on the third correspondence, the fifth risk control data and the encrypted risk control data that have a corresponding relationship are merged to obtain the risk control data of the email application. The process can be found in the description of step S33 below.

[0137] See Figure 3 , Figure 3 A detailed schematic diagram of step S24 provided in the embodiments of this application may include the following steps:

[0138] Step S31: Use the hijacking script to collect the logs of the proxy server used by the email application, and obtain the fifth risk control data and encrypted risk control data recorded in the logs, as well as the recorded third correspondence.

[0139] The third correspondence is the correspondence between the recorded fifth risk control data and the encrypted risk control data.

[0140] Step S32: Based on the third correspondence, the fifth risk control data and the encrypted risk control data that have a corresponding relationship are used as the target risk control data and the target encrypted risk control data;

[0141] Step S33: Merge the target risk control data and the target encrypted risk control data to obtain the risk control data for the email application.

[0142] The technical solution provided in this application clarifies a method for obtaining encrypted risk control data by using a hijacking script to collect logs from the application proxy server of the email application, when the cost of obtaining encrypted risk control data based on the link used by the email application is less than a preset threshold. Since encrypted risk control data can reflect more information about risk control, it can make the risk control feature database in the email risk control system more complete.

[0143] In step S31 above, the electronic device uses a hijacking script to collect logs from the proxy server used by the email application, obtains the fifth risk control data and encrypted risk control data recorded in the logs, and records the third correspondence between the fifth risk control data and the encrypted risk control data.

[0144] For example, the fifth risk control data is unencrypted risk control data, which can be the same type of data as the fourth risk control data mentioned above. For instance, the fifth risk control data could be an account identifier, client address, or transmission channel identifier. Encrypted risk control data could be a login status code, device fingerprint, or user password.

[0145] At the same time, electronic devices can obtain the correspondence between account identifiers, client addresses, transmission channel identifiers, login status codes, device fingerprints, and user passwords recorded in the logs.

[0146] Here, the correspondence between account identifier, client address, transmission channel identifier, login status code, device fingerprint, and user password refers to the following: account identifier, client address, transmission channel identifier, login status code, device fingerprint, and user password are for the same login request. Specifically, for the same login request, the account identifier is the identifier of the account requested in the login request; the transmission channel identifier is the identifier of the transmission channel used by the email application to which the login request belongs; the client address is the client address of the client to which the email application to which the login request belongs; the login status code indicates whether the login request was successful; the device fingerprint is the device information of the client to which the email application to which the login request belongs; and the user password is the password used to initiate the login request.

[0147] In this embodiment, the user password represents the password parameter used by the user when logging into their email account. The login status code indicates whether the login request was successful. Compared to the response status code mentioned above, while both login and response status codes can indicate whether a login request was successful, login status codes tend to represent the overall status of the login request, i.e., whether the login was successful or failed. Response status codes tend to provide a more detailed description of the reason for the failure, such as incorrect parameters or system errors.

[0148] Device fingerprints are used to represent the device information of the email application's client. Compared to the user agent information mentioned above, while both user agent information and device fingerprints can represent the device information of the email application's client, device fingerprints can represent richer information. For example, compared to user agent information, device fingerprints can also represent the device screen size, the user's information within the company system, and so on. Device information refers to information that uniquely identifies the client.

[0149] In step S32 above, based on the third correspondence recorded in step S31, the electronic device uses the fifth risk control data and encrypted risk control data that have a corresponding relationship as the target risk control data and target encrypted risk control data. That is, the fifth risk control data for the same request identifier is used as the target risk control data, and the encrypted risk control data for the same request identifier is used as the target encrypted risk control data.

[0150] In step S33 above, the electronic device can merge the target risk control data and the target encrypted risk control data to obtain the risk control data for the email application. This process is similar to step S15 above, and please refer to the description of step S15.

[0151] See Figure 4 This is a third schematic diagram of a risk control data acquisition method provided in this application embodiment. The method may include the following steps:

[0152] Step S41: In response to the login request for the email application, obtain the request identifier of the login request as the target request identifier, and obtain the first risk control data corresponding to the login request. The first risk control data is unencrypted risk control data.

[0153] Step S42: Collect the logs of the proxy server used by the email application, obtain the request identifier and the second risk control data recorded in the logs, and obtain the first correspondence; the second risk control data is: unencrypted risk control data with the same function as encrypted risk control data; the first correspondence is: the correspondence between the recorded request identifier and the second risk control data;

[0154] Step S43: Based on the first correspondence, determine the third risk control data that matches the target request identifier from the second risk control data;

[0155] Step S44: Determine the encrypted risk control data based on the third-party risk control data;

[0156] Step S45: Merge the first risk control data and the encrypted risk control data to obtain the risk control data for the email application;

[0157] Step S46: Perform risk control statistics based on the risk control data of the email application to obtain the risk control statistics results;

[0158] Step S47: Construct a risk control feature library based on the risk control statistics results.

[0159] In the technical solution provided in this application embodiment, after obtaining the risk control data of the email application, the electronic device can perform risk control statistics through the risk control data to obtain the risk control statistics results, and then construct a risk control feature library based on the risk control statistics results.

[0160] Steps S41-S45 are similar to steps S11-S15 mentioned above, so they will not be described in detail here.

[0161] In step S46 above, after obtaining the risk control data from the email application, the electronic device performs risk control statistics based on the obtained risk control data to obtain the risk control statistics results. For example, the electronic device can obtain the risk control data from the email application through steps S41-S45, and then perform risk control statistics based on the obtained risk control data. See below for details. Figure 5 The description in the text; for example, electronic devices can also obtain risk control data from email applications in steps S31-S35, and then perform risk control statistics based on the obtained risk control data, as detailed below. Figure 7 The description in the text.

[0162] For example, the obtained risk control data includes the client address, account identifier, and response status code. The specific process of obtaining risk control statistics results based on the risk control data is as follows:

[0163] Risk control statistics can be obtained by performing risk control analysis on client addresses, account identifiers, and response status codes in the risk control data. These statistics include the probability of login failure from the same client address and the probability of the same client address logging in with a random account identifier.

[0164] In step S47 above, the electronic device can construct a risk control feature database based on the risk control statistics results. For example, when the risk control statistics result indicates that the probability of login failure for the same client address is greater than a preset threshold, the client address can be added to the blacklist of the risk control feature database.

[0165] In some embodiments, risk control strategies can be determined based on features in a risk control statistics database, and risk control can be performed according to these strategies. See below for details. Figures 5-7 The description in the text.

[0166] See Figure 5 , Figure 5 This is a first schematic diagram of the risk control statistics system provided in an embodiment of this application. For example... Figure 5 As shown, Figure 5 The content to the left of the dashed line 51 can be considered as the risk control data collection process. Figure 5 The content to the right of the dashed line 51 can be considered as the email risk control process.

[0167] First to Figure 5The risk control data collection process shown is explained below. Specifically, "client" refers to the client of the email application, and "haproxy" refers to the proxy server used by the email application. The link used by the email application is determined through route resolution. For the case where the link used by the email application is EWS, it is generally Outlook communication / Apple MAC native Mail. For the case where the link used by the email application is autodiscover, it is generally triggered by loading a configuration file in Outlook. The electronic device uses a Lua hijacking script to hijack the haproxy logs to obtain the client address (i.e., IP), account identifier (i.e., USERNAME), transmission channel identifier (i.e., MAIL_CHANNEL), and request identifier (i.e., REQUESTID). See step S11 above for details. The aforementioned client address, account identifier, and transmission channel identifier correspond to the first risk control data mentioned above.

[0168] After the LUA hijacking script collects the IP address, USERNAME, MAIL_CHANNEL, and REQUESTID, it divides the collected data into two paths: one for data reading and the other for data merging. Data reading includes the IP address, USERNAME, and MAIL_CHANNEL; data merging includes the IP address, USERNAME, MAIL_CHANNEL, and REQUESTID. During the data collection process using the LUA hijacking script, the electronic device also collects HAProxy logs to obtain the request identifier (REQUESTID), user agent information (UA), and response status code (RES_CODE), as described in steps S12-S14 above. The user agent information and response status code correspond to the second and third risk control data mentioned above. The electronic device then adds the collected REQUESTID, UA, and RES_CODE to the data merging queue. Data with the same REQUESTID in the data merging queue are then merged to obtain the EWS mailbox request log, which is the risk control data merged in step S15 above. During the data merging process, the queue consisting of IP, USERNAME, MAIL_CHANNEL, and REQUESTID collected based on the LUA hijacking script can be called the LUA log queue; the queue consisting of REQUESTID, UA, and RES_CODE collected directly from the haproxy logs can be called the haproxy log queue.

[0169] Again Figure 5The risk control process for the email service shown is explained below. The process is as follows: In response to a login request for the email application, the client address is obtained. A risk control request carrying the client address is then initiated. Next, the risk control feature database is queried based on the client address to obtain the corresponding risk control features. These features are then returned to the risk control request. Based on the risk control features obtained from the request and the IP address, USERNAME, and MAIL_CHANNEL of the current email login request collected by the Lua hijacking script, the risk control level (i.e., the client's risk control level) is determined. Finally, based on this risk control level, the risk control request determines and executes the risk control strategy. The risk control feature database is built or updated based on risk control statistics, which are based on EWS email request logs. For details, please refer to the above. Figure 4 The description in the text.

[0170] for Figure 5 The risk control system shown in the diagram operates asynchronously with risk control data acquisition and email risk control. That is, once an electronic device detects an email login request, it will perform email risk control and acquire risk control data. However, the essential purpose of the acquired risk control data is only to perform risk control feature statistics in order to build or update the risk control feature library based on the risk control statistics, and then perform risk control statistics based on the risk control feature library. The risk control data for the current email login request may not necessarily participate in the risk control of the current login request. The data that participates in the risk control of the current login request is the IP, USERNAME, and MAIL_CHANNEL obtained by the LUA hijacking script.

[0171] See Figure 6 , Figure 6 This is a second schematic diagram of the risk control statistics system provided in the embodiments of this application; Figure 6 As shown, Figure 6 The content to the left of the dashed line 61 can be considered as the risk control data collection process. Figure 6 The content to the right of the dashed line 61 can be regarded as the email risk control process, i.e., the risk control system.

[0172] First to Figure 6 The risk control data collection process shown is explained below. Specifically, "client" refers to the client of the email application, and "haproxy" refers to the proxy server used by the email application. For cases where the email application uses ActiveSync, OWA, or OA, the electronic device uses a LUA hijacking script to hijack the haproxy logs and obtain the client address (IP), account identifier (USERNAME), transmission channel identifier (MAIL_CHANNEL), user password (PWD), login status code (LOGIN_STATUS), and device fingerprint (DFP). See the above for details. Figure 3 The description in the text is as follows. The client address, account identifier, and transmission channel identifier correspond to the fifth risk control data, while the user password, login status code, and device fingerprint correspond to encrypted risk control data. After collecting the IP address, USERNAME, MAIL_CHANNEL, REQUESTID, PWD, LOGIN_STATUS, and DFP, the LUA hijacking script transmits the collected data to the risk control request via the risk control level acquisition path. The risk control request then generates an email risk control request log based on this data, as described above. Figure 3 The risk control data obtained from it.

[0173] Again Figure 6 The email risk control process illustrated below is as follows: In response to a login request for the email application, the client address is obtained. A risk control request carrying the client address is then initiated. Next, the risk control feature database is queried based on the client address to obtain the corresponding risk control features. These features are then returned to the risk control request. Based on the risk control features obtained from the request and the IP, USERNAME, MAIL_CHANNEL, REQUESTID, PWD, LOGIN_STATUS, and DFP of the current email login request collected by the Lua hijacking script, the risk control level—that is, the client's risk control level—is determined. Finally, based on this risk control level, the risk control request determines and executes the risk control strategy. The risk control feature database is built or updated based on risk control statistics, which are based on email risk control request logs. For details, please refer to the above. Figure 4 The description in the text.

[0174] Figure 6 In the example shown, risk control data acquisition and email risk control are also performed asynchronously. That is, once the electronic device detects an email login request, it will perform email risk control and acquire risk control data. However, the essential purpose of the acquired risk control data is only to perform risk control feature statistics in order to build or update the risk control feature library based on the risk control statistics, and then perform risk control statistics based on the risk control feature library. The risk control data for the current email login request may not necessarily participate in this email risk control. The data that participates in this email risk control is the IP, USERNAME, MAIL_CHANNEL, REQUESTID, PWD, LOGIN STATUS, and DFP obtained by the LUA hijacking script.

[0175] See Figure 7 , Figure 7 This is a third schematic diagram of the risk control statistics system provided in the embodiments of this application. Figure 7 visible, Figure 7 The content can be divided into two parts: the part to the left of the dotted line and the part to the right of the dotted line. Specifically, it can be divided into two parts: the part to the left of the dotted line and the part to the right of the dotted line. Figure 7 The content to the left of the dashed line 71 is the left half, and the content to the right of the dashed line 71 is the right half. The upper part of the left half is... Figure 6 The example shown is the same; please refer to [link / reference]. Figure 6 The description in the text; the lower part of the left half and Figure 5 The example shown is the same; please refer to [link / reference]. Figure 5 The description in [the document / article]. Based on [the description / article]. Figure 7 The framework shown can enrich the features in the risk control feature library, that is, based on Figure 7 The framework shown indicates that the risk control characteristics of any link will be reflected in the risk control characteristic database. Specifically, if only deployment is used... Figure 5 The framework shown will only reflect risk control features in the risk control feature library when the email application uses EWS or autodiscover. If only one deployment is made... Figure 6 The framework shown indicates that the risk control feature library will only reflect the risk control features when the email application uses ActiveSync, OWA, and OA (Office Automation) links, and only... Figure 7 The framework shown has a risk control feature library that can reflect the risk control features when the email application uses EWS or autodiscover, as well as the risk control features when the email application uses Activesync, OWA, and OA.

[0176] In some embodiments, it can be understood that, due to Figure 5 The risk control data required in the example shown is not limited by encryption technology and can be obtained regardless of the link used by the email application. Therefore, it can be... Figure 5 The risk control statistics system shown can be applied to any email system for email risk control.

[0177] In some embodiments, taking EWS or autodiscover as an example where the cost of obtaining the login status code and device fingerprint exceeds a preset threshold, it is also possible to only use... Figure 5 The risk control system shown is applied to email systems using EWS or autodiscover as the communication link. Figure 6 The risk control system shown is applied to email systems that do not use EWS and are not autodiscover.

[0178] In other embodiments, taking EWS or autodiscover as an example, the link where the cost of obtaining the login status code and device fingerprint exceeds a preset threshold. This is understandable. Figure 7 The risk control system shown includes two scenarios: the link is EWS or autodiscover, and the link is neither EWS nor autodiscover. Therefore, it can also be considered... Figure 7The risk control and statistics system shown can be applied to any email system for email risk control. It only requires pre-determining whether the link used by the email application is EWS or autodiscover. See the above for details. Figure 2 The description in the text.

[0179] The risk control data acquisition method described in any of the embodiments of this application can be further optimized by using the real-time queue collision merging method, that is, by Figure 7 For example, it can also be optimized. Figure 7 The collision merging method between the LUA log queue and the HAProxy log queue can be adjusted in terms of collision window and log link latency calibration to improve the success rate and real-time performance of queue merging, thereby further supporting the rapid response of email risk control.

[0180] Corresponding to the above-described risk control data acquisition method, this application also provides a risk control data acquisition device, such as... Figure 8 As shown, the device includes:

[0181] The first acquisition module 81 is used to respond to a login request for an email application, acquire the request identifier of the login request as a target request identifier, and acquire the first risk control data corresponding to the login request, wherein the first risk control data is unencrypted risk control data.

[0182] The second acquisition module 82 is used to collect logs from the proxy server used by the email application, obtain the request identifier and the second risk control data recorded in the logs, and obtain a first correspondence relationship; the second risk control data is: unencrypted risk control data with the same function as encrypted risk control data; the first correspondence relationship is: the correspondence between the recorded request identifier and the second risk control data;

[0183] The first determining module 83 is used to determine, based on the first correspondence, third risk control data that matches the target request identifier from the second risk control data;

[0184] The second determining module 84 is used to determine encrypted risk control data based on the third risk control data;

[0185] The merging module 85 is used to merge the first risk control data and the encrypted risk control data to obtain the risk control data of the email application.

[0186] The technical solution provided in this application embodiment, in response to a login request for an email application, obtains the request identifier of the login request as the target request identifier, and obtains the first risk control data corresponding to the login request, wherein the first risk control data is unencrypted risk control data; collects logs from the proxy server used by the email application, obtains the request identifier and the second risk control data recorded in the logs, and obtains a first correspondence relationship; the second risk control data is: unencrypted risk control data with the same function as encrypted risk control data; the first correspondence relationship is: the correspondence between the recorded request identifier and the second risk control data; based on the first correspondence relationship, determines the third risk control data matching the target request identifier from the second risk control data; determines encrypted risk control data based on the third risk control data; and merges the first risk control data and the encrypted risk control data to obtain the risk control data of the email application.

[0187] Understandably, the first and second risk control data obtained above are unencrypted risk control data and are not limited by encryption technology. Furthermore, encrypted risk control data in related technologies has the same function as the second risk control data. Therefore, in this embodiment, third risk control data matching the target request identifier is determined from the second risk control data, and this third risk control data is used to replace the encrypted risk control data. Based on this, the encrypted risk control data determined from the third risk control data and the first risk control data are merged to obtain the risk control data for the email application. Therefore, by applying the risk control data acquisition method provided in this embodiment, and by using unencrypted risk control data with the same function as the encrypted risk control data to replace the encrypted risk control data, risk control data can be obtained without encryption technology.

[0188] In some embodiments, the second determining module 84,

[0189] Specifically, it is used to map the third risk control data into encrypted risk control data according to a preset mapping relationship.

[0190] In some embodiments, the second determining module 84,

[0191] The third risk control data is used as encrypted risk control data.

[0192] In some embodiments, the first acquisition module 81 includes:

[0193] The submodule is used to collect logs from the proxy server used by the email application using a hijacking script, obtain the request identifier and fourth risk control data recorded in the logs, and obtain a second correspondence relationship, which is the correspondence relationship between the recorded request identifier and the fourth risk control data.

[0194] The determination submodule is used to determine, based on the second correspondence, the first risk control data that matches the target request identifier from the fourth risk control data.

[0195] In some embodiments, the apparatus further includes:

[0196] The third acquisition module is used to acquire the link protocol used by the email application;

[0197] The first acquisition module 81 includes:

[0198] The first acquisition submodule is used to acquire the request identifier of the login request as the target request identifier and acquire the first risk control data corresponding to the login request if the cost of acquiring encrypted risk control data based on the link protocol used by the email application is greater than a preset threshold; wherein, the cost of acquiring encrypted risk control data represents: the difficulty of acquiring encrypted risk control data, or the time required to acquire encrypted risk control data;

[0199] The second acquisition submodule is used to collect the logs of the proxy server used by the email application using a hijacking script if the cost of acquiring encrypted risk control data based on the link protocol used by the email application is not greater than a preset threshold, thereby obtaining the fifth risk control data and encrypted risk control data recorded in the logs, and obtaining a third correspondence relationship, wherein the third correspondence relationship is: the correspondence relationship between the recorded fifth risk control data and the encrypted risk control data.

[0200] The merging submodule is used to merge the fifth risk control data and encrypted risk control data that have a corresponding relationship according to the third correspondence relationship, so as to obtain the risk control data of the email application.

[0201] In some embodiments, the apparatus further includes:

[0202] The statistics module is used to perform risk control statistics based on the risk control data of the email application after merging the first risk control data and the encrypted risk control data to obtain the risk control data of the email application, and to obtain the risk control statistics results.

[0203] The module is used to construct a risk control feature library based on the risk control statistics results.

[0204] This application also provides an electronic device, such as... Figure 9 As shown, it includes a processor 91, a communication interface 92, a memory 93, and a communication bus 94. The processor 91, the communication interface 92, and the memory 93 communicate with each other through the communication bus 94.

[0205] Memory 93 is used to store computer programs;

[0206] When the processor 91 executes the program stored in the memory 93, it implements any of the above-described risk control data acquisition methods or risk control feature library construction methods.

[0207] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0208] The communication interface is used for communication between the aforementioned terminal and other devices.

[0209] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0210] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0211] In another embodiment provided in this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, it implements the risk control data acquisition method described in any of the above embodiments.

[0212] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the risk control data acquisition methods described in the above embodiments.

[0213] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0214] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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 limitations, 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.

[0215] The various embodiments in this specification are described in a related 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, electronic devices, storage media, and computer program products 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.

[0216] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method for acquiring risk control data, characterized in that, The method includes: In response to a login request for an email application, the request identifier of the login request is obtained as the target request identifier, and the first risk control data corresponding to the login request is obtained, wherein the first risk control data is unencrypted risk control data; Logs from the proxy server used by the email application are collected to obtain the request identifier and second risk control data recorded in the logs, and a first correspondence is obtained; the second risk control data is: unencrypted risk control data with the same function as encrypted risk control data; the first correspondence is: the correspondence between the recorded request identifier and the second risk control data; Based on the first correspondence, determine the third risk control data that matches the target request identifier from the second risk control data; The encrypted risk control data is determined based on the third risk control data; The first risk control data and the encrypted risk control data are combined to obtain the risk control data of the email application.

2. The method according to claim 1, characterized in that, The step of determining encrypted risk control data based on the third risk control data includes: According to the preset mapping relationship, the third risk control data is mapped to encrypted risk control data.

3. The method according to claim 1, characterized in that, The step of determining encrypted risk control data based on the third risk control data includes: The third risk control data is used as encrypted risk control data.

4. The method according to any one of claims 1-3, characterized in that, The step of obtaining the account identifier of the account requested to log in by the login request, and obtaining the first risk control data corresponding to the login request, includes: The hijacking script collects the logs of the proxy server used by the email application, obtains the request identifier and the fourth risk control data recorded in the logs, and obtains the second correspondence relationship, which is: the correspondence relationship between the recorded request identifier and the fourth risk control data. Based on the second correspondence, the first risk control data that matches the target request identifier is determined from the fourth risk control data.

5. The method according to any one of claims 1-3, characterized in that, The method further includes: Obtain the link protocol used by the email application; The step of obtaining the request identifier of the login request as the target request identifier and obtaining the first risk control data corresponding to the login request includes: If the cost of obtaining encrypted risk control data based on the link protocol used by the email application is greater than a preset threshold, then the request identifier of the login request is obtained as the target request identifier, and the first risk control data corresponding to the login request is obtained; wherein, the cost of obtaining encrypted risk control data represents: the difficulty of obtaining encrypted risk control data, or the time required to obtain encrypted risk control data; If the cost of obtaining encrypted risk control data based on the link protocol used by the email application is not greater than a preset threshold, then a hijacking script is used to collect the logs of the proxy server used by the email application, and the fifth risk control data and encrypted risk control data recorded in the logs are obtained, as well as the third correspondence relationship is obtained. The third correspondence relationship is: the correspondence relationship between the recorded fifth risk control data and the encrypted risk control data. Based on the third correspondence, the fifth risk control data and the encrypted risk control data that have a corresponding relationship are merged to obtain the risk control data of the email application.

6. The method according to any one of claims 1-3, characterized in that, After merging the first risk control data and the encrypted risk control data to obtain the risk control data of the email application, the method further includes: Risk control statistics are performed based on the risk control data of the email application to obtain risk control statistics results; A risk control feature library is constructed based on the aforementioned risk control statistics.

7. A risk control data acquisition device, characterized in that, The device includes: The first acquisition module is used to respond to a login request for an email application, acquire the request identifier of the login request as a target request identifier, and acquire the first risk control data corresponding to the login request, wherein the first risk control data is unencrypted risk control data. The second acquisition module is used to collect logs from the proxy server used by the email application, obtain the request identifier and the second risk control data recorded in the logs, and obtain a first correspondence relationship; the second risk control data is: unencrypted risk control data with the same function as encrypted risk control data; the first correspondence relationship is: the correspondence between the recorded request identifier and the second risk control data; The first determining module is used to determine, based on the first correspondence, third risk control data that matches the target request identifier from the second risk control data; The second determining module is used to determine encrypted risk control data based on the third risk control data; The merging module is used to merge the first risk control data and the encrypted risk control data to obtain the risk control data of the email application.

8. The apparatus according to claim 7, characterized in that, The second determining module, Specifically, it is used to map the third risk control data into encrypted risk control data according to a preset mapping relationship.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-6.

Images