Service interface risk control method, device and storage medium

Abstract

The present invention relates to a risk control method, device and storage medium for a service interface, the method comprising: receiving a ticket acquisition request sent by a user end, the ticket acquisition request carrying a device identifier of the user end; in response to the ticket acquisition request, encrypting the device identifier to obtain a device identifier encryption symbol; adding the device identifier and the device identifier encryption symbol to a target ticket and feeding the target ticket back to the user end, the target ticket including a key algorithm pairing mark; receiving a data request encrypted by a target key determined by the user end based on the key algorithm pairing mark; performing risk verification on the data request, and performing risk control on the data request based on the risk verification result. By improving resistance to malicious access through dynamic key signature protection, and by adopting a multi-level honeypot diversion strategy and a strength confrontation strategy to cover the honeypot, the confrontation pressure from malicious access can be reduced and data security can be enhanced.

Description

Technical Field

[0001] The present invention relates to the field of communication security technology, and in particular to a risk control method, device and storage medium for a service interface. Background Art

[0002] At present, for front-end activity pages such as attracting new customers, receiving coupons or grabbing red envelopes, most interfaces do not have strict policy restrictions on the source of requests. Malicious access or attacks can bypass the restrictions by tampering with messages, etc., resulting in malicious access or attacks being able to use fixed interface links to promote profits.

[0003] The conventional data protection method is to design a reversible encryption function to encrypt the data. The encrypted data submitted by the browser to the server is decrypted to obtain the original data. The encryption function of this method is fixed in the browser and can be easily extracted by tools. Simple encryption is difficult to protect data security. Therefore, how to enhance data security protection capabilities, resist malicious access or attacks on batch access to sensitive interfaces, and continuously raise the threshold for malicious access attacks has become an urgent problem to be solved. Summary of the invention

[0004] The present invention intends to provide a risk control method, device and storage medium for a service interface to solve the deficiencies in the prior art. The technical problem to be solved by the present invention is achieved through the following technical solutions.

[0005] In a first aspect, an embodiment of the present invention provides a risk control method for a service interface, which is applied to a server, and includes:

[0006] Receiving a ticket acquisition request sent by a user terminal, wherein the ticket acquisition request carries a device identifier of the user terminal;

[0007] In response to the ticket acquisition request, encrypting the device identifier to obtain a device identifier encryption symbol;

[0008] Adding the device identifier and the device identifier encryption symbol to a target ticket and feeding the target ticket back to the user end, wherein the target ticket includes a key algorithm pairing mark;

[0009] Receiving a data request from a user end to be encrypted with a target key determined based on the key algorithm pairing tag;

[0010] A risk check is performed on the data request, and risk control of the data request is performed based on the risk check result.

[0011] In a possible implementation, the method further includes:

[0012] The data request carries a target ticket;

[0013] Performing a cyclic redundancy check on the target bill to verify the integrity of the target bill;

[0014] After the target ticket integrity check passes, verify the ticket validity based on the timestamp in the target ticket, and verify whether the device sending the data request is consistent with the device sending the ticket acquisition request based on the device identifier and device identifier encryption symbol in the target ticket;

[0015] After the ticket validity and device consistency checks are passed, the data request is received.

[0016] In a possible implementation, the method further includes:

[0017] The data request also carries a dynamic signature, which is a dynamic signature performed by the user end on the service interface based on the target key;

[0018] Parsing the dynamic signature to obtain a key generation algorithm corresponding to a target key used by the user end;

[0019] Encrypting the target ticket and the dynamic signature based on the key generation algorithm to generate a first key;

[0020] Decrypting and signing the data request based on the first key;

[0021] Based on the verification result, a risk tag parameter is added to the data request to mark whether the request is legal.

[0022] In a possible implementation, the method further includes:

[0023] Based on the bill type in the target bill, performing risk verification on the data request;

[0024] If the ticket type is marked as a disaster recovery type, a preset disaster recovery key algorithm mark is added to the ticket written into the cookies file and the ticket is fed back to the user end, so that the user end sends a data request based on the ticket;

[0025] If the bill type is marked as a normal business issuance type, the target data to be issued will be encrypted.

[0026] In a possible implementation, the method further includes:

[0027] The data request is risk-controlled based on the frequency of data requests sent by the same user terminal, the gateway interface traffic, or a preset risk identification model.

[0028] In a second aspect, an embodiment of the present invention provides a risk control method for a service interface, which is applied to a user end and includes:

[0029] Send a ticket acquisition request to the server;

[0030] Receive a target ticket fed back by the server, wherein the target ticket includes a key algorithm pairing tag;

[0031] Acquire a target key algorithm based on the key algorithm pairing tag, and encrypt the data request based on the target key algorithm;

