An HTTP request processing method and device

Abstract

This application provides an HTTP request processing method and device, relating to the field of computer technology. The method is applied to a gateway node in a target link and includes: receiving a first HTTP request sent by a client application node, wherein the first HTTP request is an HTTP request for which a client node signature has been added to an original HTTP request; verifying the client node signature in the first HTTP request, and obtaining the original HTTP request after successful verification; and sending a second HTTP request to a server application node in the target link, wherein the second HTTP request is an HTTP request for which a gateway node signature has been added to the original HTTP request.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an HTTP request processing method and device. Background Technology

[0002] In some business systems, client applications frequently send HTTP requests to server applications within the business system and receive responses from the server applications. To prevent malicious tampering of HTTP requests, the traditional method is to implement anti-tampering measures at the business system boundary. The client application adds a digital signature to the original HTTP request to generate a signed HTTP request, which is then sent to the gateway. The gateway verifies the digital signature in the signed HTTP request to obtain the original HTTP request, which is then forwarded to the server application within the business system. However, within the HTTP request chain from the gateway to the server application within the business system, the HTTP request can still be maliciously tampered with, compromising the data security of the business system. Summary of the Invention

[0003] This application provides an HTTP request processing method and device to prevent HTTP requests from being maliciously tampered with throughout the entire HTTP request chain, and to ensure the security and consistency of HTTP request data throughout the entire HTTP request chain.

[0004] In a first aspect, embodiments of this application provide an HTTP request processing method applied to a gateway node of a target link, the method comprising:

[0005] Receive a first HTTP request sent by a client application node, wherein the first HTTP request is an HTTP request in which the client node signature is added to the original HTTP request;

[0006] The client node signature in the first HTTP request is verified, and the original HTTP request is obtained after the verification is successful.

[0007] A second HTTP request is sent to the server application node in the target link, wherein the second HTTP request is an HTTP request with the gateway node signature added to the original HTTP request.

[0008] Secondly, embodiments of this application provide an HTTP request processing method applied to a server application node in a target link, wherein a second aspect is configured on the server application node, and the method includes:

[0009] The current node receives a first signed HTTP request sent by the previous node. When receiving the first signed HTTP request sent by the previous node, the second aspect of the current node intercepts the first signed HTTP request, verifies the previous node's signature in the first signed HTTP request, and obtains a first unsigned HTTP request after the verification is successful. The first unsigned HTTP request is then received by the current node. The first unsigned HTTP request is an HTTP request from the first signed HTTP request with the previous node's signature removed.

[0010] Process the first unsigned HTTP request;

[0011] Upon receiving a response to the first unsigned HTTP request, the response is returned to the previous node.

[0012] Thirdly, embodiments of this application provide an HTTP request processing device, the device comprising: a gateway node, the gateway node comprising:

[0013] The receiving module is used to receive the first HTTP request from the client application node, wherein the first HTTP request is an HTTP request in which the client node signature is added to the original HTTP request.

[0014] The verification module is used to verify the client node signature in the first HTTP request, and obtain the original HTTP request after the verification is successful.

[0015] The sending module is used to send a second HTTP request to the server application node, wherein the second HTTP request is an HTTP request with the gateway node signature added to the original HTTP request.

[0016] Fourthly, embodiments of this application provide an HTTP request processing device, the device comprising: a server application node, and a second aspect, the second aspect being disposed on the server application node, the server application node comprising:

[0017] The receiving module is used to receive the first signed HTTP request sent by the previous node. When receiving the first signed HTTP request sent by the previous node, the second aspect of the current node intercepts the first signed HTTP request, verifies the previous node's signature in the first signed HTTP request, and obtains the first unsigned HTTP request after the verification is successful. The first unsigned HTTP request is then received by the current node. The first unsigned HTTP request is an HTTP request from the first signed HTTP request with the previous node's signature removed.

[0018] The processing module is used to process the first unsigned HTTP request;

[0019] The return module is used to return the response to the previous node when a response to the first unsigned HTTP request is received. Attached Figure Description

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

[0021] Figure 1 A schematic diagram illustrating an application scenario of the HTTP request processing method provided in this application embodiment;

[0022] Figure 2 A flowchart illustrating an HTTP request processing method provided in an embodiment of this application;

[0023] Figure 3 A flowchart illustrating an HTTP request processing method provided in another embodiment of this application;

[0024] Figure 4 A schematic diagram illustrating another application scenario of the HTTP request processing method provided in the embodiments of this application;

[0025] Figure 5 A flowchart illustrating an HTTP request processing method provided in another embodiment of this application;

[0026] Figure 6 This is a schematic diagram of an HTTP request processing device provided in an embodiment of this application;

[0027] Figure 7 This is a schematic diagram of an HTTP request processing device provided in another embodiment of this application. Detailed Implementation

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

[0029] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The terms "first," "second," etc., used in this application are used to distinguish similar objects and are not intended to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this specification can be implemented in orders other than those illustrated or described herein.

[0030] To address the issue of HTTP request data being tampered with in the HTTP request chain within the business system from the gateway to the server application, this application provides an HTTP request processing solution for preventing HTTP request tampering. The HTTP request processing scheme provided in this application provides anti-tampering measures for the HTTP request chain after the gateway node, combined with anti-tampering measures for the HTTP request chain before the gateway node, thus achieving end-to-end anti-tampering of HTTP requests. By setting aspects for the gateway node and / or server application node in the HTTP request chain after the gateway node, each node's aspect performs signature and verification on the HTTP request for each segment of the HTTP request chain, enabling the gateway node and / or server node to perform seamless anti-tampering on each segment of the HTTP request chain, achieving seamless anti-tampering of the entire HTTP request chain after the gateway node, without requiring changes to the original processing of the gateway node and server node. By using a preset digest algorithm to sort the request parameters during signature and verification, it can prevent tampering misjudgments caused by inconsistent request parameter order while preventing tampering of the HTTP request chain. By having the keys of each node managed by a remote key management platform, and dynamically obtaining the keys from the remote key management platform during signature and verification, it can avoid key leakage and further improve security.

