CN118540169B - API safety realizing method, system, medium and API framework realizing method - Google Patents

Abstract

The invention relates to an API safety realization method, an API safety realization system, a medium and an API framework realization method, and belongs to the technical field of computers. The method for the server side comprises the following steps: verifying configuration and sending, and extracting; a verification step; resending the CSRF-Token step. The method for the client side comprises the following steps: receiving an initial CSRF-Token; an interactive request step is sent; and receiving a response and a secondary CSRF-Token step. Compared with the prior art that only the time stamp is used for verification, the method can effectively defend replay attack, is convenient to configure, does not increase additional expenditure, and almost has no sense in the interaction and verification process.

Description

API security implementation method, system, medium and API framework implementation method

Technical Field

The present invention belongs to the field of computer technology and relates to an API security implementation method, system, medium and API framework implementation method.

Background Art

Replay attack, also known as copy attack or playback attack, is a network attack technique in which the attacker intercepts valid communication data and then resends the data at a selected time point in an attempt to obtain unauthorized access rights or perform unauthorized operations. It is a more threatening attack method.

API (application programming interface) is an important way for software systems to interact with each other. In some application scenarios, customers need to interact with developers' products or services through API to complete their own business needs. Customers frequently call APIs, and APIs are often exposed to the outside world. Replay attack defense during this interaction is crucial to API security.

At present, the traditional technology is to use timestamp verification for defense. When the client generates a request, it adds the current timestamp; the server receives the request and extracts the timestamp from it. The server checks the difference between the timestamp and the current time of the server. The server will set a time window, such as 5 minutes or less, to determine whether the request is initiated within a reasonable time. If the timestamp shows that the request is sent outside the time window (that is, the difference with the current time of the server exceeds the set threshold), the server will reject the request. Security verification through a time-sensitive element can defend against replay attacks to a certain extent. However, there is always a certain time difference from the client sending a request to the server. Even if the time window is set to be very short, such as 1 second, the attacker may make many concurrent requests within this time. This makes the timestamp verification method unable to completely defend against replay attacks, which brings challenges to the security of the API.

Therefore, how to ensure the security of the API interaction process, effectively defend against replay attacks, and protect the assets of enterprises and users from loss is a technical problem that needs to be solved urgently.

Summary of the invention

In order to solve the technical problems in the above-mentioned background technology, the present invention provides an API security implementation method, system, medium and API framework implementation method.

The technical solution of the present invention to solve the above technical problems is as follows:

In a first aspect, a method for implementing API security is provided, which is used on a server side, and the method comprises the steps of:

Verify the configuration and sending steps, generate a one-time initial CSRF-Token, set the time window for interactive requests, and then send the initial CSRF-Token to the client;

Extraction step, receiving the client interaction request, extracting the timestamp and the CSRF-Token to be verified from the client interaction request;

Verification step: Verify whether the CSRF-Token to be verified carried in the interaction request is consistent with the initial CSRF-Token stored in the server, and whether the timestamp of the interaction request is within the time window; if both are met at the same time, access is allowed and the initial CSRF-Token stored in the server is destroyed; if both are not met at the same time, defense is initiated;

Resend the CSRF-Token step to generate a one-time secondary CSRF-Token, and send the secondary CSRF-Token to the client along with the response.

In a second aspect, a method for implementing API security is provided, which is used for a client, and the method comprises the steps of:

Receiving the initial CSRF-Token step, receiving and saving the initial CSRF-Token on the server side;

Sending an interaction request step: sending an interaction request to the server, the interaction request carries the initial CSRF-Token and timestamp;

The step of receiving a response and a secondary CSRF-Token includes receiving a secondary CSRF-Token from the server side along with the response, and saving the secondary CSRF-Token; wherein the server side is used to generate a one-time initial CSRF-Token, a one-time secondary CSRF-Token, and set a time window for interaction requests; the server side is also used to verify whether the CSRF-Token to be verified carried by the interaction request is consistent with the initial CSRF-Token saved in the server, and whether the timestamp of the interaction request is within the time window; if both conditions are met at the same time, access is allowed, and the initial CSRF-Token saved in the server is destroyed; if both conditions are not met at the same time, defense is initiated.