[0032] The encrypted data request is sent to the server.

[0033] In a possible implementation, the method further includes:

[0034] Acquire a target key algorithm from a key algorithm service end based on the key algorithm pairing tag;

[0035] Generate a target key based on the target key algorithm, and dynamically sign the service interface based on the target key;

[0036] The data request is encrypted based on the target key, and the data request and the dynamic signature are sent to the server, so that the server performs risk verification on the data request based on the dynamic signature.

[0037] In a third aspect, an embodiment of the present invention provides a risk control device for a service interface, including:

[0038] A receiving module, configured to receive a ticket acquisition request sent by a user terminal, wherein the ticket acquisition request carries a device identifier of the user terminal;

[0039] An encryption module, configured to encrypt the device identifier in response to the ticket acquisition request to obtain a device identifier encryption symbol;

[0040] A feedback module, used for adding the device identifier and the device identifier encryption symbol to a target ticket and feeding back the target ticket to the user end, wherein the target ticket includes a key algorithm pairing mark;

[0041] The receiving module is further used to receive a data request from the user end to be encrypted using a target key determined based on the key algorithm pairing mark;

[0042] The control module is used to perform risk verification on the data request and perform risk control on the data request based on the risk verification result.

[0043] In a fourth aspect, an embodiment of the present invention provides a risk control device for a service interface, including:

[0044] The sending module is used to send a ticket acquisition request to the server;

[0045] A receiving module, configured to receive a target ticket fed back by the server, wherein the target ticket includes a key algorithm pairing tag;

[0046] An encryption module, used to obtain a target key algorithm based on the key algorithm pairing tag, and encrypt the data request based on the target key algorithm;

[0047] The sending module is also used to send the encrypted data request to the server.

[0048] In a fifth aspect, an embodiment of the present invention provides an electronic device, comprising: a processor and a memory, wherein the processor is used to execute a resource recommendation program stored in the memory to implement the risk control method of the service interface described in the first and second aspects above.

[0049] In a sixth aspect, an embodiment of the present invention provides a storage medium, comprising: the storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the risk control method of the service interface described in the first and second aspects above.

[0050] The embodiments of the present invention include the following advantages:

[0051] The risk control scheme of the service interface provided by the embodiment of the present invention receives a ticket acquisition request sent by a user end, wherein the ticket acquisition request carries the device identifier of the user end; in response to the ticket acquisition request, the device identifier is encrypted to obtain a device identifier encryption symbol; the device identifier and the device identifier encryption symbol are added to the target ticket and the target ticket is fed back to the user end, wherein the target ticket includes a key algorithm pairing mark; a data request encrypted by the target key determined by the user end based on the key algorithm pairing mark is received; a risk check is performed on the data request, and risk control of the data request is performed based on the risk check result. Compared with the conventional data protection method, the encryption function is fixed in the browser, which is easy to be extracted by tools and is difficult to protect data security. According to this scheme, the resistance to malicious access is improved through dynamic key signature protection, and the multi-level honeypot diversion strategy is adopted to protect the honeypot with a strong confrontation strategy, which can reduce the confrontation pressure from malicious access and enhance data security. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 It is a flow chart of a risk control method of a service interface of the present invention;

[0053] Figure 2 It is a flow chart of another risk control method of a service interface of the present invention;

[0054] Figure 3 This is a schematic diagram of the overall implementation process of dynamic protection of an API interface of the present invention;

[0055] Figure 4 It is a schematic diagram of a bill of exchange of the present invention;

[0056] Figure 5 It is a schematic diagram of a flow chart of a key generation algorithm of the present invention;

[0057] Figure 6 It is a schematic diagram of a multi-level intelligent current limiting based on a risk control scenario of the present invention;

[0058] Figure 7 It is a flow chart of another risk control method of a service interface of the present invention;

[0059] Figure 8 It is a structural schematic diagram of a risk control device for a service interface of the present invention;

[0060] Fig. 9 is a schematic structural diagram of another risk control device for a service interface of the present invention;

[0061] Fig.10 It is a structural schematic diagram of an electronic device of the present invention. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0063] To facilitate understanding of the embodiments of the present invention, specific embodiments will be further explained below in conjunction with the accompanying drawings. The embodiments do not constitute a limitation on the embodiments of the present invention.

[0064] Figure 1 is a flow chart of a risk control method for a service interface of the present invention, such as Figure 1 As shown, specifically including:

[0065] S11. Receive a ticket acquisition request sent by the user.

[0066] The user end (such as the Web end, mini program, APP, etc.) sends a ticket acquisition request to the service gateway to obtain a ticket. The ticket is used to generate a dynamic key and gateway identity verification. The ticket acquisition request carries the user's device identifier.

