A Defense Method and System Against Replay Attacks

Abstract

The present invention provides a defense method and system against replay attacks, including: when receiving a page request sent by a client, determining whether there is session information of the client in the session table stored by the server; when there is no session information of the client in the session table, adding new session information of the client to the session table and sending a time redirect response to the client, so that the client re-sends a page request to the server after completing the time synchronization process with the server; performing time verification on the client request time carried by the page request; when the client request time verification is qualified, determining whether the page request has been processed by the server, and if the page request has not been processed by the server, determining that the page request is valid and returning the request content corresponding to the page request to the client. The present invention can implement the defense against replay attacks in a local area network where the client and the server have different times, improving the defense effect against replay attacks.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a defense method and system against replay attacks. Background Art

[0002] A replay attack usually means that a malicious network attacker intercepts a normal network request data packet through packet capture and then sends the data packet to the server by himself to obtain the corresponding request content. Existing replay attack defense technologies usually add a timestamp parameter to each HTTP request and then perform a digital signature on the timestamp and other parameters together. Since a normal HTTP request usually does not exceed 10 seconds from being sent to reaching the server, after the server receives the HTTP request, it first compares the timestamp parameter with the current time to determine whether it exceeds 10 seconds. If it times out, the HTTP request is considered an illegal request.

[0003] The existing replay attack defense method must satisfy that the time of the client and the server is synchronized. However, at present, the important systems of most enterprises and institutions are running in the internal local area network and cannot communicate with the Internet NTP server to complete time synchronization, and there is often no unified NTP server deployed in the internal local area network. And the time difference between some clients and the server can reach several minutes, resulting in the inapplicability of the defense scheme based on timestamp. Therefore, how to achieve the defense against replay attacks in the case where the internal local area network and the server cannot complete time synchronization has become an urgent problem to be solved. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a defense method and system against replay attacks, which can achieve the defense against replay attacks in a local area network where the client and the server are not time-synchronized, and can effectively screen out replay attacks, improving the defense effect against replay attacks.

[0005] In order to achieve the above purpose, the technical solutions adopted in the embodiments of the present invention are as follows:

[0006] In a first aspect, an embodiment of the present invention provides a defense method against replay attacks, including: when the server receives a page request sent by the client, determining whether the session information of the client exists in the session table stored by the server; when the session information of the client does not exist in the session table, adding the newly created session information of the client to the session table, and sending a time redirect response to the client, so that the client resends the page request to the server after completing the time synchronization process with the server; when the server receives the page request sent by the client again, or when the session information of the client exists in the session table, performing time verification on the client request time carried in the page request; when the client request time verification is qualified, determining whether the page request has been processed by the server, if the page request has not been processed by the server, determining that the page request is valid, and returning the request content corresponding to the page request to the client.

[0007] Further, an embodiment of the present invention provides a first possible implementation manner of the first aspect, wherein the page request carries the session cache information of the client, and the step of determining whether the session information of the client exists in the session table stored by the server includes: determining whether there is a session ID in the session table that is equal to the session ID in the session cache information, if so, determining that the session information of the client exists in the session table, if not, determining that the session information of the client does not exist in the session table.

[0008] Further, an embodiment of the present invention provides a second possible implementation manner of the first aspect, wherein the step of adding the newly created session information of the client to the session table and sending a time redirect response to the client, so that the client resends the page request to the server after completing the time synchronization process with the server includes: generating the session ID of the client based on the current local time of the server and a random number, denoted as the first session ID, and initializing all session parameters corresponding to the first session ID in the session table to 0; sending a redirect response pointing to the time synchronization page from the server to the client; wherein the redirect response carries the first session ID; when the client receives the redirect response, initiating a time synchronization request to the server based on the client, and when the time synchronization request is valid, resending the page request to the server.

[0009] Further, an embodiment of the present invention provides a third possible implementation manner of the first aspect. When the client receives the redirect response, the step of initiating a time synchronization request to the server based on the client and, when the time synchronization request is valid, sending the page request to the server again includes: when the client receives the redirect response, writing the first session ID into the session cache information of the client, denoted as the second session ID, and adding session parameters corresponding to the second session ID in the session cache information and initializing them to 0; where the session parameters corresponding to the second session ID include: the second client request time, the second request sequence number, and the second check code; loading a time synchronization page based on the client to write the current local time of the client into the second client request time, and initiating a time synchronization request to the server; where the time synchronization request carries the session cache information of the client; based on the server reading the session cache information to verify whether the time synchronization request is valid, if the time synchronization request is valid, updating the session parameters of the client in the session table, and sending a response message to the client; when the client receives the response message, determining whether the response message is valid, if the response message is valid, updating the session cache information in the client, and sending the page request to the server again.

[0010] Further, an embodiment of the present invention provides a fourth possible implementation manner of the first aspect. The session parameters corresponding to the first session ID in the session table include: the first client request time, the first request sequence number, the first check code, the server reception time, the time difference queue, the average time difference, and the valid sequence number set; the step of based on the server reading the session cache information to verify whether the time synchronization request is valid, if the time synchronization request is valid, updating the session parameters of the client in the session table includes: if both the first check code and the second check code are 0, or if the second request sequence number = the first request sequence number + 2, determining that the time synchronization request is valid; making the server reception time equal to the current local time of the server, making the first client request time equal to the second client request time, making the first request sequence number equal to the second request sequence number, the first check code = the first request sequence number + 1, inserting the server reception time - the first client request time into the time difference queue, making the average time difference equal to the current average value of the time difference queue, and inserting the first request sequence number into the valid sequence number set.

