Anti-playback method and device, electronic equipment and computer readable storage medium

Abstract

The invention discloses an anti-replay method and device, electronic equipment and a computer readable storage medium, and is applied to a server, the method comprises the following steps: receiving a first service request sent by a client, the first service request carrying a first token, and the first token is formed by the server based on field information; legality detection is carried out on the first token to obtain a first detection result, and the first detection result is used for verifying whether the decoded and decrypted first token is legal or not; legality detection is conducted on the first detection result, a second detection result is obtained, and the second detection result is used for verifying whether the field information composition format is legal or not and whether the server conducts fault-tolerant degradation processing or not; determining a verification result based on the first detection result and / or the second detection result, wherein the verification result is used for indicating to intercept or process the first service request; therefore, the security of the anti-replay information is improved.

Description

Technical Field

[0001] The present application relates to the field of distributed system security, and in particular to an anti-replay method and device, an electronic device, and a computer-readable storage medium. Background Art

[0002] In the current internet landscape, distributed systems are commonly used to deploy services to handle high-concurrency access. A replay attack is a network security threat in which an attacker captures valid communication data and then resends it to the server, misleading it into believing it is legitimate data. This allows the attacker to deceive the system and perform malicious operations.

[0003] On the one hand, existing technologies for preventing replay attacks in distributed system environments generally use timestamp defense methods, random value defense methods, or a combination of the two methods. However, whether using timestamps, random values, or a combination of the two, there is a possibility that attackers can easily determine which attack prevention measures the server has adopted, thereby launching a trial attack. On the other hand, in a distributed environment, storage is generally performed by storage components. Because the server and storage components are connected via a network, there is a possibility that network jitter, node failures, etc. may cause the server to be unable to use the storage components normally, thereby causing the entire anti-replay function to be unavailable. On the other hand, as requests accumulate, the number of storage items increases, putting pressure on storage capacity. However, if the random value data in the storage is cleared, the server may misjudge the same random value, causing the anti-replay function to fail. Therefore, an effective anti-replay method is urgently needed to ensure the reliable operation of the anti-replay function in distributed systems. Summary of the Invention

[0004] To solve the above technical problems, embodiments of the present invention provide an anti-replay method and device, an electronic device, and a computer-readable storage medium.

[0005] In a first aspect, the anti-replay method provided in an embodiment of the present application is applied to a server, including:

[0006] Receive a first service request sent by a client, where the first service request carries a first token, and the first token is composed by the server based on field information;

[0007] Performing a legitimacy check on the first token to obtain a first test result, where the first test result is used to verify whether the first token after decoding and decryption is legal;

[0008] Performing a validity check on the first detection result to obtain a second detection result, where the second detection result is used to verify whether the format of the field information is legal;

[0009] A verification result is determined based on the first detection result and / or the second detection result, where the verification result is used to indicate interception or processing of the first service request.

[0010] In a second aspect, an anti-replay device provided in an embodiment of the present application is applied to a server, including:

[0011] A receiving unit, configured to receive a first service request sent by a client, where the first service request carries a first token, and the first token is composed by the server based on field information;

[0012] a detection unit, configured to perform a legitimacy detection on the first token to obtain a first detection result, wherein the first detection result is used to verify whether the first token after decoding and decryption is legal; and further configured to perform a legitimacy detection on the first detection result to obtain a second detection result, wherein the second detection result is used to verify whether the format of the field information is legal;

[0013] A determination unit is used to determine a verification result based on the first detection result and / or the second detection result, and the verification result is used to indicate interception or processing of the first service request.

[0014] In a third aspect, an electronic device provided by an embodiment of the present application includes: a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory to execute any one of the above-mentioned anti-replay methods.

[0015] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium for storing a computer program, wherein the computer program enables a computer to execute any one of the above-mentioned anti-replay methods.

[0016] In the technical solution of the embodiment of the present application, the server receives a first business request sent by the client, and the first business request carries a first token, which is composed of the server based on field information; the first token is checked for legitimacy to obtain a first test result, and the first test result is used to verify whether the decoded and decrypted first token is legal; the first test result is checked for legitimacy to obtain a second test result, and the second test result is used to verify whether the format of the field information is legal; a verification result is determined based on the first test result and / or the second test result, and the verification result is used to indicate the interception or processing of the first business request; in this way, compared with the prior art in which the client calculates and generates anti-replay information, it is proposed that the server provide anti-replay information so that the client side will not expose the real information and calculation rules, so that attackers cannot guess the verification scheme or crack the actual information contained in the token, thereby improving the security of the anti-replay information; on the other hand, since the anti-replay parameters are obtained directly from the server, clients of any business can easily access the anti-replay function, thereby improving access convenience and functional versatility. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is the system framework of the anti-replay method of the embodiment of the present application Figure 1 ;

[0018] Figure 2 This is the system framework of the anti-replay method of the embodiment of the present application Figure 2 ;

[0019] Figure 3 This is a flowchart of the anti-replay method provided in the embodiment of the present application. Figure 1 ;

[0020] Figure 4 This is a flowchart of the anti-replay method provided in the embodiment of the present application. Figure 2 ;

[0021] Figure 5 This is a flowchart of the anti-replay method provided in the embodiment of the present application. Figure 3 ;

[0022] Figure 6 This is a flowchart of the anti-replay method provided in the embodiment of the present application. Figure 4 ;

[0023] Figure 7 This is a flowchart of the anti-replay method provided in the embodiment of the present application. Figure 5 ;

[0024] Figure 8 Schematic diagram of the structure of the anti-replay device provided in an embodiment of the present application;

[0025] Figure 9 This is a schematic structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0026] The following will describe the technical solutions in the embodiments of this application in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0027] It should be noted that the terms "first\second\third" involved in this article are only used to distinguish similar objects and do not represent a specific order for the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0028] To facilitate understanding of the technical solutions of the embodiments of the present application, the relevant technologies of the embodiments of the present application are described below. The following relevant technologies can be arbitrarily combined with the technical solutions of the embodiments of the present application as optional solutions, and they all fall within the protection scope of the embodiments of the present application.

[0029] A replay attack is a network security threat in which an attacker captures valid communication data and then resends it to the server, misleading the server into believing it is legitimate data. This allows the attacker to deceive the system and perform malicious operations. Although most data transmitted on the network is currently encrypted, encryption only protects data during transmission and does not prevent data from being replayed. Attackers do not need to know the content of the data; they only need to understand the function of the interface to deceive the server through a replay attack. A common example is an attacker replaying legitimate authentication packets to deceive the server's authentication mechanism and gain unauthorized access.

[0030] In the current internet landscape, services are typically deployed using distributed systems to handle high-concurrency requests. A distributed system distributes data and computing tasks across multiple independent nodes. These nodes communicate and collaborate over a network to provide services. Client requests are processed by one of these nodes using a random or round-robin approach. This distributed deployment model improves system scalability and concurrent processing capabilities, making it the industry's mainstream choice. However, this approach also introduces new challenges, such as inter-node network latency, component interdependencies, and system data consistency. Therefore, achieving high availability in a distributed system requires careful consideration of the inherent challenges inherent in a distributed environment. Furthermore, when implementing anti-replay attack protection in a distributed system, in addition to ensuring the anti-replay functionality itself, it is also important to address common failures between service nodes and component dependencies, taking into account the characteristics of distributed systems. This ensures the reliable operation of anti-replay functionality within a distributed system.