In a third aspect, an API security implementation system is provided, which is used on a server side, and the system includes:

Verify configuration and send module, used to generate a one-time initial CSRF-Token, set the time window for interactive requests, and then send the initial CSRF-Token to the client;

An extraction module is used to receive a client interaction request and extract a timestamp and a CSRF-Token to be verified from the client interaction request;

The verification module is used to verify whether the CSRF-Token to be verified carried in the interaction request is consistent with the initial CSRF-Token saved in the server, and whether the timestamp of the interaction request is within the time window; if both are met at the same time, access is allowed and the initial CSRF-Token saved in the server is destroyed; if both are not met at the same time, defense is initiated;

The resend CSRF-Token module is used to generate a one-time secondary CSRF-Token and send the response and the secondary CSRF-Token to the client.

In a fourth aspect, a computer-readable storage medium stores a computer program, which implements the above-mentioned API security implementation method when executed by a processor.

In a fifth aspect, an API framework implementation method is provided, which is used on the server side, and uses the above-mentioned API security implementation method to perform API call protection of the API framework, and also includes the steps of:

The API framework creation step is to create an API framework with a unified API entry and a routing pool on the server. The API framework is provided with several mutually isolated main version directories, and each main version directory is provided with several mutually isolated sub-version directories; the routing pool stores the mapping relationship rules between the request matching path and the specified version directory;

In the version call request receiving step, the API entry receives the client version call request, which includes the URL path and the specified HTTP header, or the URL path and query parameters; the version call request also includes a timestamp and a CSRF-Token to be verified;

Parsing routing step: The API framework parses the version call request, and then routes the version call request to the target version directory according to the routing pool mapping relationship rules;

In the response step, according to the routing result, the API framework calls the target version directory to process the client version call request, and then forms a response and sends it back to the client.

An API security implementation method, system, medium and API framework implementation method provided by the embodiments of the present invention verify user interaction requests based on a one-time CSRF-Token and timestamp. Compared with the prior art that only uses timestamps for verification, it can effectively defend against replay attacks, is easy to configure, does not increase additional overhead, and the interaction and verification process is almost imperceptible.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG1 is a flow chart of a method for implementing API security using double verification on a server side provided by an embodiment of the present invention.

FIG2 is a flow chart of a method for implementing API security using triple verification on a server side provided by an embodiment of the present invention.

FIG3 is a schematic flow chart of a method for implementing API security in a client provided by an embodiment of the present invention.

FIG4 is a schematic diagram of a system structure for implementing triple-verification API security in a server-side according to an embodiment of the present invention.

FIG5 is a flow chart of a method for implementing an API framework in a server-side according to an embodiment of the present invention.

FIG6 is a schematic diagram of the structure of the main version directory and the secondary version directory in the API framework provided by an embodiment of the present invention.

In the accompanying drawings, the components represented by the reference numerals are listed as follows:

400, security dictionary setting module; 410, verification configuration and sending module; 420, extraction module; 430, verification module; 440, resending CSRF-Token module.

DETAILED DESCRIPTION

In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

Replay attacks are a type of network attack that intercepts and resends communication data to gain unauthorized access. In API interactions, traditional timestamp verification methods can defend against such attacks to a certain extent, but due to the time difference between the client and the server, this method cannot completely prevent attackers from sending a large number of concurrent requests in a very short period of time. Therefore, developing more effective technologies to ensure the security of API interactions and prevent replay attacks is crucial to protecting enterprise and user assets.

In view of the above problems, an embodiment of the present invention provides an API security implementation method for a server. FIG1 is a flow chart of an API security implementation method for a server provided by an embodiment of the present invention. As shown in FIG1 , the method includes:

Step S101, generate a one-time initial CSRF-Token, set a time window for interaction requests, and then send the initial CSRF-Token to the client.

Cross-Site Request Forgery (CSRF) is a network attack that exploits the trust of a web application in a user's browser. The attacker tricks the user into clicking a link or uses some technical means such as JavaScript without the user's knowledge to make the browser send an unexpected request to a trusted website.

CSRF-Token is a technical means to defend against CSRF. The main purpose of CSRF-Token is to protect the user's session in the application from being maliciously exploited after the user has logged in through other means (such as using a username and password).

