CN119728159A

CN119728159A - A security verification method and system in API request process

Info

Publication number: CN119728159A
Application number: CN202411637413.0A
Authority: CN
Inventors: 耿守忠; 李凯; 徐卫东; 赵甜甜; 张庆群; 赵海涛; 赵洪超; 孙小祎; 狄超超; 柏明昌
Original assignee: Luban Beijing Electronic Commerce Technology Co ltd
Current assignee: Luban Beijing Electronic Commerce Technology Co ltd
Priority date: 2024-11-15
Filing date: 2024-11-15
Publication date: 2025-03-28

Abstract

The present invention provides a security verification method and system in an API request process, which relates to the technical field of network security. The method comprises: 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 the browser, decrypting to obtain a digital summary; generating browser information; combining the digital summary, browser information, request information and request method to generate a second digital signature of the HTTP request; sending the browser information and the second digital signature as the HTTP request of the request header to the server for verification; if the HTTP request verification passes, performing a business processing flow on the HTTP request, otherwise, terminating the business processing flow. The efficiency and effectiveness of anti-replay attack are improved.

Description

Security verification method and system in API request process

Technical Field

The invention relates to the technical field of network security, in particular to a security verification method and system in an API request process.

Background

With the rapid development of information technology, network security problems are increasingly prominent, and particularly in the fields of identity authentication, data transmission and the like, replay attack prevention is an important branch in the field of network security, and research and application of replay attack prevention are receiving extensive attention. Replay attacks refer to an attacker capturing legitimate communication packets and retransmitting these packets at a later point in time to fool the system or gain illegal benefit. This attack form poses a serious threat to many security protocols and systems. In recent years, with the popularization and penetration of network applications, research on replay attack prevention techniques is also in progress. From the initial simple timestamp mechanism to the later sequence number mechanism, challenge-response mechanism, etc., various replay attack schemes are endless. These approaches, while improving system security, present new technical challenges and needs.

Security verification in the API request process is very necessary, because it can effectively prevent a malicious attacker from performing unauthorized operations by repeatedly sending legal requests, so as to avoid security problems such as user data disclosure, funds loss, identity theft, etc., ensure system security, transaction integrity, and trust of users, and at the same time, such a verification mechanism helps to prevent abuse attacks, such as denial of service attacks (DoS).

However, with the rapid development of network applications, the data volume and the concurrent request quantity to be processed by the system are continuously increased, and the existing replay attack prevention technology is limited by the constraints of clock drift, sequence number space exhaustion and the like, so that the replay attack prevention technology has performance bottlenecks when processing a large number of concurrent requests, encryption loopholes can gradually appear along with the time extension, and the data transmission risk is greatly increased.

Disclosure of Invention

In order to solve the technical problems that the data volume and concurrent request quantity which need to be processed by a system are continuously increased along with the rapid development of network application in the prior art, the existing replay attack prevention technology is limited by the constraints of clock drift, serial number space exhaustion and the like, so that performance bottlenecks exist in the replay attack prevention technology when a large number of concurrent requests are processed, encryption loopholes can gradually appear along with the time extension, and the data transmission risk is greatly increased, the invention provides a security verification method and a security verification system in the API request process.

The technical scheme provided by the embodiment of the invention is as follows:

first aspect

The security verification method in the API request process provided by the embodiment of the invention comprises the following steps:

s1, receiving an API call instruction and an HTTP request sent by a browser;

S2, generating a server public key and a symmetric key related to 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 comprises a first digital signature, and the first digital signature comprises a digital abstract related to the HTTP request;

S4, sending the symmetric key, the server public key and the digital envelope to a browser, and decrypting to obtain a digital abstract;

s5, generating browser information, wherein the browser information comprises a random number, a browser time stamp, a browser token and a browser fingerprint;

s6, combining the digital abstract, browser information, request information and a request method to generate a second digital signature of the HTTP request;

S7, sending the browser information and the second digital signature to a server as HTTP requests of request headers for verification;

and S8, carrying out a service processing flow on the HTTP request under the condition that the HTTP request passes verification, and otherwise, terminating the service processing flow.

Second aspect

The security verification system in the API request process provided by the embodiment of the invention comprises the following components:

A processor;

A memory having stored thereon computer readable instructions which, when executed by the processor, implement the method of security validation in the course of an API request as described in the first aspect.

Third aspect of the invention

An embodiment of the present invention provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements a security verification method in an API request procedure as described in the first aspect.

