A method for managing application interfaces

Abstract

The application discloses a kind of management methods of application interface, it is related to information security technical field.The method is by responding to first access request, generates first signature information and first code file, first access request is generated by client when first calling first interface, and first code file is associated with client;Response content carrying first code file is generated, and response content is fed back to client, so that client carries out interface signature based on first code file, and generates second access request based on signature result;In response to second access request, when determining that client has calling authority relative to first interface, allow client to call first interface, and calling authority is determined based on second access request and first signature information.Utilize the method, the convenience and applicability of deployment are improved, and the risk of signature result is cracked is reduced, and the security of application interface in calling process is improved.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a method for managing application interfaces. Background Technology

[0002] With the rapid development of Internet technology, the application programming interface (API) is being used in more and more widespread scenarios. At the same time, network attacks targeting API interfaces are becoming more and more frequent. Among them, message tampering and replay attacks are the most common attack methods, which seriously threaten the security of API interface calls.

[0003] In existing technologies, key signatures are primarily used to secure API interfaces. Existing API interface signature protection solutions mainly fall into two categories: one is to provide developers with key signature capabilities through the development of a Software Development Kit (SDK), allowing developers to integrate the SDK into the client and complete the signature-related development and adaptation; the other is to distribute pre-generated fixed signature information through a generic configuration to the front-end page, which then directly performs the signature operation.

[0004] However, SDK-based signature schemes require developers to perform extensive integration and adaptation work, resulting in high development costs and difficulties in deployment. More importantly, SDK-based signature schemes are not suitable for web applications. For schemes that use fixed signature information for front-end pages, attackers may still be able to crack the signature method through reverse engineering, message analysis, and other means, thereby forging legitimate signatures to launch message tampering and replay attacks, making the security protection of API interfaces vulnerable to being compromised. Summary of the Invention

[0005] This invention provides a method for managing application interfaces, which solves the problems of difficulty in deployment and vulnerability to hacking in existing methods for managing application interfaces.

[0006] In a first aspect, embodiments of the present invention provide a method for managing application interfaces, applied to a server, the method comprising: In response to the first access request, first signature information and a first code file are generated. The first access request is generated by the client when it first calls the first interface, and the first code file is associated with the client. Generate response content carrying the first code file and send the response content back to the client, so that the client can perform interface signing based on the first code file and generate a second access request based on the signing result; In response to the second access request, when it is determined that the client has the right to call the first interface, the client is allowed to call the first interface, and the calling permission is determined based on the second access request and the first signature information.

[0007] Secondly, embodiments of the present invention provide another method for managing application interfaces, applied to a client, the method comprising: In response to the first call operation to the first interface, a first access request is generated and sent to the server, so that the server generates response content based on the first access request; In response to the response content, the response content is parsed to obtain a first code file, a second access request is generated based on the first code file, and the second access request is sent to the server to obtain the calling permission relative to the first interface.

[0008] The technical solution of this invention, in response to a first access request, generates first signature information and a first code file. The first access request is generated by the client when it first calls the first interface, and the first code file is associated with the client. A response content carrying the first code file is generated and fed back to the client, enabling the client to sign the interface based on the first code file and generate a second access request based on the signature result. In response to the second access request, if it is determined that the client has the right to call the first interface, the client is allowed to call the first interface, with the calling permission determined based on the second access request and the first signature information. Using this method, by dynamically generating the first signature information and the first code file corresponding to the client, and generating a response content carrying the first code file to feed back to the client, the client can perform a dedicated interface signature based on the first code file, improving the convenience and applicability of deployment. Furthermore, by verifying the client's calling permission based on the second access request carrying the signature result and the first signature information associated with the client, compared to existing schemes that use fixed signature information, this solution reduces the risk of signature cracking and improves the security of the application interface during the calling process.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0011] Figure 1 A flowchart illustrating an application interface management method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating another application interface management method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an application interface management device provided in an embodiment of the present invention; Figure 4 A schematic diagram of the structure of a management device for another application interface provided in an embodiment of the present invention; Figure 5 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation

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

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0014] It is understood that before using the technical methods disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0015] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as the electronic device, application, server, or storage medium performing the operations of this disclosed technology.

[0016] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0017] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0018] Specifically, embodiments of the present invention provide a method for managing application interfaces. Figure 1 This is a flowchart of an application interface management method provided by an embodiment of the present invention. The embodiment of the present invention can be applied to scenarios where application programming interfaces are protected. The method can be executed by an application interface management device configured on the server. The device can be implemented in the form of software and / or hardware, and optionally, it can be implemented by an electronic device, preferably a desktop computer, a laptop computer, or a server.