It is understandable that the one-time initial CSRF-Token mentioned here means that the CSRF-Token is generated uniquely in the server and is only sent to the client once. Therefore, it can be ensured that the client obtains a unique CSRF-Token.

It is understandable that there are various ways to generate CSRF-Token. It can be generated by random value, using a random number generator to create an unpredictable Token value; it can be generated based on session, and the generation of Token is associated with the user's session (Session), which may contain session ID or other session-specific information; it can also be generated using blockchain technology to ensure the uniqueness and non-tamperability of Token. Therefore, the embodiments of the present invention do not make specific limitations on this.

Step S102: receiving a client interaction request, and extracting a timestamp and a CSRF-Token to be verified from the client interaction request.

Step S103, verify whether the CSRF-Token to be verified carried by the interaction request is consistent with the initial CSRF-Token stored in the server, and whether the timestamp of the interaction request is within the time window; if both are met at the same time, access is allowed and the initial CSRF-Token stored in the server is destroyed; if both are not met at the same time, defense is initiated.

It is worth noting that, for a specific verification process, CSRF-Token verification can be performed first, and then timestamp verification; CSRF-Token verification and timestamp verification can also be performed simultaneously; or timestamp verification can be performed first, and then CSRF-Token verification can be performed. Therefore, the embodiment of the present invention does not specifically limit this. However, the token is unique, and the timestamp is allowed to be accessed within a certain error range. As a preferred method, the correctness of the CSRF-Token is verified first, and then the timestamp is verified, which is more suitable for program logic.

In addition, if a CSRF attack or timestamp anomaly is detected, the server can immediately take defensive measures, including but not limited to rejecting the request, limiting the user session or reminding the user, and their combination. Therefore, the embodiment of the present invention does not specifically limit this.

We can also add some monitoring and analysis measures. For example, the server can use logs to monitor and record all received requests and their verification results to facilitate post-audit and monitoring of potential abnormal behavior.

Step S104, generate a one-time secondary CSRF-Token, and send the secondary CSRF-Token to the client along with the response.

In the prior art, the client attaches an accurate timestamp when sending a request. After receiving the request, the server will immediately compare the timestamp with the current time of the server, and verify the timeliness of the request by setting a very short time window (such as within 1 second), so as to resist replay attacks. On the one hand, due to the inherent delay in the network transmission from the client to the server, the attacker may send a large number of concurrent requests during the time window, which makes the verification method that relies only on the timestamp face great challenges; on the other hand, in the interactive scenario, users often perform frequent operations with strong real-time requirements. The designed defense measures need to balance security and user experience to avoid affecting the normal interaction of users due to security measures.

In the embodiment of the present invention, for interactive scenarios, a one-time CSRF-Token provides an additional security layer for each request. Even if an attacker can intercept a request, the request cannot be reused without a valid Token. The comparison of the timestamp with the current time of the server ensures that the request is issued within a reasonable time window, reducing the risk of the request being delayed or replayed. The use of this CSRF-Token and timestamp dual verification method can effectively defend against replay attacks. In addition, the implementation of this verification method simplifies the configuration process and can seamlessly improve the security of the Web framework and API platform. Since the generation and verification process of CSRF-Token and timestamp are very fast, the impact on system performance is minimal. Users will not feel any delays or interruptions when interacting, and the verification process is transparent to them, thereby ensuring a smooth interactive experience. The security of the API can be enhanced without sacrificing the user experience, effectively balancing security measures, application performance, and user experience.

Based on the above embodiment, in the method, the step S101 further includes: the initial CSRF-Token is sent to the client in a hidden manner, and the sending channel is an encrypted channel;

Step S102 also includes: the secondary CSRF-Token is sent to the client in a hidden manner, and the sending channel is an encrypted channel.

It is worth noting that the hidden sending methods mentioned in this embodiment are various, including but not limited to: using a hidden <input> field in an HTML form to include the CSRF-Token, so that when the user submits the form, the Token will be sent along with the form data; attaching the CSRF-Token to the requested URL as a query parameter of the URL; storing the CSRF-Token through HTTPOnly Cookies, so that the Token will not be accessed by client scripts and has better concealment; using a custom HTTP request header to send the Token, which requires the cooperation of the client and the server, and will not be exposed to the end user. Therefore, the embodiments of the present invention do not specifically limit this.

