A security verification method and system in an API request process

Abstract

The application provides a security verification method and system in an API request process, and relates to the technical field of network security. The method comprises the following steps: receiving an API calling instruction and an HTTP request sent by a browser; generating a server public key and a symmetric key; generating a digital envelope according to the symmetric key and a server private key corresponding to the server public key; sending the symmetric key, the server public key and the digital envelope to the browser to obtain a digital digest after decryption; generating browser information; combining the digital digest, the browser information, request information and a request method to generate a second digital signature of the HTTP request; sending the browser information and the second digital signature as a request header of the HTTP request to the server for verification; if the HTTP request is verified, performing a business processing flow of the HTTP request, otherwise, terminating the business processing flow. The efficiency and effectiveness of the anti-replay attack are improved.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a security verification method and system for API request processes. Background Technology

[0002] With the rapid development of information technology, network security issues have become increasingly prominent, especially in areas such as authentication and data transmission. Replay attack prevention, as an important branch of network security, has received widespread attention for its research and application. A replay attack refers to an attacker capturing legitimate communication data packets and retransmitting them at a later time to deceive the system or gain illegal benefits. This attack method poses a serious threat to many security protocols and systems. In recent years, with the popularization and deepening of network applications, research on replay attack prevention technology has also been continuously deepening. From the initial simple timestamp mechanism to later sequence number mechanisms, challenge-response mechanisms, and so on, various replay attack prevention schemes have emerged. While these schemes improve system security, they also bring new technical challenges and requirements.

[0003] Security verification during API request processing is essential because it effectively prevents malicious attackers from performing unauthorized operations by repeatedly sending legitimate requests. This avoids security issues such as user data leakage, financial loss, and identity theft, ensuring system security, transaction integrity, and user trust. At the same time, this verification mechanism helps prevent abuse attacks, such as denial-of-service (DoS) attacks.

[0004] However, with the rapid development of network applications, the amount of data that the system needs to process and the number of concurrent requests are constantly increasing. Existing anti-replay attack technologies are limited by clock drift and serial number space exhaustion, resulting in performance bottlenecks when handling a large number of concurrent requests. As time goes on, encryption vulnerabilities will gradually appear, greatly increasing the risk of data transmission. Summary of the Invention

[0005] To address the challenges posed by the rapid development of network applications, which leads to an increasing volume of data and concurrent requests, existing anti-replay attack technologies are constrained by clock drift and sequence number space exhaustion. This results in performance bottlenecks when handling large numbers of concurrent requests, and encryption vulnerabilities gradually emerge over time, significantly increasing the risk of data transmission. Therefore, this invention provides a secure verification method and system for the API request process.

[0006] The technical solutions provided by the embodiments of the present invention are as follows:

[0007] First aspect

[0008] This invention provides a security verification method for API request processes, comprising:

[0009] S1: Receives API call instructions and HTTP requests from the browser;

[0010] S2: Generate the server public key and the symmetric key associated with the HTTP request;

[0011] S3: Combine a random number encryption algorithm and generate a digital envelope based on a symmetric key and a server private key corresponding to the server public key, wherein the digital envelope includes a first digital signature, wherein the first digital signature includes a digital digest related to the HTTP request;

[0012] S4: Send the symmetric key, server public key, and digital envelope to the browser, and decrypt them to obtain the digital digest;

[0013] S5: Generate browser information, which includes a random number, browser timestamp, browser token, and browser fingerprint;

[0014] S6: Combine digital digest, browser information, request information, and request method to generate a second digital signature for the HTTP request;

[0015] S7: Send an HTTP request to the server with browser information and a second digital signature as the request header for verification;

[0016] S8: If the HTTP request is successfully verified, proceed with the business processing flow for the HTTP request; otherwise, terminate the business processing flow.

[0017] Second aspect

[0018] This invention provides a security verification system for the API request process, comprising:

[0019] processor;

[0020] A memory storing computer-readable instructions that, when executed by the processor, implement the security verification method in the API request process as described in the first aspect.

[0021] Third aspect

[0022] The present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the security verification method in the API request process as described in the first aspect.

[0023] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0024] In this invention, a unique, custom-designed dual digital signature is generated by combining information such as browser-generated random numbers, timestamps, browser fingerprints, and digital digests, along with the server-generated public key and the symmetric key associated with the HTTP request. This ensures the uniqueness and security of each HTTP request. By using encryption and signing, the performance bottlenecks caused by clock drift and sequence number space exhaustion in traditional anti-replay attack techniques are avoided. This invention exhibits better adaptability when handling a large number of concurrent requests and can encrypt concurrent requests for extended periods. Consequently, it ensures that the data transmission process can effectively detect and defend against various replay attacks, effectively reducing the occurrence of vulnerabilities and significantly lowering the security risks of data transmission. Attached Figure Description

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

[0026] Figure 1 A flowchart illustrating a security verification method during an API request process provided by an embodiment of the present invention;