[0019] like Figure 1 As shown, the application interface management method provided in this embodiment of the invention may specifically include: S101. In response to the first access request, generate first signature information and first code file. The first access request is generated by the client when it first calls the first interface, and the first code file is associated with the client.

[0020] The first access request can be understood as a request to obtain the signature capability of a dedicated interface, containing the client's identification information. The first interface can be considered as the API interface provided by the server that the client wants to call, and this interface is configured with access rules related to signature authentication. The first signature information can be understood as a set of rules used to generate a valid signature result. For example, the first signature information may include a first signature element, a first separator, a first key, a first signature algorithm, and a signature element sorting method. The first code file can be understood as a code file generated for the client, used to execute on the client (such as a browser) to enable the client to generate a valid signature result. The first code file includes the first signature information and code used to execute and update the first signature information.

[0021] In this embodiment, when the client first calls the first interface, a first access request is generated on the client and sent to the server. In response to the received first access request, the server generates personalized first signature information for the client, such as randomly selecting a first signature element and a first separator. The first signature information can be associated with and stored with the client's identification information, such as storing the first signature information in a one-to-one correspondence with the client's IP address, ensuring that each client has unique first signature information. Optionally, a high-performance, low-latency database or caching system can be used for storage. Furthermore, based on the first signature information, code is generated that can execute logic for signing the interface based on the first signature information. Code that dynamically updates the first signature information using a preset communication protocol can also be added to this code, thus forming a first code file.

[0022] S102. Generate response content carrying the first code file and send the response content back to the client so that the client can sign the interface based on the first code file and generate a second access request based on the signing result.

[0023] The second access request can be understood as a request initiated by the client after obtaining the first code file, used to prove its identity to the server in order to apply for actual access to the interface.

[0024] In this embodiment, one way to generate response content carrying the first code file is to: parse the HTML content of the response body to generate a DOM tree; and embed the first code file into the DOM tree. <header>Within the `<meta>` tag, the modified DOM tree is restored to generate response content carrying the first code file. After generating the response content carrying the first code file, the response content is sent back to the client, enabling the client to perform interface signing based on the first code file, obtain the signature result, and generate a second access request carrying the signature result.

[0025] S103. In response to the second access request, when it is determined that the client has the right to call the first interface, the client is allowed to call the first interface, and the right to call is determined based on the second access request and the first signature information.

[0026] In this embodiment, in response to a second access request sent by the client, the system can verify the client's authorization to call the first interface by combining the signature result carried in the second access request and the element value obtained relative to the first signature information, along with the first signature information stored on the server corresponding to the client's identification information. If it is determined that the client has authorization to call the first interface, the client is allowed to call the first interface and execute the business logic corresponding to the first interface; otherwise, if it is determined that the client does not have authorization to call the first interface, the client's call to the interface is denied. For example, denying the client's call to the interface can be achieved by using traffic control tools and middleware to intercept and route traffic.

[0027] Understandably, when the client subsequently calls the first interface, it can directly sign the interface based on the first code file and generate a second access request based on the signature result.

[0028] The application interface management method provided in this invention generates first signature information and a first code file in response to a first access request. The first access request is generated by the client when it first calls the first interface, and the first code file is associated with the client. A response content carrying the first code file is generated and fed back to the client, enabling the client to sign the interface based on the first code file and generate a second access request based on the signature result. In response to the second access request, if it is determined that the client has the right to call the first interface, the client is allowed to call the first interface. The calling permission is determined based on the second access request and the first signature information. This method dynamically generates the first signature information and the first code file corresponding to the client, and generates a response content carrying the first code file to feed back to the client. This allows the client to perform a dedicated interface signature based on the first code file, improving deployment convenience and applicability. Furthermore, by verifying the client's calling permission based on the second access request carrying the signature result and the first signature information associated with the client, compared to existing schemes that use fixed signature information, this scheme reduces the risk of signature cracking and improves the security of the application interface during the calling process.

[0029] As a first optional embodiment of the present invention, based on the above embodiments, the first code file includes a first sub-code for updating the first signature information based on the target communication protocol.

[0030] It should be noted that even with the generation of a personalized first sub-code associated with the client, if the first signature information in the first sub-code is permanent and fixed, there is still a risk of it being cracked, and once cracked, the signature can be forged for a long time. Therefore, in this embodiment, a first sub-code can be pre-installed in the first code file that can receive new signature information through the target communication protocol and update the existing first signature information using the new signature information. This allows the server to proactively and periodically update the signature information, and the client, after receiving the first code file once, can automatically receive and replace the new signature information through the received first sub-code, thereby improving the user experience and further enhancing the security of the application interface during the call process.