[0011] Further, a fifth possible implementation manner of the first aspect is provided in an embodiment of the present invention. Wherein, the first verification code is carried in the response message; the step of determining whether the response message is valid, and if the response message is valid, updating the session cache information in the client and sending the page request to the server again includes: if the first verification code = the second request sequence number + 1, determining that the response message is valid, making the second client request time equal to the current local time of the client, incrementing the second request sequence number by 2, and re - sending the page request to the server.

[0012] Further, a sixth possible implementation manner of the first aspect is provided in an embodiment of the present invention. Wherein, the step of performing time verification on the request initiation time carried in the page request when the server receives the page request sent by the client again, or when there is session information of the client in the session table includes: if there is a first session ID in the session table equal to the second session ID in the page request, obtaining the second client request time corresponding to the second session ID in the page request; determining whether the second client request time satisfies Stime server - Ctime quest <Time_span + W, if so, determining that the client request time verification is qualified, if not, determining that the page request is invalid; where Ctime quest is the second client request time, Stime server is the current local time when the server receives the page request, Time_span is the average time difference, and W is the preset delay threshold.

[0013] Further, a seventh possible implementation manner of the first aspect is provided in an embodiment of the present invention. Wherein, the step of determining whether the page request has been processed by the server, and if the page request has not been processed by the server, determining that the page request is valid includes: based on the server, determining whether the second request sequence number carried in the page request exists in the set of valid sequence numbers corresponding to the first session ID, if not, determining that the page request has not been processed by the server and determining that the page request is valid.

[0014] Further, an eighth possible implementation manner of the first aspect is provided in an embodiment of the present invention. Wherein, the defense method against replay attack further includes: when determining that the page request is valid, updating the session parameters corresponding to the first session ID in the session table based on the session cache information of the client carried in the page request.

[0015] In a second aspect, an embodiment of the present invention further provides a defense system against replay attacks, including: a server and a client; the server is configured to, when receiving a page request sent by the client, determine whether there is session information of the client in the session table stored by the server; the server is further configured to, when there is no session information of the client in the session table, add new session information of the client to the session table and send a time redirect response to the client, so that the client resends a page request to the server after completing the time synchronization process with the server; the server is further configured to, when the server receives the page request sent by the client again, or when there is session information of the client in the session table, perform time verification on the client request time carried in the page request; the server is further configured to, when the client request time verification is qualified, determine whether the page request has been processed by the server, and if the page request has not been processed by the server, determine that the page request is valid and return the request content corresponding to the page request to the client.

[0016] An embodiment of the present invention provides a defense method and system against replay attacks. The method includes: when a server receives a page request sent by a client, determining whether there is session information of the client in the session table stored by the server; when there is no session information of the client in the session table, adding new session information of the client to the session table and sending a time redirect response to the client, so that the client resends a page request to the server after completing the time synchronization process with the server; when the server receives the page request sent by the client again, or when there is session information of the client in the session table, performing time verification on the client request time carried in the page request; when the client request time verification is qualified, determining whether the page request has been processed by the server, and if the page request has not been processed by the server, determining that the page request is valid and returning the request content corresponding to the page request to the client.

[0017] The present invention first controls the client and the server to complete the time synchronization process when establishing the first session between the client and the server, so that when receiving a page request sent by the client, the server can perform time verification on the received page request, and can implement the defense against replay attacks in a local area network where the client and the server are not time-synchronized. By further determining whether the page request has been processed when the request time verification is qualified, the replay attacks can be effectively screened out, and the defense effect against replay attacks is improved.

[0018] Other features and advantages of the embodiments of the present invention will be described in the subsequent description, or some features and advantages can be inferred from the description without doubt, or can be known by implementing the above technologies of the embodiments of the present invention.

[0019] To make the above objects, features, and advantages of the present invention more obvious and understandable, the following specifically provides preferred embodiments and, in conjunction with the accompanying drawings, detailed descriptions are as follows. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0021] Figure 1 Shows a flowchart of a defense method against replay attacks provided by an embodiment of the present invention;

[0022] Figure 2 Shows a schematic diagram of listing the session parameter types in a session table provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will describe the technical solutions of the present invention in conjunction with the drawings. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention.

[0024] Currently, existing replay attack defense technologies are mainly implemented based on the timestamp and the nonce. For each HTTP request, the timestamp parameter needs to be added, and then the timestamp and other parameters are digitally signed together. Since a normal HTTP request generally does not exceed 10 seconds from being sent to reaching the server, after the server receives the HTTP request, it first determines whether the timestamp parameter exceeds 10 seconds compared with the current time. If it exceeds, the request is considered illegal. However, this solution depends on the synchronization of the time between the client and the server. Most important systems in enterprises and institutions operate in internal local area networks and cannot communicate with the Internet NTP server to complete time synchronization. There is often no unified NTP server deployed in the local area network. In these networks, the time difference between the client and the server can reach several minutes. In this case, the solution based on the timestamp is not applicable.

[0025] To improve the above problems, an embodiment of the present invention provides a defense method and system against replay attacks. The following provides a detailed introduction to the embodiments of the present invention.

[0026] This embodiment provides a defense method against replay attacks. Refer to Figure 1The flowchart of the defense method for replay attack shown in the figure comprises the following steps:

[0027] Step S102: When the server receives a page request sent by the client, it determines whether there is session information of the client in the session table stored in the server.