The technical scheme provided by the embodiment of the invention has the beneficial effects that at least:

According to the invention, through combining the random number generated by the browser, the timestamp, the browser fingerprint, the digital abstract and other information, the server public key generated by the server and the symmetric key related to the HTTP request, the unique self-defined dual digital signature is generated, so that the uniqueness and the safety of each HTTP request are ensured, the performance bottleneck problem caused by clock drift and sequence number space exhaustion in the traditional replay attack prevention technology is avoided by using encryption and signature, the method has better adaptability when a large number of concurrent requests are processed, the concurrent requests can be encrypted for a long time, the data transmission process is further ensured to effectively detect and defend various replay attack behaviors, the occurrence of vulnerabilities is effectively reduced, and the safety risk of the data transmission is greatly reduced.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic flow chart of a security verification method in an API request process according to an embodiment of the present invention;

fig. 2 is a schematic structural diagram of a security verification system in an API request process according to an embodiment of the present invention.

Detailed Description

The technical scheme of the invention is described below with reference to the accompanying drawings.

In embodiments of the invention, words such as "exemplary," "such as" and the like are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the term use of an example is intended to present concepts in a concrete fashion. Furthermore, in embodiments of the present invention, the meaning of "and/or" may be that of both, or may be that of either, optionally one of both.

In the embodiments of the present invention, "image" and "picture" may be sometimes used in combination, and it should be noted that the meaning of the expression is consistent when the distinction is not emphasized. "of", "corresponding (corresponding, relevant)" and "corresponding (corresponding)" are sometimes used in combination, and it should be noted that the meaning of the expression is consistent when the distinction is not emphasized.

In embodiments of the present invention, sometimes a subscript such as W ₁ may be wrongly written in a non-subscript form such as W1, and the meaning of the expression is consistent when the distinction is not emphasized.

In order to make the technical problems, technical solutions and advantages to be solved more apparent, the following detailed description will be given with reference to the accompanying drawings and specific embodiments.

Referring to fig. 1 of the specification, a flow chart of a security verification method in an API request process according to an embodiment of the present invention is shown.

The embodiment of the invention provides a safety verification method in the API request process, which can be realized by safety verification equipment in the API request process, wherein the safety verification equipment in the API request process can be a terminal or a server. The process flow of the security verification method in the API request process may include the following steps:

S1, receiving an API call instruction and an HTTP request sent by a browser.

The API (Application Programming Interface ) call instruction is a request sent by the client to the server, which requires the server to provide a certain service or perform a certain operation, and the API call is an interaction mode between software, through which the client can access functions or data of the server. HTTP (Hypertext Transfer Protocol ) requests are a standard way of communication between a client and a server, which uses HTTP (hypertext transfer protocol) to transfer data. In API calls, HTTP requests are the carrier for the actual transfer of API call instructions, which include the manner of the request (e.g., GET, POST, etc.), the path of the target resource, and the transferred data, etc. GET and POST are two common request methods in the HTTP protocol that are used by clients (e.g., browsers) to send requests to servers to perform different types of operations.

It should be noted that, the API call instruction and the HTTP request sent by the browser are received and processed, so that smooth communication between the client and the server is ensured, the request data accurately arrives at the server, the subsequent data processing and response of the system are supported, and the interaction efficiency and the flexibility of the system are improved. Meanwhile, the received request provides basic guarantee for subsequent security verification and service processing.

And S2, generating a server public key and a symmetric key related to the HTTP request.

Wherein the server public key is a public encryption key used in asymmetric encryption. It is paired with the private key of the server and is mainly used for encrypting 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 are RSA and ECDSA. The symmetric key is an encryption key used in symmetric encryption, and is used for encrypting data and decrypting data, and the same key is used for encryption and decryption, so that the symmetric encryption efficiency is higher, but two parties must safely share the key, and common symmetric encryption algorithms are AES and DES.

By generating the server public key and the symmetric key related to the HTTP request, the data transmission safety between the client and the server is ensured, meanwhile, the encryption efficiency is improved, sensitive information is prevented from being leaked by combining asymmetric encryption and symmetric encryption, and the confidentiality and the integrity of data are ensured.

And 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 comprises a first digital signature, and the first digital signature comprises a digital digest related to the HTTP request.