[0031] Accordingly, the method can be further optimized to include: a1) When it is determined that the current conditions for updating signature information are met, generate the second signature information corresponding to the client.

[0032] The second signature information can be considered as the latest signature information generated by the corresponding client, used to replace and update the first signature information. The second signature information has the same structure as the first signature information, both including a first signature element, a first separator, a first key, a first signature algorithm, and a signature element sorting method, but the specific parameters are changed. For example, the first signature element may have a browser fingerprint element and / or an HTTP protocol element added to it, or the specific parameters of at least one of the first separator, the first key, the first signature algorithm, and the signature element sorting method may be changed.

[0033] In this embodiment, signature information update conditions can be dynamically set according to the business scenario. For example, signature information update conditions may include reaching a preset period or the client calling a new first interface. When it is determined that the signature information update conditions are met, new first signature information is generated for the client, recorded as second signature information, and saved. When the preset conditions are met (such as when the client calls a new first interface to request a new page), the second signature information replaces the original first signature information stored associated with the client.

[0034] b1) The second signature information is sent to the client through the target communication protocol, so that the client receives the second signature information based on the first sub-code and updates the first signature information in the first code file.

[0035] For example, the target communication protocol could be WebSocket, used to establish a persistent connection between the client and the server for real-time data transmission.

[0036] In this embodiment, the second signature information is sent to the client via the target communication protocol. In this way, the client can actively push the second signature information to the server without requiring the client to actively request it. The client's first sub-code can listen to messages of the target communication protocol in real time. Upon receiving the second signature information, it automatically replaces the first signature information built into the first code file with the second signature information based on the execution logic contained in the first sub-code. Optionally, the replacement can be performed when the client requests a new page (i.e., calls a new first interface).

[0037] It is known that after updating the first signature information in the first code file, when the client subsequently calls the first interface, it will perform interface signing based on the updated first code file to generate a second access request carrying a valid signature result, until the first code file is updated again.

[0038] The above-described technical solution in this embodiment, based on the first sub-code included in the first code file, enables flexible, convenient, and proactive updating of the first signature information after it has been issued. This improves the security and flexibility of the first signature information, thereby enhancing the security of the application interface. Furthermore, the updating process of the first signature information is automatically completed by the first sub-code, improving the user experience and ensuring business continuity.

[0039] As a second optional embodiment of the present invention, based on the above embodiments, the step of generating the first signature information can be specifically optimized as follows: a2) Generate first signature information based on the determined first parameter set.

[0040] The first parameter set includes a first signature element, a first separator, a first key, a first signature algorithm, and a signature element sorting method. The first signature element includes a timestamp element and a monotonically increasing one-time random value element.

[0041] In this embodiment, the method for determining the first signature element can be as follows: a timestamp element and a monotonically increasing one-time random value (nonce value) element are determined as the basic signature elements, and a random selection is made from the candidate signature elements. The selected signature element is then determined as the target signature element, and the basic signature element and the target signature element are determined as the first signature elements. Candidate signature elements may include HTTP protocol elements, such as request URI, request method, HTTP protocol, request headers, and request body; candidate signature elements may also include browser fingerprint elements, such as time zone, screen resolution, browser version, browser window size, browser language settings, browser extensions, operating system, Canvas rendering data, and processor (CPU, GPU, etc.) information. This embodiment does not impose any limitations on these aspects. One implementation for determining the signature element sorting method is to randomly select the sorting order of each first signature element and determine this sorting order as the signature element sorting method. It is understood that each time the first signature element is updated, the first signature element can be reselected and the signature element sorting method can be redefined.

[0042] In this embodiment, the method for determining the first delimiter can be: randomly selecting a delimiter from a pre-determined delimiter list, and determining the selected delimiter as the first delimiter. The method for generating the first key can be: obtaining the client's identification information from the first access request and generating an initial random byte string; hashing the identification information to obtain a processing result; performing a mixed encryption operation between the processing result and the random byte string; and converting the operation result into a standard key format as the first key. The method for determining the first signature algorithm can be: randomly selecting a signature algorithm from a pre-set list of candidate signature algorithms as the first signature algorithm.

