WebAPI security management method, system and device and storage medium

Abstract

The embodiment of the invention provides a WebAPI security management method, the WebAPI security management method is executed by a processor controlling a protection component, the protection component comprises a front-end calling component and a rear-end security piece, and the method comprises the following steps: receiving an interface calling request sent by a client through the front-end calling component, the number of times and interval time of the target interface calling requests from the client side are obtained; controlling the front-end calling component to determine a calling request instruction matched with the interface calling request according to the interface request parameter so as to receive interface request metadata sent by the client, and performing encryption processing; in response to starting the back-end security piece, sending the back-end security piece; and in response to the condition that the preset calling condition is met, sending the interface request metadata to the back-end service component through the back-end security element to obtain feedback data, sending the back-end security element, sending the back-end security element to the front-end calling component, decrypting the back-end security element by the front-end calling component, and sending the decrypted back-end security element to the client.

Description

Case Analysis

[0001] This application is a divisional application of Chinese application filed on December 17, 2024, with Chinese patent application number 202411858358.8 and the invention title "A WebAPI Protection Method, System, Apparatus and Storage Medium". Technical Field

[0002] This specification relates to the field of WebAPI security management, and in particular to a WebAPI security management method, system, device, and storage medium. Background Technology

[0003] In the traditional Web API interface call request process, the front end directly accesses the backend service components through HTTP requests. Attackers can use tools such as Burp Suite and Fiddler to intercept interface call requests, modify the parameters of the interface call requests, and carry out attacks such as SQL injection, file upload bypass, interface brute-force attack, and unauthorized traversal of the list of open interfaces.

[0004] This specification provides a WebAPI security management method, system, device, and storage medium. By taking over the WebAPI call process through a protection component, it renders existing attack tools ineffective, increases the cost and difficulty of attacks for attackers. Summary of the Invention

[0005] This specification provides one or more embodiments of a WebAPI security management method, wherein the WebAPI security management method is executed by a processor-controlled protection component, the protection component including a front-end invocation component and a back-end security component. The WebAPI security management method includes: receiving an interface call request from a client through the front-end invocation component, and obtaining the number of times and the interval between target interface call requests from the client; the interface call request corresponds to interface request parameters, and the target interface call request is an interface call request that meets preset conditions; controlling the front-end invocation component to determine a call request instruction matching the interface call request based on the interface request parameters; controlling the front-end invocation component to receive interface request metadata from the client based on the call request instruction, and encrypting the interface request metadata to generate a first ciphertext; and based on the number of times, the interval, whether the user is a high-frequency user, and / or whether the target interface call request is high-frequency. The system requests and assesses the impact of the waiting time corresponding to the execution of the protection process on the user; based on the impact, it determines whether to activate the backend security component; in response to activating the backend security component, it receives the first ciphertext through the backend security component, decrypts the first ciphertext to regenerate the interface request metadata; in response to meeting preset invocation conditions, it sends the interface request metadata to the backend service component through the backend security component; it receives feedback data from the backend service component through the backend security component, and encrypts the feedback data to generate a second ciphertext; it receives the second ciphertext through the frontend invocation component and decrypts it to regenerate the feedback data; and it sends the feedback data to the client through the frontend invocation component.

[0006] This specification provides a WebAPI security management system through one or more embodiments. The system includes a processor and a protection component, electrically connected. The protection component includes a front-end invocation component and a back-end security component. The processor is configured to: receive interface call requests from clients via the front-end invocation component, and obtain the number of times and the interval between target interface call requests from the clients; each interface call request corresponds to interface request parameters, and the target interface call request is an interface call request that meets preset conditions; control the front-end invocation component to determine a call request instruction matching the interface call request based on the interface request parameters; control the front-end invocation component to receive interface request metadata from the clients based on the call request instruction, and encrypt the interface request metadata to generate a first ciphertext; based on the number of times, the interval, and whether the user is... Whether the high-frequency user and / or the target interface call request is a high-frequency request, assess the impact of the waiting time corresponding to the execution of the protection process on the user; based on the impact, determine whether to start the backend security component; in response to starting the backend security component, receive the first ciphertext through the backend security component, decrypt the first ciphertext to regenerate the interface request metadata; in response to meeting the preset call conditions, send the interface request metadata to the backend service component through the backend security component; receive feedback data from the backend service component through the backend security component, and encrypt the feedback data to generate a second ciphertext; receive the second ciphertext through the frontend invocation component and decrypt it to regenerate the feedback data; and send the feedback data to the client through the frontend invocation component.

[0007] This specification provides one or more embodiments of a WebAPI security management device, including at least one processor and at least one memory; the at least one memory is used to store computer instructions; the at least one processor is used to execute at least a portion of the computer instructions to implement a WebAPI security management method.

[0008] This specification provides one or more embodiments of a computer-readable storage medium that stores computer instructions. When a computer reads the computer instructions from the storage medium, the computer executes a WebAPI security management method. Attached Figure Description