[0031] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0032] The HTTP request processing method provided in one or more embodiments of this application can be applied to, for example... Figure 1 The scenario shown includes: client application node 100, gateway node 300, and server application node 500.

[0033] Client application node 100 can send an HTTP request to server application node 500 within the business system via gateway node 300 and receive a response from server application node 500. Client application node 100 is equipped with anti-tampering measures, including a built-in security module. This module uses a preset signature algorithm to add a client node signature to the original HTTP request to be sent, generating a first HTTP request. Client application node 100 can then send this first HTTP request with the added client node signature to gateway node 300.

[0034] Gateway node 300 can receive the first HTTP request sent by client application node 100, verify the client node signature in the first HTTP request, and obtain the original HTTP request after successful verification. After obtaining the original HTTP request, gateway node 300 can add a gateway node tag to the original HTTP request, generate a second HTTP request, and send the second HTTP request to server node 500.

[0035] The server application node 500 can verify the gateway node tag in the second HTTP request. After successful verification, it processes the second HTTP request to obtain a response and returns the response to the client application node 100 through the gateway node 300.

[0036] The HTTP request processing scheme provided in this application provides anti-tampering measures for the target link after the gateway node. Some embodiments of the HTTP request processing scheme are applied to the gateway node in the target link, and some embodiments of the HTTP request processing scheme are applied to the server application node in the target link. The target link is the HTTP request link after the gateway node in the HTTP request link, that is, the HTTP request link from the gateway node to the last server application node.

[0037] Example 1

[0038] Please refer to Figure 2 This is a flowchart illustrating an embodiment of an HTTP request processing method provided in this application. This HTTP request processing method can be applied to... Figure 1 In the scenario shown, the executing entity can be the gateway node in the target link. For example... Figure 2 As shown, the HTTP request processing method provided in this embodiment may include the following processing:

[0039] S102 receives the first HTTP request sent by the client application node.

[0040] The first HTTP request is an HTTP request with a client node signature added to the original HTTP request, generated by the client application node. The client application node is the starting node in the HTTP request chain, and can be a browser, mobile app, or other client application. The client node signature is a digital signature of the client application node, used to prevent HTTP request data from being tampered with and to ensure the security and consistency of request data in the HTTP request chain. It is obtained by the client application node processing the original HTTP request message using a preset signature algorithm.

[0041] S104, verify the client node signature in the first HTTP request, and obtain the original HTTP request after successful verification.

[0042] Among these features, the client node signature can be verified based on the digital signature algorithm used when generating the client node signature.

[0043] In one implementation, the client application node can generate a client node signature based on its private key and a first preset digest algorithm. Specifically, the client application node can generate a first message digest based on the original HTTP request message and the first preset digest algorithm, encrypt the first message digest using its private key to generate a client node signature, add the client node signature to the original HTTP request to generate a first HTTP request, and then send the first HTTP request to the gateway node.

[0044] Correspondingly, the gateway node can verify the client node signature based on the client node's public key and a first preset digest algorithm. Specifically, the gateway node can obtain the client node's public key and the first preset digest algorithm, where the client node's public key forms a key pair with the client node's private key used when generating the client node signature, and the first preset digest algorithm is the digest algorithm used when generating the client node signature; the gateway node decrypts the client node signature using the client node's public key to obtain a first message digest; the first preset digest algorithm extracts a comparison digest from the first HTTP request; the gateway node checks whether the comparison digest matches the first message digest. If they match, the verification is successful; if they do not match, the verification fails. If the verification fails, it indicates that the HTTP request was tampered with in the request chain from the client application node to the gateway node.

[0045] S106, send the second HTTP request to the server application node in the target link, wherein the second HTTP request is an HTTP request with the gateway node signature added to the original HTTP request.

[0046] Among them, the gateway node signature is the digital signature of the gateway node, which is used to ensure the security and consistency of HTTP request data in the HTTP request link from the gateway node to the server application node, and to prevent the HTTP request data from being tampered with.

[0047] By adding a gateway node signature to the HTTP request sent from the gateway node to the server application node, anti-tampering measures are added to the HTTP request chain after the gateway node. This can prevent the HTTP request from being tampered with in the internal HTTP request chain from the gateway node to the server application node. Combined with the existing anti-tampering measures in the HTTP request chain from the client application node to the gateway node, tamper-proofing can be achieved throughout the entire HTTP request chain.

[0048] In one implementation, the existing business logic code of the gateway node can be modified to add a security module. This built-in security module adds a gateway node signature to the original HTTP request, generating a second HTTP request. The gateway node signature can be generated by the gateway node based on its private key and a second preset digest algorithm. The second preset digest algorithm can be the same as or a different one than the first preset digest algorithm.

[0049] In one implementation, a gateway node signature is added to the original HTTP request to generate a second HTTP request, which may include the following processing:

[0050] Process 1: Extract the second message digest from the original HTTP request according to the second preset digest algorithm.

[0051] The second preset digest algorithm can be a different digest algorithm than the first preset digest algorithm, so that the HTTP request link from the gateway node to the server application node and the HTTP request link from the client application node to the gateway node use different digest algorithms to generate gateway node signatures and client node signatures, thereby improving the anti-tampering capability.

