Method and apparatus for processing interface request

Abstract

This application discloses a method and apparatus for processing interface requests, belonging to the field of network security technology. It addresses the problem that related technologies struggle to accurately identify anomalies in interface requests, making interfaces vulnerable to attacks and resulting in poor interface security. The method includes: obtaining a first interface request for a target interface; the first interface request includes multiple first request parameters, each consisting of a first parameter name and a first parameter value; for each first request parameter, performing validation processing on the first request parameter according to a pre-determined parameter validation rule to obtain a validation result; wherein the parameter validation rule is determined based on multiple historical interface requests of the target interface; the parameter validation rule is used to validate the first parameter name, the length of the first parameter value, and the character elements contained in the first parameter value; and determining whether the first interface request is abnormal based on the validation result.

Description

Technical Field

[0001] This application belongs to the field of network security technology, specifically relating to a method and apparatus for processing interface requests. Background Technology

[0002] Web applications are applications accessible via the web, offering advantages such as ease of maintenance, rapid iteration, user-friendliness, and cross-platform compatibility. They have long been widely used in various sectors including finance, healthcare, education, and manufacturing. However, web applications have also become prime targets for attackers. Attackers launch attacks by tampering with and forging interface requests, injecting malicious content into request parameters, and causing security problems such as unauthorized access, data breaches, and even asset control.

[0003] Therefore, in related technologies, technical personnel typically design parameter validation logic for each interface during the interface design and development phase of a web application. This ensures that upon receiving an interface request, the interface validates the request parameters, rejecting requests with invalid parameters to achieve interface security. This parameter validation logic is often embedded or integrated into the web application through conditional statements, exception handling, or the introduction of third-party libraries. However, this approach has several drawbacks. First, it requires technical personnel to design parameter validation logic for each interface, which becomes a significant workload if there are many interfaces. Furthermore, if the required request parameters change, the parameter validation logic must be adjusted accordingly, increasing the manual design and maintenance costs. Second, due to varying skill levels among technical personnel, validating request parameters based on their designed logic may not guarantee accuracy, leaving the interface vulnerable to attacks with invalid parameters and compromising its security. Summary of the Invention

[0004] This application provides a method and apparatus for processing interface requests, which can solve the problem that related technologies have difficulty in accurately identifying anomalies in interface requests, making the interface vulnerable to attacks and resulting in poor interface security.

[0005] Firstly, embodiments of this application provide a method for processing interface requests, including:

[0006] Obtain a first interface request for the target interface; the first interface request includes multiple first request parameters, each of which consists of a first parameter name and a first parameter value.

[0007] For each first request parameter, the first request parameter is validated according to a pre-determined parameter validation rule to obtain a validation result; wherein, the parameter validation rule is determined based on multiple historical interface requests of the target interface; the parameter validation rule is used to validate the first parameter name, the length of the first parameter value, and the character elements contained in the first parameter value;

[0008] Based on the verification results, it is determined whether the first interface request is abnormal.

[0009] Secondly, embodiments of this application provide an interface request processing apparatus, including:

[0010] The first acquisition module is used to acquire a first interface request for the target interface; the first interface request includes multiple first request parameters, and the first request parameters are composed of first parameter names and first parameter values.

[0011] The verification processing module is used to verify each first request parameter according to a pre-determined parameter verification rule to obtain a verification result; wherein, the parameter verification rule is determined based on multiple historical interface requests of the target interface; the parameter verification rule is used to verify the name of the first parameter, the length of the first parameter value, and the character elements contained in the first parameter value;

[0012] The first determining module is used to determine whether the first interface request is abnormal based on the verification result.

[0013] Thirdly, embodiments of this application provide an electronic device including a processor; and a memory arranged to store computer-executable instructions configured to be executed by the processor to implement the steps of the interface request processing method as described in the first aspect.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium for storing computer-executable instructions that, when executed by a processor, implement the steps of the interface request processing method as described in the first aspect.

[0015] Fifthly, embodiments of this application provide a computer program product, the computer program product including a computer program that, when executed by a processor, implements the steps of the interface request processing method as described in the first aspect.

[0016] In a sixth aspect, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run executable instructions to implement the interface request processing method as described in the first aspect.

[0017] In this embodiment, a first interface request for a target interface can be obtained. The first interface request includes multiple first request parameters, each consisting of a first parameter name and a first parameter value. For each first request parameter, the first parameter name, the length of the first parameter value, and the character elements contained in the first parameter value are validated according to parameter validation rules pre-determined based on multiple historical interface requests of the target interface, resulting in a validation result. Furthermore, based on the validation result, it is determined whether the first interface request is abnormal. Therefore, in terms of interface security protection, compared to related technologies that rely on parameter validation logic designed and maintained by technicians to identify illegal parameters in interface requests and thus identify abnormal interface requests, this technical solution eliminates the need for technicians to design parameter validation rules for the target interface. This saves on manual design and maintenance costs, avoids reliance on technicians in the parameter validation process, and reduces the difficulty of implementing parameter validation. Furthermore, since the parameter validation rules are determined based on multiple historical interface requests of the target interface, these rules enable more targeted parameter validation of request parameters in interface requests to the target interface. Additionally, this technical solution utilizes parameter validation rules to validate multiple dimensions of the request parameters (including parameter name, parameter value length, and character elements contained in the parameter value), resulting in more accurate validation results. This allows for more precise determination of whether an interface request is abnormal, facilitating accurate security protection of the target interface and enhancing its security. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an interface request processing method provided in an embodiment of this application;

[0019] Figure 2 This is a flowchart illustrating another method for processing interface requests provided in an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of the structure of an interface request processing device provided in an embodiment of this application;