[0067] like Figure 4 As shown, the content of the bill is defined to include: protocol header, version number, platform, integrity check, bill type tag, disaster recovery algorithm tag, timestamp, key algorithm pairing tag, device unique identification string and device identifier encryption string.

[0068] S12. In response to the ticket acquisition request, encrypt the device identifier to obtain a device identifier encryption symbol.

[0069] S13: Add the device identifier and the device identifier encryption symbol to the target ticket and feed the target ticket back to the user terminal.

[0070] After the user sends a ticket acquisition request to the service gateway, it uploads the device's unique identification string. The service gateway encrypts the device's unique identification string to obtain the device identification encryptor, adds the device identifier and device identification encryptor to the target ticket, and returns the key generation algorithm and target ticket (token) to the user. The target ticket also includes the key algorithm pairing mark.

[0071] S14: Receive a data request from the user end to encrypt a target key determined based on the key algorithm pairing tag.

[0072] The user side encrypts and stores the token and key generation algorithm separately, and the service gateway synchronizes the key generation algorithm to the server side.

[0073] The user end uses the key generation algorithm and token sent by the service gateway to dynamically generate a key, such as T_a_u(t)=key(token,fp,timestamp).

[0074] Furthermore, the key generated above is used to sign and encrypt the interface data request parameters to generate a dynamic signature sign(key,fp,appid).

[0075] S15. Perform risk verification on the data request, and perform risk control on the data request based on the risk verification result.

[0076] When making an interface request, the user uploads the dynamic key elements (token, timestamp, fp, appid) and the dynamic signature sign to the server.

[0077] The server-side risk verification includes:

[0078] Parse and verify the token: determine whether the current requesting user is consistent and whether the token is expired.

[0079] Parse algorithm identifier: Get the key generation algorithm used by the user end, and use the dynamic key element in the data request parameter to generate the key.

[0080] Decryption and signature verification: Use the generated key to decrypt and verify the signature of each parameter.

[0081] Add risk tag: Add risk tag parameters to the request based on the verification results to mark whether the request is legal.

[0082] Asynchronous synchronization to risk control: The verification results are asynchronously synchronized to the risk control system, and risk control then handles the downstream business.

[0083] Issue risk labels: Issue risk label parameters to the business side.

[0084] Business processing: The business side processes according to the risk tag parameters.

[0085] The risk control method of the service interface provided by the embodiment of the present invention receives a ticket acquisition request sent by a user end, wherein the ticket acquisition request carries the device identifier of the user end; in response to the ticket acquisition request, the device identifier is encrypted to obtain a device identifier encryption symbol; the device identifier and the device identifier encryption symbol are added to the target ticket and the target ticket is fed back to the user end, wherein the target ticket includes a key algorithm pairing mark; a data request encrypted by the target key determined by the user end based on the key algorithm pairing mark is received; the data request is risk-checked, and the data request risk control is performed based on the risk check result. Compared with the conventional data protection method, the encryption function is fixed in the browser, which is easy to be extracted by tools and is difficult to protect data security. According to this method, the resistance to malicious access is improved through dynamic key signature protection, and the multi-level honeypot diversion strategy is adopted to protect the honeypot with a strong confrontation strategy, which can reduce the confrontation pressure from malicious access and enhance data security.

[0086] Figure 2 is a flow chart of another risk control method of a service interface of the present invention, such as Figure 2 As shown, specifically including:

[0087] S21. Perform a cyclic redundancy check on the target bill to verify the integrity of the target bill.

[0088] In the embodiment of the present invention, combined with Figure 3 The API interface dynamic protection overall implementation process diagram shown is explained in detail.

[0089] First, the user end (such as the Web end, mini program, APP, etc.) sends a ticket acquisition request to the service gateway to obtain a ticket (process 1.1-1.3). The ticket is used to generate a dynamic key and gateway identity verification. The ticket acquisition request carries the user's device identifier.

[0090] like Figure 4 As shown, the bill content definition includes:

[0091] Protocol header: uniquely identifies the protocol type.

[0092] Version number: current protocol version, adapted for subsequent protocol upgrades.

[0093] Platform: Distinguish the platform where the request comes from (such as the Web, mini program, APP, in-site H5, etc.).

[0094] Integrity check: Use cyclic redundancy check (CRC) to check the integrity of the entire string to prevent the bill from being tampered with.

[0095] Ticket type mark: distinguish between disaster preparedness type and normal business issuance type.

