A security verification method and system for an http protocol request

Abstract

The embodiment of the application discloses a kind of http protocol request security verification method and system. Among them, method includes: first service carries request unique id and time stamp in request message;Second service receives request message, judges whether the difference between the time stamp and current time is within the effective range of time stamp;If within the effective range of time stamp, the second service judges whether the request unique id exists in redis cache;If it exists, it is judged that the request message is illegal request;If it does not exist, it is judged that the request message is legal request, and the request unique id is added to resdis cache, for the request unique id of subsequent request message is verified;Wherein, each request unique id in the resdis cache is deleted after exceeding the effective range of the time stamp.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of network security technology, and in particular to a method and system for security verification of HTTP protocol requests. Background Art

[0002] Existing HTTP requests lack any time validity or anti-replay security verification mechanisms. If a message is intercepted while transmitting over the network, the intercepted message can be re-sent to the server at any time to disrupt the server. Alternatively, intercepted messages can be sent to the server in large quantities within the legal timestamp, causing repeated processing of multiple identical requests and causing server-side corruption.

[0003] Therefore, there are the following problems in the prior art:

[0004] 1) The rationality of the HTTP request time is not verified. The request can still succeed if the time exceeds the legal timestamp range.

[0005] 2) HTTP requests cannot intercept destructive attacks caused by the same request accessing the server multiple times. Summary of the Invention

[0006] The embodiment of the present invention provides a method and system for security verification of HTTP protocol requests to solve the above technical problems.

[0007] In a first aspect, an embodiment of the present invention provides a method for security verification of an HTTP protocol request, comprising:

[0008] The first service carries the request unique ID and timestamp in the request message;

[0009] After receiving the request message, the second service determines whether the difference between the timestamp and the current time is within the valid range of the timestamp;

[0010] If it is within the valid range of the timestamp, the second service determines whether the request unique ID exists in the Redis cache; if so, determines that the request message is an illegal request; if not, determines that the request message is a legal request, and adds the request unique ID to the Redis cache for verification of the request unique ID of subsequent request messages; wherein, each request unique ID in the Redis cache is deleted after exceeding the valid range of the timestamp;

[0011] If the timestamp is not within the valid range, the second service determines that the request message is an illegal request.

[0012] In a second aspect, an embodiment of the present invention provides a security verification system for HTTP protocol requests, comprising: two servers where a first service and a second service are located respectively; wherein,

[0013] The first service is used to carry the request unique ID and timestamp in the request message;

[0014] The second service is used to determine whether the difference between the timestamp and the current time is within the valid range of the timestamp after receiving the request message;

[0015] If it is within the valid range of the timestamp, the second service is further used to determine whether the request unique ID exists in the Redis cache; if so, determine that the request message is an illegal request; if not, determine that the request message is a legal request, and add the request unique ID to the Redis cache for verification of the request unique ID of subsequent request messages; wherein, each request unique ID in the Redis cache is deleted after exceeding the valid range of the timestamp;

[0016] If the timestamp is not within a valid range, the second service is further configured to determine that the request message is an illegal request.

[0017] In summary, this embodiment provides a security verification method for http protocol requests, which intercepts replayed requests to the maximum extent, ensures that requests are not repeated within the valid range of the timestamp, and that duplicate messages are directly intercepted and do not enter the business processing flow, thereby increasing the protection of the database. Among them, the verification of the timestamp protects the authenticity and validity of the request, and after the request unique ID is cleared, the timestamp will also exceed the valid time range, cleverly utilizing the time point to achieve closed-loop protection of the legitimacy of the request. At the same time, the unique request ID is only stored within a certain period of time and is deleted upon expiration. The expiration period is exactly equal to the valid range of the timestamp. Through the rational use of the timestamp, the request unique ID, and time, the memory overhead caused by storing a large number of request unique IDs is greatly reduced, the verification efficiency is improved, and the protection of the database is increased. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0019] Figure 1 This is a flow chart of a method for security verification of HTTP protocol requests provided by an embodiment of the present invention;

