A request verification method and device, electronic equipment and storage medium

Abstract

The present disclosure provides a request verification method and device, electronic equipment and storage medium, and relates to the technical field of network security. The method comprises: obtaining a request sequence to be verified, the request sequence comprising a plurality of requests that are continuous in time; determining API requests and non-API requests from the request sequence according to the uniform resource locators and request headers of the respective messages of the plurality of requests; performing timing verification on the API requests based on timing characteristics, and performing reverse challenge verification on the non-API requests based on the behavior characteristics of the clients that initiate the non-API requests. Compared with the traditional reverse challenge algorithm, the present disclosure can quickly identify API requests before the traffic enters the CC protection module, thereby avoiding normal requests from being misjudged as malicious attacks and ensuring the stability and availability of API interfaces. Not only does this improve user experience and reduce business losses, but it also provides a more flexible and efficient protection means for the field of network security.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of network security, and particularly relates to a request verification method and device, electronic equipment and a storage medium. BACKGROUND

[0002] In the current digital era, network security problems are becoming increasingly serious, and CC (Challenge Collapsar) attacks against Web applications have become an important threat to the normal operation of websites and user experience. CC attacks usually involve hackers using proxy servers or controlled bots to send a large number of HTTP requests to target Web pages, especially those that require frequent database queries.

[0003] To combat CC attacks, traditional defense mechanisms mainly rely on reverse challenge algorithms. Reverse challenge algorithms verify whether requests come from normal browser operations or legitimate users by setting cookies, executing JavaScript code, redirecting requests, and the like. However, with the widespread use of mobile devices and API interfaces, this verification method based on PC browsers is gradually becoming ineffective. API requests have significant differences from traditional Web requests, usually with higher request frequencies and specific content formats, which makes the traditional CC defense algorithm prone to misjudgment when identifying API requests, resulting in normal API requests being mistakenly intercepted and affecting the normal operation of the business. SUMMARY

[0004] Embodiments of the present disclosure provide a request verification method, device, electronic equipment and storage medium, aiming to solve the problems in the background art.

[0005] To solve the above technical problems, the present disclosure is implemented as follows:

[0006] In a first aspect, the embodiments of the present disclosure provide a request verification method, which comprises:

[0007] Obtaining a request sequence to be verified, the request sequence comprising a plurality of requests that are continuous in time;

[0008] Determining API requests and non-API requests from the request sequence according to the uniform resource locators and request headers of the respective messages of the plurality of requests;

[0009] Performing timing verification on the API requests based on timing characteristics, and performing reverse challenge verification on the non-API requests based on behavior characteristics of the clients that initiated the non-API requests.

[0010] Optionally, the timing verification on the API requests based on timing characteristics comprises:

[0011] determining all API requests from the request sequence, and classifying API requests of the same type into a one-to-one first request set;

[0012] performing timing verification on the first request set based on timing characteristics;

[0013] in a case where the first request set passes the timing verification, determining that API requests in the first request set are normal requests;

[0014] in a case where the first request set fails to pass the timing verification, determining that API requests in the first request set are abnormal requests.

[0015] Optionally, the determining API requests and non-API requests from the request sequence according to uniform resource locators and request headers of the plurality of requests respectively comprises:

[0016] parsing the uniform resource locators of the plurality of requests from the messages of the plurality of requests respectively;

[0017] judging whether the uniform resource locators of the plurality of requests respectively match a preset static file type;

[0018] for any request in the plurality of requests, in a case where the uniform resource locator matches the preset static file type, determining that the request is an API request;

[0019] in a case where the uniform resource locator does not match the preset static file type, parsing a request header from the message of the request; judging whether the request header matches a preset request body format; in a case where the request header matches the preset request body format, determining that the request is an API request; in a case where the request header does not match the preset request body format, determining that the request is a non-API request.

[0020] Optionally, the performing reverse challenge verification on the non-API requests based on behavior characteristics of clients initiating the non-API requests comprises:

[0021] determining all non-API requests from the request sequence, and classifying non-API requests of the same type into a one-to-one second request set;

[0022] performing reverse challenge verification on the second request set based on the behavior characteristics of the clients;

[0023] in a case where the second request set passes the reverse challenge verification, determining that non-API requests in the second request set are normal requests;

[0024] In a case where the second request set fails to pass the reverse challenge verification, determining that a non-API request in the second request set is an abnormal request.

[0025] Optionally, the timing verification on the first request set based on the timing feature comprises:

[0026] Obtaining a timestamp of each API request in the first request set;

[0027] Calculating a standard deviation for representing a dispersion degree between the API requests according to the timestamp of each API request;

[0028] Comparing the standard deviation with a preset threshold;

[0029] In a case where the standard deviation exceeds the threshold, determining that the first request set is a normal request; and in a case where the standard deviation does not exceed the threshold, determining that the first request set is an abnormal request.

