Request verification method and device, electronic equipment and storage medium

Abstract

The invention provides a request verification method and device, electronic equipment and a storage medium, and relates to the technical field of network security, and the method comprises the steps: obtaining a to-be-verified request sequence, the request sequence comprising a plurality of requests which are continuous in time; determining an API request and a non-API request from the request sequence according to the uniform resource locators and the request headers of the messages of the plurality of requests; and performing time sequence verification on the API request based on the time sequence characteristics, and performing reverse challenge verification on the non-API request based on the behavior characteristics of the client initiating the non-API request. Compared with a traditional reverse challenge algorithm, the method can quickly identify the API request before the flow enters the CC protection module, thereby preventing a normal request from being misjudged as a hostile attack, and guaranteeing the stability and availability of an API interface. The user experience is improved, the service loss is reduced, and a more flexible and efficient protection means is provided for the field of network security.

Description

Technical Field

[0001] The present disclosure relates to the field of network security technology, and in particular to a request verification method, device, electronic device and storage medium. Background Art

[0002] In today's digital age, network security issues are becoming more and more serious, especially CC (Challenge Collapsar) attacks against web applications, which have become a major threat to the normal operation of websites and user experience. CC attacks are usually carried out by hackers using proxy servers or controlled zombies to send a large number of HTTP requests to the target web pages, especially those that require frequent database queries.

[0003] In order to deal with CC attacks, traditional defense mechanisms mainly rely on reverse challenge algorithms. The reverse challenge algorithm verifies whether the request comes from normal browser operations or legitimate users by setting cookies, executing JavaScript code, redirecting requests, etc. However, with the widespread application of mobile terminals and API interfaces, this PC-based browser verification method has gradually become ineffective. The request pattern of the API interface is significantly different from that of traditional web page requests, usually with a higher request frequency and a specific content format. This makes it easy for traditional CC defense algorithms to misjudge when identifying API requests, resulting in normal API requests being incorrectly intercepted, thereby affecting the normal operation of the business. Summary of the invention

[0004] The embodiments of the present disclosure provide a request verification method, device, electronic device and storage medium, aiming to solve the problems existing in the above-mentioned background technology.

[0005] In order to solve the above technical problems, the present disclosure is implemented as follows: In a first aspect, an embodiment of the present disclosure provides a request verification method, the method comprising: Obtaining a request sequence to be verified, wherein the request sequence includes a plurality of requests that are continuous in time; Determine the API request and the non-API request from the request sequence according to the uniform resource locator and the request header of each message of the plurality of requests; The API request is subjected to a timing check based on the timing characteristics, and the non-API request is subjected to a reverse challenge check based on the behavior characteristics of the client that initiates the non-API request.

[0006] Optionally, performing timing verification on the API request based on the timing feature includes: Determine all API requests from the request sequence, and classify API requests of the same type into a one-to-one corresponding first request set; Performing a timing check on the first request set based on the timing characteristics; If the first request set passes the timing check, determining that the API requests in the first request set are normal requests; When the first request set fails the timing check, it is determined that the API requests in the first request set are abnormal requests.

[0007] Optionally, determining the API request and the non-API request from the request sequence according to the uniform resource locators and request headers of the respective messages of the multiple requests includes: Parsing the Uniform Resource Locators of the multiple requests from the messages of the multiple requests; Determining whether the uniform resource locators of the plurality of requests match a preset static file type; For any one of the multiple requests, if the uniform resource locator matches a preset static file type, determining that the request is an API request; When the uniform resource locator does not match the preset static file type, parse the request header from the request message; determine whether the request header matches the preset request body format; when the request header matches the preset request body format, determine that the request is an API request; when the request header does not match the preset request body format, determine that the request is a non-API request.

[0008] Optionally, performing a reverse challenge check on the non-API request based on a behavior characteristic of a client that initiates the non-API request includes: Determine all non-API requests from the request sequence, and classify the non-API requests of the same type into a one-to-one corresponding second request set; Performing a reverse challenge check on the second request set based on the behavioral characteristics of the client; In a case where the second request set passes the reverse challenge check, determining that the non-API requests in the second request set are normal requests; When the second request set fails the reverse challenge check, it is determined that the non-API requests in the second request set are abnormal requests.