It is worth noting that the encryption channels mentioned in this embodiment are various, including but not limited to: using HTTP Secure (HTTPS) protocol to encrypt all communications between the client and the server to ensure the security of data during transmission; using SSL (Secure Sockets Layer) or its successor TLS (Transport Layer Security) protocol to encrypt data transmission; in an enterprise environment, the client connects to the internal network through VPN (Virtual Private Network) and then communicates with the server, and VPN provides an encrypted communication tunnel; using encrypted API gateways or services, which encrypt requests before forwarding them to backend services. Therefore, the embodiments of the present invention do not specifically limit this.

The method provided in this embodiment further enhances the security of the CSRF-Token through these covert sending methods and encrypted channels, reduces the risk of the Token being intercepted during transmission, and thus further prevents replay attacks.

Based on the above embodiment, as shown in FIG2 , the method includes:

Step S201, setting a security dictionary for each API endpoint, the security dictionary stipulates that the server only receives two parameters, offset and limit, and the value of each parameter is a positive integer between 1 and 100;

Step S202, generating a one-time initial CSRF-Token, setting a time window for interactive requests, associating the initial CSRF-Token with the request of the specified API endpoint, and then sending the initial CSRF-Token to the client;

Step S203, receiving a client interaction request, and extracting a timestamp, a CSRF-Token, an API input parameter, and an API input parameter value from the client interaction request;

Step S204: Verify whether the CSRF-Token carried by the interaction request is consistent with the initial CSRF-Token stored in the server, whether the timestamp of the interaction request is within the time window, and whether the API input parameter and the API input parameter value comply with the provisions of the security dictionary; if all three are met at the same time, access is allowed and the initial CSRF-Token stored in the server is destroyed; if all three are not met at the same time, defense is initiated;

Step S205, generate a one-time secondary CSRF-Token, and send the secondary CSRF-Token to the client along with the response.

It is worth noting that in step S201, offset refers to the offset, which indicates how many records are skipped from the start position of the query result; limit is the limit number, which indicates the number of records planned to be obtained from the query result. After determining the type and value that should be transmitted by each API entry, illegal characters can be avoided, further ensuring the security of the API; at the same time, it can be intercepted at the API entry to avoid making separate judgments in each business logic, which affects system overhead.

It is also worth noting that in step S202, associating the initial CSRF-Token with the request to the specified API endpoint means that the CSRF-Token generated by the server is associated with the user session, rather than being permanently bound to a specific API endpoint. When the user interacts with the application, especially with the API endpoint through a form or request, the CSRF-Token is used to ensure that these requests are issued from the user's browser, rather than from a malicious third-party website. The purpose of the CSRF-Token is to provide an additional layer of security for all requests made by the user during the session.

The method provided in this embodiment uses a security dictionary to verify API request parameters, which ensures that only parameters that meet predetermined rules are accepted and processed. Combined with CSRF-Token and timestamp, it can effectively improve the overall security. At the same time, the verification parameters and values are transparent to the user and will not directly affect the user's operating process or perceived response time. This method can greatly improve security, but has little impact on system overhead and user experience, and better achieves a balance between security and performance.

As shown in FIG3 , an embodiment of the present invention provides an API security implementation method for a client, the method comprising the steps of:

Step S301, receiving and saving the initial CSRF-Token on the server side;

Step S302, sending an interaction request to the server, the interaction request carries an initial CSRF-Token and a timestamp;

Step S303, receiving the secondary CSRF-Token from the server in response, and saving the secondary CSRF-Token; wherein the server is used to generate a one-time initial CSRF-Token, a one-time secondary CSRF-Token and set a time window for the interaction request; the server is also used to verify whether the CSRF-Token to be verified carried by the interaction request is consistent with the initial CSRF-Token saved in the server, and whether the timestamp of the interaction request is within the time window; if both are satisfied at the same time, access is allowed, and the initial CSRF-Token saved in the server is destroyed; if both are not satisfied at the same time, defense is started.

