Security verification method and system in API (Application Program Interface) request process

Abstract

The invention provides a security verification method and system in an API request process, and relates to the technical field of network security, and the method comprises the steps: receiving an API call 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 a browser, and decrypting to obtain a digital digest; generating browser information; generating a second digital signature of the HTTP request in combination with the digital digest, the browser information, the request information and the request method; the browser information and the HTTP request with the second digital signature as a request header are sent to a server for verification; and under the condition that the HTTP request passes verification, performing a service processing flow on the HTTP request, otherwise, terminating the service processing flow. And the replay attack prevention efficiency and effectiveness are improved.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a security verification method and system in an API request process. Background Art

[0002] With the rapid development of information technology, network security issues have become increasingly prominent, especially in the fields of identity authentication and data transmission. As an important branch of network security, the research and application of anti-replay attack has received extensive attention. Replay attack refers to the attacker capturing legitimate communication data packets and resending them at a later time to deceive the system or obtain illegal benefits. This type of attack poses a serious threat to many security protocols and systems. In recent years, with the popularization and deepening of network applications, the research on anti-replay attack technology has also been continuously deepened. From the initial simple timestamp mechanism to the later serial number mechanism, challenge-response mechanism, etc., various anti-replay attack schemes have emerged in an endless stream. While these schemes improve system security, they also bring new technical challenges and requirements.

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

[0004] However, with the rapid development of network applications, the amount of data and the number of concurrent requests that the system needs to process are increasing. The existing anti-replay attack technology is limited by constraints such as clock drift and sequence number space exhaustion, resulting in performance bottlenecks when processing a large number of concurrent requests. Encryption vulnerabilities will gradually appear over time, greatly increasing the risk of data transmission. Summary of the invention

[0005] In order to solve the technical problems existing in the prior art that with the rapid development of network applications, the amount of data and the number of concurrent requests that the system needs to process are constantly increasing, and the existing anti-replay attack technology is limited by constraints such as clock drift and sequence number space exhaustion, resulting in performance bottlenecks in the anti-replay attack technology when processing a large number of concurrent requests, and encryption vulnerabilities will gradually appear over time, greatly increasing the risk of data transmission, the present invention provides a security verification method and system in an API request process.

[0006] The technical solution provided by the embodiment of the present invention is as follows:

[0007] First aspect

[0008] An embodiment of the present invention provides a security verification method in an API request process, including:

[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: combining a random number encryption algorithm and generating a digital envelope according to the 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 summary 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 summary;

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

[0014] S6: Generate a second digital signature of the HTTP request by combining the digital summary, browser information, request information and request method;

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

[0016] S8: If the HTTP request verification passes, the business processing flow is performed on the HTTP request; otherwise, the business processing flow is terminated.

[0017] Second aspect

[0018] An embodiment of the present invention provides a security verification system in an API request process, including:

[0019] processor;

[0020] A memory having computer-readable instructions stored thereon, wherein when the computer-readable instructions are executed by the processor, the security verification method in the API request process as described in the first aspect is implemented.

[0021] The third aspect

[0022] An embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the security verification method in the API request process as described in the first aspect is implemented.

[0023] The beneficial effects brought about by the technical solution provided by the embodiment of the present invention include at least:

[0024] In the present invention, by combining the random number, timestamp, browser fingerprint and digital summary information generated by the browser, the server public key generated by the server and the symmetric key related to the HTTP request, a unique customized double digital signature is generated to ensure the uniqueness and security of each HTTP request. By using encryption and signature, the performance bottleneck problem caused by clock drift and sequence number space exhaustion of traditional anti-replay attack technology is avoided. It has better adaptability when processing a large number of concurrent requests and can encrypt concurrent requests for a long time, thereby ensuring that the data transmission process can effectively detect and defend against various replay attack behaviors, effectively reducing the occurrence of vulnerabilities, thereby greatly reducing the security risks of data transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0026] Figure 1 A schematic diagram of a flow chart of a security verification method in an API request process provided by an embodiment of the present invention;

[0027] Figure 2 A structural diagram of a security verification system in an API request process provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0028] The technical solution of the present invention is described below in conjunction with the accompanying drawings.