[0009] Optionally, performing timing verification on the first request set based on the timing feature includes: Obtaining the timestamp of each API request in the first request set; According to the timestamps of each API request, the standard deviation used to characterize the degree of dispersion between each API request is calculated; comparing the standard deviation with a preset threshold; When the standard deviation exceeds the threshold, the first request set is determined to be normal requests; when the standard deviation does not exceed the threshold, the first request set is determined to be abnormal requests.

[0010] Optionally, the step of calculating, according to the timestamps of the API requests, a standard deviation for characterizing the degree of dispersion between the API requests includes: Obtaining the timestamp of each API request in the first request set; Determine, according to the timestamps of the respective API requests, a plurality of time differences between the respective temporally adjacent API requests in the first request set, and determine an average value of the plurality of time differences; A standard deviation for characterizing the degree of dispersion between the API requests is calculated based on the multiple time difference values ​​and the average value of the time difference values.

[0011] Optionally, after determining a plurality of time differences between respective temporally adjacent API requests in the first request set according to respective timestamps of respective API requests, the method further comprises: Smoothing multiple time differences between temporally adjacent API requests in the first request set; The last two digits of each of the multiple time difference values ​​after smoothing are summed to zero.

[0012] In a second aspect, an embodiment of the present disclosure provides a request verification device, the device comprising: An acquisition module, used for acquiring a request sequence to be verified, wherein the request sequence includes a plurality of requests that are continuous in time; A determination module, configured to determine the API request and the non-API request from the request sequence according to the uniform resource locator and the request header of each message of the plurality of requests; The verification module is used to perform a timing verification on the API request based on the timing characteristics, and to perform a reverse challenge verification on the non-API request based on the behavior characteristics of the client that initiates the non-API request.

[0013] Optionally, the verification module includes: A first determination submodule, configured to determine all API requests from the request sequence, and classify API requests of the same type into a one-to-one corresponding first request set; A timing check submodule, used for performing a timing check on the first request set based on the timing characteristics; A second determination submodule is used to determine that the API requests in the first request set are normal requests if the first request set passes the timing check; The third determination submodule is used to determine that the API request in the first request set is an abnormal request when the first request set fails the timing check.

[0014] Optionally, the determining module includes: A parsing submodule, used for parsing the Uniform Resource Locator of each of the multiple requests from the messages of each of the multiple requests; A first determination submodule, configured to determine whether the uniform resource locators of the plurality of requests match a preset static file type; A fourth determination submodule is used to determine, for any request among the multiple requests, that the request is an API request when the uniform resource locator matches a preset static file type; The second judgment submodule is used to parse the request header from the request message when the uniform resource locator does not match the preset static file type; determine whether the request header matches the preset request body format; when the request header matches the preset request body format, determine that the request is an API request; when the request header does not match the preset request body format, determine that the request is a non-API request.

[0015] Optionally, the verification module includes: a fifth determining submodule, configured to determine all non-API requests from the request sequence, and classify the non-API requests of the same type into a one-to-one corresponding second request set; A reverse challenge verification submodule, configured to perform a reverse challenge verification on the second request set based on the behavioral characteristics of the client; a sixth determination submodule, configured to determine, when the second request set passes the reverse challenge check, that the non-API requests in the second request set are normal requests; The seventh determination submodule is used to determine that the non-API requests in the second request set are abnormal requests when the second request set fails the reverse challenge check.

[0016] Optionally, the timing check submodule includes: An acquiring unit, configured to acquire a timestamp of each API request in the first request set; A calculation unit, used to calculate a standard deviation for representing a degree of dispersion between each API request according to the timestamp of each API request; A comparison unit, configured to compare the standard deviation with a preset threshold; A determination unit is configured to determine that the first request set is a normal request if the standard deviation exceeds the threshold value; and to determine that the first request set is an abnormal request if the standard deviation does not exceed the threshold value.

