Anti-replay method and device for service request, computer device and storage medium

Abstract

This application discloses a method, apparatus, computer device, and storage medium for preventing replay of business requests. The method includes: a client encapsulating a business request, its corresponding first identity information, and a first timestamp, and sending the encapsulated first data packet to a server; the server parsing the first data packet to obtain the business request, the first identity information, and the first timestamp, and determining whether the business request is a short-term replay request based on the first identity information, the first timestamp, and cached data; if the business request is not a short-term replay request, determining whether the business request is a long-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp and a preset time difference threshold. This application provides a replay prevention scheme that does not require strict time synchronization, does not increase the number of interactions, does not require random number management, is easy to implement, and can be rigorously proven mathematically.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a method, apparatus, computer device, and storage medium for preventing replay of service requests. Background Technology

[0002] A replay attack refers to an attacker intercepting a legitimate communication data packet and retransmitting it at a later time or in a different scenario to trick the recipient into performing an unexpected operation. For example, in identity authentication or payment transactions, replaying a successful business request could lead to duplicate charges or unauthorized authorization. Anti-replay mechanisms aim to ensure the uniqueness and timeliness of each business request, preventing it from being maliciously reused. In the field of network security, anti-replay technology is often used in conjunction with encryption, digital signatures, and other technologies, and is a crucial element in ensuring communication security. Among related technologies, anti-replay techniques are mainly based on timestamps, random numbers, or combinations thereof, which suffer from strong dependence on time synchronization, high interaction counts, high memory consumption, and complex implementation, making them difficult to widely apply. Summary of the Invention

[0003] This application provides a method, apparatus, computer device, and storage medium for preventing replay of business requests. It implements a replay prevention scheme that does not require strict time synchronization, does not increase the number of interactions, does not require random number management, is easy to implement, and can be rigorously proven mathematically. While ensuring the security of replay prevention, it significantly reduces the requirements for system resources and time synchronization, simplifies the implementation scheme, and can be widely applied in various network communication scenarios.

[0004] In a first aspect, embodiments of this application provide a method for preventing replay of business requests. The method includes: responding to a first data packet from a client, parsing the first data packet to obtain a business request, first identity information corresponding to the business request, and a first timestamp, wherein the first timestamp refers to the current timestamp when the client generates the business request; determining whether the business request belongs to a short-term replay request based on the first identity information, the first timestamp, and cached data, wherein the cached data includes at least one timestamp and identity information and cache expiration time corresponding to each timestamp; if the business request does not belong to a short-term replay request, determining whether the business request belongs to a long-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp, and a preset time difference threshold, wherein the second timestamp refers to the current timestamp when the server parses the first data packet, and the cache expiration time is greater than or equal to twice the preset time difference threshold.

[0005] In some embodiments, determining whether a business request is a short-term replay request based on the first identity information, the first timestamp, and the cached data includes: if the cached data includes the first timestamp and the identity information corresponding to the first timestamp in the cached data is the first identity information, then the business request is determined to be a short-term replay request; if the cached data does not include the first timestamp, or if the cached data includes the first timestamp and the identity information corresponding to the first timestamp in the cached data is not the first identity information, then the business request is determined not to be a short-term replay request, and the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp are written into the cached data.

[0006] In some embodiments, the above-mentioned method for preventing replay of business requests further includes: sending a first error message to the client when the business request is a short-term replay request.

[0007] In some embodiments, determining whether a service request belongs to a long-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp and a preset time difference threshold includes: if the absolute value of the deviation is greater than or equal to the preset time difference threshold, then the service request is determined to be a long-term replay request; if the absolute value of the deviation is less than the preset time difference threshold, then the service request is determined not to be a long-term replay request.

[0008] In some embodiments, the above-mentioned method for preventing replay of business requests further includes: sending a second error message to the client when the business request is a long-term replay request, and clearing the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp from the cached data.

[0009] In some embodiments, the above-mentioned method for preventing replay of business requests further includes: if the business request is not a long-term replay request, authenticating the client based on the first identity information; if the client is authenticated, generating a business response corresponding to the business request, encapsulating the business response to obtain a second data packet; and sending the second data packet to the client.

[0010] In some embodiments, after authenticating the client based on the first identity information, the method further includes: if the client fails to authenticate, sending a third error message to the client and clearing the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp from the cached data.

[0011] Secondly, embodiments of this application provide a device for preventing replay of business requests. The device includes: a data packet parsing module, configured to: parse a first data packet from a client to obtain a business request, first identity information corresponding to the business request, and a first timestamp, wherein the first timestamp refers to the current timestamp of the client when generating the business request; a short-term replay judgment module, configured to: determine whether the business request belongs to a short-term replay request based on the first identity information, the first timestamp, and cached data, wherein the cached data includes at least one timestamp and identity information and cache expiration time corresponding to each timestamp; and a long-term replay judgment module, configured to: determine whether the business request belongs to a long-term replay request if the business request does not belong to a short-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp, and a preset time difference threshold, wherein the second timestamp refers to the current timestamp of the server when parsing the first data packet, and the cache expiration time is greater than or equal to twice the preset time difference threshold.

[0012] Thirdly, embodiments of this application provide a computer device, including: a memory storing computer programs or instructions thereon; and a processor for executing the computer programs or instructions in the memory to implement the anti-replay method for service requests as described above.

[0013] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program or instructions stored thereon, wherein the computer program or instructions, when executed by a processor, implement the anti-replay method for the service request as described above.

[0014] In summary, the technical solution provided in this application involves the client encapsulating a business request, its corresponding first identity information, and a first timestamp, and sending the encapsulated first data packet to the server. The server parses the first data packet to obtain the business request, the first identity information, and the first timestamp. Based on the first identity information, the first timestamp, and cached data, the server determines whether the business request is a short-term replay request. If the business request is not a short-term replay request, the server further determines whether the business request is a long-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp and a preset time difference threshold. The cached data includes at least one timestamp, the identity information corresponding to each timestamp, and the cache expiration time. The server uses the parsed first identity information and the first timestamp as query conditions to check if a matching entry exists in the cached data, thus determining whether the business request initiated by the client is a short-term replay request. This approach eliminates the need for additional random numbers, reducing computation and storage costs. Furthermore, it achieves precise isolation of business requests through identity information, avoiding global collisions. Furthermore, the cache expiration time is set to be greater than or equal to twice the preset time difference threshold. Regardless of whether the client's time is faster or slower than the server's time, any intercepted and replayed business request will be identified. This tolerates clock skew while ensuring that replay attacks cannot exploit time window vulnerabilities, achieving a balance between security and flexibility. In addition, this application embodiment can identify both short-term and long-term replay attacks, clearly distinguishing replay attack types and improving the ability to detect replay attacks, thus assisting operations and maintenance personnel in locating problems. Therefore, this application embodiment provides an anti-replay scheme that does not require strict time synchronization, does not increase the number of interactions, does not require random number management, is easy to implement, and can be rigorously mathematically proven. While ensuring anti-replay security, it significantly reduces the requirements for system resources and time synchronization, simplifies the implementation scheme, and is widely applicable in various network communication scenarios. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of a timestamp-based anti-replay scheme; Figure 2 This is a schematic diagram of a replay prevention scheme based on random numbers; Figure 3 This is a schematic diagram of an anti-replay scheme based on a combination of timestamps and random numbers; Figure 4 This is a schematic diagram of a communication system provided in an embodiment of this application; Figure 5 This is a flowchart of a method for preventing replay of business requests provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating an anti-replay principle provided in an embodiment of this application; Figure 7 This is a schematic diagram of another anti-replay principle provided in an embodiment of this application; Figure 8 This is a flowchart of another method for preventing replay of service requests provided in an embodiment of this application; Figure 9 This is a schematic diagram of a service request anti-replay scheme provided in an embodiment of this application; Figure 10 This is a flowchart of another method for preventing replay of service requests provided in an embodiment of this application; Figure 11 This is a schematic diagram of a service request anti-replay device provided in an embodiment of this application; Figure 12 This is a schematic diagram of another anti-replay device for service requests provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified. Furthermore, "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.

