Network request protection method, electronic equipment, storage medium and program product

Abstract

The embodiment of the invention provides a network request protection method, an electronic device, a storage medium and a program product, and the method comprises the steps: receiving a first network request sent by a client device, the first network request comprising user information and signature information, the signature information is determined according to a first network request method, a path, a request body, a timestamp and a first block head key; verifying the timestamp, the signature information and the first block head key; under the condition that the timestamp, the signature information and the first block head key pass verification, service data corresponding to the first network request are obtained, a second block head key is generated according to the service data and the first block head key, the service data and the second block head key are sent to the client device, and the service data and the second block head key are generated based on browser fingerprints, so that even if the Cookie is stolen, the service data can be saved. In addition, an attacker cannot generate effective signatures on different devices, and the private key corresponding to the device cannot be obtained, so that the network request is prevented from being tampered, and the security of network transmission is improved.

Description

Technical Field

[0001] This application relates to the field of network technology, and more specifically, to a method for protecting network requests, an electronic device, a storage medium, and a program product. Background Technology

[0002] In existing web application security architectures, cookies are the primary means of maintaining user session state. However, cookies are highly vulnerable to XSS (Cross-Site Scripting) attacks. Once an attacker obtains a user's cookie, they can completely impersonate the user and perform arbitrary operations, posing a serious security risk. Currently, defenses against network attacks are implemented using methods such as HttpOnly Cookies and CSP (Content Security Policy). However, regardless of the method, once a cookie is compromised, network data will be leaked. Summary of the Invention

[0003] The purpose of some embodiments of this application is to provide a method, electronic device, storage medium, and program product for protecting network requests. Through the technical solutions of the embodiments of this application, a first network request sent by a client device is received, wherein the first network request includes at least user information and signature information, the signature information being determined based on the first network request method, path, request body, timestamp, and first header key; the timestamp, the signature information, and the first header key are verified; if the timestamp, the signature information, and the first header key pass verification, service data corresponding to the first network request is obtained, and a second network request is generated based on the service data and the first header key. The system generates a unique device key based on the client browser fingerprint and sends the business data and the second block key to the client device. In this embodiment, a blockchain-like request chain mechanism is constructed. That is, by receiving the signature information and user information sent by the client device, the system verifies the signature information and user information respectively. If all parameters pass the verification, a new block key is generated based on the block key in the signature information and the determined business data. In this way, based on browser fingerprint generation, even if the cookie is stolen, the attacker cannot generate a valid signature on different devices because they cannot obtain the private key corresponding to that device, thus preventing network requests from being tampered with and improving the security of network transmission.

[0004] Firstly, some embodiments of this application provide a method for protecting network requests, including: Receive a first network request sent by a client device, wherein the first network request includes at least user information and signature information, and the signature information is determined based on the first network request method, path, request body, timestamp and first header key; Verify the timestamp, the signature information, and the first block header key; If the timestamp, the signature information, and the first header key are verified, the service data corresponding to the first network request is obtained, and a second header key is generated based on the service data and the first header key, and the service data and the second header key are sent to the client device. Some embodiments of this application generate a unique device key based on the client browser fingerprint and construct a blockchain-like request chain mechanism. Specifically, it receives signature information and user information from the client device and verifies both. If all parameters pass verification, a new block header key is generated based on the block header key in the signature information and the determined business data. Thus, based on browser fingerprint generation, even if cookies are stolen, attackers cannot generate valid signatures on different devices because they cannot obtain the private key corresponding to that device, preventing network requests from being tampered with and improving network transmission security.

[0005] Optionally, before receiving the first network request sent by the client device, the method further includes: Obtain the browser fingerprint identifier sent by the client device, wherein the browser fingerprint identifier is obtained by hashing the browser's configuration parameters, and the browser's configuration parameters include at least fonts and hardware characteristics; Using a key derivation function, a preset private key corresponding to the user information and the client device is generated from the browser's configuration parameters, user information, and preset key. Based on the preset private key, a corresponding preset public key is generated.

[0006] Optionally, the signature information is obtained by the client device using the preset public key to perform asymmetric encryption on the first network request method, path, request body, timestamp, and first header key.

[0007] Some embodiments of this application, during the user login phase, combine the irreversible browser fingerprint and user identity to derive a unique cryptographic key pair (private key and public key) on the server side, which is bound to a specific device and user. The server uses the master key and key derivation function to generate the device key. The principle that the private key is never transmitted and only exists on the server side is followed. The "browser fingerprint" is used as a necessary factor for key generation, thereby realizing device binding.

[0008] Optionally, the verification of the timestamp, the signature information, and the first block header key includes: Determine whether the timestamp is within a preset time range; If the timestamp is within the preset time range, then the preset public key in the first network request is obtained, and the corresponding preset private key is found based on the preset public key; The signature information is decrypted using the preset private key to obtain decrypted plaintext data; The decrypted plaintext data is compared with the data in the request body of the first network request; If the decrypted plaintext data matches the data in the request body, then the first header key is verified.

[0009] In some embodiments of this application, replay protection is achieved by verifying whether the timestamp is within a reasonable time window. Based on the public key in the request header, the server finds the corresponding user device private key. This allows the server to locate the private key and then use it to decrypt the signature information, obtaining the plaintext. The decrypted plaintext is then compared with the received request data to verify whether they are consistent. Optionally, the step of verifying the first header key if the decrypted plaintext data matches the data in the request body includes: The first block header key is compared with the pre-stored hash value; If the first block header key matches the pre-stored hash value, then the first block header key is determined to be verified. Some embodiments of this application verify whether the previously obtained hash obtained through decryption is consistent with the latest hash value recorded by the server, ensuring that the request order has not been tampered with and guaranteeing the integrity of the chain.