[0096] Disaster preparedness algorithm tag: If the ticket type is disaster preparedness, the configuration content is an algorithm expression, such as x+y+z, where x / y / z represent different key algorithms. Three or more key algorithms are built-in locally, such as: 1, MD5 / 2, SHA-256 / 3, HMACSHA256. Operators indicate the use of multiple local key algorithms in combination, and support three or more operators, such as key algorithm nested operation 'x'= key_3(key_2(key_1())), key algorithm splicing operation 'y'= key_1()+key_2()+key3(), key algorithm XOR operation 'z'= toInt(key_1())^toInt(key_2())^toInt(key_3()).

[0097] Timestamp: used to verify the validity of the ticket.

[0098] Key algorithm pairing tag: identifies the key algorithm sent by the server. The ticket and key algorithm are sent in pairs.

[0099] Device unique identification string: used to verify whether the device that pulls the key algorithm is consistent with the device that initiates the service request.

[0100] Device identifier encrypted string: Encrypt the device identifier for identity verification.

[0101] The client saves the obtained target ticket to the local cache for subsequent use.

[0102] Further, key algorithm acquisition and key dynamic generation (process 2.1-2.3):

[0103] After the user sends a ticket acquisition request to the service gateway, it uploads the device's unique identification string. The service gateway encrypts the device's unique identification string to obtain the device identification encryptor, adds the device identifier and device identification encryptor to the target ticket, and returns the key generation algorithm and target ticket (token) to the user. The target ticket also includes a key algorithm pairing mark. The user side encrypts and stores the token and the key generation algorithm separately, and the service gateway synchronizes the key generation algorithm to the server. Since each request corresponds to a different algorithm and expires, it increases the difficulty of malicious access and reverse cracking. The user side uses the key generation algorithm and token issued by the service gateway to dynamically generate a key, such as T_a_u(t)=key(token,fp,timestamp). Further (process 3-4), such as Figure 5 As shown, the interface data request parameters are signed and encrypted using the key generated above to generate a dynamic signature sign(key,fp,appid).

[0104] Furthermore, the server obtains a data request sent by the user, the data request carries a target ticket, and performs a cyclic redundancy check on the target ticket to verify the integrity of the target ticket.

[0105] Specifically, a check code F is obtained after calculating the original data D, and a new data T is obtained. The receiver can verify the data after receiving it.

[0106] Specifically, the cyclic redundancy check provides a pre-set (n-k+1)-bit integer P and requires the added (nk) bits F to satisfy: ,in .

[0107] Operation steps: Before communication, the sender and the receiver agree on a preset integer P. Before sending, the sender determines F that satisfies the calculation formula based on the data D, generates a check code T, which is the concatenation of the data bit D and the check bit F, and sends T. The receiver receives the check code T and performs the result = T mod P operation. If and only if result = 0, the receiver considers that there is no error.

[0108] S22. After the target ticket integrity check is passed, verify the validity of the ticket based on the timestamp in the target ticket, and verify whether the device sending the data request is consistent with the device sending the ticket acquisition request based on the device identifier and device identifier encryption symbol in the target ticket.

[0109] Local request and service verification (process 5.1-5.6): Determine whether the current ticket is expired based on the timestamp in the target ticket, and determine whether the current data requesting user is consistent with the ticket requesting user based on the device identifier and device identifier encryption code in the target ticket.

[0110] Optionally, the data request also carries a dynamic signature, which is a dynamic signature of the service interface made by the user end based on the target key. The dynamic signature is parsed to obtain the key generation algorithm corresponding to the target key used by the user end; the user end encrypts the target ticket and dynamic signature based on the key generation algorithm to generate the first key; the server end decrypts and verifies the signature of the data request based on the first key, and adds a risk tag parameter to the data request based on the verification result to mark whether the request is legal.

[0111] S23. After the ticket validity and device consistency verification are passed, receiving the data request.

[0112] S24: Based on the bill type in the target bill, perform risk verification on the data request.

[0113] If the ticket type is marked as a disaster recovery type, the preset disaster recovery key algorithm mark will be added to the ticket written to the cookies file and the ticket will be fed back to the user end so that the user end can send a data request based on the ticket; if the ticket type is marked as a normal business distribution type, the target data to be distributed will be encrypted.

[0114] Optionally, in some risk control scenarios, malicious access targets interfaces with weak protection capabilities and often uses machine modification tools to batch swipe for arbitrage. Therefore, for tool script batch access scenarios, it is more effective to combine multi-level intelligent diversion strategies to defend the interface. Therefore, the data request can also be risk controlled based on the frequency of data requests sent by the same user end, gateway interface traffic, or a preset risk identification model, such as Figure 6 shown.

[0115] Specifically, the multi-level intelligent flow limiting strategy based on risk control scenarios (Process 6): The multi-level intelligent strategy is an upgraded measure to protect against adversarial attacks over a longer period of time, and implements intelligent flow limiting through multi-level strategies such as scenarios, window frequency control, and anti-crawler.

