Web application API security vulnerability scanning system, scanning method and equipment

Abstract

The invention provides a web application API (Application Program Interface) security vulnerability scanning system, scanning method and equipment. The system comprises a message modeling module which is used for carrying out dimension reduction modeling on an original first request message to generate a key value pair list; the vulnerability scanning module is integrated with a plurality of mutually independent scanning sub-modules, each scanning sub-module is configured with a single different-type security vulnerability scanning function, and a request message sequence is generated after the key value pair list is subjected to multiple different-type security vulnerability scanning in sequence; the request restoring module is used for adding a legal authentication field to the request message sequence and restoring the request message sequence into a second request message; the request sending module is used for sending a second request message and obtaining a response message; the vulnerability judgment module is used for judging vulnerability types existing in the API. According to the method, a plurality of mutually independent scanning sub-modules are integrated, each scanning sub-module focuses on scanning of one type of security vulnerabilities, the types of the vulnerabilities can be accurately judged, and the comprehensiveness and accuracy of scanning are ensured.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a web application API security vulnerability scanning system, scanning method and equipment. Background Art

[0002] In recent years, with the development and promotion of advanced application architectures such as cloud-native gateways and microservices, as well as the increase in the proportion of client users, most corporate web applications have abandoned the traditional server-side rendering mode (Server-Side Rendering, SSR), that is, the back-end data and the front-end page are mixed on the server side and sent to the client together. Instead, the client-side rendering (Client-Side Rendering, CSR) mode is adopted. In this mode, the back-end server no longer generates a complete HTML page, but provides an API interface for the front-end page to call to obtain data. The front-end page asynchronously requests the back-end API (Application Programming Interface) through JavaScript code to obtain the required data, and completes the dynamic rendering of the page accordingly.

[0003] This technological evolution has focused the functions of current web applications on the interaction with back-end APIs, which means that the security of APIs directly determines the security of web applications. The automated discovery of API security vulnerabilities has also become an important topic in the field of network security. For example, the authoritative non-profit network security organization OWASP has released the top 10 API security risks.

[0004] Given the diversity and severity of API security vulnerabilities, it is particularly important to conduct comprehensive security vulnerability scanning and protection for APIs. However, existing technologies can only rely on manual experience for security testing, which can easily lead to inaccurate or incomplete vulnerability detection and fail to effectively respond to complex and changing API security threats. Summary of the invention

[0005] In view of the deficiencies in the prior art, the present invention provides a web application API security vulnerability scanning system, scanning method and device to at least solve the above technical problems existing in the prior art.

[0006] In order to achieve the above purpose and other advantages, the present invention adopts the following technical solutions:

[0007] In a first aspect, the present invention provides a web application API security vulnerability scanning system, comprising:

[0008] A message modeling module, used to perform dimensionality reduction modeling on the original first HTTP request message interacting with the web application API, and generate a corresponding key-value pair list;

[0009] A vulnerability scanning module, wherein the vulnerability scanning module is integrated with a plurality of independent scanning submodules, each of which is configured with a single different type of security vulnerability scanning function, and the vulnerability scanning module is used to sequentially perform a plurality of different types of security vulnerability scans on the key-value pair list to generate a request message sequence containing vulnerability scanning related information, wherein the vulnerability scanning related information includes: parameter change information and vulnerability scanning information;

[0010] A request restoration module, used for adding a legal authentication field to the request message sequence and restoring it into a second HTTP request message;

[0011] A request sending module, used for sending the second HTTP request message and obtaining a current response;

[0012] The vulnerability judgment module is used to judge the existence of a vulnerability in the current response according to the vulnerability judgment rules configured by the different types of security vulnerability scanning functions, and determine the vulnerability type according to the vulnerability scanning information.

[0013] According to a web application API security vulnerability scanning system provided by the present invention, each of the scanning submodules includes:

[0014] A parameter identification unit, used to identify the request parameters in the key-value pair list that can interact with the web application API through a large language model or a preset parameter identification rule;

[0015] The malicious parameter generation and replacement unit is used to generate a corresponding malicious parameter value based on a preset malicious parameter generation rule, and replace the original parameter value of the request parameter with the malicious parameter value.

[0016] According to a web application API security vulnerability scanning system provided by the present invention, the malicious parameter generation rule includes:

[0017] Generate a random number within a set range of values ​​as the malicious parameter value, and / or,

[0018] Using a preset deformation rule to deform the original parameter value of the request parameter to obtain a malicious parameter value, and / or,

[0019] Obtain from the traffic log the parameter values ​​of the authentication parameters in other request messages that are different from the first HTTP request message as malicious parameter values.

[0020] According to a web application API security vulnerability scanning system provided by the present invention, the vulnerability judgment module includes:

[0021] A reference response selection unit, configured to obtain a corresponding reference response based on a preset reference response acquisition rule;

[0022] The API vulnerability judgment unit is used to determine corresponding vulnerability judgment rules according to different types of security vulnerability scanning functions, and perform vulnerability judgment on the current response according to the vulnerability judgment rules.

[0023] According to a web application API security vulnerability scanning system provided by the present invention, the benchmark response acquisition rule includes:

[0024] using the response message corresponding to the first HTTP request message as a reference response, and / or,

[0025] Using the response message corresponding to other request messages in the traffic log whose authentication parameters are different from those of the first HTTP request message as a reference response, and / or,

[0026] Replay the first HTTP request message and use the obtained response message as a reference response.

[0027] According to a web application API security vulnerability scanning system provided by the present invention, the vulnerability judgment rules include:

[0028] The output of the matching error and / or the matching sensitive field caused by the triggering API error, and / or,

[0029] Setting a similarity threshold, comparing the current response with the reference response for similarity, if the obtained similarity is greater than or equal to the similarity threshold, determining that there is a vulnerability, if the obtained similarity is less than the similarity threshold, determining that there is no vulnerability, and / or,

[0030] Monitor the sensitive data position in the current response, and determine whether the parameter change information appears in the sensitive data position. If so, determine that there is a vulnerability; if not, determine that there is no vulnerability.