[0027] Figure 2 This is a schematic diagram of the structure of a security verification system in the API request process provided by an embodiment of the present invention. Detailed Implementation

[0028] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0029] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0030] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, their intended meanings are consistent. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, their intended meanings are consistent.

[0031] In this embodiment of the invention, sometimes a subscript such as W1 may be mistakenly written as a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0032] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0033] Reference manual attached Figure 1 The diagram illustrates a flowchart of a security verification method for an API request process provided by an embodiment of the present invention.

[0034] This invention provides a security verification method for API request processes. This method can be implemented by a security verification device used in the API request process, which can be a terminal or a server. The processing flow of the security verification method for API request processes may include the following steps:

[0035] S1: Receives API call instructions and HTTP requests from the browser.

[0036] API (Application Programming Interface) calls are requests sent by clients to servers, requesting the server to provide a service or perform an operation. API calls are a form of software-to-software interaction, allowing clients to access server-side functions or data. HTTP (Hypertext Transfer Protocol) requests are the standard method of communication between clients and servers, using HTTP to transmit data. In API calls, the HTTP request is the carrier used to actually transmit the API call instructions, including the request method (e.g., GET, POST), the path to the target resource, and the data to be transmitted. GET and POST are two common request methods in the HTTP protocol, used by clients (such as browsers) to send requests to servers to perform different types of operations.

[0037] It's important to note that receiving and processing API call instructions and HTTP requests from the browser ensures smooth communication between the client and server, guarantees that requested data accurately reaches the server, supports subsequent data processing and responses, and improves interaction efficiency and system flexibility. Simultaneously, the received requests provide a fundamental guarantee for subsequent security verification and business processing.

[0038] S2: Generate the server public key and the symmetric key associated with the HTTP request.

[0039] In asymmetric encryption, the server's public key is a publicly available encryption key used in conjunction with the server's private key. It is primarily used to encrypt data. The public key is public, and any client can use it to encrypt data, but only the server, holding the private key, can decrypt it. Common asymmetric encryption algorithms include RSA and ECDSA. A symmetric key is an encryption key used in symmetric encryption. It is used for both encryption and decryption, employing the same key. Therefore, symmetric encryption is highly efficient, but both parties must securely share this key. Common symmetric encryption algorithms include AES and DES.

[0040] It should be noted that by generating a server public key and a symmetric key associated with the HTTP request, the secure data transmission between the client and the server is ensured. At the same time, by combining asymmetric and symmetric encryption, encryption efficiency is improved and sensitive information is not leaked, thus guaranteeing the confidentiality and integrity of the data.

[0041] S3: Combine a random number encryption algorithm and generate a digital envelope based on the symmetric key and the server private key corresponding to the server public key. The digital envelope includes a first digital signature, which includes a digital digest associated with the HTTP request.

[0042] Random number encryption algorithms use random numbers (or nonces) as part of the input to encrypt data. The random number ensures that each encryption result is different, even if the encrypted data is the same, increasing security and preventing replay or pre-computation attacks. Digital envelopes combine symmetric and asymmetric encryption techniques to ensure secure data transmission. Data is encrypted using symmetric encryption, and the symmetric key used for decryption is further encrypted using the recipient's public key. The recipient uses their private key to decrypt the symmetric key and then decrypts the data. A first digital signature is an encrypted signature generated by the server using its private key. It verifies the data's origin and integrity; only the corresponding public key can verify the signature, ensuring the data has not been tampered with and its origin is legitimate. A digital digest is a unique "fingerprint" of a piece of data. A hash algorithm maps data of arbitrary length to a short, fixed-length digest, ensuring data integrity. If the data changes, the digest also changes.

[0043] Specifically, by combining random number encryption, symmetric encryption, and asymmetric encryption, secure digital envelopes and digital signatures are generated to ensure the integrity and confidentiality of data transmission. At the same time, digital digests are used to verify whether the data has been tampered with, greatly improving communication security and preventing attacks and forged requests.

[0044] In practical use, the specific method for obtaining the digital digest is as follows: the browser requests a digital envelope from the server. Upon receiving the request, the server generates a session-related random string A, calculates the digital digest MD of A, encrypts MD using the server's private key to obtain the digital signature SD, encrypts SD using the AES algorithm and the key SK to obtain the digital envelope DE, and returns it to the browser. The browser receives the digital envelope DE, decrypts it using the AES algorithm and the key SK to obtain the digital signature SD, decrypts the digital signature SD using the server's public key to obtain the digital digest MD, and encrypts and stores it locally.

[0045] In one possible implementation, S3 specifically includes:

[0046] S301: Generate a random string about the HTTP request using a random number encryption algorithm.

[0047] The random string is an unpredictable random number generated by the system to enhance security. It is usually generated by a pseudo-random number generator to ensure that the data in each request is unique, avoiding replay attacks or pre-computation attacks. The introduction of the random string ensures that the generated signature and encryption result are different each time, even if the request content is the same.