[0116] 1. Scenario flow control: A single-machine computing mode is used to precisely prevent and control the problem of excessive traffic in a certain scenario. A centralized architecture mode is used to accurately match the business scenario based on the interface input parameters, and high-frequency requests are intercepted in real time based on the request frequency of the user's pin / ip / uuid.

[0117] 2. Window frequency control and flow limiting: It uses a single-machine computing mode to prevent excessive traffic on a certain interface at the gateway entrance and can limit the maximum number of requests per second.

[0118] 3. Risk model identification and interception: A centralized architecture model is used to accurately intercept illegal traffic through risk control model identification. It is mainly divided into the following models:

[0119] 3.1 Real-time frequency model

[0120] The access frequency of IP+UID is limited according to the sliding window current limiting algorithm. If the access volume reaches the threshold set in the window, the frequency of IP+UID is limited or human-computer interaction verification is enabled.

[0121] 3.2 Offline analysis model

[0122] Analyze the access behaviors within the same group of IP addresses in units of hours and IP segments. If the access behaviors are the same and the request parameters are similar, or the requests submitted by the same IP address are the same but the frequency is different from that of other IP addresses, select interception based on the source resolved from the IP address.

[0123] 3.3 Rule Engine Model

[0124] Find forged features for known or reverse malicious access software and identify and intercept them, including but not limited to forged UID, forged UA, forged EID, forged Ref, proxy IP pool, black software tool IP, etc.

[0125] The risk control method of the service interface provided by the embodiment of the present invention receives a ticket acquisition request sent by a user end, wherein the ticket acquisition request carries the device identifier of the user end; in response to the ticket acquisition request, the device identifier is encrypted to obtain a device identifier encryption code; the device identifier and the device identifier encryption code are added to the target ticket and the target ticket is fed back to the user end, wherein the target ticket includes a key algorithm pairing tag; a data request encrypted by the target key determined by the user end based on the key algorithm pairing tag is received; a risk check is performed on the data request, and risk control of the data request is performed based on the risk check result. This method improves resistance to malicious access through dynamic key signature protection, and adopts a strength confrontation strategy to protect the honeypot through a multi-level honeypot diversion strategy. Features include that the key is not pre-stored on the server end, is automatically updated, and storage management costs are reduced; the risk determination service is uniformly accessed by the gateway, and the business transformation cost is relatively low; the multi-level risk disposal is accurate and flexible, and the intensity of direct confrontation with malicious access is reduced. It can reduce external business risks such as malicious access automated crawler attacks, wool pulling, and sensitive information leakage. Achieve "risk traffic is protected before it reaches the business system" and "API interface compliance management". Enhance data security protection capabilities, fight against malicious batch access to sensitive interfaces, and continuously raise the threshold for malicious access attacks.

[0126] Figure 7It is a flow chart of another risk control method of a service interface of the present invention, such as Figure 7 As shown, specifically including:

[0127] S71. Send a ticket acquisition request to the server.

[0128] S72: Receive the target ticket fed back by the server.

[0129] The user sends a ticket acquisition request to the service gateway and uploads the device's unique identification string. The service gateway encrypts the device's unique identification string to obtain the device identification encryption code, adds the device identifier and the device identification encryption code to the target ticket, and returns the key generation algorithm and the target ticket (token) to the user. The target ticket includes the key algorithm pairing tag and the key algorithm pairing tag. The user encrypts and stores the token and the key generation algorithm separately, and the service gateway synchronizes the key generation algorithm to the server. Since each request corresponds to a different algorithm and expires, it increases the difficulty of malicious access cracking and reverse engineering.

[0130] S73. Obtain a target key algorithm based on the key algorithm pairing tag, and encrypt the data request based on the target key algorithm.

[0131] S74. Send the encrypted data request to the server.

[0132] Obtain the target key algorithm from the key algorithm server based on the key algorithm pairing tag; generate the target key based on the target key algorithm, and dynamically sign the service interface based on the target key; encrypt the data request based on the target key, and send the data request and the dynamic signature to the server, so that the server can perform risk verification on the data request based on the dynamic signature.

[0133] The risk control method for the service interface provided in the embodiment of the present invention is implemented by sending a ticket acquisition request to the server; receiving a target ticket fed back by the server, wherein the target ticket includes a key algorithm pairing tag; acquiring a target key algorithm based on the key algorithm pairing tag, and encrypting a data request based on the target key algorithm; and sending the encrypted data request to the server. Compared with the conventional data protection method, the encryption function is fixed in the browser and can be easily extracted by tools, making it difficult to protect data security. This method improves resistance to malicious access through dynamic key signature protection, and adopts a multi-level honeypot diversion strategy and a strong confrontation strategy to protect the honeypot, thereby reducing the confrontation pressure from malicious access and enhancing data security.