[0010] Optionally, the step of obtaining service data corresponding to the first network request, and generating a second header key based on the service data and the first header key, and sending the service data and the second header key to the client device, if the timestamp, the signature information, and the first header key are verified, includes: If the timestamp, the signature information, and the first header key are verified, the service data corresponding to the first network request is obtained; Perform a hash operation on the business data to obtain a first hash value; The first hash value and the first block header key are concatenated to obtain concatenated data; The concatenated data is hashed to obtain the second header key.

[0011] Some embodiments of this application utilize the verification result (block header hash) of the previous request as the signature factor for the current request, forming a chain structure. The key point is that when the client signs, the data to be signed must include: the request content, a timestamp, and the previous block header hash. A unique signing mechanism uses a public key (not a private key) issued by the server to encrypt the above data. During server verification, a three-step verification process of "decrypting the signature - matching the request - verifying the chain integrity" must be executed. The server generates and returns a new block header hash to continue the steps of the request chain.

[0012] Optionally, performing a hash operation on the business data to obtain a first hash value includes: The business data is hashed using a preset hash algorithm to obtain the first hash value, wherein the preset hash algorithm includes at least one of a message digest algorithm or a secure hash algorithm; Correspondingly, the step of performing a hash operation on the concatenated data to obtain the second header key includes: The pre-defined hash algorithm is used to perform a hash operation on the concatenated data to obtain the second hash value, and the second hash value is determined as the second header key.

[0013] Optionally, the method further includes: In the case of receiving multiple second network requests, determine the order of network responses corresponding to the second network requests; The third header key corresponding to the last response is determined based on the last response in the network response sequence.

[0014] In some embodiments of this application, the client concurrently signs multiple requests based on the same preceding block header hash. The server can verify these concurrent requests in parallel and generate a new block header hash independently for each request. The concurrent processing mechanism satisfies the actual situation of browser concurrency limitations while ensuring the effectiveness of security verification.

[0015] Optionally, the method further includes: Determine whether the third header key is the latest hash value in the blockchain; If the third header key is the latest hash value, then the blockchain is updated. The third header key is used to generate the hash value for the next network request.

[0016] In some embodiments of this application, the chain structure ensures that the order of requests can be verified, preventing request reordering attacks. The client uses the last received new hash as the block header key for subsequent requests based on the order of response arrival. This is similar to the concept of "uncle blocks" in blockchain, which guarantees both concurrency and eventual consistency.

[0017] Secondly, some embodiments of this application provide a network request protection device, including: A receiving module is configured to receive a first network request sent by a client device, wherein the first network request includes at least user information and signature information, and the signature information is determined based on the first network request method, path, request body, timestamp, and first header key; The verification module is used to verify the timestamp, the signature information, and the first block header key; The generation module is configured to, upon verification of the timestamp, the signature information, and the first header key, obtain service data corresponding to the first network request, generate a second header key based on the service data and the first header key, and send the service data and the second header key to the client device.

[0018] Some embodiments of this application generate a unique device key based on the client browser fingerprint and construct a blockchain-like request chain mechanism. Specifically, it receives signature information and user information from the client device and verifies both. If all parameters pass verification, a new block header key is generated based on the block header key in the signature information and the determined business data. Thus, based on browser fingerprint generation, even if cookies are stolen, attackers cannot generate valid signatures on different devices because they cannot obtain the private key corresponding to that device, preventing network requests from being tampered with and improving network transmission security.

[0019] Optionally, the receiving module is configured to: Obtain the browser fingerprint identifier sent by the client device, wherein the browser fingerprint identifier is obtained by hashing the browser's configuration parameters, and the browser's configuration parameters include at least fonts and hardware characteristics; Using a key derivation function, a preset private key corresponding to the user information and the client device is generated from the browser's configuration parameters, user information, and preset key. Based on the preset private key, a corresponding preset public key is generated.

[0020] Optionally, the signature information is obtained by the client device using the preset public key to perform asymmetric encryption on the first network request method, path, request body, timestamp, and first header key.

[0021] Some embodiments of this application, during the user login phase, combine the irreversible browser fingerprint and user identity to derive a unique cryptographic key pair (private key and public key) on the server side, which is bound to a specific device and user. The server uses the master key and key derivation function to generate the device key. The principle that the private key is never transmitted and only exists on the server side is followed. The "browser fingerprint" is used as a necessary factor for key generation, thereby realizing device binding.

[0022] Optionally, the verification module is used for: Determine whether the timestamp is within a preset time range; If the timestamp is within the preset time range, then the preset public key in the first network request is obtained, and the corresponding preset private key is found based on the preset public key; The signature information is decrypted using the preset private key to obtain decrypted plaintext data; The decrypted plaintext data is compared with the data in the request body of the first network request; If the decrypted plaintext data matches the data in the request body, then the first header key is verified.

[0023] In some embodiments of this application, replay protection is achieved by verifying whether the timestamp is within a reasonable time window. Based on the public key in the request header, the server finds the corresponding user device private key. This allows the server to locate the private key and then use it to decrypt the signature information, obtaining the plaintext. The decrypted plaintext is then compared with the received request data to verify whether they are consistent. Optionally, the verification module is used for: The first block header key is compared with the pre-stored hash value; If the first block header key matches the pre-stored hash value, then the first block header key is determined to be verified. Some embodiments of this application verify whether the previously obtained hash obtained through decryption is consistent with the latest hash value recorded by the server, ensuring that the request order has not been tampered with and guaranteeing the integrity of the chain.

[0024] Optionally, the generation module is used for: If the timestamp, the signature information, and the first header key are verified, the service data corresponding to the first network request is obtained; Perform a hash operation on the business data to obtain a first hash value; The first hash value and the first block header key are concatenated to obtain concatenated data; The concatenated data is hashed to obtain the second header key.