[0031] According to a web application API security vulnerability scanning system provided by the present invention, the first HTTP request message includes: a request line, a request header and a request body, and the message modeling module is specifically used for:

[0032] For the request line and the request header, directly convert them into a first key-value pair;

[0033] For the request body with a hierarchical structure, during the dimensionality reduction process, each nested level in the request body is represented by its key in the form of a hierarchical path, and the hierarchical path is composed of the upper key name connected to the key name of the current level through a specific hierarchical symbol, and finally the corresponding key value is obtained to form a second key-value pair, and then the different second key-value pairs are formed into a key-value pair list, and finally the first key-value pair is merged into the key-value pair list.

[0034] According to a web application API security vulnerability scanning system provided by the present invention, the request restoration module includes:

[0035] An authentication field adding unit is used to detect whether the authentication field in the request message sequence is expired. If it is an expired authentication field, the expired authentication field is used to generate a non-expired authentication field, or a corresponding web application process is executed to obtain a non-expired authentication field;

[0036] The request message restoration unit is used to traverse each element in the request message sequence, split it into hierarchical paths and corresponding values ​​according to hierarchical symbols, create keys in the JSON object layer by layer according to the hierarchical path, and assign the final value to the key pointed to by the path, thereby constructing the second HTTP request message that conforms to the request message format.

[0037] According to a web application API security vulnerability scanning system provided by the present invention, the system also includes: a message preprocessing module, which is used to clean and deduplicate the first HTTP request message to remove data irrelevant to API interaction.

[0038] In a second aspect, the present invention provides a scanning method based on any one of the web application API security vulnerability scanning systems described above, the method comprising:

[0039] Perform dimensionality reduction modeling on the original first HTTP request message interacting with the web application API to generate a corresponding key-value pair list;

[0040] The key-value pair list is sequentially subjected to a plurality of different types of security vulnerability scans to generate a request message sequence containing vulnerability scanning related information, wherein the vulnerability scanning related information includes: parameter change information and vulnerability scanning information;

[0041] Adding a legal authentication field to the request message sequence and restoring it into a second HTTP request message;

[0042] Send the second HTTP request message and obtain the current response;

[0043] The vulnerability existence of the current response is judged according to the vulnerability judgment rules configured by the different types of security vulnerability scanning functions, and the vulnerability type is determined according to the vulnerability scanning information.

[0044] In a third aspect, the present invention provides an electronic device, the electronic device comprising:

[0045] One or more processors; and a memory storing computer program instructions, wherein when the computer program instructions are executed, the processor executes the web application API security vulnerability scanning method as described above.

[0046] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program / instruction stored thereon, wherein the computer program / instruction, when executed by a processor, implements the web application API security vulnerability scanning method as described above.

[0047] In a fifth aspect, the present invention provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the web application API security vulnerability scanning method as described above.

[0048] The present invention provides a web application API security vulnerability scanning system, scanning method and device, the system integrates multiple independent scanning submodules, each scanning submodule focuses on a type of security vulnerability scanning, and this modular design ensures the comprehensiveness of the scan. Since each scanning submodule is independent, specific scanning functions can be easily added or removed as needed, which enhances the flexibility and scalability of the system, and enables the system to be continuously updated and improved as the web application API security threats change. The present invention can automatically scan the API of a web application for security vulnerabilities, and can accurately determine the type of vulnerability that exists by combining dynamic vulnerability scanning and sophisticated vulnerability judgment rules, greatly improving the efficiency and accuracy of vulnerability detection, and providing strong support for subsequent vulnerability repair. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0050] Figure 1 It is a structural diagram of a web application API security vulnerability scanning system provided by an embodiment of the present invention;

[0051] Figure 2It is a flowchart of a web application API security vulnerability scanning method provided by an embodiment of the present invention;

[0052] Figure 3 It is a detailed flow chart of a web application API security vulnerability scanning method provided by an embodiment of the present invention;

[0053] Figure 4 It is a structural schematic diagram of the electronic device provided by this application. DETAILED DESCRIPTION

[0054] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the following specifically cites a preferred embodiment and describes it in detail with the accompanying drawings as follows.

[0055] It should be noted that it is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in the present invention can be combined with other embodiments without conflict. Unless otherwise defined, the technical terms or scientific terms involved in the present invention should be the usual meanings understood by people with ordinary skills in the technical field to which the present invention belongs. The words "one", "a", "a", "the" and the like involved in the present invention do not indicate a quantitative limitation and may represent the singular or plural. The terms "including", "comprising", "having" and any of their variations involved in the present invention are intended to cover non-exclusive inclusions; the terms "first", "second", "third", etc. involved in the present invention are merely to distinguish similar objects and do not represent a specific ordering of objects.

[0056] As a core component of modern web applications, API is of vital importance for its security and stability. As a pure web application interface for adding, deleting, modifying and checking backend data, it is still threatened by traditional web application API security vulnerabilities such as traditional code injection and server-side request forgery. The prior art mainly relies on three types of vulnerability scanners for the automated discovery of web application API security vulnerabilities: SAST (Static Application Security Testing) for scanning source code, DAST (Dynamic Application Security Testing) for directly sending security vulnerability test requests to the target to observe whether the expected response appears, and IAST (Interactive Application Security Testing) for real-time monitoring of the data flow during application runtime to detect vulnerabilities. However, in the scenario of automated mining of API security vulnerabilities, DAST is the most direct and intuitive vulnerability detection. Since API is flexible and changeable, each API path is different, and the parameters sent to the backend server are also different, manually written scanning rules can never cover such a variety of scenarios, making traditional DAST tools seem incapable of API security testing. In view of this, the present invention provides a web application API security vulnerability scanning system, scanning method and device to at least solve the above technical problems existing in the prior art.

[0057] Embodiment 1

[0058] Reference Figure 1 As shown, an embodiment of the present invention provides a web application API security vulnerability scanning system, including:

[0059] The message modeling module 1 is used to perform dimensionality reduction modeling on the original first HTTP request message interacting with the web application API and generate a corresponding key-value pair list.

[0060] In this embodiment, the first HTTP request message includes: a request line, a request header and a request body, and the message modeling module 1 is specifically used for:

[0061] For request lines and request headers, directly convert them into the first key-value pair;

[0062] For a request body with a hierarchical structure, during the dimensionality reduction process, each nested level in the request body is represented by its key in the form of a hierarchical path. The hierarchical path is composed of the upper key name connected to the key name of the current level through a specific hierarchical symbol, and finally the corresponding key value is obtained to form a second key-value pair, and then the different second key-value pairs are formed into a key-value pair list, and finally the first key-value pair is merged into the key-value pair list.

[0063] Specifically, the message modeling module 1 reduces the dimension of each original request for interacting with the web application API from a complex HTTP message to a key-value pair list containing all the information of the original complex hierarchical structure.

[0064] For example, the HTTP request message is as follows:

[0065] "POST / api / test?aaa=bbb HTTP / 1.1

[0066] HOST:www.test.com

[0067] Cookie:Web-Token=123456789

[0068] {"user":{"name":"bob","phone":{"mobile":"1333333333","telephone":"123456"}}}"

[0069] For the more complex HTTP request message mentioned above, it contains three types of information: request line, request header and request body. For the HTTP method POST inherent in the request line, the request path / api / test, etc., these components do not require additional modeling operations. For the request header part, such as the two request headers HOST and Cookie, their expression is already in the form of key-value pairs in the original HTTP message, and no additional processing is required, and they are directly saved as the first key-value pair. What needs to be processed for data dimensionality reduction is the part of the message containing parameters, that is, the request query part "? aaa=bbb" and the parameter part in the request body:

[0070] {"user":{"name":"bob","phone":{"mobile":"1333333333","telephone":"123456"}}}.

[0071] The query part of the request, that is, the part "?aaa=bbb", can be regarded as sending the parameter aaa to the server, and the corresponding parameter value of this parameter is bbb, and its data is saved in the first key-value pair. Since the structure of the request body is much more complex than the request query, only the request body is used as an example for detailed description. Although the request body is a JSON structure with several layers of nesting, it is one-dimensional at the logical level. For example, the key-value pair "mobile": "1333333333" can be regarded as "the value of mobile of user's phone is 1333333333", then the hierarchical path of the value 1333333333 at the level of the entire request body can be expressed as user->phone->mobile to form the key name of the current level, where the hierarchical symbol is set to "->", and other symbols can also be used as the hierarchical symbol. Then for "user's name", the key-value pair formed is user->name:bob. For "user's phone's mobile", the second key-value pair is user->phone->mobile:1333333333. For "user's phone's telephone", the second key-value pair is user->phone->telephone:123456. This way, the request body can be reduced to a list of key-value pairs as shown below:

[0072] user->name:bob

[0073] user->phone->mobile:1333333333

[0074] user->phone->telephone:123456

[0075] This key-value pair list itself already contains the hierarchical information in the original JSON structure, the key names of each level, and the corresponding key values.

[0076] Therefore, reducing the dimension of the HTTP request message into a list of key-value pairs can, on the one hand, be used to modify the composition of the original complex request structure through simple string replacement, thereby realizing parameter modification on the HTTP request of the benchmark web application API; on the other hand, as verified by testing, compared with the original request message, the one-dimensional key-value pair list, the large language model is more likely to identify the function of the parameters in the key-value pair list, and it is easier to give full play to the ability of the large language model in natural language processing, which is conducive to the subsequent positioning of parameters of the specified vulnerability types that are prone to occur.

[0077] Vulnerability scanning module 2, vulnerability scanning module 2 integrates multiple independent scanning sub-modules 21, each scanning sub-module 21 is configured with a single different type of security vulnerability scanning function, vulnerability scanning module 2 is used to perform multiple different types of security vulnerability scans on the key-value pair list in sequence to generate a request message sequence containing vulnerability scanning related information, vulnerability scanning related information includes: parameter change information, vulnerability scanning information.

[0078] The present invention can distribute the scanning functions of different types of security vulnerabilities to different scanning submodules 21. These scanning submodules 21 do not overlap with each other and are independent of each other, and all scanning submodules 21 together constitute a vulnerability scanning module 2. A plurality of different types of security vulnerability scans are performed on the key-value pair list in sequence to generate a request message sequence containing vulnerability scanning related information. Vulnerability scanning related information includes: parameter change information and vulnerability scanning information. Parameter change information refers to any modification or adjustment made by the scanning module to the key-value pairs in the original request during the vulnerability scanning process. Based on the parameter change information, the subsequent system can accurately locate the parameters with vulnerabilities. Vulnerability scanning information refers to the information of the security vulnerability scanning function possessed by each scanning submodule corresponding to scanning different HTTP request messages.

[0079] Scanning functions for different types of security vulnerabilities, such as IDOR (Insecure Direct Object Reference) vulnerability scanning, SSRF (Server-Side RequestForgery) vulnerability scanning, arbitrary URL jump vulnerability scanning, BOLA (Broken Object Level Authorization) vulnerability scanning, security configuration error vulnerability scanning, unrestricted access to sensitive business flow vulnerability scanning, authentication failure vulnerability scanning, object attribute level authorization failure scanning, function level authorization failure scanning, etc.

[0080] In this embodiment, each scanning submodule 21 includes:

[0081] The parameter identification unit 211 is used to identify the request parameters that can interact with the web application API in the key-value pair list through a large language model or a preset parameter identification rule.

[0082] The parameter identification unit 211 may be configured with two parameter identification methods: Method 1: Using a large language model to identify request parameters of a web application API that may have vulnerabilities and needs to be scanned.