[0048] S302: Generate a digital digest of the random string.

[0049] S303: Encrypt the digital digest using the server's private key to obtain the first digital signature.

[0050] S304: The digital envelope is obtained by encrypting the first digital signature using a symmetric key through a symmetric encryption algorithm.

[0051] Specifically, a random string is first generated using a random number encryption algorithm. Then, a digital digest of this random string is generated, and the digest is encrypted using the server's private key to obtain the first digital signature. Next, the first digital signature is encrypted using a symmetric encryption algorithm with a symmetric key to generate a digital envelope. This entire process, by introducing a random string and a double encryption mechanism, ensures the uniqueness and security of the data, prevents replay attacks and data tampering, and enhances the confidentiality and integrity of communication.

[0052] S4: Send the symmetric key, server public key, and digital envelope to the browser, and decrypt them to obtain the digital digest.

[0053] It should be noted that by sending the symmetric key, server public key, and digital envelope to the browser and decrypting them on the browser side, the security and integrity of data transmission can be ensured. The browser can securely decrypt and obtain the digital digest, thereby verifying the legality and accuracy of the data, preventing data from being tampered with or stolen during transmission, and ensuring secure communication between the client and the server.

[0054] In one possible implementation, S4 specifically includes:

[0055] S401: Decrypt the digital envelope using a symmetric key via a symmetric encryption algorithm to obtain the first digital signature.

[0056] S402: Use the server's public key to decrypt the first digital signature to obtain a digital digest.

[0057] Specifically, the digital envelope is first decrypted using a symmetric encryption algorithm and a symmetric key to obtain the first digital signature. Then, the server's public key is used to decrypt this digital signature, yielding the original digital digest. This entire process employs a dual encryption and decryption mechanism to ensure secure data transmission and prevent sensitive information from being stolen or tampered with during transmission. By using the server's private key for encryption and the client's public key for decryption, the integrity and authenticity of the data's origin are guaranteed, effectively resisting replay attacks and tampering.

[0058] S5: Generate browser information.

[0059] The browser information includes a random number, browser timestamp, browser token, and browser fingerprint.

[0060] Specifically, a random number R and the current timestamp TS are generated on the browser side. A token T is generated using a custom symmetric encryption algorithm. The fingerprint P of the currently viewed data is obtained through a self-developed browser framework. By combining the random number and timestamp, a unique and dynamic token can be generated, effectively preventing replay attacks. Meanwhile, the symmetric encryption algorithm has high encryption and decryption efficiency, suitable for handling a large number of requests. Furthermore, obtaining fingerprint information through the self-developed browser framework further enhances the uniqueness and security of the token, ensuring the confidentiality and integrity of data transmission.

[0061] S6: Combine digital digest, browser information, request information, and request method to generate a second digital signature for the HTTP request.

[0062] The request information refers to the parameters and request body of the HTTP request, which may include query parameters, form data, JSON objects, and other actual data sent. The HTTP request method, such as GET, POST, and PUT, specifies the specific operation to be performed in this request. The signature algorithm is used to generate a digital signature based on the above information, ensuring the authenticity and integrity of the data and guaranteeing that the signature is unforgeable.

[0063] It should be noted that by combining digital digests, browser information, request information, and request methods, a custom signature algorithm is used to generate a second digital signature, ensuring the integrity and uniqueness of the request and effectively preventing replay attacks and data tampering. This process verifies the legitimacy of the request, enhances its security, and ensures secure communication between the front-end and back-end. By signing the request parameters and verifying them on the server side, this invention effectively prevents attackers from tampering with the request content. The use of signatures ensures data integrity and consistency, enabling any unauthorized modifications to request parameters to be promptly identified and rejected.

[0064] In practical use, the second digital signature is generated as follows: When the browser initiates an API call, a random number R and the current timestamp TS are generated on the browser side. A token T is generated using a custom symmetric encryption algorithm. The fingerprint P of the currently viewed request is obtained through a self-developed browser framework. The HTTP request signature SG is generated using the token T + fingerprint P + locally stored digital digest MD + request information (request parameters and request body) + request method (GET or POST) and a custom signature algorithm AR1. The specific process for generating the signature SG is as follows: Extract the token T. Extract the browser's fingerprint P. Extract the digital digest MD. Extract the parameters from the URL, sort them lexicographically, and then swap the last two items (this step usually ends after sorting the parameters lexicographically; swapping the last two items simply establishes a front-end and back-end agreed-upon algorithm, increasing the difficulty of forging parameters). Extract the request body parameters, sort them lexicographically, and then swap the positions of the last two items (generally, no processing is done on the parameters in the body; the sorting and swapping operations here are to simply establish a front-end and back-end agreed-upon algorithm, increasing the difficulty of forging parameters). If the corresponding parameter is not obtained, use a newline character "\n" as a placeholder. Obtain the request method, such as GET, POST, PUT, DELETE, OPTIONS, etc. Concatenate all the strings obtained in the above steps into a signature string S using a newline character "\n". Calculate a second digital signature using a custom signature algorithm AR1(S) and add it to the original HTTP request header.