The random number encryption algorithm is an algorithm for encrypting data by using a random number (or Nonce) as a part of input, and the random number is used for ensuring that the result of each encryption is different, so that even if the encrypted data are the same, the encryption security is improved, and replay attack or pre-calculation attack is prevented. Digital envelopes are a technique combining symmetric encryption and asymmetric encryption to ensure secure transmission of data, the data is encrypted by symmetric encryption, and a symmetric key for decryption is encrypted by a public key of a receiver, and the receiver decrypts the symmetric key using a private key and then decrypts the data. The first digital signature is an encrypted signature generated by the server on the data using the private key, which can verify the source and integrity of the data, and only the corresponding public key can verify the signature, ensuring that the data is not tampered with and the source is legitimate. The digital digest is a unique "fingerprint" of a piece of data, and maps the data of any length into a short digest of a fixed length by a hash algorithm, which can ensure the integrity of the data, and if any changes occur to the data, the digest will also change.

Specifically, by combining random number encryption, symmetric encryption and asymmetric encryption, a safe digital envelope and a digital signature are generated, so that the integrity and confidentiality in the data transmission process are ensured, and meanwhile, whether the data are tampered or not is verified through the digital abstract, so that the safety of communication is greatly improved, and attacks and counterfeiting requests are prevented.

In the actual use process, a specific acquisition mode of the digital abstract is that a browser requests a server side to acquire a digital envelope, after the server side receives a request, a random string A related to the session is generated, the digital abstract MD of the A is calculated, the MD is encrypted by a private key of the server side to obtain a digital signature SD, the SD is encrypted by an AES algorithm and a secret key SK to obtain a digital envelope DE, and the digital envelope DE is returned to the browser side. After receiving the digital envelope DE, the browser decrypts the digital envelope DE by using an AES algorithm and a key SK to obtain a digital signature SD, decrypts the digital signature SD by using a public key of a server to obtain a digital abstract MD, and encrypts and stores the digital abstract MD in a local storage.

In one possible embodiment, S3 specifically includes:

S301 generates a random string for the HTTP request by a random number encryption algorithm.

Wherein the random string is an unpredictable random number generated by the system for enhanced security. It is typically generated by a pseudo-random number generator to ensure that the data for each request is unique, avoiding replay or pre-computation attacks, and the introduction of a random string causes the signature and encryption result for each generation to be different, even if the request content is the same.

S302, generating a digital digest of the random string.

And S303, encrypting the digital digest by using the server private key to obtain a first digital signature.

S304, encrypting the first digital signature by using a symmetric key through a symmetric encryption algorithm to obtain the digital envelope.

Specifically, a random string is first generated by a random number encryption algorithm, then a digital digest of the random string is generated, and the digital digest is encrypted using a private key of a server to obtain a first digital signature. Next, the first digital signature is encrypted with a symmetric key by a symmetric encryption algorithm to generate a digital envelope. The whole flow ensures the uniqueness and the security of the data by introducing a random string and a double encryption mechanism, prevents replay attack and data tampering, and improves the confidentiality and the integrity of communication.

And S4, sending the symmetric key, the server public key and the digital envelope to a browser, and decrypting to obtain the digital abstract.

It should be noted that, by sending the symmetric key, the server public key and the digital envelope to the browser and decrypting at the browser end, the security and the integrity of data transmission can be ensured, and the browser can decrypt and acquire the digital abstract safely, so as to verify the validity and the accuracy of the data, prevent the data from being tampered or stolen in the transmission process, and ensure the secure communication between the client and the server.

In one possible embodiment, S4 specifically includes:

S401, decrypting the digital envelope by using the symmetric key through a symmetric encryption algorithm to obtain a first digital signature.

And S402, decrypting the first digital signature by using the server public key to obtain a digital digest.

Specifically, firstly, a symmetric encryption algorithm is used for decrypting the digital envelope by using a symmetric key to obtain a first digital signature. Then, the digital signature is decrypted by using the public key of the server, and the original digital digest is obtained. The whole process ensures the safe transmission of data through a double encryption and decryption mechanism, avoids the theft or tampering of sensitive information in the transmission process, ensures the integrity and the source authenticity of the data by using the private key encryption of a server and the public key decryption of a client, and effectively resists replay attack and tampering.

S5, generating browser information.

Wherein the browser information includes a random number, a browser timestamp, a browser token, and a browser fingerprint.

Specifically, a random number R and a current time stamp TS are generated at a browser end, a token T is generated through a self-defined symmetric encryption algorithm, a currently browsed fingerprint P is obtained through a self-developed browser end frame, and a unique and dynamic token can be generated by combining the random number and the time stamp, so that replay attack is effectively prevented. Meanwhile, the symmetric encryption algorithm has higher encryption and decryption efficiency, is suitable for processing a large number of requests, and on the basis, the uniqueness and the security of the token are further improved by acquiring fingerprint information from the research browser frame, and the confidentiality and the integrity of data transmission are ensured.

