An application program interface security protection method and system

Abstract

The application discloses an application program interface security protection method and system, and relates to the technical field of electronic communication, which comprises the following steps: obtaining user login data sent by a client through a single sign-on interface; sequentially performing first login verification and application key verification on the user login data to determine the user login state and corresponding login information; obtaining business request data sent by the client through a business interface; sequentially performing second login verification, login interface verification, interface verification based on the business token and signature verification on the business request data to obtain to-be-executed business data; sequentially performing decoding and RSA decryption on the to-be-executed business data to obtain to-be-executed actual business; determining business calling data according to the to-be-executed actual business; and sending the business calling data to the client after sequentially performing RSA encryption and encoding. The application program interface security protection method and system realize more comprehensive and higher degree of security protection on the application program interface.

Description

Technical Field

[0001] This invention relates to the field of electronic communication technology, and in particular to a method and system for protecting application programming interfaces (APIs) based on the RSA algorithm. Background Technology

[0002] With the development of the Internet, distributed systems, and cloud computing technologies, and to adapt to the trend of information technology development in modern society, the original integrated websites based on dynamic web page design technology are gradually evolving towards front-end and back-end separation and back-end microservices. This has led to a growing demand for the use of application programming interfaces (APIs) to transmit critical information, thus increasing the requirements for API security protection. Existing API security protection technologies include the following:

[0003] (1) The original login verification technology using session objects relies on the session objects of dynamic web servers to store user data information and perform authentication through user data information. It cannot adapt to the current application interfaces that provide services in a cluster. It can only guarantee access verification between multiple clients and one server. Moreover, user authentication information is stored in the session objects, which is susceptible to being intercepted by Trojan programs. It has now been basically phased out.

[0004] (2) Application Interface Security (API) using Application Keys: This method verifies API calls by generating a unique application ID and application key. When a client makes a request, it needs to add the application ID and a digest string containing the request body and application key. The server uses the application ID to find the application key and performs a digest operation with the request body for verification. This method directly transmits the application ID in the request header, which easily exposes the application ID and makes it easy to forge requests and gain unauthorized access by intercepting the application ID, as well as tamper with requests and return values. Currently, this technology is the security protection method for the vast majority of API calls.

[0005] (3) Application security protection technology using single sign-on and encryption algorithms. This method is based on the application interface security protection technology using application keys, and adds single sign-on, uses timestamps to prevent multiple logins, uses random strings to increase the difficulty of guessing the encryption method, uses tokens to reduce the possibility of application ID exposure, and uses encryption algorithms to prevent unauthorized viewing of the return body by intercepting network requests. It has avoided most of the disadvantages of (2), but it does not restrict the client's access IP, does not verify the request, and the request body may be tampered with. It does not restrict the client's access permissions and frequency, and the client is prone to unauthorized access. In the event of a denial-of-service attack, the attack on a single interface may cause excessive resource consumption and drag down the entire service. At present, most application interfaces involving critical data can solve security protection problems using this method, but as the sensitivity of data transmitted through application interfaces increases, new protection methods are needed to solve application interface security problems. Summary of the Invention

[0006] The purpose of this invention is to provide a method and system for protecting application programming interfaces (APIs) security, thereby achieving more comprehensive and higher-level security protection for APIs.

[0007] To achieve the above objectives, the present invention provides the following solution:

[0008] A method for protecting application programming interface (API) security includes:

[0009] Retrieve user login data sent by the client through the single sign-on interface;

[0010] The user login data is sequentially subjected to a first login verification and an application key verification to determine the user login status and the corresponding login information; the user login status includes allowed login and denied login; when the user login status is allowed login, the corresponding login information is a business token;

[0011] Retrieve business request data sent by the client through the business interface;

[0012] The business request data is sequentially subjected to second login verification, login interface verification, interface verification code verification based on the business token, and signature verification to obtain the business data to be executed;