[0021] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0024] The interface request processing method and apparatus provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0025] Figure 1 This application illustrates an embodiment of an interface request processing method, which can be executed by an electronic device, including a server and / or a terminal device, such as an in-vehicle terminal or a mobile terminal. In other words, the method can be executed by software or hardware installed in the electronic device, and includes the following steps:

[0026] Step 102: Obtain the first interface request for the target interface. The first interface request includes multiple first request parameters.

[0027] The first request parameter consists of a first parameter name and a first parameter value. For example, if the first request parameter includes a username and a password, the first parameter name for the username can be "name" and the first parameter value can be "Lily"; the first parameter name for the password can be "password" and the first parameter value can be "123456".

[0028] Optionally, the target interface can be an API (Application Programming Interface), and the first interface request can be an API request to access the application. The API request can include path parameters, query parameters, request body parameters, header parameters, and other first request parameters. Path parameters are passed through the path portion of the URL (Uniform Resource Locator), such as / users / 342, where 342 is the user ID (IdentityDocument). In this example, the first parameter name can be `path`, and the first parameter value can be ` / users / 342`. Query parameters are passed through the query portion of the URL, generally appearing as key-value pairs, such as `search?query=python&sort=asc`. In this example, the first parameter name can be `query`, and the first parameter value can be `search?query=python&sort=asc`. Request body parameters are transmitted in the HTTP (Hypertext Transfer Protocol) request body, typically used in POST requests (for data submission and addition) and PUT requests (for modifying specific content of a resource), such as: {"username":"Lily", "password":"123456"}. In this example, the first parameter name can include username and password, and the corresponding first parameter value can be Lily and 123456. Header parameters are passed in the HTTP request header, typically used to carry authentication information or other metadata, such as: Authorization: Bearer token. In this example, the first parameter name can be Authorization, and the first parameter value can be Bearer token.

[0029] Step 104: For each first request parameter, perform validation processing on the first request parameter according to the predetermined parameter validation rules to obtain the validation result.

[0030] The parameter validation rules are determined based on multiple historical API requests from the target API. These rules validate the name of the first parameter, the length of its value, and the character elements contained within that value. The validation result can be either "validation passed" or "validation failed."

[0031] Step 106: Based on the verification results, determine whether there is an anomaly in the first interface request.

[0032] If the verification passes, it can be determined that the first interface request is not abnormal. If the verification fails, it can be determined that the first interface request is abnormal. Optionally, for interface requests with abnormalities, an error message can be issued to notify technical personnel that the target interface has been attacked.

[0033] Optionally, for the first interface request without any anomalies, it can be added to the historical interface requests to increase the diversity of historical interface requests, thereby enabling the adjustment and optimization of parameter validation rules, so that the determined parameter validation rules can dynamically adapt to the ever-changing attack patterns.

[0034] In this embodiment, a first interface request for a target interface can be obtained. The first interface request includes multiple first request parameters, each consisting of a first parameter name and a first parameter value. For each first request parameter, the first parameter name, the length of the first parameter value, and the character elements contained in the first parameter value are validated according to parameter validation rules pre-determined based on multiple historical interface requests of the target interface, resulting in a validation result. Furthermore, based on the validation result, it is determined whether the first interface request is abnormal. Therefore, in terms of interface security protection, compared to related technologies that rely on parameter validation logic designed and maintained by technicians to identify illegal parameters in interface requests and thus identify abnormal interface requests, this technical solution eliminates the need for technicians to design parameter validation rules for the target interface. This saves on manual design and maintenance costs, avoids reliance on technicians in the parameter validation process, and reduces the difficulty of implementing parameter validation. Furthermore, since the parameter validation rules are determined based on multiple historical interface requests of the target interface, these rules enable more targeted parameter validation of request parameters in interface requests to the target interface. Additionally, this technical solution utilizes parameter validation rules to validate multiple dimensions of the request parameters (including parameter name, parameter value length, and character elements contained in the parameter value), resulting in more accurate validation results. This allows for more precise determination of whether an interface request is abnormal, facilitating accurate security protection of the target interface and enhancing its security.

[0035] In one implementation, before obtaining the first interface request for the target interface (i.e., step 102), the parameter validation rules corresponding to the target interface can be determined according to the following steps A1-A4.

[0036] Step A1: Obtain multiple historical interface requests for the target interface. Each historical interface request includes multiple sample request parameters, which consist of a sample parameter name and a sample parameter value.

[0037] To avoid the randomness of historical interface requests and ensure the accuracy of the generated parameter validation rules, a sufficient number of historical interface requests need to be obtained when acquiring them for generating the rules. For example, more than 30 historical interface requests can be acquired. The specific number of historical interface requests acquired can be set according to the needs of the application scenario, and this embodiment does not impose any limitations on this.

[0038] Step A2: Based on the number of times each sample parameter name appears in multiple historical interface requests, determine the set of required parameters and the set of optional parameters corresponding to the target interface.

[0039] Taking the target interface as API and the interface request as an API request as an example, the request parameter X of the API request consists of the set of required parameters X. req and optional parameter set X opt Composition. Among them, the set of required parameters X req X is a required element in every valid API request. req It can be an empty set And the optional parameter set X opt That is, it is not necessary to carry, i.e., X. opt Some parameters in the API request can be omitted, such as X. opt It can be

[0040] Step A3: For each sample request parameter, determine the parameter length range and character element set corresponding to the sample request parameter based on the sample parameter values ​​in multiple historical interface requests.

