Interface request security verification method, device and system, and electronic equipment

Abstract

This application discloses a method, apparatus, system, and electronic device for security verification of interface requests, belonging to the field of network security technology. The method includes: obtaining a key pair including a first key and a second key from a preset key manager; generating a random factor and obtaining a timestamp in real time; performing sampling verification processing on the byte stream message body transmitted by the application programming interface (API) request based on the timestamp, the first key, and the random factor to obtain a checksum; and sending the API request to a preset server, wherein the API request carries the byte stream message body, checksum, second key, random factor, and timestamp, enabling the preset server to perform security verification on the API request. This method uses a fixed data sampling length when calculating the checksum, independent of the length of the byte stream message body, reducing time complexity and shortening the time consumption for interface request security verification while reducing resource consumption from risk identification.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to an interface request security verification method, an interface request security verification device, an interface request security verification system, an electronic device, and a computer-readable storage medium. Background Technology

[0002] In application architectures where clients request APIs (Application Programming Interfaces) from servers, the server manages API usage authorization to protect against malicious attacks and tampering. Existing technologies assign a key and secret pair to different clients. When a client requests an API, it uses the key, the byte stream message body of the API request, the request timestamp, and a random factor to calculate a signature value using a hash algorithm (such as sha256 or md5). This signature value, along with the key, random factor, and request timestamp, is then sent to the server. Upon receiving the request, the server uses the same algorithm as the client to calculate a signature value and performs security verification on the client's request based on both the received and calculated signature values.

[0003] However, existing security verification schemes for API access have at least the following drawbacks: when the byte stream message body of the API request is too large, the server takes a long time to perform signature verification and consumes a lot of computing resources. When encountering malicious traffic attacks, under dense and massive byte stream message attacks, it is easy to exhaust server resources.

[0004] It is evident that existing methods for verifying the security of interface requests still require improvement. Summary of the Invention

[0005] This application provides an interface request security verification method and apparatus, which helps to shorten the time consumption of interface request security verification and reduce the resource consumption caused by risk identification, and can quickly identify risky traffic.

[0006] In a first aspect, embodiments of this application provide an interface request security verification method, applied to a client, the method comprising:

[0007] A key pair is obtained from a preset key manager, the key pair including: a first key and a second key;

[0008] Generate random factors and obtain timestamps in real time;

[0009] Based on the timestamp, the first key, and the random factor, the byte stream message body transmitted by the application programming interface request is sampled and verified to obtain a checksum.

[0010] An application programming interface (API) request is sent to a preset server, wherein the API request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp, so that the preset server performs security verification on the API request.

[0011] Secondly, embodiments of this application provide an interface request security verification method, applied to a server, the method comprising:

[0012] In response to an application programming interface (API) request, the API request is parsed to obtain the byte stream message body of the API request sent by the client, the first checksum, the second key, the random factor, and the timestamp;

[0013] Obtain the first key paired with the second key from the preset key manager;

[0014] Based on the timestamp, the first key, and the random factor, the byte stream message body is verified to obtain a second checksum;

[0015] In response to the first checksum being equal to the second checksum, it is determined that the application programming interface request has passed verification;

[0016] In response to the first checksum not being equal to the second checksum, it is determined that the application programming interface request verification failed.

[0017] Thirdly, embodiments of this application provide an interface request security verification device, applied to a client, the device comprising:

[0018] A key pair acquisition module is used to acquire a key pair from a preset key manager, the key pair including: a first key and a second key;

[0019] The verification factor acquisition module is used to generate random factors and obtain timestamps in real time.

[0020] The checksum acquisition module is used to perform sampling verification processing on the byte stream message body transmitted by the application programming interface request based on the timestamp, the first key and the random factor, and obtain the checksum;

[0021] The verification module is used to send an application programming interface (API) request to a preset server, wherein the API request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp, so that the preset server performs security verification on the API request.

[0022] Fourthly, embodiments of this application provide an interface request security verification device, applied to a server, the device comprising:

[0023] The request parsing module is used to respond to the application programming interface (API) request, parse the API request, and obtain the byte stream message body, first checksum, second key, random factor and timestamp of the API request sent by the client;

[0024] The key acquisition module is used to acquire a first key paired with the second key from a preset key manager;

[0025] The checksum acquisition module is used to perform checksum processing on the byte stream message body based on the timestamp, the first key and the random factor, and obtain a second checksum;

[0026] The verification module is configured to determine that the application programming interface request has passed verification in response to the first checksum being equal to the second checksum.

[0027] The verification module is further configured to determine that the application programming interface request verification has failed in response to the first checksum being unequal to the second checksum.

[0028] Fifthly, embodiments of this application provide an interface request security verification system, including: a client, a server, and a key manager, wherein...

[0029] The client is configured to obtain a key pair from the key manager, the key pair including a first key and a second key; and to generate a random factor and obtain a timestamp in real time.

[0030] The client is also configured to perform sampling verification processing on the byte stream message body transmitted by the application programming interface request based on the timestamp, the first key and the random factor, and obtain a checksum;

[0031] The client is further configured to send an application programming interface (API) request to the server, wherein the API request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp;

[0032] The server is configured to respond to an application programming interface (API) request, parse the API request, and obtain the byte stream message body, first checksum, second key, random factor, and timestamp of the API request sent by the client.