[0083] Specifically, we take IDOR vulnerability scanning as an example to explain how to use a large language model to identify parameters that need to be scanned. For IDOR vulnerabilities, the parameters that are prone to this type of vulnerability are often the index of the object, such as using the user id parameter (the parameter name is generally userid) to query (this behavior is a reference) the sensitive information of the user (that is, the object here). When the above vulnerability scenario exists, you only need to replace the userid submitted to the backend in the request message with other users to query the sensitive information of other users, which leads to unauthorized references. Therefore, the key point of this vulnerability type is to identify the index parameters of the object and replace the identified parameters with parameter values. However, this is also the biggest difficulty in the entire vulnerability scanning process, because of the diversity of parameter naming and parameter value formats, only format matching from parameter names or parameter values ​​will produce a large number of false positives and false negatives. However, the large language model itself has the ability to understand semantics and recognize intent, so the ability of the large language model can be used to allow it to more effectively identify the index parameters of the object based on the name of the parameter. In this way, the subsequent scanning logic can perform parameter replacement replay scanning on the index parameters of the objects identified by the large language model. That is, after replacing the parameter value, the scanning logic will resend the request to the server and observe the server's response. By comparing the server responses under different parameter values, the scanning logic can determine whether there is an IDOR vulnerability. If after replacing the parameter value, the server returns data that should not be accessed by the current user (such as sensitive information of other users), then it means that an IDOR vulnerability exists.

[0084] For example, by reducing the dimension of HTTP request messages into a list of key-value pairs, even a large language model that has not been fine-tuned can recognize the index parameters of an object through appropriate system prompts. For example, the following prompts can be used to select parameters that are vulnerable to IDOR vulnerabilities:

[0085] “Definitions and Task:

[0086] Object Entity: An abstract structure composed of multiple attributes, such as Userwith attributes like userId, userName, userBio, etc.

[0087] Object Entity Index: An attribute used for quick querying or manipulation of an object entity, typically a short and unique value, likeuserId, userName, userEmail.

[0088] Non-Index Types:

[0089] Long text (descriptive text)

[0090] Links

[0091] Short numeric identifiers or classifications(eg,xxxType)

[0092] Task:As a parameter processing assistant, identify all object entity indices from the given parameter names and values ​​based on the above definitions.”

[0093] Similarly, when facing other types of vulnerabilities, you can also combine the meaning of the parameters at the natural language level to determine whether a specific type of vulnerability is matched for scanning. The large language model has deep semantic understanding capabilities and its ability to process natural language and unstructured data helps the model accurately understand the complex logical relationships in API interfaces and request parameters during the scanning process.

[0094] Method 2: Edit custom parameter identification rules to match parameters, such as matching all parameters whose parameter values ​​conform to the URL format. The URL format usually includes the protocol part (such as http: / / or https: / / ), domain name or IP address, path, query string, etc. When defining matching rules, regular expressions or other matching rules can be constructed based on these components. First, all parameters in the HTTP request message are captured by parsing the key-value pair list. For each captured parameter value, the previously defined matching rule (such as regular expression) is applied to determine whether it conforms to the URL format. If the parameter value conforms to the URL format, it can be processed accordingly according to the test requirements, such as recording the parameter, marking it as a potential risk point, etc. Therefore, through the above two parameter identification methods, testers can flexibly identify parameters according to specific application scenarios and security requirements, and can quickly adapt to changing application scenarios and security threats.

[0095] The malicious parameter generation and replacement unit 212 is used to generate corresponding malicious parameter values ​​based on preset malicious parameter generation rules, and replace the original parameter values ​​of the request parameters with the malicious parameter values.

[0096] In this embodiment, the malicious parameter generation rules include:

[0097] Generate a random number within a set range of values ​​as the malicious parameter value, and / or,

[0098] Using a preset deformation rule to deform the original parameter value of the request parameter to obtain a malicious parameter value, and / or,

[0099] The parameter values ​​in other request messages whose authentication parameters are different from those in the first HTTP request message are obtained from the traffic log as malicious parameter values.

[0100] Specifically, the malicious parameter generation and replacement unit 212 can be configured with three malicious parameter generation methods. Method 1: Generate a random number within a set numerical range as a malicious parameter value, such as generating a random number below 100 (for example only, not representing the actual vulnerability scanning mode). Method 2: Use a preset deformation rule to deform the original parameter value of the request parameter. Since the original parameter value is retained in the key-value pair list, this parameter value can be deformed and then replaced back as a new parameter value. Deformation rules such as numerical increase and decrease, character replacement, format adjustment, etc., generate a series of new parameter values ​​that are associated with the original parameter value but have differences. For example, if the original parameter value is 202400822-01923, then new parameter values ​​such as 202400821-01921 and 202400822-01811 can be generated. Method 3: Obtain the corresponding parameter value from the traffic log to distinguish other request messages. Since the key-value pair list after dimensionality reduction retains the hierarchical information of the parameters, although other request messages are different from the HTTP request messages used for dimensionality reduction modeling, the message selection will not be random, but based on different rules, such as selecting a request message with different authentication parameters (different from the user of the request message for dimensionality reduction modeling, such as selecting request messages generated by other different users).

[0101] The following is an example of the design of several scanning submodules and their corresponding functional logic:

[0102] IDOR vulnerability scanning submodule: the parameter identification mode of the parameter identification unit 211 is configured as: priority mode 1, second mode 2; the malicious parameter generation mode of the malicious parameter generation and replacement unit 212 is configured as mode 3.

[0103] SSRF vulnerability scanning submodule: the parameter identification method of the parameter identification unit 211 is configured as: priority method one, followed by method two; the malicious parameter generation method of the malicious parameter generation and replacement unit 212 is configured as method two.

[0104] Arbitrary URL jump vulnerability scanning submodule: the parameter identification mode of the parameter identification unit 211 is configured as: priority mode 1, second mode 2; the malicious parameter generation mode of the malicious parameter generation and replacement unit 212 is configured as mode 2.

[0105] The system integrates multiple independent scanning submodules, each of which focuses on scanning a type of security vulnerability. This modular design ensures comprehensive scanning and can cover more types of security vulnerabilities. Moreover, since each scanning submodule is independent, specific scanning functions can be easily added or removed as needed, enhancing the flexibility and scalability of the system. This allows the system to be continuously updated and improved as security threats change.