[0009] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein: Figure 1This is a schematic diagram of the modules of a WebAPI security management system according to some embodiments of this specification; Figure 2 This is an exemplary flowchart of a WebAPI security management method according to some embodiments of this specification; Figure 3 This is an exemplary flowchart illustrating whether to enable backend security components according to some embodiments of this specification; Figure 4 This is another exemplary flowchart illustrating the determination of whether to enable the backend security component, as shown in some embodiments of this specification. Detailed Implementation

[0010] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0011] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0012] As indicated in this specification and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of expressly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0013] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0014] Figure 1 This is a schematic diagram of the modules of a WebAPI security management system according to some embodiments of this specification.

[0015] In some embodiments, the WebAPI security management system 100 may include a processor 110 and a protection component 120, which are electrically connected.

[0016] Protection component 120 refers to a pre-configured WebAPI interface protection framework, such as a package.

[0017] In some embodiments, the protection component 120 includes a front-end access component 121 and a back-end security component 122.

[0018] The front-end call component 121 is part of the protection component. The front-end call component 121 can be used to receive interface call requests sent by users through a client. The client can include mobile phones, computers, etc. The front-end call component 121 can reside on a server.

[0019] Backend security component 122 is another part of the protection component. Backend security component 122 is configured to automatically perform security protection related tasks for API call requests. Backend security component 122 can be configured on one of the following: a server, a virtual machine, a cloud service platform, etc.

[0020] In some embodiments, the processor is configured to: receive an interface call request from a client via a front-end invocation component, the interface call request corresponding to interface request parameters; control the front-end invocation component to determine a call request instruction matching the interface call request based on the interface request parameters; control the front-end invocation component to receive interface request metadata from the client based on the call request instruction, and encrypt the interface request metadata to generate a first ciphertext; receive the first ciphertext via a back-end security component, and decrypt the first ciphertext to regenerate the interface request metadata; in response to meeting preset invocation conditions, send the interface request metadata to a back-end service component via the back-end security component; receive feedback data from the back-end service component via the back-end security component, and encrypt the feedback data to generate a second ciphertext; receive the second ciphertext via the front-end invocation component and decrypt it to regenerate the feedback data; and send the feedback data to the client via the front-end invocation component.

[0021] In some embodiments, the front-end retrieval component further includes a caching component, which is configured to cache the call request instructions corresponding to the interface call requests of high-frequency requests and / or high-frequency users; the processor is further configured to: in response to identifying high-frequency requests or high-frequency users, control the front-end retrieval component to determine, through the caching component, the call request instructions corresponding to the interface call requests of high-frequency requests and / or high-frequency users based on the interface request parameters.

[0022] In some embodiments, the processor is further configured to: determine the security value corresponding to the interface call request based on the interface request parameters and interface request metadata corresponding to the interface call request; and determine whether to enable the backend security component based on the security value and the security value threshold, wherein the backend security component is configured to perform protection processing on subsequent interface call requests.

[0023] In some embodiments, the processor is further configured to: estimate the waiting time corresponding to the execution of the protection process based on the interface call request, the waiting time including the waiting time corresponding to the execution of the call request instruction, encryption processing and decryption processing; after receiving the interface call request issued by the client, obtain the number of target interface call requests from the client and the interval time, the target interface call request being an interface call request that meets preset conditions; assess the impact of the waiting time on the user based on the number of requests and the interval time; and determine whether to enable the backend security component based on the impact.

[0024] For further information regarding the components of processor 110 and protection assembly 120, please refer to [link to relevant documentation]. Figures 2-4 The relevant explanations are in the text.

[0025] It should be noted that the above description of the WebAPI security management system and its modules is for convenience only and should not be construed as limiting this specification to the scope of the illustrated embodiments. It is understood that those skilled in the art, after understanding the principles of the system, may arbitrarily combine the various modules or construct subsystems connected to other modules without departing from these principles. In some embodiments, Figure 1 The processors and protection components disclosed herein can be different modules within a system, or a single module can implement the functions of two or more of the aforementioned modules. For example, modules can share a single storage module, or each module can have its own separate storage module. Such variations are all within the scope of protection of this specification.

[0026] Figure 2 This is an exemplary flowchart illustrating a WebAPI security management method according to some embodiments of this specification. Figure 2 As shown, process 200 includes steps 210-280. In some embodiments, process 200 may be executed by processor 110 controlling protection component 120.

[0027] Step 210: Receive the interface call request sent by the client through the front-end call component.

[0028] An API call request refers to information related to a user request. User requests can include user login requests, file upload requests, data retrieval requests, data analysis requests, etc.

[0029] In some embodiments, the API call request corresponds to API request parameters.

[0030] Interface request parameters refer to the characteristic parameters corresponding to the interface call request sent by the client.

[0031] In some embodiments, the interface request parameters include at least one of the following: request type code, request time point, user login identifier, virtual address, and geographical location.

[0032] The request type code refers to the code corresponding to the type of the API call request. The type of the API call request can include one of the following: creating a new user, user login, information query, data collection, data analysis, etc. The codes corresponding to each API call request type can be preset by those skilled in the art based on experience.