[0033] The server is also used to obtain a first key paired with the second key from the key manager;

[0034] The server is also used to perform verification processing on the byte stream message body based on the timestamp, the first key and the random factor, and obtain a second checksum;

[0035] The server is further configured to obtain a verification result for determining the application programming interface request based on the comparison result between the first checksum and the second checksum.

[0036] Sixthly, embodiments of this application also disclose an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the interface request security verification method described in embodiments of this application.

[0037] In a seventh aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the interface request security verification method disclosed in embodiments of this application.

[0038] The interface request security verification method disclosed in this application obtains a key pair from a preset key manager. The key pair includes a first key and a second key. A random factor is generated, and a timestamp is obtained in real time. Then, based on the timestamp, the first key, and the random factor, the byte stream message body transmitted by the application programming interface request is sampled and verified to obtain a checksum. The application programming interface request is sent to a preset server. The application programming interface request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp, so that the preset server performs security verification on the application programming interface request. Since the data sampling length for calculating the checksum is fixed and does not depend on the length of the byte stream message body, the time complexity is reduced. It also helps to shorten the time consumption of interface request security verification and reduce the resource consumption caused by risk identification. It can quickly identify risky traffic and promptly block potential attacks on the server.

[0039] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0040] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0041] Figure 1 This is one of the flowcharts of the interface request security verification method disclosed in the embodiments of this application;

[0042] Figure 2 This is a schematic diagram illustrating the principle of the verification and acquisition method in the interface request security verification method disclosed in this application embodiment;

[0043] Figure 3 This is the second flowchart of the interface request security verification method disclosed in the embodiments of this application;

[0044] Figure 4 This is an interactive schematic diagram of the interface request security verification method disclosed in the embodiments of this application;

[0045] Figure 5 This is a schematic diagram illustrating the principle of the interface request security verification method disclosed in the embodiments of this application;

[0046] Figure 6 This is one of the schematic diagrams of the interface request security verification device disclosed in the embodiments of this application;

[0047] Figure 7 This is the second schematic diagram of the interface request security verification device disclosed in the embodiments of this application;

[0048] Figure 8 A block diagram schematically illustrates an electronic device for performing the method according to this application; and

[0049] Figure 9 A storage unit for holding or carrying program code implementing the method according to this application is schematically shown. 。 Detailed Implementation

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

[0051] Reference Figure 1The present application discloses an interface request security verification method, which includes steps 110 to 140.

[0052] Step 110: Obtain a key pair from a preset key manager. The key pair includes a first key and a second key.

[0053] The key pair is generated by the preset key manager in response to the client's registration request and sent to the client.

[0054] For example, a client can obtain a key pair bound to it by registering a key service with a preset key manager. In the embodiments of this application, the methods for generating and obtaining key pairs are not limited.

[0055] In the embodiments of this application, before the client and server communicate, the client first requests a key pair from a preset key manager. The key pair is bound to the client and includes a first key and a second key (i.e., Key). The preset key manager maintains the mapping relationship between the first key and the second key. The first key is used to sign the data to be transmitted, and the signed data, processed with the first key, is sent to the receiver along with the second key. After receiving the signed data, the receiver parses it to obtain the second key. Then, based on the mapping relationship stored on the server, it obtains the first key that matches the second key, and then uses the first key to perform signature verification processing on the signed data.

[0056] Step 120: Generate a random factor and obtain the timestamp in real time.

[0057] The timestamp mentioned here is the current timestamp of the client system. In the embodiments of this application, the specific method for obtaining the timestamp in real time is not limited.

[0058] In the embodiments of this application, the specific method for generating random factors is not limited. For example, hash algorithms such as sha256 and md5 can be used to generate random factors.

[0059] Step 130: Based on the timestamp, the first key, and the random factor, perform sampling verification on the byte stream message body transmitted by the application programming interface request to obtain a checksum.

[0060] In the embodiments of this application, when calculating the checksum, an index table first needs to be initialized, referred to as the "first index table" in this embodiment. The length of the first index table is equal to the number of sampled bytes of the byte stream message body, determined according to the algorithm requirements for calculating the checksum. Optionally, the first index table is initialized as a list of different prime numbers. For example, when the algorithm for calculating the checksum requires extracting N bytes of content from the byte stream message body, the length of the first index table can be set to N, where N is an integer greater than 1. Taking N as an example, the first index table has a length of 8 bytes, and the first index table can be initialized to store the following prime numbers in sequence: 1, 3, 7, 11, 19, 13, 31, 17.

[0061] In the embodiments of this application, the first index table prime number table is generated and stored in a system containing clients and servers for use by the clients and servers.

[0062] In some optional embodiments, the step of sampling and verifying the byte stream message body transmitted by the application programming interface request based on the timestamp, the first key, and the random factor to obtain a checksum includes: calculating a result value using a preset function based on the timestamp, the first key, and the random factor; obtaining a first index value obtained by taking the result value modulo a target length, wherein the target length is the table length of a pre-initialized first index table; reading the first index table based on the first index values ​​to obtain a specified number of second index values; obtaining the byte content corresponding to each second index value in the byte stream message body transmitted by the application programming interface request; and performing a preset operation on the obtained byte content to obtain a checksum. The specified number is determined according to application requirements.