[0065] In one possible implementation, the request information includes request parameters and a request body, and the request method includes GET request method, POST request method, PUT request method, DELETE request method, and OPTIONS request method.

[0066] In this context, request parameters, also known as URLs, are additional information sent to the server via the URL. The request body, also known as the request body, contains the actual data content transmitted in the HTTP request and is commonly found in POST and PUT requests, such as submitting form data or JSON data. The request body is located in the main part of the request and is not displayed in the URL.

[0067] S6 specifically includes:

[0068] S601: If the request information is obtained, sort the request parameters and request body in the request information in lexicographical order; otherwise, proceed to step S604.

[0069] Lexicographical order refers to sorting strings according to alphabetical order, similar to arranging words in a dictionary.

[0070] S602: Swap the last two items in the sorted request parameters and output the swapped request parameters as a string.

[0071] S603: Swap the first and second items in the sorted request body and output the swapped request body as a string.

[0072] S604: Use newline characters as placeholders for request parameters and request body, and output the placeholders as strings.

[0073] Placeholders are characters or symbols used to replace actual values ​​when data is missing.

[0074] S605: Concatenate the obtained strings using newline characters to obtain the signature string.

[0075] The signature string is a string that integrates all request information (such as request parameters, request body, etc.) and concatenates them according to certain rules to form a digital signature.

[0076] S606: Calculate the signature string to obtain the second digital signature.

[0077] Specifically, the parameters and request body in the request information are first sorted lexicographically. Then, the last two parameters are swapped, and the first and second items in the request body are swapped. If any request information is missing, a newline character is used as a placeholder. Next, all processed strings are concatenated into a signature string using newline characters. Finally, the signature string is encrypted using a custom signature algorithm to generate a second digital signature. This processing method, by standardizing the sorting and swapping of the request information, ensures the uniqueness and tamper-proof capability of the signature, avoids inconsistencies in signatures due to different data orders, and also improves the system's security in preventing replay attacks.

[0078] S7: Send an HTTP request to the server for verification, with browser information and a second digital signature as the request header.

[0079] The request header is a part of an HTTP request that contains metadata about the request. It conveys information unrelated to the request itself but needed by the server, such as the request type, content format, and authorization information. This information helps the server correctly understand and process the request. By sending browser information and a second digital signature as part of the HTTP request header to the server, the security and uniqueness of the request are increased. The server can use this information to verify the legitimacy of the request, ensuring that the request origin is trustworthy and has not been tampered with, preventing malicious attackers from forging requests or replaying previous requests, thereby improving the overall system security and communication reliability.

[0080] In practical use, the verification process is as follows: After the server intercepts the request through an interceptor, it first verifies the legitimacy of the current request through the system's identity authentication system. If the verification is successful, the second digital signature is decrypted. After decryption, the token T, fingerprint P, digital digest MD, request information, and request method are then verified for legitimacy in sequence. Only after successful verification does the business logic processing proceed. If any verification fails, it is immediately logged, and an error message is returned to the browser, ending the processing.

[0081] In one possible implementation, S7 specifically includes:

[0082] S701: Sends browser information and an HTTP request with a second digital signature to the server via the HTTPS protocol.

[0083] Among them, the identity authentication system is a key mechanism to ensure that a system or service is only accessed by legitimately verified users. It uses multiple verification methods to ensure the authenticity of user identities, prevent unauthorized access, and enhance system security.

[0084] S702: Verify the legitimacy of the HTTP request through the server's authentication system. If the verification is successful, proceed to step S703; otherwise, proceed to step S709.

[0085] An identity authentication system is a technical system used to verify the identity of users, devices, or systems. It ensures that the access requester is legitimate and authorized. The identity authentication system confirms the true identity of the requester by collecting and verifying the provided credentials (such as username and password, digital certificate, two-factor authentication, etc.) in order to grant them the corresponding access rights.

[0086] S703: Decrypt the second digital signature using a custom signature algorithm. If decryption is successful, proceed to step S704; otherwise, proceed to step S709.

[0087] Specifically, the second digital signature sent from the browser is obtained and decrypted using a custom signature algorithm AR2(SG) to obtain a string containing the token T, fingerprint P, digital digest MD, request information, and request method. If decryption fails, it indicates that SG is invalid, the process is logged, an error message is returned, and the process ends.

[0088] S704: Verify the decrypted browser token. If the verification passes, proceed to step S705; otherwise, proceed to step S709.

[0089] In one possible implementation, S704 specifically includes:

[0090] S7041: Decrypt the browser token to obtain a random number and a browser timestamp.

[0091] S7042: Determine whether the random number has been used in the server's cache. If it has not been used, store the random number in the cache and proceed to step S7043. Otherwise, return a verification error message to the browser.