[0013] The data to be executed is sequentially decoded and RSA decrypted to obtain the actual business to be executed;

[0014] Determine the service call data based on the actual service to be executed;

[0015] The service call data is sequentially encrypted and encoded using RSA before being sent to the client.

[0016] Optionally, the user login data includes login IP, verification string, RSA encryption application number, login timestamp, and random string;

[0017] The user login data is sequentially subjected to a first login verification and an application key verification to determine the user's login status and corresponding login information, specifically including:

[0018] The login IP is matched and verified based on a first preset login IP whitelist to obtain a first verification result; the first verification result includes verification qualified and verification unqualified.

[0019] When the first test result is unqualified, the user's login status will be determined as login denied.

[0020] When the first verification result is qualified, the RSA encrypted application number is decrypted using the server's RSA private key to determine the application number;

[0021] The application ID is matched against a preset database to determine a preset application key;

[0022] The preset application key, the random string, and the login timestamp are encrypted using MD5 to obtain the encrypted string;

[0023] When the encrypted string does not match the verification string, the user's login status will be determined as login denied.

[0024] When the encrypted string matches the verification string, the user's login status is determined to be allowed to log in, and a UUID string is randomly generated; the UUID string is a business token.

[0025] Optionally, the business request data includes login IP, business request interface address, number of business request interface calls within a preset time period, verification string, login timestamp, random string, preset signature data, and business request body;

[0026] The second login verification of the business request data specifically includes:

[0027] The login IP is matched and verified based on a second preset login IP whitelist to obtain a second verification result; the second verification result includes verification passed and verification failed.

[0028] When the second inspection result is unqualified, a service request rejection instruction is generated;

[0029] When the second inspection result is qualified, the login interface is verified on the business request data;

[0030] The login interface verifies the business request data, specifically including:

[0031] Determine whether the address of the business request interface is consistent with the address of the interface allowed for client calls in the relational database, and whether the number of business request interface calls within the preset time period is lower than a preset number of times;

[0032] If the address of the business request interface is inconsistent with the address of the interface allowed for client calls in the relational database, or if the number of business request interface calls within the preset time period is not less than the preset number of calls, a business request rejection instruction will be generated.

[0033] If the business request interface address is consistent with the address of the interface allowed for client calls in the relational database, and the number of business request interface calls within the preset time period is lower than the preset number of calls, then the business request data will be verified using an interface verification code based on the business token.

[0034] The business request data is verified using an interface verification code based on the business token, specifically including:

[0035] Determine the corresponding preset application key based on the business token;

[0036] The preset application key corresponding to the business token, the random string, and the login timestamp are concatenated and then encrypted using MD5 to obtain the first encrypted string corresponding to the business token.

[0037] When the first encrypted string corresponding to the service token is inconsistent with the verification string, a service request rejection instruction is generated;

[0038] When the first encrypted string corresponding to the business token matches the verification string, the business request data is signed and verified.

[0039] The signature verification of the business request data specifically includes:

[0040] The preset application key corresponding to the service token and the service request body are concatenated and then encrypted using MD5 to obtain the second encrypted string corresponding to the service token;

[0041] When the second encrypted string corresponding to the business token is inconsistent with the preset signature data, a business request rejection instruction is generated;

[0042] When the second encrypted string corresponding to the business token matches the preset signature data, the business request body is marked as business data to be executed.

[0043] Optionally, the data to be executed is sequentially decoded and RSA decrypted to obtain the actual service to be executed, specifically including:

[0044] The data to be executed is Base64 decoded;

[0045] The decoded business data to be executed is decrypted using the server's RSA private key to obtain the actual business to be executed.

[0046] To achieve the above objectives, the present invention also provides the following technical solutions:

[0047] An application programming interface (API) security protection system includes:

[0048] The login data acquisition module is used to acquire user login data sent by the client through the single sign-on interface;