[0063] When a client sends an Application Programming Interface (API) request, it first obtains a timestamp in real time and generates a random factor. Then, it samples the request payload (i.e., the byte stream message body transmitted in the API request) according to a preset verification algorithm, and then uses the verification algorithm to calculate a checksum sum1 of the sampled result. The following section combines... Figure 2 The schematic diagram shown illustrates the principle and the scheme for generating checksums.

[0064] In practice, the timestamp, the first key, and the random factor can be used as input parameters for a preset function, which is then executed to calculate a result value. In the embodiments of this application, the specific implementation of the preset function is not limited.

[0065] Next, the calculated result is modulo the length of the first index table to obtain the first index value. This first index value is used to index the entries stored in the first index table. In some optional embodiments, taking the calculated result value as M (a positive integer), the first index value i can be obtained using the formula M%N=i, where "%" represents the modulo operator. The first index value obtained by the modulo operation is an integer greater than or equal to 0 and less than N. Taking the first index table as an array with indices from 0 to N-1 as an example, the first index value can be used to index the contents of the first to Nth entries in the first index table. When the generated values ​​are different, different first index values ​​will be obtained after modulo the length of the first index table. Based on these different first index values, different entries in the first index table can be read.

[0066] Then, the first index table is read based on the first index value to obtain a specified number of second index values. In some embodiments of this application, taking an array of length N to represent the first index table as an example, the first index value i is used as the subscript of the array element, then the i-th array element in the array represents the content of the (i+1)-th table entry in the first index table, and the content of the (i+1)-th table entry will be used as the second index value.

[0067] In embodiments of this application, the first index table is read based on the first index value to obtain a specified number of second index values. The second index values ​​are used to sample the byte content in the byte stream message body to obtain byte stream message body data for calculating the checksum.

[0068] In the embodiments of this application, to ensure the security and accuracy of the verification while saving computational resources and time costs during verification, it is necessary to extract a portion of the byte content from the byte stream message body for calculating the checksum. Specifically, multiple second index values ​​are first obtained from a first index table, and then, based on each obtained second index value, the byte content from the byte stream message body is extracted for calculating the checksum.

[0069] In some optional embodiments, the step of reading the first index table based on the first index value to obtain a specified number of second index values ​​involves taking the index table position corresponding to the first index value as the starting position, and reading the contents of the specified number of consecutively stored entries in the first index table from the starting position in the first index table to obtain a specified number of second index values.

[0070] Taking a sampling length of 5 for the byte stream message body (the specified number is equal to 5) and storing the following prime numbers in the first index table in sequence: 1, 3, 7, 11, 19, 13, 31, 17 as an example, if the calculated first index value is equal to 1, then the contents of the table entries at the 2nd, 3rd, 4th, 5th, and 6th index positions in the first index table, namely 3, 7, 11, 19, and 13, are read as the second index values ​​for subsequent calculation and verification.

[0071] Next, using the second index value as the sampling index, data is sampled from the byte stream message body passed by the application programming interface request.

[0072] In some optional embodiments, the step of obtaining the byte content corresponding to each of the second index values ​​in the byte stream message body of the application programming interface request includes: treating the byte stream message body of the application programming interface request as a logical ring and determining the starting index position of the logical ring; obtaining the current index position of the logical ring according to the starting index position and the second index value; and obtaining the byte content in the byte stream message body corresponding to the current index position in the logical ring. The preset data reading direction can be clockwise or counterclockwise.

[0073] The starting index position of the logical ring can be the position corresponding to the first byte in the byte stream message body.

[0074] In some optional embodiments, obtaining the current index position of the logical ring based on the starting index position and the second index value includes: when the logical ring is read clockwise, shifting the starting index position clockwise by the second index value by byte positions to obtain the current index position of the logical ring; and when the logical ring is read counterclockwise, shifting the starting index position counterclockwise by the second index value by byte positions to obtain the current index position of the logical ring.

[0075] Taking a byte stream message body containing K bytes of data as an example, the byte stream message body can be virtualized as a counter-clockwise logical ring, which contains K bytes of data. The starting index position of the logical ring is set. In this way, starting from the starting index position, any integer index value can be used to read the data at the corresponding position in the logical ring, thereby realizing the sampling of the byte stream message body.

[0076] To virtualize the byte stream message body as such Figure 2Taking the counter-clockwise logic ring described above as an example, the logic ring position marked by the number "0" is the starting index position. When the second index value is 3, it can move 3 index positions counter-clockwise from the starting index position to obtain the logic ring position corresponding to the number "3", which is used as the current index position. When the second index value is 7, it can move 7 index positions counter-clockwise from the starting index position to obtain the logic ring position corresponding to the number "7", which is used as the current index position.

[0077] In some optional embodiments, obtaining the current index position of the logical ring based on the starting index position and the second index value includes: when the logical ring is a clockwise read logical ring, shifting the starting index position clockwise by the second index value minus one byte to obtain the current index position of the logical ring; and when the logical ring is a counterclockwise read logical ring, shifting the starting index position counterclockwise by the second index value minus one byte to obtain the current index position of the logical ring.