[0043] In this embodiment, the determined first signature element, first separator, first key, first signature algorithm, and signature element sorting method are summarized as parameter items to form a first parameter set. Then, the parameter items in the first parameter set are integrated to generate the first signature information. For example, the parameter items in the first parameter set can be integrated into structured data that can be parsed and executed by the first code file, i.e., the first signature information, according to a fixed format (such as JSON, key-value pairs).

[0044] The technical solution described in this embodiment determines a different set of first parameters for each client, making the generated first signature information both exclusive and standardized. This enhances the anti-attack capability and makes signature verification easier, making large-scale automated attacks and large-scale replay attacks impossible. It also has flexible scalability and further reduces the security risks of calling application interfaces.

[0045] As a third optional embodiment of the present invention, based on the above embodiments, the step of generating the first code file can be further optimized to the following steps: a3) Obtain a predefined code template library, which includes an initial signature generation template and a communication code template. The initial signature generation template includes execution logic for generating signature results, and the communication code template includes execution logic for updating signature information.

[0046] In this embodiment, the initial signature generation template may include built-in general execution logic such as collecting element values ​​corresponding to signature information, performing interface signing based on the signature information, and writing request headers. For example, the general execution logic for performing interface signing based on signature information may include a fixed process of first concatenating element values ​​according to the signature element sorting method and delimiters to generate a signature string, and then signing the signature string using a specified signature algorithm. Taking the HMAC-SHA256 signature algorithm as an example, the fixed process of signing the signature string using a specified signature algorithm can be: padding the key to 64 bytes; performing an XOR operation on the key using 0x5c to obtain the inner padding; performing an XOR operation on the key using 0x36 to obtain the outer padding; concatenating the inner padding with the signature string and calculating the SHA256 hash value to obtain the inner hash; intercepting the outer padding and the inner hash, calculating the SHA256 hash value, and obtaining the signature.

[0047] Optionally, the communication code template may include built-in general logic such as monitoring the target communication protocol, receiving update instructions, and triggering signature information replacement.

[0048] b3) Configure the initial signature generation template according to the first signature information, generate the target signature generation template, and integrate the communication code template into the target signature generation template so that the update callback function of the communication code template points to the first signature information replacement entry of the target signature generation template.

[0049] In this embodiment, the first signature information generated for the client is embedded into a specified parameter position of the initial signature generation template to generate a target signature generation template. The target signature generation template can be understood as the initial signature generation template bound to the first signature information, used to generate a valid signature result corresponding to the client. Next, the communication code template is integrated into the target signature generation template, and the update callback function of the communication code template points to the first signature information replacement entry point of the target signature generation template. This allows the communication code template to automatically call the replacement logic to update the first signature information in the target signature generation template when the client receives the second signature information.

[0050] c3) Perform syntax verification and format standardization on the target signature generation template to generate an initial code file; obfuscate the initial code file to generate a first code file.

[0051] The initial code file can be understood as a code file that can be executed normally on the client but has not been hardened.

[0052] In this embodiment, the initial code file can be obfuscated to achieve security hardening. For example, obfuscation methods may include compression, variable name replacement, string obfuscation, control flow obfuscation, dead code insertion, and code equivalence transformation.

[0053] In this embodiment, by customizing the general initial signature generation template and integrating the communication code template into the target signature generation template, the initial code file is generated through standardized processing. This ensures the executableness, reusability, generation efficiency, and client-specificity of the initial code file, and provides support for the generation of signature results and dynamic updating of the first signature information. By obfuscating the initial code file to generate the first code file, the first code file becomes difficult to understand and analyze, increasing the complexity and obfuscation of the code, hindering reverse engineering and code calls, and further improving the security of the application interface.

[0054] As a fourth optional embodiment of the present invention, based on the above embodiments, the step of determining the calling permission based on the second access request and the first signature information can be specified as the following steps: a4) Parse the second access request and obtain the first request header carrying the element value corresponding to the timestamp element; b4) Obtain the timestamp from the first request header and determine the time difference between the timestamp and the current time of the server; c4) If the time difference is greater than or equal to a preset difference threshold, it is determined that the user does not have the permission to call. d4) If the time difference is less than a preset difference threshold, the first signature information corresponding to the client is determined according to the client identification information in the second access request, and the target first request header and the second request header carrying the signature result are obtained according to the first signature information and the second access request; the signature verification information is determined according to the target first request header and the second request header, and the calling permission is determined according to the first signature information and the signature verification information, wherein the signature verification information includes the element value of the first signature element and the signature result.