[0052] In HTTP request messages, the order of multiple request parameters in the sent and received HTTP requests may be inconsistent, leading to inconsistent message digests and potential misjudgments. To prevent misjudgments due to inconsistent request parameter order, a second preset digest algorithm can specify the sorting order of the request parameters. Request parameters can be obtained from the original HTTP request message according to the second preset digest algorithm, sorted according to the specified order, and the second message digest can be generated based on the sorted request parameters. Specifically, the sorted request parameters can be concatenated into a string to be signed, and a preset hash algorithm can be used to calculate the hash value of the string to be signed. The second message digest can then be generated based on the hash value of the string to be signed. The preset hash algorithm can be an existing hash algorithm, such as HmacSHA256 or HmacSHA512.

[0053] The specified order can be ascending alphabetical order of the request parameter names, descending alphabetical order, or any other predefined sorting order. It's understandable that as long as the sorting method for the request parameters when generating the second message digest is the same as the sorting method when generating the comparison digest for signature verification, misjudgments due to inconsistent request parameters can be avoided. Therefore, as long as the second preset digest algorithm is used to sort the request parameters when generating the signature, and the same digest algorithm is used when verifying the signature, regardless of the sorting order, misjudgments due to inconsistent request parameter order can be avoided. Thus, the specified order for sorting request parameters in the second message digest algorithm can be any specified order.

[0054] In some implementations, to further enhance security, the specified order can be set to an unconventional sorting order. This allows the request parameters to be sorted and concatenated according to this unconventional order to obtain the string to be signed. For example, the request parameters can be sorted and concatenated in ascending order of their character count to obtain the string to be signed.

[0055] In some implementations, to further enhance security, the parameter names and values ​​of the request parameters can be concatenated using a first special character to form a request parameter combination. Different request parameter combinations are then sorted, and finally, a second special character is used to concatenate the sorted request parameter combinations into a string to be signed. Afterward, a message digest is generated based on the final concatenated string. For example, the request parameters can be concatenated in the form of "first parameter name = first parameter value & second parameter name = second parameter value ... & Nth parameter name = Nth parameter value".

[0056] Process 2: Encrypt the second message digest using the gateway node's private key to obtain the gateway node's signature.

[0057] Specifically, the second message digest can be encrypted using a preset encryption algorithm and the gateway node's private key to form a digital signature for the gateway node. The preset encryption algorithm can be an existing algorithm such as SM2 or RSA. This preset encryption algorithm can be different from the one used to encrypt the first message digest. By using different encryption algorithms to generate the gateway signature and client node signature, the signature algorithms for the HTTP request link from the gateway node to the server application node and the HTTP request link from the client application node to the gateway node can be different, thereby further improving security. Of course, both can also use the same encryption algorithm.

[0058] In one implementation, to further enhance security and prevent key leakage, the gateway node's private key can be pre-stored on a remote key escrow platform. After extracting the second message digest, the gateway node's private key can be dynamically retrieved from the remote key escrow platform based on the gateway node's identifier. Before using the gateway node's private key, it can be retrieved from the remote key escrow platform based on the gateway node's identifier; after using the gateway node's private key, it can be destroyed.

[0059] Process 3: Add the gateway node signature to a specified location in the original HTTP request to obtain a second HTTP request.

[0060] The specified location is a pre-defined position for adding the signature. In one implementation, the gateway node signature can be added to the specified position in the request header of the original HTTP request to obtain a second HTTP request. The original HTTP request can be a GET request or a POST request. Since a GET request only has a request header, by adding the gateway node signature to the request header of the original HTTP request, it is possible to adapt to different types of HTTP requests.

[0061] In the above implementation, the business logic code of the gateway node itself is modified to add a gateway node signature to the original HTTP request, generating a second HTTP request to be sent to the server application node. In one implementation, an aspect can be set for the gateway node, using aspect-based technology to add the gateway node signature to the original HTTP request to generate a second HTTP request. This method allows the gateway node to be unaware of the added anti-tampering measures without requiring changes to its existing business logic code.

[0062] Aspect-oriented programming (AOP) is a technique that enhances existing code by weaving new code into pre-encapsulated classes during compilation or runtime. The enhanced code is called an aspect. In this implementation, AOP can be used to set a first aspect for the gateway node. This first aspect can hook the event of the gateway node sending an HTTP request (a hook is a system mechanism that, when a specific system event is hooked, the hooked program receives a system notification and can respond immediately). This can be code woven into the gateway node's existing business logic when the gateway node sends an HTTP request to the server application node. This code adds the gateway node's signature to the HTTP request, generating a signed HTTP request that is then sent to the server application node. This eliminates the need to modify the gateway node's existing business logic, making the gateway node unaware of the added anti-tampering measures.

[0063] Specifically, the gateway node can send a raw HTTP request to the server application node. The first aspect can intercept the raw HTTP request when the gateway node sends it to the server application node, add the gateway node's signature to the raw HTTP request, generate a second HTTP request, and send the second HTTP request to the server application node.

[0064] In related technologies, after a gateway node receives an original HTTP request, its original business logic is to send the original HTTP request to the server application node in the target link. In this embodiment, after setting a first aspect for the gateway node, its original business logic remains unchanged—it still sends the original HTTP request to the server application node. However, when the gateway node sends the original HTTP request to the server application node, the first aspect intercepts the original HTTP request, adds the gateway node's signature to the original HTTP request, and generates a second HTTP request. That is, during the process of the gateway node sending the original HTTP request to the server application node, the first aspect changes the original HTTP request into a second HTTP request with the gateway node's signature. Therefore, the request ultimately sent by the gateway node to the server application node is actually a second HTTP request with the gateway node's signature, and the HTTP requests in the HTTP request link between the gateway node and the server application node are actually second HTTP requests with the gateway node's signature. Thus, without changing the original business logic code of the gateway node, seamless anti-tampering measures can be implemented for the HTTP request link after the gateway node, ensuring the security and consistency of the HTTP requests in this link.