[0078] In some alternative embodiments, other methods can be used to obtain the current index position of the logical ring based on the starting index position and the second index value, which will not be listed one by one in this application embodiment.

[0079] Using the above method, one byte of content can be extracted from the byte stream message body based on each second index value, and a specified number of bytes of content can be extracted from the byte stream message body based on a specified number of second index values.

[0080] Next, calculate the checksum of the specified number of extracted bytes.

[0081] In some optional embodiments, the step of performing a preset operation on the acquired byte content to obtain a checksum includes: adding the original code of the acquired byte content to obtain a first binary value; in response to the first value being greater than 16 bits, truncating the high bits of the first value that exceed 16 bits and adding them to the low bits of the first value to obtain a second value; and inverting the second value bit by bit to obtain a checksum.

[0082] In some alternative embodiments, performing a preset operation on the acquired byte content to obtain a checksum includes: adding the original code of the acquired byte content to obtain a checksum.

[0083] For a specific example, let the byte stream message body be "This is a test", corresponding to the byte stream message body [84104 105 115 32 105 115 32 97 32 116 101 115 116], with a length of 14; the first key is "TestKey001"; the random factor is 531497; the timestamp is 1731400361; the first index table is [1 3 7 11 1913 31 17], with a length of 8; assuming the preset function is: to accumulate each byte of the random factor, timestamp, and first key, and the sum is the result value, that is, sum = 531497 + 1731400361 + 84 + 101 + 115 + 116 + 75 + 101 + 121 + 48 + 48 + 49 = 1731932716. The length of the first index table is 8, so the sampling length is 8 bytes. The first index sampled is: 1731932716%8 = 4. The second index sampled in sequence is: 19, 13, 31, 17, 1, 3, 7, 11.

[0084] Taking the data stored in the byte stream message body as: [84 101 115 116 75 101 121 48 48 49] as an example, the byte stream message body is virtualized as a logical ring read in a counter-clockwise direction. Taking the first byte (i.e., byte content 84) in the byte stream message body as the starting index position, when sampling the byte stream message body in a counter-clockwise direction, the corresponding relationship between the index position and byte content of each byte in the byte stream message body is shown in Table 1 below:

[0085] Table 1: Diagram of the correspondence between data and index positions in the byte stream message body

[0086]

[0087]

[0088] Finally, a specified number of bytes are extracted from the byte stream message body as sample data of the byte stream message body, and a checksum is calculated.

[0089] Taking the method of calculating the checksum as an example, the cumulative sum of the extracted sampled data is calculated, and then the inversion operation is performed. The cumulative sum of the 8 sampled data in Table 1 above is equal to 803, and the corresponding binary original code is: 1100100011. The result of the inversion operation is: 1111110011011100, and the corresponding decimal number is: 64732. Therefore, 64732 is the checksum of the final result.

[0090] In some alternative embodiments, assuming that the sum is 131292 during the checksum calculation, the corresponding binary original code is 10 00000000 11011100. Then the left "10" is the high bit that exceeds 16 bits. The high bit "10" is superimposed on the low bit 00000000 11011100, that is, 00000000 11011100 + 10 = 00000000 11011110. The result of performing the inverse operation is 1111111100100001, which corresponds to the decimal number 65313. Then 65313 is the checksum of the final result.

[0091] In some alternative embodiments, for cases where the sum exceeds 16 bits, the operation of adding the overflowing high bits to the low bits can be repeated until the sum is less than or equal to 16 bits.

[0092] The interface request security verification method disclosed in this application sample the byte stream message body by virtualizing it as a logical ring, generating a two-stage index based on random numbers, and then using the index generated in the second stage to sample the logical ring, thereby sampling the byte stream message body. This further enhances the security of the verification and reduces the probability of the algorithm being brute-forced.

[0093] Step 140: Send an application programming interface (API) request to a preset server, wherein the API request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp, so that the preset server performs security verification on the API request.

[0094] In some optional embodiments, optionally, an application programming interface (API) request is sent to a preset server, wherein the API request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp, including: generating an API request to be sent based on the byte stream message body; setting the checksum, the second key, the random factor, and the timestamp into the communication protocol request header of the API request to be sent to obtain the API request; and sending the API request to the preset server. For example, the checksum, the second key, the random factor, and the timestamp are set into the HTTP header field of the API request and sent to the preset server.

[0095] In some optional embodiments, the preset server performs security verification on the client based on the application programming interface (API) request, including: in response to the API request, parsing the API request to obtain the byte stream message body, first checksum, second key, random factor, and timestamp of the API request sent by the client; obtaining a first key paired with the second key from a preset key manager; performing verification processing on the byte stream message body based on the timestamp, the first key, and the random factor to obtain a second checksum; in response to the first checksum being equal to the second checksum, determining that the API request verification has passed; in response to the first checksum being unequal to the second checksum, determining that the API request verification has failed.

[0096] After receiving an application programming interface (API) request from a client, the pre-defined server, in addition to parsing the API request to obtain a byte stream message body, further parses the random factor, second key, timestamp, and checksum sum1 from the HTTP header of the API request. Then, it samples data in the byte stream message body of the request according to the verification algorithm, and then uses the verification algorithm to calculate a checksum sum2. Finally, the server verifies the API request based on the comparison result between the locally calculated checksum and the received checksum.