[0033] The request time point refers to the time point recorded by the client when the user made the API call request.

[0034] User login identifiers may include the user's username and password for logging into the client.

[0035] Virtual addresses can include the IP address of the user's login client, etc.

[0036] Geographic location refers to the geographical region corresponding to the client, such as Beijing, Chengdu, etc.

[0037] In some embodiments, the processor can parse the interface call request through the user terminal to obtain the interface request parameters.

[0038] In some embodiments, the processor can generate an interface call request based on relevant information sent by the user through the client's interactive interface.

[0039] Step 220: Control the front-end retrieval component to determine the call request instruction that matches the interface call request based on the interface request parameters.

[0040] A call request instruction refers to the set of code generated internally by the front-end component that relates to API call requests. Different API call requests can correspond to different call request instructions.

[0041] In some embodiments, the processor can control the front-end retrieval component to determine a call request instruction that matches the interface call request based on the interface request parameters and through a first preset lookup table. In some embodiments, the first preset lookup table includes the correspondence between multiple different reference interface request parameters and reference call request instructions that match the reference interface call requests. In some embodiments, the first preset lookup table can be constructed based on prior knowledge or historical data.

[0042] In some embodiments, the front-end retrieval component further includes a caching component, which is configured to cache the call request instructions corresponding to the interface call requests of high-frequency requests and / or high-frequency users; in response to identifying high-frequency requests or high-frequency users, the processor controls the front-end retrieval component to determine the call request instructions corresponding to the interface call requests of high-frequency requests and / or high-frequency users through the caching component based on the interface request parameters.

[0043] A caching component is a component used to cache data. Caching components can be a combination of hardware and software, such as a cache database.

[0044] High-frequency requests refer to API call requests that meet specific requirements among one or more API call request types. API call request types can be categorized into at least one of the following: new user creation, user login, information query, data collection, and data analysis. Meeting specific requirements for one or more API call request types can be understood as follows: within a preset time period, classifying all API call request types sent by one or more clients, and counting the number of requests for each API call request type; and identifying one or more API call request types whose number of requests exceeds a preset threshold as meeting specific requirements.

[0045] In some embodiments, when the processor counts the number of requests for a certain type of interface call, the interface call requests of the same type may come from different clients.

[0046] High-frequency users refer to clients that send more API call requests than a preset number of times within a preset time period.

[0047] The preset time period, preset request threshold, and preset number of transmissions can be preset by those skilled in the art based on experience.

[0048] In some embodiments, the processor may generate interface request statistics based on historical interface request parameters; and determine high-frequency requests and / or high-frequency users based on the interface request statistics.

[0049] Historical API request parameters refer to the API request parameters corresponding to multiple historical API call requests sent by the client within a preset time period. Historical API call requests refer to API call requests that the client has sent in the past.

[0050] Each historical API call request corresponds to a request record. Request record information includes historical API request parameters, the cumulative number of historical API call requests for each request type within different request types, or the number of historical API call requests for each client across different clients. API request statistics refer to information obtained by aggregating a large amount of request record information. API request statistics can include, within a preset time period, the cumulative number of historical API call requests for each request type within different request types, or the number of historical API call requests for each client across different clients, and the time distribution of different historical API call requests.

[0051] In some embodiments, the processor can perform statistics on the request record information corresponding to historical interface call requests to obtain interface request statistics.

[0052] In some embodiments, the processor may further divide the preset time period into multiple sub-time periods. For each sub-time period, based on interface request statistics, the total number of historical interface call requests corresponding to each request type is counted. The total number of historical interface call requests corresponding to each request type is compared with a preset request threshold. If the total number of historical interface call requests corresponding to a certain request type is greater than the preset request threshold, then the historical interface call requests corresponding to that request type are identified as high-frequency requests in the corresponding sub-time period. Similarly, in different sub-time periods, clients that send more than a preset number of historical interface call requests are identified as high-frequency users in the corresponding sub-time period. Multiple sub-time periods may include sub-time periods corresponding to weekdays, holidays, working hours, and off-hours. The call request instructions temporarily stored in the cache component may be different in different sub-time periods.

[0053] In some embodiments, the processor can further determine, based on interface request statistics, the type of historical interface call requests at different time points, the client to which the historical interface call requests belong, and the number of historical interface call requests; based on the type of historical interface call requests at different time points, the client to which the historical interface call requests belong, and the number of historical interface call requests, perform clustering to determine the time periods corresponding to high-frequency requests and / or the time periods corresponding to high-frequency users; and based on the time points corresponding to the interface call requests and the time periods corresponding to high-frequency requests and / or high-frequency users, determine whether an interface call request is a high-frequency request and / or a high-frequency user. The time period corresponding to a high-frequency user refers to the time interval between the maximum and minimum time points corresponding to historical interface call requests within a specific cluster obtained through clustering. A specific cluster refers to a cluster obtained by grouping specific clients into one class. A specific client refers to a client that sends historical interface call requests more than a preset number of times.