[0028] After the client browser (hereinafter referred to as the client) initiates a page request to the server, the server determines whether the client's session information already exists in the stored session table (Session table) based on the client's session cache information carried in the page request. The session information may include parameters that can identify the client, such as a session ID (SessionID), that is, to determine whether the client is establishing a session with the server for the first time.

[0029] In a specific implementation, it is determined whether there is a session ID in the session table that is equal to the session ID in the session cache information. If so, it is determined that the session information of the client exists in the session table. If not, it is determined that the session information of the client does not exist in the session table. After receiving the page request sent by the client, the server checks whether the session cache information carried in the page request includes a valid session ID (that is, the same session ID number also exists in the session table). If so, step S106 is executed. If not, step S104 is executed.

[0030] The above session cache information may be a cookie cache of the client, and the session cache information includes a session ID, a client request time Ctime, a request sequence number Ctag, and a check code Stag.

[0031] The server usually maintains a session table named Session in memory, which records the client information that has recently communicated with the server. The session parameters in the session table include: session ID, client request time Ctime, request sequence number Ctag and check code Stag, server reception time Stime, time difference queue Span, average time difference Time_span and valid sequence number set Nonce. See the meaning table of each parameter in the session table shown in Table 1 below. The meaning of each field is shown in Table 1 below:

[0032] Table 1 Meaning of parameters in the Session table

[0033]

[0034]

[0035] Step S104, when the session information of the client does not exist in the session table, add the newly created session information of the client to the session table, and send a time redirection response to the client, so that the client sends a page request to the server again after completing the time synchronization process with the server.

[0036] When the server determines that the session information of the client does not exist in the session table, it indicates that this is the first session between the client and the server recently. Add the newly created session information of this client to the session table, and control the server to return a redirection response pointing to the time synchronization page to the client, so that the client completes the time synchronization process with the server. Furthermore, the time relationship between the server local time and the client local time can be stored in the server's session table. After the client completes the time synchronization process with the server, it sends a page request to the server again, so as to perform time verification on the page request of this client.

[0037] Step S106, when the server receives the page request sent by the client again, or when the session information of the client exists in the session table, perform time verification on the client request time carried in the page request.

[0038] When the server receives the page request sent by the client again, the session information of this client has been newly added to the server's session table. When the session information of the client exists in the session table, it indicates that there is a session record between this client and the server recently. The session table of the server includes the session information of this client, that is, the session ID of this client is included in the session table.

[0039] Based on the server's current local time and the time relationship between the server local time and the client local time stored in the session table, determine whether the client request time carried in the page request is a timeout request. If not, determine that the client request time verification is qualified.

[0040] Step S108, when the client request time verification is qualified, determine whether the page request has been processed by the server. If the page request has not been processed by the server, determine that the page request is valid, and return the request content corresponding to the page request to the client.

[0041] When the client request time verification is qualified, judge whether the page request has been processed by the server based on the session cache information of the client carried in the page request. If the page request has not been processed by the server, consider this page request as a valid request, and the server returns the requested content to the client.

[0042] The above defense method against replay attacks provided by this embodiment controls the client and the server to complete the time synchronization process when establishing the first session, so that when receiving a page request sent by the client, the server can perform time verification on the received page request, and can realize the defense against replay attacks in a local area network where the client and the server are out of time synchronization. By further determining whether the page request has been processed when the request time verification is qualified, replay attacks can be effectively screened out, improving the defense effect against replay attacks.

[0043] In one embodiment, since the session parameter types included in the session cache information of the client are the same as some of the parameter types in the server session table, in order to facilitate the distinction of the session parameters of a certain client and the server, the session parameters of this client in the server can be respectively recorded as: the first session ID, the first client request time Ctime1, the first request sequence number Ctag1, and the first check code Stag1, the server reception time Stime, the time difference queue Span, the average time difference Time_span, and the valid sequence number set Nonce; the session parameters in the session cache information (Cookie cache) of this client can be respectively recorded as: the second session ID, the second client request time Ctime2, the second request sequence number Ctag2, and the second check code Stag2.

[0044] In one embodiment, this embodiment provides an implementation manner of adding the new session information of the client to the session table and sending a time redirection response to the client, so that the client can re-send a page request to the server after completing the time synchronization process with the server. The specific steps can be executed with reference to the following steps (1) to (3):

[0045] Step (1): Generate the session ID of the client based on the current local time of the server and a random number, denoted as the first session ID, and initialize all the session parameters corresponding to the first session ID in the session table to 0.

[0046] The server generates the session number of this client, that is, the session ID, according to the current local time and a random number, and updates and adds the session ID to the session table of the server, and initializes the other session parameters in the session table to 0, that is, initializes the first client request time Ctime1, the first request sequence number Ctag1, and the first check code Stag1, the server reception time Stime, the time difference queue Span, the average time difference Time_span, and the valid sequence number set Nonce corresponding to the first session ID in the session table to 0.

[0047] Step (2): Send a redirection response pointing to the time synchronization page from the server to the client.

[0048] The server returns a redirect response pointing to the time synchronization page to the client, and the first session ID corresponding to the client is carried in the redirect response.

[0049] Step (3): When the client receives the redirect response, initiate a time synchronization request to the server based on the client, and when the time synchronization request is valid, send a page request to the server again.

[0050] When the client receives the redirect response sent by the server, update the session cache information of the client, and send a time synchronization request to the server according to the session cache information, so that the server can verify the validity of the time synchronization request. When the time synchronization request is valid, the server stores the time difference between the local time of the client and the local time of the server. After the client completes the time synchronization process, send a page request to the server again, so that the server can re-verify the validity of the page request.