[0065] The first aspect adds a gateway node signature to the original HTTP request. The specific processing for generating the second HTTP request can include the aforementioned processes one to three, which will not be elaborated here.

[0066] Example 2

[0067] Corresponding to the above-mentioned addition of the gateway node signature to the HTTP request sent by the gateway node through the first aspect, a second aspect can be set for the server application node. The second aspect verifies the gateway node signature in the second HTTP request received by the server application node, so that the server application node receives the original HTTP after verification. Thus, the server application node does not need to change its own business logic code, and the server application node is unaware of the added anti-tampering measures.

[0068] Please refer to Figure 3 This is a flowchart illustrating an HTTP request processing method provided in another embodiment of this application. This HTTP request processing method can be applied to... Figure 1 In the scenario shown, the executing entity can be the server-side application node in the target link. The server-side application node has a second aspect configured to hook the event of the server-side application node receiving an HTTP request. This second aspect can be program code woven into the original business logic code of the server-side application node when it receives a second HTTP request sent by the gateway node. This program code is used to verify the gateway node's signature in the second HTTP request, ensuring that the original HTTP request obtained after signature verification is received by the server-side application node. The target link is the HTTP request link after the gateway node in the HTTP request chain. For example... Figure 3 As shown, the HTTP request processing method provided in this embodiment may include the following processing:

[0069] S202, Receive the second HTTP request sent by the gateway node. When receiving the second HTTP request sent by the gateway node, the second aspect intercepts the second HTTP request, verifies the gateway node signature in the second HTTP request, and after the verification is successful, obtains the original HTTP request, so that the original HTTP request is received by the server application node.

[0070] Specifically, in the relevant technologies, the original business processing logic of the server application node is to receive the original HTTP request sent by the gateway node, process the original HTTP request, and obtain the response to the original HTTP request. In this embodiment, after setting the second aspect for the server application node, the original business processing logic of the server application node remains unchanged. It still receives the original HTTP request sent by the server and processes the original HTTP request. However, the HTTP request sent by the gateway node is actually a second HTTP request with the gateway node's signature added to the original HTTP request. When the server application node receives the second HTTP request sent by the gateway node, the second aspect intercepts the second HTTP request and verifies the client node signature in the second HTTP request. After the verification is successful, the original HTTP request is obtained. That is, during the process of the server application node receiving the HTTP request sent by the gateway node, the second aspect changes the received second HTTP request to the original HTTP request without removing the gateway node's signature. Thus, the request received by the server application node is still the original HTTP request. The server application node can continue to use its original business processing logic to process the original HTTP request to obtain a response without the server application node needing to change its original business processing logic code. Therefore, the server application node is unaware of the added anti-tampering measures.

[0071] Corresponding to adding the gateway node signature in the original request, the second aspect verifies the gateway node signature in the second HTTP request, which may include the following processing:

[0072] Process 4: Obtain the client node signature from the specified location in the second HTTP request.

[0073] On the gateway node side, a client node signature is added to a specified position in the original HTTP request to generate a second HTTP request. Correspondingly, on the server application node side, a specified position can be obtained, from which the client signature is retrieved in the second HTTP request. This specified position can be a position agreed upon by both the gateway node and the server application node, such as a specified position in the message header.

[0074] Step 5: Use the gateway node's public key to decrypt the client node's signature to obtain the second message digest.

[0075] On the gateway node side, the gateway node's private key is used to encrypt the second message digest to generate a client signature. Correspondingly, on the server-side application node side, the gateway node's public key, which forms a key pair with the gateway node's private key, is obtained. This public key is then used to decrypt the client node's signature, yielding the second message digest. The encryption algorithm used to generate the client signature can be obtained, and the client signature is decrypted using the gateway node's public key and this encryption algorithm.

[0076] Process six: Extract the comparison digest from the second HTTP request according to the second preset digest algorithm.

[0077] Specifically, on the gateway node side, a second message digest is extracted from the original HTTP request message according to a second preset digest algorithm. Correspondingly, on the server application node side, the second preset digest algorithm used to generate the second message digest can be obtained, and a comparison digest can be extracted from the second HTTP request according to the second preset digest algorithm.

[0078] Step 7: Check whether the comparison digest matches the second message digest. If they do, the verification is successful, and the original HTTP request is obtained.

[0079] If the comparison digest matches the second message digest, it indicates that the HTTP request parameters received by the server application node and the HTTP request sent by the gateway node are consistent, and the HTTP request in the HTTP request chain from the gateway node to the server application node has not been tampered with. In this case, the verification is considered successful. After successful verification, the gateway node signature can be removed from the second HTTP request to obtain the original HTTP request. If the comparison digest does not match the second message digest, it indicates that the HTTP request received by the server application node and the HTTP request sent by the gateway node are inconsistent, and the HTTP request in the HTTP request chain from the gateway node to the server application node has been tampered with. In this case, the verification is considered unsuccessful. In this situation, the HTTP request sent by the gateway node does not need to be processed or responded to; that is, subsequent processing S204 and S206 are not required.

[0080] S204 processes the original HTTP request and obtains the response to the original HTTP request.

[0081] Among them, the server-side application node can use its original HTTP request processing to process the original HTTP request and obtain the response to the original HTTP request.

[0082] S206 returns the response to the original HTTP request to the gateway node.

[0083] The server-side application node can use its original HTTP request processing to return the response to the gateway node.

[0084] Furthermore, after receiving the response from the server application node, the gateway node can then return the response to the client application node, thereby completing the response to the HTTP request sent by the client application node.

[0085] By setting a second aspect on the server-side application node, the gateway node can perform seamless anti-tampering without changing its original business processing logic.