[0106] The request restoration module 3 is used to add a legal authentication field to the request message sequence and restore it into a second HTTP request message.

[0107] In this embodiment, the request restoration module 3 includes:

[0108] The authentication field adding unit 31 is used to detect whether the authentication field in the request message sequence is expired. If it is an expired authentication field, the expired authentication field is used to generate a non-expired authentication field, or the corresponding web application process is executed to obtain a non-expired authentication field.

[0109] It should be noted that the HTTP protocol itself contains a lot of information transmitted to the backend, such as the following HTTP message:

[0110] "POST / api / test?aaa=bbb HTTP / 1.1

[0111] HOST:www.test.com

[0112] Cookie:Web-Token=123

[0113] {“ccc”:”ddd”}”

[0114] The request header of this request message contains the Cookie field, whose content is a set of key-value pairs. The Cookie field is also the "authentication field" used by most Web applications. The value of this field will be regarded as a unique user identity in the backend of the Web application. For example, if the value of the Cookie field is Web-Token = 123, and in the backend of the Web application, this Web-Token = 123 actually corresponds to a real user a, then this request will be regarded as issued by user a, and this request is also eligible to access user a's resources, such as user a's ID number and other sensitive information.

[0115] It should be noted that the location of the authentication field is not always consistent in different Web applications. For example, some applications use the request header Authorization to transmit the authentication field. However, for all API requests of the same Web application, the location of the authentication field is consistent, so it is easy to set the authentication information for the API request of a specific Web application. At the same time, when processing API requests, Web applications usually verify whether the authentication field is legal and expired. Illegal API requests are directly intercepted and will not trigger the real function of the API. Therefore, in order to conduct effective vulnerability scanning, it is necessary to add a usable legal authentication field to the HTTP request message to avoid being intercepted by the application's security mechanism during the scanning process.

[0116] Therefore, before sending a request and getting a response, first test whether the authentication field in the request message is legal and available. As mentioned above, the authentication fields of all APIs in the same web application are universal, so a most basic API request (different from the API request that needs to be scanned) can be used to make a legal authentication judgment. If the authentication is legal, the JSON format is returned, and if it is illegal, a fixed intercept response is returned. Therefore, the authentication field in this API request is added to determine whether the request is rejected. If it is rejected, it means that the authentication field in the request message has expired. The authentication field adding unit 31 can use the following two methods to generate an unexpired authentication field. Method 1: Use an expired authentication field to generate an unexpired field. For example, a Web application with an automatic renewal mechanism is used. When it is detected that the authentication field used by the user has expired, the Web application interface is called with the expired authentication field, and a new, unexpired authentication field will be automatically generated for the user. This method allows the two authentication fields to point to the same user, and the user identity consistency is stronger. Method 2: The request restoration module 3 has a built-in automated authentication field generation tool, which is used to simulate a specific web application process (such as a login process) to obtain a legal and unexpired authentication field. The above method can automatically obtain and update authentication credentials, and can stably and reliably obtain valid authentication fields when executing the authentication process.

[0117] The request message restoration unit 32 is used to traverse each element in the request message sequence, split it into hierarchical paths and corresponding values ​​according to hierarchical symbols, create keys in the JSON object layer by layer according to the hierarchical path, and assign the final value to the key pointed to by the path, thereby constructing a second HTTP request message that conforms to the request message format.

[0118] Specifically, the request message restoration unit 32 processes the elements in the request message sequence one by one, and these elements are usually represented by a certain hierarchical structure (such as a key-value pair). Each key-value pair is split according to the hierarchical symbol "->" to form a hierarchical path and a corresponding value. The hierarchical path represents the position of the value in the final JSON object, and the value is the data that should be assigned to the position. The restoration can be performed by executing the following pseudo code in a traversal manner, such as restoring the JSON structure of "user's name":

[0119] body = {}

[0120] body["user"] = {}

[0121] body["user"]["name"]="bob"

[0122] In this way, a JSON structure such as {"user":{"name":"bob"}} is restored. The restoration of other parameters can be executed according to this logic, and there is no need to repeat it. Then add the request line and request header to form a second HTTP request message that conforms to the request message format.

[0123] During the implementation process, the request restoration module 3 ensures that each request contains a legal and valid authentication field, and finally restores these processed messages to messages in the standard HTTP request format, so that all information in the original HTTP request message can be completely restored, supporting lossless restoration of data.

[0124] The request sending module 4 is used to send a second HTTP request message and obtain a current response. For example, the second HTTP request message is encapsulated into a standard HTTP request message format, i.e., a text-formatted request message, using Python's requests library. Then, a RequestSender instance is created through the requests library, and after sending a POST request for the second HTTP request message, a response message is obtained as the current response.

[0125] The vulnerability judgment module 5 is used to perform vulnerability judgment on the current response according to the vulnerability judgment rules configured by different types of security vulnerability scanning functions to determine the type of vulnerability existing in the API.

[0126] In this embodiment, the vulnerability judgment module 5 includes:

[0127] The reference response selection unit 51 is used to obtain a corresponding reference response based on a preset reference response acquisition rule.

[0128] In this embodiment, the benchmark response acquisition rules include:

[0129] Using the response message corresponding to the first HTTP request message as a reference response, and / or,

[0130] Using the response message corresponding to other request messages in the traffic log whose authentication parameters are different from the first HTTP request message as the reference response, and / or,

[0131] The first HTTP request message is replayed, and the obtained response message is used as a reference response.

[0132] Specifically, the benchmark response selection unit 51 can be configured with three benchmark response acquisition methods. Method 1: Use the response message corresponding to the original HTTP request message (i.e., the HTTP request message used for dimensionality reduction modeling) as the benchmark response. Method 2: When using the traffic log to obtain parameters, use the response message corresponding to other request messages in the traffic log whose authentication parameters are different from the original HTTP request message as the benchmark response. Method 3: Replay the original HTTP request message without making any changes, and use the obtained response message as the benchmark response.