[0025] Some embodiments of this application utilize the verification result (block header hash) of the previous request as the signature factor of the current request to form a chain structure. When the client signs, the data to be signed must include: request content, timestamp, and the previous block header hash. The above data is encrypted using the public key (not the private key) issued by the server as a unique signing mechanism. When the server verifies, it must perform a three-step verification process of "decrypting the signature - matching the request - verifying the chain integrity". The server generates and returns a new block header hash to continue the steps of the request chain.

[0026] Optionally, the generation module is used for: The business data is hashed using a preset hash algorithm to obtain the first hash value, wherein the preset hash algorithm includes at least one of a message digest algorithm or a secure hash algorithm; Correspondingly, the generation module is used for: The pre-defined hash algorithm is used to perform a hash operation on the concatenated data to obtain the second hash value, and the second hash value is determined as the second header key.

[0027] Optionally, the generation module is used for: In the case of receiving multiple second network requests, determine the order of network responses corresponding to the second network requests; The third header key corresponding to the last response is determined based on the last response in the network response sequence.

[0028] In some embodiments of this application, the client concurrently signs multiple requests based on the same preceding block header hash. The server can verify these concurrent requests in parallel and generate a new block header hash independently for each request. The concurrent processing mechanism satisfies the actual situation of browser concurrency limitations while ensuring the effectiveness of security verification.

[0029] Optionally, the generation module is used for: Determine whether the third header key is the latest hash value in the blockchain; If the third header key is the latest hash value, then the blockchain is updated. The third header key is used to generate the hash value for the next network request.

[0030] In some embodiments of this application, the chain structure ensures that the order of requests can be verified, preventing request reordering attacks. The client uses the last received new hash as the block header key for subsequent requests based on the order of response arrival. This is similar to the concept of "uncle blocks" in blockchain, which guarantees both concurrency and eventual consistency.

[0031] Thirdly, some embodiments of this application provide an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, can implement the network request protection method as described in any embodiment of the first aspect.

[0032] Fourthly, some embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the network request protection method as described in any embodiment of the first aspect.

[0033] Fifthly, some embodiments of this application provide a computer program product, the computer program product including a computer program, wherein the computer program, when executed by a processor, can implement the network request protection method as described in any embodiment of the first aspect. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of some embodiments of this application, the accompanying drawings used in some embodiments of this application will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 A flowchart illustrating a method for protecting network requests provided in an embodiment of this application; Figure 2 A flowchart illustrating another method for protecting network requests provided in an embodiment of this application; Figure 3 A flowchart illustrating another method for protecting network requests provided in an embodiment of this application; Figure 4 A schematic diagram of a network request protection device provided in an embodiment of this application; Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0036] The technical solutions of some embodiments of this application will now be described with reference to the accompanying drawings.

[0037] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0038] In existing web application security systems, cookies are the primary means of maintaining user session state. However, cookies are highly vulnerable to XSS (Cross-Site Scripting) attacks. Once an attacker obtains a user's cookie, they can completely impersonate the user and perform arbitrary operations, posing a serious security risk. Currently, defenses against network attacks are implemented using methods such as HttpOnly Cookies and CSP (Content Security Policy). However, regardless of the method, once a cookie is compromised, network data will be leaked. Therefore, some embodiments of this application provide a method for protecting network requests. This method includes receiving a first network request sent by a client device, wherein the first network request includes at least user information and signature information, the signature information being determined based on the first network request method, path, request body, timestamp, and first header key; verifying the timestamp, signature information, and first header key; and, if the timestamp, signature information, and first header key pass verification, obtaining business data corresponding to the first network request, and processing the data based on the business data and the first header key. The system generates a second header key and sends business data and the second header key to the client device. In this embodiment, a unique device key is generated based on the client browser fingerprint, and a blockchain-like request chain mechanism is constructed. That is, by receiving the signature information and user information sent by the client device, the signature information and user information are verified respectively. If all parameters pass the verification, a new header key is generated based on the header key in the signature information and the determined business data. In this way, based on browser fingerprint generation, even if the cookie is stolen, the attacker cannot generate a valid signature on different devices because they cannot obtain the private key corresponding to that device, thus preventing network requests from being tampered with and improving the security of network transmission.

[0039] like Figure 1 As shown, an embodiment of this application provides a method for protecting network requests, the method comprising: S101. Receive a first network request sent by a client device, wherein the first network request includes at least user information and signature information, and the signature information is determined based on the first network request method, path, request body, timestamp and first block header key; Specifically, the embodiments of this application are applied to a protection system, which includes a client device and a server device. The client device runs a JavaScript SDK in the user's browser, and the server device is deployed as an authentication and verification service in the business backend, including a fingerprint processing module, a key management module, a signature verification module, and a chain management module.

[0040] The client device encrypts the first network request method, path, request body, timestamp, and first header key to obtain signature information. It then logs in on the client device using user information, which includes at least the login account. Based on the timestamp, user information, signature information, and public key, the client device generates an HTTP request, i.e., the first network request, and sends this HTTP request to the server device.

[0041] S102. Verify the timestamp, signature information, and first block header key; The server parses the first network request and obtains the timestamp, signature information, public key, and first header key from the first network request. Then, it verifies the timestamp, public key, signature information, and first header key respectively. This can prevent network request replay, verify the signature, and ensure the integrity of the data chain.

[0042] S103. If the timestamp, signature information and first header key are verified, obtain the service data corresponding to the first network request, generate the second header key based on the service data and the first header key, and send the service data and the second header key to the client device. Specifically, when the timestamp, signature information, and first header key are verified, the server device obtains the business data corresponding to the first network request, performs a hash operation on the business data, and concatenates the hash result with the first header key to obtain a concatenated result. Then, it performs a hash operation on the concatenated result to generate a second header key, and sends the second header key and the business data to the client device. The second header key is used by the client device when sending a network request next time.