[0041] For each sample request parameter, its sample parameter value in multiple historical interface requests may be the same or different. However, based on multiple sample parameter values, some patterns of the parameter value of the sample request parameter can be inferred, such as the length pattern of the sample parameter value, the character element pattern contained in the sample parameter value, etc. The length pattern of the sample parameter value is the parameter length range corresponding to the sample request parameter, and the character element pattern contained in the sample parameter value is the character element set corresponding to the sample request parameter.

[0042] Step A4: Determine the parameter validation rules for the target interface based on the set of required parameters, the set of optional parameters, the parameter length range, and the set of character elements.

[0043] In this embodiment, based on multiple historical interface requests of the target interface, the parameter verification rules corresponding to the target interface can be automatically determined through statistical processing. This eliminates the need for technical personnel to design parameter verification rules for the target interface, thus saving manual design and maintenance costs, avoiding reliance on technical personnel in the parameter verification process, and reducing the implementation difficulty of parameter verification.

[0044] In one implementation, the required parameter set and optional parameter set corresponding to the target interface are determined based on the number of times each sample parameter name appears in multiple historical interface requests (i.e., step A2). This can be executed as follows: Steps A21-A24:

[0045] Step A21: For each sample parameter name, count the number of times the sample parameter name appears in multiple historical interface requests.

[0046] Using the example from step A2, assuming the number of historical interface requests is N (N is a positive integer), by counting the first occurrences of the sample parameter name in the N historical interface requests, we can clearly know whether the sample parameter name has appeared in all N historical interface requests or only in some historical interface requests.

[0047] Step A22: If the first number of requests is consistent with the number of requests from multiple historical interfaces, the sample request parameter corresponding to the sample parameter name is determined as a required parameter.

[0048] Following the example in step A21, if the first number of times is N, it can be determined that the sample parameter name has appeared in all N historical interface requests. Therefore, the sample request parameter corresponding to the sample parameter name can be determined as a required parameter.

[0049] Step A23: If the number of requests in the first instance is inconsistent with the number of requests from multiple historical interfaces, the sample request parameter corresponding to the sample parameter name shall be determined as an optional parameter.

[0050] Following the example in step A21, if the first number is not N, that is, the first number is less than N, then it can be determined that the sample parameter name has only appeared in some historical interface requests. Therefore, the sample request parameter corresponding to the sample parameter name can be determined as an optional parameter.

[0051] Step A24: Determine the set of required parameters corresponding to the target interface based on each required parameter; and determine the set of optional parameters corresponding to the target interface based on each optional parameter.

[0052] In this embodiment, by counting the number of times each sample parameter name appears in multiple historical interface requests, the required parameter set and optional parameter set corresponding to the target interface can be automatically and accurately determined without manual intervention. This not only avoids dependence on technical personnel and makes the solution easier to implement, but also makes the solution more versatile and can determine the required parameter set and optional parameter set for different interfaces.

[0053] In one implementation, for each sample request parameter, the parameter length range and character element set corresponding to the sample request parameter are determined based on the sample parameter values ​​in multiple historical interface requests (i.e., step A3). This can be executed as follows: Steps A31-A34:

[0054] Step A31: For each sample request parameter, determine the first length set corresponding to the sample request parameter based on the first length of the sample parameter value in multiple historical interface requests.

[0055] The data type of the sample parameter value can include string and numeric types. When the sample parameter value is a string, it consists of characters, and its first length can be the length of the string. For example, if the sample parameter value for the path parameter is / users / 634, then the first length of this sample parameter value is 10 characters. When the sample parameter value is a numeric type, it is a number, and its first length can be the length of the number. For example, if the sample parameter value for the password parameter is 123456, then its first length is 6.

[0056] Step A32: Determine the parameter length range corresponding to the sample request parameters based on the first length set.

[0057] Optionally, the left and right boundaries of the parameter length range can be determined based on the elements contained in the first length set, thereby obtaining the parameter length range corresponding to the sample request parameter.

[0058] Taking the target interface as API and the historical interface requests as API requests as an example, in order to obtain the API request parameter x i The corresponding parameter length range S i It is possible to find N pairs of elements containing x. i From the historical interface requests, determine x. i The corresponding first length set {l1, l2, ... l N}, thus based on the elements l1, l2, ... l contained in the first length set N Determine the parameter length range S i Given the left boundary 'a' and the right boundary 'b', we obtain the parameter length range S corresponding to the sample request parameters. i = [a, b], 0 ≤ a ≤ b. Where, the sample request parameter x... i The first length l of any sample parameter value i (i∈[1,N]) will not exceed S i That is, l i ∈Si = [a, b]. N is a positive integer, and the size of N can be set according to the needs of the application scenario. This application embodiment does not limit this, but in order to avoid the randomness of historical interface requests and ensure the accuracy of the generated parameter verification rules, the number of N needs to be large enough.

[0059] In this embodiment, by statistically analyzing the length set corresponding to the sample parameter values ​​of each sample request parameter, the parameter length range corresponding to each sample request parameter is determined based on the elements in the length set. This achieves the effect of automatically determining the parameter length range corresponding to the sample request parameter, providing a data foundation for automatically generating parameter verification rules corresponding to the sample request parameter. This helps save the cost of manually designing and maintaining parameter verification logic, avoids dependence on technical personnel in the parameter verification process, and thus helps reduce the implementation difficulty of parameter verification.

[0060] Step A33: Determine the character elements contained in the sample parameter values ​​of the sample request parameters in multiple historical interface requests.