[0029] In the embodiments of the present invention, words such as "exemplarily" and "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "example" in the present invention should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of the word "example" is intended to present the concept in a specific way. In addition, in the embodiments of the present invention, the meaning expressed by "and / or" can be both, or it can be either of the two.

[0030] In the embodiments of the present invention, "image" and "picture" can sometimes be used interchangeably. It should be noted that when the difference between them is not emphasized, the meanings they intend to express are the same. "of", "corresponding, relevant" and "corresponding" can sometimes be used interchangeably. It should be noted that when the difference between them is not emphasized, the meanings they intend to express are the same.

[0031] In the embodiments of the present invention, sometimes a subscript such as W1 may be mistakenly written as a non-subscript such as W1. When the difference is not emphasized, the meanings to be expressed are consistent.

[0032] In order to make the technical problems, technical solutions and advantages to be solved by the present invention more clear, a detailed description will be given below with reference to the accompanying drawings and specific embodiments.

[0033] Reference Manual Attached Figure 1 , shows a flow chart of a security verification method in an API request process provided by an embodiment of the present invention.

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

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

[0036] Among them, the API (Application Programming Interface) call instruction is a request sent by the client to the server, requiring the server to provide a certain service or perform a certain operation. API call is a way of interaction between software, through which the client can access the functions or data on the server side. HTTP (Hypertext Transfer Protocol) request is a standard way of communication between the client and the server, which uses HTTP (Hypertext Transfer Protocol) to transmit data. In the API call, the HTTP request is the carrier for actually transmitting the API call instruction, which includes the request method (such as GET, POST, etc.), the path of the target resource, and the transmitted data. GET and POST are two common request methods in the HTTP protocol. They are used by the client (such as the browser) to send requests to the server to perform different types of operations.

[0037] It should be noted that receiving and processing API call instructions and HTTP requests issued by the browser ensures smooth communication between the client and the server, ensures that the request data reaches the server accurately, supports the subsequent data processing and response of the system, and improves the interaction efficiency and system flexibility. At the same time, the received requests provide a basic guarantee for subsequent security verification and business processing.

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

[0039] Among them, the server public key is a public encryption key used in asymmetric encryption. It is paired with the server's private key and is mainly used to encrypt data. The public key is public and can be used by any client to encrypt data, but only the private key held by the server can decrypt the data. Common asymmetric encryption algorithms include RSA and ECDSA. A symmetric key is an encryption key used in symmetric encryption. It is used to encrypt and decrypt data. The same key is used for encryption and decryption. Therefore, symmetric encryption is more efficient, but both parties must share this key securely. Common symmetric encryption algorithms include AES and DES.

[0040] It should be noted that by generating a server public key and a symmetric key related to the HTTP request, the security of data transmission between the client and the server is ensured. At the same time, asymmetric encryption and symmetric encryption are combined to improve encryption efficiency and ensure that sensitive information is not leaked, thereby ensuring the confidentiality and integrity of the data.

[0041] S3: In combination with a random number encryption algorithm, a digital envelope is generated according to a symmetric key and a server private key corresponding to a server public key, wherein the digital envelope includes a first digital signature, wherein the first digital signature includes a digital summary related to the HTTP request.

[0042] Among them, the random number encryption algorithm is an algorithm that uses a random number (or Nonce) as part of the input to encrypt data. The random number is used to ensure that the result of each encryption is different, even if the encrypted data is the same, which increases the security of encryption and prevents replay attacks or pre-calculation attacks. Digital envelope is a technology that combines symmetric encryption and asymmetric encryption to ensure the secure transmission of data. The data is encrypted by symmetric encryption, and the symmetric key used for decryption is encrypted by the public key of the recipient. The recipient uses the private key to decrypt the symmetric key and then decrypts the data. The first digital signature is an encrypted signature generated by the server using the private key for the data. It can verify the source and integrity of the data. Only the corresponding public key can verify the signature to ensure that the data has not been tampered with and the source is legitimate. The digital summary is the unique "fingerprint" of a piece of data. It maps data of any length into a short summary of fixed length through the hash algorithm. It can ensure the integrity of the data. If any change occurs to the data, the summary will also change.

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