[0055] It should be noted that the second access request contains multiple first request headers and one second request header. The first request header can be considered as the request header carrying the element value corresponding to the first signature element. For example, the first request header carrying the element value (timestamp) corresponding to the timestamp element could be an X-DATE request header; the first request header carrying the element value (one-time random value) corresponding to the one-time random value element could be an X-NONCE request header; and the first request header carrying the element value corresponding to the browser fingerprint element could be an X-FINGERPRINT request header. The second request header can be considered as the request header carrying the signature result, and could be an Authorization request header.

[0056] In this embodiment, the element value carried by the timestamp element can first be obtained from the first request header, which is the timestamp obtained by the client. Next, the time difference between this timestamp and the server's current time is determined. If the time difference is greater than or equal to a preset difference threshold (e.g., 1 minute), it is determined that the client does not have calling permission relative to the first interface. Conversely, if the time difference is less than the preset difference threshold, the server retrieves the first signature information corresponding to the client's identification information from the server cache based on the client's identification information contained in the second access request; that is, the first signature information corresponding to the client. Then, the corresponding first request header is obtained from the second access request based on the first signature element in the first signature information, and recorded as the target first request header. In addition, a second request header carrying the signature result can also be obtained.

[0057] As described above, after obtaining the target first request header and the second request header, the element values ​​carried in the target first request header and the second request header can be extracted, and verification information for verifying the signature result can be generated based on each element value.

[0058] As one implementation method, based on the above optional embodiments, the determination of calling permissions based on the first signature information and the verification information can be further specified as follows: d41) Generate a verification signature based on the first signature information and the values ​​of each element, and compare the verification signature with the signature result.

[0059] In this context, the verification signature can be understood as a signature used to verify the signature result generated by the client.

[0060] Optionally, generating a verification signature based on the first signature information and each of the element values ​​includes: The element values ​​are sorted according to the sorting method of the signature elements in the first signature information, and the sorted element values ​​are concatenated according to the first separator in the first signature information to generate a verification signature string. The verification signature is obtained by signing the verification signature string according to the first key and the first signature algorithm in the first signature information.

[0061] The above-described technical solution in this embodiment regenerates the verification signature by combining the first signature information stored on the server with the client's identification information and the element value obtained from the second access request. This provides support for the correctness of the subsequent verification signature results and ensures the feasibility and accuracy of the signature verification.

[0062] d42) If the comparison results are inconsistent, it is determined that the user does not have the right to call; if the comparison results are consistent, it is checked whether there is an existing value in the cache that is the same as the one-time random value in the element value; if there is, it is determined that the user does not have the right to call; if there is no such value, it is determined that the user has the right to call, and the one-time random value is written into the cache and its validity period is set.

[0063] In this embodiment, if the comparison results are inconsistent, it is directly determined that the client does not have calling permission relative to the first interface. If the comparison results are consistent, it is possible to check whether the one-time random value carried in the second access request exists in the cache bound to the client identification information. If it exists, it is determined that the client does not have calling permission relative to the first interface; if it does not exist, it is determined that the client has calling permission relative to the first interface. The one-time random value is then saved in the cache, and an expiration period is set, such as 1 minute.

[0064] The technical solution described in this embodiment enhances the security of the application interface by implementing triple verification based on timestamps, signature results, and a one-time random value. Furthermore, the verification based on the one-time random value effectively counters replay attacks through the dual constraints of uniqueness and timeliness.

[0065] In this specific embodiment, the implementation process of the application interface management method is also presented from the client's perspective. Specifically, Figure 2 This is a flowchart of another application interface management method provided by an embodiment of the present invention. The embodiment of the present invention is applicable to scenarios of security protection for application programming interfaces. The method can be executed by an application interface management device configured on the client. The device can be implemented in the form of software and / or hardware, and optionally, it can be implemented by an electronic device, preferably a mobile terminal, desktop computer, laptop computer, or server.

[0066] like Figure 2 As shown, the application interface management method provided in this embodiment of the invention may specifically include: S201. In response to the first call operation to the first interface, a first access request is generated and sent to the server so that the server generates response content based on the first access request.

[0067] S202. In response to the response content, parse the response content to obtain the first code file, generate a second access request based on the first code file, and send the second access request to the server to obtain the calling permission relative to the first interface.

[0068] In this embodiment, the method for generating a second access request based on the first code file can be as follows: obtaining the corresponding collection value based on the first signature element in the first code file, and writing the collection value as the element value corresponding to the first signature element into the first request header corresponding to the first signature element; generating a signature result based on the element value relative to the first interface according to the code contained in the first code file for executing the logic of interface signing based on the first signature information, and writing the signature result into the second request header accordingly; and generating a second access request based on the first request header and the second request header.