[0097] The specific implementation of each step of the preset server requesting security verification of the client based on the application programming interface is described in the relevant descriptions in the following embodiments, and will not be repeated here.

[0098] In summary, the interface request security verification method disclosed in this application obtains a key pair from a preset key manager, the key pair including a first key and a second key, and generates a random factor and obtains a timestamp in real time. Then, based on the timestamp, the first key, and the random factor, it performs sampling verification processing on the byte stream message body transmitted by the application programming interface request to obtain a checksum. The application programming interface request is then sent to a preset server, wherein the application programming interface request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp. This allows the preset server to perform security verification on the application programming interface request. Since the data sampling length for calculating the checksum is fixed and does not depend on the length of the byte stream message body, the time complexity is reduced. This also helps to shorten the time consumption of interface request security verification and reduce the resource consumption caused by risk identification, enabling rapid identification of risky traffic and timely blocking of potential attacks on the server. Furthermore, by combining the random factor with the sampling checksum, the verification result is more discrete, which helps to reduce the probability of the algorithm being brute-forced, thereby improving verification security.

[0099] Based on the foregoing embodiments, this application also discloses an interface request security verification method, applied to the server side, such as... Figure 3 As shown, the method includes steps 310 to 350.

[0100] Step 310: In response to the application programming interface (API) request, parse the API request to obtain the byte stream message body, first checksum, second key, random factor, and timestamp of the API request sent by the client.

[0101] In some optional embodiments, the client and the server communicate according to a preset communication protocol. After receiving the application programming interface (API) request, the server parses the API request according to the preset protocol to obtain the byte stream message body of the API request sent by the client, the first checksum, the second key, the random factor, and the timestamp.

[0102] Step 320: Obtain the first key paired with the second key from the preset key manager.

[0103] The server obtains the first key paired with the second key through a preset key manager.

[0104] Step 330: Based on the timestamp, the first key, and the random factor, perform verification processing on the byte stream message body to obtain a second checksum.

[0105] In some optional embodiments, the step of performing verification processing on the byte stream message body based on the timestamp, the first key, and the random factor to obtain a second checksum includes: calculating a result value using a preset function based on the timestamp, the first key, and the random factor; obtaining a first index value obtained by taking the result value modulo a target length, wherein the target length is the table length of a pre-initialized first index table; reading the first index table based on the first index value to obtain a specified number of second index values; obtaining the byte content in the byte stream message body corresponding to each second index value; and performing preset operation processing on the obtained byte content to obtain a checksum.

[0106] The specific implementation method for calculating a result value using a preset function based on the timestamp, the first key, and the random factor is the same as the method used by the client to calculate a result value using a preset function based on the timestamp, the first key, and the random factor in the previous embodiment, and will not be repeated here.

[0107] The initialization method for the first index table is described above and will not be repeated here.

[0108] In some optional embodiments, obtaining the byte content in the byte stream message body corresponding to each of the second index values ​​includes: taking the byte stream message body as a logical ring and determining the starting index position of the logical ring; obtaining the current index position of the logical ring according to the starting index position and the second index value; and obtaining the byte content in the byte stream message body corresponding to the current index position in the logical ring.

[0109] For the specific implementation of each step in obtaining the byte content corresponding to each second index value in the byte stream message body, please refer to the specific implementation of sampling the byte stream message body in the previous embodiment, which will not be repeated here.

[0110] For details on how to perform a preset operation on the obtained byte content to obtain the checksum, please refer to the specific implementation of the client's checksum calculation in the previous embodiment, which will not be repeated here.

[0111] Step 340: In response to the first checksum being equal to the second checksum, it is determined that the application programming interface request has passed verification.

[0112] Step 350: In response to the first checksum not being equal to the second checksum, it is determined that the application programming interface request verification failed.

[0113] Taking the first checksum obtained by the server as sum1 and the second checksum obtained by the server by sampling the byte stream message body as sum2 as an example, the server compares whether sum1 and sum2 are equal. If the first checksum sum1 and the second checksum sum2 are equal, the check passes and the subsequent business processing continues; if the first checksum sum1 and the second checksum sum2 are not equal, the check fails and the subsequent business processing is terminated.

[0114] In summary, the interface request security verification method disclosed in this application involves the server responding to an application programming interface (API) request, parsing the API request to obtain the byte stream message body, first checksum, second key, random factor, and timestamp of the API request sent by the client; obtaining a first key paired with the second key from a preset key manager; performing verification processing on the byte stream message body based on the timestamp, the first key, and the random factor to obtain a second checksum; determining that the API request verification passes when the first checksum is equal to the second checksum; and determining that the API request verification fails when the first checksum is not equal to the second checksum. This method reduces time complexity because the data sampling length for calculating the checksum is fixed and does not depend on the length of the byte stream message body. It also helps shorten the time consumption for interface request security verification and reduce resource consumption caused by risk identification, enabling rapid identification of risky traffic and timely blocking of potential attacks on the server. Furthermore, by combining the random factor with the sampling checksum, the verification result is more discrete, which helps reduce the probability of the algorithm being brute-forced, thereby improving verification security.

[0115] Based on the foregoing embodiments, this application also discloses an interface request security verification system, the system comprising: a client, a server, and a key manager.