[0054] In some embodiments, the processor can cluster historical interface call requests of the same type and whose corresponding time points fall within a preset time interval into a single cluster. Within each cluster, the processor identifies clusters where the number of historical interface call requests exceeds a preset request threshold, and defines the time interval between the maximum and minimum time points corresponding to the historical interface call requests within that cluster as the time period corresponding to high-frequency requests. Furthermore, if the time point corresponding to an interface call request falls within the time period corresponding to high-frequency requests, then that interface call request is considered a high-frequency request. The preset time interval can be preset by those skilled in the art based on experience. The number of historical interface call requests in a cluster can be equivalent to the number of historical interface call requests obtained from clustering within that cluster.

[0055] In some embodiments, the processor may determine high-frequency users using a method similar to that used to determine high-frequency requests.

[0056] In some embodiments, the caching component includes a cache database, and the processor can also control the front-end invocation component to determine the invocation request instruction that matches the interface invocation request by querying the cache database based on the interface request parameters.

[0057] The cache database includes the mapping between various reference interface request parameters and reference call request instructions. In some embodiments, the cache database can be constructed based on prior knowledge or historical data.

[0058] In some embodiments of this specification, by setting up a caching component, the call request instructions that may be frequently used corresponding to the interface request parameters at the current time point can be retrieved from the cache database in advance, which can improve the running speed.

[0059] Step 230: Control the front-end retrieval component to receive the interface request metadata sent by the client according to the call request instruction, and encrypt the interface request metadata to generate the first ciphertext.

[0060] API request metadata refers to information that records the specific content of a user's request. For example, API request metadata may include details about a user's login request.

[0061] In some embodiments, the processor can control the front-end invocation component to receive interface request metadata sent by the client according to the invocation request instruction.

[0062] The first ciphertext refers to the encrypted metadata of the interface request.

[0063] In some embodiments, the processor can control the front-end invocation component to obtain interface request metadata from the interface invocation request sent by the client according to the invocation request instruction; and to encrypt the interface request metadata to generate a first ciphertext. The encryption method may include Base64 encryption and decryption methods, DES encryption and decryption methods, etc.

[0064] In some embodiments, the processor may determine whether to enable the backend security component. In response to enabling the backend security component, the processor controls the frontend retrieval component to send the first ciphertext generated after encrypting the interface request metadata to the backend security component via a WebSocket connection, and performs steps 240-280 as follows; and in response to not enabling the backend security component, the processor directly sends the interface request metadata without encryption to the backend service component.

[0065] Backend service components can be used to provide feedback related to API call requests. Backend service components can be configured on a server.

[0066] For example, backend service components can be used to provide feedback on services related to user login, services related to user data queries, etc.

[0067] For instructions on how to determine whether backend security components are enabled, please see the following text. Figures 3-4 The explanation in the document.

[0068] Step 240: Receive the first ciphertext through the backend security component, and decrypt the first ciphertext to regenerate the interface request metadata.

[0069] Decryption methods can include Base64 encryption / decryption, DES encryption / decryption, etc.

[0070] Step 250: In response to the fulfillment of the preset call conditions, the interface request metadata is sent to the backend service component through the backend security component.

[0071] Preset invocation conditions can be predetermined by those skilled in the art based on experience. For example, preset invocation conditions may include a valid user login identifier and no abnormalities in the interface request parameters. A valid user login identifier may include the user's login account and password matching without any abnormal behavior. No abnormalities in the interface request parameters may include the virtual address in the interface request parameters not being an invalid address.

[0072] Step 260: Receive feedback data from the backend service component through the backend security component, and encrypt the feedback data to generate a second ciphertext.

[0073] Feedback data refers to the data returned to the user in response to an API call request. For example, feedback data may include results related to login, data queries, and data analysis.

[0074] The second ciphertext refers to the encrypted feedback data. The processor can generate the second ciphertext using a similar method as that used to generate the first ciphertext.

[0075] Step 270: Receive the second ciphertext through the front-end call component and decrypt it to regenerate the feedback data.

[0076] The processor can use a similar method as the decryption of the first ciphertext to decrypt the second ciphertext and generate feedback data.

[0077] Step 280: Send the feedback data to the client by calling the front-end component.

[0078] In some embodiments, the processor can invoke components through the front end and send feedback data to the client via WebSocket communication.

[0079] In some embodiments, the processor can update the client's user interface based on feedback data. For example, the user interface can be updated to display a message indicating successful login or showing data query results.

[0080] In some embodiments of this specification, the interface call requests sent by the user through the client are processed by the protection component before reaching the backend service component for data interaction. This hides all the original API interfaces behind the backend security component of the protection component, so that only the WebSocket communication interface is exposed to threat attackers. Attackers cannot directly access the backend service component, and therefore cannot use existing attack tools to attack the backend service component. This greatly increases the attack cost for threat attackers and improves the security of the backend service component.

[0081] Figure 3 This is an exemplary flowchart illustrating how to determine whether to enable backend security components, based on some embodiments of this specification. Figure 3 As shown, process 300 includes steps 310-320. In some embodiments, process 300 may be executed by processor 110 controlling protection component 120.