[0030] Optionally, the calculating a standard deviation for representing a dispersion degree between the API requests according to the timestamp of each API request comprises:

[0031] Obtaining a timestamp of each API request in the first request set;

[0032] Determining a plurality of time difference values between each adjacent API request in the first request set according to the timestamp of each API request, and determining an average value of the plurality of time difference values;

[0033] Calculating a standard deviation for representing a dispersion degree between the API requests according to the plurality of time difference values and the average value of the time difference values.

[0034] Optionally, after the determining a plurality of time difference values between each adjacent API request in the first request set according to the timestamp of each API request, the method further comprises:

[0035] Performing smoothing processing on the plurality of time difference values between each adjacent API request in the first request set;

[0036] Performing zero and processing on the last two digits of each of the plurality of time difference values after the smoothing processing.

[0037] In a second aspect, an embodiment of the present disclosure provides a request verification device, and the device comprises:

[0038] An obtaining module, configured to obtain a request sequence to be verified, the request sequence comprising a plurality of requests that are continuous in time;

[0039] determining, from the request sequence, API requests and non-API requests according to uniform resource locators and request headers of respective messages of the plurality of requests;

[0040] verifying, based on a timing feature, the API requests, and verifying, based on a behavior feature of a client that initiates the non-API requests, the non-API requests.

[0041] Optionally, the verifying module comprises:

[0042] a first determining submodule configured to determine all API requests from the request sequence, and classify API requests of a same type into a corresponding first request set;

[0043] a timing verifying submodule configured to verify, based on a timing feature, the first request set;

[0044] a second determining submodule configured to determine, in a case where the first request set passes the timing verification, that the API requests in the first request set are normal requests;

[0045] a third determining submodule configured to determine, in a case where the first request set fails the timing verification, that the API requests in the first request set are abnormal requests.

[0046] Optionally, the determining module comprises:

[0047] a parsing submodule configured to parse, from respective messages of the plurality of requests, uniform resource locators of the plurality of requests;

[0048] a first judging submodule configured to judge whether the uniform resource locators of the plurality of requests match a preset static file type;

[0049] a fourth determining submodule configured to determine, for any request of the plurality of requests, in a case where the uniform resource locators match the preset static file type, that the request is an API request;

[0050] a second judging submodule configured to, in a case where the uniform resource locators do not match the preset static file type, parse a request header from a message of the request; judge whether the request header matches a preset request body format; in a case where the request header matches the preset request body format, determine that the request is an API request; and in a case where the request header does not match the preset request body format, determine that the request is a non-API request.

[0051] Optionally, the verifying module comprises:

[0052] a fifth determining sub-module, configured to determine all non-API requests from the request sequence, and classify non-API requests of the same type into a second request set corresponding one-to-one;

[0053] a reverse challenge verification sub-module, configured to perform reverse challenge verification on the second request set based on the behavior characteristics of the client;

[0054] a sixth determining sub-module, configured to determine that the non-API requests in the second request set are normal requests in a case where the second request set passes the reverse challenge verification;

[0055] a seventh determining sub-module, configured to determine that the non-API requests in the second request set are abnormal requests in a case where the second request set fails to pass the reverse challenge verification.

[0056] Optionally, the timing verification sub-module comprises:

[0057] an obtaining unit, configured to obtain a respective time stamp of each API request in the first request set;

[0058] a calculating unit, configured to calculate a standard deviation representing a dispersion degree between the API requests according to the respective time stamp of each API request;

[0059] a comparing unit, configured to compare the standard deviation with a preset threshold value;

[0060] a determining unit, configured to determine that the first request set is a normal request in a case where the standard deviation exceeds the threshold value, and determine that the first request set is an abnormal request in a case where the standard deviation does not exceed the threshold value.

[0061] Optionally, the calculating unit comprises:

[0062] an obtaining sub-unit, configured to obtain a respective time stamp of each API request in the first request set;

[0063] a determining sub-unit, configured to determine a plurality of time difference values between each pair of adjacent API requests in the first request set according to the respective time stamp of each API request, and determine an average value of the plurality of time difference values;

[0064] a calculating sub-unit, configured to calculate a standard deviation representing a dispersion degree between the API requests according to the plurality of time difference values and the average value of the time difference values.

[0065] Optionally, the apparatus further comprises:

[0066] a smoothing processing module, configured to smooth a plurality of time difference values between adjacent API requests in time in the first request set;

[0067] a zero-sum processing module, configured to perform zero-sum processing on the last two digits of each of the plurality of time difference values after smoothing.

[0068] In a third aspect, an electronic device is provided, comprising: a processor, a memory, and

[0069] a computer program stored on the memory and capable of running on the processor, the computer program being executed by the processor to implement the steps of the request verification method.

[0070] In a fourth aspect, a computer readable storage medium is provided, the computer readable storage medium storing a computer program, the computer program being executed by a processor to implement the steps of the request verification method.

[0071] The technical solutions provided by the embodiments of the present disclosure at least bring the following beneficial effects:

[0072] The present disclosure effectively reduces the false interception rate of CC defense algorithms on API requests based on API request feature recognition, significantly improving the accuracy and efficiency of network security protection. Compared with traditional reverse challenge algorithms, the present disclosure can quickly identify API requests before the traffic enters the CC protection module, thereby avoiding normal requests from being misjudged as malicious attacks, ensuring the stability and availability of API interfaces. In addition, the verification method based on timing characteristics can accurately evaluate the regularity of client request behavior and timely identify potential attack behavior, enhancing the defense capability of the system. Not only does it improve user experience and reduce business loss, but it also provides more flexible and efficient protection means for the network security field. BRIEF DESCRIPTION OF DRAWINGS

[0073] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, a brief introduction of the drawings needed to be used in the embodiments or prior art description will be given below. Obviously, the drawings in the following description are only some embodiments of the present disclosure, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0074] Figure 1 is a reverse challenge schematic diagram based on a CC defense algorithm in related art;

[0075] Figure 2 is a step schematic diagram of a request verification method provided by an embodiment of the present disclosure;

[0076] Figure 3is a general flowchart of a request verification method provided by an embodiment of the present disclosure;

[0077] Figure 4 is a timing verification flowchart based on timing characteristics in an embodiment of the present disclosure;

[0078] Figure 5 is a structural block diagram of a request verification device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0079] The technical solutions in the embodiments of the present disclosure will be described clearly and completely below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, rather than all the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of the present disclosure.

