List-based session replay defense method, system, equipment and medium

Abstract

The invention discloses a List-based session replay defense method, a List-based session replay defense system, List-based session replay defense equipment and a List-based session replay defense medium, belongs to the technical field of network security, and aims to solve the technical problem of how to effectively prevent session replay attacks and improve the flexibility and expandability of preventing the session replay attacks at the same time. According to the technical scheme, a client generates a unique identifier through a UUID generation algorithm and attaches the unique identifier to a request header; sending the request with the unique identifier to a server, and initializing the size of List; the server stores the processed request identifier by using the List; checking each request, and judging whether the request contains a corresponding request identifier or not: if so, indicating that the corresponding request exists, and directly returning false to indicate that the request is invalid; if not, adding the corresponding request identifier into the List, and returning true to indicate that the request is valid; judging whether the corresponding request identifier exceeds the set size of List; if yes, cleaning the request processed earliest; if not, no operation is performed.

Description

Technical Field

[0001] The present invention relates to the technical field of network security, and in particular to a List-based session replay defense method, system, device and medium. Background Art

[0002] Session replay attacks are a common form of cybersecurity. Attackers intercept legitimate session data and resend it at a later time, potentially gaining unauthorized access or performing illegal operations. Current defenses typically rely on mechanisms like timestamps, which can be limited when dealing with high-frequency requests.

[0003] Therefore, how to effectively prevent session replay attacks while improving the flexibility and scalability of preventing session replay attacks is a technical problem that needs to be solved urgently. Summary of the Invention

[0004] The technical task of the present invention is to provide a List-based session replay defense method, system, device and medium to solve the problem of how to effectively prevent session replay attacks while improving the flexibility and scalability of preventing session replay attacks.

[0005] The technical task of the present invention is achieved in the following manner: a List-based session replay defense method, the method is as follows:

[0006] The client generates a unique identifier using a UUID (Universally Unique Identifier) ​​generation algorithm and appends it to the request header;

[0007] Send the request with the unique identifier to the server to provide a basis for the server to determine whether the request is repeated and initialize the list size;

[0008] The server uses List to store processed request identifiers;

[0009] Check each request to see if it contains the corresponding request identifier:

[0010] If yes, it means the corresponding request already exists, and false is returned directly, indicating that the request is invalid;

[0011] If not, add the corresponding request identifier to the List and return true to indicate that the request is valid;

[0012] Determine whether the corresponding request identifier exceeds the set size of the List:

[0013] If so, clean up the oldest processed request;

[0014] If not, no action is taken.

[0015] Preferably, in an HTTP request scenario, the client adds the generated unique identifier to a custom field in the request header through the OkHttp or HttpClient network request library.

[0016] Preferably, after sending the request with the unique identifier to the server, call the lock.lock() method to obtain the lock and perform the locking operation to ensure that the operation of requestWindow is thread-safe in a multi-threaded environment;

[0017] When checking each request, use the requestWindow.contains(requestId) method to check whether the requestWindow list already contains the incoming requestId.

[0018] Preferably, adding the corresponding request identifier to the List is done by calling the requestWindow.addLast(requestId) method to add the corresponding request ID to the end of the requestWindow linked list.

[0019] Preferably, the determination of whether the corresponding request identifier exceeds the set size of the List is performed by calling the requestWindow.size() method to obtain the current size of the requestWindow list and comparing it with the windowSize:

[0020] When the size of the linked list exceeds windowSize, the requestWindow.removeFirst() method is called to remove the first element of the linked list to ensure that the size of the linked list does not exceed the set window size.

[0021] Preferably, during the execution of this method, regardless of whether an exception occurs, the lock.unlock() method is called in the finally block to release the lock, ensuring that the lock will eventually be released.

[0022] A List-based session replay protection system initializes the List size by constructing a SessionReplayProtection object and developing a filter to configure the path to the service to be called. When a session request is received, the isRequestValid method checks whether the request's unique identifier exists. If so, the request is rejected; otherwise, an addition operation is performed using a sliding window mechanism. The system includes a client and a server.

[0023] The client generates a unique identifier and appends it to the request header, which is then sent to the server along with the request. This provides a basis for the server to determine whether the request is a duplicate.

[0024] The server receives the client request, determines whether the request is a duplicate based on the unique identifier in the request header, maintains a list of request identifiers, and clears the earliest request identifier when the list exceeds a certain size.

[0025] Preferably, the client adds the generated unique identifier to a custom field in the request header through the OkHttp or HttpClient network request library in the HTTP request scenario;

[0026] The server determines whether a request is a duplicate based on the unique identifier in the request header, maintains a request identifier list, and clears the oldest request identifier when the request identifier list exceeds the set size. The server has the following functions:

[0027] ① Data storage: Use the list data structure provided by the programming language (such as LinkedList and ArrayList in Java) to store the request identifier;

[0028] ②Duplicate judgment: Use the search function of the list, that is, use the contains method to determine whether a specific request identifier already exists in the list.

[0029] ③Thread safety: In a multi-threaded environment, to prevent multiple threads from operating the list at the same time, causing data inconsistencies and other problems, the ReentrantLock lock mechanism in Java is used to ensure thread safety of list operations;

[0030] ④ Cleanup operation: When the list exceeds the set size, use the list's removal function, that is, use the removeFirst method to remove the earliest added element.

[0031] The key technologies involved in this invention mainly include List data structure and sliding window mechanism, which are as follows:

[0032] The List interface in Java is a sub-interface of the Collection interface and is mainly used to store a sequence of elements in an ordered order. The implementation classes of the List interface provide indexed access operations to the elements, which enables them to store the elements in a specific order. The following are some of the main features of the List interface:

[0033] ①Support fast search and insertion;

[0034] ② It is necessary to regularly clean up expired data to avoid excessive memory usage.

[0035] The sliding window mechanism is a commonly used algorithmic technique in Java. The core idea of ​​the sliding window mechanism is to maintain a window that can dynamically slide to delete a specific part of the data to solve the problem. The main features of the sliding window mechanism include:

[0036] Dynamic window size: The size of the sliding window can be changed dynamically, and the window size can be adjusted according to the needs of the problem;

[0037] ③Easy to understand and implement: The basic concept of sliding window is relatively simple, easy to understand and implement.

[0038] Multi-threaded concurrency control in Java mainly refers to the control and coordination of access and modification of shared resources in a multi-threaded environment to prevent data inconsistency or other concurrency problems, and the use of lock mechanisms (such as ReentrantLock) to ensure thread safety in a multi-threaded environment.

[0039] An electronic device comprising: a memory and at least one processor;

[0040] Wherein, the memory stores a computer program;

[0041] The at least one processor executes the computer program stored in the memory, so that the at least one processor performs the above-mentioned List-based session replay defense method.

[0042] A computer-readable storage medium stores a computer program, which can be executed by a processor to implement the above-mentioned List-based session replay defense method.

[0043] The List-based session replay defense method, system, device, and medium of the present invention have the following advantages:

[0044] (1) Efficiency: The present invention uses a sliding window mechanism to avoid infinite list growth and save memory;

[0045] (2) Real-time performance: The present invention regularly cleans up expired data to ensure that only valid request identifiers are retained;

[0046] (3) Scalability: The present invention supports distributed caching (such as Redis) to achieve scalability in high-concurrency scenarios and is suitable for high-concurrency scenarios;

[0047] (IV) Flexibility: The list size of the present invention can be configured as needed, and a sliding window mechanism is used to clear the earliest expired identifiers to adapt to different application scenarios;

[0048] (5) The present invention uses concurrency control mechanisms (such as ReentrantLock) to ensure thread safety in a multi-threaded environment;

[0049] (6) The present invention implements session replay defense through the List data structure and sliding window mechanism, which is efficient, flexible and scalable, and is suitable for various scenarios such as Web applications, payment systems, and distributed systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] The present invention will be further described below with reference to the accompanying drawings.

[0051] Attachment Figure 1 This is a flowchart of the List-based session replay defense method. DETAILED DESCRIPTION

[0052] The List-based session replay defense method, system, device, and medium of the present invention are described in detail below with reference to the accompanying drawings and specific embodiments.

[0053] Example 1:

[0054] As attached Figure 1 As shown, this embodiment provides a List-based session replay defense method, which is specifically as follows:

[0055] S1. The client generates a unique identifier using a UUID (Universally Unique Identifier) ​​generation algorithm and appends it to the request header.

[0056] S2. Send the request with the unique identifier to the server, providing a basis for the server to determine whether the request is repeated and initialize the list size;

[0057] S3, the server uses List to store processed request identifiers;

[0058] S4. Check each request to see if it contains the corresponding request identifier:

[0059] ① If yes, it means the corresponding request already exists, and false is returned directly, indicating that the request is invalid;

[0060] ②If not, proceed to step S5;

[0061] S5. Add the corresponding request identifier to the List and return true, indicating that the request is valid;

[0062] S6. Determine whether the corresponding request identifier exceeds the set size of the List:

[0063] ① If yes, clean up the earliest processed request;

[0064] ②If not, no operation.

[0065] In this embodiment, in an HTTP request scenario, the client adds the generated unique identifier to a custom field in the request header through the OkHttp or HttpClient network request library.

[0066] The following code snippets are part of the backend code encapsulation code of this embodiment:

[0067]

[0068]

[0069] The above code defines three class member variables and two methods:

[0070] (1) windowSize: This is a private and immutable integer type variable used to represent the size of the request window. The value can be reasonably set by evaluating the system's access volume, concurrency, etc. It is initialized during the class instantiation process and its value cannot be modified afterwards.

[0071] (2) requestWindow: This is a private and immutable LinkedList object that stores long request IDs. It is initialized when the class is instantiated, and subsequent operations will add or remove elements from this linked list.

[0072] (3) Lock: This is a static ReentrantLock type object used to implement thread synchronization and ensure that operations on requestWindow are thread-safe in a multi-threaded environment.

[0073] (4) SessionReplayProtection(int windowSize): This is the class constructor, which accepts an integer parameter windowSize. Inside the constructor, the passed windowSize parameter is assigned to the class member variable windowSize. A new LinkedList object is created and assigned to the requestWindow member variable, completing the class initialization.

[0074] (5) isRequestValid(long requestId): This is a public synchronous method that receives a Long parameter requestId and is used to determine whether the incoming request ID is valid. The specific execution steps are as follows:

[0075] ① Locking: Call the lock.lock() method to acquire the lock to ensure that the operation of requestWindow is thread-safe in a multi-threaded environment.

[0076] ② Check if the request already exists: Use the requestWindow.contains(requestId) method to check whether the requestWindow list already contains the passed requestId. If it does, it means that the request already exists, and the method directly returns false, indicating that the request is invalid.

[0077] ③Add request ID: If the request ID does not exist in the linked list, call the requestWindow.addLast(requestId) method to add the request ID to the end of the requestWindow linked list.

[0078] ④ Check the size of the linked list: Call the requestWindow.size() method to get the current size of the requestWindow linked list and compare it with windowSize. If the linked list size exceeds windowSize, call the requestWindow.removeFirst() method to remove the first element of the linked list to ensure that the size of the linked list does not exceed the set window size.

[0079] ⑤Unlock: Regardless of whether an exception occurs, call the lock.unlock() method in the finally block to release the lock to ensure that the lock will eventually be released.

[0080] ⑥Return result: If the request ID does not exist in the linked list and is successfully added to the linked list, the method returns true, indicating that the request is valid.

[0081] Example 2:

[0082] This embodiment provides a List-based session replay protection system. The system initializes the List size by constructing a SessionReplayProtection object and develops a filter to configure the path to the service to be called. When a session request is received, the isRequestValid method checks whether the request unique identifier exists. If so, the request is rejected; otherwise, an addition operation is performed using a sliding window mechanism. The system includes a client and a server.

[0083] The client generates a unique identifier and appends it to the request header, which is then sent to the server along with the request. This provides a basis for the server to determine whether the request is a duplicate.

[0084] The server receives the client request, determines whether the request is a duplicate based on the unique identifier in the request header, maintains a list of request identifiers, and clears the earliest request identifier when the list exceeds a certain size.

[0085] The client in this embodiment can use a UUID (Universally Unique Identifier) ​​generation algorithm to create a unique identifier; in an HTTP request scenario, the generated unique identifier is added to a custom field in the request header through the OkHttp or HttpClient network request library.

[0086] The server in this implementation determines whether a request is a duplicate based on the unique identifier in the request header, maintains a list of request identifiers, and removes the oldest request identifier if the list exceeds a set size. The server has the following functions:

[0087] ① Data storage: Use the list data structure provided by the programming language (such as LinkedList and ArrayList in Java) to store the request identifier;

[0088] ②Duplicate judgment: Use the search function of the list, that is, use the contains method to determine whether a specific request identifier already exists in the list.

[0089] ③Thread safety: In a multi-threaded environment, to prevent multiple threads from operating the list at the same time, causing data inconsistencies and other problems, the ReentrantLock lock mechanism in Java is used to ensure thread safety of list operations;

[0090] ④ Cleanup operation: When the list exceeds the set size, use the list's removal function, that is, use the removeFirst method to remove the earliest added element.

[0091] Example 3:

[0092] This embodiment also provides an electronic device, including: a memory and at least one processor;

[0093] wherein the memory stores computer-executable instructions;

[0094] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the List-based session replay defense method in any embodiment of the present invention.

[0095] The processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor may be a microprocessor or any conventional processor, etc.

[0096] The memory can be used to store computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and calling the data stored in the memory. The memory can mainly include a program storage area and a data storage area. The program storage area can store an operating system, at least one application required for a function, etc.; the data storage area can store data created based on the use of the terminal, etc. In addition, the memory can also include high-speed random access memory and non-volatile memory, such as a hard disk, internal memory, a plug-in hard disk, a smart memory card (SMC), a secure digital (SD) card, a flash memory card, at least one disk storage period, a flash memory device, or other volatile solid-state memory devices.

[0097] Example 4:

[0098] This embodiment also provides a computer-readable storage medium storing a plurality of instructions, which are loaded by a processor and cause the processor to execute the List-based session replay protection method according to any embodiment of the present invention. Specifically, a system or device equipped with a storage medium can be provided. The storage medium stores software program code that implements the functions of any of the above-described embodiments, and the computer (or CPU or MPU) of the system or device can read and execute the program code stored in the storage medium.

[0099] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute part of the present invention.

[0100] Examples of storage media for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-Rs, CD-RWs, DVD-ROMs, DVD-RYMs, DVD-RWs, DVD+RWs), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer via a communications network.

[0101] In addition, it should be clear that the functions of any of the above embodiments can be achieved not only by executing the program code read by the computer, but also by enabling the operating system operating on the computer to complete part or all of the actual operations based on the instructions of the program code.

[0102] In addition, it can be understood that the program code read from the storage medium is written into the memory provided in the expansion board inserted into the computer or into the memory provided in the expansion unit connected to the computer, and then based on the instructions of the program code, the CPU installed on the expansion board or expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above embodiments.

[0103] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A List-based session replay defense method, characterized in that: The method is as follows: The client generates a unique identifier using a UUID generation algorithm and appends it to the request header; Send the request with the unique identifier to the server and initialize the List size; The server uses List to store processed request identifiers; Check each request to see if it contains the corresponding request identifier: If yes, it means the corresponding request already exists, and false is returned directly, indicating that the request is invalid; If not, add the corresponding request identifier to the List and return true to indicate that the request is valid; Determine whether the corresponding request identifier exceeds the set size of the List: If so, clean up the oldest processed request; If not, no action is taken.

2. The List-based session replay defense method according to claim 1, characterized in that: In the HTTP request scenario, the client adds the generated unique identifier to the custom field of the request header through the OkHttp or HttpClient network request library.

3. The List-based session replay defense method according to claim 1, characterized in that: After sending the request with the unique identifier to the server, call the lock.lock() method to obtain the lock and perform the locking operation to ensure that the operation of requestWindow is thread-safe in a multi-threaded environment; When checking each request, use the requestWindow.contains(requestId) method to check whether the requestWindow list already contains the incoming requestId.

4. The List-based session replay defense method according to claim 1, characterized in that: Adding the corresponding request identifier to the List is done by calling the requestWindow.addLast(requestId) method to add the corresponding request ID to the end of the requestWindow list.

5. The List-based session replay defense method according to claim 1, characterized in that: To determine whether the corresponding request identifier exceeds the set size of the List, call the requestWindow.size() method to obtain the current size of the requestWindow list and compare it with windowSize: When the size of the linked list exceeds windowSize, the requestWindow.removeFirst() method is called to remove the first element of the linked list to ensure that the size of the linked list does not exceed the set window size.

6. The List-based session replay defense method according to any one of claims 1 to 5, characterized in that: During the execution of this method, regardless of whether an exception occurs, call the lock.unlock() method in the finally block to release the lock to ensure that the lock will eventually be released.

7. A List-based session replay defense system, characterized in that: Initialize the List size by constructing a SessionReplayProtection object and develop a filter to configure the path to the service to be called. When a session request is received, the isRequestValid method checks whether the request unique identifier exists. If so, the request is rejected. If not, an addition operation is performed using a sliding window mechanism. The system includes a client and a server. The client generates a unique identifier and appends it to the request header, which is then sent to the server along with the request. This provides a basis for the server to determine whether the request is a duplicate. The server receives the client request, determines whether the request is a duplicate based on the unique identifier in the request header, maintains a list of request identifiers, and clears the earliest request identifier when the list exceeds a certain size.

8. The List-based session replay defense system according to claim 7, characterized in that: In the HTTP request scenario, the client adds the generated unique identifier to the custom field of the request header through the OkHttp or HttpClient network request library; The server determines whether a request is a duplicate based on the unique identifier in the request header, maintains a request identifier list, and clears the oldest request identifier when the request identifier list exceeds the set size. The server has the following functions: ① Data storage: Use the list data structure provided by the programming language to store the request identifier; ②Duplicate judgment: Use the search function of the list, that is, use the contains method to determine whether a specific request identifier already exists in the list. ③Thread safety: In a multi-threaded environment, the ReentrantLock lock mechanism in Java is used to ensure thread safety of list operations; ④ Cleanup operation: When the list exceeds the set size, use the list's removal function, that is, use the removeFirst method to remove the earliest added element.

9. An electronic device, characterized in that: include: memory and at least one processor; Wherein, the memory stores a computer program; The at least one processor executes the computer program stored in the memory, so that the at least one processor performs the List-based session replay defense method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which can be executed by a processor to implement the List-based session replay defense method according to any one of claims 1 to 6.

Images