And S6, combining the digital abstract, the browser information, the request information and the request method to generate a second digital signature of the HTTP request.

The request information refers to parameters, request bodies and other contents in the HTTP request, and may include query parameters, form data, JSON objects and other data actually sent. The method of request in HTTP, such as GET, POST, PUT, indicates the specific manner of operation of the request. The signature algorithm is used for generating a digital signature according to the information, ensuring the authenticity and the integrity of the data and ensuring that the signature is not counterfeitable.

By combining the digital abstract, browser information, request information and request method, a custom signature algorithm is used for generating a second digital signature, so that the integrity and uniqueness of the request are ensured, replay attack and data tampering are effectively prevented, the legality of the request is verified, the safety of the request is improved, and the safety communication between front and rear ends is ensured. By signing the request parameters and verifying the request parameters at the server side, the invention can effectively prevent an attacker from tampering with the request content, and the use of the signature ensures the integrity and consistency of the data, so that any illegal modification of the request parameters can be timely identified and refused.

In the actual use process, when the specific generation mode of the second digital signature is that the browser initiates an API call, a random number R and a current time stamp TS are generated at the browser end, and a token T is generated through a self-defined symmetric encryption algorithm. And acquiring the currently browsed fingerprint P through the self-developed browser end frame. The token T+fingerprint P+locally stored digital digest MD+request information (request parameters and request body) +request method (GET or POST), and the signature SG of the HTTP request is generated through a custom signature algorithm AR 1. The specific flow of generating signature SG is as follows, extracting token T. The fingerprint P to the browser is extracted. And extracting the digital abstract MD. Extracting parameters in the URL, sorting according to dictionary sequence, and then switching the last two items of positions (the general method of the step is that the parameters are terminated after sorting according to dictionary sequence, and the purpose of the last two items of positions is to simply form a front-back end contract algorithm, so that the difficulty of forging parameters is increased). Extracting request Body parameters, ordering according to dictionary sequence, and starting two exchange positions (for parameters in Body, general practice is not to process, ordering and position exchange operations are performed here, so that front-end and back-end contract algorithm is simply formed, and difficulty of forging parameters is increased). If no corresponding parameter is obtained, a linefeed "\n" is used as a placeholder. The acquisition request method, GET, POST, PUT, DELETE, OPTIONS, etc. All the character strings obtained in the steps are connected into a signature string S through a line feed symbol "\n". The second digital signature is calculated by the custom signature algorithm AR1 (S) and added to the original HTTP request header.

In one possible implementation, the request information includes a request parameter 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 request parameter is also called URL, the request parameter is additional information sent to the server through URL, the request Body is also called Body, the request Body contains actual data content transmitted in HTTP request, and is commonly found in POST, PUT and other requests, such as submitting form data, JSON data and the like. The request body is located in the body portion of the request and is not displayed in the URL.

S6 specifically comprises the following steps:

and S601, under the condition that the request information is acquired, sequencing request parameters and request bodies in the request information according to dictionary sequences respectively, and otherwise, entering step S604.

Where dictionary order refers to ordering strings in alphabetical order, similar to how words are arranged in a dictionary.

S602, carrying out position exchange on the last two items in the ordered request parameters, and outputting the obtained exchanged request parameters as character strings.

S603, performing position exchange on the first item and the second item in the ordered request body, and outputting the obtained exchanged request body as a character string.

S604, using the line feed as a request parameter and a placeholder of a request body, and outputting the placeholder as a character string.

Wherein a placeholder is a character or symbol that is used to replace an actual value when data is missing.

And S605, connecting the obtained character strings by using the line connector to obtain a signature string.

The signature string is a character string formed by integrating all request information (such as request parameters, request bodies and the like) and splicing the request information into a character string according to a certain rule, and the character string is used as basic data for generating a digital signature.

S606, calculating the signature string to obtain a second digital signature.

Specifically, firstly, the parameters in the request information and the request body are ordered according to dictionary sequence, then, the last two items of the request parameters are subjected to position exchange, and the first item and the second item of the request body are subjected to position exchange. If the request information is missing, a linefeed is used as a placeholder. Then, all the processed character strings are connected into a signature string by using a line feed, and finally the signature string is encrypted by a custom signature algorithm to generate a second digital signature, wherein the processing mode is that the request information is subjected to standardized ordering and position exchange, the uniqueness and tamper resistance of the signature are ensured, signature inconsistency caused by different data sequences is avoided, and meanwhile, the security of the system in preventing replay attack is improved.