[0133] For the IDOR vulnerability scan type, the baseline response acquisition rule is configured as method 2; for the SSRF vulnerability scan type, the baseline response acquisition rule is configured as method 1; for the arbitrary URL jump vulnerability scan type, because the current response message is not used, the baseline response acquisition rule configuration is not performed.

[0134] The API vulnerability judgment unit 52 is used to judge the existence of a vulnerability in the current response according to the vulnerability judgment rules configured by different types of security vulnerability scanning functions, and determine the vulnerability type according to the vulnerability scanning information.

[0135] In this embodiment, the vulnerability judgment rules include:

[0136] The output of the matching error and / or the matching sensitive field caused by the triggering API error, and / or,

[0137] Set a similarity threshold, compare the current response with the benchmark response, if the obtained similarity is greater than or equal to the similarity threshold, it is determined that there is a vulnerability, if the obtained similarity is less than the similarity threshold, it is determined that there is no vulnerability, and / or,

[0138] Monitor the sensitive data location in the current response and determine whether the parameter change information appears in the sensitive data location. If so, it is determined that a vulnerability exists; if not, it is determined that no vulnerability exists.

[0139] Specifically, the API vulnerability judgment unit 52 can be configured with three vulnerability judgment rules. The first vulnerability judgment rule can be regarded as a general rule, which is used to detect common unexpected outputs in API responses that may cause security risks. Since the changes in parameter values ​​when changing the request message are often beyond the expectations of the design itself, there is a high probability that an API error may be triggered to cause unexpected outputs, so such general rules are configured to cover such scenarios. These general rules include but are not limited to: matching error outputs, matching sensitive field outputs such as passwords, etc. For example, the following response content:

[0140] {"error":"Can't connectto Mysql serverwithpasswordtest123456"}

[0141] Such output is due to an error in the backend (a large part of which is caused by unexpected request parameters), and the error message is output to the API response message, resulting in the leakage of passwords. Configuring this general rule can effectively avoid leaking sensitive information or exposing system vulnerabilities.

[0142] The second vulnerability judgment rule is response comparison, which is to compare whether the response of the current request (hereinafter referred to as the current response) is the same as the baseline response. In the actual environment, various invisible characters, parameter display order, etc. will make the current response and the baseline response impossible to be the same, so in actual execution, the current response and the baseline response are compared by similarity. According to the actual application scenario and security requirements, a similarity threshold is set. When the similarity is greater than or equal to this threshold, the response is considered to be similar, which means that the API does not generate abnormal responses due to potential security vulnerabilities. Otherwise, it indicates that there is a significant difference between the current response and the baseline response. For IDOR vulnerability scanning type and SSRF vulnerability scanning type, the second vulnerability judgment rule can be used to judge the existence of vulnerabilities.

[0143] The third vulnerability judgment rule is to monitor the location of sensitive data and determine whether there is a vulnerability. Take the arbitrary URL jump vulnerability scanning type as an example. This type of vulnerability means that if the target URL is not fully verified and restricted, the attacker can use this to redirect the user to a malicious external site, thereby conducting phishing attacks, session hijacking or other malicious behaviors. Therefore, monitor the sensitive data location in the current response (such as the response header), extract the URL that appears in the Location field of the response header, and determine whether the URL has the malicious redirection target configured in the parameter change information. If it exists, it is determined that there is a vulnerability. If not, it is determined that there is no vulnerability. The malicious redirection target refers to any external URL that is different from the currently set web application domain name.

[0144] For confirmed vulnerabilities, the vulnerability judgment module 5 will determine the specific type of vulnerability based on the vulnerability scanning information marked by the vulnerability scanning module 2 on different HTTP request messages. Once the vulnerability type is determined, the vulnerability judgment module 5 will also generate a detailed vulnerability report. This vulnerability report will include information such as the type, description, impact range, severity, reproduction steps, and repair suggestions of the vulnerability. This information is crucial for the development team and can help the team quickly locate and repair vulnerabilities.

[0145] In this embodiment, the system also includes: a message preprocessing module (not shown in the figure), which is used to clean and deduplicate the first HTTP request message to remove data that is not related to the API interaction. The message preprocessing module checks the various fields in the HTTP request message and removes data that is not directly related to the API interaction. For example, some unnecessary request headers, query parameters, or irrelevant fields in the request body are removed. The purpose is to filter out data that is irrelevant or redundant to the API interaction, so that the request message used for dimensionality reduction modeling can truly represent the real function of interacting with the API.

[0146] Embodiment 2

[0147] Reference Figure 2 As shown, the embodiment of the present invention also provides a scanning method of the web application API security vulnerability scanning system based on the above embodiment 1, the method comprising:

[0148] Step S1: Perform dimensionality reduction modeling on the original first HTTP request message interacting with the web application API to generate a corresponding key-value pair list;

[0149] Step S2: performing multiple different types of security vulnerability scans on the key-value pair list in sequence to generate a request message sequence containing vulnerability scanning related information, wherein the vulnerability scanning related information includes: parameter change information and vulnerability scanning information;

[0150] Step S3: adding a legal authentication field to the request message sequence and restoring it into a second HTTP request message;

[0151] Step S4: Send a second HTTP request message and obtain a response message;

[0152] Step S5: Perform vulnerability judgment on the response message according to the vulnerability judgment rules configured for different types of security vulnerability scanning functions, and determine the vulnerability type according to the vulnerability scanning information.

[0153] Those skilled in the art will appreciate that, in the above method of specific implementation, the order in which the steps are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of the steps should be determined by their functions and possible internal logic.

[0154] Specifically, based on Figure 1 The system logic framework shown is consistent with Figure 2 The execution flow shown in the figure ensures the implementation of the above vulnerability scanning method. Figure 3 As shown in the figure, the execution process of vulnerability scanning is briefly described.