[0017] Optionally, the computing unit includes: An acquiring subunit, used to acquire the timestamp of each API request in the first request set; a determination subunit, configured to determine, according to respective timestamps of respective API requests, a plurality of time differences between respective temporally adjacent API requests in the first request set, and to determine an average value of the plurality of time differences; The calculation subunit is used to calculate a standard deviation for characterizing the degree of discreteness between each API request based on the multiple time difference values ​​and the average value of the time difference values.

[0018] Optionally, the device further comprises: A smoothing processing module, used for smoothing a plurality of time differences between each of the temporally adjacent API requests in the first request set; The zero-sum processing module is used to perform zero-sum processing on the last two digits of each of the multiple time difference values ​​after smoothing.

[0019] In a third aspect, an embodiment of the present disclosure provides an electronic device, including: a processor, a memory, and A computer program stored in the memory and capable of running on the processor implements the steps of a request verification method when the computer program is executed by the processor.

[0020] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of a request verification method are implemented.

[0021] The technical solution provided by the embodiments of the present disclosure brings at least the following beneficial effects: Based on API request feature recognition, the present disclosure effectively reduces the CC defense algorithm's false interception rate of API requests, significantly improving the accuracy and efficiency of network security protection. Compared with the traditional reverse challenge algorithm, the present disclosure can quickly identify API requests before the traffic enters the CC protection module, thereby preventing normal requests from being misjudged as malicious attacks and ensuring the stability and availability of the API interface. In addition, the verification method based on timing features can accurately evaluate the regularity of client request behavior, identify potential attack behaviors in a timely manner, and enhance the system's defense capabilities. It not only improves user experience and reduces business losses, but also provides a more flexible and efficient means of protection for the field of network security. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0023] Figure 1 It is a schematic diagram of reverse challenge based on CC defense algorithm in related technologies; Figure 2 It is a schematic diagram of the steps of a request verification method provided by an embodiment of the present disclosure; Figure 3 It is a schematic diagram of the overall flow of a request verification method provided by an embodiment of the present disclosure; Figure 4 is a schematic diagram of a timing verification process based on timing characteristics in an embodiment of the present disclosure; Figure 5 It is a structural block diagram of a request verification device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0024] The following will be combined with the drawings in the embodiments of the present disclosure to clearly and completely describe the technical solutions in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, rather than all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present disclosure.