[0049] The login verification module is used to sequentially perform a first login verification and an application key verification on the user login data to determine the user login status and the corresponding login information; the user login status includes allowed login and denied login; when the user login status is allowed login, the corresponding login information is a business token;

[0050] The business data acquisition module is used to acquire business request data sent by the client through the business interface;

[0051] The business verification module is used to sequentially perform second login verification, login interface verification, interface verification code verification based on the business token, and signature verification on the business request data to obtain the business data to be executed.

[0052] The business decoding and decryption module is used to decode and RSA decrypt the business data to be executed in sequence to obtain the actual business to be executed;

[0053] The business data retrieval module is used to determine the business retrieval data based on the actual business to be executed;

[0054] The business data return module is used to sequentially encrypt and encode the business call data using RSA before sending it to the client.

[0055] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects:

[0056] This invention discloses an application programming interface (API) security protection method and system. The method sequentially performs a first login verification and an application key verification on user login data sent by the client through a single sign-on interface to verify the client's identity, prevent replay attacks, prevent unauthorized access, reduce the possibility of denial-of-service attacks, and reduce the possibility of unauthorized access by others using previously intercepted request information or simulating client API calls by inferring the meaning of different parts of the request body. The method further performs a second login verification, a login interface verification, an interface verification code based on the business token, and a signature verification on business request data sent by the client through a business interface to prevent unauthorized viewing and tampering of client API requests and responses. Specifically, the second login verification prevents unauthorized access, the signature verification prevents tampering of request parameters, and the interface verification code based on the business token uses encryption to prevent the application ID from being exposed. Finally, the business data to be executed is sequentially decoded and RSA decrypted to obtain the actual business to be executed. Based on the actual business to be executed, the business call data is determined, and the business call data is sequentially RSA encrypted and encoded before being returned to the client, ensuring that the business call result is not viewed by attackers without authorization. This invention implements application programming interface security protection based on the RSA algorithm, increasing the scope of protection and improving the level of security. Attached Figure Description

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

[0058] Figure 1 This is a flowchart illustrating the application programming interface security protection method of the present invention;

[0059] Figure 2 This is a schematic diagram of the application programming interface security protection system of the present invention. Detailed Implementation

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

[0061] This invention provides a method and system for application programming interface (API) security protection, which realizes API security protection based on the RSA algorithm.

[0062] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0063] Example 1

[0064] This invention proposes a security protection method for application programming interfaces (APIs) based on the RSA algorithm. The server and client each generate their own public and private keys for an RSA key, storing them in a relational database and providing the public key to each other. The server generates only one private key; when the public key is needed, it generates a new public key from the private key and provides it to the client. The application ID and application key used by the client program to access the API should be requested from the service provider in advance.

[0065] If it is necessary to restrict the client's IP address, the client should send its IP address to the server before data interaction. If the server needs to restrict the interfaces that the client can call, the server should store the allowed client interface addresses in a relational database before data interaction. For business interfaces, the request body data format should be application / json, and the string encoding should be UTF-8. The request parameter table is shown in Table 1 below, and the return information is shown in Tables 2 and 3 below.

[0066] Table 1 Request Parameter Table

[0067]

[0068]

[0069] Table 2 Returns Information (Refer to Table 1)

[0070]

[0071] Table 3 Return Information Parameter Table 2

[0072]

[0073] like Figure 1 As shown, the application programming interface security protection method of the present invention includes:

[0074] Step 100: Obtain user login data sent by the client through the single sign-on interface; the user login data includes login IP, verification string, RSA encryption application number, login timestamp, and random string.

[0075] Within the client, a random string, a login timestamp (in milliseconds), and the client's corresponding application key are concatenated and then encrypted using MD5 to obtain a verification string. In one specific embodiment, the client's corresponding application key, the random string, and the login timestamp are concatenated sequentially using "|" to form a string, and the resulting string after MD5 digest operation is the verification value ("checkSum" field), thus obtaining the verification string. Then, the verification string, the application ID encrypted with the server's RSA public key (i.e., the RSA-encrypted application ID, represented by the "appIdSec" field), the login timestamp ("curTime" field), and the random string ("nonce" field) are sent as request header parameters to the server through the single sign-on interface.