[0086] Example 3

[0087] The application scenarios of the HTTP request processing method provided in the above embodiments are as follows: Figure 1 The scene shown is in Figure 1 The scenario shown includes a server-side application node that can obtain the response to the HTTP request through its own processing. In some scenarios, such as... Figure 4 As shown, the HTTP request chain after the gateway node includes multiple server-side application nodes. When a server-side application node processes an HTTP request, it needs to call other server-side application nodes and generate the response to the HTTP request based on the responses from those other server-side application nodes. For example, in a microservice architecture, when application service A processes HTTP request A, it needs to send HTTP request B to application service B and generate the response to HTTP request A based on the response to HTTP request B returned by application service B.

[0088] This application provides an HTTP request processing method that can be applied to... Figure 4 In the scenario shown, the executing entity can be... Figure 4 In the scenario shown, each server-side application node has a first aspect and a second aspect. The first aspect hooks the event of a server-side application node sending an HTTP request. This can be code woven into the business logic code of the current node when it sends an HTTP request to the next node. This code adds the current node's signature to the HTTP request, generating a signed HTTP request, which is then sent to the next node. The second aspect hooks the event of a server-side application node receiving an HTTP request. This can be code woven into the business logic code of the current node when it receives a signed HTTP request from the previous node. This code verifies the previous node's signature in the received signed HTTP request. If the verification is successful, an unsigned HTTP request is obtained and received by the current node.

[0089] In related technologies, in the original business processing logic of the server-side application nodes, the current node receives an unsigned HTTP request sent by the previous node, processes the received unsigned HTTP request, generates a next unsigned HTTP request to be sent to the next node, and sends the next unsigned HTTP request to the next node for processing. By adding a first aspect and a second aspect to each server-side application node, and having the first and second aspects sign and verify the HTTP requests, anti-tampering measures can be added to each segment of the HTTP request chain between server-side application nodes without changing the original business processing logic code of the server-side application nodes, thus achieving end-to-end HTTP anti-tampering.

[0090] Please refer to Figure 5 This is a flowchart illustrating an HTTP request processing method provided in another embodiment of this application. This HTTP request processing method can be applied to... Figure 4 In the scenario shown, the executing entity can be any server-side application node in the target link, and each server-side application node has a first aspect and a second aspect configured. For example... Figure 5 As shown, the HTTP request processing method provided in this embodiment may include the following processing:

[0091] S302: Receive the first signed HTTP request sent by the previous node. When receiving the first signed HTTP request sent by the previous node, the second aspect of the current node intercepts the first signed HTTP request, verifies the previous node's signature in the first signed HTTP request, and after the verification is successful, obtains the first unsigned HTTP request, so that the first unsigned HTTP request is received by the current node.

[0092] The first signed HTTP request is an HTTP request with the signature of the previous node added, and the first unsigned HTTP request is an HTTP request with the signature of the previous node removed from the first signed HTTP request. During the process of the current node receiving the first signed HTTP request sent by the previous node, the second aspect of the current node changes the first signed HTTP request to the first unsigned HTTP request, so that the HTTP request actually received by the current node is the first unsigned HTTP request.

[0093] In one implementation, the current node is the first server-side application node in the HTTP request chain, i.e., the next server-side application node after the gateway node. The previous node is the gateway node. The first signed HTTP request can be a request sent from the gateway node to the current node with the gateway node's signature added, such as the second HTTP request in the aforementioned embodiment. The first unsigned HTTP request can be a request from the first signed HTTP request with the gateway node's signature removed, such as the original HTTP request in the aforementioned embodiment. The specific processing of the second aspect in verifying the first signed HTTP request to generate the first unsigned HTTP request can be found in the aforementioned embodiment.

[0094] In one implementation, the current node is any server-side application node in the target link, the previous node is the server-side application node / gateway node preceding the current node in the target link, and the next node is the next server-side application node following the current node in the target link. The second interface verifies the first signed HTTP request. After successful verification, a first unsigned HTTP request is obtained. Specifically, this process may include: obtaining the previous node's public key, digest algorithm, encryption algorithm, and signature insertion position based on the previous node's identifier; and verifying the previous node's signature based on the previous node's public key, digest algorithm, encryption algorithm, and signature insertion position.

[0095] The previous node's public key, digest algorithm, encryption algorithm, and signature insertion location are the information used when adding the previous node's signature to the first unsigned HTTP request to generate the first signed HTTP request. Therefore, as the reverse process, the previous node's signature in the first signed HTTP request can be verified based on the previous node's public key, digest algorithm, encryption algorithm, and signature insertion location. For example, the previous node's signature can be obtained from the first signed HTTP request based on its insertion location. The signature can then be decrypted using the previous node's public key encryption algorithm and public key to obtain the first message digest. A comparison digest can then be extracted from the first signed HTTP request using the previous node's digest algorithm. The comparison digest and the previous node's digest can be checked for consistency; if they match, the verification is successful.

[0096] Process 3: After successful verification, generate the first unsigned HTTP request based on the first signed HTTP request.

[0097] Specifically, the signature of the previous node can be deleted from the first signed HTTP request to obtain the first unsigned HTTP request.

[0098] S304: Process the first unsigned HTTP request.

[0099] The current node can use its existing HTTP request processing capabilities to process the first unsigned HTTP request.

[0100] If the current node does not need to generate a response based on the processing results of other nodes, and it can generate the first unsigned HTTP response itself (meaning the current node is the last node in the HTTP request chain), then the HTTP request chain ends. The current node can return the first unsigned HTTP request response to the previous node, causing the previous node to generate a response to be sent to its previous node, and then send that response to its previous node, until the response requested by the client application node is generated and returned to the client application node.