And S7, sending the browser information and the second digital signature to a server as HTTP requests of request headers for verification.

Wherein the request header is part of the HTTP request and contains metadata about the request that conveys information not related to the request itself but required by the server, such as the type of request, content format, authorization information, etc., which aids the server in properly understanding and processing 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 is increased. The server can verify the validity of the request through the information, so that the source of the request is reliable and is not tampered, and a malicious attacker is prevented from forging the request or replaying the previous request, thereby improving the safety of the whole system and the reliability of communication.

In the actual use process, the verification process is that after the server intercepts the request through the interceptor, the validity of the current request is verified through the identity authentication system of the system. After verification, the second digital signature is decrypted, and after decryption, the token T, the fingerprint P, the digital digest MD, the request information and the request method are subjected to validity verification in sequence. And after the verification is successful, carrying out service logic processing, if any verification fails, directly recording a log, returning error information to the browser, and ending the processing.

In one possible implementation, S7 specifically includes:

And S701, transmitting the browser information and the HTTP request with the second digital signature to a server through HTTPS protocol.

The identity authentication system is a key mechanism for ensuring that the system or service is only accessed by a user after legal verification, and ensures the authenticity of the user identity through various verification modes, prevents unauthorized access and enhances the security of the system.

S702, carrying out validity verification on the HTTP request through an identity authentication system of the server, if the verification is passed, entering a step S703, otherwise, entering a step S709.

The identity authentication system is a technical system for verifying the identity of a user, a device or a system, and ensures that an access requester is legal and authorized, and the identity authentication system confirms the true identity of the requester by collecting and verifying the provided credentials (such as a user name and a password, a digital certificate, two-factor verification and the like) so as to grant corresponding access rights.

S703, decrypting the second digital signature through a custom signature algorithm, if the decryption is successful, entering step S704, otherwise, entering step S709.

Specifically, a second digital signature transmitted from the browser side is obtained, and the token t+fingerprint p+digital abstract md+request information+character string of the request method is decrypted through a custom signature algorithm AR2 (SG). If the decryption fails, the SG is illegal, the log is recorded, error information is returned, and the processing is finished.

And S704, checking the decrypted browser token, if the browser token passes the check, proceeding to step S705, otherwise, proceeding to step S709.

In one possible implementation, S704 specifically includes:

and S7041, decrypting the browser token to obtain the random number and the browser time stamp.

S7042, judging whether the random number is used in the cache of the server, if not, storing the random number in the cache, and proceeding to step S7043, otherwise, returning a verification error message to the browser.

S7043, judging whether the time difference between the browser time stamp and the current time is smaller than a preset time difference, if yes, outputting the browser token to pass the verification, otherwise, returning the verification error information to the browser.

Alternatively, the preset time difference may be specifically 15 minutes.

It should be noted that, the size of the preset time difference can be set by a person skilled in the art according to actual needs, and the present invention is not limited herein.

It should be noted that, the browser token is decrypted by the custom symmetric encryption algorithm to obtain the random number and the timestamp. It is then checked whether the random number has been used in the server cache and if not, it is stored and continued. Otherwise, an error message is returned. Finally, verifying whether the time difference between the time stamp and the current time is within an allowable range or not ensures the uniqueness of the request in the whole flow, prevents replay attack, increases timeliness constraint on the request through time stamp verification, and enhances the security of the system.

For example, after the token T is obtained, the "random number R and the timestamp TS" are obtained by decrypting with the custom symmetric encryption algorithm, and it is determined whether the random number R is present in the cache (mainly recording the random number R in the previous request), if so, it is indicated that the random number R is reused, which is a replay attack, logs, returns an error message, and ends the process. If not, it is indicated that the random number R is not reused, and it is stored in the cache for later judgment. Judging whether the current time-timestamp TS is smaller than 15 minutes (the value can be adjusted in time according to the actual system running condition), if the difference is larger than 15 minutes, indicating that the time from the browser to the server is too long, the risk of tampering exists, recording a log, returning error information, and ending the processing. If the difference is less than 15 minutes, the step passes the verification, and the next verification is performed.

S705, checking the decrypted browser fingerprint, if the browser fingerprint passes the checking, proceeding to step S706, otherwise proceeding to step S709.

In one possible implementation, S705 specifically includes:

S7051, judging whether the corresponding relation exists between the browser fingerprint and the SessionID in the cache of the server, if not, proceeding to step S7052, otherwise, proceeding to step S7053.

Where SessionID is a unique identifier assigned by the server for each user Session (Session) that is used to maintain the Session state of the user among multiple requests.

And S7052, storing the corresponding relation in a cache, and outputting the browser fingerprint verification pass.

S7053, acquiring a first sessionID of the browser fingerprint request and a second sessionID corresponding to the browser fingerprint in the cache.

S7054, judging whether the first SessionID and the second SessionID are the same, if so, returning verification error information to the browser, otherwise, outputting the fingerprint verification of the browser to pass.

Specifically, it is first checked whether there is a correspondence between the browser fingerprint and the SessionID in the server cache, and if not, the correspondence is stored in the cache and checked. If so, acquiring and comparing the SessionID sent by the browser with the SessionID in the cache. If the two sessionIDs are the same, a verification error message is returned, otherwise, the verification is passed. The process ensures that the request comes from legal Session environment, prevents Session hijacking and falsifying the request, and improves the security of user Session and the protection capability of the system.

For example, after the browser fingerprint P is obtained, it is determined whether the fingerprint P appears in the cache (mainly records the correspondence between the previously requested browser fingerprint and the SessionID), if not, it is indicated that the browser is the first call server, the correspondence between the fingerprint P and the SessionID is recorded in the cache, and the step of verification is passed, and the next step of verification is performed. If the fingerprint P appears in the cache, acquiring the SessionID of the current request, comparing the SessionIDs corresponding to the fingerprint P in the cache, indicating that the same browser logs in the same system twice, recording logs, returning error information and ending the processing under the present scene, wherein the suspicion that a plurality of SessionIDs are forged by the same browser or the SessionIDs are copied from other places is existed. And if the current requested SessionID is the same as the SessionID in the cache, the step of verification is passed, and the next step of verification is performed.

S706, checking the digital abstract obtained by decryption, if the digital abstract passes the checking, proceeding to step S707, otherwise proceeding to step S709.

In one possible implementation, S706 specifically includes:

s7061, obtaining a random string to be verified, which is carried in the digital abstract.

S7062, calculating a digital digest to be verified of the random string to be verified.

S7063, judging whether the digital abstract is consistent with the digital abstract to be verified, if so, outputting the digital abstract to pass verification, otherwise, returning verification error information to the browser.

It should be noted that, the random string to be verified is extracted from the digital digest, and then the digital digest to be verified is recalculated according to the random string. And comparing whether the original digital abstract is consistent with the recalculated abstract, if so, verifying to pass, otherwise, returning error information to the browser. The process ensures the integrity and the authenticity of the data, prevents the data from being tampered or forged in the transmission process, and improves the security and the anti-attack capability of the system.

For example, a digital digest MD in the request is obtained, a random string a of the server is obtained from the session, a digital digest MD2 of a is calculated, whether MD and MD2 are consistent or not is judged, the digital digest MD on the browser side is tampered, a log is recorded, an error message is returned, and the process is ended. And the two are consistent, the verification in the step is passed, and the next verification is carried out.

S707, checking the request information and the request method obtained by decryption, if the check is passed, proceeding to step S708, otherwise proceeding to step S709.

In one possible implementation, S707 specifically includes:

S7071, judging whether the browser has the authority to access the request parameters or not through the authority management system of the server according to the request method, if so, acquiring the request parameters, and entering step S7072, otherwise, returning verification error information to the browser.

S7072, judging whether the request parameters accord with the ordered form of the exchanged request parameters, if so, entering into a step S7073, otherwise, returning a verification error message to the browser.

S7073, acquiring a request body, judging whether the request body accords with the ordering form of the exchanged request body, if so, entering step S7074, otherwise, returning verification error information to the browser.

S7074, outputting the request information and the request method passes the verification.

Specifically, the authority management system of the server judges whether the browser has authority to access the request parameters, if so, the request parameters are checked to be in accordance with the exchanged ordering form, and then the same check is carried out on the request body. And if the request parameters and the request body meet the requirements, finally checking. The process ensures that the requests and the data are correctly verified and sequenced, prevents malicious tampering, ensures the validity of the requests and the integrity of the data, and effectively enhances the security of the system.