[0076] Step 200: Perform a first login verification and an application key verification on the user login data in sequence to determine the user login status and the corresponding login information; the user login status includes allowed login and denied login; when the user login status is allowed login, the corresponding login information is a business token.

[0077] In step 200, the user login data undergoes a first login verification, i.e., whitelist blocking, which specifically includes:

[0078] 1) The login IP is matched and verified based on a first preset login IP whitelist to obtain a first verification result; the first verification result includes verification pass and verification fail. Specifically, the server checks whether the client's IP address is in the first preset login IP whitelist.

[0079] 2) If the first verification result is unsuccessful, the user's login status is determined as "login refused". Specifically, if the client's IP address is not in the whitelist, a failure message is returned to the client, i.e., login is refused.

[0080] 3) When the first inspection result is qualified, the user login data is subjected to the first login verification, that is, the login operation is allowed. The login interface generally does not perform permission management.

[0081] In step 200, a first login verification is performed on the user login data, specifically including:

[0082] 1) Use the server's RSA private key to decrypt the RSA encrypted application number to determine the application number.

[0083] 2) Match the application IDs against a preset database to determine a preset application key. Specifically, the preset application key is the application key pre-stored in the preset database corresponding to each client.

[0084] 3) Encrypt the preset application key, the random string, and the login timestamp using MD5 to obtain the encrypted string; specifically, perform MD5 hash string operation on the preset application key, the random string, and the login timestamp.

[0085] 4) When the encrypted string does not match the verification string, the user's login status is determined to be "login refused".

[0086] 5) When the encrypted string matches the verification string, the user's login status is determined to be allowed to log in, and a UUID (Universally Unique Identifier) ​​string is randomly generated; the UUID string is a business token, and the business token, client key and the first generation time of the business token are stored together in the memory database.

[0087] After step 200, the method of the present invention further includes:

[0088] 1) Obtain the first generation time of the business token.

[0089] 2) Calculate the difference between the first generation time and the login timestamp to obtain the login maintenance time.

[0090] 3) Determine whether the login duration is within the preset login validity period; in a practical application, the preset login validity period is 5 minutes.

[0091] 4) If the login maintenance time is within the preset login validity period, the service token is retained; if the login maintenance time is not within the preset login validity period, the service token is discarded, and the process returns to the step of obtaining user login data sent by the client through the single sign-on interface.

[0092] Specifically, a new business token is generated for each API call; tokens that have expired become invalid. Tokens are also invalidated for the same application ID, the same client, or repeated logins. A business token is required to access any API other than client login.

[0093] The purpose of setting up step 200 above is to prevent unauthorized access to the interface by verifying user identity. Unified authorization through the client-side single sign-on interface, using a temporarily specified UUID as a token, combined with a random string and login timestamp, can prevent attackers from directly intercepting requests received by the server and using them to request the server again—a "replay attack." Simultaneously, using an RSA-encrypted string instead of the normally transmitted application ID can protect the application ID from being obtained during network information transmission.

[0094] Step 300: Obtain the business request data sent by the client through the business interface; the business request data includes the login IP, the business request interface address, the number of times the business request interface is called within a preset time period, the verification string, the login timestamp, the random string, the preset signature data, and the business request body.

[0095] When a client requests a server interface other than the single sign-on interface (hereinafter referred to as a business interface), the server intercepts the request by using "controller enhancement" technology.

[0096] Within the client, the application key corresponding to the client, the login timestamp, and the random string are concatenated in order using "|", an MD5 hash is performed, and the resulting hash string is then sent to the server as a request header parameter along with the login timestamp ("curTime" field), the random string ("nonce" field), and the business token ("token" field).