[0031] Current distributed systems generally use the following defenses against replay attacks: timestamp defense, nonce defense, or a combination of the two. Specifically:

[0032] Timestamp protection involves the server evaluating the timestamp in the client request and comparing it with the server's current timestamp, timestamp1. If the time difference exceeds a set validity period, such as 60 seconds, the request is considered invalid and a replay request is considered invalid. Furthermore, to prevent the timestamp from being easily modified, the client and server typically agree on an algorithm, such as MD5, to generate a digital signature using the timestamp. When making a request, the client generates a digital signature, sign, using the timestamp, using the algorithm, such as sign = md5(timestamp, key). The client then sends sign along with the timestamp to the server, such as url?timestamp=timestamp&sign=signature. Upon receiving the request, the server generates a digital signature, sign1 = md5(timestamp, key), and compares sign1 with sign to see if they are equal. If they are, the timestamp in the request is valid. The server then uses the difference between timestamp1 and timestamp to determine whether the request is a replay request.

[0033] Random value defense involves the client generating a random nonce value and adding it to the request body when requesting the server. The server then uses its cache to check whether the nonce has been used before. If it is the first time the request has been received, it accepts the request and adds it to the cache. Subsequent requests with the same nonce value can retrieve the nonce value from the cache, and the request is considered a replay request. Generally, to prevent forgery of nonce values ​​and verify their timeliness, the client and server also agree on a digital signature algorithm to generate a signature value, such as sign = md5 (timestamp, nonce, key). Upon receiving the request, the server also generates sign1, compares sign1 with sign to see if they are equal, and then uses the nonce value to determine whether the request is a replay.

[0034] However, existing technologies, whether using timestamps, random values, or a combination of both, present two problems. First, from the client's perspective, exposing information in request parameters, such as timestamps, nonce values, and digital signatures, makes it easy for attackers to determine which attack prevention measures the server has implemented, allowing them to launch attempted attacks. Furthermore, since the digital signature logic must be implemented on the client side, web clients typically implement this logic using JavaScript code. An attacker can easily access the JavaScript code, obtain the digital signature algorithm, and then generate their own digital signatures, verify them, and launch a replay attack. Furthermore, this approach requires each client accessing anti-replay capabilities to perform digital signature calculations, complicating the access process. Second, from the server's perspective, for nonce protection, the server stores the identifier after first encountering it. This allows subsequent requests with the same nonce value to be retrieved and identified as replay requests. In a distributed environment, storage often requires distributed caches or databases, making anti-replay functionality highly dependent on these storage components. Since the server and storage components belong to different functional nodes in a distributed system and are connected through the network, it is easy for the server to be unable to use the storage components normally due to network jitter, node failure, etc., which in turn causes the entire anti-replay function to be unavailable. On the other hand, as requests accumulate, this storage method will also lead to an increasing number of storages, putting pressure on storage capacity. However, if the nonce data in the storage is cleared, it may cause the server to misjudge the same nonce value, causing the anti-replay capability to fail. To this end, the following technical solution is proposed in this application.

[0035] To facilitate understanding of the technical solutions of the embodiments of the present application, the technical solutions of the present application are described in detail below through specific embodiments. The above related technologies can be combined arbitrarily with the technical solutions of the embodiments of the present application as optional solutions, and all of them fall within the scope of protection of the embodiments of the present application. The embodiments of the present application include at least part of the following contents.

[0036] Figure 1 and Figure 2 This is the system framework of the anti-replay method provided in the embodiment of the present application Figure 1 and Figure 2 The anti-replay method provided in this application is located on a server. The server can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0037] In some embodiments, the server can implement the anti-replay method provided in the embodiments of the present application by running various computer executable instructions or computer programs. For example, computer executable instructions can be microprogram-level commands, machine instructions or software instructions. The computer program can be a native program or software module in the operating system; it can be a local (Native) application (APPlication, APP); it can also be a small program that can be embedded in any APP, that is, a program that can be run only by downloading it to a browser environment; the server carries the server, and the server is a targeted service program that serves the corresponding client. The server and the client generally interact through the network, the client initiates a request, and the server responds to the client request. In short, the above-mentioned computer executable instructions can be instructions in any form, and the above-mentioned computer program can be an application, module or plug-in in any form.

[0038] like Figure 1 As shown, the server can be deployed as an independent service and provide an interface to the outside world. For example, the client sends a service request to the business server, and the business server remotely calls the anti-replay interface to the anti-replay service cluster; Figure 2As shown, the server can also be integrated into the business service, and the business service provides a unified interface. For example, the client sends a business request to the business server, and the business function in the business server calls the anti-replay interface to the anti-replay function. In a distributed environment, at least two instances need to be deployed in the anti-replay service cluster to avoid single point failure. When the request volume is high, the anti-replay service cluster supports horizontal expansion by increasing the number of instances to cope with high concurrency requests. The business request sent by the client can be routed to one of the instances for processing by random or polling. In some embodiments, each service instance with anti-replay function will be connected to a distributed cache component, which is used to store key values ​​and set the automatic expiration time of the key values, wherein the distributed cache component can be a key-value distributed cache component, such as redis, or it can be replaced by other distributed caches with the same function such as MemCache, TongRDS, Alibaba Cloud Tair, etc. This application does not limit the specific components.

[0039] The anti-replay system provided in the embodiment of the present application provides two interfaces, namely the first interface and the second interface, wherein the first interface can also be called getToken, which is an interface exposed to the client for obtaining the token value, and the second interface can also be called verifyToken, which is an interface used for replay verification inside the server. Before the client actually initiates a business request, the client needs to obtain the token value through the first interface first; then when initiating a business request, the client needs to attach the token value obtained in the previous step to the server, and the server uses the second interface to perform anti-replay verification on the token. Only after the verification passes can the subsequent business logic processing be carried out. If the verification fails, it will be intercepted. Specifically, Figure 3 This is a flowchart of the anti-replay method provided in the embodiment of the present application. Figure 1 ,like Figure 3 As shown, the anti-replay method is applied to the server, and the method specifically includes the following steps:

[0040] Step 301: Receive a first service request sent by a client. The first service request carries a first token. The first token is composed by the server based on field information.

[0041] In this embodiment of the present application, the server receives a first service request from a client via a second interface. The first service request carries a first token. The second interface, also called verifyToken, is an interface used internally by the server for replay verification. The server uses the second interface to perform an anti-replay verification on the first token. If the first token verification passes, subsequent service logic processing can proceed. If the first token verification fails, the first service request is intercepted.

[0042] In the embodiment of the present application, the first token is generated by the server based on the second service request sent by the client. Figure 4 , receiving a first service request sent by a client, the first service request carrying a first token, the first token being composed by the server based on the first field information, specifically comprising the following steps:

[0043] Step 401: Receive a second service request sent by a client, where the second service request is used to obtain a first token.

[0044] In some implementations, the server receives a second service request sent by the client through the first interface. The second service request is a request from the client to the server for a token. The first interface is an interface exposed by the server to the client for the client to obtain a token value.

[0045] Specifically, the anti-replay system provides a first interface, which can also be called getToken. Before the client actually initiates a business request, the client needs to first obtain a token value from the server through the first interface, that is, the server receives the second business request sent by the client; then, when initiating a business request, the client needs to attach the token value obtained in the previous step to the server, and the server performs an anti-replay check on the token. Only after the check passes can subsequent business logic processing be performed. If the check fails, it will be intercepted.

[0046] It should be noted that the first token carried in the first service request sent by the client may not be the first token obtained in the same session. For example, service A has two identical clients a and b, which obtain the first tokens a-token1 and b-token1 respectively. When sending the first service request next, the two clients can exchange the first tokens they obtained, because a-token and b-token are both legal, unused first tokens for the same service, and can pass the replay verification; that is, if client a obtains a-token but transmits b-token, it can also pass the verification. Later, if client b transmits b-token again, it will be regarded as having been used and will be intercepted.

[0047] Step 402: Generate a first token based on the second service request, where the first token consists of field information.

[0048] The first token carries anti-replay information generated by the server. Specifically, after receiving the request for obtaining a token from the client, the server combines multiple anti-replay related information in the form of field information into the first token and encrypts the first token.

[0049] Step 403: Encrypt the first token to generate an encrypted first token, and send the encrypted first token to the client.

[0050] In some embodiments, the server encrypts the first token. For example, a symmetric encryption algorithm such as AES and Base64 encoding are used to generate the first token, the first token = e_base64(encodeAes(k1, salt)), where k1 represents the field information. Symmetric encryption is an encryption method that uses a single-key cryptographic system, and the same key can be used for both encryption and decryption of information. For example, the encryption algorithm can be the Aes algorithm, or it can be replaced by other commonly used symmetric encryption algorithms such as SM4, 3DES, RC4, etc. Base64 encoding is a method of representing binary data based on 64 printable characters, which can concentrate the expression of all characters on some common, visible character sets. In network communications, Base64 allows data to be transmitted conveniently. It should be noted that the server does not specifically limit the specific encoding method and encryption method.

[0051] In some embodiments, the server generates a first token based on the second service request. The first token carries field information. Specifically, the field information may be a combination of anti-replay information. In conjunction with the fault tolerance of the system in a distributed environment, data related to fault tolerance, anti-replay feature information, and a nonce are combined to generate a unique first token. The first token string includes the basic fields and other feature information.

[0052] In some embodiments, the server obtains first time information and sets a first field based on the first time information. The first field is used to indicate the first time the server received the second service request. Here, the first time the server received the second service request can be obtained by obtaining the current server's timestamp as the first field information t1. There are two main types of timestamps: Unix timestamps and Windows timestamps, both of which are integers. In practice, servers are generally Linux-based servers. In addition, in a distributed environment, clock synchronization must be enabled on each server node to ensure that the time on each node is roughly consistent.

[0053] In some embodiments, the server generates first identification information and sets a second field based on the first identification information. The second field is used to indicate the key-value information of the first token in the cache. Here, the server can obtain the first identification information, i.e., the globally unique string s1, based on an ID generation algorithm such as uuid or snowflake, and set s12 as the second field. The second field is used to identify the key-value information of the first token in the key-value pair distributed cache component. For example, if the value of the first token is stored in the cache component, it can be set to s1:1.

[0054] In some embodiments, the server creates a first cache flag and sets a third field based on the first cache flag. The third field is used to indicate the availability of the first token in the cache. Here, the server creates a first cache flag, cache_flag, for the distributed cache for continuous liveness detection. The cache_flag is used to mark whether the distributed cache is available, generating the third field r1.

[0055] Specifically, a first cache tag is created, the first cache tag is used to detect whether the cache is available, the cache is used to store the key value information and the second time information of the first token in the cache; based on the first cache tag, whether the cache is available is determined; if available, the third field is set to the first character, the key value corresponding to the second field in the cache is set to the first value, and the fourth field is set to the first preset time; if unavailable, the third field is set to the second character, and the second character is used to indicate fault-tolerant degradation processing of the first token.

[0056] Here, the server creates a first cache flag, cache_flag, for the distributed cache for continuous liveness detection. This flag indicates whether the distributed cache is available. If the liveness detection finds the cache unavailable, the cache_flag is marked as false. If the liveness detection finds the cache available, the cache_flag is marked as true. With continuous detection, the cache_flag field is continuously updated according to changes in the distributed cache's availability.

[0057] The server generates a third field r1 based on the cache_flag field. When the cache_flag mark is true, it indicates that the distributed cache is available, and the third field r1 is set to the first character, which can be "1". After that, the key value corresponding to the second field in the cache is set to the first value, for example, the key-value pair s1:1 is set in the distributed cache, and the second time information ttl is set to the allowed token validity period. When the cache_flag mark is false, it indicates that the distributed cache is unavailable, and the third field r1 is set to the second character, which can be "0". The second character is used to indicate fault-tolerant degradation processing of the first token. In other embodiments, if the setting of the second field and the fourth field fails, r1 is reset to the second character.

[0058] It should be noted that when the cache_flag mark is true, the first character can also be set to "0", indicating that the distributed cache component is available. When the cache_flag mark is false, the second character can also be set to "1", indicating that the distributed cache component is unavailable. This application does not limit the values ​​of the first and second characters.

[0059] In some embodiments, the server obtains second time information and sets a fourth field based on the second time information, and the fourth field is used to indicate that the first token is valid within a first preset time. Here, the server obtains the validity period ttl of the token corresponding to the pre-configured business interface. If the validity period of all interfaces is the same value, such as 60 seconds, the value can be directly hard-coded. If each interface is required to have a different validity period, the first preset time represents the automatic expiration time ttl of the first token when it is stored in the distributed cache component, indicating the validity period allowed for the token value to be stored in the cache component. If the validity period of the token value stored in the cache component exceeds the second time information ttl, the token value is cleared or invalid, and r1 is set to "0". For example, the validity period ttl of the token corresponding to business interface A is 60 seconds, and the validity period ttl of the token corresponding to business interface B is 30 seconds. The validity period can be configured in a persistent component such as a database or file. The service process only needs to load it into the process memory when it starts, and directly read the process memory when it needs to be read, thereby reducing reading time.

[0060] In some implementations, the server may also add other field information, such as adding a fifth field indicating the client identification information id, binding the client id to the unique string s1, thereby further accurate verification. Specifically, whether the token needs to be bound to the session depends on the specific implementation of different services. It can be bound or not. If binding is required, it can be achieved by adding information such as the session id or the client id when generating the token field information in getToken. For example, if business A has two identical clients a and b, and each obtains the first token, the client id can be bound to the unique string s1 as a-token1 and b-token1.