[0019] The use of "applies to" or "configured to" in this application implies open and inclusive language, which does not exclude the applicability to or configuration of devices to perform additional tasks or steps. Additionally, the use of "based on" implies open and inclusive language, meaning that processes, steps, calculations, or other actions "based on" one or more of the stated conditions or values ​​may in practice be based on additional conditions or values ​​beyond those stated.

[0020] In the description of this application, "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0021] Among related technologies, anti-replay technology is mainly based on timestamps, random numbers, or combinations thereof, but each has its limitations, as shown below.

[0022] Please see Figure 1 , Figure 1 This is a schematic diagram of a timestamp-based anti-replay scheme.

[0023] like Figure 1 As shown, the anti-replay scheme may include: time synchronization between the client and the server; the client generates a timestamp Ts1 and identity information S, then encrypts the business request, timestamp Ts1 and identity information S to obtain a data packet Ekey (request||S||Ts1), and sends the data packet Ekey (request||S||Ts1) to the server; the server decrypts the data packet Ekey (request||S||Ts1) to obtain the business request, timestamp Ts1 and identity information S, then obtains the server's timestamp Ts2, verifies whether the time difference |Ts2 – Ts1| is less than a preset threshold ΔT, verifies the identity information S, and finally generates a business response for the business request and sends the business response to the client.

[0024] Therefore, the principle of the timestamp-based anti-replay scheme is as follows: the client appends the current timestamp Ts1 to the request data packet, and the server obtains the local time Ts2 after receiving the request data packet and calculates the time difference |Ts2 – Ts1|; if the time difference |Ts2 – Ts1| is less than the preset threshold ΔT (such as 5 minutes), the business request is considered fresh, otherwise it is rejected.

[0025] The timestamp-based anti-replay scheme has the following problems: 1) Strict time synchronization requirement: It requires strict synchronization between the client and the server time. Otherwise, legitimate requests may be misjudged due to clock deviation, or attackers can replay requests using the time window (as long as the request is sent multiple times within the window); 2) Inability to prevent replay within the window: Even if the server records the timestamp, if the time window is set too large (to tolerate clock deviation), attackers can replay the same timestamp business request multiple times within the window, and the server cannot distinguish them (because the same timestamp only appears once. If it is not recorded, replay cannot be prevented; if it is recorded, all timestamps need to be stored, causing memory problems).

[0026] Please see Figure 2 , Figure 2 This is a schematic diagram of a replay prevention scheme based on random numbers.

[0027] like Figure 2 As shown, the anti-replay scheme may include: the client requesting a random number from the server; the server generating a random number RN1 (challenge value), adding the random number RN1 to the cache, and sending the random number RN1 to the client; the client generating identity information S, then encrypting the business request, identity information S, and random number RN1 to obtain a data packet Ekey (request||S||RN1), and sending the data packet Ekey (request||S||RN1) to the server; the server decrypting the data packet Ekey (request||S||RN1) to obtain the business request, identity information S, and random number RN1, querying the random number RN1 in the cache, verifying the identity information S, and finally generating a business response for the business request and sending the business response to the client.

[0028] Therefore, the principle of the anti-replay scheme based on random numbers is as follows: the server sends a random number (challenge value) to the client each time, the client encrypts or signs the random number and returns it (response), the server verifies the correctness of the response and ensures that the random number has not been reused.

[0029] The replay prevention scheme based on random numbers has the following problems: 1) Increased number of interactions: A challenge-response handshake is required before each business request, which doubles the number of communication rounds, introduces additional latency, and seriously affects business scenarios with high real-time requirements (such as high-frequency APIs and real-time transactions); 2) Random number generation and management overhead: It is necessary to ensure the unpredictability and global uniqueness of random numbers, which increases the system complexity; the server needs to store all used random numbers, and the memory usage increases linearly with the number of requests.

[0030] Please see Figure 3 , Figure 3 This is a schematic diagram of a replay prevention scheme based on a combination of timestamps and random numbers.

[0031] like Figure 3 As shown, the anti-replay scheme may include: time synchronization between the client and the server; the client generates a timestamp Ts1 and a random number RN1, generates identity information S, and then encrypts the business request, identity information S, timestamp Ts1, and random number RN1 to obtain a data packet Ekey (request||S||Ts1||RN1), and sends the data packet Ekey (request||S||Ts1||RN1) to the server; the server decrypts the data packet Ekey (request||S||Ts1||RN1) to obtain the business request, identity information S, timestamp Ts1, and random number RN1, then obtains the server's timestamp Ts2, verifies whether the time difference |Ts2 – Ts1| is less than a preset threshold ΔT, verifies whether the random number RN1 exists in the cache and has not expired (if the random number RN1 already exists, it is a replay request and the request is rejected; if the random number RN1 does not exist, it is stored in the cache and an expiration date is set), verifies the identity information S, and finally generates a business response for the business request and sends the business response to the client.

[0032] Therefore, the principle of the anti-replay scheme based on the combination of timestamps and random numbers is as follows: combining the timeliness of timestamps and the uniqueness of random numbers, the client attaches both timestamps and random numbers to the request data packets, and the server verifies the validity of the timestamps and checks whether the random numbers are reused.

[0033] The anti-replay scheme based on a combination of timestamps and random numbers has the following problems: 1) Time synchronization is still required: The timestamp verification part still relies on the client and server times being basically consistent. If the clock deviation is too large, the time window still needs to be widened, leaving room for replay attacks; 2) Parameter configuration is complex: It is necessary to set the time window threshold and the validity period of the random number at the same time, and the two need to be coordinated (usually the validity period of the random number is slightly longer than the time window), but it lacks strict mathematical constraints and is easy to introduce security vulnerabilities or misjudgments due to improper configuration; 3) Implementation complexity is high: It is necessary to manage two independent parameters at the same time and handle two kinds of logic in the verification process, which increases the code complexity and the probability of error.