[0043] The network request anti-tampering method provided in this application embodiment generates a device unique key based on the client browser fingerprint and constructs a blockchain-like request chain mechanism. This ensures that even if the cookie is stolen, attackers cannot forge a valid request signature, fundamentally defending against XSS attacks based on cookie theft and ensuring the integrity, timeliness, and non-repudiation of each request.

[0044] Some embodiments of this application generate a unique device key based on the client browser fingerprint and construct a blockchain-like request chain mechanism. Specifically, it receives signature information and user information from the client device and verifies both. If all parameters pass verification, a new block header key is generated based on the block header key in the signature information and the determined business data. Thus, based on browser fingerprint generation, even if cookies are stolen, attackers cannot generate valid signatures on different devices because they cannot obtain the private key corresponding to that device, preventing network requests from being tampered with and improving network transmission security.

[0045] Another embodiment of this application further supplements the description of the network request protection method provided in the above embodiments.

[0046] like Figure 2 As shown, before receiving the first network request sent by the client device, the method further includes: Obtain the browser fingerprint identifier sent by the client device. The browser fingerprint identifier is obtained by hashing the browser's configuration parameters, which include at least fonts and hardware characteristics. Using a key derivation function, a preset private key corresponding to the user information and client device is generated from the browser's configuration parameters, user information, and preset key. Generate a corresponding preset public key based on the preset private key.

[0047] Optionally, the signature information is obtained by the client device using a preset public key to perform asymmetric encryption on the first network request method, path, request body, timestamp, and first header key.

[0048] Specifically, step one: Generate a device private key upon login: 1) Collect browser fingerprint: Log in on the client device using user information. The client SDK collects various irreversible identifiers of the user's browser (such as Canvas, WebGL, AudioContext, font, UserAgent, hardware characteristics, etc.) and generates a unique and stable browser fingerprint identifier through a specific algorithm, namely a hash algorithm (such as MurmurHash).

[0049] 2) Derivation of encryption key: After receiving the login request and browser fingerprint, the server device combines the user information with a server-preset master key. The user information is the user's identity ID, such as the username. The key derivation function (such as HKDF) is used to process the user information and the server-preset master key to derive a unique device private key for the "user-device" combination.

[0050] 3) Secure transmission of public key: The server device returns the public key corresponding to its private key to the client device. The client device stores this public key in memory and does not persist it (it is cleared when the session ends). The default private key is never stored or appears on the client device; it is only secretly stored by the server device.

[0051] Some embodiments of this application, during the user login phase, combine the irreversible browser fingerprint and user identity to derive a unique cryptographic key pair (private key and public key) on the server side, which is bound to a specific device and user. The server uses a preset master key and key derivation function to generate a device key. The principle that the private key is never transmitted and only stored on the server side is followed. The "browser fingerprint" is used as a necessary factor for key generation, thereby realizing device binding.

[0052] Optionally, the timestamp, signature information, and first block header key are verified, including: Determine if the timestamp is within a preset time range; If the timestamp is within the preset time range, the preset public key in the first network request is obtained, and the corresponding preset private key is found based on the preset public key; The signature information is decrypted using a preset private key to obtain the decrypted plaintext data; Compare the decrypted plaintext data with the data in the request body of the first network request; If the decrypted plaintext data matches the data in the request body, then the first header key is verified.

[0053] In some embodiments of this application, replay protection is achieved by verifying whether the timestamp is within a reasonable time window. Based on the public key in the request header, the server finds the corresponding user device private key. This allows the server to locate the private key and then use it to decrypt the signature information, obtaining the plaintext. The decrypted plaintext is then compared with the received request data to verify whether they are consistent. Optionally, if the decrypted plaintext data matches the data in the request body, the first header key is verified, including: Compare the first header key with the pre-stored hash value; If the first header key matches the pre-stored hash value, then the first header key is verified. Specifically, step two: The server-side device constructs the request chain and performs signature verification. 1) Initialize the request chain: After a user successfully logs in, the server device initializes a "quasi-blockchain" structure for the session. The "genesis block" of this chain is a random number generated by the server device.

[0054] 2) Client device requests encryption and signature: a. Before the client initiates any business request, it first retrieves the latest "block header key" (i.e., the hash value returned by the response of the previous request) from memory.

[0055] b. The client device combines the current request method, path, request body, timestamp, and header key into plaintext data to be signed.

[0056] c. The client device uses the public key issued by the server device to perform asymmetric encryption on this plaintext data and generate a signature.

[0057] d. The client puts the encrypted signature, timestamp, public key, and unencrypted block header key into a specific header of the HTTP request (such as Signature-Header).

[0058] 3) Server-side device verification: a. Anti-replay: Verify whether the timestamp is within a reasonable time window.

[0059] b. Find the private key: Based on the public key in the request header, the server finds the corresponding user device private key.

[0060] c. Signature Verification: Decrypt the signature information using the private key to obtain the plaintext data. Compare the decrypted plaintext with the received request data to verify their consistency.

[0061] Specifically, after the server device decrypts the signature information, it obtains the decrypted plaintext data and compares the decrypted plaintext data with the data in the request body of the first network request.

[0062] d. Verify chain integrity: Verify whether the previous hash obtained from decryption is consistent with the latest hash value recorded by the server to ensure that the request order has not been tampered with.

[0063] Specifically, the server compares the received first block header key (hash value) with the latest block header password stored on the server (i.e., the latest hash value recorded by the server). If the two are the same, it means that the order of network requests has not been tampered with.

[0064] e. Generate a new header: After successful verification, the server device obtains the business data corresponding to the first network request, uses the SHA-256 algorithm to calculate the hash value of the current request's business data, and combines it with the first header key in the first network request received. Then, it performs a hash operation on the combined data to obtain a new hash value, namely the second header key, which serves as the new header key for the next request.

[0065] f. Response: After the business processing is completed, the server returns the new Hash, i.e. the second header key, along with the business data corresponding to the first network request to the client device. After receiving the second header key, the client device updates it to the "header key" for the next request.