[0061] In some embodiments, the server generates a first token based on the first field, the second field, the third field, and the fourth field. Here, the basic fields are spliced ​​to obtain the field information k1. For example, the first field, the second field, and the third field are spliced ​​to obtain k1=r1_s1_t1; for another example, the first field, the second field, the third field, and the fourth field are spliced ​​to obtain k1=r1_s1_t1_ttl. For another example, the first field, the second field, the third field, and the fifth field are spliced ​​to obtain k1=r1_s1_t1_id. It should be noted that this application does not limit the splicing method, nor does it limit the constituent fields of k1, such as using other delimiters for field splicing, using json string serialization and deserialization, etc.

[0062] From the above, it can be seen that the anti-replay method provided in the embodiment of the present application is that the server receives a second business request sent by the client for obtaining a first token, generates a first token carrying field information based on the second business request, and then encrypts the first token to generate an encrypted first token, and sends the encrypted first token to the client; in this way, the anti-replay related information is generated by the server, and the server combines multiple anti-replay related information and encrypts them. Compared with the prior art in which the client calculates and generates anti-replay information, it is proposed that the server provide anti-replay information so that the client side will not expose the real information and calculation rules, so that the attacker cannot guess the verification scheme or crack the actual information contained in the token, thereby improving the security of the anti-replay information; on the other hand, since the client obtains the anti-replay parameters directly from the server, the client of any business can easily access the anti-replay function, which improves the access convenience and functional versatility.

[0063] Step 302: Perform a legitimacy check on the first token to obtain a first test result. The first test result is used to verify whether the decoded and decrypted first token is legal.

[0064] In an embodiment of the present application, the server uses the second interface to perform anti-replay verification on the first token. Subsequent business logic processing can only be performed after the verification passes. If the verification fails, it will be intercepted.

[0065] Specifically, the first token is decoded and decrypted; if the decoding and decryption of the first token fails, the first detection result is used to indicate that the first token is illegal; if the decoding and decryption of the first token is successful, a decoded and decrypted first token is generated, and the first detection result is used to indicate that the first token is legal.

[0066] Here, the server first verifies whether the first token is legal, and decodes and decrypts the first token. If the decoding and decryption fails, it means that the first token is a token forged by the attacker, and the server returns an interception. If the decoding and decryption is successful, the first token after decoding and decryption is generated. It should be noted that the specific decoding and decryption method of the server corresponds to the encryption encoding method, and this application does not specifically limit the specific decoding and decryption method. For example, if the first token is encrypted and encoded by a symmetric encryption algorithm such as AES and Base64 encoding, the first token is Base64 decoded and symmetric decrypted, such as decodeAes(d_base64(token)). If the decoding and decryption is successful, the next step is executed to perform a legitimacy check on the first detection result, that is, the first token, to obtain a second detection result. The second detection result is used to verify whether the format of the field information composition is legal.

[0067] Step 303: Perform a validity check on the first detection result to obtain a second detection result. The second detection result is used to verify whether the format of the field information is legal.

[0068] In an embodiment of the present application, if the first detection result is that the first token is legal, that is, the decoding of the first token is successful, then the first detection result, that is, the first token, is subjected to a legitimacy check, that is, whether the field information composition format of the first token is legal is verified. If the field information composition format parsing fails, the second detection result indicates that the first token is illegal; if the field information composition format parsing succeeds, the second detection result indicates that the first token is legal.

[0069] Specifically, if the first token is successfully decoded and decrypted, a decoded and decrypted first token is generated, and the field information of the first token is parsed. If the field information format parsing fails, the second test result indicates that the first token is illegal. If the field information format parsing succeeds, the second test result indicates that the first token is legal. For example, when the encrypted encoding is performed, the field information format is k1=r1_s1_t1. Then, the field information of the first token is parsed to determine whether the parsed k1 format is r1_s1_t1. If not, the parsing fails and the first token is illegal. If the k1 format parsing succeeds, the first token is legal.

[0070] In some embodiments, after the server successfully parses the segment information composition format, if the field information composition also includes the customer ID, it can continue to determine whether the current customer ID is consistent with the customer ID in k1, such as in some scenarios where the binding of the first token and the customer ID is restricted; if there is no other field logic to be judged in k1, it means that the request is legal and has passed the anti-replay verification.

[0071] Step 304: Determine a verification result based on the first detection result and / or the second detection result, where the verification result is used to indicate whether to intercept or process the first service request.

[0072] In an embodiment of the present application, if the first detection result and / or the second detection result indicates that the first token is illegal, the verification result is determined to be the first verification result, and the first business request is intercepted based on the first verification result; if the second detection result indicates that the first token is legal, the verification result is determined to be the second verification result, and the first business request is processed based on the second verification result.

[0073] Here, if the first token is validated and determined to be invalid, the server determines the verification result to be the first verification result and intercepts the first service request. Alternatively, if the formatting of the field information components of the first token fails to be parsed, the server determines the verification result to be the first verification result and intercepts the first service request. If the first token is validated and determined to be valid, and the formatting of the field information components of the first token is successfully parsed, the server determines the verification result to be the second verification result and processes the first service request.

[0074] As can be seen from the above, the anti-replay method provided in the embodiment of the present application is that the server receives a first business request sent by the client, and the first business request carries a first token, which is composed by the server based on field information; the first token is subjected to a legitimacy check to obtain a first test result, and the first test result is used to verify whether the first token after decoding and decryption is legal; the first test result is subjected to a legitimacy check to obtain a second test result, and the second test result is used to verify whether the format of the field information is legal; a verification result is determined based on the first test result and / or the second test result, and the verification result is used to indicate interception or processing of the first business request; in this way, the anti-replay related information is generated by the server, and the server combines multiple anti-replay related information and encrypts them. Compared with the prior art in which the client calculates and generates anti-replay information, it is proposed that the server provide anti-replay information so that the client side will not expose the real information and calculation rules, so that the attacker cannot guess the verification scheme or crack the actual information contained in the token, thereby improving the security of the anti-replay information; on the other hand, since the anti-replay parameters are obtained directly from the server, the client of any business can easily access the anti-replay function, thereby improving the access convenience and functional versatility.

[0075] In some implementations, before the server processes the first service request based on the second verification result, the method further includes: determining whether to perform fault tolerance degradation processing based on field information of the first token.

[0076] Specifically, refer to Figure 5 , Figure 5 Schematic diagram of the process of the anti-replay method provided in the embodiment of the present application Figure 3 ,like Figure 5 As shown, determining whether to perform fault-tolerant degradation processing based on the field information of the first token includes the following steps:

[0077] Step 501: Extract field information of the first token, where the field information includes: a first field, a second field, a third field, and a fourth field.

[0078] Before processing the first service request, the server needs to determine whether fault tolerance degradation was performed when generating the first token. Specifically, the server extracts field information k1 from the first token. For example, the server generates the first token based on the first, second, third, and fourth fields. The server extracts the basic fields from field information k1, for example, the first field t1, the second field s1, the third field r1, and so on.