[0082] Step 310: Based on the interface request parameters 311 and interface request metadata 312 corresponding to the interface call request, determine the security value 313 corresponding to the interface call request.

[0083] For explanations regarding API request parameters and API request metadata, please refer to [link / reference]. Figure 2 The relevant explanations are in the text.

[0084] A security value is a numerical value that reflects the security level of an API call request. Security values ​​can be represented by a number between 0 and 1; the higher the value, the more secure the API call request is, and the lower the possibility or risk of attacking the server.

[0085] In some embodiments, the processor can determine the security value corresponding to an interface call request based on the interface request parameters and interface request metadata, using a security table. In some embodiments, the security table includes multiple different correspondences between reference interface request parameters, reference interface request metadata, and reference security values. One reference interface call request corresponds to one reference interface request parameter, one reference interface request metadata, and one reference security value. In some embodiments, the security table can be constructed based on historical server interception data, attack data, and blacklist data from other platforms on the Internet.

[0086] For example, the processor can classify historical attack parameters (representing request type, request time, virtual address, and geographical location) into different security values ​​based on the severity of the attack. Thus, when a particular virtual address or geographical location frequently sends phishing messages, but requests from these addresses or locations cannot be completely blocked, a security value can be evaluated to determine whether to enable backend security features.

[0087] In some embodiments, the processor may also determine the security value corresponding to the interface call request based on the interface request parameters and interface request metadata corresponding to the interface call request, through a protection model.

[0088] In some embodiments, the protection model is a machine learning model. In some embodiments, the protection model may be a neural network (NN) model or a deep neural network (DNN) model.

[0089] In some embodiments, the input of the protection model includes the interface request parameters and interface request metadata corresponding to the interface call request, and the output includes the security value corresponding to the interface call request.

[0090] In some embodiments, the inputs to the protection model also include the number of API call requests made by the same client.

[0091] In some embodiments, the protection model can be trained based on multiple labeled training samples.

[0092] In some embodiments, each training sample may include sample interface request parameters and sample interface request metadata corresponding to the sample interface call request. Training samples can be constructed based on sample interface call requests. The processor can parse the sample interface call request through the user terminal to obtain the sample interface request parameters and sample interface request metadata. For instructions on how to obtain sample interface request parameters and sample interface request metadata, please refer to [link to documentation]. Figure 2 The relevant explanations are in the text.

[0093] In some embodiments, the tag may be a security value corresponding to a sample API call request.

[0094] In some embodiments, the tag is related to whether the sample interface call request is a high-frequency request or whether the sample interface call request is a request issued by a high-frequency user. For example, the security value of the sample interface call request corresponding to high-frequency requests and high-frequency users can be preset to a relatively high value.

[0095] Tags can be obtained through manual labeling. For example, those skilled in the art can determine the statistical number of sample call requests of the same type that have been intercepted by the server or have engaged in server attacks based on the request type, virtual address, geographical location, etc., corresponding to the sample call requests; and manually label the requests based on the statistical number and whether the sample interface call requests are high-frequency requests or requests issued by high-frequency users.

[0096] For example, if the virtual address of a sample API call request has not historically been intercepted or used to attack the server, but is not a high-frequency request or a request from a high-frequency user, its manually assigned security value can be 0.6. Conversely, if the virtual address of a sample API call request has historically been used to attack the server, its security value will not be preset to the highest value. Furthermore, if a client is sending an API call request for the first time (i.e., the client is not a high-frequency user), the security value for that client's sample API call request will be preset to a relatively low value.

[0097] In some embodiments, the processor can acquire one or more training samples and the label corresponding to each training sample; perform multiple iterations, and terminate the iteration when the iteration termination condition is met, thus obtaining a trained protection model. Each iteration includes: selecting a training sample from the training samples, inputting the training sample into the initial protection model, and obtaining the predicted output of the initial protection model corresponding to the training sample; calculating the value of the loss function by substituting the predicted output and the label of the training sample into a predefined loss function formula; and updating the model parameters in the initial protection model in reverse based on the value of the loss function. Updating the model parameters in the protection model in reverse can be performed using various methods. For example, the model parameters in the initial protection model can be updated in reverse based on the gradient descent method. The iteration termination condition may include the number of iterations reaching a threshold, etc.

[0098] In some embodiments of this specification, the processor can quickly obtain a reasonable security value corresponding to an interface call request through a trained protection model.

[0099] Step 320: Based on security value 313 and security value threshold 321, determine whether to enable backend security component 322.

[0100] A safety threshold refers to a critical value for safety. The safety threshold used for the first time can be preset by those skilled in the art based on experience.

[0101] In some embodiments, the processor can update the security threshold at preset time intervals to obtain the updated security threshold. Thus, when the server is subjected to intensive attacks (i.e., when the average security value may decrease significantly), the security threshold is automatically increased to enable backend security components for more API call requests; when the server is subjected to fewer attacks (i.e., when the average security value may increase significantly), the security threshold is decreased to enable backend security components for fewer API call requests, reducing the server hardware load.