[0097] The process of determining the preset signature data specifically includes: In the client, encrypting the business request body using the server's RSA public key; encoding the encrypted business request body using Base64 encoding (if the actual request body is empty, an empty string is used directly); concatenating the client's corresponding application key and the encoded business request body sequentially with "|" and then performing MD5 encryption to obtain the preset signature data. The encrypted request is sent to the server as the request body "str" ​​parameter, and the preset signature data is sent as the request header "sign" parameter.

[0098] Step 400: Perform second login verification, login interface verification, interface verification code verification based on the business token, and signature verification on the business request data in sequence to obtain the business data to be executed.

[0099] In step 400, a second login verification is performed on the business request data, that is, whitelist permission interception is performed again, specifically including:

[0100] 1) The login IP is matched and verified based on the second preset login IP whitelist to obtain a second verification result; the second verification result includes verification qualified and verification unqualified.

[0101] 2) When the second inspection result is unqualified, a service request rejection instruction is generated; when the second inspection result is qualified, the service request data is verified by the login interface.

[0102] Specifically, it checks whether the client's IP address is in the second preset login IP whitelist. If it is not in the second preset login IP whitelist, it returns a failure message to the client; if it is, it proceeds to the next step of login interface verification.

[0103] In step 400, the login interface is verified on the business request data, specifically including:

[0104] 1) Determine whether the address of the business request interface is consistent with the address of the interface allowed for client calls in the relational database, and whether the number of business request interface calls within the preset time period is lower than the preset number of calls.

[0105] 2) If the address of the business request interface is inconsistent with the address of the interface allowed for client calls in the relational database, or if the number of business request interface calls within the preset time period is not less than the preset number of calls, a business request rejection instruction will be generated and a failure message will be returned to the client.

[0106] 3) If the address of the business request interface is consistent with the address of the interface allowed to be called by the client in the relational database, and the number of times the business request interface is called within the preset time period is less than the preset number of times, then the business request data is verified by the interface verification code based on the business token.

[0107] The purpose of setting up a second login verification and login interface verification is to prevent users from accessing the system without authorization, narrow down the range of client IPs that may access the business system, and prevent denial-of-service or distributed denial-of-service attacks from consuming resources by sending a large number of requests to individual interfaces at the same time, causing the server to crash or other interfaces to be unable to provide normal services.

[0108] In step 400, the business request data is verified using an interface verification code based on the business token, specifically including:

[0109] 1) Determine the corresponding preset application key based on the business token.

[0110] 2) The preset application key corresponding to the service token, the random string, and the login timestamp are concatenated and then encrypted using MD5 to obtain the first encrypted string corresponding to the service token. Specifically, the preset application key, login timestamp, and random string corresponding to the service token are concatenated in sequence using "|", and an MD5 digest operation is performed to obtain the first encrypted string.

[0111] 3) When the first encrypted string corresponding to the service token is inconsistent with the verification string, a service request rejection instruction is generated and a failure message is returned; when the first encrypted string corresponding to the service token is consistent with the verification string, the service request data is signed and verified.

[0112] The verification of the business request data using an interface verification code based on the business token also includes:

[0113] 1) Obtain the second generation time of the preset application key corresponding to the business token.

[0114] 2) Calculate the difference between the second generation time and the login timestamp to obtain the requested maintenance time.

[0115] 3) Determine whether the duration of the request is within a preset valid request range. Preferably, the preset valid request range is within 1 minute.

[0116] 4) If the login duration is within the preset login validity period, the business request data is retained, and then the preset application key corresponding to the business token, the random string and the login timestamp are concatenated and encrypted using MD5.

[0117] Furthermore, if the random string corresponding to the business request data is the same as the random string of other requests within one minute, the business request data is invalid and discarded; if the random string corresponding to the business request data is different from the random string of other requests within one minute, the business request data is retained, and then the preset application key corresponding to the business token, the random string, and the login timestamp are concatenated and encrypted using MD5. Application interface access logs are stored in a relational database to record the validity or invalidity of the business request data.