[0079] Step 502: Determine whether to perform fault-tolerant degradation processing based on the third field; if the third field is the first character, determine whether the cache is available based on the first cache tag; if the cache is not available, perform fault-tolerant degradation processing; or, if the third field is the second character, perform fault-tolerant degradation processing.

[0080] Here, after extracting the field information of the first token, first determine whether the server performed fault-tolerant degradation when generating the first token based on the value of the third field r1. If the third field r1 is the first character, for example, r1 = "1", it means that the server has previously stored the key value corresponding to s1 in the distributed cache. At this time, determine whether the distributed cache is available. If it is not available, it means that the server needs to perform fault-tolerant degradation processing for verification logic. Alternatively, if the third field is the second character, that is, r1 = "0", or r1 is not equal to the first character, it means that the distributed cache is unavailable when the server generates the first token, and the server needs to perform fault-tolerant degradation processing for verification logic.

[0081] In some embodiments, fault-tolerant degradation processing is performed, including: obtaining third time information, the third time information indicating the first time when the server receives the first business request; obtaining the first time information based on the first field, obtaining the second time information based on the fourth field, and determining the fourth time information based on the difference between the third time information and the first time information; judging whether the fourth time information is greater than the second time information, and if so, determining that the verification result is the first verification result; if less than or equal to, determining that the verification result is the second verification result.

[0082] Here, if the third field is the second character, that is, r1 = "0", or r1 is not equal to the first character, it means that the server needs to perform fault-tolerant degradation processing. Specifically, the third time information is obtained, and the third time information represents the current timestamp t2 of the server. It is determined whether the difference between the third time information and the first time information is less than or equal to the second time information, that is, it is determined that t2-t1 <= the configured token validity period ttl. If it is greater than, it means that the first token has expired, and the server determines that the verification result is the first verification result and intercepts the first service request. If the difference between the third time information and the first time information is less than or equal to the second time information, and the k1 component field does not include other field information, then the verification result is determined to be the second verification result, that is, the first service request is determined to be a non-replay request, and the server processes the first service request; if there is other field information in the k1 component field, then the verification processing continues according to the other field information. For example, in some scenarios, the token is restricted to being bound to the customer ID. That is, the k1 component field also includes a fifth field, the customer ID. Then, it is determined whether the current customer ID is consistent with the customer ID in k1. If there is no other field logic to be determined in k1, it means that the first business request is legal and has passed the anti-replay check.

[0083] From the above, it can be seen that in the anti-replay method provided in the embodiment of the present application, before the server processes the first business request based on the second verification result, it also determines whether to perform fault-tolerant degradation processing based on the field information of the first token. Specifically, the field information of the first token is extracted, and the field information includes: the first field, the second field, the third field and the fourth field; based on the third field, it is determined whether to perform fault-tolerant degradation processing; if the third field is the first character, it is determined whether the cache is available based on the first cache mark, and if the cache is not available, fault-tolerant degradation processing is performed; or, if the third field is the second character, fault-tolerant degradation processing is performed; in this way, the current Internet field solves the problem of failure between service nodes and component dependencies in anti-replay attacks in a distributed system environment, and ensures the reliable operation of the anti-replay function in a distributed system.

[0084] In some embodiments, in step 502, if the third field is the first character, then when determining whether the cache is available based on the first cache tag, if the cache is available, then querying whether the key value information of the first token is stored in the cache based on the second field; if the key value information of the first token is stored, then determining whether the key value information of the first token is equal to the first value; if it is equal to the first value, then determining that the verification result is the second verification result, and setting the key value corresponding to the second field in the cache to the second value; if it is not equal to the first value, then determining that the verification result is the first verification result.

[0085] Here, after extracting the field information of the first token, if the third field r1 is the first character, for example, r1 = "1", it means that the server has previously stored the key value corresponding to s1 in the distributed cache. At this time, it is determined whether the distributed cache is available. If it is available, the key value information of the first token stored in the cache component is determined. Specifically, if s1 has been stored in the cache before, and the cache_flag field is true, that is, the distributed cache is also available, then the key value corresponding to s1 is queried from the distributed cache, for example, value = getCache (s1). If value exists, then it is determined whether the key value value corresponding to s1 is the first numerical value, for example, whether value is equal to 1. If it is equal to 1, it means that this s1 is valid and has not been used. At this time, if the k1 component field does not include other field information, then the verification result is determined to be the second verification result, that is, the first business request is determined to be a non-replay request, and the server processes the first business request; if there is other field information in the k1 component field, then the verification process continues based on the other field information. For example, in some scenarios, the token is restricted to being bound to the customer ID. That is, the k1 component field also includes a fifth field, the customer ID. Then, it is determined whether the current customer ID is consistent with the customer ID in k1. If there is no other field logic to be determined in k1, it means that the first business request is legal and has passed the anti-replay check.

[0086] In some embodiments, it is determined that value is equal to 1, s1 is valid and has not been used, and the verification result is determined to be the second verification result. After the server processes the first business request, the server sets the key value corresponding to the second field in the cache to the second value, that is, sets the value corresponding to s1 in the cache to 0, for example, s1:0, to indicate that the token value in the distributed cache component has been used.

[0087] In some embodiments, if the key value corresponding to the second field s1 in the cache is not equal to the first value, it is determined whether the key value corresponding to s1 in the cache is the second value. If the key value is the second value 0, it means that s1 is valid but has been used. At this time, the first business request is a replay request, and the server intercepts the first business request; if the key value corresponding to the second field s1 in the cache does not exist, it means that s1 has expired, and the server intercepts the second business request sent by the client.

[0088] As can be seen from the above, the anti-replay method provided by the embodiment of the present application is aimed at the problem that the anti-replay function is unavailable due to the strong dependence of the distributed environment on the storage component, and the storage failure caused by it. It is proposed to take into account the fault tolerance of the system in the distributed environment, and combine the data related to fault tolerance, anti-replay related feature information and key values ​​together, so that the server can automatically tolerate the abnormal scene of the storage component. When the storage component cannot be connected, the request reports an error, etc., the server can automatically tolerate the downgrade of the anti-replay judgment rule, so that the normal use of the anti-replay function is still guaranteed without the client's perception. In addition, in order to solve the problem that the storage in the prior art gradually accumulates and it is impossible to find a suitable time for cleaning, verification storage and automatic expiration are proposed, which can delete historical storage in a timely manner and ensure the correctness of the anti-replay function.

[0089] Example 1

[0090] Figure 6 This is a flowchart of the anti-replay method provided in the embodiment of the present application. Figure 4 ,like Figure 6 As shown in the figure, after the server receives the anti-replay token sent by the client through the first interface, it generates the token carrying the anti-replay information through the internal second interface. The specific process is as follows:

[0091] 601. The client initiates a second service request to the server.

[0092] Here, the client initiates a token acquisition request to the server through the first interface getToken interface.

[0093] 602. After receiving the token acquisition request, the server obtains the current server timestamp t1, the globally unique string s1, and the token validity period ttl.