[0066] Some embodiments of this application verify whether the previously obtained hash obtained through decryption is consistent with the latest hash value recorded by the server, ensuring that the request order has not been tampered with and guaranteeing the integrity of the chain.

[0067] Optionally, if the timestamp, signature information, and first header key are verified, service data corresponding to the first network request is obtained, and a second header key is generated based on the service data and the first header key. The service data and the second header key are then sent to the client device, including: If the timestamp, signature information, and first header key are verified, obtain the business data corresponding to the first network request; Perform a hash operation on the business data to obtain the first hash value; The first hash value and the first header key are concatenated to obtain the concatenated data; The concatenated data is hashed to obtain the second header key.

[0068] Some embodiments of this application utilize the verification result (block header hash) of the previous request as the signature factor for the current request, forming a chain structure. When the client signs, the data to be signed must include: the request content, a timestamp, and the previous block header hash. A unique signing mechanism uses a public key (not a private key) issued by the server to encrypt the above data. During server verification, a three-step verification process of "decrypting the signature - matching the request - verifying the chain integrity" must be executed. The server generates and returns a new block header hash to continue the steps of the request chain.

[0069] Optionally, a hash operation is performed on the business data to obtain a first hash value, including: A preset hash algorithm is used to perform hash operations on the business data to obtain a first hash value. The preset hash algorithm includes at least one of the following: a message digest algorithm or a secure hash algorithm. Correspondingly, a hash operation is performed on the concatenated data to obtain the second header key, which includes: The pre-defined hash algorithm is used to perform a hash operation on the concatenated data to obtain the second hash value, and the second hash value is determined as the second header key.

[0070] Optionally, the method further includes: In the case of receiving multiple second network requests, determine the order of network responses corresponding to the second network requests; Determine the third header key corresponding to the last response in the network response sequence.

[0071] In some embodiments of this application, the client concurrently signs multiple requests based on the same preceding block header hash. The server can verify these concurrent requests in parallel and generate a new block header hash independently for each request. The concurrent processing mechanism satisfies the actual situation of browser concurrency limitations while ensuring the effectiveness of security verification.

[0072] Optionally, the method further includes: Determine if the third header key is the latest hash value in the blockchain; If the third header key is the latest hash value, the blockchain is updated. The third header key is used to generate the hash value for the next network request.

[0073] Specifically, based on the above embodiments, the device in this application embodiment can also perform concurrent processing, that is, support a concurrent forking mechanism.

[0074] Step 3: Handle concurrent requests as follows: To support browser concurrency (such as 6 concurrent connections in HTTP / 1.1), embodiments of this application allow for brief forks in the "request chain".

[0075] The client device can initiate up to N (e.g., 6) requests simultaneously, all of which are signed using the same current block header key. The server device processes these requests in parallel, and the verification and generation of a new hash for each request are independent. The server device maintains a lightweight chain state, allowing it to receive multiple requests based on the same parent hash and generate a different new hash for each request.

[0076] The client uses the most recently received hash as the block header key for subsequent sequential requests, based on the order of responses. This mechanism is similar to the "uncle block" concept in blockchain, ensuring concurrency and eventual consistency.

[0077] For example, in the above example steps, the "block header key" is a constantly changing chain of pointers that closely links historical requests with the current request. The "Hash of the current request" is calculated based on the content of the response to this request, ensuring that the response cannot be tampered with. The "new block header key" is a product of the previous chain state and the result of this request, making the entire chain irreversible and tamper-proof.

[0078] To support the browser's concurrent request capabilities, in this embodiment, the client device can initiate multiple requests simultaneously. These requests are all signed using the same parent block header key. The server device processes these requests in parallel, with each request's verification and new hash generation being independent. The server device maintains a lightweight chain state, capable of receiving multiple requests based on the same parent hash and generating a different new hash for each successful request. The client device uses the last received new hash as the block header key for subsequent requests, based on the order in which responses arrive. This is similar to the concept of "uncle blocks" in blockchain, ensuring both concurrency and eventual consistency.

[0079] The following example uses Li Si's concurrent requests. If the current block header key is H0, and three API requests are simultaneously signed using H0 on the client: ReqA: Query user information (GET / api / userinfo) ReqB: Query the order list (GET / api / orders) ReqC: Query message notifications (GET / api / notifications) The server-side device processes these three requests in parallel, generating an independent sub-hash for each successful request, such as... Figure 3 As shown: The following is an example of blockchain state record data on the server side: {"session_list":{"latestHash":"H0", "forkedHashes":["HA", "HB","HC"]}} For example, in the three concurrent requests above, the response arrival order is A->B->C, so the final chain state is H0->HC (HA and HB both become "uncle blocks"). When the next request is initiated, the HC of the last response is used as the prevHash hash value for encryption.

[0080] During server-side device verification, it checks whether prevHash: "HC" is already in the recorded hash. Since it is in forkedHashes, if the verification passes, a new Hash: HD is generated for the next request, updated to the latest Hash, i.e., "latestHash": "HD", and the forked record is cleared.

[0081] In this embodiment, allowing transient forks is a key parameter for concurrency control. Although transient forks exist, client devices determine the main chain through a last-in-first-out principle, ensuring that all clients eventually converge to the same state. Even with forks, signature verification and chain association for each request remain effective, and security is not compromised by concurrency. Moreover, the server only needs to maintain the hashes of the most recent forks; older fork states can be periodically cleaned up to avoid state bloat. This design provides good concurrency performance without compromising chain security, making it ideal for high-concurrency scenarios in web front-ends. It supports concurrent request processing while maintaining the order and correlation verification between requests.