[0044] In actual use, the specific method of obtaining the digital summary is that the browser requests the server to obtain a digital envelope. When the server receives the request, it generates a random string A related to the session, calculates the digital summary MD of A, encrypts MD with the server's private key, obtains the digital signature SD, encrypts SD with the AES algorithm and key SK, obtains the digital envelope DE, and returns it to the browser. After receiving the digital envelope DE, the browser uses the AES algorithm and key SK to decrypt it to obtain the digital signature SD, uses the server's public key to decrypt the digital signature SD, obtains the digital summary MD, and encrypts it and stores it in local storage.

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

[0046] S301: Generate a random string for HTTP request through 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 of each request is unique and to avoid replay attacks or pre-calculation attacks. The introduction of the random string makes the signature and encryption results generated each time different, even if the request content is the same.

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

[0049] S303: Encrypt the digital summary using the server private key to obtain a first digital signature.

[0050] S304: Encrypt the first digital signature using a symmetric key through a symmetric encryption algorithm to obtain a digital envelope.

[0051] Specifically, a random string is first generated through a random number encryption algorithm, and then a digital summary of the random string is generated, and the digital summary is encrypted using the server's private key to obtain a first digital signature. Next, the first digital signature is encrypted using a symmetric key through a symmetric encryption algorithm to generate a digital envelope. The entire process ensures the uniqueness and security of data by introducing a random string and a double encryption mechanism, prevents replay attacks and data tampering, and improves the confidentiality and integrity of communications.

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