[0102] In some embodiments, the updated security threshold is related to the average security value over the most recent preset time period.

[0103] The average security value refers to the average security value of all API call requests received by the front-end component within a preset time period.

[0104] The most recent preset time period refers to the time interval between the current update of the security threshold and the previous update. The length of the most recent preset time period can be determined in various ways. For example, the length of the most recent preset time period can be preset by those skilled in the art based on experience. For instance, the most recent preset time period could be 5 minutes prior to the time of the API call request. The length of the preset time period reflects the update frequency of the security threshold.

[0105] In some embodiments, the length of the preset time period is related to the request density of the interface call requests.

[0106] Request density refers to the number of API call requests received per second by the front-end invocation component.

[0107] In some embodiments, the higher the request density, the shorter the preset time period can be. By way of example only, the processor may use the following first algorithm to determine the adjusted length of the preset time period: The adjusted preset time period length = original length (1 - Request density of the most recent preset time period / Request density of the previous preset time period). The previous preset time period refers to the time interval between the last update of the security threshold and the update of the security threshold two years prior. The original length refers to the length of the preset time period after the last update. The original length of the preset time period used for the first time can be preset by those skilled in the art based on experience.

[0108] In some embodiments of this specification, the length of the preset time period is correlated with the request density. The update frequency of the security value threshold can be dynamically adjusted according to the number of interface call requests, so as to ensure the protection effect while avoiding excessive increase in the server load.

[0109] In some embodiments, the processor may employ the following second algorithm to determine the updated security threshold: Updated security threshold = original security threshold (1 - Average security value of the most recent preset period / Average security value of the previous preset period). The original security value threshold refers to the security value threshold after the last update. The original security value threshold set for the first time can be preset by those skilled in the art based on experience.

[0110] In some embodiments of this specification, the security threshold is updated every preset time period, which can better dynamically adjust whether to enable backend security components.

[0111] In some embodiments, the processor can compare the security value corresponding to the interface call request with a security value threshold, and determine to enable the backend security component in response to the security value corresponding to the interface call request being lower than the security value threshold.

[0112] In some embodiments, the backend security component is configured to perform protective processing on subsequent API call requests.

[0113] In some embodiments, the backend security component has a plug-in module structure, and its activation is controlled by the processor.

[0114] A plug-in modular architecture allows software to enhance or extend the functionality of backend security components by loading specific plug-ins.

[0115] In some embodiments of this specification, a determination is made on whether to enable backend security components based on security values ​​and security value thresholds, so as to ensure server security while minimizing additional feedback delays caused by WebAPI security management.

[0116] In addition, the backend security components are designed with a minimally invasive plug-in modular structure, which improves server security and allows for targeted security protection, while also being easy to start and stop.

[0117] Figure 4 This is another exemplary flowchart illustrating the determination of whether to enable backend security components, based on some embodiments of this specification. Figure 4 As shown, process 400 includes steps 410-440. In some embodiments, process 400 may be executed by processor 110 controlling protection component 120.

[0118] Step 410: Based on the interface call request, estimate the waiting time corresponding to the execution of the protection process.

[0119] The protection process refers to the protective handling procedure of the protection component for API call requests. For a description of API call requests, please refer to [link to relevant documentation]. Figure 2 The explanation in step 210.

[0120] Waiting time refers to the time between when a user sends an API call request and when the user's client receives the response data from the server. If the waiting time is too long, the user may resend the API call request through the client.

[0121] In some embodiments, the waiting time includes the time required to execute the invocation request instruction, the encryption process, and the decryption process.

[0122] In some embodiments, the processor can estimate the waiting time for executing the protection process based on the interface request parameters, interface request metadata, and whether the interface call request is a high-frequency request, through a waiting schedule.

[0123] The waiting timetable includes the reference interface request parameters, reference interface request metadata, and the correspondence between whether the reference interface request is a high-frequency request and the estimated reference waiting time for the execution of the protection process. For instructions on how to determine whether a reference interface request is a high-frequency request, please refer to [link to documentation / reference]. Figure 2 The relevant instructions in step 220.

[0124] The waiting time can be determined based on historical API processing data. Historical API processing data refers to data related to historical API call requests. This data may include API request parameters, high-frequency attributes of historical API call requests, and the average historical waiting time for metadata of the same type of API request. High-frequency attributes of historical API call requests can be used to characterize whether a historical API call request belongs to or is not a high-frequency request. For methods on determining whether a historical API call request belongs to or is not a high-frequency request, please refer to [link to relevant documentation]. Figure 2 The explanation in step 220.

[0125] For example, the processor can construct a waiting time table by matching the same interface request parameters, the high-frequency attributes of historical interface call requests, and the historical waiting time average corresponding to the same type of interface request metadata in the historical interface processing data.

[0126] Step 420: After receiving the interface call request from the client, obtain the number of target interface call requests from the client and the interval time.

[0127] The target API call request refers to an API call request that meets preset conditions. The preset conditions can be API call requests of the same type sent by the same client within a preset time period.