[0082] This application's embodiments allow for brief forks in the request chain to support browser concurrency, and manage the states of multiple concurrent chain heads through a server-side mechanism, allowing clients to concurrently sign multiple requests based on the same preceding block header hash. The server-side device can verify these concurrent requests in parallel and generate a new block header hash independently for each request. The client device updates its local chain head state according to the response order, similar to the "uncle block" concept in blockchain, which addresses the problem of chain structure conflicts in concurrent web scenarios.

[0083] In some embodiments of this application, the chain structure ensures that the order of requests can be verified, preventing request reordering attacks. The client uses the last received new hash as the block header key for subsequent requests based on the order of response arrival. This is similar to the concept of "uncle blocks" in blockchain, which guarantees both concurrency and eventual consistency.

[0084] By way of example, this application embodiment clearly and intuitively shows the flow and changes of data through a specific implementation example, setting the following data scenario: (1) User: Zhang San (userId:1) (2) Current block header key: a1b2c3d4e5… (This is the hash value returned by the server after the previous request, which is saved by the client); (3) This request: query user balance, the request method is GET, and the request path is / api / blance; (4) Timestamp: 1761374138871 (representing 2025-10-25 14:35:38) The client device sends the first network request. First, it obtains the block header key. The client device reads the latest block header key a1b2c3d4e5… from memory; and constructs the plaintext to be signed. The client device concatenates the following data according to a predefined format (such as a JSON string); For example: {"method":"GET","path":" / api / balance","timestamp":"1761374138871","preHavh":"a1b2c3d4e5…"}, This concatenated string is called textA, which is the plaintext data to be signed.

[0085] The client device uses the public key issued by the server to encrypt the plaintext data textA to be signed. The encrypted ciphertext is the signature information of this request, called SignatureA, which is usually transmitted after being Base64 encoded.

[0086] When a client initiates an HTTP request, it carries the following in the header: Signature-Header:signature=SignatureA,Timestamp=1761374138871,Public-Key:…(client public key),prev-hash=a1b2c3d4e5…; After receiving the first network request, the server retrieves the data from the first network request and performs verification, including: 1. To prevent replay, the server-side device checks whether timestamp=1761374138871 is within a certain range (e.g., 2 minutes) before or after the server's current time. If so, the replay is allowed.

[0087] 2. Query the private key. The server device searches the database for the private key corresponding to userId 1 based on the public-key in the header. This private key is called PrivateKey_zhang.

[0088] 3. Verify the signature. The server uses PrivateKey_zhang to decrypt SignatureA. After successful decryption, the resulting plaintext data is called DecryptedTextA. The server compares DecryptedTextA with a string it concatenates based on the received request information (method, path, request body, timestamp, prev-hash). If the two are completely identical, the signature verification is successful.

[0089] 4. Generate a new block header key. The server device calculates the SHA-256 hash of the business data requested in this request, such as the JSON returned after a successful balance query ({"balance":"100"}). Let's assume the result is: f6g7h8i9j10...; The previous hash and the current hash are concatenated together, and the SHA-256 is calculated again to generate a new hash value, for example, k11l12m13…; The server updates the latest hash value of Zhang San's session to k11l12m13... 5. After the server-side device finishes processing the business logic, it returns the business result and the new block header key to the client: {"data":{"balance":100},nextHash:"k11l12m13..."}.

[0090] Furthermore, this application embodiment uses a user performing a series of operations in an online banking system as a scenario.

[0091] Background: User "Amy" uses her browser to log in to an online banking system to perform the aforementioned security verification method.

[0092] Login and Key Initialization 1. Device fingerprint acquisition and key derivation Amy logs in with her username and password. The client SDK collects her browser fingerprint (Canvas, font, hardware, etc.) to generate a fingerprint identifier FP_Amy. The login request sends FP_Amy and the username "Amy" to the server. The server uses the master key and HKDF functions to derive the device private key Priv_A from the unique combination ("Amy", FP_Amy) and stores it in a secure database. Simultaneously, it calculates the corresponding public key Pub_A. The server returns Pub_A to Amy's browser, which stores it in memory.

[0093] 2. Calculate the chain initialization. After successful login, the server generates a "genesis block" random number, Block_123, for Amy's session and returns it to the client as the first block header key. The client stores Block_123 in memory. At this point, the chain state of the client and the server is synchronized, both being Block_123.

[0094] Sequential requests and chained verification 1. Client constructs request: Query balance Retrieve the current block header key from memory: Block_123. Assemble the plaintext to be signed: Plaintext1 = {"method": "GET", "path": " / balance", "body": "", "timestamp": T1, "prevHash":"Block_123"}. Encrypt Plaintext1 using the public key Pub_A to obtain the signature Sig1. Send the request, including (Sig1, T1, Pub_A, Block_123) in the header.

[0095] 2. Server-side verification and chain update Find Priv_A through Pub_A, decrypt Sig1 to obtain Plaintext1, and verify it. Verify that the prevHash in Plaintext1 matches the Block_123 recorded on the server. Process the query and return the balance data {"balance": 100}.

[0096] Generate a new block header key: Calculate the hash of the current response data, H1 = SHA-256('{"balance":100}'). Combine H1 with Block_123 to generate a new block header key NextHash_A = SHA-256(Block_123 + H1). Return NextHash_A along with the balance data to the client and update the server-side chain state to NextHash_A.

[0097] 3. Client update After receiving the response, the client replaces Block_123 in memory with NextHash_A.

[0098] At this point, an immutable request chain has been formed: Block_123 → NextHash_A → NextHash_B. Any attempt to advance the request or perform a replay attack will be immediately rejected by the server due to a mismatch in the prevHash verification.

[0099] Furthermore, as demonstrated in the preceding implementation examples, this invention perfectly supports the browser's concurrent request capabilities by allowing brief chain forks, avoiding blocking and improving the user experience. Simultaneously, the eventual consistency model ensures the eventual unification of the chain, achieving concurrent performance without sacrificing ultimate security guarantees.