[0094] Here, after receiving the token request through the first interface, the server obtains the current server Unix timestamp as t1, uses algorithms such as uuid or snowflake to obtain a globally unique string s1, and obtains the validity period ttl of the token corresponding to the pre-configured interface.

[0095] 603. Mark whether the distributed cache is available according to the cache_flag field. If available, execute step 604; if not available, execute step 605.

[0096] Here, the server uses a distributed cache with automatic expiration. If the distributed cache fails, it automatically downgrades its anti-replay solution without client awareness, while still providing usable anti-replay functionality. Once the failure is resolved, it automatically resumes and upgrades, requiring no manual or client intervention. Specifically, each service instance with anti-replay functionality connects to the distributed cache component described in 1 and establishes a continuous liveness check for the distributed cache. A field called cache_flag is used to indicate whether the distributed cache is available. As the liveness check continues, the cache_flag field is continuously updated based on changes in the distributed cache's availability. When the liveness check indicates the cache is available, the cache_flag field is marked as true, and the r1 field is generated based on the cache_flag field. If true, r1 is 1. When the liveness check indicates the cache is unavailable, the cache_flag field is marked as false, and the r1 field is generated based on the cache_flag field. If false, r1 is 0.

[0097] Step 604: If the cache is available, set r1 = "1", set the key-value pair s1:1 in the distributed cache, and set ttl to the allowed token validity period. If the setting fails, reset r1 to "0".

[0098] Here, if the liveness detection finds that the cache is available, the cache_flag is marked as true, and the r1 field is generated based on the cache_flag field. If r1 = "1", the key-value pair s1:1 is set in the distributed cache, and the ttl is set to the allowed token validity period. If the setting fails, r1 is reset to "0", and step 606 is executed.

[0099] Step 605: If the cache is unavailable, perform fault tolerance degradation processing and set r1 = "0".

[0100] Here, when the liveness detection finds that the cache is unavailable, the cache_flag is marked as false, and the r1 field is generated according to the cache_flag generation field. When it is false, r1 is “0”. Then, step 606 is executed.

[0101] Step 606: Concatenate the basic fields to obtain k1, and generate the final token based on the encryption code.

[0102] Here, k1 is obtained by concatenating the basic fields. The concatenation method is not restricted, as long as the fields can be distinguished. For example, k1 = r1_s1_t1 can be used. Other fields can also be added here, such as the customer ID, k1 = r1_s1_t1_id, which can be bound to a unique string for further precision verification. Alternatively, for tokens with different expiration dates, different expiration dates can be concatenated, k1 = r1_s1_t1_ttl, and the ttl value can be used to verify that the token is within the expiration date. The final token is then encrypted and generated using e_base64(encodeAes(k1, salt)).

[0103] 607. The server sends a token to the client.

[0104] Here, the final token is encrypted by the server, making it impossible to parse the original data. Furthermore, it's difficult to forge a token that meets the decryption rules, ensuring the security of the original data. The client doesn't need to know the token generation rules; it only needs to include the token value in subsequent requests, ensuring convenient client access and the security of the token generation rules.

[0105] Example 2

[0106] Figure 7 This is a flowchart of the anti-replay method provided in the embodiment of the present application. Figure 5 ,like Figure 7 As shown in the figure, after receiving the first service request with a token from the client, the server verifies the token to implement the specific steps of preventing the interface from being replayed in a distributed environment with good security and high availability. The specific process is as follows:

[0107] Step 701: The client initiates a first service request, which carries a token.

[0108] Here, the server uses the second interface verifyToken for replay verification to perform anti-replay verification on the token.

[0109] Step 702: Decode and symmetrically decrypt the token to determine whether a legal k1 is obtained.

[0110] Here, the token is first verified to be legitimate by performing base64 decoding and symmetric decryption on it, such as decodeAes(d_base64(token)). If decryption is successful, the k1 component format is analyzed to see if it is legitimate. For example, if it is r1_s1_t1_... during encryption, the k1 format is analyzed to see if it is correct. If so, step 703 is executed. If decoding or decryption fails, or if parsing the k1 format fails, it means that the token is forged, and step 709 is executed to return to interception.

[0111] Step 703: Extract field information based on k1 to obtain r1_s1_t1_ttl.

[0112] Here, each field is extracted according to the component field information of k1, such as r1, s1, t1...

[0113] Step 704: Determine whether fault tolerance degradation is performed when generating the token based on the value of r1.

[0114] Here, if r1 == "1", it means that s1 was previously stored in the cache. If the distributed cache is available at this time, the value of s1 is queried from the distributed cache (value = getCache(s1)), and step 605 is executed. If r1 == "1" but the distributed cache is unavailable at this time, it indicates that the verification logic needs to be downgraded, and step 707 is executed. If r1 != "1", it means that the distributed cache was unavailable when the token was obtained, and downgrade processing was performed at that time, and step 707 is executed.

[0115] Step 705: Request the value of s1 from the distributed cache (value=getCache(s1)).

[0116] Here, if the request is successful, step 706 is executed; if the request fails, step 707 is executed to perform downgrade processing.

[0117] Step 706: If value exists, determine whether value is equal to 1. If it is equal to 1, it means that s1 is valid and has not been used. At this time, it is necessary to process according to whether there are other component fields in k1. If k1 also includes the customer id, then the judgment of whether the current customer id is consistent with the customer id in k1 can be continued; if there is no other field logic to be judged in k1, it means that this request is legal and has passed the anti-replay check. If value is not equal to 1, it means that s1 is valid but has been used, and the second business request is a replay request and is intercepted. If value does not exist, it means that the token is invalid or has expired and has been automatically deleted, and the server rejects the second business request.

[0118] Step 707: If r1! = "1", obtain the token validity period (ttl), obtain the server's current time (t2), and determine whether the difference between t2 and t1 is greater than ttl. If so, the token is invalid and the request is rejected. Additional verification can be performed based on whether other components in k1 exist. If k1 also includes the customer ID, the current customer ID can be checked to see if it matches the customer ID in k1.

[0119] Step 708: The server returns the verification result.

[0120] As can be seen from the above, the anti-replay method proposed in the embodiment of the present application, by combining data security encryption, automatic component detection, automatic fault tolerance and degradation measures, proposes that the server generates tokens securely, verifies tokens more conveniently, separates tokens from actual unique strings, and automatically associates tokens with degradation fault tolerance, thereby providing a highly secure and highly available anti-replay capability that is not restricted by language or business scenarios, and can achieve anti-replay requirements by simply following technical steps. Specifically, on the one hand, it solves the weaknesses of low data security, easy prediction and forgery in current anti-replay attack technologies, and can cope with scenarios where storage component failures in distributed systems cause anti-replay functions to be unavailable, thereby improving the security and availability of anti-replay capabilities. On the other hand, it proposes an innovative method for generating anti-replay token values ​​to avoid exposing real data and rules to the client, so that attackers can no longer forge data. In addition, since the token value is completely generated by the server, any client can easily access it, lowering the client access threshold; the token value can also be accompanied by other information that can be used to further strengthen the judgment. Third, there is no longer a strong reliance on storage components. Instead, a distributed cache with automatic expiration function is used. When a distributed cache fails, the anti-replay judgment solution can be automatically downgraded without the client's awareness, while still providing an available anti-replay function. When the fault is resolved, the upgrade can be automatically restored. The entire process does not require manual or client intervention.