In the method provided in this embodiment, during the entire process, the client relies on the server to strictly verify the carried CSRF-Token and timestamp, ensuring that only requests that meet the requirements can be accepted by the server, thereby effectively defending against replay attacks and providing users with a seamless and secure operating experience.

As shown in FIG4 , an embodiment of the present invention provides an API security implementation system for a server, the system comprising:

Verification configuration and sending module 410, used to generate a one-time initial CSRF-Token, set a time window for interactive requests, and then send the initial CSRF-Token to the client;

An extraction module 420 is used to receive a client interaction request and extract a timestamp and a CSRF-Token to be verified from the client interaction request;

Verification module 430, used to verify whether the CSRF-Token to be verified carried in the interaction request is consistent with the initial CSRF-Token stored in the server, and whether the timestamp of the interaction request is within the time window; if both are satisfied at the same time, access is allowed and the initial CSRF-Token stored in the server is destroyed; if both are not satisfied at the same time, defense is initiated;

The resend CSRF-Token module 440 is used to generate a one-time secondary CSRF-Token and send the response and the secondary CSRF-Token to the client.

Preferably, as shown in FIG4 , before the verification configuration and sending module 410, the method further includes:

The security dictionary setting module 400 is used to set a security dictionary for each API endpoint. The security dictionary stipulates that the server only receives two parameters, namely, offset and limit, and the value of each parameter is a positive integer between 1 and 100;

The verification configuration and sending module 410 is also used to associate the initial CSRF-Token with the request of the specified API endpoint;

The extraction module 420 is further used to receive a client interaction request, and extract a timestamp, a CSRF-Token, an API input parameter, and an API input parameter value from the client interaction request;

The verification module 430 is also used to verify whether the CSRF-Token carried in the interaction request is consistent with the initial CSRF-Token stored in the server, whether the timestamp of the interaction request is within the time window, and whether the API input parameters and API input parameter values comply with the provisions of the security dictionary; if the three are met at the same time, access is allowed and the initial CSRF-Token stored in the server is destroyed; if the three are not met at the same time, defense is initiated.

The system provided in this embodiment can provide users with a more secure and reliable interaction environment in an almost imperceptible manner through this verification form based on a one-time CSRF-Token and a timestamp.

In this embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the API security implementation method described in the above embodiment is implemented.

As shown in FIG5 , an embodiment of the present invention provides an API framework implementation method for a server side, and uses the API security implementation method of the above embodiment to perform API call protection of the API framework, including the steps of:

Step S501, generate a one-time initial CSRF-Token, set a time window for interactive requests, and then send the initial CSRF-Token to the client;

Step S502: Create an API framework with a unified API entry and a routing pool on the server. The API framework is provided with a number of mutually isolated main version directories, and each main version directory is provided with a number of mutually isolated sub-version directories; the routing pool stores the mapping relationship rules between the request matching path and the specified version directory;

Step S503: The API entry receives a client version call request, the version call request includes a URL path and a specified HTTP header, or a URL path and query parameters, and the version call request also includes a timestamp and a CSRF-Token to be verified;

Step S504, extracting the timestamp and the CSRF-Token to be verified from the client interaction request;

Step S505: Verify whether the CSRF-Token to be verified carried by the interaction request is consistent with the initial CSRF-Token stored in the server, and whether the timestamp of the interaction request is within the time window; if both conditions are met at the same time, access is allowed and the initial CSRF-Token stored in the server is destroyed; if both conditions are not met at the same time, defense is initiated;

Step S506, the API framework parses the version call request, and then routes the version call request to the target version directory according to the routing pool mapping relationship rule;

Step S507, according to the routing result, the API framework calls the target version directory to process the client version call request, and then generates a response and a one-time secondary CSRF-Token and sends it back to the client.

In the embodiments of the present invention, the constructed API framework itself has the characteristics of high modularity, flexible routing mechanism and stable and secure API entry, etc. On this basis, with the specific version call request, that is, selecting the URL path with the specified HTTP header or query parameter, on the one hand, the required version can be dynamically specified and switched without changing the URL by passing the version information through the HTTP header or query parameter, and on the other hand, it also provides additional scalability, allowing the client to request specific functions of a specific version as needed. Therefore, it can meet the version iteration and maintenance needs of developers, and meet the needs of customers to flexibly call the required version code through the API.