[0100] This application combines the chain structure of blockchain with cryptographic signatures to build a dynamic security protection system for Web API interactions that is tamper-proof, replay-proof, supports concurrency, and does not rely on fixed tokens, effectively solving the key security problems faced in the prior art.

[0101] The present invention has the following significant advantages: Strong device binding: The key is generated based on the browser fingerprint. Even if the cookie is stolen, the attacker will not be able to generate a valid signature on different devices because they cannot obtain the private key corresponding to that device.

[0102] Proactive security: Shifts from passive cookie protection to proactive request signature verification, making security independent of client-side storage security.

[0103] Comprehensive protection: It defends against multiple attacks, including XSS, CSRF, request replay, and request tampering.

[0104] Guaranteeing request order: The chained structure ensures that the order of requests can be verified, preventing request reordering attacks.

[0105] High-performance concurrency: The innovative concurrency processing mechanism not only meets the actual needs of browser concurrency limits, but also ensures the effectiveness of security verification.

[0106] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.

[0107] Another embodiment of this application provides a network request protection device for performing the network request protection method provided in the above embodiments.

[0108] like Figure 4 The diagram shown is a structural schematic of a network request protection device provided in an embodiment of this application. The network request protection device includes a receiving module 301, a verification module 302, and a generation module 303, wherein: The receiving module 301 is used to receive a first network request sent by the client device, wherein the first network request includes at least user information and signature information, and the signature information is determined according to the first network request method, path, request body, timestamp and first block header key; Verification module 302 is used to verify the timestamp, signature information, and first block header key; The generation module 303 is used to obtain the service data corresponding to the first network request when the timestamp, signature information and first header key are verified, and to generate a second header key based on the service data and the first header key, and send the service data and the second header key to the client device.

[0109] Some embodiments of this application generate a unique device key based on the client browser fingerprint and construct a blockchain-like request chain mechanism. Specifically, it receives signature information and user information from the client device and verifies both. If all parameters pass verification, a new block header key is generated based on the block header key in the signature information and the determined business data. Thus, based on browser fingerprint generation, even if cookies are stolen, attackers cannot generate valid signatures on different devices because they cannot obtain the private key corresponding to that device, preventing network requests from being tampered with and improving network transmission security.

[0110] Regarding the apparatus in this embodiment, the specific manner in which each module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0111] Another embodiment of this application further supplements the description of the network request protection device provided in the above embodiments.

[0112] Optionally, the receiving module is used for: Obtain the browser fingerprint identifier sent by the client device. The browser fingerprint identifier is obtained by hashing the browser's configuration parameters, which include at least fonts and hardware characteristics. Using a key derivation function, a preset private key corresponding to the user information and client device is generated from the browser's configuration parameters, user information, and preset key. Generate a corresponding preset public key based on the preset private key.

[0113] Optionally, the signature information is obtained by the client device using a preset public key to perform asymmetric encryption on the first network request method, path, request body, timestamp, and first header key.

[0114] Some embodiments of this application, during the user login phase, combine the irreversible browser fingerprint and user identity to derive a unique cryptographic key pair (private key and public key) on the server side, which is bound to a specific device and user. The server uses the master key and key derivation function to generate the device key. The principle that the private key is never transmitted and only exists on the server side is followed. The "browser fingerprint" is used as a necessary factor for key generation, thereby realizing device binding.

[0115] Optionally, the verification module is used for: Determine if the timestamp is within a preset time range; If the timestamp is within the preset time range, the preset public key in the first network request is obtained, and the corresponding preset private key is found based on the preset public key; The signature information is decrypted using a preset private key to obtain the decrypted plaintext data; Compare the decrypted plaintext data with the data in the request body of the first network request; If the decrypted plaintext data matches the data in the request body, then the first header key is verified.

[0116] In some embodiments of this application, replay protection is achieved by verifying whether the timestamp is within a reasonable time window. Based on the public key in the request header, the server finds the corresponding user device private key. This allows the server to locate the private key and then use it to decrypt the signature information, obtaining the plaintext. The decrypted plaintext is then compared with the received request data to verify whether they are consistent. Optionally, the verification module is used for: Compare the first header key with the pre-stored hash value; If the first header key matches the pre-stored hash value, then the first header key is verified. Some embodiments of this application verify whether the previously obtained hash obtained through decryption is consistent with the latest hash value recorded by the server, ensuring that the request order has not been tampered with and guaranteeing the integrity of the chain.

[0117] Optionally, a generation module is used for: If the timestamp, signature information, and first header key are verified, obtain the business data corresponding to the first network request; Perform a hash operation on the business data to obtain the first hash value; The first hash value and the first header key are concatenated to obtain the concatenated data; The concatenated data is hashed to obtain the second header key.

[0118] Some embodiments of this application utilize the verification result (block header hash) of the previous request as the signature factor of the current request to form a chain structure. When the client signs, the data to be signed must include: request content, timestamp, and the previous block header hash. The above data is encrypted using the public key (not the private key) issued by the server as a unique signing mechanism. When the server verifies, it must perform a three-step verification process of "decrypting the signature - matching the request - verifying the chain integrity". The server generates and returns a new block header hash to continue the steps of the request chain.

[0119] Optionally, a generation module is used for: A preset hash algorithm is used to perform hash operations on the business data to obtain a first hash value. The preset hash algorithm includes at least one of the following: a message digest algorithm or a secure hash algorithm. Correspondingly, the generation module is used for: The pre-defined hash algorithm is used to perform a hash operation on the concatenated data to obtain the second hash value, and the second hash value is determined as the second header key.

[0120] Optionally, a generation module is used for: In the case of receiving multiple second network requests, determine the order of network responses corresponding to the second network requests; Determine the third header key corresponding to the last response in the network response sequence.