[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 safely decrypt and obtain the digital summary to verify the legitimacy and accuracy of the data, prevent the data from being tampered with or stolen during transmission, and ensure secure communication between the client and the server.

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

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

[0056] S402: Decrypt the first digital signature using the server public key to obtain a digital summary.

[0057] Specifically, the digital envelope is first decrypted using a symmetric key through a symmetric encryption algorithm to obtain the first digital signature. Then, the digital signature is decrypted using the server's public key to obtain the original digital summary. The entire process uses a double encryption and decryption mechanism to ensure the secure transmission of data 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 of the data and the authenticity of the source are guaranteed, effectively resisting replay attacks and tampering.

[0058] S5: Generate browser information.

[0059] Among them, browser information includes random numbers, browser timestamps, browser tokens, and browser fingerprints.

[0060] Specifically, a random number R and the current timestamp TS are generated on the browser side, and a token T is generated through a custom symmetric encryption algorithm. The fingerprint P of the current browsing is obtained through the self-developed browser-side framework. A unique and dynamic token can be generated by combining the random number and the timestamp, effectively preventing replay attacks. At the same time, the symmetric encryption algorithm has a high encryption and decryption efficiency and is suitable for processing a large number of requests. On this basis, the fingerprint information is obtained through the self-developed browser framework, which further improves the uniqueness and security of the token and ensures the confidentiality and integrity of data transmission.

[0061] S6: Generate a second digital signature of the HTTP request by combining the digital summary, browser information, request information and request method.

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

[0063] It should be noted that by combining the digital summary, browser information, request information and request method, a custom signature algorithm is used to generate a second digital signature to ensure the integrity and uniqueness of the request and effectively prevent replay attacks and data tampering. This process verifies the legitimacy of the request, improves the security of the request, and ensures secure communication between the front and back ends. By signing the request parameters and verifying them on the server side, the present invention can effectively prevent attackers from tampering with the request content. The use of signatures ensures the integrity and consistency of the data, so that any illegal modification of the request parameters can be promptly identified and rejected.

[0064] In actual use, the specific method of generating the second digital signature is that when the browser initiates an API call, a random number R and the current timestamp TS are generated on the browser side, and a token T is generated through a custom symmetric encryption algorithm. The fingerprint P of the current browsing is obtained through the self-developed browser-side framework. The signature SG of the HTTP request is generated through the custom signature algorithm AR1 using token T + fingerprint P + locally stored digital summary MD + request information (request parameters and request body) + request method (GET or POST). The specific process of generating the signature SG is as follows: Extract token T. Extract the fingerprint P of the browser. Extract the digital summary MD. Extract the parameters in the URL, sort them in lexicographic order, and swap the last two items (the general practice of this step is to terminate after the parameters are sorted in lexicographic order. The purpose of swapping the last two items is to simply form a front-end and back-end agreed algorithm to increase the difficulty of forging parameters). Extract the request Body parameters, sort them in lexicographic order, and start swapping the two items (for the parameters in the Body, the general practice is not to process them. The sorting and swapping operations here are intended to simply form a front-end and back-end agreed algorithm to increase the difficulty of forging parameters). If the corresponding parameter is not obtained, the line break "\n" is used as a placeholder. Get the request method, i.e. GET, POST, PUT, DELETE, OPTIONS, etc. Connect all the strings obtained in the above steps into a signature string S through the line break "\n". Calculate the second digital signature through the custom signature algorithm AR1(S) and add it to the original HTTP request header.

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

[0066] Among them, the request parameter is also called URL, which is additional information sent to the server through the URL. The request body is also called Body, which contains the actual data content transmitted in the HTTP request, and is commonly seen in POST, PUT and other requests, such as submitting form data, JSON data, etc. 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: When request information is obtained, the request parameters and request body in the request information are sorted in lexicographic order respectively; otherwise, the process proceeds to step S604.

[0069] Lexicographic order refers to sorting strings in alphabetical order, similar to how words are arranged in a dictionary.

[0070] S602: swap the positions of the last two items in the sorted request parameters, and output the obtained swapped request parameters as a character string.

[0071] S603: Swap the positions of the first item and the second item in the sorted request body, and output the obtained swapped request body as a string.

[0072] S604: Use the line break as a placeholder for the request parameter and the request body, and output the placeholder as a string.

[0073] Among them, placeholders are characters or symbols used to replace actual values ​​when data is missing.

[0074] S605: Connect the obtained character strings using line breaks to obtain a signature string.

[0075] The signature string is a string of data that is obtained by integrating all request information (such as request parameters, request body, etc.) and concatenating them according to certain rules, and serves as the basic data for generating a digital signature.

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

[0077] Specifically, the parameters and request body in the request information are first sorted in lexicographical order, and then the last two items of the request parameters are swapped, and the first and second items of the request body are swapped. If the request information is missing, a line break is used as a placeholder. Next, all processed strings are concatenated into a signature string using a line break, and finally the signature string is encrypted using a custom signature algorithm to generate a second digital signature. This processing method ensures the uniqueness and tamper-proof capability of the signature by standardizing the order and swapping the request information, avoiding signature inconsistencies caused by different data sequences, and also improves the security of the system in preventing replay attacks.

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

[0079] The request header is a part of the HTTP request that contains metadata about the request. It transmits information that is not related to the request itself but is required by the server, such as the type of request, content format, authorization information, etc. This information helps the server to correctly understand and process the request. By sending the browser information and the second digital signature to the server as the request header of the HTTP request, the security and uniqueness of the request are increased. The server can verify the legitimacy of the request through this information, ensure that the source of the request is credible and has not been tampered with, and prevent malicious attackers from forging requests or replaying previous requests, thereby improving the security of the entire system and the reliability of communications.

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

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

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

[0083] Among them, the identity authentication system is a key mechanism to ensure that the system or service is accessed only by legally verified users. It ensures the authenticity of the user's identity through a variety of verification methods, prevents unauthorized access, and enhances the security of the system.

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

[0085] Among them, the 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 user name and password, digital certificate, two-factor verification, etc.) in order to grant them the corresponding access rights.

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

[0087] Specifically, the second digital signature transmitted by the browser is obtained, and the token T+fingerprint P+digital summary MD+request information+request method string is decrypted through the custom signature algorithm AR2(SG). If the decryption fails, it means that SG is illegal, logs are recorded, error information 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 a possible implementation manner, S704 specifically includes:

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

[0091] S7042: Determine whether the random number has been used in the server's cache. If not, 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 so, output the browser token verification passed. Otherwise, return the verification error information to the browser.

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

[0094] It should be noted that those skilled in the art can set the size of the preset time difference according to actual needs, and the present invention is not limited here.

[0095] It should be noted that the browser token is decrypted through a custom symmetric encryption algorithm to obtain a random number and a timestamp. Then check whether the random number has been used in the server cache. If not, store it and continue. Otherwise, return an error message. Finally, verify whether the time difference between the timestamp and the current time is within the allowable range. The entire process ensures the uniqueness of the request and prevents replay attacks. At the same time, timestamp verification increases the timeliness constraints on the request and enhances the security of the system.