[0025] Figure 1 This is a schematic diagram of the reverse challenge based on the CC defense algorithm in the related technology. Please refer to Figure 1, the client (such as the user's browser or application) sends an HTTP request to the target server, requesting access to specific resources or services. At this time, the client's request may be a normal user request or a malicious attack request. After receiving the request, the protection module initiates a reverse challenge to determine the legitimacy of the request. Usually, it includes setting cookies, responding to JavaScript codes, or performing 302 / 307 redirects. The protection module attempts to verify whether the client is a normal user through these challenges. For example, the protection module may require the client to execute specific JavaScript code and carry the correct cookie value in the next request. After receiving the challenge from the protection module, the client will respond according to the content of the challenge. If the challenge is successful, the client will carry the correct cookie or execute the corresponding JavaScript code and initiate a request to the protection module again. After verifying the validity of the client's response, if the protection module confirms that the request is legitimate, it forwards the request to the target server for processing. At this point, the target server can normally process the request from the client and return the corresponding result. The relevant technology is mainly designed for traditional PC browser requests and cannot effectively process API interface requests. API requests are usually initiated directly by programs and do not have the behavioral characteristics of browsers, which causes the reverse challenge algorithm to fail and normal API requests may be intercepted by mistake. The reverse challenge process may lead to a decline in user experience, especially in mobile or application scenarios, where users may need to wait for multiple requests to complete the operation, which increases latency and complexity. It can be seen that the relevant technology has obvious defects in responding to API requests and improving user experience, and it is urgently needed to be improved to adapt to the increasingly complex network security environment.

[0026] Figure 2 is a schematic diagram of the steps of a request verification method provided by an embodiment of the present disclosure, such as Figure 2 As shown, the method includes: Step S101, obtaining a request sequence to be verified, wherein the request sequence includes a plurality of requests that are continuous in time.

[0027] The request sequence refers to multiple 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 issued in chronological order, and each request has a timestamp indicating the specific time when it was issued.

[0028] Step S102: 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 multiple requests.

[0029] 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 multiple requests. The step S102 specifically includes steps S1021 to S1024: Step S1021: parse the Uniform Resource Locator (URL) of each of the multiple requests from the respective messages of the multiple requests.

[0030] When processing a sequence of requests, first extract the complete request message from each request. The first line of the request message is the request line. 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, its uniform location identifier is / images / logo.png. For different HTTP request methods (such as GET, POST, etc.), the structure of the request line remains consistent, so the way to extract the URL is the same. Regardless of the request method, the process of parsing the request line is similar.

[0031] Step S1022, determining whether the uniform resource locators of the multiple requests match a preset static file type.

[0032] The present disclosure predefines a set of static file types, including various file extensions, such as: .css, .js, .jpg, .png, .pdf, etc. These file types point to static resources, such as style sheets, scripts, images, and documents. For each URL, its file extension is 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 type. Specifically, check whether the extracted extension is in the preset static file type list.

[0033] Step S1023: For any request among the multiple requests, when the uniform resource locator matches a preset static file type, determine that the request is an API request.

[0034] For each request whose uniform resource locator matches the preset static file type determined in step S1022, the request header part in the request message is parsed to extract the request header fields and their corresponding values. For example, for the following message: GET / images / logo.png HTTP / 1.1 Host: example.com 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 Accept: image / webp,image / apng,image / *,* / *; q=0.8; the following request headers can be parsed: Host: example.com User-Agent: Mozilla / 5.0 ... Accept: image / webp,image / apng,…. Figure 3 FIG. 1 is a schematic diagram of the overall flow of a request verification method provided by an embodiment of the present disclosure, such as Figure 3 As shown, requests that match the preset static file type with a uniform resource identifier are determined as API requests, and these requests that successfully match are static requests, which is equivalent to filtering static file URLs. Non-static requests that do not successfully match are further determined in step S1024.

[0035] Step S1024, when the uniform resource locator does not match the preset static file type, parse the request header from the request message; determine whether the request header matches the preset request body format; when the request header matches the preset request body format, determine that the request is an API request; when the request header does not match the preset request body format, determine that the request is a non-API request.

[0036] A set of request body formats predefined by this 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 form data format. Figure 3 , further judge the non-static requests whose URLs do not match the static file type in step S1023, and match the Content-Type extracted from these non-static requests with the preset request body format.

[0037] For example, assume the request header is as follows: POST / api / v1 / users HTTP / 1.1 Host: example.com Content-Type: application / json; extract the Content-Type field and get application / json. Check whether application / json is in the preset request body format list (assuming that the preset formats include application / json, application / x-www-form-urlencoded, and multipart / form-data). Since application / json matches the preset format, the request is determined to be an API request. On the contrary, for a non-static request, the request does not match the static file type nor the request body format preset in the request header, so the request is determined to be a non-API request.

[0038] Step S103: performing a timing check on the API request based on the timing characteristics, and performing a reverse challenge check on the non-API request based on the behavior characteristics of the client that initiates the non-API request.

[0039] The core idea of ​​the present disclosure is to adopt different processing methods for API requests and non-API requests. For API requests, a verification method based on timing characteristics is adopted. Timing characteristics refer to behavioral patterns such as the time interval and frequency of requests. Normal user requests have a certain randomness, while attacker requests often show regularity and high frequency. By analyzing the time interval and frequency of requests, potential automated attacks (such as CC attacks) can be identified and the risk of false interception can be reduced. Relatively speaking, non-API requests are processed through a reverse challenge mechanism based on the behavioral characteristics of the client (such as request frequency, request mode, request source, etc.) to verify the true identity of the client and prevent malicious users from using normal requests to attack.

[0040] Based on API request feature recognition, the present disclosure effectively reduces the CC defense algorithm's false interception rate of API requests, significantly improving the accuracy and efficiency of network security protection. Compared with the traditional reverse challenge algorithm, the present disclosure can quickly identify API requests before the traffic enters the CC protection module, thereby preventing normal requests from being misjudged as malicious attacks and ensuring the stability and availability of the API interface. In addition, the verification method based on timing features can accurately evaluate the regularity of client request behavior, identify potential attack behaviors in a timely manner, and enhance the system's defense capabilities. It not only improves user experience and reduces business losses, but also provides a more flexible and efficient means of protection for the field of network security.

[0041] In an optional embodiment, the timing verification of the API requests based on timing features includes: determining all API requests from the request sequence, and classifying API requests of the same type into a one-to-one corresponding first request set; performing timing verification on the first request set based on timing features; if the first request set passes the timing verification, determining that the API requests in the first request set are normal requests; if the first request set fails the timing verification, determining that the API requests in the first request set are abnormal requests.

[0042] All identified API requests are classified according to the request type. Specifically, they are classified according to the uniform resource locator URL of each API request. For example, all requests starting with / api / users can be classified as "user-related API requests", and requests starting with / api / products can be classified as "product-related API requests". The classified API request sets correspond one by one to a first request set, and at least one first request set is obtained. The first request set is timing-verified based on the timing characteristics. It can be understood that the embodiment of the present disclosure performs timing verification on API requests with the same URL. API requests with the same URL represent the same operation or resource access. These API requests are functionally consistent, so their request patterns and behavioral characteristics will also be similar. Only timing verification is performed on API requests with the same URL to more accurately identify the regularity and abnormality of the requests.

[0043] For any set in at least one first request set, if the timing characteristics of the first request set pass the preset verification criteria (for example, the standard deviation is within a certain range), the API requests in the set are determined to be normal requests. In other words, the behavior patterns of these requests are consistent with the operating habits of normal users, and these requests can be processed with confidence. 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. This means that these requests may be initiated by scripts or automated tools, and there is a potential risk of attack.

[0044] Through the above steps, the verification method based on timing features can effectively distinguish normal API requests from potential abnormal requests, reduce the possibility of false interception, and ensure that normal user requests can be processed smoothly.

[0045] In an optional embodiment, the reverse challenge check is performed on the non-API request based on the behavioral characteristics of the client that initiates the non-API request, including: determining all non-API requests from the request sequence, and classifying the non-API requests of the same type into a one-to-one corresponding second request set; performing a reverse challenge check on the second request set based on the behavioral characteristics of the client; if the second request set passes the reverse challenge check, determining that the non-API requests in the second request set are normal requests; if the second request set fails the reverse challenge check, determining that the non-API requests in the second request set are abnormal requests.

[0046] All identified non-API requests are classified according to the request type. The classification method is the same as the aforementioned method for classifying API requests, 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 reverse challenge verified. It can also be understood that the embodiment of the present disclosure is to perform a reverse challenge check on non-API requests with the same URL. It specifically involves verifying whether the client has the behavioral characteristics of a normal user.

[0047] For any set in at least one second request set, if the requests in the second request set pass the preset reverse challenge check (for example, the client successfully carries the correct cookie, executes the JavaScript code, or successfully redirects), the non-API requests in the second request set are determined to be normal requests, that is, the initiators of these requests are identified as legitimate users and these requests can be processed normally. If the second request set fails to pass the reverse challenge check (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 malicious users or automated tools, and there is a potential risk of attack.

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

[0049] In an optional implementation, performing timing verification on the first request set based on the timing feature includes: Step S201, obtaining the timestamp of each API request in the first request set.

[0050] Figure 4This is a schematic diagram of the timing verification process based on timing characteristics in the embodiment of the present disclosure, please refer to Figure 4 , extract the timestamp of each API request from the first request set. Assume that there are the following API requests and their corresponding timestamps (in milliseconds): Request 1: 1000 ms; Request 2: 1020 ms; Request 3: 1050 ms; Request 4: 1075 ms; Request 5: 1100 ms.

[0051] Step S202: Calculate the standard deviation for characterizing the degree of dispersion between the API requests according to the timestamps of the API requests.

[0052] Specifically, step S202 includes steps S2021 to S2023: Step S2021, obtaining the timestamp of each API request in the first request set.

[0053] Step S2022: determining, based on the timestamps of the respective API requests, a plurality of time differences between the respective temporally adjacent API requests in the first request set, and determining an average value of the plurality of time differences.

[0054] Back to the previous example, based on the timestamps of each API request, we calculate the time difference between adjacent requests (i.e., the difference in timestamps). We can get: 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.

[0055] The sequence of time differences is: 20 milliseconds, 30 milliseconds, 25 milliseconds, and 25 milliseconds. The average value of the time difference is calculated based on the sequence of time differences:

[0056] In the formula, is the average of the time differences.

[0057] Step S2023: Calculate a standard deviation for characterizing the degree of discreteness between each API request based on the multiple time differences and the average value of the time differences.

[0058] According to the obtained , the standard deviation used to characterize the degree of dispersion between API requests is calculated according to the following formula

[0059] In the formula, Nis the amount of time difference, is each time difference, is the average of the time differences, N is the number of time differences. It can be concluded that the variance in the standard deviation of the above formula is:

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

[0061] Step S203: compare the standard deviation with a preset threshold.

[0062] Assuming that the preset threshold is 5 milliseconds, the calculated standard deviation (about 3.54 milliseconds) is compared with the preset threshold (5 milliseconds).

[0063] Step S204: when the standard deviation exceeds the threshold, determine that the first request set is a normal request; when the standard deviation does not exceed the threshold, determine that the first request set is an abnormal request.

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

[0065] The timing verification method based on timing features proposed in the present disclosure can effectively identify the behavior patterns of normal users for API interface type requests and help prevent potential malicious attacks.

[0066] In an optional implementation, after determining multiple time differences between temporally adjacent API requests in the first request set according to respective timestamps of respective API requests, the method further includes: Step S301: Smoothing multiple time differences between temporally adjacent API requests in the first request set.

[0067] See also Figure 4 In step S201, it is assumed that the sequence of time differences between adjacent API requests has been calculated as: 20 milliseconds, 30 milliseconds, 25 milliseconds, and 25 milliseconds. The purpose of smoothing is to reduce the random fluctuations in the time difference. Methods such as moving average or weighted average can be used. Here, a simple moving average method can be used for smoothing. For each time difference, take the average of the adjacent values ​​before and after it. For the boundary values ​​(the first and the last), you can simply use their own values ​​or only consider one adjacent value.

[0068] For the first time difference (20 milliseconds), we can only consider it by itself, with a smoothing value of 20 milliseconds.

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

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

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

[0072] The resulting smoothed time difference sequence is: 20 milliseconds, 25 milliseconds, 27 milliseconds, 25 milliseconds.

[0073] Step S302, performing zero-sum processing on the last two digits of each of the plurality of time difference values ​​after the smoothing processing.

[0074] Zero-sum processing is to process the last two digits of the smoothed time difference to reduce the interference of network factors. The specific method is to perform zero-sum processing on the last two digits of each time difference. For each smoothed value, take the last two digits and perform zero-sum processing, that is, divide the value by 100, round it up, and then multiply it by 100.

[0075] 20 milliseconds: 20 / 100 = 0, 0 * 100 = 0 milliseconds; 25 milliseconds: 25 / 100 = 0, 0 * 100 = 0 milliseconds; 27 milliseconds: 27 / 100 = 0, 0 * 100 = 0 milliseconds; 25 milliseconds: 25 / 100 = 0, 0 * 100 = 0 milliseconds; the obtained zero-sum processed time difference sequence is: 0 milliseconds, 0 milliseconds, 0 milliseconds, 0 milliseconds. The zero-sum processed time difference sequence will be used as the multiple time differences to participate in the calculation in step S202.

[0076] Through the above steps, the time differences between adjacent API requests in the first request set are smoothed and zero-summed. Smoothing reduces the fluctuation of the time difference, while zero-summing further normalizes the time difference, which helps with subsequent standard deviation calculation and identification of abnormal requests, improves the accuracy of identifying normal request behaviors, and reduces the risk of misjudgment.

[0077] Figure 5 is a structural block diagram of a request verification device provided by an embodiment of the present disclosure, such as Figure 5 As shown, the device comprises: An acquisition module 401 is used to acquire a request sequence to be verified, wherein the request sequence includes a plurality of requests that are continuous in time; A determination module 402, configured to determine an API request and a non-API request from the request sequence according to a uniform resource locator and a request header of each message of the plurality of requests; The verification module 403 is used to perform a timing verification on the API request based on the timing characteristics, and to perform a reverse challenge verification on the non-API request based on the behavior characteristics of the client that initiates the non-API request.

[0078] In an optional implementation, the verification module includes: A first determination submodule, configured to determine all API requests from the request sequence, and classify API requests of the same type into a one-to-one corresponding first request set; A timing check submodule, used for performing a timing check on the first request set based on the timing characteristics; A second determination submodule is used to determine that the API requests in the first request set are normal requests if the first request set passes the timing check; The third determination submodule is used to determine that the API request in the first request set is an abnormal request when the first request set fails the timing check.

[0079] In an optional implementation, in an optional implementation, the determining module includes: A parsing submodule, used for parsing the Uniform Resource Locator of each of the multiple requests from the messages of each of the multiple requests; A first determination submodule, configured to determine whether the uniform resource locators of the plurality of requests match a preset static file type; A fourth determination submodule is used to determine, for any request among the multiple requests, that the request is an API request when the uniform resource locator matches a preset static file type; The second judgment submodule is used to parse the request header from the request message when the uniform resource locator does not match the preset static file type; determine whether the request header matches the preset request body format; when the request header matches the preset request body format, determine that the request is an API request; when the request header does not match the preset request body format, determine that the request is a non-API request.

[0080] In an optional implementation, the verification module includes: a fifth determining submodule, configured to determine all non-API requests from the request sequence, and classify the non-API requests of the same type into a one-to-one corresponding second request set; A reverse challenge verification submodule, configured to perform a reverse challenge verification on the second request set based on the behavioral characteristics of the client; a sixth determination submodule, configured to determine, when the second request set passes the reverse challenge check, that the non-API requests in the second request set are normal requests; The seventh determination submodule is used to determine that the non-API requests in the second request set are abnormal requests when the second request set fails the reverse challenge check.

[0081] In an optional implementation, the timing check submodule includes: An acquiring unit, configured to acquire a timestamp of each API request in the first request set; A calculation unit, used to calculate a standard deviation for representing a degree of dispersion between each API request according to the timestamp of each API request; A comparison unit, configured to compare the standard deviation with a preset threshold; A determination unit is configured to determine that the first request set is a normal request if the standard deviation exceeds the threshold value; and to determine that the first request set is an abnormal request if the standard deviation does not exceed the threshold value.

[0082] In an optional implementation, the calculation unit includes: An acquiring subunit, used to acquire the timestamp of each API request in the first request set; a determination subunit, configured to determine, according to respective timestamps of respective API requests, a plurality of time differences between respective temporally adjacent API requests in the first request set, and to determine an average value of the plurality of time differences; The calculation subunit is used to calculate a standard deviation for characterizing the degree of discreteness between each API request based on the multiple time difference values ​​and the average value of the time difference values.

[0083] In an optional embodiment, the device further comprises: A smoothing processing module, used for smoothing a plurality of time differences between each of the temporally adjacent API requests in the first request set; The zero-sum processing module is used to perform zero-sum processing on the last two digits of each of the multiple time difference values ​​after smoothing.

[0084] An embodiment of the present disclosure also provides 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 various processes in the above-mentioned request verification method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0085] The embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, each process in the above-mentioned request verification method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it is not repeated here. Each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the embodiments can be referred to each other.

[0086] Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, devices, electronic devices, and storage media. Therefore, the embodiments of the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of the present disclosure may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0087] The embodiments of the present disclosure are described with reference to the flowcharts and / or block diagrams of the methods and devices according to the embodiments of the present disclosure. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing terminal device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 A process or multiple processes and / or boxes Figure 1These computer program instructions can also be loaded into a computer or other programmable data processing terminal device, so that a series of operation steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable terminal device provide for implementing the process in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0088] Although the preferred embodiments of the present disclosure have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present disclosure.