[0134] Figure 8 It is a structural schematic diagram of a risk control device for a service interface of the present invention, which specifically includes:

[0135] The receiving module 801 is used to receive a ticket acquisition request sent by a user terminal, wherein the ticket acquisition request carries a device identifier of the user terminal. For detailed description, please refer to the relevant description corresponding to the above method embodiment, which will not be repeated here.

[0136] The encryption module 802 is used to encrypt the device identifier in response to the ticket acquisition request to obtain a device identifier encryption code. For detailed description, please refer to the relevant description corresponding to the above method embodiment, which will not be repeated here.

[0137] Feedback module 803 is used to add the device identifier and the device identifier encryption code to the target ticket and feed the target ticket back to the user end, wherein the target ticket includes a key algorithm pairing mark. Detailed descriptions refer to the relevant descriptions corresponding to the above method embodiments, which will not be repeated here.

[0138] The receiving module 801 is further configured to receive a data request from the user end to be encrypted with a target key determined based on the key algorithm pairing tag. For detailed description, please refer to the relevant description corresponding to the above method embodiment, which will not be repeated here.

[0139] The control module 804 is used to perform risk verification on the data request and perform risk control on the data request based on the risk verification result. For detailed description, please refer to the relevant description corresponding to the above method embodiment, which will not be repeated here.

[0140] The risk control device of the service interface provided in this embodiment may be as follows Figure 8 The risk control device of the service interface shown in can be executed as follows Figure 1-2 All steps of the risk control method of the service interface in Figure 1-2 For details, please refer to the technical effects of the risk control method of the service interface shown in Figure 1-2 For the sake of brevity, the relevant description is not repeated here.

[0141] Fig. 9 It is a structural schematic diagram of another risk control device of a service interface of the present invention, which specifically includes:

[0142] The sending module 901 is used to send a ticket acquisition request to the server. For detailed description, please refer to the relevant description of the above method embodiment, which will not be repeated here.

[0143] The receiving module 902 is used to receive the target ticket fed back by the server, wherein the target ticket includes the key algorithm pairing tag. For detailed description, please refer to the relevant description corresponding to the above method embodiment, which will not be repeated here.

[0144] The encryption module 903 is used to obtain the target key algorithm based on the key algorithm pairing tag, and encrypt the data request based on the target key algorithm. For detailed description, please refer to the relevant description corresponding to the above method embodiment, which will not be repeated here.

[0145] The sending module 901 is also used to send the encrypted data request to the server. For detailed description, please refer to the relevant description of the above method embodiment, which will not be repeated here.

[0146] The risk control device of the service interface provided in this embodiment may be as follows Fig. 9 The risk control device of the service interface shown in can be executed as follows Figure 7 All steps of the risk control method of the service interface in Figure 7 For details, please refer to the technical effects of the risk control method of the service interface shown in Figure 7 For the sake of brevity, the relevant description is not repeated here.

[0147] Fig.10 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention, Fig.10 The electronic device 500 shown includes: at least one processor 501, a memory 502, at least one network interface 504 and other user interfaces 503. The various components in the electronic device 500 are coupled together via a bus system 505. It is understood that the bus system 505 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 505 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 505 is not shown in FIG. Fig.10 Various buses are labeled as bus system 505 .

[0148] The user interface 503 may include a display, a keyboard, or a pointing device (eg, a mouse, a trackball, a touch pad, or a touch screen).

[0149] It can be understood that the memory 502 in the embodiment of the present invention can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus random access memory (DRRAM). The memory 502 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0150] In some implementations, the memory 502 stores the following elements, executable units or data structures, or a subset thereof, or an extended set thereof: an operating system 5021 and an application program 5022 .

[0151] The operating system 5021 includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., which are used to implement various basic services and process hardware-based tasks. The application 5022 includes various application programs, such as a media player (Media Player), a browser (Browser), etc., which are used to implement various application services. The program for implementing the method of the embodiment of the present invention can be included in the application 5022.

[0152] In the embodiment of the present invention, by calling the program or instruction stored in the memory 502, specifically, the program or instruction stored in the application 5022, the processor 501 is used to execute the method steps provided by each method embodiment, for example, including:

[0153] Receive a ticket acquisition request sent by a user terminal, the ticket acquisition request carrying the device identifier of the user terminal; in response to the ticket acquisition request, encrypt the device identifier to obtain a device identifier encryption symbol; add the device identifier and the device identifier encryption symbol to a target ticket and feed the target ticket back to the user terminal, the target ticket including a key algorithm pairing mark; receive a data request encrypted by a target key determined by the user terminal based on the key algorithm pairing mark; perform risk verification on the data request, and perform risk control on the data request based on the risk verification result.