[0092] S7043: Determine whether the time difference between the browser timestamp and the current time is less than the preset time difference. If yes, output that the browser token verification passed; otherwise, return the verification error message to the browser.

[0093] Optionally, the preset time difference can be 15 minutes.

[0094] It should be noted that those skilled in the art can set the preset time difference according to actual needs, and this invention does not limit this.

[0095] It's important to note that the browser token is decrypted using a custom symmetric encryption algorithm to obtain a random number and a timestamp. Next, it checks if this random number has already been used in the server cache. If not, it's stored and the process continues. Otherwise, an error message is returned. Finally, it verifies that the time difference between the timestamp and the current time is within the allowed range. This entire process ensures the uniqueness of the request, prevents replay attacks, and the timestamp verification adds a constraint on the timeliness of the request, enhancing system security.

[0096] For example, after obtaining token T, the system decrypts it using a custom symmetric encryption algorithm to obtain a "random number R and timestamp TS". It then checks if the random number R appears in the cache (primarily recording random numbers R from previous requests). If it does, it indicates that the random number R has been reused, suggesting a replay attack. The system logs this, returns an error message, and terminates the process. If it doesn't appear, it means the random number R hasn't been reused and stores it in the cache for later use. Next, it checks if the current time minus the timestamp TS is less than 15 minutes (this value can be adjusted based on actual system performance). If the difference is greater than 15 minutes, it indicates that the request took too long to travel from the browser to the server, posing a risk of tampering. The system logs this, returns an error message, and terminates the process. If the difference is less than 15 minutes, this step passes verification, and the next step is performed.

[0097] S705: Verify the decrypted browser fingerprint. If the verification passes, proceed to step S706; otherwise, proceed to step S709.

[0098] In one possible implementation, S705 specifically includes:

[0099] S7051: Determine whether there is a correspondence between the browser fingerprint and the SessionID in the server's cache. If not, proceed to step S7052; otherwise, proceed to step S7053.

[0100] The SessionID is a unique identifier assigned by the server to each user session, which is used to maintain the user's session state across multiple requests.

[0101] S7052: Store the corresponding relationship in the cache and output the browser fingerprint verification as passed.

[0102] S7053: Obtain the first SessionID of the browser fingerprint request and the second SessionID corresponding to the browser fingerprint in the cache.

[0103] S7054: Determine if the first SessionID and the second SessionID are the same. If they are the same, return a verification error message to the browser; otherwise, output that the browser fingerprint verification is successful.

[0104] Specifically, the process first checks if a correspondence exists between the browser fingerprint and the SessionID in the server cache. If not, the correspondence is stored in the cache and validated. If a correspondence exists, the SessionID sent by the browser is retrieved and compared with the SessionID in the cache. If the two SessionIDs are the same, a validation error message is returned; otherwise, validation passes. This process ensures that the request originates from a legitimate session environment, preventing session hijacking and forged requests, thus improving the security of user sessions and the system's protection capabilities.

[0105] For example, after obtaining the browser fingerprint P, it checks if fingerprint P appears in the cache (mainly recording the correspondence between browser fingerprints and SessionIDs from previous requests). If it hasn't appeared, it means this is the browser's first call to the server, and the fingerprint P and SessionID correspondence are recorded in the cache. This step passes verification and proceeds to the next step. If fingerprint P has appeared in the cache, the current request's SessionID is obtained and compared with the SessionID corresponding to fingerprint P in the cache. If the two SessionIDs are different, it means the same browser has logged into the same system twice. In this scenario, there is suspicion of "using the same browser to forge multiple SessionIDs or copying SessionIDs from other places." A log is recorded, an error message is returned, and processing ends. If the current request's SessionID is the same as the SessionID in the cache, this step passes verification and proceeds to the next step.

[0106] S706: Verify the decrypted digital digest. If the verification passes, proceed to step S707; otherwise, proceed to step S709.

[0107] In one possible implementation, S706 specifically includes:

[0108] S7061: Obtain the random string to be verified carried in the digital digest.

[0109] S7062: Calculate the digital digest of the random string to be verified.

[0110] S7063: Determine whether the digital digest matches the digital digest to be verified. If they match, output that the digital digest verification passed; otherwise, return a verification error message to the browser.

[0111] It should be noted that the process involves extracting a random string to be verified from the digital digest, and then recalculating the digital digest based on this random string. The original digital digest is then compared with the recalculated digest. If they match, the verification passes; otherwise, an error message is returned to the browser. This process ensures the integrity and authenticity of the data, prevents data from being tampered with or forged during transmission, and improves the system's security and resistance to attacks.

[0112] For example, to obtain the digital digest (MD) from the request, retrieve the random string A from the server in the session, calculate the digital digest MD2 of A, and determine if MD and MD2 are consistent. If they are inconsistent, it means that the digital digest MD on the browser side has been tampered with, log the error, return an error message, and end the process. If they are consistent, this step passes the verification, and proceed to the next verification step.

[0113] S707: Verify the decrypted request information and request method. If the verification passes, proceed to step S708; otherwise, proceed to step S709.