[0089] Finally, it should be noted that, in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the term "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "include..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements. The above is a detailed introduction to a request verification method, device, electronic device and storage medium provided by the present disclosure. The principles and implementation methods of the present disclosure are explained in this article using specific examples. The description of the above embodiments is only used to help understand the method and its core idea of ​​the present disclosure; at the same time, for those of ordinary skill in the art, according to the idea of ​​the present disclosure, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present disclosure.

Claims

1. A request verification method, characterized in that: The method comprises: Obtaining a request sequence to be verified, wherein the request sequence includes a plurality of requests that are continuous in time; Determine the API request and the non-API request from the request sequence according to the uniform resource locator and the request header of each message of the plurality of requests; The API request is subjected to a timing check based on the timing characteristics, and the non-API request is subjected to a reverse challenge check based on the behavior characteristics of the client that initiates the non-API request.

2. The method according to claim 1, characterized in that The performing timing verification on the API request based on the timing feature includes: Determine all API requests from the request sequence, and classify API requests of the same type into a one-to-one corresponding first request set; Performing a timing check on the first request set based on the timing characteristics; If the first request set passes the timing check, determining that the API requests in the first request set are normal requests; When the first request set fails the timing check, it is determined that the API requests in the first request set are abnormal requests.

3. The method according to claim 1, characterized in that The step of determining the API request and the non-API request from the request sequence according to the uniform resource locators and request headers of the respective messages of the plurality of requests includes: Parsing the Uniform Resource Locators of the multiple requests from the messages of the multiple requests; Determining whether the uniform resource locators of the plurality of requests match a preset static file type; For any one of the multiple requests, if the uniform resource locator matches a preset static file type, determining that the request is an API request; When the uniform resource locator does not match the preset static file type, parse the request header from the request message; determine whether the request header matches the preset request body format; when the request header matches the preset request body format, determine that the request is an API request; when the request header does not match the preset request body format, determine that the request is a non-API request.