[0020] Figure 2 A schematic structural diagram of a security verification system for HTTP protocol requests provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0021] To make the objectives, technical solutions, and advantages of the present invention more clear, the technical solutions of the present invention are described clearly and completely below. Obviously, the embodiments described are only some of the embodiments of the present invention, not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without inventive effort are also within the scope of protection of the present invention.

[0022] In the description of the present invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings and are intended solely to facilitate and simplify the description of the present invention. They are not intended to indicate or imply that the devices or components referred to must have, be constructed, or operate in a specific orientation, and therefore should not be construed as limitations on the present invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0023] In the description of the present invention, it should also be noted that, unless otherwise expressly specified or limited, the terms "mounted," "connected," and "connected" should be understood broadly. For example, they may refer to fixed, detachable, or integral connections; mechanical or electrical connections; direct or indirect connections through an intermediate medium; and internal communication between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on the specific circumstances.

[0024] Figure 1 This is a flow chart of a method for securely verifying HTTP protocol requests provided by an embodiment of the present invention. The method is executed by two services to be communicated, and specifically includes the following steps:

[0025] S110. The first service carries a request unique ID and a timestamp in a request message, signs the request message, and sends it to the second service.

[0026] Specifically, suppose service A needs to access service B. Service A is called the first service, and service B is called the second service. Service A needs to send a request message to service B. The message contains two fields: a unique request ID and a timestamp. The message is signed to prevent tampering. The timestamp represents the time when service A initiated the request.

[0027] S120. After receiving the request message, the second service verifies whether the message has been tampered with through the signature; if it has been tampered with, it determines that the request message is an illegal request and does not respond; if it has not been tampered with, it continues to determine whether the timestamp and the current time are within the valid range of the timestamp.

[0028] The valid range of the timestamp is used to verify the validity of the timestamp. Optionally, timestamp validity verification requires that the difference between the timestamp in the message and the current time must be within a certain threshold range. This threshold range is the valid range of the timestamp. Preferably, the threshold range can be set to 3 minutes, because a reasonable request time will not exceed 3 minutes, and it leaves a margin for slight deviations in the server time.

[0029] Furthermore, the valid range of the timestamp can be set separately for the two services to be communicated. For example, the time difference between the two servers where the first service and the second service are located, and the normal request time of the legitimate request between the first service and the second service are obtained, and the two times are added together to serve as the valid range of the timestamp applicable to the first service and the second service; or for legitimate requests between a large number of servers and different servers, a server time difference and normal request time with universal applicability can be counted, and the two can be added together to serve as the universal valid range of the timestamp.

[0030] S130: If the timestamp is not within a valid range, the second service determines that the request message is an illegal request.

[0031] If the difference between the timestamp in the message and the current time is not within the valid timestamp range, it means that the time verification has failed and no response is given.

[0032] S140. If it is within the valid range of the timestamp, the second service determines whether the request unique ID exists in the redis cache; if it exists, the request message is determined to be an illegal request; if it does not exist, the request message is determined to be a legal request, and the request unique ID is added to the resdis cache for verification of the request unique ID of subsequent request messages; wherein, each request unique ID in the resdis cache is cleared after exceeding the valid range of the timestamp.

[0033] If the time verification passes, the request unique ID is verified. If the verification fails, the request is returned as invalid. Specifically, the request unique ID verification is combined with the Redis cache to verify whether the ID exists in the cache. If it exists, the request is returned as a duplicate request. If it does not exist, it is a new and valid request. The request unique ID is stored in Redis and the expiration time is set to the valid timestamp range. This greatly reduces the pressure on memory.

[0034] When all the above verifications are passed, real business processing will be carried out, otherwise an illegal request will be returned.