[0114] In one possible implementation, S707 specifically includes:

[0115] S7071: Based on the request method, the server's permission management system determines whether the browser has permission to access the request parameters. If permission is granted, the request parameters are retrieved, and the process proceeds to step S7072. Otherwise, a verification error message is returned to the browser.

[0116] S7072: Determine whether the request parameters conform to the sorting format of the swapped request parameters. If they do, proceed to step S7073; otherwise, return a verification error message to the browser.

[0117] S7073: Obtain the request body and determine whether the request body conforms to the sorting format of the swapped request body. If it does, proceed to step S7074; otherwise, return a verification error message to the browser.

[0118] S7074: The output request information and request method have passed the validation.

[0119] Specifically, the server's access control system determines whether the browser has permission to access the request parameters. If permission is granted, the system checks whether the request parameters conform to the swapped order. The same validation is then performed on the request body. If both the request parameters and the request body meet the requirements, the validation passes. This process ensures that requests and data are correctly validated and ordered, preventing malicious tampering, guaranteeing the legitimacy of requests and the integrity of data, and effectively enhancing system security.

[0120] For example, upon obtaining the requested URL, the access control system is called to determine if the current user has permission to access the URL. If permission is denied, a log entry is logged, an error message is returned, and the process ends. If permission is granted, the URL parameters are retrieved, and it is determined whether the parameters are sorted according to the rule of "sorting by lexicographical order and then swapping the last two items." The request body is retrieved, and it is determined whether it is sorted according to the rule of "sorting by lexicographical order and then swapping the first two items." If either sorting rule is not met, a log entry is logged, an error message is returned, and the process ends. If both sorting rules are met, business logic processing is performed, and the result is returned to the browser.

[0121] S708: Output HTTP request verification passed.

[0122] S709: Return the verification error message to the browser.

[0123] Specifically, the browser information and second digital signature are first sent to the server via HTTPS. The server verifies the legitimacy of the request using its authentication system. Then, a custom signature algorithm is used to decrypt the second digital signature, and the browser token, browser fingerprint, digital digest, request information, and request method are verified one by one. If all verifications pass, the legitimacy of the request is confirmed, and subsequent business processing is executed. If any verification fails, an error message is returned to the browser. This entire process, through multiple verification mechanisms, ensures the authenticity of the request source, the integrity of the data, and the security of communication, effectively preventing forged requests and replay attacks.

[0124] S8: If the HTTP request is successfully verified, proceed with the business processing flow for the HTTP request; otherwise, terminate the business processing flow.

[0125] The business processing flow refers to a series of business-related operations performed by the server after receiving and validating a client's request. Step S8 ensures that only valid requests that pass verification can trigger the server-side business processing flow, preventing malicious requests or requests that tamper with data from affecting the normal operation of the system. By terminating business processing when verification fails, the system's security and stability are effectively improved, ensuring the accuracy of data processing and reducing security risks.

[0126] In practical use, the entire data transmission process utilizes the HTTPS protocol for communication between the browser and server. This ensures data confidentiality, integrity, and effective authentication to prevent man-in-the-middle attacks. Upon receiving API call instructions and HTTP requests, a public key and symmetric key are generated, combined with a random number to encrypt and generate a digital envelope, which is then transmitted to the browser. The browser decrypts the envelope, generates a digitally signed request, and sends it to the server. The server then performs a series of verifications, including verifying the token, fingerprint, digital digest, request information, and request method, to ensure the request's legitimacy and integrity. If verification is successful, the server executes the business processing flow; otherwise, processing terminates. This multi-layered encryption and verification mechanism ensures request security, prevents data tampering, replay attacks, and unauthorized requests, significantly improving system security and stability.

[0127] This invention comprehensively utilizes multiple security mechanisms to form a multi-layered, all-encompassing protection system. This design not only effectively resists single-type replay attacks but also maintains strong defense capabilities against complex and ever-changing attack methods. By combining technologies such as browser fingerprinting, dynamic keys, and timestamps, this invention can accurately identify and verify the authenticity and timeliness of requests. This greatly reduces the possibility of false positives, ensuring the smooth passage of legitimate requests while effectively intercepting malicious replay requests. The custom signature algorithm and interface authorization mechanism of this invention enhance the robustness of the system. Even if attackers attempt to attack by intercepting keys or tampering with request parameters, it is difficult to bypass the multiple defenses set up by this invention. This invention can detect and defend against various attack behaviors, including cookie copying, key interception attacks, freshness attacks, staleness attacks, man-in-the-middle attacks, and interface privilege escalation attacks. This greatly improves the overall security of the system. The design of this invention allows for flexible adjustment of security policies and parameter settings according to actual needs. At the same time, its modular architecture facilitates future functional expansion and upgrades based on technological developments or new security threats. By effectively preventing replay attacks, this invention helps protect user privacy and data security, thereby enhancing user trust in the system. This not only enhances the user experience but also helps maintain a company's reputation and customer relationships. The comprehensive defense strategy of this invention reduces system failures and security incidents caused by replay attacks. This lowers maintenance costs and potential economic losses for businesses.