[0118] 5) If the login maintenance time is not within the preset login validity period, discard the business request data and return to the step of obtaining the business request data sent by the client through the business interface.

[0119] The purpose of setting up interface verification code is to prevent attackers from inferring the application key by observing the digest string; the reason for using a business token instead of the application number is to prevent the application number from being leaked; the purpose of using the second generation time and random string of the preset application key corresponding to the business token is to increase the difficulty for attackers to crack the encryption method and to prevent replay attacks.

[0120] In step 400, the signature verification of the business request data is performed, specifically including:

[0121] 1) Concatenate the preset application key corresponding to the service token and the service request body, then perform MD5 encryption to obtain the second encrypted string corresponding to the service token. Specifically, connect the preset application key corresponding to the service token and the service request body with "|" and perform MD5 digest operation.

[0122] 2) When the second encrypted string corresponding to the service token is inconsistent with the preset signature data, a service request rejection instruction is generated and a failure message is returned; when the second encrypted string corresponding to the service token is consistent with the preset signature data, the service request body is marked as service data to be executed.

[0123] The purpose of setting up signature verification is to prevent attackers from viewing the content of business request bodies or tampering with it using "transparent proxy" technology.

[0124] Step 500: Decode and RSA decrypt the data to be executed in sequence to obtain the actual business to be executed.

[0125] Step 500 specifically includes: Base64 decoding the data to be executed; and decrypting the decoded data using the server's RSA private key to obtain the actual business data to be executed. Specifically, the server decodes the "str" ​​field of the request body using Base64, and then decrypts the decoded string using the server's RSA private key to obtain the actual request body.

[0126] Step 600: Determine the business call data based on the actual business to be executed; specifically, find the actual business controller class and method of the interface to be processed through the interface call address, and make the call normally. If the call fails, return a failure message; otherwise, return an unencrypted call result and convert it into a JSON string.

[0127] Step 700: After sequentially encrypting and encoding the business call data using RSA, it is sent to the client. Specifically, the normal execution result of this method is intercepted using "controller enhancement" technology. The returned JSON string is encrypted using the client's RSA public key and Base64 encoded, serving as the "str" ​​field in the return body, and then returned to the client.

[0128] The purpose of setting step 700 is to prevent attackers from viewing the results of API calls without authorization.

[0129] After the client receives the "str" ​​field in the return body, it decrypts the Base64 decoded result of the str field using the client's RSA private key to obtain the normal API call result, and the entire call process ends.

[0130] Example 2

[0131] like Figure 2 As shown, in order to implement the technical solution in Embodiment 1, this embodiment provides an application programming interface (API) security protection system, including:

[0132] The login data acquisition module 101 is used to acquire user login data sent by the client through the single sign-on interface;

[0133] The login verification module 201 is used to perform a first login verification and an application key verification on the user login data in sequence to determine the user login status and the corresponding login information; the user login status includes allowed login and denied login; when the user login status is allowed login, the corresponding login information is a business token.

[0134] The business data acquisition module 301 is used to acquire business request data sent by the client through the business interface.

[0135] The business verification module 401 is used to sequentially perform a second login verification, a login interface verification, an interface verification code verification based on the business token, and a signature verification on the business request data to obtain the business data to be executed.

[0136] The service decoding and decryption module 501 is used to decode and decrypt the service data to be executed in sequence to obtain the actual service to be executed.

[0137] The business data call module 601 is used to determine the business call data based on the actual business to be executed.

[0138] The business data return module 701 is used to sequentially encrypt and encode the business call data using RSA before sending it to the client.

[0139] Compared with the prior art, the present invention also has the following advantages:

[0140] (1) Prevent requests from being invoked by others without permission through previously intercepted request information, or from being simulated by inferring the meaning of each part of the request body.