[0116] The following is combined Figure 4 The interactive diagram shown and Figure 5 The schematic diagram of the security verification principle shown in the figure illustrates the specific implementation of the interface request security verification system.

[0117] like Figure 5 As shown, the client and server respectively request key pairs from the key manager. The key pair includes a first key and a second key. Optionally, the first key serves as the private key used for data signing, and the second key serves as the public key for querying the first key.

[0118] like Figure 4 As shown, optionally, in the interface request security verification system,

[0119] The key manager is used to generate and manage key pairs according to requests from the client or the server.

[0120] The client is configured to obtain a key pair from the key manager, the key pair including a first key and a second key; and to generate a random factor and obtain a timestamp in real time.

[0121] The client is also configured to perform sampling verification processing on the byte stream message body transmitted by the application programming interface request based on the timestamp, the first key and the random factor, and obtain a checksum;

[0122] The client is further configured to send an application programming interface (API) request to the server, wherein the API request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp;

[0123] The server is configured to respond to an application programming interface (API) request, parse the API request, and obtain the byte stream message body, first checksum, second key, random factor, and timestamp of the API request sent by the client.

[0124] The server is also used to obtain a first key paired with the second key from the key manager;

[0125] The server is also used to perform verification processing on the byte stream message body based on the timestamp, the first key and the random factor, and obtain a second checksum;

[0126] The server is further configured to obtain a verification result for determining the application programming interface request based on the comparison result between the first checksum and the second checksum.

[0127] Then, the server sends the application programming interface request verification result to the server.

[0128] Optionally, based on the comparison result of the first checksum and the second checksum, the verification result of the application programming interface request is obtained, including: in response to the first checksum being equal to the second checksum, determining that the application programming interface request has passed verification; in response to the first checksum being unequal to the second checksum, determining that the application programming interface request has failed verification.

[0129] For specific implementation methods of each step in the interaction process between the client and the server, please refer to the specific implementation methods of the relevant operations in the previous embodiments, which will not be repeated here.

[0130] In summary, the interface request security verification system disclosed in this application uses a two-stage index value calculated based on random numbers to sample and calculate the checksum of the byte stream message body of the application programming interface request. Since the data sampling length for calculating the checksum is fixed and does not depend on the length of the byte stream message body, the time complexity is reduced. This also helps shorten the time consumption of interface request security verification and reduce the resource consumption caused by risk identification, enabling rapid identification of risky traffic and timely blocking of potential attacks on the server. Furthermore, by incorporating a random factor into the sampling checksum, the verification result is more discrete, which helps reduce the probability of the algorithm being brute-forced, thereby improving verification security.

[0131] Based on the foregoing embodiments, this application also discloses an interface request security verification device, applied to a client, such as... Figure 6 As shown, the device includes:

[0132] The key pair acquisition module 610 is used to acquire a key pair from a preset key manager, the key pair including: a first key and a second key;

[0133] The verification factor acquisition module 620 is used to generate random factors and obtain timestamps in real time;

[0134] The checksum acquisition module 630 is used to perform sampling verification processing on the byte stream message body transmitted by the application programming interface request based on the timestamp, the first key and the random factor, and to obtain the checksum.

[0135] The verification module 640 is used to send an application programming interface request to a preset server, wherein the application programming interface request carries the byte stream message body, the checksum, the second key, the random factor and the timestamp, so that the preset server performs security verification on the application programming interface request.

[0136] Optionally, the checksum acquisition module 630 is further configured to:

[0137] Based on the timestamp, the first key, and the random factor, a result value is calculated using a preset function;

[0138] Obtain the first index value by taking the result value modulo the target length, wherein the target length is: the table length of the first index table obtained by pre-initialization;

[0139] Read the first index table based on the first index value to obtain a specified number of second index values;

[0140] Obtain the byte content corresponding to each of the second index values ​​in the byte stream message body passed by the application programming interface request;

[0141] The acquired byte content is subjected to a preset operation to obtain a checksum.

[0142] Optionally, obtaining the byte content at the position corresponding to each of the second index values ​​in the byte stream message body passed by the application programming interface request includes:

[0143] The byte stream message body passed by the application programming interface request is taken as a logical ring, and the starting index position of the logical ring is determined.

[0144] Based on the starting index position and the second index value, obtain the current index position of the logical ring;

[0145] Obtain the byte content in the byte stream message body corresponding to the current index position in the logical ring.

[0146] The interface request security verification device disclosed in this application is used to implement the interface request security verification method described in this application. The specific implementation methods of each module of the device will not be repeated here, but can be found in the specific implementation methods of the corresponding steps in the method embodiments.

[0147] The interface request security verification device disclosed in this application is applied to a client. It obtains a key pair from a preset key manager, the key pair including a first key and a second key, and generates a random factor and obtains a timestamp in real time. Then, based on the timestamp, the first key, and the random factor, it performs sampling verification processing on the byte stream message body transmitted by the application programming interface (API) request to obtain a checksum. The API request is then sent to a preset server, wherein the API request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp. This allows the preset server to perform security verification on the API request. Since the data sampling length for calculating the checksum is fixed and does not depend on the length of the byte stream message body, the time complexity is reduced. This also helps shorten the time consumption for interface request security verification and reduce the resource consumption caused by risk identification, enabling rapid identification of risky traffic and timely blocking of potential attacks on the server. Simultaneously, by combining the random factor with the sampling checksum, the verification result is more discrete, which helps reduce the probability of the algorithm being brute-forced, thereby improving verification security.