[0034] The shortcomings of anti-replay technologies in related fields can be summarized as follows: 1) Strong dependence on time synchronization: Traditional timestamp-based anti-replay schemes require strict time synchronization between the client and the server; in actual distributed systems, factors such as device clock drift and network latency often cause time deviations, causing legitimate requests to be misjudged as replays due to time window discrepancies, or attackers to exploit time window vulnerabilities to launch attacks; this limits the applicability of anti-replay schemes in heterogeneous environments (such as IoT and mobile applications); 2) Increased interaction count leads to performance degradation: Challenge-response mechanisms based on random numbers require an additional handshake process before a complete business interaction (the server sends a random number, the client returns a response). (Returning encrypted results) not only increases the number of communication rounds but also introduces additional latency, affecting user experience, and is especially unsuitable for high-frequency real-time interaction scenarios; 3) High server-side storage overhead: Whether it is a pure random number scheme or a combination of timestamps and random numbers, the server usually needs to maintain a list of used random numbers (such as a database or cache) and set an expiration date; as the number of requests increases, the storage pressure increases linearly, occupying a large amount of memory resources for a long time, making it difficult to support high-concurrency systems; 4) High implementation complexity: Anti-replay schemes combining timestamps and random numbers need to manage time windows and random number states at the same time, with complex parameter configuration, high development and maintenance costs, and easy to introduce logical vulnerabilities.

[0035] In summary, the anti-replay technology in the relevant technologies has problems such as strong dependence on time synchronization, high number of interactions, high memory consumption, and complex implementation, making it difficult to meet the comprehensive requirements of modern distributed systems for efficiency, scalability, and security.

[0036] In view of this, embodiments of this application provide a method, apparatus, computer device, and storage medium for preventing replay of business requests. This enables a replay prevention scheme that does not require strict time synchronization, does not increase the number of interactions, does not require random number management, is easy to implement, and can be rigorously proven mathematically. While ensuring replay prevention security, embodiments of this application significantly reduce the requirements for system resources and time synchronization, simplify the implementation scheme, and are applicable to various network communication scenarios, especially distributed systems with high requirements for real-time performance and scalability.

[0037] Please see Figure 4 , Figure 4 This is a schematic diagram of a communication system provided in an embodiment of this application. For example... Figure 4 As shown, the communication system may include a first device 410 and a second device 420.

[0038] The first device 410 may be a client 411 running the target service, such as a mobile phone, tablet computer, laptop computer, smart wearable device, desktop computer, vehicle terminal, smart robot, smart home appliance, etc.

[0039] The second device 420 runs a server 421 that provides the target service. The second device 420 may be, for example, a server, desktop computer, computing cluster, edge computing node, cloud server, network device, edge server, etc.

[0040] The first device 410 and the second device 420 can be connected via a network, which can be a wired network (such as Ethernet, fiber optic, etc.), a wireless network (such as Bluetooth, Wi-Fi, 4G / 5G cellular mobile communication networks, etc.), or a combination of wired and wireless networks. This embodiment of the application does not limit this. Of course, in practical applications, the first device 410 and the second device 420 can also be connected via a hardwired connection. Because a connection is established between the first device 410 and the second device 420, the client 411 and the server 421 can interact with data to achieve the target service.

[0041] In this embodiment, client 411 can initiate a business request for the target service and encapsulate the business request and other auxiliary data (such as timestamps, identity information, etc.), and send the encapsulated encrypted data packet to server 421; server 421 can parse the encrypted data packet to obtain the business request and other auxiliary data (such as timestamps, identity information, etc.), and then perform replay judgment and / or authentication based on the other auxiliary data (such as timestamps, identity information, etc.), and then generate a business response for the business request and feed it back to client 411.

[0042] It should be understood that a target service refers to a specific function or business capability that the client 411 needs to access and the server 421 is responsible for providing in the communication system. In some embodiments, the target service may include, but is not limited to, user login service, payment transaction service, data query service, device control service, message push service, etc. The specific type of target service is not limited in this application embodiment. Based on this, a business request refers to the specific request data sent by the client 411 to the server 421 for invoking the target service; a business response refers to the result data returned by the server 421 to the client 411 after processing the business request.

[0043] For further details regarding the steps performed by the client 411 and the server 421 and their beneficial effects, please refer to the following embodiments, which will not be elaborated upon here.

[0044] Please see Figure 5 , Figure 5 This is a flowchart illustrating a method for preventing replay of service requests according to an embodiment of this application. This method for preventing replay of service requests can be applied to communication systems, such as those described above. Figure 1In the communication system shown, there is a client 411 in the first device 410 and a server 421 in the second device 420. Figure 5 As shown, the method for preventing replay of this service request may include the following steps S510 to S550.

[0045] Step S510: The client encapsulates the business request and the corresponding first identity information and first timestamp to obtain the first data packet.

[0046] This application does not limit the specific type of business request, and in practical applications, it can be flexibly set according to requirements. For example, business requests may include, but are not limited to: user login requests, payment transaction requests, data query requests, device control requests, message push requests, etc.

[0047] When generating a business request, the client can obtain the first identity information and first timestamp corresponding to the business request, and encapsulate the business request, the first identity information, and the first timestamp to obtain the first data packet. The first identity information uniquely identifies the initiating entity of the business request. For example, the first identity information can be the identifier of the user account logged into the client (such as ID, email, mobile phone number, etc.), or it can be the device identifier of the client's device (such as device code, MAC address, etc.), or it can be a session identifier, certificate / key, temporary credential, etc. The first timestamp refers to the current timestamp when the client generates the business request. For example, the first timestamp can be the timestamp corresponding to the moment the business request is generated, or it can be the timestamp corresponding to the moment the business request is encapsulated, etc. The client can obtain the first timestamp from the local clock of its device or a third-party time server.

[0048] It should be understood that the client can perform encryption processing during the encapsulation and acquisition of the first data packet to improve the security and integrity of the first data packet. This application embodiment does not limit the specific method of encryption processing; in practical applications, it can be flexibly set according to requirements. For example, encryption processing can be based on a pre-shared symmetric key, or it can be based on a symmetric key obtained through ECDH (Elliptic Curve Diffie-Hellman key Exchange) negotiation, or it can be directly based on an asymmetric key, or it can encrypt the symmetric key (digital envelope) based on an asymmetric key, etc. Taking encryption processing based on a symmetric key (the client and server each have the same symmetric key, which can be negotiated and calculated through ECDH, or it can be pre-shared) as an example, during the encapsulation of the first data packet, the client randomly selects an initial vector to symmetrically encrypt the business request, the first identity information, and the first timestamp as a whole, and calculates a message verification code for integrity protection. Taking encryption processing based on a public key (the server can transmit a public key to the client) as an example, during the encapsulation of the first data packet, the client can use this public key to encrypt plaintext.

[0049] Step S520: The client sends the first data packet to the server.

[0050] Step S530: The server parses the first data packet to obtain the business request and the first identity information and first timestamp corresponding to the business request.

[0051] The server parses the first data packet to obtain the business request, initial identity information, and initial timestamp. It should be understood that if encryption was performed during the client's encapsulation of the first data packet, the server needs to decrypt it accordingly during parsing. Taking symmetric key encryption as an example, during parsing the first data packet, the server extracts an initialization vector, calculates a Message Authentication Code (MAC) based on the symmetric key to verify integrity, and performs decryption based on the initialization vector after successful integrity verification. Taking public key encryption as an example, the server uses the private key for decryption during parsing the first data packet.