[0061] The sample parameter values ​​can be composed of character elements of various types, such as letters, numbers, Chinese characters, and symbols. Optionally, according to the type of character element, the value range Ω can be divided into 10 value ranges r1 to r10, as follows: the value range r1 for Chinese characters is [\\u4e00-\\u9fff]; the value range r2 for letters is [az, AZ]; the value range r3 for numbers is [0-9]; the value range r4 for mathematical symbols is [+-* / =]; the value range r5 for punctuation marks is [! ? 。 , :;]; the value range r6 for special meaning symbols is [@#￥%&]; the value range r7 for tags or parentheses is [()[]{}<>]; the value range r8 for general symbols is [^~|\_]; the value range r9 for quotation marks is [“”'']; and the value range r10 for other symbols is [other].

[0062] Step A34: Determine the set of character elements corresponding to the sample request parameters based on the value ranges corresponding to each character element; wherein the set of character elements is the union of each value range.

[0063] Taking the target interface as API and the interface request as an API request as an example, in order to obtain the API request parameter x i The corresponding set of character elements U i It is possible to find N pairs of elements containing x. i From the historical interface requests, determine x. i The included character elements {v1, v2, ... v m}, thereby determining the value range to which each character element belongs (such as the value range r1 to r10 mentioned above), and determining the union of multiple value ranges as x. i The corresponding set of character elements. Where N is a positive integer, the size of N can be set according to the needs of the application scenario. This application embodiment does not impose any restrictions on this, but to avoid the randomness of historical interface requests and ensure the accuracy of the generated parameter validation rules, the number of N needs to be sufficiently large. m is a positive integer, v1-v m Used to refer to x i It contains different types of character elements, such as numbers, mathematical symbols, Chinese characters, etc.

[0064] In this embodiment, by statistically analyzing the character elements contained in the sample parameter values ​​of each sample request parameter, the set of character elements corresponding to the sample request parameter is determined based on the value range corresponding to each character element. This achieves the effect of automatically determining the set of character elements corresponding to the sample request parameter, providing a data foundation for automatically generating parameter verification rules corresponding to the sample request parameter. This helps save the cost of manually designing and maintaining parameter verification logic, avoids dependence on technical personnel in the parameter verification process, and thus helps reduce the difficulty of implementing parameter verification.

[0065] In one implementation, determining the parameter length range corresponding to the sample request parameters based on the first length set (i.e., step A32) can be performed as follows: steps A321-A324:

[0066] Step A321: When all the first lengths are consistent, determine that the left and right boundaries of the parameter length range corresponding to the sample request parameter are both the first lengths.

[0067] Following the example in step A32, if l1, l2, ... l N If both are L, then a = b = L.

[0068] Step A322: When the first lengths are inconsistent, perform a normality test on the set of first lengths to obtain the normality test result.

[0069] Following the example in step A32, the Shapiro-Wilk test (a method for testing normality) can be used to test {l1,l2,……l N Perform a normality test. If the calculated p-value is greater than 0.05, then {l1, l2, ..., l} is considered normal. N The distribution approximately follows a normal distribution; if the calculated P-value is less than or equal to 0.05, then {l1, l2, ... l} is considered to be within the normal distribution. N It does not conform to a normal distribution.

[0070] Step A323: If the normality test result shows that the sample request parameter range conforms to a normal distribution, determine the parameter length range corresponding to the mean and standard deviation of the first length set.

[0071] If the normality test result indicates that the data conforms to a normal distribution, the mean e and standard deviation σ of the first length set can be calculated. Based on the mean e and standard deviation σ, the parameter length range S corresponding to the sample request parameters can be determined. i .

[0072] Optionally, the difference e-3σ between the mean and three times the standard deviation can be defined as the left boundary of the parameter length range, and the sum e+3σ between the mean and three times the standard deviation can be defined as the right boundary of the parameter length range, thus obtaining the parameter length range S corresponding to the sample requested parameters. i = [e-3σ, e+3σ].

[0073] Step A324: If the normality test result is not a normal distribution, determine the parameter length range corresponding to the sample request parameter based on the range of the first length set.

[0074] In cases where the normality test result indicates that the distribution does not conform to a normal distribution, the first length set {l1, l2, ... l} can be determined first. N The maximum value l in} max and minimum value l min Then based on the maximum value l max and minimum value l min The difference is used to determine the range R. Finally, based on the maximum value l max Minimum value l min And the range R, determine the parameter length range S corresponding to the sample request parameters. i .

[0075] Optionally, the left boundary of the parameter length range can be determined based on the minimum value and range in the first length set, and the right boundary of the parameter length range can be determined based on the maximum value and range in the first length set.

[0076] In an alternative embodiment, the difference l between the minimum and the range in the first length set can be used. min -R, which defines the left boundary of the parameter length range, can be the sum of the maximum value and the range in the first length set. max +R is used to define the right boundary of the parameter length range, thus obtaining the parameter length range S corresponding to the sample request parameters. i =[l min -R,l max +R].

[0077] In this embodiment, the parameter length range corresponding to the sample request parameter can be determined by combining the specific circumstances of the first length set (including whether each first length is consistent, whether the first length set conforms to a normal distribution, etc.), instead of using a fixed parameter length range determination strategy. This not only makes the implementation of the scheme more flexible, but also helps to improve the accuracy of the determined parameter length range.

[0078] In one implementation, for each first request parameter, the first request parameter is validated according to a predetermined parameter validation rule to obtain the validation result (i.e., step 104), which can be executed as follows: Steps B1-B2:

[0079] Step B1: Based on the name of the first parameter, determine whether the first request parameter belongs to the set of required parameters or the set of optional parameters.

[0080] Step B2: If it is determined that the first request parameter does not belong to the set of required parameters or the set of optional parameters, then the validation of the first request parameter is determined to fail.

[0081] Following the example in step A2, for a normal API request, in addition to including the required parameter set X... req In addition, if other parameters are required, these other parameters should all belong to the optional parameter set X. opt If the API request contains parameters that do not belong to X req It does not belong to X. opt If this parameter is invalid, then the validation for this parameter failed, and the API request is an abnormal request. Therefore, any API request parameter x... i The parameter range should satisfy:

[0082] In one implementation, after determining whether the first request parameter belongs to the set of required parameters or the set of optional parameters based on the first parameter name (i.e., step B1), if it is determined that the first request parameter belongs to the set of required parameters or the set of optional parameters, then it is further determined whether the length of the first parameter value is within the parameter length range. If it is determined that the length of the first parameter value is not within the parameter length range, then it is determined that the validation of the first request parameter fails.

[0083] In this embodiment, if the length of the first parameter value exceeds the parameter length range, it indicates that the length of the parameter value is abnormal or non-compliant, thus determining that the first request parameter verification fails.

[0084] In one implementation, after determining whether the length of the first parameter value is within the parameter length range, if it is determined that the length of the first parameter value is within the parameter length range, it is further determined whether the character elements contained in the first parameter value are contained in the character element set. If it is determined that the character elements contained in the first parameter value are not contained in the character element set, then it is determined that the validation of the first request parameter fails.

[0085] In this embodiment, if there are characters in the first parameter value that do not belong to the character element set, it indicates that the value of the parameter is abnormal or non-compliant, and thus it can be determined that the first request parameter verification fails.

[0086] In this embodiment, by performing layer-by-layer verification on the parameter name, parameter value length, and character elements contained in the parameter value of the request parameters, the verification results are more accurate. This allows for a more precise determination of whether the interface request is abnormal, which is beneficial for accurately implementing security protection for the target interface and improving the security of the target interface.

[0087] Figure 2 This is a flowchart illustrating another method for processing interface requests provided in an embodiment of this application. Optionally, in Figure 2 The interface request processing method shown is applied to web application interface security scenarios. This method can be deployed in a separate interface request processing unit, positioned in front of the web application. This means the processing unit can pre-process request parameters for interface requests accessing the web application, rejecting any abnormal requests and thus decoupling anomaly detection from the web application. Consequently, updates to parameter validation rules do not need to be packaged and deployed within the web application, significantly reducing the cost of changing these rules.

[0088] like Figure 2 As shown, the method for processing interface requests may include the following steps 201-208:

[0089] Step 201: Obtain the first interface request for the target interface. The first interface request includes multiple first request parameters, which consist of a first parameter name and a first parameter value.

[0090] Step 202: For each first request parameter, determine whether the first request parameter belongs to the set of required parameters or the set of optional parameters based on the first parameter name; if yes, proceed to step 203; if no, proceed to step 207.

[0091] The required parameter set and the optional parameter set are determined based on multiple historical interface requests of the target interface.

[0092] Step 203: Determine whether the length of the first parameter value is within the parameter length range corresponding to the first request parameter; if yes, proceed to step 204; if no, proceed to step 207.

[0093] The parameter length range is determined based on multiple historical interface requests from the target interface.

[0094] Step 204: Determine whether the character element contained in the first parameter value is contained in the character element set corresponding to the first request parameter; if yes, proceed to step 205; if no, proceed to step 207.

[0095] The character element set is determined based on multiple historical interface requests from the target interface.

[0096] Step 205: Confirm that the first request parameter has passed the verification.

[0097] Step 206: Determine that there are no exceptions in the first interface request.

[0098] Step 207: Determine that the validation of the first request parameter failed.

[0099] Step 208: Determine that there is an anomaly in the first interface request.

[0100] The specific processes of steps 201 to 208 have been described in detail in the above embodiments and will not be repeated here.

[0101] In this embodiment, a first interface request for a target interface can be obtained. The first interface request includes multiple first request parameters, each consisting of a first parameter name and a first parameter value. For each first request parameter, the first parameter name, the length of the first parameter value, and the character elements contained in the first parameter value are validated according to parameter validation rules pre-determined based on multiple historical interface requests of the target interface, resulting in a validation result. Furthermore, based on the validation result, it is determined whether the first interface request is abnormal. Therefore, in terms of interface security protection, compared to related technologies that rely on parameter validation logic designed and maintained by technicians to identify illegal parameters in interface requests and thus identify abnormal interface requests, this technical solution eliminates the need for technicians to design parameter validation rules for the target interface. This saves on manual design and maintenance costs, avoids reliance on technicians in the parameter validation process, and reduces the difficulty of implementing parameter validation. Furthermore, since the parameter validation rules are determined based on multiple historical interface requests of the target interface, these rules enable more targeted parameter validation of request parameters in interface requests to the target interface. Additionally, this technical solution utilizes parameter validation rules to validate multiple dimensions of the request parameters (including parameter name, parameter value length, and character elements contained in the parameter value), resulting in more accurate validation results. This allows for more precise determination of whether an interface request is abnormal, facilitating accurate security protection of the target interface and enhancing its security.

[0102] It should be noted that the interface request processing method provided in this application embodiment can be executed by an interface request processing device or a control module within that interface request processing device for executing the interface request processing method. This application embodiment uses the execution of the interface request processing method by an interface request processing device as an example to illustrate the interface request processing device provided in this application embodiment.

[0103] Figure 3 This is a schematic diagram of the structure of an interface request processing device provided in an embodiment of this application. For example... Figure 3 As shown, the interface request processing device includes: a first acquisition module 310, a verification processing module 320, and a first determination module 330.

[0104] The first acquisition module 310 is used to acquire a first interface request for the target interface; the first interface request includes multiple first request parameters, each consisting of a first parameter name and a first parameter value; the verification processing module 320 is used to perform verification processing on each first request parameter according to a predetermined parameter verification rule to obtain a verification result; wherein, the parameter verification rule is determined based on multiple historical interface requests of the target interface; the parameter verification rule is used to verify the first parameter name, the length of the first parameter value, and the character elements contained in the first parameter value; the first determination module 330 is used to determine whether the first interface request has any abnormalities based on the verification result.

[0105] In one implementation, the interface request processing device further includes a second acquisition module, a second determination module, a third determination module, and a fourth determination module;

[0106] The second acquisition module is used to acquire multiple historical interface requests for the target interface before acquiring the first interface request for the target interface; each historical interface request includes multiple sample request parameters, which consist of sample parameter names and sample parameter values; the second determination module is used to determine the set of required parameters and the set of optional parameters corresponding to the target interface based on the number of times each sample parameter name appears in the multiple historical interface requests; the third determination module is used to determine the parameter length range and character element set corresponding to each sample request parameter based on the sample parameter values ​​in the multiple historical interface requests; the fourth determination module is used to determine the parameter validation rules corresponding to the target interface based on the set of required parameters, the set of optional parameters, the parameter length range, and the character element set.

[0107] In one implementation, the second determining module includes a statistical unit, a first determining unit, a second determining unit, and a third determining unit;

[0108] The system comprises: a statistics unit for counting the first occurrences of each sample parameter name in multiple historical interface requests; a first determination unit for determining the sample request parameter corresponding to the sample parameter name as a required parameter if the first occurrence matches the number of occurrences in multiple historical interface requests; a second determination unit for determining the sample request parameter corresponding to the sample parameter name as an optional parameter if the first occurrence does not match the number of occurrences in multiple historical interface requests; and a third determination unit for determining the set of required parameters corresponding to the target interface based on each required parameter, and determining the set of optional parameters corresponding to the target interface based on each optional parameter.

[0109] In one implementation, the third determining module includes a fourth determining unit, a fifth determining unit, a sixth determining unit, and a seventh determining unit;

[0110] The fourth determining unit is used to determine the first length set corresponding to the sample request parameter for each sample request parameter based on the first length of the sample parameter value in multiple historical interface requests; the fifth determining unit is used to determine the parameter length range corresponding to the sample request parameter based on the first length set; the sixth determining unit is used to determine the character elements contained in the sample parameter value in multiple historical interface requests respectively; the seventh determining unit is used to determine the character element set corresponding to the sample request parameter based on the value range corresponding to each character element respectively; wherein, the character element set is the union of each value range.

[0111] In one implementation, the fifth determining unit is specifically used for: when all first lengths are consistent, determining that the left and right boundaries of the parameter length range corresponding to the sample request parameter are both first lengths; when the first lengths are inconsistent, performing a normality test on the set of first lengths to obtain a normality test result; when the normality test result shows that it conforms to a normal distribution, determining the parameter length range corresponding to the sample request parameter based on the mean and standard deviation of the set of first lengths; when the normality test result shows that it does not conform to a normal distribution, determining the parameter length range corresponding to the sample request parameter based on the range of the set of first lengths.

[0112] In one implementation, the fifth determining unit is specifically used to: determine the difference between the mean and three times the standard deviation as the left boundary of the parameter length range; and determine the sum between the mean and three times the standard deviation as the right boundary of the parameter length range.

[0113] In one implementation, the fifth determining unit is specifically used to: determine the left boundary of the parameter length range based on the minimum value and range in the first length set; and determine the right boundary of the parameter length range based on the maximum value and range in the first length set.

[0114] In one implementation, the verification processing module 320 includes: a first judgment unit and an eighth determination unit;

[0115] The first judgment unit is used to determine whether the first request parameter belongs to the set of required parameters or the set of optional parameters based on the name of the first parameter; the eighth determination unit is used to determine that the first request parameter fails the verification if it is determined that the first request parameter does not belong to the set of required parameters or the set of optional parameters.

[0116] In one implementation, the verification processing module 320 further includes: a second judgment unit and a ninth determination unit;

[0117] The second judgment unit is used to determine whether the length of the first request parameter is within the parameter length range after determining whether the first request parameter belongs to the set of required parameters or the set of optional parameters based on the first parameter name; the ninth determination unit is used to determine that the first request parameter fails the verification if it is determined that the length of the first parameter value is not within the parameter length range.

[0118] In one implementation, the verification processing module 320 further includes: a third judgment unit and a tenth determination unit;

[0119] The third judgment unit is used to determine whether the character elements contained in the first parameter value are included in the character element set if the length of the first parameter value is within the parameter length range after determining whether the length of the first parameter value is within the parameter length range; the tenth determination unit is used to determine whether the first request parameter verification fails if the character elements contained in the first parameter value are not included in the character element set.

[0120] In this embodiment, a first interface request for a target interface can be obtained. The first interface request includes multiple first request parameters, each consisting of a first parameter name and a first parameter value. For each first request parameter, the first parameter name, the length of the first parameter value, and the character elements contained in the first parameter value are validated according to parameter validation rules pre-determined based on multiple historical interface requests of the target interface, resulting in a validation result. Furthermore, based on the validation result, it is determined whether the first interface request is abnormal. Therefore, in terms of interface security protection, compared to related technologies that rely on parameter validation logic designed and maintained by technicians to identify illegal parameters in interface requests and thus identify abnormal interface requests, this technical solution eliminates the need for technicians to design parameter validation rules for the target interface. This saves on manual design and maintenance costs, avoids reliance on technicians in the parameter validation process, and reduces the difficulty of implementing parameter validation. Furthermore, since the parameter validation rules are determined based on multiple historical interface requests of the target interface, these rules enable more targeted parameter validation of request parameters in interface requests to the target interface. Additionally, this technical solution utilizes parameter validation rules to validate multiple dimensions of the request parameters (including parameter name, parameter value length, and character elements contained in the parameter value), resulting in more accurate validation results. This allows for more precise determination of whether an interface request is abnormal, facilitating accurate security protection of the target interface and enhancing its security.

[0121] The interface request processing device in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, a mobile electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. A non-mobile electronic device can be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not impose specific limitations.

[0122] The interface request processing device in this application embodiment can be a device with an operating system. The operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit this.

[0123] The interface request processing device provided in this application embodiment can achieve Figures 1 to 2 The various processes implemented in the method embodiments are not described in detail here to avoid repetition.

[0124] Based on the same technical concept, embodiments of this application also provide an electronic device for executing the aforementioned interface request processing method. Figure 4 This is a schematic diagram of the structure of an electronic device to implement various embodiments of this application. The electronic device can vary significantly due to differences in configuration or performance, and may include a processor 410, a communications interface 420, a memory 430, and a communication bus 440. The processor 410, communications interface 420, and memory 430 communicate with each other via the communication bus 440. The processor 410 can call a computer program stored in the memory 430 and executable on the processor 410 to perform the following steps:

[0125] Obtain the first interface request for the target interface; the first interface request includes multiple first request parameters, each consisting of a first parameter name and a first parameter value; for each first request parameter, perform validation processing according to pre-determined parameter validation rules to obtain a validation result; wherein, the parameter validation rules are determined based on multiple historical interface requests of the target interface; the parameter validation rules are used to validate the first parameter name, the length of the first parameter value, and the character elements contained in the first parameter value; based on the validation result, determine whether the first interface request has any anomalies.

[0126] In this embodiment, a first interface request for a target interface can be obtained. The first interface request includes multiple first request parameters, each consisting of a first parameter name and a first parameter value. For each first request parameter, the first parameter name, the length of the first parameter value, and the character elements contained in the first parameter value are validated according to parameter validation rules pre-determined based on multiple historical interface requests of the target interface, resulting in a validation result. Furthermore, based on the validation result, it is determined whether the first interface request is abnormal. Therefore, in terms of interface security protection, compared to related technologies that rely on parameter validation logic designed and maintained by technicians to identify illegal parameters in interface requests and thus identify abnormal interface requests, this technical solution eliminates the need for technicians to design parameter validation rules for the target interface. This saves on manual design and maintenance costs, avoids reliance on technicians in the parameter validation process, and reduces the difficulty of implementing parameter validation. Furthermore, since the parameter validation rules are determined based on multiple historical interface requests of the target interface, these rules enable more targeted parameter validation of request parameters in interface requests to the target interface. Additionally, this technical solution utilizes parameter validation rules to validate multiple dimensions of the request parameters (including parameter name, parameter value length, and character elements contained in the parameter value), resulting in more accurate validation results. This allows for more precise determination of whether an interface request is abnormal, facilitating accurate security protection of the target interface and enhancing its security.

[0127] The specific execution steps can be found in the various steps of the above-described interface request processing method embodiment, and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0128] It should be noted that the electronic devices in the embodiments of this application include: servers, terminals, or other devices besides terminals.