[0096] For example, after obtaining the token T, the "random number R and timestamp TS" is decrypted through a custom symmetric encryption algorithm to determine whether the random number R appears in the cache (mainly recording the random number R in the previous request). If it appears, it means that the random number R has been reused, which is a replay attack. The log is recorded, an error message is returned, and the processing ends. If it has not appeared, it means that the random number R has not been reused, and it is stored in the cache for subsequent judgment. Determine whether the current time-timestamp TS is less than 15 minutes (this value can be adjusted in real time according to the actual system operation situation). If the difference is greater than 15 minutes, it means that the request takes too long from the browser to the server and there is a risk of tampering. The log is recorded, an error message is returned, and the processing ends. If the difference is less than 15 minutes, this step is verified and the next step of verification is performed.

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

[0098] In a possible implementation manner, S705 specifically includes:

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

[0100] Among them, SessionID is a unique identifier assigned by the server to each user session (Session), which is used to maintain the user's session state between multiple requests.

[0101] S7052: The corresponding relationship is stored in the cache and the output browser fingerprint verification is 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 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 passed.

[0104] Specifically, first check whether there is a corresponding relationship between the browser fingerprint and the SessionID in the server cache. If not, store the relationship in the cache and pass the verification. If it exists, obtain and compare the SessionID sent by the browser and the SessionID in the cache. If the two SessionIDs are the same, return a verification error message, otherwise the verification passes. This process ensures that the request comes from a legitimate session environment, prevents Session hijacking and forged requests, and improves the security of user sessions and the protection capabilities of the system.

[0105] For example, after obtaining the browser fingerprint P, determine whether the fingerprint P appears in the cache (mainly recording the correspondence between the browser fingerprint and SessionID of the previous request). If it has not appeared, it means that the browser is calling the server for the first time, and the correspondence between the fingerprint P and SessionID is recorded in the cache. This step is verified to be successful, and the next step of verification is performed. If the fingerprint P has appeared in the cache, and then the SessionID of the current request is obtained, the SessionID corresponding to the fingerprint P in the cache is compared. The two SessionIDs are different, indicating that the same browser has logged into the same system twice. In this scenario, there is a suspicion of "using the same browser to forge multiple SessionIDs or copying SessionIDs from other places". The log is recorded, an error message is returned, and the processing ends. If the SessionID of the current request is the same as the SessionID in the cache, this step is verified to be successful, and the next step of verification is performed.

[0106] S706: Verify the digital summary obtained by decryption. If the verification passes, proceed to step S707; otherwise, proceed to step S709.

[0107] In a possible implementation manner, S706 specifically includes:

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

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

[0110] S7063: Determine whether the digital summary is consistent with the digital summary to be verified. If they are consistent, output the digital summary verification pass. Otherwise, return the verification error information to the browser.

[0111] It should be noted that the random string to be verified is extracted from the digital summary, and then the digital summary to be verified is recalculated based on the random string. Then the original digital summary is compared with the recalculated summary to see if they are consistent. If they are consistent, the verification is successful, 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 security and anti-attack capabilities of the system.

[0112] For example, get the digital summary MD in the request, get the server random string A from the session, calculate the digital summary MD2 of A, and determine whether MD and MD2 are consistent. If they are inconsistent, it means that the digital summary MD on the browser side has been tampered with, record the log, return an error message, and end the process. If they are consistent, this step is verified and the next step is verified.