[0069] The technical solution described in this embodiment generates a first access request and sends it to the server in response to the first call to the first interface, enabling the server to generate response content based on the first access request. In response to the response content, the server parses the response content to obtain a first code file, generates a second access request based on the first code file, and sends the second access request to the server to obtain calling permissions relative to the first interface. Using this method, the client only needs to parse and obtain the first code file and generate a second access request carrying a signature result based on it, lowering the client access threshold, making deployment easy and seamless for developers, while also exhibiting strong adaptability and compatibility with different client types. Furthermore, since the first code file is a dedicated code file generated by the server for the client after receiving the first access request, attackers cannot bypass authentication by forging a generic signature result, thereby improving the security of application interface calls.

[0070] As a fifth optional embodiment of the present invention, the method can be further optimized based on the above embodiments, including: Based on the first sub-code in the first code file, the system receives the second signature information sent by the server through the target communication protocol, and updates the first signature information in the first code file according to the second signature information.

[0071] The first sub-code can be used to update the first signature information in the first code file based on the target communication protocol.

[0072] In this embodiment, after the client loads the first code file, the first sub-code can automatically start and continuously listen to the target communication protocol without manual operation from the client. Upon receiving the second signature information sent by the server through the target communication protocol, the storage location of the first signature information in the first code file can be located, and the second signature information can replace the first signature information in the first code file when preset conditions are met. For example, the preset conditions could be calling a new first interface to request a new page, etc. It is understood that after the update is completed, the updated first signature information will be automatically used when a second access request is subsequently generated.

[0073] The above technical solution in this embodiment provides an implementation scheme for dynamically updating the first signature information in the first code file loaded by the client based on the first sub-code, so that the first signature information changes from static solidification to dynamic controllability, which not only ensures the security of the application interface, but also takes into account the ease of use of the client (unobtrusive and low maintenance cost).

[0074] As a sixth optional embodiment of the present invention, based on the above embodiments, the step of generating a second access request based on the first code file can be optimized as follows: Obtain the first signature information in the first code file; for each first signature element in the first signature information, obtain the corresponding collection value, determine the collection value as the element value of the first signature element, and write the element value into the corresponding first request header; The element values ​​are sorted according to the sorting method of the signature elements in the first signature information, and the sorted element values ​​are concatenated according to the first separator in the first signature information to generate a signature string; the signature string is signed according to the execution logic for generating the signature result in the first code file to obtain a signature result, and the signature result is written into the second request header accordingly; a second access request is generated according to the first request header and the second request header combined with the request fixed structure.

[0075] For example, the first signature information includes a browser fingerprint element, a timestamp element, and a one-time random value element. The element value corresponding to the browser fingerprint element is obtained based on the first signature information and written into the first request header X-FINGERPRINT; the element value corresponding to the timestamp element, i.e., the timestamp, is generated based on the first signature information and written into the first request header X-DATE; a monotonically increasing one-time random value (i.e., nonce value) is generated based on the first signature information and written into the first request header X-NONCE.

[0076] For example, the element values ​​are sorted according to the sorting method of the signature elements, and the sorted element values ​​are concatenated using the first delimiter to generate a signature string. Then, the signature string is signed according to the signature result generation logic including the first key and the first signature algorithm in the first signature information to obtain the signature result, and the signature result is written into the second request header Authorization.

[0077] For example, a fixed request structure may include basic elements such as a Uniform Resource Identifier (URI) for interface access, a request method, and / or a request body.

[0078] The technical solution described in this embodiment provides a technical solution for generating a second access request based on a first code file. Through standardized, parameterized, and automated process design, it not only solves the problems of high error rate and low adaptability in traditional signature request generation, but also ensures consistency with the server-side signature verification logic. At the same time, the signature string generation steps are entirely driven by the first signature information in the first code file, which cannot be tampered with by the client (e.g., the sorting method cannot be adjusted or the separator cannot be replaced), ensuring the uniqueness and legality of the signature string and improving the anti-forgery capability of the signature. Furthermore, the first signature element by default includes a timestamp element and a one-time random value element. The steps require the collection of the element values ​​of these elements and their writing into the request header and inclusion in the signature string, ensuring that these two core anti-replay parameters are fully used, further strengthening the security protection of the application interface.