[0129] The above electronic device structure does not constitute a limitation on the electronic device. An electronic device may include more or fewer components than illustrated, or combine certain components, or arrange them differently. For example, an input unit may include a Graphics Processing Unit (GPU) and a microphone, and a display unit may use a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar display panels. User input units include at least one of a touch panel and other input devices. A touch panel is also called a touchscreen. Other input devices may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be elaborated further here.

[0130] Memory can be used to store software programs and various data. Memory can primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area can store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, memory can include volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (Synchlink DRAM, SLDRAM), and direct memory bus RAM (DRRAM).

[0131] The processor may include one or more processing units; optionally, the processor integrates an application processor and a modem processor, wherein the application processor mainly handles operations related to the operating system, user interface, and applications, while the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into the processor.

[0132] This application also provides a computer-readable storage medium for storing computer-executable instructions. When these computer-executable instructions are executed by a processor, they implement the various processes of the above-described interface request processing method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0133] The processor is the processor in the electronic device described in the above embodiments. The computer-readable storage medium is, for example, a computer read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk.

[0134] This application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described interface request processing method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0135] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-mentioned interface request processing method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0136] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0137] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0138] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0139] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for processing interface requests, characterized in that, include: Get the first API request for the target API; The first interface request includes multiple first request parameters, each of which consists of a first parameter name and a first parameter value. For each first request parameter, the first request parameter is validated according to a pre-determined parameter validation rule to obtain a validation result; wherein, the parameter validation rule is determined based on multiple historical interface requests of the target interface; the parameter validation rule is used to validate the first parameter name, the length of the first parameter value, and the character elements contained in the first parameter value; Based on the verification results, determine whether the first interface request is abnormal; For the first interface request that does not have any anomalies, add it to the history of interface requests; Before obtaining the first interface request for the target interface, the method further includes: Obtain the multiple historical interface requests for the target interface; each historical interface request includes multiple sample request parameters, which consist of sample parameter names and sample parameter values; Based on the number of times each sample parameter name appears in the multiple historical interface requests, determine the set of required parameters and the set of optional parameters corresponding to the target interface; For each sample request parameter, a first length set corresponding to the sample request parameter is determined based on the first length of the sample parameter value in the multiple historical interface requests. Based on the first set of lengths, determine the parameter length range corresponding to the sample request parameter; Determine the character elements contained in the sample parameter values ​​of the sample request parameters in the multiple historical interface requests; Based on the value range corresponding to each of the aforementioned character elements, the set of character elements corresponding to the sample request parameter is determined; wherein, the set of character elements is the union of the value ranges. Based on the set of required parameters, the set of optional parameters, the parameter length range, and the set of character elements, determine the parameter validation rules corresponding to the target interface; The step of determining the parameter length range corresponding to the sample request parameter based on the first length set includes: When all the first lengths are consistent, the left and right boundaries of the parameter length range corresponding to the sample request parameter are determined to be the first lengths. When the first lengths are inconsistent, a normality test is performed on the set of first lengths to obtain the normality test results; If the normality test result is that it conforms to a normal distribution, the parameter length range corresponding to the sample request parameter is determined based on the mean and standard deviation of the first length set. If the normality test result is that it does not conform to a normal distribution, the parameter length range corresponding to the sample request parameter is determined based on the range of the first length set.