[0051] In a specific embodiment, this embodiment provides a time synchronization process between the client and the server, which can be specifically executed according to the following steps 1) to 4):

[0052] Step 1): When the client receives the redirect response, write the first session ID into the session cache information of the client, denoted as the second session ID, and add the session parameters corresponding to the second session ID in the session cache information and initialize them to 0.

[0053] When the client receives the redirect response, reset the local session cache information (Cookie cache information), store the first session ID newly created by the server for the client into the session cache information, denoted as the second session ID. The first session ID and the second session ID are essentially the same encoding. Add the session parameters corresponding to the second session ID in the session cache information. Among them, the session parameters corresponding to the second session ID include: the second client request time Ctime2, the second request sequence number Ctag2, and the second verification code Stag2. Initialize the fields of the second client request time Ctime2, the second request sequence number Ctag2, and the second verification code Stag2 to 0.

[0054] Step 2): Based on the client loading the time synchronization page to write the current local time of the client into the second client request time, initiate a time synchronization request to the server.

[0055] Write the above first session ID into the browser cookie, and redirect to the time synchronization page. After the time synchronization page is loaded, the page JavaScript script writes the current local time of the client into the second client request time Ctime2 corresponding to the second session ID (the Ctime2 field in the cookie), and then the client initiates a time synchronization request to the server. The time synchronization request carries the session cache information of the client, that is, it carries the second client request time Ctime2, the second request sequence number Ctag2, and the second verification code Stag2 corresponding to the second session ID.

[0056] Step 3): Based on the server reading the session cache information to verify whether the time synchronization request is valid. If the time synchronization request is valid, update the session parameters of the client in the session table, and send a response message to the client.

[0057] The session parameters corresponding to the first session ID in the server's session table include: the first client request time Ctime1, the first request sequence number Ctag1, and the first verification code Stag1, the server reception time Stime, the time difference queue Span, the average time difference Time_span, and the valid sequence number set Nonce.

[0058] After the server receives the time synchronization request from the client, it reads the session cache information (Cookie information) carried in it for judgment:

[0059] If both the first verification code and the second verification code are 0, or if the second request sequence number = the first request sequence number + 2, it is determined that the time synchronization request is valid. If the second verification code is 0 and the first verification code is not 0, then the time synchronization request is invalid, and the time synchronization request is discarded.

[0060] If the second verification code Stag2 carried in the time synchronization request is 0 and the first verification code Stag1 in the server's session table is also 0; or the second verification code Stag2 carried in the time synchronization request is not 0, and the second request sequence number Ctag2 carried in the time synchronization request is equal to the first request sequence number Ctag1 + 2 in the server's session table, it indicates that the time synchronization request sent by the client is valid, and the session parameter values in the session table of the server can be updated according to the session cache information carried in the time synchronization request.

[0061] When the time synchronization request is valid, update the session parameters in the session table: set the server reception time equal to the current local time of the server, set the first client request time equal to the second client request time, set the first request sequence number equal to the second request sequence number, the first check code = first request sequence number + 1, insert the server reception time - first client request time into the time difference queue, set the average time difference equal to the current average value of the time difference queue, and insert the first request sequence number into the valid sequence number set.

[0062] Let the server receiving time Stime be the local time when the server receives the time synchronization request, let the first client request time Ctime1 in the server session table be equal to the second client request time Ctime2 in the session cache information; let the first request sequence number Ctag1 in the server session table be equal to the second request sequence number Ctag2 in the session cache information; let the first check code Stag1 in the server session table = the updated first request sequence number Ctag1+1, insert Stime-Ctime1 into the insertion time difference queue Span, update the average time difference Time_span according to the current average value of the time difference queue, and insert the first request sequence number Ctag1 into the valid sequence number set Nonce. Then the server sends a response message to the client, which includes the server receiving time Stime and the first check code Stag1 in the session table.

[0063] Step 4): When the client receives the response message, it determines whether the response message is valid. If the response message is valid, the session cache information in the client is updated, and a page request is sent to the server again.

[0064] If the first check code Stag1 in the server's session table = the second request sequence number Ctag2+1, the response message is determined to be valid, the second client request time Ctime2 is set equal to the client's current local time, the second request sequence number Ctag2 is incremented by 2, and the page request is re-initiated to the server.

[0065] After the client synchronization page receives the response data packet sent by the server, it verifies whether the Stag1 contained in the response is equal to Ctag2+1 of the local cookie. If they are not equal, it means that the response data packet is invalid and discarded. If they are equal, the local cookie is updated, Ctime2 is set to the local time, Ctag2 is incremented by 2, and then a page request is sent to the server.

[0066] In one embodiment, this embodiment provides an implementation method for performing time verification on the request initiation time carried in the page request when the server receives the page request sent by the client again, or when the session information of the client exists in the session table. Specifically, the implementation method may refer to the following steps a to b:

[0067] Step a, if there is a first session ID in the session table that is equal to the second session ID in the page request, obtain the second client request time corresponding to the second session ID in the page request.

[0068] When the server receives a page request sent by the client or receives a page request sent again by the client, if there is a first session ID in the session table that is equal to the second session ID in the page request, it is determined that the verification of the session ID (SessionID) passes. The server obtains the second client request time Ctime2 corresponding to the second session ID from the page request sent by the client, that is, obtains the local time when the client sends this page request, denoted as Ctime. quest 。

[0069] Step b, determine whether the second client request time satisfies Stime server -Ctime quest <Time_span + W. If so, it is determined that the client request time verification is qualified; if not, it is determined that the page request is invalid.