[0121] In some embodiments of this application, the client concurrently signs multiple requests based on the same preceding block header hash. The server can verify these concurrent requests in parallel and generate a new block header hash independently for each request. The concurrent processing mechanism satisfies the actual situation of browser concurrency limitations while ensuring the effectiveness of security verification.

[0122] Optionally, a generation module is used for: Determine if the third header key is the latest hash value in the blockchain; If the third header key is the latest hash value, the blockchain is updated. The third header key is used to generate the hash value for the next network request.

[0123] In some embodiments of this application, the chain structure ensures that the order of requests can be verified, preventing request reordering attacks. The client uses the last received new hash as the block header key for subsequent requests based on the order of response arrival. This is similar to the concept of "uncle blocks" in blockchain, which guarantees both concurrency and eventual consistency.

[0124] Regarding the apparatus in this embodiment, the specific manner in which each module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0125] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.

[0126] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, can implement the operation of any of the methods corresponding to the network request protection methods provided in the above embodiments.

[0127] This application also provides a computer program product, which includes a computer program, wherein when the computer program is executed by a processor, it can implement the operation of any of the methods corresponding to the network request protection methods provided in the above embodiments.

[0128] like Figure 5 As shown, some embodiments of this application provide an electronic device 400, which includes: a memory 410, a processor 420, and a computer program stored in the memory 410 and executable on the processor 420. When the processor 420 reads the program from the memory 410 via a bus 430 and executes the program, it can implement any of the methods included in the above-described network request protection method.

[0129] Processor 420 can process digital signals and may include various computing architectures. For example, it may be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 420 may be a microprocessor.

[0130] Memory 410 can be used to store instructions executed by processor 420 or data related to the execution of instructions. These instructions and / or data may include code for implementing some or all of the functions of one or more modules described in the embodiments of this application. The processor 420 of this disclosure embodiment can be used to execute instructions in memory 410 to implement the methods shown above. Memory 410 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memories well known to those skilled in the art.

[0131] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0132] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0133] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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 limitations, 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.

Claims

1. A method for protecting a network request, characterized in that, The method comprises: receiving a first network request sent by a client device, wherein the first network request comprises at least user information and signature information, and the signature information is determined according to a method, a path, a request body, a timestamp and a first block header key of the first network request; verifying the timestamp, the signature information and the first block header key; in a case where the timestamp, the signature information and the first block header key pass the verification, obtaining service data corresponding to the first network request, generating a second block header key according to the service data and the first block header key, and sending the service data and the second block header key to the client device.

2. The method of claim 1, wherein the first network request is a request for a web page. Before receiving the first network request sent by the client device, the method further comprises: obtaining a browser fingerprint identifier sent by the client device, wherein the browser fingerprint identifier is obtained by performing a hash operation on configuration parameters of a browser, and the configuration parameters of the browser at least include fonts and hardware characteristics; generating a preset private key corresponding to the user information and the client device by using a key derivation function on the configuration parameters of the browser, the user information and a preset key; generating a corresponding preset public key according to the preset private key.

3. The method of claim 2, wherein the first network request is a request for a web page. The signature information is obtained by performing asymmetric encryption on the method, the path, the request body, the timestamp and the first block header key of the first network request by the client device using the preset public key.

4. The method of claim 1, wherein the first network request is a request for a web page. The verification of the timestamp, the signature information and the first block header key comprises: determining whether the timestamp is within a preset time range; in a case where the timestamp is within the preset time range, obtaining a preset public key in the first network request, and searching for a corresponding preset private key according to the preset public key; decrypting the signature information according to the preset private key to obtain decrypted plaintext data; comparing the decrypted plaintext data with data in the request body in the first network request; in a case where the decrypted plaintext data matches the data in the request body, verifying the first block header key.

5. The method of claim 4, wherein the first network request is a request for a web page. The verification of the first block header key in a case where the decrypted plaintext data matches the data in the request body comprises: comparing the first block header key with a pre-stored hash value; in a case where the first block header key matches the pre-stored hash value, determining that the first block header key passes the verification.

6. The method of claim 1, wherein the first network request is a request for a web page. The verification of the first block header key in a case where the decrypted plaintext data matches the data in the request body comprises: comparing the first block header key with a pre-stored hash value; in a case where the first block header key matches the pre-stored hash value, determining that the first block header key passes the verification. The verification of the first block header key in a case where the decrypted plaintext data matches the data in the request body comprises: in a case where the timestamp, the signature information and the first block header key pass the verification, obtaining service data corresponding to the first network request; performing a hash operation on the service data to obtain a first hash value; splicing the first hash value and the first block header key to obtain spliced data; Hashing the spliced data to obtain the second block header key.

7. The method of claim 6, wherein the first network request is a request for a web page. The hashing the service data to obtain the first hash value comprises: hashing the service data by using a preset hash algorithm to obtain the first hash value, wherein the preset hash algorithm at least includes one of message digest algorithm or secure hash algorithm; Correspondingly, the hashing the spliced data to obtain the second block header key comprises: hashing the spliced data by using the preset hash algorithm to obtain a second hash value, and determining the second hash value as the second block header key.

8. The network-requested protection method of claim 1, wherein, The method further comprises: in the case of receiving a plurality of second network requests, determining a network response order corresponding to the second network requests; determining a third block header key corresponding to the last response in the network response order according to the last response.

9. The network-requested protection method of claim 8, wherein, The method further comprises: judging whether the third block header key is the latest hash value in the block chain or not; if the third block header key is the latest hash value, updating the block chain, and the third block header key is used to generate a hash value of a next network request.

10. An electronic device, comprising: The computer readable storage medium stores a computer program, and the program is executed by the processor to implement the network request protection method of any one of claims 1-9.

11. A computer readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the program is executed by the processor to implement the network request protection method of any one of claims 1-9.

12. A computer program product comprising a computer program, wherein, The computer program is executed by the processor to implement the network request protection method of any one of claims 1-9.

Images