[0101] If the current node is not the last node in the HTTP request chain, it needs to generate the current node's response to the previous requesting node based on the next server application node's response to the current node's request. The current node can further generate a second unsigned HTTP request based on the first unsigned HTTP request. The second unsigned HTTP request is an HTTP request to be sent to the next node of the current node, and the current node's signature is not added to this request.

[0102] S306: When generating a second unsigned HTTP request based on a first unsigned HTTP request, the second unsigned HTTP request is sent to the next node. When sending the second unsigned HTTP request to the next node, the first aspect of the current node intercepts the second unsigned HTTP request, adds the current node's signature to the second unsigned HTTP request, generates a second signed HTTP request, and sends the second signed HTTP request to the next node.

[0103] The second unsigned HTTP request is an HTTP request without the current node's signature, while the second signed HTTP request is an HTTP request with the current node's signature added to the second unsigned HTTP request. During the process of the current node sending the second unsigned HTTP request to the next node, the first aspect of the current node changes the second unsigned HTTP request into a second signed HTTP request, so that the second signed HTTP request is sent to the next node.

[0104] In one implementation, the first aspect adds the current node's signature to the second unsigned HTTP request to generate the second signed HTTP request. Specifically, this may include the following processes: obtaining the current node's private key, current node digest algorithm, current node encryption algorithm, and the location for adding the current node's signature based on the current node's identifier; generating the current node's signature based on the current node's private key, current node digest algorithm, and current node encryption algorithm; and adding the current node's signature to the second unsigned HTTP request based on the location for adding the current node's signature to generate the second signed HTTP request.

[0105] Specifically, the second message digest can be extracted from the second unsigned HTTP request according to the current node digest algorithm, and the second message digest can be encrypted according to the current node private key and the current node encryption algorithm to generate the current node signature.

[0106] It is understandable that the current node digest algorithm can be the same as or different from the previous node digest algorithm; the current node encryption algorithm can be the same as or different from the previous node encryption algorithm; and the specified position of the current node signature can be the same as or different from the specified position of the previous node signature.

[0107] In one implementation, the current node digest algorithm is the same as the previous node digest algorithm, the current node encryption algorithm is the same as the previous node encryption algorithm, and the specified position of the current node signature is the same as the specified position of the previous node signature. This simplifies the signing and verification process and improves processing efficiency.

[0108] In one implementation, at least one of the following is different: the current node digest algorithm is different from the previous node digest algorithm; the current node encryption algorithm is different from the previous node encryption algorithm; and the specified position of the current node signature is different from the specified position of the previous node signature. This allows for personalized signing and verification algorithms to be provided for the HTTP request links between adjacent nodes in the target link. As a result, the signing and verification processing methods are different for different segments of the HTTP request link, thereby further improving the anti-tampering capability of the entire HTTP request link and ensuring the security and consistency of the HTTP request.

[0109] In one implementation, during each signing process, the current node's digest algorithm, encryption algorithm, and the specified position of its signature are dynamically obtained based on the node's identifier. A signing HTTP request is then generated based on these dynamically obtained information. The digest algorithms, encryption algorithms, and the specified position of the signature for different nodes can be uniformly managed and dynamically updated to prevent leakage. Furthermore, the dynamically obtained digest algorithms, encryption algorithms, and the specified position of the signature change over time, thereby further enhancing tamper resistance.

[0110] Example 4

[0111] Corresponding to the HTTP request processing method for gateway nodes provided in this application, embodiments of this application also provide an HTTP request processing device. Figure 6 This is a schematic diagram of the structure of the HTTP request processing device provided in the embodiments of this application, as shown below. Figure 6 As shown, the HTTP request processing device includes: a gateway node 300, wherein the gateway node 300 includes:

[0112] The receiving module 310 is used to receive a first HTTP request from a client application node, wherein the first HTTP request is an HTTP request in which the client node signature is added to the original HTTP request.

[0113] The verification module 320 is used to verify the client node signature in the first HTTP request, and obtain the original HTTP request after the verification is successful.

[0114] The sending module 330 is used to send a second HTTP request to the server application node, wherein the second HTTP request is an HTTP request with the gateway node signature added to the original HTTP request.

[0115] Furthermore, the verification module 320 specifically includes:

[0116] The acquisition unit is used to acquire the client node public key and the first preset digest algorithm, wherein the client node signature is obtained based on the client node private key corresponding to the client node public key and the first preset digest algorithm;

[0117] The decryption unit is used to decrypt the client node signature using the client node's public key to obtain a first message digest, which is generated by the client application node based on the original HTTP request message and the first preset digest algorithm.

[0118] The generation unit is configured to generate a comparison digest based on the first HTTP request and the first preset digest algorithm.

[0119] The detection unit is used to detect whether the comparison digest is consistent with the first message digest. If they are consistent, the verification is deemed successful.

[0120] Optionally, the gateway node 300 is provided with a first cross-section 410, and the sending module 330 includes:

[0121] The sending unit is used to send the original HTTP request to the server application node. When sending the original HTTP request to the server application node, the first aspect 410 intercepts the original HTTP request, adds a gateway node signature to the original HTTP request, generates a second HTTP request, and sends the second HTTP request to the server application node.

[0122] Further, the first cut surface 410 includes:

[0123] The digest generation unit is used to extract a second message digest from the original HTTP request according to a second preset digest algorithm;

[0124] The encryption unit is used to encrypt the second message digest using the gateway node's private key to obtain the gateway node's signature;

[0125] An adding unit is used to add the gateway node signature to a specified position in the original HTTP request to obtain the second HTTP request.

[0126] Optionally, the digest generation unit is further configured to obtain request parameters from the original HTTP request message, sort the request parameters in a specified order, and generate the second message digest based on the sorted request parameters.