2. The method according to claim 1, characterized in that, The step of determining the set of required parameters and the set of optional parameters corresponding to the target interface based on the number of times each sample parameter name appears in the multiple historical interface requests includes: For each sample parameter name, count the number of times the sample parameter name appears in the multiple historical interface requests; If the first number of requests is consistent with the number of requests to the multiple historical interfaces, the sample request parameter corresponding to the sample parameter name will be determined as a required parameter. If the first number of requests is inconsistent with the number of requests to the multiple historical interfaces, the sample request parameter corresponding to the sample parameter name will be determined as an optional parameter. Based on each of the required parameters, determine the set of required parameters corresponding to the target interface; and based on each of the optional parameters, determine the set of optional parameters corresponding to the target interface.

3. The method according to claim 1, characterized in that, The step of determining the parameter length range corresponding to the sample request parameter based on the mean and standard deviation of the first length set includes: The difference between the mean and three times the standard deviation is determined as the left boundary of the parameter length range; The sum of the mean and three times the standard deviation is determined as the right boundary of the parameter length range.

4. The method according to claim 1, characterized in that, Determining the parameter length range corresponding to the sample request parameter based on the range of the first length set includes: The left boundary of the parameter length range is determined based on the minimum value in the first length set and the range; The right boundary of the parameter length range is determined based on the maximum value in the first length set and the range.