For example, the URL of the request is obtained, the rights management system is called to determine whether the current user has rights to access the URL, if not, the log is recorded, an error message is returned, and the process is ended. If the authority is available, URL parameters are obtained, and whether the parameters are ordered according to the rules of the dictionary sequence and the last two exchange positions are ordered is judged. The request Body is acquired, and whether the request Body is ordered according to the rule of 'ordering according to dictionary sequence and then starting two exchange positions'. If any ordering rule is not met, recording a log, returning error information and ending the processing. And if the service logic processing rules are met, carrying out service logic processing and returning a service processing result to the browser.

S708, outputting HTTP request authentication pass.

And S709, returning the verification error information to the browser.

Specifically, the browser information and the second digital signature are firstly sent to the server through an HTTPS protocol, and the server verifies the validity of the request through an identity authentication system. And then decrypting the second digital signature by using a custom signature algorithm, and checking the browser token, the browser fingerprint, the digital digest, the request information and the request method one by one. If all the checks pass, the validity of the request is confirmed and the subsequent business processing is executed. If any one of the verifications fails, an error message is returned to the browser. The whole flow ensures the authenticity of the request source, the integrity of data and the safety of communication through a multiple verification mechanism, and effectively prevents counterfeit requests and replay attacks.

Wherein, the service processing flow refers to a series of operations related to the service, which are executed by the server after receiving and verifying the request passing through the client. Step S8 ensures that only legal requests passing verification can trigger the service processing flow of the server side, prevents malicious requests or requests for tampering data from affecting the normal operation of the system, effectively improves the safety and stability of the system by stopping service processing when verification fails, ensures the accuracy of data processing and reduces the safety risk.

In the actual use process, the HTTPS protocol is adopted for communication between the browser and the server in the whole data transmission process, so that the effects of ensuring data confidentiality and data integrity in the data transmission process, effectively carrying out authentication, surrounding, preventing man-in-the-middle attack and the like can be ensured. And generating a public key and a symmetric key by receiving an API call instruction and an HTTP request, generating a digital envelope by combining random number encryption, transmitting the digital envelope to a browser, and generating and transmitting a request with a digital signature to a server after the browser decrypts the digital envelope. The server then performs a series of checks including verification tokens, fingerprints, digital digests, request information, and request methods to ensure the validity and integrity of the request. And under the condition of passing the verification, the server executes the business processing flow, and if the verification fails, the processing is terminated. The process ensures the safety of the request through a multi-level encryption and verification mechanism, prevents data tampering, replay attack and illegal request, and greatly improves the safety and stability of the system.

The invention comprehensively utilizes a plurality of safety mechanisms and forms a multi-layer and all-directional protection system. The design not only can effectively resist single-type replay attacks, but also can maintain strong defensive capability when facing complex and changeable attack means. By combining the technologies of browser fingerprints, dynamic keys, time stamps and the like, the method and the device can accurately identify and verify the authenticity and timeliness of the request. The method greatly reduces the possibility of misjudgment, ensures smooth passing of normal requests, and effectively intercepts malicious replay requests. The custom signature algorithm and the interface authorization mechanism of the invention enhance the robustness of the system. Even if an attacker tries to attack by intercepting a secret key or tampering with a request parameter, the multiple defense lines set by the invention are difficult to bypass. The invention can detect and defend various attack behaviors including copy Cookie, interception key attack, freshness attack, staleness attack, man-in-the-middle tamper attack and interface override attack. This greatly improves the overall security of the system. The design of the invention allows flexible adjustment of security policies and parameter settings according to actual requirements. Meanwhile, the modularized architecture is convenient for function expansion and upgrading according to technical development or new security threat in the future. By effectively preventing replay attacks, the invention is helpful for protecting the privacy and data security of the user, thereby enhancing the trust feeling of the user on the system. This not only enhances the user experience, but also helps maintain the reputation and customer relationship of the enterprise. The comprehensive defense strategy of the present invention reduces system failures and security events caused by replay attacks. This reduces maintenance costs and potential economic losses for the enterprise.

The technical scheme provided by the implementation of the invention has the beneficial effects that at least the following steps are included:

According to the invention, through combining the random number generated by the browser, the timestamp, the browser fingerprint, the digital abstract and other information, the server public key generated by the server and the symmetric key related to the HTTP request, the unique self-defined dual digital signature is generated, so that the uniqueness and the safety of each HTTP request are ensured, the performance bottleneck problem caused by clock drift and sequence number space exhaustion in the traditional replay attack prevention technology is avoided by using encryption and signature, the method has better adaptability when a large number of concurrent requests are processed, the concurrent requests can be encrypted for a long time, the data transmission process is further ensured to effectively detect and defend various replay attack behaviors, the occurrence of loopholes is effectively reduced, and the safety risk of the data transmission is greatly reduced.