[0121] Figure 8 This is a schematic diagram of the structure of the anti-replay device provided in the embodiment of the present application. Figure 1 , applied to the server, such as Figure 8 As shown, the anti-replay device 800 includes:

[0122] The receiving unit 801 is configured to receive a first service request sent by a client, where the first service request carries a first token, and the first token is composed by the server based on field information.

[0123] The detection unit 802 is used to perform a legitimacy check on the first token to obtain a first detection result, and the first detection result is used to verify whether the first token after decoding and decryption is legal; it is also used to perform a legitimacy check on the first detection result to obtain a second detection result, and the second detection result is used to verify whether the format of the field information composition is legal.

[0124] The determining unit 803 is configured to determine a verification result based on the first detection result and / or the second detection result, where the verification result is used to indicate whether to intercept or process the first service request.

[0125] In some embodiments, the receiving unit 801 receives a first business request sent by the client, the first business request carries a first token, and the first token is composed of first field information. It is also used to receive a second business request sent by the client, and the second business request is used to obtain the first token.

[0126] In some implementations, the anti-replay device 800 further includes: a processing unit 804 .

[0127] The processing unit 804 is configured to generate the first token based on the second service request, where the first token is composed of the field information; and encrypt the first token to generate an encrypted first token.

[0128] In some implementations, the anti-replay device 800 further includes: a sending unit 805 .

[0129] The sending unit 805 is configured to send the encrypted first token to the client.

[0130] In some embodiments, the processing unit 804 is further used to obtain first time information, set a first field based on the first time information, and the first field is used to indicate the first time when the server receives the second business request; generate first identification information, set a second field based on the first identification information, and the second field is used to indicate the key value information of the first token in the cache; create a first cache mark, set a third field based on the first cache mark, and the third field is used to indicate the available information of the first token in the cache; obtain second time information, set a fourth field based on the second time information, and the fourth field is used to indicate that the first token is valid within a first preset range; and compose the first token based on the first field, the second field, the third field, and the fourth field.

[0131] In some embodiments, the processing unit 804 is further used to create the first cache tag, which is used to detect whether the cache is available, and the cache is used to store the key value information and the second time information of the first token in the cache; determine whether the cache is available based on the first cache tag; if available, set the third field to the first character, set the key value corresponding to the second field in the cache to the first value, and set the fourth field to the first preset time; if unavailable, set the third field to the second character, and the second character is used to indicate fault-tolerant degradation processing of the first token.

[0132] In some embodiments, the detection unit 802 is further used to decode and decrypt the first token; if the decoding and decryption of the first token fails, the first detection result is used to indicate that the first token is illegal; if the decoding and decryption of the first token is successful, a decoded and decrypted first token is generated, and the first detection result is used to indicate that the first token is legal; if the decoding and decryption of the first token is successful, a decoded and decrypted first token is generated, and the field information of the first token is parsed; if the field information composition format parsing fails, the second detection result indicates that the first token is illegal; if the field information composition format parsing is successful, the second detection result indicates that the first token is legal.

[0133] In some embodiments, the determination unit 803 is further used to determine that the verification result is a first verification result if the first detection result and / or the second detection result indicates that the first token is illegal, and intercept the first business request based on the first verification result; if the second detection result indicates that the first token is legal, determine that the verification result is a second verification result.

[0134] In some implementations, the processing unit 804 is configured to process the first service request based on the second verification result.

[0135] In some implementations, before processing the first service request based on the second verification result, the determining unit 803 is further configured to determine whether to perform fault tolerance degradation processing based on field information of the first token.

[0136] In some embodiments, the determination unit 803 is further used to extract field information of the first token, the field information including: a first field, a second field, a third field and a fourth field; determine whether to perform fault-tolerant degradation processing based on the third field; if the third field is the first character, determine whether the cache is available based on the first cache tag, and if the cache is not available, perform fault-tolerant degradation processing; or, if the third field is the second character, perform fault-tolerant degradation processing.

[0137] In some embodiments, the processing unit 804 is also used to perform fault-tolerant degradation processing; specifically, it is used to obtain third time information, where the third time information indicates the first time when the server receives the first business request; obtain the first time information based on the first field, obtain the second time information based on the fourth field, and determine the fourth time information based on the difference between the third time information and the first time information; determine whether the fourth time information is greater than the second time information, and if so, determine that the verification result is the first verification result; if less than or equal to, determine that the verification result is the second verification result.

[0138] In some embodiments, the processing unit 804 is also used to, if the cache is available, query whether the key value information of the first token is stored in the cache based on the second field; if the key value information of the first token is stored, determine whether the key value information of the first token is equal to the first value; if it is equal to the first value, determine that the verification result is the second verification result, and set the key value corresponding to the second field in the cache to the second value; if it is not equal to the first value, determine that the verification result is the first verification result.

[0139] Those skilled in the art should understand that Figure 8 The functions implemented by each unit in the anti-replay device shown can be understood by referring to the relevant description of the aforementioned method. Figure 8 The functions of the various units in the anti-replay device shown can be implemented by a program running on a processor, or by a specific logic circuit.

[0140] Figure 9 900 is a schematic structural diagram of an electronic device provided in an embodiment of the present application. The electronic device may be a server, Figure 9 The electronic device 900 shown includes a processor 910, which can call and run a computer program from a memory to implement the method in the embodiment of the present application.

[0141] Alternatively, as Figure 9As shown, the electronic device 900 may further include a memory 920. The processor 910 may call and execute a computer program from the memory 920 to implement the method in the embodiment of the present application.

[0142] The memory 920 may be a separate device independent of the processor 910 , or may be integrated into the processor 910 .

[0143] Alternatively, as Figure 9 As shown, the electronic device 900 may further include a transceiver 930 , and the processor 910 may control the transceiver 930 to communicate with other devices. Specifically, it may send information or data to other devices, or receive information or data sent by other devices.

[0144] The transceiver 930 may include a transmitter and a receiver. The transceiver 930 may further include an antenna, and the number of antennas may be one or more.

[0145] Optionally, the electronic device 900 may specifically be a server in an embodiment of the present application, and the electronic device 900 may implement the corresponding processes implemented by the server in each method in the embodiment of the present application. For the sake of brevity, they will not be repeated here.

[0146] It should be understood that the processor of the embodiments of the present application may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiment can be completed by hardware integrated logic circuits in the processor or software instructions. The above processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of the present application can be directly implemented as a hardware decoding processor, or can be implemented by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0147] It is understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM bus random access memory (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0148] It should be understood that the above-mentioned memories are exemplary but not restrictive. For example, the memories in the embodiments of the present application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM RAM (DR RAM), etc. In other words, the memories in the embodiments of the present application are intended to include, but are not limited to, these and any other suitable types of memories.

[0149] An embodiment of the present application also provides a computer-readable storage medium for storing a computer program.