[0070] Among them, Ctime quest is the second client request time, Stime server is the current local time when the server receives the page request, Time_span is the average time difference, and W is the preset delay threshold.

[0071] Determine whether the local time Ctime quest when the client sends this page request is valid. Usually, it is expected that the time taken for each page request to reach the server from the client is approximately equal, that is, it satisfies:

[0072] Stime server --Ctime quest ≈Time_span

[0073] Considering the transmission delay that may be caused by network fluctuations, adding a delay threshold W, then the above formula is equivalent to:

[0074] Stime server -Ctime quest <Time_span + W

[0075] The delay threshold W can be 5 to 10 s, and the preferred value is 10 s. If the time when the server receives the page request does not satisfy the above formula, it is considered that this page request is an invalid request. This page request may be a replay attack, and this page request is discarded.

[0076] If the time when the server receives the page request satisfies the above formula, based on the server's judgment of whether the second request sequence number Ctag2 carried in the page request exists in the valid sequence number set Nonce corresponding to the first session ID, if not, it is determined that the page request has not been processed by the server, and the page request is determined to be valid.

[0077] If the time when the server receives the page request satisfies the above formula, but the second request sequence number Ctag2 carried in the page request already exists in the valid sequence number set Nonce corresponding to the first session ID in the session table, it indicates that the server has already responded to this page request, and this page request is discarded.

[0078] If the time when the server receives the page request satisfies the above formula, and the second request sequence number Ctag2 carried in the page request does not exist in the valid sequence number set Nonce corresponding to the first session ID in the session table, it indicates that this page request is a valid request. The server returns the content requested by the client's page request and updates the session information corresponding to the first session ID in the server's session table Session.

[0079] In one embodiment, the method provided in this embodiment further includes: when it is determined that the page request is valid, updating the session parameters corresponding to the first session ID in the session table based on the session cache information of the client carried in the page request.

[0080] Let the server receive time Stime be the local time when the server receives the page request. Let the first client request time Ctime1 in the server session table be equal to the second client request time Ctime2 in the session cache information (i.e., the local time when the client initiates this page request); let the first request sequence number Ctag1 in the server session table be equal to the second request sequence number Ctag2 in the session cache information; let the first verification code Stag1 in the server session table = the updated first request sequence number Ctag1 + 1, insert Stime - Ctime1 into the time difference queue Span, update the average time difference Time_span according to the current average value of this time difference queue, and insert the first request sequence number Ctag1 into the valid sequence number set Nonce.

[0081] The above method for defending against replay attacks provided in this embodiment can defend against replay attacks based on the session mechanism, can implement the defense against replay attacks in a local area network with time asynchrony, can effectively intercept page requests repeatedly sent to the server, and can be applied to a local area network with time asynchrony, with wide applicability and improved network environment security.

[0082] On the basis of the foregoing embodiment, this embodiment provides an example of applying the method for defending against replay attacks, which can be specifically executed according to the following steps:

[0083] Step 1, the client browser (hereinafter referred to as the client) initiates a page request.

[0084] Step 2, after the server receives the page request, it checks whether there is session information of the client on the server. If not, execute Step 3; if so, execute Step 5.

[0085] The server maintains a session table named Session in memory, which records the session information of the clients that have communicated with the server recently. See the schematic diagram of the session parameter type list in the session table as shown in Figure 2 The session table includes session ID (SessionID), client request time Ctime, request sequence number Ctag and verification code Stag, server reception time Stime, time difference queue Span, average time difference Time_span and valid sequence number set Nonce. The capacity of the time difference queue Span is 5. The valid sequence number set Nonce stores the request sequence number Ctag of each valid request. The meanings of each field are shown in Table 1 above. After the server receives the page request from the client, it first checks whether the Cookie information carried in the page request contains a valid SessionID (that is, there is the same number as the client SessionID in the session table); if not, execute Step 3; if so, execute Step 5.

[0086] Step 3, the server creates a new session for the client in the session table and returns a redirect response pointing to the time synchronization page to the client.

[0087] The server creates a new session for the client in the session table Session. It includes the following steps:

[0088] a. The server generates the session ID (i.e., session ID) of the client based on the current time and a random number and updates it to the Session table. All other fields in the Session table are initialized to 0.

[0089] b. The server returns a redirect response pointing to the time synchronization page to the client, and the response contains the SessionID.

[0090] Step 4, after the client receives the response information returned by the server, it will be redirected to the time synchronization page, initiate the time synchronization process, and after completing the time synchronization process, it will initiate a page request to the server again.

[0091] After the client receives the response information returned by the server, it will be redirected to the time synchronization page and initiate the time synchronization process. It includes the following steps:

[0092] a) Reset the relevant Cookie cache (local cache information) in the browser, add fields such as SessionID, Ctime, Ctag, Stime, and Stag to the Cookie cache and assign initial values of 0.

[0093] b) Write the SessionID in the response information into the browser Cookie and redirect to the time synchronization page;

[0094] c) After the time synchronization page is loaded, the page javascript script writes the current local time of the client into the Ctime field in the Cookie, and then the client initiates a time synchronization request to the server, and the request carries Ctime, Ctag, and Stag in the client Cookie.

[0095] d) After the server receives the time synchronization request from the client, it reads the Cookie information carried in it for judgment:

[0096] If Stag in the time synchronization request is 0 and Stag in the server Session table is also 0; or, if Stag in the time synchronization request is not 0 and Ctag in the time synchronization request is equal to Ctag + 2 in the Session table, update each field in the Session table.