[0052] Step S540: The server determines whether the business request is a short-term replay request based on the first identity information, the first timestamp, and the cached data.

[0053] Cache data is historical request identification information temporarily stored by the server to maintain a replay prevention state. It is used to identify business requests submitted repeatedly within a short time window. In other words, cache data is a short-term memory of recently processed business requests by the server. In this embodiment, the cache data includes at least one timestamp, as well as the identity information and cache expiration time corresponding to each timestamp. If the cache data only records timestamps, multiple requests from the same initiating entity at the same timestamp will conflict; if the cache data only records identity information, multiple requests from the same initiating entity will be indistinguishable. This embodiment binds timestamps and identity information in the cache data to uniquely identify a specific entity's business request at a specific time. This ensures that the same timestamp from different initiating entities does not interfere with each other, achieving precise isolation of business requests and supporting multi-user concurrency. Furthermore, the cache expiration time defines the boundary of short-term replay. When the cache expiration time is reached, the corresponding cache data is automatically cleaned up, achieving efficient resource control.

[0054] The server uses the parsed first identity information and first timestamp as query conditions to check if a matching entry exists in the cached data to determine whether the business request initiated by the client is a short-term replay request. If a matching entry exists in the cached data, it is determined to be a short-term replay request; if no matching entry exists in the cached data, it is determined not to be a short-term replay request. In this case, the server can write the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp into the cached data for subsequent detection and judgment. For other descriptions regarding short-term replay judgment, please refer to the following embodiments, which will not be elaborated here.

[0055] Step S550: If the business request is not a short-term replay request, the server determines whether the business request is a long-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp, and the preset time difference threshold.

[0056] The second timestamp refers to the current timestamp of the server when parsing the first data packet. For example, the second timestamp could be the timestamp corresponding to the time when the first data packet was received, the timestamp corresponding to the time when the parsing of the first data packet started, or the timestamp corresponding to the time when the parsing of the first data packet was completed, etc. The server can obtain the second timestamp from the local clock of the device or a third-party time server.

[0057] If the business request is not a short-term replay request, the server further determines whether it is a long-term replay request to implement strict replay protection. Based on this, the server calculates the absolute value of the deviation between the first and second timestamps and compares this absolute value with a preset time difference threshold to determine if the business request is a long-term replay request. If the absolute value of the deviation is greater than the preset time difference threshold, it is determined to be a long-term replay request; if the absolute value of the deviation is less than the preset time difference threshold, it is determined not to be a long-term replay request. In this case, the server can further perform authentication, etc., to respond to the business request. For further details regarding long-term replay detection, authentication, request-response, etc., please refer to the following embodiments, which will not be elaborated here.

[0058] This application does not limit the specific value of the preset time difference threshold; in practical applications, it can be flexibly set according to requirements. For example, the server can set the preset time difference threshold based on business type. Furthermore, the server can set a specific value for the cache expiration time. To achieve strict replay prevention and avoid missing replay requests, in this application embodiment, the cache expiration time set by the server is greater than or equal to twice the preset time difference threshold.

[0059] Please see Figure 6 , Figure 6 This is a schematic diagram illustrating an anti-replay principle provided in an embodiment of this application. For example... Figure 6 As shown, the current timeline represents the server's timestamps. Assume the first timestamp of the client's business request is Ts1, and the identity information is S. The second timestamp obtained by the server is Ts2. Normally, when the server responds to the client's business request, it records: Ts1 < Ts2 and Ts2 - Ts1 < △T1 (a preset time difference threshold). The server sets a cache expiration time △T2 for Ts1 at Ts2. If the server receives the same business request (corresponding to Ts1 and S) at time Ts3 (Ts3 does not exceed the cache expiration time Ts2 + △T2 of Ts1), since Ts3 is within the cache expiration time and the cached data records Ts1 and S, it can be determined that Ts3 is a short-term replay. If the server receives the same business request (corresponding to Ts1 and S) at time Ts4 (Ts4 exceeds the cache expiration time Ts2 + △T2 of Ts1), since Ts4 - Ts1 > △T1, it can be determined that Ts4 is a long-term replay.

[0060] The proof process is as follows: Given that Ts4 - Ts2 > ΔT2, ΔT2 ≥ 2×ΔT1, and Ts1 < Ts2; since ΔT2 ≥ 2×ΔT1, then Ts4 - Ts2 > ΔT2 ≥ 2×ΔT1, that is, Ts4 - Ts2 > 2×ΔT1; because Ts1 < Ts2, so Ts2 - Ts1 > 0; adding Ts4 - Ts2 > 2×ΔT1 and Ts2 - Ts1 > 0 gives Ts4 - Ts2 + Ts2 - Ts1 > 2×ΔT1, that is, Ts4 - Ts1 > 2×ΔT1, so Ts4 - Ts1 > ΔT1.

[0061] Please refer to Figure 7 , Figure 7 which is a schematic diagram of another anti-replay principle provided by an embodiment of the present application. As Figure 7 shown, the current time axis is the timestamp of the server. Assume that the first timestamp corresponding to the service request initiated by the client is Ts1, the identity information is S, the second timestamp obtained by the server is Ts2, and the time of the client is faster than that of the server. Under normal circumstances, the server responds to the service request of the client. At this time, the server records: Ts1 > Ts2 and Ts1 - Ts2 < ΔT1 (preset time difference threshold), and the server sets the cache expiration time ΔT2 for Ts1 at Ts2. Assume that the server receives the same service request (corresponding to Ts1 and S) at Ts3 (Ts3 does not exceed the cache expiration time Ts2 + ΔT2 of Ts1). Since Ts3 is within the cache expiration time and the cache data records Ts1 and S, it can be determined that Ts3 belongs to short-term replay. Assume that the server receives the same service request (corresponding to Ts1 and S) at Ts4 (Ts4 exceeds the cache expiration time Ts2 + ΔT2 of Ts1). Since Ts4 - Ts1 > ΔT1, it can be determined that Ts4 belongs to long-term replay.

[0062] The proof process is as follows: Given that Ts4 - Ts2 > ΔT2, Ts1 - Ts2 < ΔT1, and ΔT2 ≥ 2×ΔT1; taking the inverse of Ts1 - Ts2 < ΔT1 gives -Ts1 + Ts2 > -ΔT1; adding Ts4 - Ts2 > ΔT2 and -Ts1 + Ts2 > -ΔT1 gives Ts4 - Ts2 - Ts1 + Ts2 > ΔT2 - ΔT1, that is, Ts4 - Ts1 > ΔT2 - ΔT1; since ΔT2 ≥ 2×ΔT1, then Ts4 - Ts1 > ΔT2 - ΔT1 ≥ 2×ΔT1 - ΔT1, that is, Ts4 - Ts1 > ΔT1.

[0063] Based on this, whether the time of the client is faster or slower than that of the server, any intercepted and replayed service request can be identified, ensuring that replay attacks cannot take advantage of the vulnerability of the time window while tolerating clock deviations, achieving the unity of security and flexibility.