[0148] Based on the foregoing embodiments, this application also discloses an interface request security verification device, applied to the server side, such as... Figure 7 As shown, the device includes:

[0149] The request parsing module 710 is used to respond to the application programming interface request, parse the application programming interface request, and obtain the byte stream message body, first checksum, second key, random factor and timestamp of the application programming interface request sent by the client;

[0150] The key acquisition module 720 is used to acquire a first key paired with the second key from a preset key manager;

[0151] The checksum acquisition module 730 is used to perform checksum processing on the byte stream message body based on the timestamp, the first key and the random factor, and obtain a second checksum;

[0152] Verification module 740 is configured to determine that the application programming interface request verification has passed in response to the first checksum being equal to the second checksum;

[0153] The verification module 740 is further configured to determine that the application programming interface request verification has failed in response to the first checksum being unequal to the second checksum.

[0154] Optionally, the checksum acquisition module 730 is further configured to:

[0155] Based on the timestamp, the first key, and the random factor, a result value is calculated using a preset function;

[0156] Obtain the first index value by taking the result value modulo the target length, wherein the target length is: the table length of the first index table obtained by pre-initialization;

[0157] Read the first index table based on the first index value to obtain a specified number of second index values;

[0158] Obtain the byte content at each position corresponding to the second index value in the byte stream message body;

[0159] The acquired byte content is subjected to a preset operation to obtain a checksum.

[0160] The interface request security verification device disclosed in this application is used to implement the interface request security verification method described in this application. The specific implementation methods of each module of the device will not be repeated here, but can be found in the specific implementation methods of the corresponding steps in the method embodiments.

[0161] The interface request security verification device disclosed in this application involves the server responding to an Application Programming Interface (API) request, parsing the API request, and obtaining the byte stream message body, first checksum, second key, random factor, and timestamp of the API request sent by the client. A first key paired with the second key is obtained from a preset key manager. Based on the timestamp, the first key, and the random factor, the byte stream message body is verified to obtain a second checksum. If the first checksum is equal to the second checksum, the API request verification is deemed successful; if the first checksum is not equal to the second checksum, the API request verification is deemed unsuccessful. This method reduces time complexity because the data sampling length for calculating the checksum is fixed and does not depend on the length of the byte stream message body. It also helps shorten the time consumption for interface request security verification and reduce the resource consumption caused by risk identification, enabling rapid identification of risky traffic and timely blocking of potential attacks on the server. Furthermore, by combining the random factor with the sampling checksum, the verification result is more discrete, which helps reduce the probability of the algorithm being brute-forced, thereby improving verification security.

[0162] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus embodiments, since they are fundamentally similar to the method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0163] The above provides a detailed description of the interface request security verification method and apparatus provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method of this application and its core idea. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the idea of ​​this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0164] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0165] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the electronic device according to the embodiments of this application. This application can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such a program implementing this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0166] For example, Figure 8 An electronic device is shown that can implement the methods according to this application. The electronic device can be a PC, mobile terminal, personal digital assistant, tablet computer, etc. The electronic device conventionally includes a processor 810 and a memory 820, and program code 830 stored in the memory 820 and executable on the processor 810. When the processor 810 executes the program code 830, it implements the methods described in the above embodiments. The memory 820 can be a computer program product or a computer-readable medium. The memory 820 can be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. The memory 820 has a storage space 8201 for the program code 830 of a computer program for performing any of the method steps described above. For example, the storage space 8201 for the program code 830 can include various computer programs for implementing the various steps in the above methods. The program code 830 is computer-readable code. These computer programs can be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, CDs, memory cards, or floppy disks. The computer program includes computer-readable code that, when executed on an electronic device, causes the electronic device to perform the method according to the above embodiments.

[0167] This application also discloses a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the interface request security verification method as described in this application.

[0168] Such a computer program product can be a computer-readable storage medium, which can have the same characteristics as... Figure 8The memory 820 in the illustrated electronic device is similarly arranged as storage segments, storage spaces, etc. Program code can be stored, for example, in a compressed form on the computer-readable storage medium. The computer-readable storage medium is typically as shown in the reference... Figure 9 The portable or fixed storage unit is described above. Typically, the storage unit includes computer-readable code 830', which is code read by a processor and, when executed by the processor, implements the various steps in the method described above.

[0169] The terms "an embodiment," "embodiment," or "one or more embodiments" as used herein mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of this application. Furthermore, please note that the examples of the phrase "in one embodiment" do not necessarily all refer to the same embodiment.

[0170] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0171] In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0172] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for verifying the security of interface requests, applied to a client, characterized in that, The method includes: A key pair is obtained from a preset key manager, the key pair including: a first key and a second key; Generate random factors and obtain timestamps in real time; Based on the timestamp, the first key, and the random factor, a result value is calculated using a preset function; Obtain the first index value by taking the result value modulo the target length, wherein the target length is: the table length of the first index table obtained by pre-initialization; Read the first index table based on the first index value to obtain a specified number of second index values; Obtain the byte content corresponding to each of the second index values ​​in the byte stream message body passed by the application programming interface request; Perform a preset operation on the acquired byte content to obtain a checksum; An application programming interface (API) request is sent to a preset server, wherein the API request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp, so that the preset server performs security verification on the API request.