[0128] The number of target interface call requests refers to the total number of interface call requests of the same request type sent by the same client up to the current moment.

[0129] Interval time refers to the time interval between the current target interface call request and the previous target interface call request in the same type of interface call requests sent by the same client.

[0130] In some embodiments, the number of times and the interval between each target interface call request of the same client can be represented by a vector, such as (request 1, number 1, request type (e.g., login request), request time (10:04:24), interval 0 seconds; request 2, number 2, request type (e.g., login request), request time (10:04:53), interval 29 seconds; ...).

[0131] In some embodiments, after receiving an interface call request from a client, the processor can determine the number of target interface call requests from the same client and the interval between them based on the interface request parameters corresponding to all interface call requests sent by the same client.

[0132] Step 430: Based on the number of times and the interval, assess the impact of the waiting time on the user.

[0133] The degree of impact can characterize how much users dislike a certain waiting time. In some embodiments, the degree of impact can be represented numerically; the larger the value, the more disliked the user is during that waiting time, and the more likely they are to resend the API call request on the same client.

[0134] In some embodiments, the more times the intervals are longer, the greater the impact of the waiting time on the user. As an example only, the processor may employ the following third algorithm to determine the impact of the waiting time on the user: The degree of impact of waiting time on users k= ,in, It refers to the first One API call request, This refers to the total number of API call requests of the same request type as the current API call request issued by this client; It is the time interval between the current interface call request and the most recent target interface call request among interface call requests of the same request type as the current interface call request issued by the client; a1 is the first preset coefficient; e is an irrational number. The preset coefficient can be preset by those skilled in the art based on experience.

[0135] In some embodiments, the processor may also assess the impact of the waiting time on the user based on the number of times, the interval, whether the user is a high-frequency client and / or whether the target interface call request is a high-frequency request.

[0136] In some embodiments, the processor may, in response to the user being a high-frequency client and / or the target interface call request being a high-frequency request, adjust the value of the first preset coefficient a1 in the aforementioned third algorithm to a larger second preset coefficient a2, and then evaluate the degree of impact of the waiting time on the user according to the aforementioned third algorithm.

[0137] In some embodiments, the processor may employ the following fourth algorithm to determine the second preset coefficient a2: The second preset coefficient a2 = a1 (1 + number of times the target interface is called / 100).

[0138] In some embodiments of this specification, when determining the degree of impact, it is also considered whether the user is a high-frequency customer and / or whether the target interface call request is a high-frequency request. This can effectively ensure the user experience of high-frequency users and avoid causing user resentment while ensuring server security.

[0139] Step 440: Based on the degree of impact, determine whether to enable backend security components.

[0140] In some embodiments, the processor can compare the degree of impact with a preset threshold for the degree of impact. If the degree of impact is greater than the preset threshold, the backend security component is not enabled; otherwise, the backend security component is enabled. The threshold for the degree of impact can be preset by those skilled in the art based on experience. For example, the threshold for the degree of impact can be the maximum value among the degree of impacts corresponding to the clients of historical interface call requests that were attacked or intercepted by the server, based on historical interface processing data.

[0141] In some embodiments, the processor may also determine whether to enable backend security features based on the degree of impact and security values.

[0142] In some embodiments, the processor may use the product of the impact level and the security value as the corrected security value; and in response to the corrected security value being less than a security value threshold, determine to enable the backend security component, otherwise disable the backend security component. For further information on security values ​​and security value thresholds, please refer to [link to relevant documentation]. Figure 3 The explanation in the document.

[0143] In some embodiments of this specification, by assessing the impact of waiting time on users, it is possible to effectively assess whether there is a risk of the client potentially attacking the server, and thus decide whether to enable backend security components, so as to provide reasonable security protection while avoiding affecting the experience of non-malicious users.

[0144] In addition, before deciding whether to enable backend security components, besides assessing the security of the target interface call request, it is also necessary to reasonably assess the impact of the latency (i.e., waiting time) caused by enabling backend security components on the client. This allows for targeted application of backend security components for protection, reducing the probability of the server being successfully attacked, while avoiding impacting the user experience of normal users.

[0145] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0146] Furthermore, this specification uses specific terms to describe embodiments thereof. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Moreover, certain features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.

[0147] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on existing servers or mobile devices.

[0148] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.

[0149] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of range in some embodiments of this specification are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

[0150] For each patent, patent application, patent application publication, and other material such as articles, books, specifications, publications, and documents referenced in this specification, the entire contents of which are incorporated herein by reference. This excludes historical application documents that are inconsistent with or conflict with the content of this specification, as well as documents that limit the broadest scope of the claims in this specification (currently or subsequently appended to this specification). It should be noted that in the event of any inconsistency or conflict between the descriptions, definitions, and / or terminology used in the supplementary materials to this specification and the content of this specification, the descriptions, definitions, and / or terminology used in this specification shall prevail.

[0151] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.

Claims