[0097] Let Ctime and Ctag in Session be equal to the Ctime and Ctag values in the time synchronization request, Stime be the current local time of the server, let Stag in Session = Ctag + 1, insert (Stime - Ctime) into the Span queue, Time_span be equal to the average value of the elements in the Span queue, and insert the Ctag in the request into the set Nonce in Session. Then the server sends a response message to the client, and the response message contains the Stime and Stag field values in the Seesion table.

[0098] If Stag in the time synchronization request is 0 while Stag in the Session table is not 0, then the time synchronization request is invalid and discard the time synchronization request.

[0099] e) After the client synchronization page receives the response message, verify whether the Stag included in the response message is equal to Ctag + 1 of the local Cookie. If not, it means the response message is invalid and discard it; if equal, update the local Cookie, let Ctime be the local time of the client, let Ctag increment by 2, and then re-initiate the page request in step 1 to the server.

[0100] Step 5. After the server receives the client request and verifies that the session information is passed, it will continue to verify whether the request initiation time is valid. If it is valid, it will continue to verify whether the request has been processed before. If the request initiation time is valid and it has not been processed by the server before, the request is determined to be valid.

[0101] After the server receives the page request from the client and verifies that the SessionID is passed, it will continue to verify whether the Ctime in the page request is valid. Generally, it is expected that the time taken for each page request to reach the server from the client is approximately the same. Denote the Ctime in the page request as Ctime quest Let the time when the server receives the page request be Stime server Let the average time difference between the client and the server stored in the server Session table be Time_span, then there is:

[0102] time server --Ctime quest ≈Time_span

[0103] Considering the transmission delay that may be caused by network fluctuations, adding a delay threshold W, then the above formula is equivalent to:

[0104] Stime server -Ctime quest <Time_span+W

[0105] If the Ctime in the page request received by the server does not satisfy the above formula, the page request can be considered an invalid request, which may be a replay attack and should be discarded.

[0106] If the Ctime in the page request satisfies the above formula, but the Ctag already exists in the Nonce set of the Session table, it means that the server has already responded to this page request and should be discarded.

[0107] If the Ctime in the page request satisfies the above formula and the Ctag does not exist in the Nonce set of the Session, the page request is considered a valid request. The server returns the content requested by the client and updates the Session information according to the following steps.

[0108] a) Update the Ctime and Ctag in the Session table to the Ctime and Ctag values in the page request;

[0109] b) Update the Stime in the Session table to the server local time, and update the Stag to Ctag+1;

[0110] c) Calculate Stime-Ctime and insert the result into the Span queue of the Session;

[0111] d) Calculate the mean value of the existing element values in the queue and assign the result to Time_span in the Session;

[0112] e) Insert the Ctag in the request into the set Nonce in the Session.

[0113] Step 6, the server regularly checks the Session table and clears the expired Session information.

[0114] Generally speaking, within a certain period of time, the usage environment of the client (including the user, network status, time setting) remains unchanged. Even if the server does not receive a new request from the client, the Session information of the client should be retained. However, if the time elapsed since the last request from the client exceeds a certain period, the Session information of the client should be cleared.

[0115] Considering that Stime in the Session table represents the local time of the server when the last request from the client was received, the server should regularly check the value of the Stime field in the Session table, calculate the difference between it and the current time, and clear the Session information (i.e., the session ID and its corresponding session information) of the client whose difference is greater than the set threshold.

[0116] Corresponding to the replay attack defense method provided in the above embodiments, an embodiment of the present invention provides a replay attack defense system, which includes: a server and a client.

[0117] The server is used to determine whether there is session information of the client in the session table stored by the server when receiving a page request sent by the client;

[0118] The server is also used to add new session information of the client to the session table and send a time redirection response to the client when there is no session information of the client in the session table, so that the client can resend a page request to the server after completing the time synchronization process with the server;

[0119] The server is also used to perform time verification on the client request time carried in the page request when the server receives the page request sent by the client again, or when there is session information of the client in the session table;

[0120] The server is also used to determine whether the page request has been processed by the server when the client request time verification is qualified. If the page request has not been processed by the server, it is determined that the page request is valid, and the request content corresponding to the page request is returned to the client.

[0121] The defense system against replay attacks provided in this embodiment controls the client and the server to complete the time synchronization process when establishing the first session, so that when receiving a page request sent by the client, the server can perform time verification on the received page request, and can realize the defense against replay attacks in a local area network where the client and the server are not time-synchronized. By further determining whether the page request has been processed when the request time verification is qualified, replay attacks can be effectively screened out, improving the defense effect against replay attacks.

[0122] In one implementation, the page request carries the session cache information of the client. The server is used to determine whether there is a session ID in the session table that is equal to the session ID in the session cache information. If it exists, it is determined that there is session information of the client in the session table. If it does not exist, it is determined that there is no session information of the client in the session table.

[0123] In one implementation, the server is used to generate the session ID of the client based on the current local time and a random number, denoted as the first session ID, and initialize all session parameters corresponding to the first session ID in the session table to 0; send a redirect response pointing to the time synchronization page to the client; where the redirect response carries the first session ID; when the client receives the redirect response, initiate a time synchronization request to the server, and when the time synchronization request is valid, send a page request to the server again.

[0124] In one implementation, when receiving the redirect response, the client is used to write the first session ID into the session cache information of the client, denoted as the second session ID, and add and initialize to 0 the session parameters corresponding to the second session ID in the session cache information; where the session parameters corresponding to the second session ID include: the second client request time, the second request sequence number, and the second check code; load the time synchronization page to write the current local time of the client into the second client request time, and initiate a time synchronization request to the server; where the time synchronization request carries the session cache information of the client.