2. The method according to claim 1, characterized in that, The step of obtaining the byte content corresponding to each of the second index values ​​in the byte stream message body passed by the application programming interface request includes: The byte stream message body passed by the application programming interface request is taken as a logical ring, and the starting index position of the logical ring is determined. Based on the starting index position and the second index value, obtain the current index position of the logical ring; Obtain the byte content in the byte stream message body corresponding to the current index position in the logical ring.

3. An interface request security verification method, applied to the server side, characterized in that, The method includes: In response to an application programming interface (API) request, the API request is parsed to obtain the byte stream message body of the API request sent by the client, the first checksum, the second key, the random factor, and the timestamp; Obtain the first key paired with the second key from the preset key manager; Based on the timestamp, the first key, and the random factor, a result value is calculated using a preset function; Obtain the first index value by taking the result value modulo the target length, wherein the target length is: the table length of the first index table obtained by pre-initialization; Read the first index table based on the first index value to obtain a specified number of second index values; Obtain the byte content at each position corresponding to the second index value in the byte stream message body; Perform a preset operation on the acquired byte content to obtain a second checksum; In response to the first checksum being equal to the second checksum, it is determined that the application programming interface request has passed verification; In response to the first checksum not being equal to the second checksum, it is determined that the application programming interface request verification failed.

4. An interface request security verification device, characterized in that, Applied to a client, the device includes: A key pair acquisition module is used to acquire a key pair from a preset key manager, the key pair including: a first key and a second key; The verification factor acquisition module is used to generate random factors and obtain timestamps in real time. The checksum acquisition module is configured to: calculate a result value using a preset function based on the timestamp, the first key, and the random factor; acquire a first index value obtained by taking the result value modulo a target length, wherein the target length is the table length of a pre-initialized first index table; read the first index table based on the first index value to obtain a specified number of second index values; acquire the byte content corresponding to each second index value in the byte stream message body; and perform preset operation processing on the acquired byte content to obtain a checksum. The verification module is used to send an application programming interface (API) request to a preset server, wherein the API request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp, so that the preset server performs security verification on the API request.

5. An interface request security verification device, characterized in that, Applied to the server side, the device includes: The request parsing module is used to respond to the application programming interface (API) request, parse the API request, and obtain the byte stream message body, first checksum, second key, random factor and timestamp of the API request sent by the client; The key acquisition module is used to acquire a first key paired with the second key from a preset key manager; The checksum acquisition module is configured to: calculate a result value using a preset function based on the timestamp, the first key, and the random factor; acquire a first index value obtained by taking the result value modulo a target length, wherein the target length is the table length of a pre-initialized first index table; read the first index table based on the first index value to obtain a specified number of second index values; acquire the byte content corresponding to each second index value in the byte stream message body; and perform preset operation processing on the acquired byte content to obtain a second checksum. The verification module is configured to determine that the application programming interface request has passed verification in response to the first checksum being equal to the second checksum. The verification module is further configured to determine that the application programming interface request verification has failed in response to the first checksum being unequal to the second checksum.

6. An interface request security verification system, characterized in that, The system includes: a client, a server, and a key manager, wherein, The client is configured to obtain a key pair from the key manager, the key pair including a first key and a second key; and to generate a random factor and obtain a timestamp in real time. The client is further configured to: calculate a result value using a preset function based on the timestamp, the first key, and the random factor; obtain a first index value obtained by taking the result value modulo a target length, wherein the target length is the table length of a pre-initialized first index table; read the first index table based on the first index value to obtain a specified number of second index values; obtain the byte content corresponding to each second index value in the byte stream message body; perform preset operation processing on the obtained byte content to obtain a checksum; The client is further configured to send an application programming interface (API) request to the server, wherein the API request carries the byte stream message body, the checksum, the second key, the random factor, and the timestamp; The server is configured to respond to an application programming interface (API) request, parse the API request, and obtain the byte stream message body, first checksum, second key, random factor, and timestamp of the API request sent by the client. The server is also used to obtain a first key paired with the second key from the key manager; The server is further configured to: calculate a result value using a preset function based on the timestamp, the first key, and the random factor; obtain a first index value obtained by taking the result value modulo a target length, wherein the target length is the table length of a pre-initialized first index table; read the first index table based on the first index value to obtain a specified number of second index values; obtain the byte content in the byte stream message body corresponding to each second index value; perform preset operation processing on the obtained byte content to obtain a second checksum; The server is further configured to obtain a verification result for determining the application programming interface request based on the comparison result between the first checksum and the second checksum.

7. An electronic device, comprising a memory, a processor, and program code stored in the memory and executable on the processor, characterized in that, When the processor executes the program code, it implements the method according to any one of claims 1 to 3.

8. A computer-readable storage medium having program code stored thereon, characterized in that, When the program code is executed by the processor, it implements the steps of the method described in any one of claims 1 to 3.

Images