1. A WebAPI security management method, characterized in that, The WebAPI security management method is executed by a processor-controlled protection component, which includes a front-end invocation component and a back-end security component. The method includes: The front-end invocation component receives the interface call request sent by the client and obtains the number of target interface call requests and the interval time from the client; the interface call request corresponds to the interface request parameters, and the target interface call request is the interface call request that meets the preset conditions; The front-end invocation component is controlled to determine the invocation request instruction that matches the interface invocation request based on the interface request parameters; The front-end invocation component is controlled to receive the interface request metadata sent by the client according to the invocation request instruction, and to encrypt the interface request metadata to generate a first ciphertext; Based on the number of times, the interval time, whether the user is a high-frequency user and / or whether the target interface call request is a high-frequency request, assess the impact of the waiting time corresponding to the execution of the protection process on the user; Based on the degree of impact, determine whether to activate the backend security component; In response to activating the backend security component, the first ciphertext is received through the backend security component, and the first ciphertext is decrypted to regenerate the interface request metadata; In response to the fulfillment of preset invocation conditions, the interface request metadata is sent to the backend service component through the backend security component; The backend security component receives feedback data from the backend service component and encrypts the feedback data to generate a second ciphertext. The second ciphertext is received and decrypted by the front-end invocation component to regenerate the feedback data; and The feedback data is sent to the client via the front-end retrieval component.

2. The WebAPI security management method according to claim 1, characterized in that, The front-end retrieval component further includes a caching component, which is configured to cache the call request instructions corresponding to the high-frequency requests and / or the interface call requests of the high-frequency users; The step of controlling the front-end invocation component to determine the invocation request instruction matching the interface invocation request based on the interface request parameters includes: In response to the identification of the high-frequency request or the high-frequency user, the front-end invocation component is controlled to determine, through the caching component, the invocation request instruction corresponding to the interface invocation request of the high-frequency request and / or the high-frequency user, based on the interface request parameters.

3. The WebAPI security management method according to claim 1, characterized in that, The method further includes: Based on the interface call request, the estimated waiting time corresponding to the execution of the protection process is calculated. The waiting time includes the waiting time corresponding to the execution of the call request instruction, the encryption process, and the decryption process.

4. The WebAPI security management method according to claim 1, characterized in that, The process of determining whether to enable the backend security component based on the degree of impact includes: Based on the degree of impact and the security value corresponding to the interface call request, determine whether to enable the backend security component.

5. The WebAPI security management method according to claim 4, characterized in that, The process of determining whether to enable the backend security component based on the degree of impact further includes: Based on the interface request parameters corresponding to the interface call request, the interface request metadata, and the number of interface call requests issued by the same client, a security value corresponding to the interface call request is determined through a protection model, wherein the protection model is a machine learning model.

6. The WebAPI security management method according to claim 1, characterized in that, The backend security component has a plug-in module structure, and its activation is controlled by the processor.

7. A WebAPI security management system, characterized in that, The system includes a processor and a protection component, the processor and the protection component being electrically connected, the protection component including a front-end access component and a back-end security component; the processor is configured to: The front-end invocation component receives the interface call request sent by the client and obtains the number of target interface call requests and the interval time from the client. The interface call request corresponds to interface request parameters, and the target interface call request is the interface call request that meets the preset conditions; The front-end invocation component is controlled to determine the invocation request instruction that matches the interface invocation request based on the interface request parameters; The front-end invocation component is controlled to receive the interface request metadata sent by the client according to the invocation request instruction, and to encrypt the interface request metadata to generate a first ciphertext; Based on the number of times, the interval time, whether the user is a high-frequency user and / or whether the target interface call request is a high-frequency request, assess the impact of the waiting time corresponding to the execution of the protection process on the user; Based on the degree of impact, determine whether to activate the backend security component; In response to activating the backend security component, the first ciphertext is received through the backend security component, and the first ciphertext is decrypted to regenerate the interface request metadata; In response to the fulfillment of preset invocation conditions, the interface request metadata is sent to the backend service component through the backend security component; The backend security component receives feedback data from the backend service component and encrypts the feedback data to generate a second ciphertext. The front-end retrieval component receives the second ciphertext and decrypts it to regenerate the feedback data. as well as The feedback data is sent to the client via the front-end retrieval component.

8. The system according to claim 5, characterized in that, The front-end retrieval component further includes a caching component, which is configured to cache the call request instructions corresponding to the high-frequency requests and / or the interface call requests of the high-frequency users; The processor is further configured to: In response to the identification of the high-frequency request or the high-frequency user, the front-end invocation component is controlled to determine, through the caching component, the invocation request instruction corresponding to the interface invocation request of the high-frequency request and / or the high-frequency user, based on the interface request parameters.

9. A WebAPI security management device, characterized in that, The device includes at least one processor and at least one memory; The at least one memory is used to store computer instructions; The at least one processor is used to execute at least a portion of the computer instructions to implement the WebAPI security management method as described in any one of claims 1 to 4.

10. A computer-readable storage medium, characterized in that, The storage medium stores computer instructions. When the computer reads the computer instructions from the storage medium, the computer executes the WebAPI security management method as described in any one of claims 1 to 4.

Images