[0080] Figure 1 is a reverse challenge schematic diagram based on a CC defense algorithm in the related art, please refer to Figure 1 , the client (such as the user's browser or application) sends an HTTP request to the target server, requesting to access specific resources or services. At this time, the client's request may be a normal user request, or it may be a malicious attack request. The protection module initiates a reverse challenge after receiving the request in order to judge the legitimacy of the request. Commonly includes setting cookies, responding to JavaScript code or performing 302 / 307 redirection and other methods. The protection module tries to verify whether the client is a normal user through these challenge methods. For example, the protection module may require the client to execute specific JavaScript code and carry the correct cookie value in the next request. The client will respond according to the challenge content after receiving the challenge of the protection module. If the challenge is successful, the client will carry the correct cookie or execute the corresponding JavaScript code, and will initiate a request to the protection module again. After verifying the effectiveness of the client's response, the protection module confirms that the request is legitimate and forwards it to the target server for processing. At this time, the target server can normally process the request from the client and return the corresponding result. The related art is mainly designed for traditional PC browser requests and cannot effectively handle API interface requests. API requests are usually initiated directly by programs and do not have the behavior characteristics of browsers, resulting in the failure of the reverse challenge algorithm, and normal API requests may be mistakenly intercepted. The process of reverse challenge may cause the user experience to decline, especially in mobile or application scenarios, the user may need to wait for multiple requests to complete the operation, which increases the delay and complexity. It can be seen that the related art has obvious defects in dealing with API requests and improving user experience, and needs to be improved to adapt to the increasingly complex network security environment.

[0081] Figure 2 is a step schematic diagram of a request verification method provided by one embodiment of the present disclosure, as shown in the figure, the method comprises: Figure 2

[0082] Step S101, obtaining a request sequence to be verified, the request sequence comprising a plurality of requests continuous in time.

[0083] The request sequence refers to a plurality of HTTP requests from the same client (such as the same IP address or user agent), which are continuous in time. Specifically, the request sequence contains a series of requests sent in time sequence, each request having a timestamp indicating the specific time of sending.

[0084] Step S102, determining API requests and non-API requests from the request sequence according to the uniform resource locators and request headers of the respective messages of the plurality of requests.

[0085] In order to identify which requests are API requests that need to be monitored and verified, and to provide a basis for subsequent timing feature analysis and attack detection, this step aims to determine the request type of each of the plurality of requests. The step S102 specifically comprises steps S1021-S1024:

[0086] Step S1021, parsing the uniform resource locators of the plurality of requests from the respective messages of the plurality of requests.

[0087] In processing the request sequence, the complete request message is first extracted from each request. The first line of the request message is the request line, and by parsing the request line, the uniform resource locator URL can be extracted. For example, for a typical request GET / images / logo.png HTTP / 1.1, the uniform resource locator is / images / logo.png. For different HTTP request methods (such as GET, POST, etc.), the structure of the request line remains the same, so the way to extract the URL is the same. No matter what the request method is, the process of parsing the request line is similar.

[0088] Step S1022, judging whether the uniform resource locators of the plurality of requests match the preset static file type.

[0089] ​The present disclosure predefines a set of static file types, including various file extensions, such as.css,.js,.jpg,.png,.pdf, and the like. These file types refer to static resources, such as style sheets, scripts, pictures, and documents, and the like. For each URL, its file extension will be extracted. The file extension is the part after the last dot (.) in the URL. The extracted file extension is matched with the preset static file types. Specifically, it is checked whether the extracted extension is in the preset static file type list.

[0090] In step S1023, for any request in the plurality of requests, if the uniform resource locator matches the preset static file type, it is determined that the request is an API request.

[0091] For each request in which the uniform resource locator matches the preset static file type determined in step S1022, the request header part in the request message is parsed, and the request header field and its corresponding value are extracted. For example, for the following message:

[0092] GET / images / logo.png HTTP / 1.1

[0093] Host: example.com

[0094] User-Agent: Mozilla / 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 58.0.3029.110 Safari / 537.3

[0095] Accept: image / webp, image / apng, image / *, * / *; q=0.8

[0096] Host: example.com

[0097] User-Agent: Mozilla / 5.0...

[0098] Accept: image / webp, image / apng,... Figure 3 is a general flowchart of a request verification method provided by an embodiment of the present disclosure, as shown in Figure 3As shown, the request with the uniform resource symbol matching the preset static file type is determined as an API request, and the matching successful request is a static request, which is equivalent to filtering the static file URL. The non-static request which is not matched is further determined in step S1024.

[0099] In step S1024, the request header is parsed from the message of the request in the case that the uniform resource locator does not match the preset static file type; it is judged whether the request header matches the preset request body format; in the case that the request header matches the preset request body format, it is determined that the request is an API request; in the case that the request header does not match the preset request body format, it is determined that the request is a non-API request.

[0100] The set of request body formats predefined by the present disclosure is associated with the Content-Type field in the request header. For example, application / x-www-form-urlencoded indicates that the request body is in the form of form data. Please refer to Figure 3 The non-static request whose URL does not match the static file type in step S1023 is further judged, and the Content-Type extracted from the non-static request is matched with the preset request body format.

[0101] For example, it is assumed that the request header is as follows:

[0102] POST / api / v1 / users HTTP / 1.1

[0103] Host: example.com

[0104] Content-Type: application / json;The Content-Type field is extracted to obtain application / json. It is checked whether application / json is in the preset request body format list (assuming that the preset format includes application / json, application / x-www-form-urlencoded, and multipart / form-data). Since application / json matches the preset format, it is determined that the request is an API request. On the contrary, for a non-static request, the request does not match the static file type nor the preset request body format of the request header, and it is determined that the request is a non-API request.

[0105] In step S103, the API request is time sequence verified based on the time sequence characteristics, and the non-API request is reverse challenge verified based on the behavior characteristics of the client initiating the non-API request.

[0106] The core idea of the present disclosure is to take different processing methods for API requests and non-API requests. For API requests, a timing feature-based verification method is adopted, where the timing feature refers to the time interval and frequency of the request, and other behavior patterns. The requests of normal users have certain randomness, while the requests of attackers often show regularity and high frequency. By analyzing the time interval and frequency of the request, potential automated attacks (such as CC attacks) can be identified, and the risk of false interception can be reduced. In contrast, non-API requests are processed based on the behavior characteristics of the client (such as request frequency, request pattern, request source, etc.) through a reverse challenge mechanism to verify the true identity of the client and prevent malicious users from using normal requests to attack.

[0107] The present disclosure effectively reduces the false interception rate of CC defense algorithms for API requests based on API request feature recognition, significantly improving the accuracy and efficiency of network security protection. Compared with traditional reverse challenge algorithms, the present disclosure can quickly identify API requests before the traffic enters the CC protection module, thereby avoiding normal requests from being misjudged as malicious attacks, ensuring the stability and availability of API interfaces. In addition, the timing feature-based verification method can accurately assess the regularity of client request behavior, identify potential attack behavior in a timely manner, and enhance the defense capability of the system. Not only does it improve user experience and reduce business losses, but it also provides more flexible and efficient protection means for the field of network security.

[0108] In an optional implementation, the timing feature-based timing verification of the API request comprises: determining all API requests from the request sequence, and classifying API requests of the same type into a one-to-one first request set; performing timing verification on the first request set based on timing features; in the case where the first request set passes the timing verification, determining that the API requests in the first request set are normal requests; and in the case where the first request set does not pass the timing verification, determining that the API requests in the first request set are abnormal requests.

[0109] All identified API requests are classified according to request types, specifically, classified according to the uniform resource locators (URLs) of the respective API requests, for example, all requests starting with / api / users can be classified as "user-related API requests", and all requests starting with / api / products can be classified as "product-related API requests". The classified API request set corresponds to a first request set, and at least one first request set is obtained. The first request set is subjected to timing verification based on timing characteristics. It can be understood that the timing verification is performed on API requests with the same URL. API requests with the same URL represent the same operation or resource access. These API requests are consistent in function, so their request patterns and behavior characteristics are similar. Timing verification is only performed on API requests with the same URL, which more accurately identifies the regularity and abnormality of the requests.

[0110] For any set in the at least one first request set, if the timing characteristics of the first request set pass the preset verification standard (for example, the standard deviation is within a certain range), the API requests in the set are determined to be normal requests. That is, the behavior patterns of these requests conform to the operation habits of normal users, and these requests can be safely processed. If the first request set fails to pass the timing verification (for example, the standard deviation exceeds the set threshold), the API requests in the set are marked as abnormal requests. These requests may be initiated by scripts or automated tools, and there is a potential attack risk.

[0111] Through the above steps, the timing characteristic-based verification method can effectively distinguish between normal API requests and potential abnormal requests, reducing the possibility of false interception and ensuring that normal user requests can be processed smoothly.

[0112] In an optional implementation, the reverse challenge verification of the non-API request based on the behavior characteristics of the client initiating the non-API request includes: determining all non-API requests from the request sequence, and classifying non-API requests of the same type into a second request set corresponding to each other; performing reverse challenge verification on the second request set based on the behavior characteristics of the client; in the case where the second request set passes the reverse challenge verification, determining the non-API requests in the second request set to be normal requests; in the case where the second request set fails to pass the reverse challenge verification, determining the non-API requests in the second request set to be abnormal requests.

[0113] All the identified non-API requests are classified according to the request type, and the classification method is the same as the method of classifying API requests described above, which will not be repeated here. At least one second request set is obtained, and all related non-API requests are separated from the API requests for subsequent reverse challenge verification. The second request set is subjected to reverse challenge verification, and it can also be understood that the embodiments of the present disclosure are subjected to reverse challenge verification on non-API requests with the same URL. Specifically, it is verified whether the client has the behavior characteristics of a normal user.

[0114] For any of the at least one second request set, if the requests of the second request set pass the preset reverse challenge verification (for example, the client successfully carries the correct cookie, executes the JavaScript code, or successfully performs the redirection), the non-API requests in the second request set are determined as normal requests, that is, the initiators of these requests are identified as legitimate users, and these requests can be normally processed. If the second request set fails to pass the reverse challenge verification (for example, the client fails to correctly carry the cookie, fails to execute the JavaScript code, or fails to successfully redirect), the non-API requests in the second request set are marked as abnormal requests, indicating that these non-API requests may be initiated by a malicious user or an automated tool, and there is a potential attack risk.

[0115] Through the above steps, the reverse challenge verification method based on the behavior characteristics of the client can effectively distinguish between normal non-API requests and potential abnormal requests, effectively prevent malicious attacks, and ensure that the requests of normal users can be smoothly processed.

[0116] In an optional implementation, the timing verification of the first request set based on the timing characteristics comprises:

[0117] In step S201, the time stamp of each API request in the first request set is obtained.

[0118] Figure 4 is a timing verification flowchart based on timing characteristics in the embodiments of the present disclosure, please refer to Figure 4 The time stamp of each API request is extracted from the first request set. It is assumed that the following API requests and their corresponding time stamps (in milliseconds) are as follows:

[0119] Request 1: 1000 milliseconds; Request 2: 1020 milliseconds; Request 3: 1050 milliseconds; Request 4: 1075 milliseconds; Request 5: 1100 milliseconds.

[0120] Step S202, according to the respective timestamps of the API requests, a standard deviation is calculated to represent the dispersion degree between the API requests.

[0121] Specifically, step S202 includes steps S2021-S2023:

[0122] Step S2021, the respective timestamps of the API requests in the first request set are obtained.

[0123] Step S2022, according to the respective timestamps of the API requests, a plurality of time difference values between each adjacent API request in time in the first request set are determined, and an average value of the plurality of time difference values is determined.

[0124] Returning to the foregoing example, according to the respective timestamps of the API requests, the time difference (i.e., the difference value of the timestamps) between adjacent requests is calculated. It can be obtained that: request 2-request 1: 1020-1000=20 milliseconds; request 3-request 2: 1050-1020=30 milliseconds; request 4-request 3: 1075-1050=25 milliseconds; request 5-request 4: 1100-1075=25 milliseconds.

[0125] The sequence of the obtained time difference values is: 20 milliseconds, 30 milliseconds, 25 milliseconds, 25 milliseconds. According to the sequence of the time difference values, an average value of the time difference values is calculated:

[0126]

[0127] In the formula, is the average value of the time difference values.

[0128] Step S2023, according to the plurality of time difference values and the average value of the time difference values, a standard deviation is calculated to represent the dispersion degree between the API requests.

[0129] According to the obtained , the standard deviation representing the dispersion degree between the API requests is calculated according to the following formula

[0130] In the formula, N is the number of time differences, is each time difference value, is the average value of the time difference values, N is the number of time difference values. It can be obtained that the variance in the standard deviation in the above formula is:

[0131] The standard deviation is calculated as: ≈3.54.

[0132] Step S203, comparing the standard deviation with a preset threshold value.

[0133] Suppose the preset threshold value is 5 milliseconds, the calculated standard deviation (about 3.54 milliseconds) is compared with the preset threshold value (5 milliseconds).

[0134] Step S204, in the case that the standard deviation exceeds the threshold value, determining that the first request set is a normal request; in the case that the standard deviation does not exceed the threshold value, determining that the first request set is an abnormal request.

[0135] Since 3.54 milliseconds is less than 5 milliseconds, according to the rule, it is determined that the first request set is a normal request. On the contrary, if the preset threshold value is 2 milliseconds, it is determined that the first request set is an abnormal request.

[0136] The timing verification method based on timing characteristics proposed by the present disclosure can effectively identify the behavior pattern of normal users for API interface type requests, helping to prevent potential malicious attacks.

[0137] In an alternative embodiment, after determining the plurality of time difference values between each time adjacent API requests in the first request set according to the respective time stamps of the respective API requests, the method further comprises:

[0138] Step S301, performing smoothing processing on the plurality of time difference values between each time adjacent API requests in the first request set.

[0139] Please refer to Figure 4 In step S201, suppose the sequence of time difference values between adjacent API requests has been calculated as: 20 milliseconds, 30 milliseconds, 25 milliseconds, 25 milliseconds. The purpose of smoothing processing is to reduce random fluctuations in time difference values, and methods such as moving average or weighted average can be used, here a simple moving average method can be used for smoothing processing. For each time difference value, take the average of its adjacent values. For the boundary values (the first and the last), you can simply use its own value or only consider one adjacent value.

[0140] For the first time difference value (20 milliseconds), only itself can be considered, and the smoothed value is 20 milliseconds.

[0141] For the second time difference value (30 milliseconds), calculate (20 + 30 + 25) / 3 = 25 milliseconds.

[0142] For the third time difference value (25 milliseconds), calculate (30 + 25 + 25) / 3 = 26.67 milliseconds (rounded to 27 milliseconds).

[0143] For the fourth time difference value (25 ms), only itself can be considered, and the smoothing value is 25 ms.

[0144] The obtained smoothed time difference value sequence is: 20 ms, 25 ms, 27 ms, 25 ms.

[0145] In step S302, the last two digits of each smoothed time difference value are zero processed.

[0146] The zero processing is to process the last two digits of the smoothed time difference value to reduce the interference of network factors. The specific method is to zero process the last two digits of each time difference value. For each smoothing value, the last two digits are taken for zero processing, that is, the value is divided by 100 and then multiplied by 100.

[0147] 20 ms: 20 / 100 = 0, 0*100 = 0 ms;

[0148] 25 ms: 25 / 100 = 0, 0*100 = 0 ms;

[0149] 27 ms: 27 / 100 = 0, 0*100 = 0 ms;

[0150] 25 ms: 25 / 100 = 0, 0*100 = 0 ms; The obtained zero processed time difference value sequence is: 0 ms, 0 ms, 0 ms, 0 ms. The zero processed time difference value sequence will be used as the plurality of time difference values in step S202 for calculation.

[0151] Through the above steps, the time difference values between adjacent API requests in the first request set are smoothed and zero processed. The smoothing processing reduces the fluctuation of the time difference values, and the zero processing further normalizes the time difference values, helps the subsequent standard deviation calculation and abnormal request identification, can improve the identification accuracy of normal request behavior, and reduces the risk of misjudgment.

[0152] Figure 5 is a structural block diagram of a request verification device provided by an embodiment of the present disclosure, as shown in Figure 5 The device comprises:

[0153] The acquisition module 401 is configured to acquire a request sequence to be verified, wherein the request sequence comprises a plurality of requests that are continuous in time.

[0154] The determination module 402 is configured to determine API requests and non-API requests from the request sequence according to uniform resource locators and request headers of respective messages of the plurality of requests.

[0155] The verification module 403 is configured to perform timing verification on the API request based on timing features, and perform reverse challenge verification on the non-API request based on behavior features of a client initiating the non-API request.

[0156] In an optional embodiment, the verification module comprises:

[0157] The first determination sub-module is configured to determine all API requests from the request sequence, and classify API requests of the same type into a corresponding first request set;

[0158] The timing verification sub-module is configured to perform timing verification on the first request set based on timing features;

[0159] The second determination sub-module is configured to determine that the API request in the first request set is a normal request when the first request set passes the timing verification;

[0160] The third determination sub-module is configured to determine that the API request in the first request set is an abnormal request when the first request set fails to pass the timing verification.

[0161] In an optional embodiment, the determination module comprises:

[0162] The parsing sub-module is configured to parse a uniform resource locator of each of the plurality of requests from a message of each of the plurality of requests;

[0163] The first judgment sub-module is configured to judge whether the uniform resource locator of each of the plurality of requests matches a preset static file type;

[0164] The fourth determination sub-module is configured to determine that any request in the plurality of requests is an API request when the uniform resource locator matches the preset static file type.

[0165] The second judgment sub-module is configured to parse a request header from the message of the request when the uniform resource locator does not match the preset static file type, judge whether the request header matches a preset request body format, determine that the request is an API request when the request header matches the preset request body format, and determine that the request is a non-API request when the request header does not match the preset request body format.

[0166] In an optional embodiment, the verification module comprises:

[0167] a fifth determining sub-module, configured to determine all non-API requests from the request sequence, and classify non-API requests of the same type into a second request set corresponding one-to-one;

[0168] a reverse challenge verification sub-module, configured to perform reverse challenge verification on the second request set based on the behavior characteristics of the client;

[0169] a sixth determining sub-module, configured to determine that the non-API requests in the second request set are normal requests in a case where the second request set passes the reverse challenge verification;

[0170] a seventh determining sub-module, configured to determine that the non-API requests in the second request set are abnormal requests in a case where the second request set fails to pass the reverse challenge verification.

[0171] In an optional implementation, the timing verification sub-module includes:

[0172] an obtaining unit, configured to obtain a respective time stamp of each API request in the first request set;

[0173] a calculating unit, configured to calculate a standard deviation representing a dispersion degree between the API requests according to the respective time stamp of each API request;

[0174] a comparing unit, configured to compare the standard deviation with a preset threshold value;

[0175] a determining unit, configured to determine that the first request set is a normal request in a case where the standard deviation exceeds the threshold value, and determine that the first request set is an abnormal request in a case where the standard deviation does not exceed the threshold value.

[0176] In an optional implementation, the calculating unit includes:

[0177] an obtaining sub-unit, configured to obtain a respective time stamp of each API request in the first request set;

[0178] a determining sub-unit, configured to determine a plurality of time difference values between adjacent API requests in time in the first request set according to the respective time stamp of each API request, and determine an average value of the plurality of time difference values;

[0179] a calculating sub-unit, configured to calculate a standard deviation representing a dispersion degree between the API requests according to the plurality of time difference values and the average value of the time difference values.

[0180] In an optional implementation, the apparatus further includes:

[0181] a smoothing processing module, configured to smooth a plurality of time difference values between adjacent API requests in time in the first request set;

[0182] a zero processing module, configured to perform zero processing on last two digits of each of the plurality of time difference values after the smoothing processing.

[0183] The embodiments of the present disclosure further provide an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, the processes of the above-described request verification method embodiments are implemented, and the same technical effects are achieved. To avoid repetition, details are not described herein.

[0184] The embodiments of the present disclosure further provide a computer readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the processes of the above-described request verification method embodiments are implemented, and the same technical effects are achieved. To avoid repetition, details are not described herein. Each of the embodiments in the present disclosure is described in a progressive manner, and each embodiment mainly describes the differences from other embodiments. The same or similar parts of each embodiment can be referred to each other.

[0185] Those skilled in the art should understand that the embodiments of the present disclosure can be provided as methods, apparatuses, electronic devices, and storage media. Therefore, the embodiments of the present disclosure can be in the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Moreover, the embodiments of the present disclosure can be in the form of a computer program product implemented on one or more computer readable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage, etc.) containing computer usable program code.