[0154] In one possible implementation, the data request carries a target ticket; a cyclic redundancy check is performed on the target ticket to verify the integrity of the target ticket; after the target ticket integrity check passes, the ticket validity is verified based on the timestamp in the target ticket, and based on the device identifier and device identifier encryption character in the target ticket, it is verified whether the device sending the data request is consistent with the device sending the ticket acquisition request; after the ticket validity and device consistency checks pass, the data request is received.

[0155] In one possible implementation, the data request also carries a dynamic signature, which is a dynamic signature of the service interface made by the user end based on the target key; the dynamic signature is parsed to obtain a key generation algorithm corresponding to the target key used by the user end; the target ticket and the dynamic signature are encrypted based on the key generation algorithm to generate a first key; the data request is decrypted and the signature is verified based on the first key; and a risk label parameter is added to the data request based on the verification result to mark whether the request is legal.

[0156] In one possible implementation, the data request is risk-checked based on the ticket type in the target ticket; if the ticket type is marked as a disaster recovery type, a preset disaster recovery key algorithm mark is added to the ticket written to the cookies file and the ticket is fed back to the user terminal, so that the user terminal sends a data request based on the ticket; if the ticket type is marked as a normal business delivery type, the target data to be delivered is encrypted.

[0157] In a possible implementation, risk control is performed on the data request based on the frequency of data requests sent by the same user terminal, gateway interface traffic, or a preset risk identification model.

[0158] Send a ticket acquisition request to the server; receive a target ticket fed back by the server, wherein the target ticket includes a key algorithm pairing tag; obtain a target key algorithm based on the key algorithm pairing tag, and encrypt a data request based on the target key algorithm; and send the encrypted data request to the server.

[0159] In one possible implementation, a target key algorithm is obtained from a key algorithm server based on the key algorithm pairing tag; a target key is generated based on the target key algorithm, and a service interface is dynamically signed based on the target key; the data request is encrypted based on the target key, and the data request and the dynamic signature are sent to the server, so that the server performs a risk check on the data request based on the dynamic signature.

[0160] The method disclosed in the above embodiment of the present invention can be applied to the processor 501, or implemented by the processor 501. The processor 501 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 501 or the instruction in the form of software. The above processor 501 can be a general processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a field programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present invention can be implemented or executed. The general processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiment of the present invention can be directly embodied as a hardware decoding processor to execute, or the hardware and software units in the decoding processor can be executed. The software unit can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 502, and the processor 501 reads the information in the memory 502 and completes the steps of the above method in combination with its hardware.

[0161] It is understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPDevice, DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in the present application, or a combination thereof.

[0162] For software implementation, the technology described herein can be implemented by a unit that performs the functions described herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0163] The electronic device provided in this embodiment may be Fig.10 The electronic device shown in FIG. 1 may perform the following steps: Figure 1-2 All steps of the risk control method of the service interface in 7 are implemented Figure 1-2 For details, please refer to Figure 1-2 The description related to 7 is omitted here for the sake of brevity.

[0164] The embodiment of the present invention further provides a storage medium (computer-readable storage medium). The storage medium here stores one or more programs. The storage medium may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a read-only memory, a flash memory, a hard disk or a solid-state drive; the memory may also include a combination of the above-mentioned types of memory.

[0165] When one or more programs in the storage medium can be executed by one or more processors, the risk control method of the service interface executed on the electronic device side can be implemented.

[0166] The processor is used to execute the risk control program of the service interface stored in the memory to implement the following steps of the risk control method of the service interface executed on the electronic device side:

[0167] Receive a ticket acquisition request sent by a user terminal, the ticket acquisition request carrying the device identifier of the user terminal; in response to the ticket acquisition request, encrypt the device identifier to obtain a device identifier encryption symbol; add the device identifier and the device identifier encryption symbol to a target ticket and feed the target ticket back to the user terminal, the target ticket including a key algorithm pairing mark; receive a data request encrypted by a target key determined by the user terminal based on the key algorithm pairing mark; perform risk verification on the data request, and perform risk control on the data request based on the risk verification result.

[0168] In one possible implementation, the data request carries a target ticket; a cyclic redundancy check is performed on the target ticket to verify the integrity of the target ticket; after the target ticket integrity check passes, the ticket validity is verified based on the timestamp in the target ticket, and based on the device identifier and device identifier encryption character in the target ticket, it is verified whether the device sending the data request is consistent with the device sending the ticket acquisition request; after the ticket validity and device consistency checks pass, the data request is received.