[0150] Optionally, the computer-readable storage medium can be applied to the network device in the embodiments of the present application, and the computer program enables the computer to execute the corresponding processes implemented by the network device in the various methods of the embodiments of the present application. For the sake of brevity, they are not repeated here.

[0151] Optionally, the computer-readable storage medium can be applied to the mobile terminal / terminal device in the embodiments of the present application, and the computer program enables the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of the present application. For the sake of brevity, they will not be repeated here.

[0152] An embodiment of the present application also provides a computer program product, including computer program instructions.

[0153] Optionally, the computer program product can be applied to the network device in the embodiments of the present application, and the computer program instructions enable the computer to execute the corresponding processes implemented by the network device in the various methods of the embodiments of the present application. For the sake of brevity, they are not repeated here.

[0154] Optionally, the computer program product can be applied to the mobile terminal / terminal device in the embodiments of the present application, and the computer program instructions enable the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of the present application. For the sake of brevity, they will not be repeated here.

[0155] The embodiment of the present application also provides a computer program.

[0156] Optionally, the computer program can be applied to the server in the embodiments of the present application. When the computer program runs on a computer, the computer executes the corresponding processes implemented by the server in the various methods of the embodiments of the present application. For the sake of brevity, they will not be repeated here.

[0157] Optionally, the computer program can be applied to the client in the embodiments of the present application. When the computer program runs on the computer, the computer executes the corresponding processes implemented by the client device in the various methods of the embodiments of the present application. For the sake of brevity, they are not repeated here.

[0158] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0159] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0160] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0161] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0162] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0163] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0164] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. An anti-replay method, characterized in that: Applied to a server, the method comprises: Receive a first service request sent by a client, where the first service request carries a first token, and the first token is composed by the server based on field information; Performing a legitimacy check on the first token to obtain a first check result, where the first check result is used to verify whether the first token after decoding and decryption is legal; Performing a legality check on the first detection result to obtain a second detection result, wherein the second detection result is used to verify whether the format of the field information is legal; A verification result is determined based on the first detection result and / or the second detection result, where the verification result is used to indicate intercepting or processing the first service request.

2. The method according to claim 1, characterized in that Before receiving a first service request sent by a client, wherein the first service request carries a first token, and the first token is composed by the server based on field information, the method further includes: Receive a second service request sent by the client, where the second service request is used to obtain the first token; generating the first token based on the second service request, where the first token consists of the field information; The first token is encrypted to generate an encrypted first token, and the encrypted first token is sent to the client.

3. The method according to claim 2, characterized in that The first token is generated based on the second service request, and the first token is composed of the field information, including: Acquire first time information, and set a first field based on the first time information, where the first field is used to indicate a first time when the server receives the second service request; Generate first identification information, and set a second field based on the first identification information, where the second field is used to indicate key value information of the first token in the cache; Creating a first cache tag, and setting a third field based on the first cache tag, wherein the third field is used to indicate available information of the first token in the cache; Acquire second time information, and set a fourth field based on the second time information, where the fourth field is used to indicate that the first token is valid within a first preset range; The first token is composed based on the first field, the second field, the third field and the fourth field.

4. The method according to claim 3, characterized in that The method further comprises: Creating the first cache marker, where the first cache marker is used to detect whether a cache is available, and the cache is used to store key value information of the first token in the cache and the second time information; Determining whether the cache is available based on the first cache tag; If available, setting the third field to the first character, setting the key value corresponding to the second field in the cache to the first value, and setting the fourth field to the first preset time; If not available, the third field is set to a second character, where the second character is used to indicate that fault-tolerant degradation processing is performed on the first token.

5. The method according to claims 1 to 4, characterized in that The performing a legitimacy check on the first token to obtain a first check result, wherein the first check result is used to verify whether the first token after decoding and decryption is legal, includes: Decoding and decrypting the first token; if the decoding and decryption of the first token fails, the first detection result is used to indicate that the first token is illegal; If the first token is decoded and decrypted successfully, a decoded and decrypted first token is generated, and the first detection result is used to indicate that the first token is legal; Correspondingly, the first detection result is subjected to a legality check to obtain a second detection result, and the second detection result is used to verify whether the field information composition format is legal, including: If the first token is decoded and decrypted successfully, a decoded and decrypted first token is generated, and field information of the first token is parsed; If the parsing of the format of the field information composition fails, the second detection result indicates that the first token is illegal; if the parsing of the format of the field information composition succeeds, the second detection result indicates that the first token is legal; Accordingly, determining a verification result based on the first detection result and / or the second detection result, wherein the verification result is used to indicate intercepting or processing the first service request, includes: If the first detection result and / or the second detection result indicates that the first token is illegal, determining that the verification result is a first verification result, and intercepting the first service request based on the first verification result; If the second detection result indicates that the first token is legal, the verification result is determined to be a second verification result, and the first service request is processed based on the second verification result.

6. The method according to claim 5, characterized in that Before processing the first service request based on the second verification result, the method further includes: Determining whether to perform fault tolerance degradation processing based on the field information of the first token; The determining whether to perform fault tolerance degradation processing based on the field information of the first token includes: Extracting field information of the first token, the field information including: a first field, a second field, a third field, and a fourth field; Determine whether to perform fault-tolerant downgrade processing based on the third field; if the third field is the first character, determine whether the cache is available based on the first cache tag, and if the cache is not available, perform fault-tolerant downgrade processing; or, if the third field is the second character, perform fault-tolerant downgrade processing.

7. The method according to claim 6, characterized in that The fault-tolerant degradation processing includes: Acquire third time information, where the third time information indicates a first time when the server receives the first service request; Acquire first time information based on the first field, acquire second time information based on the fourth field, and determine fourth time information based on a difference between the third time information and the first time information; Determine whether the fourth time information is greater than the second time information; if so, determine that the verification result is the first verification result; if less than or equal to, determine that the verification result is the second verification result.

8. The method according to claim 7, characterized in that The method further comprises: If the cache is available, querying whether the key value information of the first token is stored in the cache based on the second field; If the key value information of the first token is stored, determining whether the key value information of the first token is equal to a first value; If it is equal to the first value, determining that the verification result is the second verification result, and setting the key value corresponding to the second field in the cache to the second value; If it is not equal to the first value, the verification result is determined to be the first verification result.

9. An anti-replay device, characterized in that: Applied to a server, the device comprises: A receiving unit, configured to receive a first service request sent by a client, wherein the first service request carries a first token, and the first token is formed by the server based on field information; A detection unit, configured to perform a legitimacy detection on the first token to obtain a first detection result, wherein the first detection result is used to verify whether the first token after decoding and decryption is legal; and further configured to perform a legitimacy detection on the first detection result to obtain a second detection result, wherein the second detection result is used to verify whether the format of the field information composition is legal; A determination unit is used to determine a verification result based on the first detection result and / or the second detection result, and the verification result is used to indicate intercepting or processing the first service request.

10. An electronic device, characterized in that: include: A processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory to execute the method according to any one of claims 1 to 8.

Images