[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 a possible implementation manner, S707 specifically includes:

[0115] S7071: Based on the request method, determine whether the browser has the authority to access the request parameters through the server's authority management system. If it has the authority, obtain the request parameters and enter step S7072. Otherwise, return the verification error information to the browser.

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

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

[0118] S7074: The output request information and request method pass verification.

[0119] Specifically, the server's permission management system determines whether the browser has permission to access the request parameters. If it has permission, it checks whether the request parameters conform to the sorting format after the exchange, and then performs the same check on the request body. If both the request parameters and the request body meet the requirements, the check is finally passed. This process ensures that the request and data are correctly verified and sorted, prevents malicious tampering, ensures the legitimacy of the request and the integrity of the data, and effectively enhances the security of the system.

[0120] For example, after obtaining the requested URL, the permission management system is called to determine whether the current user has permission to access the URL. If not, the log is recorded, an error message is returned, and the processing ends. If permission is granted, the URL parameters are obtained to determine whether the parameters are sorted according to the rule of "sorting in lexicographic order, and swapping the positions of the last two items". The request Body is obtained to determine whether it is sorted according to the rule of "sorting in lexicographic order, and swapping the positions of the first two items". If any of the sorting rules are not met, the log is recorded, an error message is returned, and the processing ends. If all sorting rules are met, business logic processing is performed and the results of the business processing are returned to the browser.

[0121] S708: Output HTTP request verification passed.

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

[0123] Specifically, the browser information and the second digital signature are first sent to the server through the HTTPS protocol, and the server verifies the legitimacy of the request through the identity authentication system. The second digital signature is then decrypted using a custom signature algorithm, and the browser token, browser fingerprint, digital summary, 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 performed. If any step of the verification fails, an error message is returned to the browser. The entire process uses a multiple verification mechanism to ensure the authenticity of the request source, the integrity of the data, and the security of the communication, effectively preventing forged requests and replay attacks.

[0124] S8: If the HTTP request verification passes, the business processing flow is performed on the HTTP request; otherwise, the business processing flow is terminated.

[0125] The business processing flow refers to a series of business-related operations performed by the server after receiving and verifying the request from the client. Step S8 ensures that only legitimate requests that have passed verification can trigger the business processing flow on the server side, preventing malicious requests or requests for tampering with data from affecting the normal operation of the system. By terminating business processing when verification fails, the security and stability of the system are effectively improved, the accuracy of data processing is ensured, and security risks are reduced.

[0126] In actual use, the communication between the browser and the server during the entire data transmission process uses the HTTPS protocol, which can ensure data confidentiality, data integrity, and effective identity authentication to prevent man-in-the-middle attacks during data transmission. By receiving API call instructions and HTTP requests, public keys and symmetric keys are generated, and digital envelopes are generated and transmitted to the browser in combination with random number encryption. After decryption, the browser generates and sends a request with a digital signature to the server. The server then performs a series of checks, including verification tokens, fingerprints, digital summaries, request information, and request methods, to ensure the legitimacy and integrity of the request. If the verification is passed, the server executes the business processing flow, and terminates the processing if the verification fails. This process ensures the security of the request through a multi-level encryption and verification mechanism, prevents data tampering, replay attacks, and illegal requests, and greatly improves the security and stability of the system.

[0127] The present invention uses a variety of security mechanisms to form a multi-level, all-round protection system. This design can not only effectively resist a single type of replay attack, but also maintain a strong defense capability when facing complex and changeable attack methods. By combining technologies such as browser fingerprints, dynamic keys and timestamps, the present invention can accurately identify and verify the authenticity and timeliness of requests. This greatly reduces the possibility of misjudgment, ensures the smooth passage of normal requests, and effectively intercepts malicious replay requests. The custom signature algorithm and interface authorization mechanism of the present invention enhance the robustness of the system. Even if an attacker attempts to attack by intercepting keys or tampering with request parameters, it is difficult to bypass the multiple lines of defense set by the present invention. The present invention can detect and defend against a variety of attack behaviors including copying cookies, intercepting key attacks, freshness attacks, staleness attacks, middleman tampering attacks, and interface unauthorized attacks. This greatly improves the overall security of the system. The design of the present invention allows flexible adjustment of security policies and parameter settings according to actual needs. At the same time, its modular architecture is also convenient for future functional expansion and upgrading according to technological development or new security threats. By effectively preventing replay attacks, the present invention helps to protect the privacy and data security of users, thereby enhancing the user's trust in the system. This not only improves the user experience, but also helps maintain the company's reputation and customer relationships. The comprehensive defense strategy of the present invention reduces system failures and security incidents caused by replay attacks. This reduces the company's maintenance costs and potential economic losses.

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

[0129] In the present invention, by combining the random number, timestamp, browser fingerprint and digital summary information generated by the browser, as well as the server public key generated by the server and the symmetric key related to the HTTP request, a unique customized double digital signature is generated to ensure the uniqueness and security of each HTTP request. By using encryption and signature, the performance bottleneck problem caused by clock drift and sequence number space exhaustion of traditional anti-replay attack technology is avoided. It has better adaptability when processing a large number of concurrent requests and can encrypt concurrent requests for a long time, thereby ensuring that the data transmission process can effectively detect and defend against various replay attack behaviors, effectively reducing the occurrence of vulnerabilities, thereby greatly reducing the security risks of data transmission.

[0130] Reference Manual Attached Figure 2 , showing a structural schematic diagram of a security verification system in an API request process provided by the present invention.

[0131] The present invention also provides a security verification system 20 in an API request process, which is applied to the security verification method in the above-mentioned API request process, including:

[0132] Processor 201.

[0133] The memory 202 stores computer-readable instructions. When the computer-readable instructions are executed by the processor 201, the security verification method in the API request process of the method embodiment is implemented.

[0134] The security verification system 20 in the API request process provided by the present invention can execute the security verification method in the API request process mentioned above and achieve the same or similar technical effects. To avoid repetition, the present invention will not go into details.

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

[0136] In the present invention, by combining the random number, timestamp, browser fingerprint and digital summary information generated by the browser, the server public key generated by the server and the symmetric key related to the HTTP request, a unique customized double digital signature is generated to ensure the uniqueness and security of each HTTP request. By using encryption and signature, the performance bottleneck problem caused by clock drift and sequence number space exhaustion of traditional anti-replay attack technology is avoided. It has better adaptability when processing a large number of concurrent requests and can encrypt concurrent requests for a long time, thereby ensuring that the data transmission process can effectively detect and defend against various replay attack behaviors, effectively reducing the occurrence of vulnerabilities, thereby greatly reducing the security risks of data transmission.

[0137] It should be understood that the processor in the embodiment of the present invention may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0138] It should also be understood that the memory in the embodiments of the present invention may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link 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. When implemented by software, the above embodiments can be implemented in whole or in part in the form of 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, the process or function described in the embodiment of the present invention is generated in whole or in part. 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 computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state hard disk.