[0186] The embodiments of the present disclosure are described with reference to the flowcharts and / or block diagrams according to the methods and apparatuses of the embodiments of the present disclosure. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks, can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminals to produce a machine, so that the instructions executed by the computer or other programmable data processing terminals produce a device that implements the functions described in the flowcharts and / or block diagrams. Figure 1 one flow or multiple flows and / or blocks Figure 1apparatuses that carry out functions specified in one or more of the blocks. Such computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 one or more of the processes and / or blocks Figure 1 one or more of the blocks. Such computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the block or blocks. Figure 1 one or more of the processes and / or blocks Figure 1 one or more of the blocks. Such computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the block or blocks.

[0187] While preferred embodiments of the present disclosure have been described, additional variations and modifications can be made to these embodiments by those skilled in the art once they learn of the basic inventive concepts disclosed. Therefore, the appended claims are intended to cover all such variations and modifications as fall within the scope of the present disclosure.

[0188] Finally, it is also important to note that the use of relational terms such as first and second, and the like, are used solely to distinguish one from another entity or action, without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element. The terms "comprising", "comprise", "comprised", and "comprises" and the like in the above specification are used to specify the presence of stated features, integers, steps or components but do not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. The above description of the present disclosure has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the present disclosure to the precise form described, and many modifications, variations, and alterations are possible in light of the above teachings. It is intended that the scope of the present disclosure be limited not by this detailed description, but rather by the claims of the application.