[0079] Figure 3 This is a schematic diagram of the structure of an application interface management device provided in an embodiment of the present invention. This device is configured on the server side. Figure 3 As shown, the device includes: a generation module 31, a feedback module 32, and an authorization determination module 33, wherein... Generation module 31 is used to generate first signature information and first code file in response to the first access request. The first access request is generated by the client when it first calls the first interface, and the first code file is associated with the client. Feedback module 32 is used to generate response content carrying the first code file and feed the response content back to the client, so that the client performs interface signing based on the first code file and generates a second access request based on the signing result; The permission determination module 33 is used to respond to the second access request and, when it is determined that the client has the right to call the first interface, allow the client to call the first interface. The calling permission is determined based on the second access request and the first signature information.

[0080] The application interface management device provided in this embodiment of the invention generates first signature information and a first code file in response to a first access request. The first access request is generated by the client when it first calls the first interface, and the first code file is associated with the client. It then generates response content carrying the first code file and sends the response content back to the client, enabling the client to sign the interface based on the first code file and generate a second access request based on the signature result. In response to the second access request, if it is determined that the client has the right to call the first interface, the client is allowed to call the first interface. The calling permission is determined based on the second access request and the first signature information. Using this device, by dynamically generating the first signature information and the first code file corresponding to the client, and generating response content carrying the first code file to send back to the client, the client can perform a dedicated interface signature based on the first code file. This improves the convenience and applicability of deployment. Furthermore, by verifying the client's calling permission based on the second access request carrying the signature result and the first signature information associated with the client, compared to existing schemes that use fixed signature information, this scheme reduces the risk of signature cracking and improves the security of the application interface during the calling process.

[0081] The application interface management device provided in this embodiment of the invention can execute the application interface management method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0082] Figure 4 This is a schematic diagram of a management device for another application interface provided in an embodiment of the present invention, which is configured on the client side. Figure 4 As shown, the device includes: a first request sending module 41 and a second request sending module 42, wherein, The first request sending module 41 is used to generate a first access request and send it to the server in response to the first call operation for the first interface, so that the server generates response content based on the first access request. The second request sending module 42 is used to respond to the response content, parse the response content to obtain a first code file, generate a second access request based on the first code file, and send the second access request to the server to obtain the calling permission relative to the first interface.

[0083] The application interface management device provided in this embodiment of the invention generates a first access request and sends it to the server in response to the first call operation to the first interface, so that the server generates response content based on the first access request; in response to the response content, it parses the response content to obtain a first code file, generates a second access request based on the first code file, and sends the second access request to the server to obtain the calling permission relative to the first interface. Using this device, the client only needs to parse and obtain the first code file and generate a second access request carrying a signature result based on the first code file, lowering the client access threshold, making deployment easy and imperceptible to developers, while also being highly adaptable and compatible with different client types. Furthermore, since the first code file is a dedicated code file generated by the server for the client after receiving the first access request, attackers cannot bypass authentication by forging a generic signature result, thereby improving the security of application interface calls.

[0084] Figure 5 A schematic diagram of an electronic device 50 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0085] like Figure 5 As shown, the electronic device 50 includes at least one processor 51 and a memory, such as a read-only memory (ROM) 52 and a random access memory (RAM) 53, communicatively connected to the at least one processor 51. The memory stores computer programs executable by the at least one processor. The processor 51 can perform various appropriate actions and processes based on the computer program stored in the ROM 52 or loaded from storage unit 58 into the RAM 53. The RAM 53 can also store various programs and data required for the operation of the electronic device 50. The processor 51, ROM 52, and RAM 53 are interconnected via a bus 54. An input / output (I / O) interface 55 is also connected to the bus 54.

[0086] Multiple components in electronic device 50 are connected to I / O interface 55, including: input unit 56, such as keyboard, mouse, etc.; output unit 57, such as various types of monitors, speakers, etc.; storage unit 58, such as disk, optical disk, etc.; and communication unit 59, such as network card, modem, wireless transceiver, etc. Communication unit 59 allows electronic device 50 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0087] Processor 51 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 51 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 51 performs the various methods and processes described above, such as application interface management methods.

[0088] In some embodiments, the application interface management method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 58. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 50 via ROM 52 and / or communication unit 59. When the computer program is loaded into RAM 53 and executed by processor 51, one or more steps of the application interface management method described above may be performed. Alternatively, in other embodiments, processor 51 may be configured to perform the application interface management method by any other suitable means (e.g., by means of firmware).

[0089] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0090] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0091] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0092] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0093] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0094] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0095] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0096] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.< / header>

Claims