[0035] Furthermore, the request unique id can use a hash value generated according to the server machine code and time where the first service is located; or the user's department, personnel ID, date, etc. can be included in the request unique id according to user-customized rules to identify various information required by the user.

[0036] At the same time, the request unique ID can also include the user channel. In subsequent operations, the second service can use the unique request ID of legitimate requests to count the request volume of each user channel; and group and forward subsequent request messages from different user channels according to the request volume. For example, the unique ID code can be used to directly locate the docking party information. Subsequently, dynamic routing and forwarding can be performed based on the docking party's request volume. In other words, request distribution can be performed based on traffic volume. Requests with large volumes are forwarded to a group of servers, while requests with small volumes are forwarded to a group of servers by several docking stations.

[0037] At the same time, the request unique id can also include the timestamp of sending the request. Then, in subsequent operations, after the second service receives the request message, it can first determine whether the timestamp in the message is consistent with the timestamp inside the request unique id; if they are consistent, it can determine whether the difference between the timestamp and the current time is within the valid range of the timestamp; if they are inconsistent, it can determine that the request message is an illegal request; and the security of the request is increased by time consistency verification. In addition, the second service can also perform time dimension statistics based on the timestamp in the request unique id, and can also reuse the request unique id in the log system as the link tracking id for this request. In this way, the complete log information of this request can be quickly and accurately filtered out from a large number of logs under high concurrency conditions.

[0038] In summary, this embodiment provides a security verification method for http protocol requests, which intercepts replayed requests to the maximum extent, ensures that requests cannot be repeated within 3 minutes (within the valid range of the timestamp), and that duplicate messages are directly intercepted and do not enter the business processing flow, thereby increasing the protection of the database. Among them, the verification of the timestamp protects the authenticity and validity of the request, and after the request unique id is cleared, the timestamp will also exceed the valid time range, cleverly utilizing the time point to achieve closed-loop protection of the legitimacy of the request. At the same time, the unique request id is only stored within a certain period of time and is deleted upon expiration. The expiration period is exactly equal to the valid range of the timestamp. Through the rational use of the timestamp, the request unique id, and time, the memory overhead caused by storing a large number of request unique ids is greatly reduced, the verification efficiency is improved, and the protection of the database is increased.

[0039] Figure 2A schematic diagram of a security verification system for HTTP protocol requests provided by an embodiment of the present invention is shown as follows: Figure 2 As shown, the system includes: two servers where the first service and the second service are located respectively; wherein,

[0040] The first service is used to carry the request unique ID and timestamp in the request message;

[0041] The second service is used to determine whether the difference between the timestamp and the current time is within the valid range of the timestamp after receiving the request message;

[0042] If it is within the valid range of the timestamp, the second service is further used to determine whether the request unique ID exists in the Redis cache; if so, determine that the request message is an illegal request; if not, determine that the request message is a legal request, and add the request unique ID to the Redis cache for verification of the request unique ID of subsequent request messages; wherein, each request unique ID in the Redis cache is deleted after exceeding the valid range of the timestamp;

[0043] If the timestamp is not within a valid range, the second service is further configured to determine that the request message is an illegal request.

[0044] Furthermore, before determining whether the difference between the timestamp and the current time is within a valid range of the timestamp, the system is further configured to perform the following operations:

[0045] The valid range of the timestamp is determined according to the time difference between the two servers where the first service and the second service are respectively located, and the normal request time of the legal request between the first service and the second service.

[0046] This embodiment and the above-mentioned method embodiment are based on the same inventive concept. The features of any of the above-mentioned method embodiments are applicable to this embodiment and can achieve the same beneficial effects, which will not be repeated here.

[0047] 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 deviate the essence of the corresponding technical solutions from the technical solutions of the embodiments of the present invention.

Claims