Claims

1. A request verification method, characterized by, The method comprises: obtaining a request sequence to be verified, the request sequence comprising a plurality of requests that are continuous in time; determining API requests and non-API requests from the request sequence according to uniform resource locators and request headers of respective messages of the plurality of requests; performing timing verification on the API requests based on timing characteristics, and performing reverse challenge verification on the non-API requests based on behavior characteristics of clients that initiate the non-API requests; the timing verification on the API requests based on timing characteristics comprises: determining all API requests from the request sequence, and classifying API requests of the same type into a corresponding first request set; performing timing verification on the first request set based on timing characteristics; in a case where the first request set passes the timing verification, determining that the API requests in the first request set are normal requests; in a case where the first request set does not pass the timing verification, determining that the API requests in the first request set are abnormal requests; the timing verification on the first request set based on timing characteristics comprises: obtaining respective time stamps of the API requests in the first request set; calculating a standard deviation representing a dispersion degree between the API requests according to the respective time stamps of the API requests; comparing the standard deviation with a preset threshold; in a case where the standard deviation exceeds the threshold, determining that the first request set is a normal request; and in a case where the standard deviation does not exceed the threshold, determining that the first request set is an abnormal request; the calculation of the standard deviation representing the dispersion degree between the API requests according to the respective time stamps of the API requests comprises: obtaining respective time stamps of the API requests in the first request set; determining a plurality of time difference values between respective adjacent API requests in the first request set and an average value of the plurality of time difference values according to the respective time stamps of the API requests; calculating the standard deviation representing the dispersion degree between the API requests according to the plurality of time difference values and the average value of the time difference values.