Based on the above embodiment, in the method, step S502 includes:

Step S5021, creating an API framework on the server side, wherein the API framework has a unified API entry for receiving and responding to external requests.

Step S5022, create several mutually isolated main version directories in the API framework, create a general configuration information directory and a secondary version directory in each main version directory, the general configuration information directory and the secondary version directory are isolated from each other, and a first controller is set in the secondary version directory.

It is worth noting that a common configuration information directory is created in each main version directory. This directory is used to store configuration information shared by all sub-versions and revisions, such as database connection information, API keys, log configuration, etc. This centralized management facilitates maintenance and updates. At the same time, ensuring that the common configuration information directory is isolated from the sub-version directory can effectively avoid conflicts and misuse of configuration information.

In addition, a controller needs to be set in each sub-version directory. The controller is the core component in the API framework, responsible for processing client requests and returning responses. The controller contains business logic and data access logic. In this embodiment, the path of the version call request is resolved to the controller, which can receive requests and output responses.

Step S5023, set version control in the API entry path to support operations of different versions of API.

It is understandable that version control here does not refer to a holistic method. Version control here is a technical means to implement version control in the API URL. More specifically, it can clearly distinguish different versions of the API in the API URL path for easy management and calling.

For users, setting version control in the API entry path allows them to explicitly select the API version they want to use through the URL path; for developers, setting version control in the API entry path makes it easier to manage and deploy different versions of the API.

Step S5024, creating a routing pool in the API framework, saving a number of request matching paths in the routing pool, and making a one-to-one correspondence between the request matching paths and the specified version directories to form a mapping relationship rule.

The method provided in this embodiment utilizes the isolation of version directories to ensure the centralized management and security of configuration information. The unified API entry and version control mechanism provide a clear structure and flexibility for the entire framework. The setting of the controller and the creation of the routing pool ensure that requests can be processed efficiently and accurately, thereby realizing a more efficient, more secure, scalable and easy-to-maintain API multi-version control framework.

Based on the above embodiment, in the method, step S5022 further includes:

Step S50221, a configuration file directory, a description directory and a language directory are created in the general configuration information directory;

Step S50222: A controller directory and a business logic extension directory are created in the secondary version directory, a revised version directory is created in the business logic extension directory, and the revised version directory stores a second controller.

For ease of understanding, as shown in Figure 6, we show the structure of the main version directory (V1) and the secondary version directory (V1.0) in the API framework, and explain the subdirectories in the main version directory and the secondary version directory:

(1) Configuration file directory (config): Create a configuration file directory in the common configuration information directory to allow centralized storage of configuration files shared by all API versions, such as database configuration, server endpoints, etc.;

(2) Description: Contains documentation on the use of the API, which may include how to use the API, parameter descriptions, version update logs, etc., to help users and developers understand how the API works and how to use it;

(3) Language directory (lang): used to store resource files for multi-language support, so that the API can return responses in the corresponding language based on the language preference of the request;

(4) Controller directory: Create a controller directory in the secondary version directory to store controller code that handles specific business logic;

(5) Business logic extension directory (logic): provides an extension point that allows developers to add additional business logic processing modules as needed.

In addition, we create a revision directory in the business logic extension directory to store the second controller and provide revisions. In addition, in Figure 6, app refers to the application, which represents the version management part, that is, the root directory; alarm usually refers to the alarm or notification system, and the configuration information directory and the sub-version directory can be set in this directory for specific reminders.

In addition, some function directories may be added according to specific usage scenarios, such as adding a log directory and an environment directory to a configuration file directory, and adding a service directory (service) and a validation directory (validate) to a secondary version directory. This is not specifically limited in the embodiments of the present invention.

Different from the previous implementation method, this embodiment allows developers to expand and revise specific functions without affecting the main business logic, further improving the flexibility and maintainability of the API. At the same time, by creating a second controller in the business logic extension directory, the controller is modularized, so that different business logics can be processed by different controllers, which helps to reduce the coupling of the code. In addition, a clear directory also makes management more organized and professional.

The computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for performing the operations of the present invention may be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, Ruby, Go, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