[0141] Compared to existing application programming interface (API) technologies that do not require client-side single sign-on, this invention can verify the client's identity, and user authentication information is stored only on the server side, eliminating the possibility of it being intercepted by malware.

[0142] Compared to existing application interface security protection methods that directly use application IDs and application keys for authentication, and application interface security protection technologies that use single sign-on and encryption algorithms, this invention reduces the range of client IPs that may access the interface through whitelist permission interception technology. By using tokens instead of application IDs and using encrypted application IDs on business interfaces, the exposure of application IDs and the forgery of requests through intercepted application IDs can be completely avoided.

[0143] (2) Prevent attackers from intercepting requests and obtaining or tampering with the request and response bodies. Signature verification ensures that the request cannot be viewed by attackers or tampered with through "transparent proxy" technology; encryption of the response content ensures that the call result cannot be viewed by attackers without authorization.

[0144] (3) Prevent a large number of simultaneous requests to individual interfaces from consuming excessive resources and crippling the entire service. This is achieved through whitelist permission interception, which verifies the interface address of the request against the address that the client is allowed to call, preventing unauthorized access by users and controlling the number of client method calls within a certain time period to not exceed the allowed limit.

[0145] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0146] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for protecting application programming interface (API) security, characterized in that, The methods include: Retrieve user login data sent by the client through the single sign-on interface; The user login data is sequentially subjected to a first login verification and an application key verification to determine the user login status and the corresponding login information; the user login status includes allowed login and denied login; when the user login status is allowed login, the corresponding login information is a business token; the business token is a randomly generated UUID string; Retrieve business request data sent by the client through the business interface; The business request data is sequentially subjected to second login verification, login interface verification, interface verification code verification based on the business token, and signature verification to obtain the business data to be executed; Specifically, the process of verifying the business request data using an interface verification code based on the business token includes: determining a corresponding preset application key based on the business token; concatenating the preset application key, a random string, and a login timestamp corresponding to the business token, and then performing MD5 encryption to obtain a first encrypted string corresponding to the business token; generating a business request rejection instruction when the first encrypted string corresponding to the business token does not match the verification string; and performing signature verification on the business request data when the first encrypted string corresponding to the business token matches the verification string. The signature verification of the business request data specifically includes: concatenating the preset application key corresponding to the business token and the business request body, and then performing MD5 encryption to obtain a second encrypted string corresponding to the business token; when the second encrypted string corresponding to the business token is inconsistent with the preset signature data, a business request rejection instruction is generated; when the second encrypted string corresponding to the business token is consistent with the preset signature data, the business request body is marked as business data to be executed. The data to be executed is sequentially decoded and RSA decrypted to obtain the actual data to be executed; specifically, this includes: Base64 decoding the data to be executed; and decrypting the decoded data to be executed using the server's RSA private key to obtain the actual data to be executed. Determine the service call data based on the actual service to be executed; The service call data is sequentially encrypted and encoded using RSA before being sent to the client.

2. The application programming interface security protection method according to claim 1, characterized in that, The user login data includes login IP, verification string, RSA encryption application number, login timestamp, and random string; The user login data is sequentially subjected to a first login verification and an application key verification to determine the user's login status and corresponding login information, specifically including: The login IP is matched and verified based on a first preset login IP whitelist to obtain a first verification result; the first verification result includes verification qualified and verification unqualified. When the first test result is unqualified, the user's login status will be determined as login denied. When the first verification result is qualified, the RSA encrypted application number is decrypted using the server's RSA private key to determine the application number; The application ID is matched against a preset database to determine a preset application key; The preset application key, the random string, and the login timestamp are encrypted using MD5 to obtain the encrypted string; When the encrypted string does not match the verification string, the user's login status will be determined as login denied. When the encrypted string matches the verification string, the user's login status is determined to be allowed to log in, and a UUID string is randomly generated.