2. The method of claim 1, wherein, the determination of the API requests and the non-API requests from the request sequence according to the uniform resource locators and the request headers of respective messages of the plurality of requests comprises: parsing the uniform resource locators of the plurality of requests from respective messages of the plurality of requests; determining whether the uniform resource locators of the plurality of requests match a preset static file type; for any request in the plurality of requests, in a case where the uniform resource locator matches the preset static file type, determining that the request is an API request; In a case where the uniform resource locator does not match the preset static file type, a request header is parsed from the message of the request; it is judged whether the request header matches a preset request body format; in a case where the request header matches the preset request body format, it is determined that the request is an API request; in a case where the request header does not match the preset request body format, it is determined that the request is a non-API request.

3. The method of claim 1, wherein, The reverse challenge verification on the non-API request based on the behavior characteristics of the client initiating the non-API request comprises: All non-API requests in the request sequence are determined, and non-API requests of the same type are classified into a corresponding second request set; The reverse challenge verification is performed on the second request set based on the behavior characteristics of the client; In a case where the second request set passes the reverse challenge verification, the non-API requests in the second request set are determined to be normal requests; In a case where the second request set does not pass the reverse challenge verification, the non-API requests in the second request set are determined to be abnormal requests.

4. The method of claim 1, wherein, After determining the time difference values between adjacent API requests in the first request set according to the time stamps of the respective API requests, the method further comprises: The time difference values between adjacent API requests in the first request set are smoothed; The last two digits of the smoothed time difference values are processed by zero and one.

