Safety verification method and system for http protocol request

Abstract

The embodiment of the invention discloses a security verification method and system for an http protocol request. The method comprises the following steps: a first service carries a request unique id and a timestamp in a request message; after receiving the request message, the second service judges whether the difference between the timestamp and the current time is within the effective range of the timestamp; if the request unique id is within the effective range of the timestamp, the second service judges whether the request unique id exists in a redis cache or not; if yes, judging that the request message is an illegal request; if the request message does not exist, judging that the request message is a legal request, and adding the unique id of the request to a redis cache for verifying the unique id of the request of a subsequent request message; wherein the unique id of each request in the redis cache is deleted after the unique id exceeds the effective range of the timestamp.

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] In the existing technical solution, there is no time validity and anti-replay security verification mechanism in the http request. If a message is intercepted during transmission on the network, the request can be sent to the server at any time to achieve the purpose of destruction. Or after the message is intercepted, a large number of messages are sent to the server at the same time within the legal timestamp, resulting in repeated processing of multiple identical requests, which causes damage to the server.

[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 it 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 request 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 a request unique ID and a 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 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 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 also used to determine 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;

[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 the requests are not repeatable within the valid range of the timestamp, and that repeated messages are directly intercepted and will 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, and the time point is cleverly used 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 when it expires. The expiration time is exactly equal to the valid range of the timestamp. Through the reasonable 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 implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

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

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

[0021] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be described clearly and completely below. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work belong to 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", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are 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, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance.

[0023] In the description of the present invention, it is also necessary to explain that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0024] 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. 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, assuming that 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, which carries two fields: the request unique ID and the timestamp. The message is signed to prevent information 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, the request message is determined to be an illegal request and no response is given; if it has not been tampered with, the second service 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 legitimacy of the timestamp. Optionally, the legitimacy verification of the timestamp requires that the difference between the timestamp in the message and the current time must be within a certain threshold range, and the threshold range is the valid range of the timestamp. Preferably, the threshold range can be 3 minutes, because the reasonable request time for a request will not exceed 3 minutes, and it leaves a margin for slight deviations in the server time.

[0029] Furthermore, the effective 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 effective range of the timestamp applicable to the first service and the second service; or, for a large number of servers and legitimate requests between 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 effective 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 range of the timestamp, it means that the time verification has failed and no response will be 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, continue to verify the request unique ID. If the verification fails, directly return an illegal request. Specifically, the request unique ID verification will be combined with the redis cache to verify whether the ID exists in the cache. If it exists, it will directly return the request as a duplicate request. If it does not exist, it is a new legal request. The request unique ID is stored in redis and the expiration time is set to be exactly the valid range of the timestamp. This will greatly save 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 generate a hash value based on 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 unique request ID can also include the user channel. In subsequent operations, the second service can count the request volume of each user channel through the unique request ID of the legitimate request; and forward the subsequent request messages of different user channels in groups according to the request volume. For example, the docking party information can be directly located through the unique ID code, and dynamic routing forwarding and load distribution can be performed according to the request volume of the docking party, that is, request distribution processing can be performed according to the traffic volume. Large requests are forwarded to a group of servers, and small requests are forwarded to a group of servers by several dockings.

[0037] At the same time, the request unique id can also include the timestamp of sending the request. In the subsequent operation, 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, the request message is judged to be an illegal request; 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 of this request, so that the complete log information of this request can be quickly and accurately filtered out from a large number of logs in the case of high concurrency.

[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 repeated messages are directly intercepted and will 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, and the time point is cleverly used 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 when it expires. The expiration time is exactly equal to the valid range of the timestamp. Through the reasonable 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 the structure of a security verification system for HTTP protocol requests provided by an embodiment of the present invention, such as 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 also used to determine 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;

[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 the 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 two servers where the first service and the second service are located respectively, 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, and 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 aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein by 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 request unique ID and a timestamp in the request message; 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; 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 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 verifying 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; 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 two servers where the first service and the second service are located respectively, 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, characterized in that: 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, characterized in that Before the first service carries the request unique ID and the 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 as the unique request ID of 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 of this request; Correspondingly, after determining that the request message is a legitimate request, it also includes: the second service counts the request volume of each user channel through the unique request ID of the legitimate request, 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 The first service carries a request unique id and a timestamp in a request message, including: 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; 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 determines whether the timestamp in the message is consistent with the timestamp inside the request unique ID; 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 they are inconsistent, determine that the request message is an illegal request.

8. 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 according to the timestamp in the request unique ID.

9. 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 is used to carry the request unique ID and timestamp in the request message; 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; If it is within the valid range of the timestamp, the second service is also used to determine 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; 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.

10. The system 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 system is further configured to perform the following operations: The valid range of the timestamp is determined according to the time difference between two servers where the first service and the second service are located respectively, and the normal request time of the legal request between the first service and the second service.

Images