3. The application programming interface security protection method according to claim 2, characterized in that, The process of determining the verification string specifically includes: Within the client, the random string, the login timestamp, and the application key corresponding to the client are concatenated and then encrypted using MD5 to obtain a verification string.

4. The application programming interface security protection method according to claim 2, characterized in that, After performing a first login verification and an application key verification on the user login data in sequence to determine the user login status and corresponding login information, the method further includes: Obtain the first generation time of the business token; Calculate the difference between the first generation time and the login timestamp to obtain the login maintenance time; Determine whether the login duration is within the preset login validity period; If the login duration is within the preset login validity period, the service token is retained; If the login duration is not within the preset login validity period, the service token is discarded, and the process returns to the step of obtaining user login data sent by the client through the single sign-on interface.

5. The application programming interface security protection method according to claim 1, characterized in that, The business request data includes login IP, business request interface address, number of business request interface calls within a preset time period, verification string, login timestamp, random string, preset signature data, and business request body; The second login verification of the business request data specifically includes: The login IP is matched and verified based on a second preset login IP whitelist to obtain a second verification result; the second verification result includes verification passed and verification failed. When the second inspection result is unqualified, a service request rejection instruction is generated; When the second inspection result is qualified, the login interface is verified on the business request data; The login interface verifies the business request data, specifically including: Determine whether the address of the business request interface is consistent with the address of the interface allowed for client calls in the relational database, and whether the number of business request interface calls within the preset time period is lower than a preset number of times; If the address of the business request interface is inconsistent with the address of the interface allowed for client calls in the relational database, or if the number of business request interface calls within the preset time period is not less than the preset number of calls, a business request rejection instruction will be generated. If the address of the business request interface is consistent with the address of the interface allowed for client calls in the relational database, and the number of business request interface calls within the preset time period is lower than the preset number of calls, then the business request data will be verified using an interface verification code based on the business token.

6. The application programming interface security protection method according to claim 5, characterized in that, The process of determining the preset signature data specifically includes: In the client, the service request body is encrypted using the server's RSA public key; The encrypted business request body is encoded using Base64 encoding. The encoded business request body is concatenated with the application key corresponding to the client and then encrypted using MD5 to obtain preset signature data.

7. The application programming interface security protection method according to claim 5, characterized in that, The verification of the business request data using an interface verification code based on the business token also includes: Obtain the second generation time of the preset application key corresponding to the service token; Calculate the difference between the second generation time and the login timestamp to obtain the requested maintenance time; Determine whether the request duration is within the preset request validity range; If the login duration is within the preset login validity period, the business request data is retained, and then the preset application key corresponding to the business token, the random string, and the login timestamp are concatenated and encrypted using MD5. If the login duration is not within the preset login validity period, the business request data is discarded, and the process returns to the step of obtaining the business request data sent by the client through the business interface.

8. An application programming interface (API) security protection system, characterized in that, The system comprising the application programming interface security protection method according to any one of claims 1-7 includes: The login data acquisition module is used to acquire user login data sent by the client through the single sign-on interface; The login verification module is used to sequentially perform a first login verification and an application key verification on the user login data to determine the user login status and the corresponding login information; the user login status includes allowed login and denied login; when the user login status is allowed login, the corresponding login information is a business token; the business token is a randomly generated UUID string; The business data acquisition module is used to acquire business request data sent by the client through the business interface; The business verification module is used to sequentially perform second login verification, login interface verification, interface verification code verification based on the business token, and signature verification on the business request data to obtain the business data to be executed. The business decoding and decryption module is used to sequentially decode and RSA decrypt the business data to be executed to obtain the actual business to be executed; specifically, it includes: Base64 decoding the business data to be executed; and decrypting the decoded business data to be executed using the server's RSA private key to obtain the actual business to be executed. The business data retrieval module is used to determine the business retrieval data based on the actual business to be executed; The business data return module is used to sequentially encrypt and encode the business call data using RSA before sending it to the client.

Images