[0140] It should be understood that the term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship, but it may also indicate an "and / or" relationship. Please refer to the context for specific understanding.

[0141] In the present 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 refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can be represented by: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0142] It should be understood that in various embodiments of the present invention, the size of the serial numbers of the above-mentioned processes does not mean 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 appreciate that the units and algorithm steps of each example 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 performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0144] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described equipment, devices and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0145] In the several embodiments provided by the present invention, it should be understood that the disclosed devices, apparatuses and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0146] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

[0148] If the functions are implemented in the form of 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 can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0149] An embodiment of the present invention provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the security verification method in the API request process as described in the method embodiment is implemented.

[0150] A computer-readable storage medium provided by the present invention can implement the steps and effects of the security verification method in the API request process of the above method embodiment. To avoid repetition, the present invention will not go into details.

[0151] The beneficial effects brought about by the technical solution provided by the embodiment of the present invention include at least:

[0152] In the present invention, by combining the random number, timestamp, browser fingerprint and digital summary information generated by the browser, the server public key generated by the server and the symmetric key related to the HTTP request, a unique customized double digital signature is generated to ensure the uniqueness and security of each HTTP request. By using encryption and signature, the performance bottleneck problem caused by clock drift and sequence number space exhaustion of traditional anti-replay attack technology is avoided. It has better adaptability when processing a large number of concurrent requests and can encrypt concurrent requests for a long time, thereby ensuring that the data transmission process can effectively detect and defend against various replay attack behaviors, effectively reducing the occurrence of vulnerabilities, thereby greatly reducing the security risks of data transmission.

[0153] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

[0154] There are a few points to note:

[0155] (1) The drawings of the embodiments of the present invention only relate to the structures related to the embodiments of the present invention, and other structures may refer to the general design.

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

[0157] (3) In the absence of conflict, the embodiments of the present invention and the features therein may be combined with each other to obtain new embodiments.