[0064] In summary, the technical solution provided in this application involves the client encapsulating a business request, its corresponding first identity information, and a first timestamp, and sending the encapsulated first data packet to the server. The server parses the first data packet to obtain the business request, the first identity information, and the first timestamp. Based on the first identity information, the first timestamp, and cached data, the server determines whether the business request is a short-term replay request. If the business request is not a short-term replay request, the server further determines whether the business request is a long-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp and a preset time difference threshold. The cached data includes at least one timestamp, the identity information corresponding to each timestamp, and the cache expiration time. The server uses the parsed first identity information and the first timestamp as query conditions to check if a matching entry exists in the cached data, thus determining whether the business request initiated by the client is a short-term replay request. This approach eliminates the need for additional random numbers, reducing computation and storage costs. Furthermore, it achieves precise isolation of business requests through identity information, avoiding global collisions. Furthermore, the cache expiration time is set to be greater than or equal to twice the preset time difference threshold. Regardless of whether the client's time is faster or slower than the server's time, any intercepted and replayed business request will be identified. This tolerates clock skew while ensuring that replay attacks cannot exploit time window vulnerabilities, achieving a balance between security and flexibility. In addition, this application embodiment can identify both short-term and long-term replay attacks, clearly distinguishing replay attack types and improving the ability to detect replay attacks, thus assisting operations and maintenance personnel in locating problems. Therefore, this application embodiment provides an anti-replay scheme that does not require strict time synchronization, does not increase the number of interactions, does not require random number management, is easy to implement, and can be rigorously mathematically proven. While ensuring anti-replay security, it significantly reduces the requirements for system resources and time synchronization, simplifies the implementation scheme, and is widely applicable in various network communication scenarios.

[0065] In some embodiments, step S540 may include: if the cached data includes a first timestamp and the identity information corresponding to the first timestamp in the cached data is the first identity information, then the server determines that the business request belongs to a short-term replay request; if the cached data does not include a first timestamp, or if the cached data includes a first timestamp and the identity information corresponding to the first timestamp in the cached data is not the first identity information, then the server determines that the business request does not belong to a short-term replay request, and writes the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp into the cached data.

[0066] As shown in the above embodiments, the timestamp and identity information are interlinked in the cached data to uniquely identify a specific entity's business request at a specific time. This ensures that the same timestamp from different initiating entities does not interfere with each other, achieving precise isolation of business requests and supporting multi-user concurrency. Furthermore, the cached data also includes the cache expiration time corresponding to the timestamp to define short-term replay boundaries. When the cache expiration time is reached, the corresponding cached data is automatically cleaned up, achieving efficient resource control.

[0067] Based on this, this embodiment uses the first timestamp and first identity information parsed by the server as query conditions to check whether there is a matching entry in the cached data, in order to determine whether the business request initiated by the client belongs to a short-term replay request. If there is a matching entry in the cached data, that is, the cached data includes the first timestamp and the identity information corresponding to the first timestamp in the cached data is the first identity information, then it is determined that the business request initiated by the client belongs to a short-term replay request. If there is no matching entry in the cached data, that is, the cached data does not include the first timestamp, or the cached data includes the first timestamp and the identity information corresponding to the first timestamp in the cached data is not the first identity information, then it is determined that the business request initiated by the client does not belong to a short-term replay request. In this case, the server can set a cache expiration time for the first timestamp and write the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp into the cached data for subsequent detection and judgment.

[0068] In some embodiments, the above-described method for preventing replay of business requests may further include: the server sending a first error message to the client when the business request is a short-lived replay request. The first error message indicates that the business request has encountered an error, and the server may also indicate the error type of the business request in the first error message, such as the business request being a short-lived replay request. Of course, in practical applications, when the business request is a short-lived replay request, the server may also terminate the anti-replay process without sending a first error message to the client to indicate that the business request has encountered an error.

[0069] In some embodiments, step S550 may include: if the service request does not belong to a short-term replay request, the server calculates the absolute value of the deviation between the first timestamp and the second timestamp; if the absolute value of the deviation is greater than or equal to a preset time difference threshold, the server determines that the service request belongs to a long-term replay request; if the absolute value of the deviation is less than the preset time difference threshold, the server determines that the service request does not belong to a long-term replay request.

[0070] As can be seen from the above embodiments, the cache expiration time is set to be greater than or equal to twice the preset time difference threshold. Therefore, regardless of whether the client's time is faster or slower than the server's time, any intercepted and replayed business request will be identified. This ensures that replay attacks cannot exploit time window vulnerabilities while tolerating clock skew, thus achieving a strict anti-replay mechanism. For a detailed explanation of the anti-replay principle, please refer to the above embodiments; further details will not be elaborated here.

[0071] It should be understood that a cache expiration time greater than or equal to twice the preset time difference threshold is the minimum requirement to avoid missing replay requests. However, in practical applications, the cache expiration time △T2 can also be set to be greater than or equal to more than twice the preset time difference threshold △T1, such as △T2≥2×△T1+constant (the constant is a positive number) or △T2≥3×△T1. The specific setting can be arbitrarily and flexibly set according to requirements, and this application embodiment does not limit it.

[0072] In some embodiments, the above-mentioned method for preventing replay of business requests may further include: when a business request is a long-term replay request, the server sends a second error message to the client and removes the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp from the cached data. The second error message indicates that the business request has encountered an error, and the server may also indicate the error type of the business request in the second error message, such as the business request being a long-term replay request. Of course, in practical applications, when a business request is a long-term replay request, the server may also terminate the anti-replay process without sending a second error message to the client to indicate that the business request has encountered an error. Furthermore, when a business request is a long-term replay request, the server may also remove the corresponding first identity information, first timestamp, and cache expiration time from the cached data to prevent illegal long-term replay requests from occupying storage resources, ensuring the effective utilization of cache space and the accuracy of anti-replay detection.

[0073] In some embodiments, the above-mentioned method for preventing replay of business requests may further include: when the business request is not a long-term replay request, the server authenticates the client based on the first identity information; when the client is authenticated, the server generates a business response corresponding to the business request, encapsulates the business response to obtain a second data packet; and the server sends the second data packet to the client.

[0074] When a business request passes the anti-replay verification (it is neither a short-term nor a long-term replay request), further authentication can be performed to prevent invalid identity information. The server authenticates the client based on the first identity information. For example, the server can obtain the second identity information from a local database or a third-party server. If the first and second identity information do not match, authentication is deemed unsuccessful; if they match, authentication is deemed successful. If the client is successfully authenticated, the server can respond to the client's business request normally. That is, it generates a business response corresponding to the business request, encapsulates the response, and sends the encapsulated second data packet to the client, allowing the client to parse the business response from the second data packet.

[0075] In some embodiments, after authenticating the client based on the first identity information, the process may further include: if the client fails authentication, sending a third error message to the client and clearing the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp from the cached data. The third error message indicates an error in the business request, and the server may also indicate the error type in the third error message, such as the client failing authentication (e.g., incorrect username or password). Of course, in practical applications, when the client fails authentication, the server may also terminate the anti-replay process without sending a third error message to the client to indicate an error in the business request. Furthermore, when the client fails authentication, the server may also clear the corresponding first identity information, first timestamp, and cache expiration time from the cached data to prevent unauthorized business requests from occupying storage resources, ensuring effective utilization of cache space and accuracy of anti-replay detection.