The above-mentioned embodiments only express several implementation methods of the present invention, and the description thereof is relatively specific and detailed, but it cannot be understood as limiting the scope of the patent of the present invention. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be subject to the attached claims.

Claims (4)

1. A method for implementing an API framework, characterized in that it is used on a server side and comprises the steps of: The API framework creation step is to create an API framework with a unified API entry and a routing pool on the server. The API framework is provided with several mutually isolated main version directories, and each main version directory is provided with several mutually isolated sub-version directories; the routing pool stores the mapping relationship rules between the request matching path and the specified version directory; In the version call request receiving step, the API entry receives the client version call request, which includes the URL path and the specified HTTP header, or the URL path and query parameters; the version call request also includes a timestamp and a CSRF-Token to be verified; Parsing routing step: The API framework parses the version call request, and then routes the version call request to the target version directory according to the routing pool mapping relationship rules; In the response step, according to the routing result, the API framework calls the target version directory to process the client version call request, and then forms a response and sends it back to the client; The API framework creation step further includes: An API framework preliminary creation step is to create an API framework on the server side, wherein the API framework has a unified API entry for receiving and responding to external requests; The version directory creation step is to create several mutually isolated main version directories in the API framework, and create a general configuration information directory and a sub-version directory in each main version directory. The general configuration information directory and the sub-version directory are mutually isolated. The general configuration information directory is used to store configuration information shared by all sub-versions and revisions. The sub-version directory is provided with a first controller, which is responsible for processing client requests and returning responses, including business logic and data access logic. The path of the version call request is resolved to the controller; Version control setting step: set version control in the API entry path to support operations on different versions of the API; The routing pool setting step is to create a routing pool in the API framework, save several request matching paths in the routing pool, and correspond the request matching paths to the specified version directories one by one to form a mapping relationship rule; Among them, the API call protection for the API framework also includes the following steps: Verify the configuration and sending steps, generate a one-time initial CSRF-Token, set the time window for interactive requests, and then send the initial CSRF-Token to the client; Extraction step, receiving the client interaction request, extracting the timestamp and the CSRF-Token to be verified from the client interaction request; Verification step: Verify whether the CSRF-Token to be verified carried in the interaction request is consistent with the initial CSRF-Token stored in the server, and whether the timestamp of the interaction request is within the time window; if both are met at the same time, access is allowed and the initial CSRF-Token stored in the server is destroyed; if both are not met at the same time, defense is initiated; Resend the CSRF-Token step to generate a one-time secondary CSRF-Token, and send the secondary CSRF-Token to the client along with the response. 2. The API framework implementation method according to claim 1, characterized in that the verification configuration and sending steps further include: The initial CSRF-Token is sent to the client in a hidden manner, and the sending channel is an encrypted channel; The step of resending the CSRF-Token further includes: The secondary CSRF-Token is sent to the client in a hidden manner, and the sending channel is an encrypted channel. 3. The API framework implementation method according to claim 1 is characterized in that before the verification configuration and sending steps, it also includes: Security dictionary setting step: Set a security dictionary for each API endpoint. The security dictionary stipulates that the server only receives two parameters: offset and limit, and the value of each parameter is a positive integer; The verification configuration and sending steps further include: associating the initial CSRF-Token with the request of the specified API endpoint; The extraction step further includes: receiving a client interaction request, extracting a timestamp, a CSRF-Token, an API input parameter, and an API input parameter value from the client interaction request; The verification step also includes: verifying whether the CSRF-Token carried by the interaction request is consistent with the initial CSRF-Token stored in the server, whether the timestamp of the interaction request is within the time window, and whether the API input parameters and API input parameter values comply with the provisions of the security dictionary; if the three are met at the same time, access is allowed and the initial CSRF-Token stored in the server is destroyed; if the three are not met at the same time, defense is initiated. 4. The API framework implementation method according to claim 1, characterized in that the version directory creation step further includes: A general configuration information directory setting step, wherein a configuration file directory, a description directory and a language directory are created in the general configuration information directory; A business logic extension directory setting step is performed, wherein a controller directory and a business logic extension directory are created in the secondary version directory, a revision version directory is created in the business logic extension directory, and the revision version directory stores a second controller.