[0158] The above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. The protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A security verification method in an API request process, characterized in that: include: S1: Receives API call instructions and HTTP requests from the browser; S2: Generate a server public key and a symmetric key associated with the HTTP request; S3: combining a random number encryption algorithm and generating a digital envelope according to the 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 summary related to the HTTP request; S4: sending the symmetric key, the server public key and the digital envelope to the browser, and decrypting them to obtain the digital summary; S5: Generate browser information, wherein the browser information includes a random number, a browser timestamp, a browser token, and a browser fingerprint; S6: Generate a second digital signature of the HTTP request by combining the digital summary, the browser information, the request information and the request method; S7: Send the browser information and the second digital signature as an HTTP request with a request header to a server for verification; S8: If the HTTP request verification passes, perform a business processing flow on the HTTP request; otherwise, terminate the business processing flow.

2. The security verification method in the API request process according to claim 1 is characterized in that: The S3 specifically includes: S301: Generate a random string for the HTTP request through a random number encryption algorithm; S302: Generate a digital summary of the random string; S303: Encrypt the digital summary using the server private key to obtain the first digital signature; S304: Encrypt the first digital signature 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 is characterized in that: The S4 specifically includes: S401: Decrypt the digital envelope using the symmetric key through the symmetric encryption algorithm to obtain the first digital signature; S402: Decrypt the first digital signature using the server public key to obtain the digital summary.

4. The security verification method in the API request process according to claim 1 is characterized in that: The request information includes request parameters and a request body, and the request method includes a GET request method, a POST request method, a PUT request method, a DELETE request method, and an OPTIONS request method; The S6 specifically includes: S601: When the request information is obtained, the request parameters and the request body in the request information are sorted in lexicographic order respectively; otherwise, the process proceeds to step S604; S602: swap the positions of the last two items in the sorted request parameters, and output the obtained swapped request parameters as a character string; S603: swap the positions of the first item and the second item in the sorted request body, and output the obtained swapped request body as a string; S604: Use line breaks as placeholders for the request parameters and the request body, and output the placeholders as a character string; S605: Connect the obtained character strings using the line break to obtain a signature string; S606: Calculate the signature string to obtain the second digital signature.

5. According to the security verification method in the API request process of claim 1, it is characterized in that: The S7 specifically includes: S701: Sending the browser information and the HTTP request with the second digital signature to the server through the HTTPS protocol; S702: Verify the legitimacy of the HTTP request through the identity authentication system of the server. 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 browser token obtained by decryption. If the verification passes, proceed to step S705; otherwise, proceed to step S709; S705: Verify the browser fingerprint obtained by decryption. If the verification passes, proceed to step S706; otherwise, proceed to step S709; S706: Verify the digital summary obtained by decryption. If the verification passes, proceed to step S707; otherwise, proceed to step S709; S707: Verify the decrypted request information and the request method. If the verification passes, proceed to step S708; otherwise, proceed to step S709; S708: Outputting the HTTP request verification is successful; S709: Return the verification error information to the browser.

6. The security verification method in the API request process according to claim 5 is characterized in that: The S704 specifically 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 cache of the server. If not, 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 the preset time difference. If so, output the browser token verification passed. Otherwise, return the verification error information to the browser.

7. The security verification method in the API request process according to claim 5 is characterized in that: The S705 specifically includes: S7051: Determine whether there is a corresponding relationship between the browser fingerprint and the SessionID in the cache of the server. If not, proceed to step S7052; otherwise, proceed to step S7053; S7052: storing the corresponding relationship in the cache, and outputting that the browser fingerprint verification is passed; 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 passed.

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

9. The security verification method in the API request process according to claim 5 is characterized in that: The S707 specifically includes: S7071: According to the request method, determine whether the browser has the authority to access the request parameters through the authority management system of the server. If so, obtain the request parameters and proceed to step S7072. Otherwise, return verification error information to the browser. S7072: Determine whether the request parameters conform to the ordering format of the exchanged request parameters. If so, 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 ordering format of the exchanged request body. If so, proceed to step S7074; otherwise, return verification error information to the browser. S7074: Output the request information and the request method to pass verification.

10. A security verification system in an API request process, characterized in that: include: processor; A memory having computer-readable instructions stored thereon, wherein when the computer-readable instructions are executed by the processor, the security verification method in the API request process as described in any one of claims 1 to 9 is implemented.

Images