[0076] The technical solutions provided in the embodiments of this application will be described below with several examples.

[0077] Please see Figure 8 , Figure 8 This is a flowchart of another method for preventing replay of service requests provided in an embodiment of this application. This method for preventing replay of service requests can be applied to communication systems, such as those described above. Figure 1 In the communication system shown, there is a client 411 in the first device 410 and a server 421 in the second device 420. Figure 8 As shown, the method for preventing replay of this service request may include the following steps S801 to S811.

[0078] Step S801: The server performs parameter initialization.

[0079] The server can set a preset time difference threshold △T1 according to business type and requirements, and set a cache expiration time △T2 based on this. The cache expiration time and the preset time difference threshold satisfy the following condition: △T2≥2×△T1.

[0080] Step S802: The client encapsulates the business request and the corresponding first identity information and first timestamp to obtain the first data packet.

[0081] The client generates a business request and can obtain the current timestamp (first timestamp Ts1) from the local clock. It encapsulates the business request Req, the first identity information S, and the first timestamp Ts1 to obtain the first data packet (Req||S||Ts1).

[0082] Step S803: The client sends the first data packet to the server.

[0083] Step S804: The server parses the first data packet to obtain the business request and the first identity information and first timestamp corresponding to the business request.

[0084] The server responds to the first data packet from the client by parsing the first data packet to obtain the business request Req, the first identity information S, and the first timestamp Ts1.

[0085] Step S805: The server obtains the second timestamp.

[0086] The server can obtain the second timestamp Ts2 from the local clock or a third-party time server.

[0087] Step S806: The server determines whether the business request is a short-term replay request based on the first identity information, the first timestamp, and the cached data.

[0088] The server uses the parsed first identity information and first timestamp as query conditions (S-Ts1) to check if a matching entry exists in the cached data to determine whether the business request initiated by the client belongs to a short-term replay request. If a matching entry exists in the cached data (i.e., S-Ts1 exists), it is determined to be a short-term replay request, and the server returns the first error message to the client. If no matching entry exists in the cached data (i.e., S-Ts1 does not exist), it is determined not to be a short-term replay request, and the server can write the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp into the cached data for subsequent detection and judgment.

[0089] Step S807: The server determines whether the business request is a long-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp, and the preset time difference threshold.

[0090] If the business request is not a short-term replay request, the server further calculates the absolute value of the deviation between the first and second timestamps, |Ts2-Ts1|, and compares it with a preset time difference threshold △T1 to determine whether the business request is a long-term replay request. If the absolute value of the deviation |Ts2-Ts1| is greater than the preset time difference threshold △T1, it is determined to be a long-term replay request. At this time, the server clears the corresponding first identity information S, the first timestamp Ts1, and the cache expiration time corresponding to the first timestamp from the cached data, and returns the second error information to the client; if the absolute value of the deviation |Ts2-Ts1| is less than the preset time difference threshold △T1, it is determined not to be a long-term replay request.

[0091] Step S808: The server authenticates the client based on the first identity information.

[0092] When a business request passes the anti-replay verification (it is neither a short-term nor a long-term replay request), further authentication can be performed. The server can obtain secondary identity information from a local database or a third-party server. If the primary and secondary identity information do not match, authentication is deemed unsuccessful, and the server returns a third error message to the client. If the primary and secondary identity information match, authentication is deemed successful, and the server generates the corresponding business response for the business request.

[0093] Step S809: The server encapsulates the business response to obtain the second data packet.

[0094] Step S810: The server sends a second data packet to the client.

[0095] Step S811: The client parses the service response from the second data packet.

[0096] Please see Figure 9 , Figure 9 This is a schematic diagram of a service request anti-replay scheme provided in an embodiment of this application.

[0097] like Figure 9 As shown, the client encapsulates the business request Req, the first identity information S, and the first timestamp Ts1 to obtain the first data packet, and then sends the first data packet to the server. Figure 9 As shown, the server parses the first data packet to obtain the business request Req, the first identity information S, and the first timestamp Ts1, and the server obtains the second timestamp Ts2. Figure 9As shown, the server uses the first identity information and the first timestamp as query conditions (S-Ts1) to determine whether S-Ts1 exists in the cached data. If it exists, it is determined to be a short-term replay request, and the first error message is returned to the client. If it does not exist, the first identity information S, the first timestamp Ts1, and the cache expiration time △T2 corresponding to the first timestamp are written into the cached data. Figure 9 As shown, the server further determines whether the absolute value of the deviation |Ts2-Ts1| is less than the preset time difference threshold △T1; if it is not less than △T1, it determines that it is a long-term replay request, and returns a second error message to the client and clears the corresponding cached data; if it is less than △T1, it retrieves the second identity information from the database. Figure 9 As shown, the server determines whether the client has passed authentication based on the first and second identity information. If authentication fails, the server returns a third error message to the client and clears the corresponding cached data. If authentication is successful, the server generates a business response for the business request. The server encapsulates the business response to obtain a second data packet and sends the second data packet to the client. Figure 9 As shown, the client parses the second data packet and obtains the service response.

[0098] related Figure 8 and Figure 9 For further details on each step, please refer to the above embodiments; they will not be repeated here.

[0099] In summary, the technical solutions provided by the embodiments of this application include the following improvements and beneficial effects.

[0100] Firstly, a combined anti-replay key based on identity information and timestamps is used: when a client initiates a business request, it appends a local timestamp Ts1 and unique identity information S. The server then uses S-Ts1 as the key (query condition) to perform deduplication checks in the cached data. This utilizes existing identity information at the business layer to replace the independent random numbers used in traditional solutions, saving on random number generation and management overhead, reducing computational and storage costs; it also achieves precise isolation between different business requests (the same timestamp will not conflict under different identity information), avoiding global collisions. Furthermore, the cache key has business semantics, facilitating problem tracing.

[0101] Secondly, the dual threshold constraint: △T2≥2×△T1: The server initializes a preset time difference threshold △T1 and a cache expiration time △T2, ensuring that △T2≥2×△T1. This relationship theoretically ensures that regardless of whether the client's time is faster or slower than the server's time, any intercepted and replayed business request will be identified. While tolerating clock skew, it ensures that replay attacks cannot exploit time window vulnerabilities, achieving a balance between security and flexibility. However, related technologies do not possess such a strict constraint; they typically only require △T2>△T1, which cannot cover bidirectional skew.

[0102] Third, differentiated handling of replay attack types: The server identifies replay types using two different conditions: short-term replays (the same business request being sent repeatedly within a very short time) are identified by the existence of S-Ts1 in the cached data; long-term replays (business request timestamps have expired, but may be sent repeatedly due to clock skew or malicious manipulation) are identified by |Ts2-Ts1|>△T1. This allows for clear differentiation of specific replay attack types and the implementation of differentiated response strategies (e.g., directly rejecting short-term replays, clearing the cache and rejecting long-term replays), improving the system's ability to detect replay attacks, providing richer information for system log analysis and security auditing, and assisting operations personnel in locating problems.