5. The method according to claim 1, characterized in that, For each first request parameter, the first request parameter is validated according to a pre-determined parameter validation rule to obtain a validation result, including: Based on the first parameter name, determine whether the first request parameter belongs to the set of required parameters or the set of optional parameters; If it is determined that the first request parameter does not belong to the set of required parameters or the set of optional parameters, then it is determined that the validation of the first request parameter fails.

6. The method according to claim 5, characterized in that, After determining whether the first request parameter belongs to the set of required parameters or the set of optional parameters based on the first parameter name, the method further includes: If it is determined that the first request parameter belongs to the set of required parameters or the set of optional parameters, then it is determined whether the length of the first parameter value is within the range of the parameter length. If it is determined that the length of the first parameter value is not within the range of the parameter length, then it is determined that the validation of the first request parameter fails.

7. The method according to claim 6, characterized in that, After determining whether the length of the first parameter value is within the range of the parameter length, the method further includes: If it is determined that the length of the first parameter value is within the range of the parameter length, then it is determined whether the character element contained in the first parameter value is included in the character element set; If it is determined that the character element contained in the first parameter value is not included in the character element set, then it is determined that the validation of the first request parameter fails.

8. An interface request processing apparatus, characterized in that, include: The first acquisition module is used to acquire the first interface request for the target interface; The first interface request includes multiple first request parameters, each of which consists of a first parameter name and a first parameter value. The verification processing module is used to verify each first request parameter according to a pre-determined parameter verification rule to obtain a verification result; wherein, the parameter verification rule is determined based on multiple historical interface requests of the target interface; the parameter verification rule is used to verify the name of the first parameter, the length of the first parameter value, and the character elements contained in the first parameter value; The first determining module is used to determine whether the first interface request is abnormal based on the verification result, and to add the first interface request without abnormality to the historical interface requests. The second acquisition module is used to acquire the plurality of historical interface requests for the target interface before acquiring the first interface request for the target interface; each historical interface request includes a plurality of sample requests. The sample request parameters consist of sample parameter names and sample parameter values; The second determining module is used to determine the set of required parameters and the set of optional parameters corresponding to the target interface based on the number of times each sample parameter name appears in the multiple historical interface requests. The third determining module includes: The fourth determining unit is used to determine, for each sample request parameter, a first length set corresponding to the sample request parameter based on the first length of the sample parameter value in the plurality of historical interface requests. Based on the first set of lengths, determine the parameter length range corresponding to the sample request parameter; Determine the character elements contained in the sample parameter values ​​of the sample request parameters in the multiple historical interface requests; Based on the value range corresponding to each of the aforementioned character elements, the set of character elements corresponding to the sample request parameter is determined; wherein, the set of character elements is the union of the value ranges. Based on the set of required parameters, the set of optional parameters, the parameter length range, and the set of character elements, determine the parameter validation rules corresponding to the target interface; The fifth determining unit is used to determine that, when all the first lengths are consistent, the left and right boundaries of the parameter length range corresponding to the sample request parameter are both the first lengths. When the first lengths are inconsistent, a normality test is performed on the set of first lengths to obtain the normality test results; If the normality test result is that it conforms to a normal distribution, the parameter length range corresponding to the sample request parameter is determined based on the mean and standard deviation of the first length set. If the normality test result is that it does not conform to a normal distribution, the parameter length range corresponding to the sample request parameter is determined based on the range of the first length set.

9. An electronic device, characterized in that, include: processor; as well as A memory configured to store computer-executable instructions configured to be executed by the processor to implement the method of processing an interface request as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store computer-executable instructions, which, when executed by a processor, implement the interface request processing method as described in any one of claims 1-7.

Images