5. A request verification apparatus characterized by comprising: The device comprises: An acquisition module is configured to acquire a request sequence to be verified, the request sequence comprising a plurality of requests in time sequence; A determination module is configured to determine API requests and non-API requests from the request sequence according to the uniform resource locators and request headers of the respective messages of the plurality of requests; A verification module is configured to perform timing verification on the API requests based on timing characteristics, and perform reverse challenge verification on the non-API requests based on the behavior characteristics of the client initiating the non-API requests; The verification module comprises: A first determination submodule is configured to determine all API requests from the request sequence, and classify API requests of the same type into a corresponding first request set; A timing verification submodule is configured to perform timing verification on the first request set based on timing characteristics; A second determination submodule is configured to determine the API requests in the first request set to be normal requests in a case where the first request set passes the timing verification; A third determination submodule is configured to determine the API requests in the first request set to be abnormal requests in a case where the first request set does not pass the timing verification; The timing verification submodule comprises: An acquisition unit is configured to acquire the time stamps of the respective API requests in the first request set; A calculation unit is configured to calculate a standard deviation representing the dispersion degree between the API requests according to the time stamps of the respective API requests; A comparison unit is configured to compare the standard deviation with a preset threshold. The determining unit is configured to determine that the first request set is a normal request if the standard deviation exceeds the threshold value, and determine that the first request set is an abnormal request if the standard deviation does not exceed the threshold value. The computing unit comprises: The obtaining sub-unit is configured to obtain a respective time stamp of each API request in the first request set; The determining sub-unit is configured to determine a plurality of time difference values between each pair of adjacent API requests in the first request set according to the respective time stamp of each API request, and determine an average value of the plurality of time difference values; The computing sub-unit is configured to calculate a standard deviation representing a degree of dispersion between each pair of API requests according to the plurality of time difference values and the average value of the time difference values.

6. An electronic device, comprising: The computer program is stored on the computer readable storage medium and is executable on the processor to implement the steps of the method according to any one of claims 1-5. The computer program is stored on the computer readable storage medium and is executable on the processor to implement the steps of the method according to any one of claims 1-5.

7. A computer-readable storage medium, characterized in that, ​

Images