[0127] Furthermore, the first cut surface 410 also includes:

[0128] The key acquisition unit is used to obtain the gateway node private key from the remote key escrow platform according to the gateway node identifier before using the gateway node private key.

[0129] The key destruction unit is used to destroy the gateway node private key after it has been used.

[0130] It should be noted that the HTTP request processing device provided in this application embodiment and the HTTP request processing method for gateway devices provided in this application embodiment are based on the same inventive concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the corresponding HTTP request processing method for gateway nodes mentioned above, and repeated details will not be repeated.

[0131] Example 5

[0132] Corresponding to the HTTP request processing method for server-side application nodes provided in this application, this application also provides an HTTP request processing device. Figure 7 This is a schematic diagram of the structure of the HTTP request processing device provided in the embodiments of this application, as shown below. Figure 7 As shown, the HTTP request processing device includes: a server application node 500 and a second aspect 420, wherein the server application node 500 includes:

[0133] The receiving module 510 is used to receive a first signed HTTP request sent by the previous node. When receiving the first signed HTTP request sent by the previous node, the second aspect 420 intercepts the first signed HTTP request, verifies the previous node signature in the first signed HTTP request, and obtains a first unsigned HTTP request after the verification is successful. The first unsigned HTTP request is then received by the current node. The first unsigned HTTP request is an HTTP request from the first signed HTTP request with the previous node signature removed.

[0134] Processing module 520 is used to process the first unsigned HTTP request;

[0135] The return module 530 is used to return the response to the previous node when a response to the first unsigned HTTP request is received.

[0136] Optionally, the processing module 520 includes:

[0137] The first response generation unit is used to generate a response to the first unsigned HTTP request based on the first unsigned HTTP request.

[0138] Optionally, the processing module 520 includes:

[0139] The request generation unit is configured to generate a second unsigned HTTP request to be sent to the next node based on the first unsigned HTTP request.

[0140] The request sending unit sends the second unsigned HTTP request to the next node. When sending the second unsigned HTTP request to the next node, the first aspect of the current node intercepts the second unsigned HTTP request, adds the current node's signature to the second unsigned HTTP request, generates a second signed HTTP request, and sends the second signed HTTP request to the next node.

[0141] The second response generation unit is used to generate a response to the first unsigned HTTP request based on the response returned by the next node.

[0142] Furthermore, the second cross-section includes:

[0143] The first signature information acquisition unit is used to acquire, based on the previous node identifier, the previous node public key, the previous node digest algorithm, the previous node encryption algorithm, and the addition position of the previous node signature.

[0144] The signature verification unit is used to verify the signature of the previous node based on the previous node's public key, previous node's digest algorithm, previous node's encryption algorithm, and the location where the previous node's signature was added.

[0145] The designature unit is used to remove the previous node signature from the first signed HTTP request after the verification is successful, so as to obtain the first unsigned HTTP request.

[0146] Furthermore, the HTTP request processing device also includes a first aspect, which is configured on the server-side application node and includes:

[0147] The second signature information acquisition unit is used to obtain the current node's private key, current node digest algorithm, current node encryption algorithm, and the position for adding the current node's signature based on the current node identifier;

[0148] The signature generation unit is used to generate a signature for the current node based on the current node's private key, the current node's digest algorithm, and the current node's encryption algorithm.

[0149] The signing unit adds the current node's signature to the second unsigned HTTP request according to the current node's signature addition position, and generates the second signed HTTP request.

[0150] Optionally, at least one of the following is different: the current node digest algorithm is different from the previous node digest algorithm; the current node encryption algorithm is different from the previous node encryption algorithm; and the current node signature addition position is different from the previous node signature addition position. The previous node generates the first signature HTTP request based on the previous node digest algorithm, the previous node encryption algorithm, and the previous node signature addition position.

[0151] It should be noted that the HTTP request processing device provided in this application embodiment and the HTTP request processing method for server application nodes provided in this application embodiment are based on the same inventive concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the corresponding HTTP request processing method for server application nodes mentioned above, and repeated details will not be repeated.

[0152] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0153] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0154] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0155] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing one or more embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0156] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0157] Embodiments in this specification are described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable parallel device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable parallel device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0158] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable fraud device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0159] These computer program instructions can also be loaded onto a computer or other programmable device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0160] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0161] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0162] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0163] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0164] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0165] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0166] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0167] The above description is merely an embodiment of this specification and is not intended to limit this application. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. An HTTP request processing method, applied to a gateway node in a target link, wherein the target link is an HTTP request link within a business system; the method includes: Receive a first HTTP request sent by a client application node, wherein the first HTTP request is an HTTP request in which the client node signature is added to the original HTTP request; The client node signature in the first HTTP request is verified, and the original HTTP request is obtained after the verification is successful. Send the original HTTP request to the server application node in the target link; The gateway node is equipped with a first aspect. When the original HTTP request is sent to the server application node, the first aspect intercepts the original HTTP request, adds the gateway node signature to the original HTTP request, generates a second HTTP request, and sends the second HTTP request to the server application node.

2. The HTTP request processing method according to claim 1, wherein verifying the client node signature in the first HTTP request includes: Obtain the client node public key and a first preset digest algorithm, wherein the client node signature is generated based on the client node private key corresponding to the client node public key and the first preset digest algorithm; The client node signature is decrypted using the client node's public key to obtain a first message digest, wherein the first message digest is generated by the client application node based on the original HTTP request message and the first preset digest algorithm; A comparison digest is generated based on the first HTTP request and the first preset digest algorithm; The comparison digest is checked to see if it matches the first message digest. If they match, the verification is considered successful.