1. A method for managing application interfaces, characterized in that, Applied to the server side, the method includes: In response to the first access request, first signature information and a first code file are generated. The first access request is generated by the client when it first calls the first interface, and the first code file is associated with the client. Generate response content carrying the first code file and send the response content back to the client, so that the client can perform interface signing based on the first code file and generate a second access request based on the signing result; In response to the second access request, when it is determined that the client has the right to call the first interface, the client is allowed to call the first interface, and the calling permission is determined based on the second access request and the first signature information.

2. The method according to claim 1, characterized in that, The first code file includes first sub-code for updating the first signature information based on the target communication protocol; The method further includes: When it is determined that the conditions for updating the signature information are met, a second signature information corresponding to the client is generated; The second signature information is sent to the client via the target communication protocol, so that the client receives the second signature information based on the first sub-code and updates the first signature information in the first code file.

3. The method according to claim 1, characterized in that, The steps for generating the first signature information include: Based on the determined first set of parameters, generate the first signature information; The first parameter set includes a first signature element, a first separator, a first key, a first signature algorithm, and a signature element sorting method. The first signature element includes a timestamp element and a monotonically increasing one-time random value element.

4. The method according to claim 1, characterized in that, The steps for generating the first code file include: Obtain a predefined code template library, which includes an initial signature generation template and a communication code template. The initial signature generation template includes execution logic for generating signature results, and the communication code template includes execution logic for updating signature information. Configure the initial signature generation template according to the first signature information, generate the target signature generation template, and integrate the communication code template into the target signature generation template so that the update callback function of the communication code template points to the first signature information replacement entry of the target signature generation template; The target signature generation template is subjected to syntax validation and format standardization to generate an initial code file; The initial code file is obfuscated to generate the first code file.

5. The method according to claim 1, characterized in that, The steps for determining the invocation permission based on the second access request and the first signature information include: Parse the second access request to obtain the first request header carrying the value of the element corresponding to the timestamp element; Obtain the timestamp from the first request header and determine the time difference between the timestamp and the server's current time; If the time difference is greater than or equal to a preset difference threshold, it is determined that the user does not have the permission to make the call. If the time difference is less than a preset difference threshold, the first signature information corresponding to the client is determined according to the client identification information in the second access request, and the target first request header and the second request header carrying the signature result are obtained based on the first signature information and the second access request. The signature verification information is determined based on the first request header and the second request header of the target, and the calling permission is determined based on the first signature information and the signature verification information. The signature verification information includes the element value of the first signature element and the signature result.

6. The method according to claim 5, characterized in that, The determination of access permissions based on the first signature information and the verification information includes: A verification signature is generated based on the first signature information and the values ​​of each element, and the verification signature is compared with the signature result; If the comparison results are inconsistent, it is determined that the user does not have the permission to call the function. If the comparison results are consistent, check if there is an existing value in the cache that is the same as the one-time random value in the element value; if it exists, determine that the calling permission is not available; if it does not exist, determine that the calling permission is available, and write the one-time random value into the cache and set its validity period.

7. The method according to claim 6, characterized in that, The step of generating a verification signature based on the first signature information and each of the element values ​​includes: The element values ​​are sorted according to the sorting method of the signature elements in the first signature information, and the sorted element values ​​are concatenated according to the first separator in the first signature information to generate a verification signature string. The verification signature is obtained by signing the verification signature string according to the first key and the first signature algorithm in the first signature information.

8. A method for managing application interfaces, characterized in that, Applied to a client, the method includes: In response to the first call operation to the first interface, a first access request is generated and sent to the server, so that the server generates response content based on the first access request; In response to the response content, the response content is parsed to obtain a first code file, a second access request is generated based on the first code file, and the second access request is sent to the server to obtain the calling permission relative to the first interface.

9. The method according to claim 8, characterized in that, Also includes: Based on the first sub-code in the first code file, the system receives the second signature information sent by the server through the target communication protocol, and updates the first signature information in the first code file according to the second signature information.

10. The method according to claim 8, characterized in that, The step of generating a second access request based on the first code file includes: Obtain the first signature information from the first code file; For each first signature element in the first signature information, obtain the corresponding collection value, determine the collection value as the element value of the first signature element, and write the element value into the corresponding first request header; The element values ​​are sorted according to the sorting method of the signature elements in the first signature information, and the sorted element values ​​are concatenated according to the first delimiter in the first signature information to generate a signature string. The signature string is signed according to the execution logic used for signature result generation in the first code file to obtain the signature result, and the signature result is written into the second request header accordingly; A second access request is generated based on the first request header and the second request header combined with the fixed request structure.

Images