[0125] In one implementation, the server is used to read the session cache information to verify whether the time synchronization request is valid. If the time synchronization request is valid, update the session parameters of the client in the session table and send a response message to the client.

[0126] In one implementation, when receiving the response message, the client is used to determine whether the response message is valid. If the response message is valid, update the session cache information in the client and send a page request to the server again.

[0127] In one implementation, the session parameters corresponding to the first session ID in the above session table include: the first client request time, the first request sequence number, the first check code, the server reception time, the time difference queue, the average time difference, and the set of valid sequence numbers; the server is configured to determine that the time synchronization request is valid if both the first check code and the second check code are 0, or if the second request sequence number = the first request sequence number + 2; set the server reception time equal to the current local time of the server, set the first client request time equal to the second client request time, set the first request sequence number equal to the second request sequence number, the first check code = the first request sequence number + 1, insert the server reception time - the first client request time into the time difference queue, set the average time difference equal to the current average value of the time difference queue, and insert the first request sequence number into the set of valid sequence numbers.

[0128] In one implementation, the first check code is carried in the response message; the client is configured to determine that the response message is valid if the first check code = the second request sequence number + 1, set the second client request time equal to the current local time of the client, increment the second request sequence number by 2, and re-initiate a page request to the server.

[0129] In one implementation, the server is configured to, if there is a first session ID in the session table that is equal to the second session ID in the page request, obtain the second client request time corresponding to the second session ID in the page request; determine whether the second client request time satisfies Stime server -Ctime quest <Time_span + W, if so, determine that the client request time verification is qualified, if not, determine that the page request is invalid; where Ctime quest is the second client request time, Stime server is the current local time when the server receives the page request, Time_span is the average time difference, and W is a preset delay threshold.

[0130] In one implementation, the server is configured to determine whether the second request sequence number carried in the page request exists in the set of valid sequence numbers corresponding to the first session ID. If not, determine that the page request has not been processed by the server and determine that the page request is valid.

[0131] In one implementation, the server is configured to, when determining that the page request is valid, update the session parameters corresponding to the first session ID in the session table based on the session cache information of the client carried in the page request.

[0132] For the system provided in this embodiment, its implementation principle and the technical effects produced are the same as those of the foregoing embodiments. For the sake of brief description, for the parts not mentioned in the device embodiment, reference may be made to the corresponding content in the foregoing method embodiment.

[0133] An embodiment of the present invention provides a computer-readable medium, wherein the computer-readable medium stores computer-executable instructions, and when the computer-executable instructions are called and executed by a processor, the computer-executable instructions cause the processor to implement the method described in the above embodiment.

[0134] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working process of the above-described system can refer to the corresponding process in the foregoing embodiment, and will not be described herein again.

[0135] The computer program product of the replay attack defense method and system provided by the embodiment of the present invention includes a computer-readable storage medium storing program code, and the instructions included in the program code can be used to execute the method described in the foregoing method embodiment. For the specific implementation, reference can be made to the method embodiment, and details will not be described herein again.

[0136] In addition, in the description of the embodiments of the present invention, unless otherwise clearly defined and limited, the terms "installation", "connection", and "connection" shall be understood in a broad sense. For example, it may be a fixed connection, a detachable connection, or an integral connection; it may be a mechanical connection or an electrical connection; it may be directly connected or indirectly connected through an intermediate medium, and it may be the communication inside two elements. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific situations.

[0137] If the above functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a 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 causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in various embodiments of the present invention. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program code.

[0138] In the description of the present invention, it should be noted that the orientation or positional relationship indicated by the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. is based on the orientation or positional relationship shown in the drawings. It is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation to the present invention. In addition, the terms "first", "second", and "third" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance.

[0139] Finally, it should be noted that the above-described embodiments are only specific embodiments of the present invention, which are used to illustrate the technical solutions of the present invention, rather than limiting them. The protection scope of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that any person skilled in the art within the technical scope disclosed by the present invention can still modify the technical solutions described in the foregoing embodiments or can easily conceive of changes, or perform equivalent replacements on some of the technical features; and these modifications, changes or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A defense method against replay attacks, characterized in that, it includes: When the server receives a page request sent by the client, it determines whether there is session information of the client in the session table stored by the server; When there is no session information of the client in the session table, new session information of the client is added to the session table, and a time redirection response is sent to the client, so that the client resends a page request to the server after completing the time synchronization process with the server; When the server receives the page request sent by the client again, or when there is session information of the client in the session table, time verification is performed on the client request time carried in the page request; When the client request time verification is qualified, it is determined whether the page request has been processed by the server. If the page request has not been processed by the server, it is determined that the page request is valid, and the request content corresponding to the page request is returned to the client; The step of adding new session information of the client to the session table and sending a time redirection response to the client, so that the client resends a page request to the server after completing the time synchronization process with the server, includes: Generating a session ID of the client based on the current local time of the server and a random number, denoted as the first session ID, and initializing all session parameters corresponding to the first session ID in the session table to 0; Sending a redirection response pointing to a time synchronization page to the client based on the server; wherein, the first session ID is carried in the redirection response; When the client receives the redirection response, writing the first session ID into the session cache information of the client, denoted as the second session ID, and adding and initializing session parameters corresponding to the second session ID to 0 in the session cache information; wherein, the session parameters corresponding to the second session ID include: the second client request time, the second request sequence number, and the second verification code; Based on the client loading the time synchronization page to write the current local time of the client into the second client request time, and initiating a time synchronization request to the server; wherein, the session cache information of the client is carried in the time synchronization request; Based on the server reading the session cache information to verify whether the time synchronization request is valid. If the time synchronization request is valid, updating the session parameters of the client in the session table, and sending a response message to the client; When the client receives the response message, it determines whether the response message is valid. If the response message is valid, updating the session cache information in the client, and resending the page request to the server; The session parameters corresponding to the first session ID in the session table include: the first client request time, the first request sequence number, the first check code, the server reception time, the time difference queue, the average time difference, and the set of valid sequence numbers; the step of verifying whether the time synchronization request is valid based on the server reading the session cache information and updating the session parameters of the client in the session table if the time synchronization request is valid includes: if both the first check code and the second check code are 0, or if the second request sequence number = the first request sequence number + 2, determining that the time synchronization request is valid; making the server reception time equal to the current local time of the server, making the first client request time equal to the second client request time, making the first request sequence number equal to the second request sequence number, the first check code = the first request sequence number + 1, inserting the difference between the server reception time and the first client request time into the time difference queue, making the average time difference equal to the current average value of the time difference queue, and inserting the first request sequence number into the set of valid sequence numbers.