1. A security verification method for HTTP protocol requests, characterized in that: include: The first service carries a timestamp in the request unique ID, and carries the timestamp and the request unique ID again in the request message; After receiving the request message, the second service determines whether the timestamp in the message is consistent with the timestamp inside the request unique id; If they are inconsistent, the request message is determined to be an illegal request; if they are consistent, continue to determine whether the difference between the timestamp and the current time is within the valid range of the timestamp; If the timestamp is within the valid range, the second service determines whether the request unique ID exists in the Redis cache; If it exists, the request message is judged to be an illegal request; if it does not exist, the request message is judged to be a legal request, and the request unique ID is added to the resdis cache for verification of the request unique ID of subsequent request messages; wherein, each request unique ID in the resdis cache is deleted after exceeding the valid range of the timestamp, and the expiration time of the unique request ID in the cache is exactly equal to the valid range of the timestamp; If the timestamp is not within the valid range, the second service determines that the request message is an illegal request.

2. The method according to claim 1, characterized in that Before determining whether the difference between the timestamp and the current time is within the valid range of the timestamp, the method further includes: The valid range of the timestamp is determined according to the time difference between the two servers where the first service and the second service are respectively located, and the normal request time of the legal request between the first service and the second service.

3. The method according to claim 1, characterized in that The valid range of the timestamp is 3 minutes.

4. The method according to claim 1, wherein The first service carries a request unique ID and a timestamp in a request message, including: the first service carries a request unique ID and a timestamp in a request message, and signs the request message before sending it to the second service; Correspondingly, after receiving the request message, the second service determines whether the difference between the timestamp and the current time is within the valid range of the timestamp, including: after receiving the request message, the second service verifies whether the message has been tampered with through the signature; if it has not been tampered with, determines whether the difference between the timestamp and the current time is within the valid range of the timestamp; if it has been tampered with, determines that the request message is an illegal request.

5. The method according to claim 1, wherein Before the first service carries the request unique ID and timestamp in the request message, the method further includes: A hash value is generated according to the server machine code where the first service is located and the request time, and is used as the unique request ID for this request.

6. The method according to claim 1, characterized in that Before the first service carries the request unique ID and timestamp in the request message, the method further includes: merging the user-customized request unique code with the user channel as the unique request ID for this request; Correspondingly, after determining that the request message is a legitimate request, it also includes: the second service uses the unique request ID of the legitimate request to count the request volume of each user channel, and groups and forwards subsequent request messages from different user channels according to the size of the request volume.

7. The method according to claim 1, characterized in that Before the first service carries the request unique id and the timestamp in the request message, the method further includes: the first service carries the timestamp in the request unique id; Correspondingly, after the second service receives the request message, it also includes: the second service reuses the request unique ID in the log system, filters the complete log information of this request, and performs time dimension statistics based on the timestamp in the request unique ID.

8. A security verification system for HTTP protocol requests, characterized in that: include: The first service and the second service are located on two servers respectively; wherein, The first service carries a timestamp in the request unique ID, and carries the timestamp and the request unique ID again in the request message; After receiving the request message, the second service determines whether the timestamp in the message is consistent with the timestamp inside the request unique ID; if they are inconsistent, the request message is determined to be an illegal request; if they are consistent, it continues to determine whether the difference between the timestamp and the current time is within the valid range of the timestamp; If it is within the valid range of the timestamp, the second service is further used to determine whether the request unique ID exists in the Redis cache; if so, determine that the request message is an illegal request; if not, determine that the request message is a legal request, and add the request unique ID to the Redis cache for verification of the request unique ID of subsequent request messages; wherein, each request unique ID in the Redis cache is deleted after exceeding the valid range of the timestamp; If the timestamp is not within a valid range, the second service is further configured to determine that the request message is an illegal request.

9. The system according to claim 8, characterized in that Before determining whether the difference between the timestamp and the current time is within a valid range of the timestamp, the system is further configured to perform the following operations: The valid range of the timestamp is determined according to the time difference between the two servers where the first service and the second service are respectively located, and the normal request time of the legal request between the first service and the second service.

Images