[0128] The beneficial effects of the technical solution provided by the present invention include at least the following:

[0129] In this invention, a unique, custom-designed dual digital signature is generated by combining information such as browser-generated random numbers, timestamps, browser fingerprints, and digital digests, along with the server-generated public key and the symmetric key associated with the HTTP request. This ensures the uniqueness and security of each HTTP request. By using encryption and signing, the performance bottlenecks caused by clock drift and sequence number space exhaustion in traditional anti-replay attack techniques are avoided. This invention exhibits better adaptability when handling a large number of concurrent requests and can encrypt concurrent requests for extended periods. Consequently, it ensures that the data transmission process can effectively detect and defend against various replay attacks, effectively reducing the occurrence of vulnerabilities and significantly lowering the security risks of data transmission.

[0130] Reference manual attached Figure 2 The diagram shows a structural schematic of a security verification system for the API request process provided by the present invention.

[0131] The present invention also provides a security verification system 20 for the API request process, applied to the aforementioned security verification method for the API request process, comprising:

[0132] Processor 201.

[0133] The memory 202 stores computer-readable instructions that, when executed by the processor 201, implement a security verification method in the API request process as described in the method embodiment.

[0134] The security verification system 20 for the API request process provided by this invention can execute the security verification method for the API request process described above and achieve the same or similar technical effects. To avoid duplication, this invention will not elaborate further.

[0135] The beneficial effects of the technical solution provided by the present invention include at least the following:

[0136] In this invention, a unique, custom-designed dual digital signature is generated by combining information such as browser-generated random numbers, timestamps, browser fingerprints, and digital digests, along with the server-generated public key and the symmetric key associated with the HTTP request. This ensures the uniqueness and security of each HTTP request. By using encryption and signing, the performance bottlenecks caused by clock drift and sequence number space exhaustion in traditional anti-replay attack techniques are avoided. This invention exhibits better adaptability when handling a large number of concurrent requests and can encrypt concurrent requests for extended periods. Consequently, it ensures that the data transmission process can effectively detect and defend against various replay attacks, effectively reducing the occurrence of vulnerabilities and significantly lowering the security risks of data transmission.

[0137] It should be understood that the processor in the embodiments of the present invention can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0138] It should also be understood that the memory in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0139] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0140] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0141] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0142] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0143] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0144] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0145] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0146] 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0147] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0148] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0149] This invention provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a security verification method in the API request process as described in the method embodiment.

[0150] The present invention provides a computer-readable storage medium that can implement the steps and effects of the security verification method in the API request process of the above method embodiments. To avoid repetition, the present invention will not repeat them.

[0151] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0152] In this invention, a unique, custom-designed dual digital signature is generated by combining information such as browser-generated random numbers, timestamps, browser fingerprints, and digital digests, along with the server-generated public key and the symmetric key associated with the HTTP request. This ensures the uniqueness and security of each HTTP request. By using encryption and signing, the performance bottlenecks caused by clock drift and sequence number space exhaustion in traditional anti-replay attack techniques are avoided. This invention exhibits better adaptability when handling a large number of concurrent requests and can encrypt concurrent requests for extended periods. Consequently, it ensures that the data transmission process can effectively detect and defend against various replay attacks, effectively reducing the occurrence of vulnerabilities and significantly lowering the security risks of data transmission.

[0153] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0154] The following points need to be explained:

[0155] (1) The accompanying drawings of the embodiments of the present invention only involve the structures involved in the embodiments of the present invention. Other structures can refer to the general design.

[0156] (2) For clarity, the thickness of layers or regions is enlarged or reduced in the drawings used to describe embodiments of the present invention; that is, these drawings are not drawn to actual scale. It is understood that when an element such as a layer, film, region, or substrate is referred to as being “above” or “below” another element, the element may be “directly” located “above” or “below” the other element, or there may be intermediate elements.

[0157] (3) Where there is no conflict, the embodiments of the present invention and the features in the embodiments can be combined with each other to obtain new embodiments.

[0158] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. The scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A security verification method during an API request process, characterized in that, include: S1: Receives API call instructions and HTTP requests from the browser; S2: Generate the server public key and the symmetric key associated with the HTTP request; S3: Combine a random number encryption algorithm and generate a digital envelope based on the symmetric key and the server private key corresponding to the server public key, wherein the digital envelope includes a first digital signature, wherein the first digital signature includes a digital digest related to the HTTP request; S4: Send the symmetric key, the server public key, and the digital envelope to the browser, and decrypt them in the browser to obtain the digital digest; S5: Generate browser information, wherein the browser information includes a random number, a browser timestamp, a browser token, and a browser fingerprint; S6: Combine the digital digest, the browser information, the request information, and the request method to generate a second digital signature for the HTTP request; S7: Send an HTTP request with the browser information and the second digital signature as the request header to the server for verification; S8: If the HTTP request is verified successfully, proceed with the business processing flow for the HTTP request; otherwise, terminate the business processing flow. Specifically, S6 includes: S601: If the request information is obtained, sort the request parameters and request body in the request information in lexicographical order; otherwise, proceed to step S604. S602: Swap the last two items in the sorted request parameters and output the swapped request parameters as a string. S603: Swap the first and second items in the sorted request body and output the resulting swapped request body as a string. S604: Use a newline character as a placeholder for the request parameters and the request body, and output the placeholder as a string; S605: Concatenate the obtained strings using the newline character to obtain the signature string; S606: Calculate the signature string to obtain the second digital signature.