2. The method according to claim 1, wherein, the page request carries the session cache information of the client, and the step of determining whether there is session information of the client in the session table stored by the server includes: determining whether there is a session ID in the session table that is equal to the session ID in the session cache information. If there is, it is determined that there is session information of the client in the session table; if not, it is determined that there is no session information of the client in the session table.

3. The method according to claim 1, wherein, the response message carries the first check code; the step of determining whether the response message is valid and updating the session cache information in the client and sending the page request to the server again if the response message is valid includes: if the first check code = the second request sequence number + 1, determining that the response message is valid, making the second client request time equal to the current local time of the client, incrementing the second request sequence number by 2, and re - sending the page request to the server.

4. The method according to any one of claims 1 - 3, wherein, the step of performing time verification on the request initiation time carried by the page request when the server receives the page request sent by the client again, or when there is session information of the client in the session table includes: if there is a first session ID in the session table that is equal to the second session ID in the page request, obtaining the second client request time corresponding to the second session ID in the page request; determining whether the second client request time satisfies Stime server -Ctime quest <Time_span+W, If so, determine that the client request time is verified to be qualified; if not, determine that the page request is invalid; where Ctime quest is the second client request time, and Stime server is the current local time when the server receives the page request, Time_span is the average time difference, and W is the preset delay threshold.

5. The method according to claim 4, wherein, the step of determining whether the page request has been processed by the server and determining that the page request is valid if the page request has not been processed by the server includes: Based on the server, determine whether the second request sequence number carried in the page request exists in the set of valid sequence numbers corresponding to the first session ID. If not, determine that the page request has not been processed by the server and determine that the page request is valid.

6. The method according to claim 5, wherein, further comprising: When it is determined that the page request is valid, update the session parameters corresponding to the first session ID in the session table based on the session cache information of the client carried in the page request.

7. A defense system against replay attacks, wherein, comprising: A server and a client; The server is configured to, when receiving a page request sent by the client, determine whether the session information of the client exists in the session table stored by the server; The server is further configured to, when the session information of the client does not exist in the session table, add the newly created session information of the client to the session table and send a time redirect response to the client, so that the client resends the page request to the server after completing the time synchronization process with the server; The server is further configured to, when the server receives the page request sent by the client again, or when the session information of the client exists in the session table, perform time verification on the client request time carried in the page request; The server is further configured to, when the client request time verification is qualified, determine whether the page request has been processed by the server. If the page request has not been processed by the server, determine that the page request is valid and return the request content corresponding to the page request to the client; The server is further configured to generate the session ID of the client based on the current local time and a random number, denoted as the first session ID, and initialize all the session parameters corresponding to the first session ID in the session table to 0; The server is further configured to send a redirect response pointing to the time synchronization page to the client; wherein, the first session ID is carried in the redirect response; The client is configured to, when receiving the redirect response, write the first session ID into the session cache information of the client, denoted as the second session ID, and add the session parameters corresponding to the second session ID in the session cache information and initialize them to 0; wherein, the session parameters corresponding to the second session ID include: the second client request time, the second request sequence number, and the second check code; The client is further configured to load the time synchronization page to write the current local time of the client into the second client request time and initiate a time synchronization request to the server; wherein, the session cache information of the client is carried in the time synchronization request; The server is further configured to read the session cache information to verify whether the time synchronization request is valid. If the time synchronization request is valid, update the session parameters of the client in the session table and send a response message to the client. The client is further configured to, when receiving the response message, determine whether the response message is valid. If the response message is valid, update the session cache information in the client and send the page request to the server again; The session parameters corresponding to the first session ID in the session table include: the first client request time, the first request sequence number, the first check code, the server reception time, the time difference queue, the average time difference, and the set of valid sequence numbers. The server is further configured to determine that the time synchronization request is valid if both the first check code and the second check code are 0, or if the second request sequence number = the first request sequence number + 2; set the server reception time equal to the current local time of the server, set the first client request time equal to the second client request time, set the first request sequence number equal to the second request sequence number, set the first check code = the first request sequence number + 1, insert the difference between the server reception time and the first client request time into the time difference queue, set the average time difference equal to the current average value of the time difference queue, and insert the first request sequence number into the set of valid sequence numbers.

Images