Referring to fig. 2 of the specification, a schematic structural diagram of a security verification system in an API request process according to the present invention is shown.

The invention also provides a security verification system 20 in the process of API request, which is applied to the security verification method in the process of API request, and comprises the following steps:

a processor 201.

Memory 202, having stored thereon computer readable instructions which, when executed by processor 201, implement a security verification method in the course of an API request as in a method embodiment.

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, and achieve the same or similar technical effects, and in order to avoid repetition, the present invention is not repeated.

It should be appreciated that the processor in embodiments of the invention may be a central processing unit (central processing unit, CPU), which may also be other general purpose processors, digital signal processors (DIGITAL SIGNAL processors, DSPs), application Specific Integrated Circuits (ASICs), off-the-shelf programmable gate arrays (field programmable GATE ARRAY, FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

It should also be appreciated that the memory in embodiments of the present invention may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an erasable programmable ROM (erasable PROM), an electrically erasable programmable EPROM (EEPROM), or a flash memory. The volatile memory may be random access memory (random access memory, RAM) which acts as external cache memory. By way of example, and not limitation, many forms of random access memory (random access memory, RAM) are available, such as static random access memory (STATIC RAM, SRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic Random Access Memory (SDRAM), double data rate synchronous dynamic random access memory (doubledata RATE SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (ENHANCED SDRAM, ESDRAM), synchronous link dynamic random access memory (SYNCHLINK DRAM, SLDRAM), and direct memory bus random access memory (direct rambus RAM, DR RAM).

The above embodiments may be implemented in whole or in part by software, hardware (e.g., circuitry), firmware, or any other combination. When implemented in software, the above-described embodiments may be implemented in whole or in part in the form of a computer program product. The computer program product comprises one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, the processes or functions described in accordance with embodiments of the present invention are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may 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 may be transmitted from one website site, computer, server, or data center to another website site, computer, server, or data center by wired (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains one or more sets of available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium may be a solid state disk.

It should be understood that the term "and/or" is merely an association relationship describing the associated object, and means that three relationships may exist, for example, a and/or B, and may mean that a exists alone, while a and B exist alone, and B exists alone, wherein a and B may be singular or plural. In addition, the character "/" herein generally indicates that the associated object is an "or" relationship, but may also indicate an "and/or" relationship, and may be understood by referring to the context.

In the present invention, "at least one" means one or more, and "a plurality" means two or more. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (a, b, or c) of a, b, c, a-b, a-c, b-c, or a-b-c may be represented, wherein a, b, c may be single or plural.

It should be understood that, in various embodiments of the present invention, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

It will be clearly understood by those skilled in the art that, for convenience and brevity of description, specific working procedures of the apparatus, device and unit described above may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.

In the several embodiments provided by the present invention, it should be understood that the disclosed apparatus, device and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another device, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of 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.

In addition, each functional unit in the embodiments of the present invention may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present invention. The storage medium includes a U disk, a removable hard disk, a read-only memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, an optical disk, or other various media capable of storing program codes.

An embodiment of the present invention provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements a method of security verification in an API request procedure as described in the method embodiment.

The computer readable storage medium provided by the invention can realize the steps and effects of the security verification method in the API request process of the method embodiment, and in order to avoid repetition, the invention is not repeated.

The foregoing is merely illustrative of the present invention, and the present invention is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

The following points need to be described:

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

(2) In the drawings for describing embodiments of the present invention, the thickness of layers or regions is exaggerated or reduced for clarity, i.e., the drawings are not drawn to actual scale. It will be understood that when an element such as a layer, film, region or substrate is referred to as being "on" or "under" another element, it can be "directly on" or "under" the other element or intervening elements may be present.

(3) The embodiments of the invention and the features of the embodiments can be combined with each other to give new embodiments without conflict.

The present invention is not limited to the above embodiments, but the scope of the invention is defined by the claims.

Claims

1. A security verification method in an API request process, characterized by comprising:

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, characterized in that 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, characterized in that 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 success;

S709: Return the verification error information to the browser.

6. The security verification method in the API request process according to claim 5, characterized in that the step S704 specifically comprises:

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, characterized in that the step S705 specifically comprises:

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, characterized in that the step S706 specifically comprises:

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, characterized in that the step S707 specifically comprises:

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 by comprising:

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.