[0155] First, you need to obtain the original HTTP request message and HTTP response message that interact with the web application API. The HTTP response message can be used as a benchmark response for subsequent response comparison. The request message and response message can be extracted from the enterprise's network gateway or API gateway. Gateway logs, or network traffic mirroring technology can be used to copy the real-time traffic of the API for security analysis without affecting actual business. Then, these original HTTP request messages need to be cleaned and deduplicated to remove data that is not related to API interaction, so that the request message used for dimensionality reduction modeling can truly reflect the function of interacting with the API.

[0156] After cleaning and deduplication, the request message is modeled using the aforementioned dimensionality reduction modeling method to form a key-value pair list. The key-value pair list is sent to the scanning module, and each vulnerability scanning submodule is called in turn, such as the IDOR vulnerability scanning submodule, the SSRF vulnerability scanning submodule, the arbitrary URL jump vulnerability scanning submodule, and a series of vulnerability scanning submodules. The vulnerability scanning submodule identifies the parameters of the corresponding vulnerability through a large language model or parameter recognition rules, and then replaces these parameter values ​​with parameter values ​​used to verify the specified vulnerability type. Perform a series of operations such as parameter recognition and malicious parameter replacement to generate a request message sequence carrying parameter change information and vulnerability scanning information. Add a legal authentication field to the request message sequence and restore it to a message in the standard HTTP request format.

[0157] These request messages with replaced parameter values ​​will be sent to the unified request sending module, which will send the request message to the API and get the current response. The current response will be matched with the vulnerability judgment rules maintained by the system to determine whether the current response meets the conditions for the existence of a vulnerability, and the vulnerability type will be determined based on the vulnerability scanning information.

[0158] The implementation process of the above method is detailed in the implementation process of the system, which will not be repeated here.

[0159] In summary, the web application API security vulnerability scanning system and vulnerability scanning method provided by the present invention integrate multiple independent scanning sub-modules, each scanning sub-module focuses on scanning a type of security vulnerability. This modular design ensures the comprehensiveness of the scan. Since each scanning sub-module is independent, specific scanning functions can be easily added or removed as needed, which enhances the flexibility and scalability of the system, allowing the system to be continuously updated and improved as the web application API security threats change. The present invention can automatically scan the API of a web application for security vulnerabilities, and can accurately determine the type of vulnerability that exists by combining dynamic vulnerability scanning and sophisticated vulnerability judgment rules, greatly improving the efficiency and accuracy of vulnerability detection, and providing strong support for subsequent vulnerability repairs.

[0160] In addition, some embodiments of the present application also provide an electronic device. The electronic device may be a digital computer in various forms, such as a laptop computer, a desktop computer, a workbench, a personal digital assistant, a server, a blade server, a mainframe computer, etc. The electronic device may also be a mobile device in various forms, such as a personal digital processing, a cellular phone, a smart phone, a wearable device, and other similar computing devices.

[0161] The electronic device includes: one or more processors; and a memory storing computer program instructions, wherein when the computer program instructions are executed, the processor executes the web application API security vulnerability scanning method provided by any one or more of the above embodiments. Figure 4 An exemplary structural diagram of the electronic device is disclosed. Figure 4 As shown, the electronic device includes: one or more processors 1101, memory 1102, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Among them, the components shown in this article, their connections and relationships, and their functions are only used as examples, and are not intended to limit the implementation of the present application described and / or required herein.

[0162] The electronic device may further include: an input device 1103 and an output device 1104. The processor 1101, the memory 1102, the input device 1103 and the output device 1104 may be connected via a bus or other means. Figure 4 The example of connecting through bus is taken in the following.

[0163] The input device 1103 can receive input digital or character information, and generate key signal input related to the user settings and function control of the electronic device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator rod, one or more mouse buttons, a trackball, a joystick and other input devices. The output device 1104 may include a display device, an auxiliary lighting device (e.g., LED, Light-Emitting Diode, light-emitting diode) and a tactile feedback device (e.g., a vibration motor), etc. The display device may include, but is not limited to, a liquid crystal display (LCD, Liquid Crystal Display), a light-emitting diode (LED) display and a plasma display. In some embodiments, the display device may be a touch screen.

[0164] In order to provide interaction with the user, the electronic device may be a computer. The computer has: a display device (e.g., a CRT (Cathode-Ray Tube) or LCD (Liquid Crystal Display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or a trackball), through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0165] In the embodiments of the present application, a computer program / instruction is stored on a computer-readable medium, and when the computer program / instruction is executed by a processor, the web application API security vulnerability scanning method provided by any one or more of the above embodiments is implemented. The computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently without being assembled into the device. The above computer-readable medium carries one or more computer-readable instructions.

[0166] The memory 1102 can be used as a non-transient computer-readable storage medium, which can be used to store non-transient software programs, non-transient computer executable programs and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transient software programs, instructions and modules stored in the memory 1102, so as to implement the program instructions / modules corresponding to the method provided by any one or more embodiments in the embodiments of the present application.

[0167] The memory 1102 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 1102 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 1102 may optionally include a memory remotely arranged relative to the processor 1101, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0168] It should be noted that more specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0169] Computer readable storage media include permanent and non-permanent, removable and non-removable media, and can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, modules of programs or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0170] Computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on the remote computer, or completely on the remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0171] In the above-described embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. For example, it can be implemented by using a dedicated integrated circuit (ASIC, Application-Specific Integrated Circuit), a general-purpose computer or any other similar hardware device. In certain embodiments, the software program of the present application can be executed by a processor to implement the above steps or functions. Similarly, the software program of the present application (including related data structures) can be stored in a computer-readable recording medium, for example, a RAM memory, a magnetic or optical drive or a floppy disk and similar devices. In addition, some steps or functions of the present application can be implemented by hardware, for example, as a circuit that cooperates with a processor to perform each step or function.

[0172] The computer program product provided in the embodiment of the present application includes one or more computer programs / instructions, and when the computer program / instructions are executed by the processor, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from a computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL, Digital Subscriber Line)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integrations. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state hard disk solid state disk, SSD), etc.

[0173] The flow chart or block diagram in the accompanying drawings shows the possible architecture, function and operation of the equipment, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated system for hardware that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0174] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily mention changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims, and the above embodiments should be regarded as exemplary and non-restrictive.