2. The security verification method in the API request process according to claim 1, characterized in that, S3 specifically includes: S301: Generate a random string about the HTTP request using a random number encryption algorithm; S302: Generate a digital digest of the random string; S303: Encrypt the digital digest using the server's private key to obtain the first digital signature; S304: The first digital signature is encrypted using the symmetric key through a symmetric encryption algorithm to obtain the digital envelope.

3. The security verification method in the API request process according to claim 1, characterized in that, S4 specifically includes: S401: Decrypt the digital envelope using the symmetric key through a symmetric encryption algorithm to obtain the first digital signature; S402: Use the server's public key to decrypt the first digital signature to obtain the digital digest.

4. The security verification method in the API request process according to claim 1, characterized in that, The request information includes request parameters and a request body, and the request methods include GET, POST, PUT, DELETE, and OPTIONS request methods.

5. The security verification method in the API request process according to claim 1, characterized in that, Specifically, S7 includes: S701: Send the browser information and the HTTP request with the second digital signature to the server via the HTTPS protocol; S702: Verify the legitimacy of the HTTP request through the server's identity authentication system. If the verification is successful, proceed to step S703; otherwise, proceed to step S709. S703: Decrypt the second digital signature. If the decryption is successful, proceed to step S704; otherwise, proceed to step S709. S704: Verify the decrypted browser token. If the verification passes, proceed to step S705; otherwise, proceed to step S709. S705: Verify the decrypted browser fingerprint. If the verification passes, proceed to step S706; otherwise, proceed to step S709. S706: Verify the digital digest obtained by decryption. If the verification passes, proceed to step S707; otherwise, proceed to step S709. S707: Verify the decrypted request information and request method. If the verification passes, proceed to step S708; otherwise, proceed to step S709. S708: Output: The HTTP request verification passed; S709: Return the verification error message to the browser.

6. The security verification method in the API request process according to claim 5, characterized in that, Specifically, S704 includes: S7041: Decrypt the browser token to obtain the random number and the browser timestamp; S7042: Determine whether the random number has been used in the server's cache. If it has not been used, store the random number in the cache and proceed to step S7043. Otherwise, return a verification error message to the browser. S7043: Determine whether the time difference between the browser timestamp and the current time is less than a preset time difference. If so, output that the browser token verification passed; otherwise, return a verification error message to the browser.

7. The security verification method in the API request process according to claim 5, characterized in that, Specifically, S705 includes: S7051: Determine whether there is a correspondence between the browser fingerprint and the SessionID in the server's cache. If not, proceed to step S7052; otherwise, proceed to step S7053. S7052: Store the corresponding relationship in the cache and output that the browser fingerprint verification is successful; S7053: Obtain the first SessionID of the browser fingerprint request and the second SessionID corresponding to the browser fingerprint in the cache; S7054: Determine whether the first SessionID and the second SessionID are the same. If they are the same, return a verification error message to the browser; otherwise, output that the browser fingerprint verification is successful.

8. The security verification method in the API request process according to claim 5, characterized in that, Specifically, S706 includes: S7061: Obtain the random string to be verified carried in the digital digest; S7062: Calculate the digital digest of the random string to be verified; S7063: Determine whether the digital digest is consistent with the digital digest to be verified. If they are consistent, output that the digital digest has passed verification; otherwise, return a verification error message to the browser.

9. The security verification method in the API request process according to claim 5, characterized in that, The S707 specifically includes: S7071: Based on the request method, the server's permission management system determines whether the browser has permission to access the request parameters. If it has permission, the request parameters are obtained, and the process proceeds to step S7072. Otherwise, a verification error message is returned to the browser. S7072: Determine whether the request parameters conform to the sorting format of the swapped request parameters. If they do, proceed to step S7073; otherwise, return a verification error message to the browser. S7073: Obtain the request body and determine whether the request body conforms to the sorting format of the swapped request body. If it does, proceed to step S7074; otherwise, return a verification error message to the browser. S7074: Output the request information and the request method, and verify that they pass the check.

10. A security verification system for API request processes, characterized in that, include: processor; A memory storing computer-readable instructions that, when executed by the processor, implement the security verification method in the API request process as described in any one of claims 1 to 9.

Images