[0103] Fourth, the single-interaction anti-replay process: The client encrypts and sends Ts1 and S along with the business request. The server completes all anti-replay verifications within a single request-response cycle, without any additional handshake interaction. This eliminates mechanisms such as challenge-response that require additional communication rounds, maintains the original business communication mode, and achieves zero additional network latency, making it particularly suitable for scenarios sensitive to response time, such as high-frequency trading and real-time APIs.

[0104] Fifth, the collaborative mechanism of caching and time difference verification: The server first performs cache deduplication; if a cache miss is found, it is stored in the cache first, and then time difference verification is performed; if the time difference exceeds the limit, the corresponding cache entry is immediately cleared. This "store first, clear later" strategy ensures effective interception of short-term replays (cache checks before time difference checks) and avoids invalid caches occupying memory for a long time due to excessive time differences. While strictly preventing replays, it optimizes cache resource utilization and prevents maliciously constructed expired requests from polluting the cache.

[0105] It should be noted that in the above embodiments, the method for preventing replay of business requests provided in this application is described from the perspective of interaction between the client and the server, but this does not constitute a limitation on the embodiments of this application. In practical applications, the steps executed by the client in the above embodiments can be implemented separately as a method for preventing replay of business requests on the client side; the steps executed by the server in the above embodiments can be implemented separately as a method for preventing replay of business requests on the server side. The following description uses a method for preventing replay of business requests on the server side as an example.

[0106] Please see Figure 10 , Figure 10 This is a flowchart of another method for preventing replay of business requests provided in an embodiment of this application. This method for preventing replay of business requests can be applied to the server side, as described above. Figure 1 The server 421 in the second device 420 of the communication system shown. Figure 10As shown, the method for preventing replay of this service request may include the following steps S1010 to S1030.

[0107] Step S1010: In response to the first data packet from the client, parse the first data packet to obtain the business request and the first identity information and first timestamp corresponding to the business request; wherein, the first timestamp refers to the current timestamp when the client generates the business request; Step S1020: Based on the first identity information, the first timestamp, and the cached data, determine whether the business request is a short-term replay request; wherein, the cached data includes at least one timestamp and the identity information and cache expiration time corresponding to each timestamp; Step S1030: If the business request is not a short-term replay request, determine whether the business request is a long-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp, and the preset time difference threshold; wherein, the second timestamp refers to the current timestamp of the server when parsing the first data packet, and the cache expiration time is greater than or equal to twice the preset time difference threshold.

[0108] In some embodiments, step S1020 may include: if the cached data includes a first timestamp and the identity information corresponding to the first timestamp in the cached data is the first identity information, then it is determined that the business request belongs to a short-term replay request; if the cached data does not include a first timestamp, or if the cached data includes a first timestamp and the identity information corresponding to the first timestamp in the cached data is not the first identity information, then it is determined that the business request does not belong to a short-term replay request, and the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp are written into the cached data.

[0109] In some embodiments, the method further includes sending a first error message to the client if the service request is a short-lived replay request.

[0110] In some embodiments, step S1030 may include: if the absolute value of the deviation is greater than or equal to a preset time difference threshold, then the service request is determined to be a long-term replay request; if the absolute value of the deviation is less than the preset time difference threshold, then the service request is determined not to be a long-term replay request.

[0111] In some embodiments, the method further includes: sending a second error message to the client when the business request is a long-term replay request, and clearing the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp from the cached data.

[0112] In some embodiments, the method further includes: authenticating the client based on the first identity information when the business request is not a long-running replay request; generating a business response corresponding to the business request and encapsulating the business response to obtain a second data packet when the client is successfully authenticated; and sending the second data packet to the client.

[0113] In some embodiments, after authenticating the client based on the first identity information, the method further includes: if the client fails to authenticate, sending a third error message to the client and clearing the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp from the cached data.

[0114] For further details on the steps and beneficial effects of the server-side anti-replay method for business requests, please refer to the above embodiments; they will not be elaborated upon here.

[0115] Please see Figure 11 , Figure 11 This is a schematic diagram of a service request anti-replay device provided in an embodiment of this application. This service request anti-replay device can be used to execute the server-side service request anti-replay method described in the above embodiments. Figure 11 As shown, the anti-replay device 1100 for this service request may include: a data packet parsing module 1110, a short-term replay judgment module 1120, and a long-term replay judgment module 1130.

[0116] The data packet parsing module 1110 is used to: parse the first data packet in response to the first data packet from the client to obtain the business request and the first identity information and first timestamp corresponding to the business request; wherein, the first timestamp refers to the current timestamp when the client generates the business request; The short-term replay judgment module 1120 is used to: determine whether a business request belongs to a short-term replay request based on the first identity information, the first timestamp, and cached data; wherein, the cached data includes at least one timestamp and the identity information and cache expiration time corresponding to each timestamp; The long-term replay judgment module 1130 is used to: determine whether a business request is a long-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp, and a preset time difference threshold, when the business request is not a short-term replay request; wherein, the second timestamp refers to the current timestamp of the server when parsing the first data packet, and the cache expiration time is greater than or equal to twice the preset time difference threshold.

[0117] In some embodiments, the short-term replay determination module 1120 is further configured to: if the cached data includes a first timestamp and the identity information corresponding to the first timestamp in the cached data is the first identity information, then determine that the business request belongs to a short-term replay request; if the cached data does not include a first timestamp, or if the cached data includes a first timestamp and the identity information corresponding to the first timestamp in the cached data is not the first identity information, then determine that the business request does not belong to a short-term replay request, and write the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp into the cached data.

[0118] In some embodiments, the short-term replay determination module 1120 is further configured to: send a first error message to the client if the service request is a short-term replay request.

[0119] In some embodiments, the long-term replay determination module 1130 is further configured to: determine that the service request belongs to a long-term replay request if the absolute value of the deviation is greater than or equal to a preset time difference threshold; and determine that the service request does not belong to a long-term replay request if the absolute value of the deviation is less than the preset time difference threshold.

[0120] In some embodiments, the long-term replay judgment module 1130 is further configured to: send a second error message to the client when the business request is a long-term replay request, and clear the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp from the cache data.

[0121] In some embodiments, such as Figure 12 As shown, the aforementioned anti-replay device 1100 for business requests may further include an authentication module 1140 and a business response module 1150. The authentication module 1140 is used to: authenticate the client based on first identity information when the business request is not a long-term replay request; the business response module 1150 is used to: generate a business response corresponding to the business request when the client is authenticated, encapsulate the business response to obtain a second data packet, and send the second data packet to the client.

[0122] In some embodiments, the authentication module 1140 is further configured to: send a third error message to the client if the client fails to authenticate, and clear the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp from the cached data.

[0123] For further description of the functions and beneficial effects of each module in the above-mentioned anti-replay device, please refer to the embodiments of the above-mentioned anti-replay method, which will not be elaborated here.