Claims

1. A web application API security vulnerability scanning system, characterized in that: include: A message modeling module, used to perform dimensionality reduction modeling on the original first HTTP request message interacting with the web application API, and generate a corresponding key-value pair list; A vulnerability scanning module, wherein the vulnerability scanning module is integrated with a plurality of independent scanning submodules, each of which is configured with a single different type of security vulnerability scanning function, and the vulnerability scanning module is used to sequentially perform a plurality of different types of security vulnerability scans on the key-value pair list to generate a request message sequence containing vulnerability scanning related information, wherein the vulnerability scanning related information includes: parameter change information and vulnerability scanning information; A request restoration module, used to add a legal authentication field to the request message sequence and restore it into a second HTTP request message; A request sending module, used for sending the second HTTP request message and obtaining a current response; The vulnerability judgment module is used to judge the existence of a vulnerability in the current response according to the vulnerability judgment rules configured by the different types of security vulnerability scanning functions, and determine the vulnerability type according to the vulnerability scanning information.

2. The web application API security vulnerability scanning system according to claim 1, characterized in that: Each of the scanning submodules comprises: A parameter identification unit, used to identify the request parameters in the key-value pair list that can interact with the web application API through a large language model or a preset parameter identification rule; The malicious parameter generation and replacement unit is used to generate a corresponding malicious parameter value based on a preset malicious parameter generation rule, and replace the original parameter value of the request parameter with the malicious parameter value.

3. The web application API security vulnerability scanning system according to claim 2, characterized in that: The malicious parameter generation rules include: Generate a random number within a set range of values ​​as the malicious parameter value, and / or, Using a preset deformation rule to deform the original parameter value of the request parameter to obtain a malicious parameter value, and / or, Obtain from the traffic log the parameter values ​​of the authentication parameters in other request messages that are different from the first HTTP request message as malicious parameter values.

4. The web application API security vulnerability scanning system according to claim 1, characterized in that: The vulnerability judgment module includes: A reference response selection unit, configured to obtain a corresponding reference response based on a preset reference response acquisition rule; The API vulnerability judgment unit is used to determine corresponding vulnerability judgment rules according to different types of security vulnerability scanning functions, and perform vulnerability judgment on the current response according to the vulnerability judgment rules.

5. The web application API security vulnerability scanning system according to claim 4, characterized in that: The benchmark response acquisition rules include: using the response message corresponding to the first HTTP request message as a reference response, and / or, Using the response message corresponding to other request messages in the traffic log whose authentication parameters are different from those of the first HTTP request message as a reference response, and / or, Replay the first HTTP request message and use the obtained response message as a reference response.

6. The web application API security vulnerability scanning system according to claim 4, characterized in that: The vulnerability judgment rules include: The output of the matching error and / or the matching sensitive field caused by the triggering API error, and / or, Setting a similarity threshold, comparing the current response with the reference response for similarity, if the obtained similarity is greater than or equal to the similarity threshold, determining that there is a vulnerability, if the obtained similarity is less than the similarity threshold, determining that there is no vulnerability, and / or, Monitor the sensitive data position in the current response, and determine whether the parameter change information appears in the sensitive data position. If so, determine that there is a vulnerability; if not, determine that there is no vulnerability.

7. The web application API security vulnerability scanning system according to claim 1, characterized in that: The first HTTP request message includes: a request line, a request header and a request body, and the message modeling module is specifically used for: For the request line and the request header, directly convert them into a first key-value pair; For the request body with a hierarchical structure, during the dimensionality reduction process, each nested level in the request body is represented by its key in the form of a hierarchical path, and the hierarchical path is composed of the upper key name connected to the key name of the current level through a specific hierarchical symbol, and finally the corresponding key value is obtained to form a second key-value pair, and then the different second key-value pairs are formed into a key-value pair list, and finally the first key-value pair is merged into the key-value pair list.

8. The web application API security vulnerability scanning system according to claim 1, characterized in that: The request restoration module comprises: An authentication field adding unit is used to detect whether the authentication field in the request message sequence is expired. If it is an expired authentication field, the expired authentication field is used to generate a non-expired authentication field, or a corresponding web application process is executed to obtain a non-expired authentication field; The request message restoration unit is used to traverse each element in the request message sequence, split it into hierarchical paths and corresponding values ​​according to hierarchical symbols, create keys in the JSON object layer by layer according to the hierarchical path, and assign the final value to the key pointed to by the path, thereby constructing the second HTTP request message that conforms to the request message format.

9. The web application API security vulnerability scanning system according to claim 1, characterized in that: The system also includes: a message preprocessing module, which is used to clean and deduplicate the first HTTP request message to remove data that is not related to API interaction.

10. A scanning method based on the web application API security vulnerability scanning system according to any one of claims 1 to 9, characterized in that: The method comprises: Perform dimensionality reduction modeling on the original first HTTP request message interacting with the web application API to generate a corresponding key-value pair list; The key-value pair list is sequentially subjected to a plurality of different types of security vulnerability scans to generate a request message sequence containing vulnerability scanning related information, wherein the vulnerability scanning related information includes: parameter change information and vulnerability scanning information; Adding a legal authentication field to the request message sequence and restoring it into a second HTTP request message; Send the second HTTP request message and obtain the current response; The vulnerability existence of the current response is judged according to the vulnerability judgment rules configured by the different types of security vulnerability scanning functions, and the vulnerability type is determined according to the vulnerability scanning information.

11. An electronic device, characterized in that: The electronic device comprises: One or more processors; and a memory storing computer program instructions, wherein when the computer program instructions are executed, the processor executes the web application API security vulnerability scanning method according to claim 10.

12. A computer-readable storage medium having a computer program / instruction stored thereon, characterized in that: When the computer program / instructions are executed by a processor, the web application API security vulnerability scanning method as claimed in claim 10 is implemented.

13. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the web application API security vulnerability scanning method as claimed in claim 10 is implemented.

Images