4. The method according to claim 1, characterized in that: The performing a reverse challenge check on the non-API request based on the behavior characteristics of the client that initiates the non-API request includes: Determine all non-API requests from the request sequence, and classify the non-API requests of the same type into a one-to-one corresponding second request set; Performing a reverse challenge check on the second request set based on the behavioral characteristics of the client; In a case where the second request set passes the reverse challenge check, determining that the non-API requests in the second request set are normal requests; When the second request set fails the reverse challenge check, it is determined that the non-API requests in the second request set are abnormal requests.

5. The method according to claim 2, characterized in that: The performing timing verification on the first request set based on the timing characteristics includes: Obtaining the timestamp of each API request in the first request set; According to the timestamps of each API request, the standard deviation used to characterize the degree of dispersion between each API request is calculated; comparing the standard deviation with a preset threshold; When the standard deviation exceeds the threshold, the first request set is determined to be normal requests; when the standard deviation does not exceed the threshold, the first request set is determined to be abnormal requests.

6. The method according to claim 5, characterized in that The standard deviation used to characterize the degree of dispersion between the API requests is calculated according to the timestamps of the API requests, including: Obtaining the timestamp of each API request in the first request set; Determine, according to the timestamps of the respective API requests, a plurality of time differences between the respective temporally adjacent API requests in the first request set, and determine an average value of the plurality of time differences; A standard deviation for characterizing the degree of dispersion between the API requests is calculated based on the multiple time difference values ​​and the average value of the time difference values.

7. The method according to claim 6, characterized in that After determining a plurality of time differences between respective temporally adjacent API requests in the first request set according to respective timestamps of respective API requests, the method further comprises: Smoothing multiple time differences between temporally adjacent API requests in the first request set; The last two digits of each of the multiple time difference values ​​after smoothing are summed to zero.

8. A request verification device, characterized in that: The device comprises: An acquisition module, used for acquiring a request sequence to be verified, wherein the request sequence includes a plurality of requests that are continuous in time; A determination module, configured to determine the API request and the non-API request from the request sequence according to the uniform resource locator and the request header of each message of the plurality of requests; The verification module is used to perform a timing verification on the API request based on the timing characteristics, and to perform a reverse challenge verification on the non-API request based on the behavior characteristics of the client that initiates the non-API request.

9. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein when the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images