[0124] This application also provides a computer-readable storage medium storing a computer program or instructions. When the computer program or instructions are executed by a processor, they implement the above-mentioned anti-replay method for the service request and have all the beneficial effects of the above-mentioned anti-replay method for the service request. This application will not elaborate further here.

[0125] This application also provides a computer program product, including a computer program or instructions. When the computer program or instructions are executed by a processor, they implement the above-mentioned anti-replay method for the business request and have all the beneficial effects of the above-mentioned anti-replay method for the business request. Further details will not be elaborated here.

[0126] This application also provides a computer device, including: a memory and a processor, wherein the memory stores a computer program or instructions; the processor executes the computer program or instructions in the memory to implement the steps of the above-described anti-replay method for service requests. This computer device possesses all the beneficial effects of the above-described anti-replay method for service requests, which will not be elaborated further here. This computer device may be, for example, the one described above. Figure 1 The second device 420 in the communication system shown. In practical applications, this computer device can be implemented as a server, desktop computer, computing cluster, edge computing node, cloud server, network device, edge server, etc.

[0127] Computer-readable storage media can be, for example, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof, without particular limitation herein. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0128] In some embodiments, a computer-readable storage medium may be any tangible medium that contains or stores a program that may be used by or in connection with an instruction execution system, apparatus, or device.

[0129] The aforementioned computer-readable storage medium may be included in the aforementioned computer device; or it may exist independently and not assembled into the computer device.

[0130] Computer program code for performing operations of some embodiments of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a Local Area Network (LAN) or a Wide Area Network (WAN)), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0131] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function.

[0132] It should also be noted that in some alternative implementations, the functions marked in the box may occur in a different order than those marked in the attached figures.

[0133] For example, two consecutively represented blocks can actually be executed in substantially parallel order, and sometimes they can be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, as well as combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operations, or using a combination of dedicated hardware and computer instructions.

[0134] The units described in some embodiments of this application can be implemented in software or in hardware. The described units can also be located in a processor.

[0135] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), Application Specific Standard Parts (ASSP), System on Chip (SOC), Complex Programmable Logic Device (CPLD), and so on.

[0136] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0137] The embodiments, implementation methods, and related technical features of this application can be combined and substituted for each other without conflict.

[0138] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of exemplary embodiments and may not be to scale. The modules or processes shown in the drawings are not necessarily essential for implementing this application and therefore should not be used to limit the scope of protection of this application.

[0139] It should be noted that, in the data processing stage, the technical solution of this application has strictly limited the scope of data collection to the minimum necessary to achieve the technical objectives, preventing the acquisition of irrelevant information. For any user information to be collected, the data subject will be clearly informed and their consent obtained. Furthermore, technologies such as encrypted storage and access control are employed to strengthen data security and ensure the security and compliance of the entire data processing process. The technical model and decision-making mechanism are based on objective technical parameters and do not introduce unnecessary parameters such as gender or age that may lead to discrimination, resolutely eliminating algorithmic discrimination and upholding public order and good morals. In addition, the specification fully describes the technical implementation methods, application scenarios, and compliance protection details. The claims are consistent with the content of the specification, key compliance designs are clear and verifiable, and the overall technical design is guided by the protection of public interests and adherence to social ethics, without any circumstances that harm public interests or violate public order and good morals.

[0140] The above provides a detailed description of the anti-replay method, apparatus, computer equipment, and storage medium for service requests provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the technical solutions and core ideas of this application. Those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for preventing replay of business requests, characterized in that, The method includes: In response to a first data packet from the client, the first data packet is parsed to obtain a business request and the first identity information and first timestamp corresponding to the business request; wherein, the first timestamp refers to the current timestamp of the client when the business request is generated; Based on the first identity information, the first timestamp, and the cached data, it is determined whether the business request is a short-term replay request; wherein, the cached data includes at least one timestamp and the identity information and cache expiration time corresponding to each timestamp; If the service request does not belong to the short-term replay request, the absolute value of the deviation between the first timestamp and the second timestamp, and the preset time difference threshold, are used to determine whether the service request belongs to the long-term replay request; wherein, the second timestamp refers to the current timestamp when the server parses the first data packet, and the cache expiration time is greater than or equal to twice the preset time difference threshold.

2. The method according to claim 1, characterized in that, The step of determining whether the business request belongs to a short-term replay request based on the first identity information, the first timestamp, and cached data includes: If the cached data includes the first timestamp, and the identity information corresponding to the first timestamp in the cached data is the first identity information, then the service request is determined to belong to the short-term replay request. If the cached data does not include the first timestamp, or if the cached data includes the first timestamp and the identity information corresponding to the first timestamp in the cached data is not the first identity information, then it is determined that the business request does not belong to the short-term replay request, and the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp are written into the cached data.

3. The method according to claim 1 or 2, characterized in that, The method further includes: If the service request belongs to the short-term replay request, a first error message is sent to the client.

4. The method according to claim 1, characterized in that, The step of determining whether the service request belongs to a long-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp, and a preset time difference threshold, includes: If the absolute value of the deviation is greater than or equal to the preset time difference threshold, then the service request is determined to belong to the long-term replay request. If the absolute value of the deviation is less than the preset time difference threshold, then the service request is determined not to be a long-term replay request.

5. The method according to claim 1 or 4, characterized in that, The method further includes: If the service request belongs to the long-term replay request, a second error message is sent to the client, and the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp are cleared from the cache data.

6. The method according to claim 1 or 4, characterized in that, The method further includes: If the service request does not belong to the long-running replay request, the client is authenticated based on the first identity information; If the client passes the authentication, a business response corresponding to the business request is generated, and the business response is encapsulated to obtain a second data packet; The second data packet is sent to the client.

7. The method according to claim 6, characterized in that, After verifying the client based on the first identity information, the process further includes: If the client fails the authentication, a third error message is sent to the client, and the first identity information, the first timestamp, and the cache expiration time corresponding to the first timestamp are cleared from the cached data.

8. A device for preventing replay of service requests, characterized in that, The device includes: The data packet parsing module is configured to: in response to a first data packet from the client, parse the first data packet to obtain a business request and the first identity information and first timestamp corresponding to the business request; wherein, the first timestamp refers to the current timestamp of the client when the business request was generated; The short-term replay determination module is used to: determine whether the business request belongs to a short-term replay request based on the first identity information, the first timestamp, and cached data; wherein, the cached data includes at least one timestamp and the identity information and cache expiration time corresponding to each timestamp; The long-term replay determination module is used to: determine whether the business request belongs to the long-term replay request based on the absolute value of the deviation between the first timestamp and the second timestamp, and a preset time difference threshold, when the business request does not belong to the short-term replay request; wherein, the second timestamp refers to the current timestamp of the server when parsing the first data packet, and the cache expiration time is greater than or equal to twice the preset time difference threshold.

9. A computer device, characterized in that, include: A memory on which computer programs or instructions are stored; A processor for executing the computer program or instructions in the memory to implement the anti-replay method for service requests as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program or instructions, which, when executed by a processor, implement the anti-replay method for service requests as described in any one of claims 1 to 7.

Images