[0169] In one possible implementation, the data request also carries a dynamic signature, which is a dynamic signature of the service interface made by the user end based on the target key; the dynamic signature is parsed to obtain a key generation algorithm corresponding to the target key used by the user end; the target ticket and the dynamic signature are encrypted based on the key generation algorithm to generate a first key; the data request is decrypted and the signature is verified based on the first key; and a risk label parameter is added to the data request based on the verification result to mark whether the request is legal.

[0170] In one possible implementation, the data request is risk-checked based on the ticket type in the target ticket; if the ticket type is marked as a disaster recovery type, a preset disaster recovery key algorithm mark is added to the ticket written to the cookies file and the ticket is fed back to the user terminal, so that the user terminal sends a data request based on the ticket; if the ticket type is marked as a normal business delivery type, the target data to be delivered is encrypted.

[0171] In a possible implementation, risk control is performed on the data request based on the frequency of data requests sent by the same user terminal, gateway interface traffic, or a preset risk identification model.

[0172] Send a ticket acquisition request to the server; receive a target ticket fed back by the server, wherein the target ticket includes a key algorithm pairing tag; obtain a target key algorithm based on the key algorithm pairing tag, and encrypt a data request based on the target key algorithm; and send the encrypted data request to the server.

[0173] In one possible implementation, a target key algorithm is obtained from a key algorithm server based on the key algorithm pairing tag; a target key is generated based on the target key algorithm, and a service interface is dynamically signed based on the target key; the data request is encrypted based on the target key, and the data request and the dynamic signature are sent to the server, so that the server performs a risk check on the data request based on the dynamic signature.

[0174] The professionals should further realize that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to the function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0175] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0176] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A risk control method for a service interface, applied to a service end, characterized in that: include: Receiving a ticket acquisition request sent by a user terminal, wherein the ticket acquisition request carries a device identifier of the user terminal; In response to the ticket acquisition request, encrypting the device identifier to obtain a device identifier encryption symbol; Adding the device identifier and the device identifier encryption symbol to a target ticket and feeding the target ticket back to the user end, wherein the target ticket includes a key algorithm pairing mark; Receiving a data request from a user end to be encrypted with a target key determined based on the key algorithm pairing tag; Performing risk verification on the data request, and performing risk control on the data request based on the risk verification result; The receiving a data request from a user end to be encrypted with a target key determined by the key algorithm pairing mark includes: The data request carries a target ticket, and the data request also carries a dynamic signature, where the dynamic signature is a dynamic signature made by the user end on the service interface based on the target key; Performing a cyclic redundancy check on the target note to verify the integrity of the target note; After the integrity check of the target ticket passes, verify the validity of the ticket based on the timestamp in the target ticket, and verify whether the device sending the data request is consistent with the device sending the ticket acquisition request based on the device identifier and device identifier encryption symbol in the target ticket; After the ticket validity and device consistency checks are passed, receiving the data request; Parsing the dynamic signature to obtain a key generation algorithm corresponding to a target key used by the user end; Encrypting the target ticket and the dynamic signature based on the key generation algorithm to generate a first key; Decrypting and signing the data request based on the first key; Based on the verification result, a risk tag parameter is added to the data request to mark whether the request is legal; The performing risk verification on the data request and performing risk control on the data request based on the risk verification result includes: Based on the bill type in the target bill, performing risk verification on the data request; If the ticket type is marked as a disaster recovery type, a preset disaster recovery key algorithm mark is added to the ticket written into the cookies file and the ticket is fed back to the user end, so that the user end sends a data request based on the ticket; If the bill type is marked as a normal business issuance type, the target data to be issued is encrypted.

2. The method according to claim 1, characterized in that The method further comprises: The data request is risk-controlled based on the frequency of data requests sent by the same user terminal, the gateway interface traffic, or a preset risk identification model.

3. A risk control device for a service interface, characterized in that: The method for executing claim 1 comprises: A receiving module, configured to receive a ticket acquisition request sent by a user terminal, wherein the ticket acquisition request carries a device identifier of the user terminal; An encryption module, configured to encrypt the device identifier in response to the ticket acquisition request to obtain a device identifier encryption symbol; A feedback module, used for adding the device identifier and the device identifier encryption symbol to a target ticket and feeding back the target ticket to the user end, wherein the target ticket includes a key algorithm pairing mark; The receiving module is further used to receive a data request from the user end to be encrypted using a target key determined based on the key algorithm pairing mark; The control module is used to perform risk verification on the data request and perform risk control on the data request based on the risk verification result.

4. A storage medium, characterized in that: The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the risk control method of the service interface described in any one of claims 1 to 2.

Images