3. The HTTP request processing method according to claim 1, wherein, The step of adding a gateway node signature to the original HTTP request to generate the second HTTP request includes: A second message digest is extracted from the original HTTP request according to a second preset digest algorithm; The gateway node's private key is used to encrypt the second message digest to obtain the gateway node's signature; The gateway node signature is added to a specified location in the original HTTP request to obtain the second HTTP request.

4. The HTTP request processing method according to claim 3, wherein, The step of extracting the second message digest from the original HTTP request according to the second preset digest algorithm includes: The request parameters are obtained from the original HTTP request message according to the second preset digest algorithm, the request parameters are sorted in a specified order, and the second message digest is generated based on the sorted request parameters.

5. The HTTP request processing method according to claim 3, wherein adding a gateway node signature to the original HTTP request to generate the second HTTP request further includes: Before using the gateway node private key, obtain the gateway node private key from the remote key hosting platform based on the gateway node identifier; After using the gateway node private key, destroy the gateway node private key.

6. An HTTP request processing method, applied to a server application node in a target link, wherein the target link is an HTTP request link within a business system; The server-side application node is configured with a second aspect, and the method includes: The current node receives a first signed HTTP request sent by the previous node in the target link. When receiving the first signed HTTP request sent by the previous node, the second aspect of the current node intercepts the first signed HTTP request, verifies the previous node's signature in the first signed HTTP request, and obtains a first unsigned HTTP request after the verification is successful. The first unsigned HTTP request is then received by the current node. The first unsigned HTTP request is an HTTP request from the first signed HTTP request with the previous node's signature removed. Process the first unsigned HTTP request; Upon receiving a response to the first unsigned HTTP request, the response is returned to the previous node; The processing of the first unsigned HTTP request includes: A second unsigned HTTP request is generated based on the first unsigned HTTP request and is to be sent to the next node. Send the second unsigned HTTP request to the next node in the target link; The server application node is equipped with a first aspect. When sending the second unsigned HTTP request to the next node, the first aspect intercepts the second unsigned HTTP request, adds the current node's signature to the second unsigned HTTP request, generates a second signed HTTP request, and sends the second signed HTTP request to the next node.

7. The HTTP request processing method according to claim 6, wherein processing the first unsigned HTTP request includes: Generate a response to the first unsigned HTTP request based on the first unsigned HTTP request.

8. The HTTP request processing method according to claim 6, wherein the second aspect verifies the signature of the previous node in the first signed HTTP request, and after successful verification, obtains the first unsigned HTTP request, comprising: The previous node's public key, digest algorithm, encryption algorithm, and signature addition position are obtained based on the previous node's identifier. The previous node generates the first signature HTTP request based on the previous node's digest algorithm, encryption algorithm, and signature addition position. The signature of the previous node in the first signed HTTP request is verified based on the previous node's public key, previous node digest algorithm, previous node encryption algorithm, and the location where the previous node's signature is added. After successful verification, the signature of the previous node is removed from the first signed HTTP request, resulting in the first unsigned HTTP request.

9. The HTTP request processing method according to claim 6, wherein the first aspect adds the current node's signature to the second unsigned HTTP request to generate a second signed HTTP request, comprising: Retrieve the current node's private key, digest algorithm, encryption algorithm, and signature insertion position based on the current node's identifier; Generate the current node signature based on the current node's private key, current node's digest algorithm, and current node's encryption algorithm; The current node signature is added to the second unsigned HTTP request based on the current node signature addition position, and the second signed HTTP request is generated.

10. The HTTP request processing method according to claim 9, wherein, The current node digest algorithm is different from the previous node digest algorithm, the current node encryption algorithm is different from the previous node encryption algorithm, and the position where the current node signature is added is different from the position where the previous node signature is added. The first signing HTTP request is generated based on the previous node digest algorithm, the previous node encryption algorithm, and the position where the previous node signature is added.

11. An HTTP request processing device, comprising: Gateway node, which is a node in the target link, and the target link is an HTTP request link within the business system; The gateway node includes: The receiving module is used to receive the first HTTP request from the client application node, wherein the first HTTP request is an HTTP request in which the client node signature is added to the original HTTP request. The verification module is used to verify the client node signature in the first HTTP request, and obtain the original HTTP request after the verification is successful. The sending module is used to send the original HTTP request to the server application node in the target link; The gateway node is equipped with a first aspect. When the original HTTP request is sent to the server application node, the first aspect intercepts the original HTTP request, adds the gateway node signature to the original HTTP request, generates a second HTTP request, and sends the second HTTP request to the server application node.

12. An HTTP request processing device, comprising a server application node and a second aspect, the second aspect being disposed on the server application node, the server application node being a node in a target link, the target link being an HTTP request link within a business system, the server application node comprising: The receiving module is used to receive the first signed HTTP request sent by the previous node. When receiving the first signed HTTP request sent by the previous node, the second aspect of the current node intercepts the first signed HTTP request, verifies the previous node's signature in the first signed HTTP request, and obtains the first unsigned HTTP request after the verification is successful. The first unsigned HTTP request is then received by the current node. The first unsigned HTTP request is an HTTP request from the first signed HTTP request with the previous node's signature removed. The processing module is used to process the first unsigned HTTP request; The return module is used to return the response to the previous node when a response to the first unsigned HTTP request is received; The processing of the first unsigned HTTP request includes: A second unsigned HTTP request is generated based on the first unsigned HTTP request and is to be sent to the next node. Send the second unsigned HTTP request to the next node in the target link; The server application node is equipped with a first aspect. When sending the second unsigned HTTP request to the next node, the first aspect intercepts the second unsigned HTTP request, adds the current node's signature to the second unsigned HTTP request, generates a second signed HTTP request, and sends the second signed HTTP request to the next node.

Images