CN117150514B

CN117150514B - Vulnerability active verification method and device based on code vaccine IAST probe

Info

Publication number: CN117150514B
Application number: CN202311423143.9A
Authority: CN
Inventors: 张涛; 宁戈; 董毅; 杜玉洁; 周辜名
Original assignee: Beijing Anpro Information Technology Co ltd
Current assignee: Beijing Anpro Information Technology Co ltd
Priority date: 2023-10-30
Filing date: 2023-10-30
Publication date: 2024-02-02
Anticipated expiration: 2043-10-30
Also published as: CN117150514A

Abstract

The disclosure provides a vulnerability initiative verification method and device based on a code vaccine IAST probe, which relate to the technical field of computers, and in the process of responding to a user request, if an objective function currently responding to the user request is a risk function, risk event information is generated; generating a simulation test request based on the risk event information, and responding to the simulation test request by utilizing a plurality of functions of the target application program; and verifying the security hole corresponding to the risk event information based on the test information generated in the process of responding to the simulation test request. According to the method, the risk event information can be generated by utilizing the data generated by the server when the server responds to the user request, the simulation test request is generated by utilizing the risk event information, the security vulnerability is verified by utilizing the simulation test request, the test end is not required to continuously send the request to the server, and the occupied computing resources in the test process can be effectively reduced.

Description

Vulnerability active verification method and device based on code vaccine IAST probe

Technical Field

The disclosure relates to the technical field of computers, in particular to a vulnerability active verification method and device based on a code vaccine IAST probe.

Background

To ensure that an application can safely and stably provide services, weak points and vulnerabilities in the application are generally discovered and repaired by applying security tests to prevent the related application from being utilized to cause security hazards. In active vulnerability detection, a scanner is required to actively scan an application program to find the existing vulnerability, the basic principle of detection is a process of simulating network attack, a network request containing a specific test script is sent to a server, and then whether the vulnerability exists or not is judged by analyzing information of a response packet.

In general, the vulnerability detection scheme needs to continuously send a request to a server by using a test terminal, perform a simulated attack message construction on known vulnerabilities, and detect known types of vulnerabilities possibly hidden in a target program through a simulated attack test. However, this method requires continuous interaction and data transmission between the service end and the test end, which generates a large amount of test data and occupies more computing resources.

Disclosure of Invention

The embodiment of the disclosure at least provides a vulnerability active verification method, device and system based on a code vaccine IAST probe.

In a first aspect, an embodiment of the present disclosure provides a vulnerability active verification method based on a code vaccine IAST probe, including:

Responding to a user request for a target application program by utilizing a plurality of functions of the target application program in response to acquiring the user request;

in the process of responding to the user request, if the current objective function responding to the user request is a risk function, risk event information is generated; the risk event information comprises context information generated in the responded process of the user request, identification information corresponding to the objective function and risk type information;

generating a simulation test request based on the risk event information, and responding to the simulation test request by utilizing a plurality of functions of the target application program;

and verifying the security hole corresponding to the risk event information based on the test information generated in the process of responding to the simulation test request.

In an alternative embodiment, the generating a simulation test request based on the risk event information includes:

determining parameter information corresponding to the user request from the context information in the risk event information;

updating the parameter information by using a test data set to obtain test parameter information;

Generating the simulation test request based on the address information indicated in the context information and the test parameter information; the simulation test request carries the identification information and the risk type information.

In an optional implementation manner, the updating the parameter information by using the test data set to obtain test parameter information includes:

determining a target parameter type from a plurality of parameter types in the parameter information;

obtaining a parameter value sample matched with the target parameter type from the test data set;

and replacing the parameter value matched with the target parameter type in the parameter information by using the parameter value sample to obtain the test parameter information.

In an alternative embodiment, the responding to the simulation test request with a plurality of functions of the target application program includes:

determining whether risk type information corresponding to a test function is consistent with risk type information carried in the simulation test request or not according to the test function which responds to the simulation test request currently in the plurality of functions;

when the risk type information corresponding to the test function is inconsistent with the risk type information carried in the simulation test request, responding to the simulation test request by using the test function, and sending the simulation test request to the next function in a response flow for responding to the simulation test request;

And stopping responding to the simulation test request and acquiring the test information generated in the process of responding to the simulation test request under the condition that the risk type information corresponding to the test function is consistent with the risk type information carried in the simulation test request.

In an optional implementation manner, the verifying the security hole corresponding to the risk event information based on the test information generated in the process of responding to the simulation test request includes:

determining risk type information corresponding to the simulation test request, and acquiring vulnerability characteristics matched with the risk type information;

and performing vulnerability feature matching on the test information based on the vulnerability features to obtain a verification result of the security vulnerability corresponding to the risk event information.

determining risk type information corresponding to the simulation test request;

determining a target risk level of risk event information corresponding to the simulation test request based on the risk type information;

adding the simulation test request to a target test request queue corresponding to the target risk level;

And responding to the simulation test requests in each test request queue in sequence according to the priorities of the corresponding test request queues of each risk level.

In an alternative embodiment, after the simulation test request is added to the target test request queue corresponding to the target risk level, the method further includes:

setting a preset response time length for the simulation test request, and updating the preset total response time length of the target test request queue by utilizing the preset response time length;

the response to the simulation test requests in each test request queue sequentially according to the priorities of the corresponding test request queues of each risk level comprises the following steps:

and aiming at a first simulation test request which is being responded, if the actual response time of the first simulation test request exceeds the preset response time of the first simulation test request, adding the first simulation test request to the tail of a first test request queue corresponding to the first simulation test request.

In an alternative embodiment, the method further comprises:

if the actual total response time length of the first test request queue exceeds the preset total response time length, ending the response to the simulation test request in the first test request queue, and adding the simulation test request with incomplete response in the first test request queue to the end of the second test request queue; and the priority corresponding to the second test request queue is lower than that of the first test request queue.

In an optional implementation manner, the responding to the simulation test requests in each test request queue sequentially according to the priorities of the test request queues corresponding to each risk level includes:

and suspending the response to the second simulation test request and starting to respond to the simulation test request in the third test request queue when the new simulation test request is detected to be added to the corresponding third test request queue and the priority corresponding to the second simulation test request which is currently responded is lower than the priority of the new simulation test request.

In a second aspect, an embodiment of the present disclosure further provides a vulnerability active verification device based on a code vaccine IAST probe, including:

a first response module, configured to respond to a user request for a target application program by using a plurality of functions of the target application program in response to acquiring the user request;

the generation module is used for generating risk event information if the current objective function responding to the user request is a risk function in the process of responding to the user request; the risk event information comprises context information generated in the responded process of the user request, identification information corresponding to the objective function and risk type information;

The second response module is used for generating a simulation test request based on the risk event information and responding to the simulation test request by utilizing a plurality of functions of the target application program;

and the verification module is used for verifying the security hole corresponding to the risk event information based on the test information generated in the process of responding to the simulation test request.

In an alternative embodiment, the generating module is specifically configured to:

In an optional implementation manner, the generating module updates the parameter information by using a test data set, and when obtaining test parameter information, the generating module is configured to:

In an alternative embodiment, the second response module is specifically configured to:

In an alternative embodiment, the verification module is specifically configured to:

determining risk type information corresponding to the simulation test request;

In an optional implementation manner, after the simulation test request is added to the target test request queue corresponding to the target risk level, the second response module is further configured to:

The second response module is further configured to, when responding to the simulation test requests in each test request queue in sequence according to the priorities of the test request queues corresponding to each risk level:

In an alternative embodiment, the second response module is further configured to:

In an optional implementation manner, the second response module is configured to, when responding to the simulation test requests in each test request queue in turn according to the priorities of the test request queues corresponding to each risk level:

In a third aspect, an optional implementation manner of the disclosure further provides a computer device, a processor, and a memory, where the memory stores machine-readable instructions executable by the processor, and the processor is configured to execute the machine-readable instructions stored in the memory, where the machine-readable instructions, when executed by the processor, perform the steps in the first aspect, or any possible implementation manner of the first aspect, when executed by the processor.

In a fourth aspect, an alternative implementation of the present disclosure further provides a computer readable storage medium having stored thereon a computer program which when executed performs the steps of the first aspect, or any of the possible implementation manners of the first aspect.

The description of the effect of the above-mentioned active vulnerability verification device, computer device, and computer-readable storage medium based on the code vaccine IAST probe is referred to the description of the above-mentioned active vulnerability verification method based on the code vaccine IAST probe, and will not be repeated here.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the aspects of the disclosure.

According to the vulnerability active verification method and device based on the code vaccine IAST probe, the risk event information can be generated by utilizing the data generated by the server when the server responds to the user request, the simulation test request is generated by utilizing the risk event information, the security vulnerability is verified by utilizing the simulation test request, the test end is not required to continuously send the request to the server, and the calculation resources occupied in the test process can be effectively reduced.

The foregoing objects, features and advantages of the disclosure will be more readily apparent from the following detailed description of the preferred embodiments taken in conjunction with the accompanying drawings.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for the embodiments are briefly described below, which are incorporated in and constitute a part of the specification, these drawings showing embodiments consistent with the present disclosure and together with the description serve to illustrate the technical solutions of the present disclosure. It is to be understood that the following drawings illustrate only certain embodiments of the present disclosure and are therefore not to be considered limiting of its scope, for the person of ordinary skill in the art may admit to other equally relevant drawings without inventive effort.

FIG. 1 illustrates a flow chart of a method of active vulnerability verification based on a code vaccine IAST probe provided by some embodiments of the present disclosure;

FIG. 2 illustrates a flow chart of another active vulnerability verification based on a code vaccine IAST probe provided by some embodiments of the present disclosure;

FIG. 3 illustrates a schematic diagram of a code vaccine IAST probe-based vulnerability active verification apparatus provided by some embodiments of the present disclosure;

fig. 4 illustrates a schematic diagram of a computer device provided by some embodiments of the present disclosure.

Detailed Description

For the purposes of making the objects, technical solutions and advantages of the embodiments of the present disclosure more apparent, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure, and it is apparent that the described embodiments are only some embodiments of the present disclosure, but not all embodiments. The components of the disclosed embodiments generally described and illustrated herein may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present disclosure is not intended to limit the scope of the disclosure, as claimed, but is merely representative of selected embodiments of the disclosure. All other embodiments, which can be made by those skilled in the art based on the embodiments of this disclosure without making any inventive effort, are intended to be within the scope of this disclosure.

According to research, the vulnerability detection scheme needs to continuously send requests to the server by using a test terminal, a simulation attack message structure is carried out on known vulnerabilities, and known types of vulnerabilities which are possibly hidden in a target program are detected through simulation attack tests. However, this method requires continuous interaction and data transmission between the service end and the test end, which generates a large amount of test data and occupies more computing resources.

Based on the above study, the disclosure provides a vulnerability initiative verification method and device based on a code vaccine IAST probe, which can generate risk event information by using data generated by a server when responding to a user request, generate a simulation test request by using the risk event information, verify a security vulnerability by using the simulation test request, and effectively reduce calculation resources occupied in a test process without continuously sending a request to the server by a test terminal.

The present invention is directed to a method for manufacturing a semiconductor device, and a semiconductor device manufactured by the method.

It should be noted that: like reference numerals and letters denote like items in the following figures, and thus once an item is defined in one figure, no further definition or explanation thereof is necessary in the following figures.

For the convenience of understanding the present embodiment, first, a detailed description will be given of a vulnerability active verification method based on a code vaccine IAST probe disclosed in the present disclosure, and an execution subject of the vulnerability active verification method based on a code vaccine IAST probe provided in the present disclosure is generally a computer device with a certain computing capability, where the computer device includes, for example: a terminal device or server or other processing device. In some possible implementations, the active vulnerability verification method based on the code vaccine IAST probe can be implemented by a mode that a processor calls computer readable instructions stored in a memory.

The following describes a vulnerability active verification method based on a code vaccine IAST probe according to an embodiment of the present disclosure, taking an execution subject as a server as an example.

Referring to fig. 1, a flowchart of a vulnerability active verification method based on a code vaccine iat probe according to an embodiment of the present disclosure is shown, where the method includes steps S101 to S104, in which:

S101, responding to a user request aiming at a target application program by utilizing a plurality of functions of the target application program.

S102, in the process of responding to the user request, if the current objective function responding to the user request is a risk function, risk event information is generated; the risk event information comprises context information generated in the responded process of the user request, identification information corresponding to the objective function and risk type information.

S103, generating a simulation test request based on the risk event information, and responding to the simulation test request by utilizing a plurality of functions of the target application program.

S104, verifying security vulnerabilities corresponding to the risk event information based on test information generated in the process of responding to the simulation test request.

The following will describe the above steps in detail:

the steps may be performed by a server, on which a target application (e.g., a micro-service) may be running, which may receive a user request sent by a client and respond to the user request with the target application. The target application may provide a plurality of functions, which may include a plurality of types, thereby implementing different functions.

In responding to a user request, multiple functions may be used to respond to the user request as required by the user request. The functions in the target application program may be functions related to the Request, specifically, may refer to functions in the target application program for acquiring external data of the target application program, such as an entry method of hypertext transfer protocol (Hypertext Transfer Protocol, HTTP) Request processing, a Request object, a related method of setting returned data in Response to the Response object, and the like.

Among these functions, there may be some risk functions (i.e., methods that may be exploited) that may refer to functions that directly produce security-sensitive operations (such as violating data integrity) or that may reveal private data to the outside world (such as violating data confidentiality), such as simple mail transfer protocol (Simple Mail Transfer Protocol, SMTP) operation methods, send hypertext transfer protocol (Hypertext Transfer Protocol, HTTP) request-related methods, extensible markup language (Extensible Markup Language, XML) decoding-related methods, related methods that execute system commands, methods that execute lightweight directory access protocol (Lightweight Directory Access Protocol, LDAP) query-related methods, methods that execute XML path language (XPATH) query-related methods, file operation-related methods, JSON deserialization-related methods, etc.

When the function responding to the user request is detected to be the risk function, the user request may carry a risk code, so that the risk function sends data to the outside, and the risk event can be considered to occur, and at this time, risk event information can be generated.

The risk event information may include context information generated in the response process of the user request, identification information corresponding to the objective function, and risk type information. The context information may refer to context information related to a user request, and may include, for example, request parameters, uniform resource location system (uniform resource locator, URL) identification, request methods, and the like.

The risk type may be determined according to the potential risk corresponding to the risk function.

To obtain the context information described above, a probe may be deployed for the target application using a coded vaccine technique. The probe may be an interactive application (Interactive Application Security Testing, IAST) probe. The code vaccine technology is to inject codes with safety functions into an application server like a vaccine, so that the analyzed flow can be clearly observed in the application program, and the context of the running process of the application program can be perceived. The method can realize the diagnosis of the position of the vulnerability and the cause of the defect existing in the application program during running, and based on the position, the autonomous detection and response of risks can be realized, so that the external hazards are actively defended.

Specifically, the security code of the probe can be injected into the function through a pre-instrumentation mode under the condition of user authorization, the instrumentation probe is inserted into the program on the basis of ensuring the original program logic integrity, and the information (method/function, method/function parameter value, return value and the like) in the program code is collected through the probe. Code fragments are inserted at specific locations of the program code to gather dynamic context information at program runtime.

It is noted that the probe needs to acquire the information after acquiring the authorization of the user.

The risk event information may be recorded in a risk list. The risk list may be plural and corresponds to different risk types.

When the risk event information is utilized to generate a simulation test request, the corresponding parameter information of the user request can be determined from the context information in the risk event information, then the parameter information is updated by utilizing the test data set to obtain test parameter information, and then the simulation test request is generated according to the address information indicated in the context information and the test parameter information.

When the test parameter information is determined, a target parameter type can be determined from a plurality of parameter types in the parameter information, then a parameter value sample matched with the target parameter type is obtained from the test data set, and the parameter value matched with the target parameter type in the parameter information is replaced by the parameter value sample to obtain the test parameter information.

The parameter information corresponding to the user request may refer to key value pair information in the user request, where the key value pair information may include a key information key and a value information value, where the key information may indicate a parameter type, and the value information may indicate a parameter value of the parameter.

Specifically, each key information capable of indicating the parameter type may be identified from the parameter information, and the target key information may be determined from the plurality of key information, thereby obtaining the target parameter type. The target parameter type can be selected randomly from a plurality of parameter types or obtained by condition screening. The number of the target parameter types can be determined according to practical situations, for example, in order to reduce the change of the simulation test request relative to the user request, the test is convenient, and only one target parameter type can be determined by adopting a unique variable principle.

After the target parameter type is obtained, a parameter value sample matching the target parameter type may be obtained from the test dataset. The test dataset may be a pre-generated Proof of Concept (POC) dataset. POC is an incomplete piece of code program for checking whether the target has a corresponding vulnerability, and the preset POC data set is a set of published code programs for checking the corresponding vulnerability.

For example, the test dataset may contain a number of parameter types, and one or more samples of parameter values corresponding to each parameter type. The parameter value samples used in the simulation test request can be obtained by extracting the parameter value samples matched with the target parameter types.

Specifically, information of a message type (content type) in the context information as a data transmission type (such as json, xml, x-www-form-url code/multi part) may be obtained, and a value pointed by a key to be replaced may be found from the information and replaced with POC data.

For example, if the target parameter type and the corresponding parameter value in the parameter information are:

{

“key”：“value”

}

the updated target parameter type and the parameter value sample thereof are:

{

“key”：“poc”

}

after the test parameter information is obtained, the address information and the test parameter information can be assembled to obtain a simulation test request.

For example, according to the URL information in the context information and the request data after replacing the POC parameter value, the specific request header added to the request may be implemented and reassembled into a new URL instance object, so as to obtain the simulation test request.

In order to facilitate the use of the subsequent simulation test request, the simulation test request may carry identification information of an objective function corresponding to the risk event information and risk type information corresponding to the risk event information.

After the simulation test request is obtained, the simulation test request can be correspondingly tested by utilizing a plurality of functions of the target application program, and the risk event information is tested.

In the process of responding to the simulation test request, before a function responds to the simulation test request, whether the current function needs to respond to the simulation test request can be judged.

For example, for a test function currently responding to a simulation test request in a plurality of functions, whether risk type information corresponding to the test function is consistent with risk type information carried in the simulation test request can be determined;

under the condition that risk type information corresponding to the test function is inconsistent with risk type information carried in the simulation test request, the current function which does not exist in the risk is described, the test function can be utilized to respond to the simulation test request, so that the test progress is advanced, and the simulation test request is sent to the next function in a response flow for responding to the simulation test request;

under the condition that the risk type information corresponding to the test function is consistent with the risk type information carried in the simulation test request, the risk type to be tested is consistent with the risk type corresponding to the simulation test function when the risk type information corresponding to the test function is already carried out to the node with the risk, the response to the simulation test request can be stopped, the test information generated in the process of responding to the simulation test request is obtained, and the security hole is verified by utilizing the test information.

When verifying the security vulnerabilities, risk type information corresponding to the simulation test request can be determined first, vulnerability characteristics matched with the risk type information are obtained, then vulnerability characteristic matching can be carried out on the test information based on the vulnerability characteristics, and a security vulnerability verification result corresponding to the risk event information is obtained.

In performing security vulnerability verification, test information generated in the process of responding to a simulated test request needs to be used.

The context information generated in the simulation test request is generated in the corresponding process may include the name and parameter of the function related to the request, the name, input parameter, stack trace information of the related risk function, the specific execution command corresponding to the risk function, the triggered vulnerability type (i.e. the risk type corresponding to the risk event), and the like.

After the vulnerability characteristics are acquired, verification logic of the security vulnerability can be generated according to the vulnerability characteristics, for example, after the vulnerability characteristics of the path traversing type are generated, the following verification logic can be generated:

judging whether the function related to the request is path class or not;

if yes, judging whether the parameters of the function related to the request are of the string type, and if the parameters of the risk function are of the string type;

If yes, judging whether crossing symbols exist in the risk function;

if yes, judging whether the parameter end of the function related to the request exists in the parameters of the risk function;

if yes, determining that the path passes through the vulnerability.

For another example, for XXE vulnerabilities, the following validation logic may be generated:

acquiring a system identifier and stack tracking information in a risk function;

judging whether the parameters of the function related to the request contain a system identifier, if so, continuously judging whether the file content contains the system identifier;

if so, judging whether stack tracking information in the risk function exists in a preset white list stack or not;

if not, a XXE vulnerability is determined.

After the verification result is obtained, or after the identification information carried by the current simulation test request is determined to be consistent with the identification information of the function currently responding to the simulation test request, or after the risk type information carried by the current simulation test request is determined to be consistent with the risk type information of the function currently responding to the simulation test request, the response of the simulation test request can be intercepted, and the response to the simulation test request is stopped, so that the server is prevented from generating more test data.

In the actual implementation process, the server can directly respond to any received request, and acquire the context information generated in the process of responding to the request by using the probe, and when the risk function starts to respond to the request, the server judges whether the request is a user request or a simulation test request. If the user requests, risk event information is generated, and then the risk event information is utilized to generate a simulation test request; if the response request is a simulation test request, verification of the security hole can be performed according to the test information generated in the response process.

In one possible implementation manner, the server may generate a plurality of simulation test requests in real time, and when generating the simulation test requests, the simulation test requests may be implemented according to a preset generation policy. For example, corresponding simulation test requests can be generated for different risk types according to the risk type information, and each risk type can generate a preset number of simulation test requests so as to test various risk types.

In order to ensure the health of the server as much as possible in the test process and reduce the influence on the user request, the simulation test request can be queued and/or limited to prevent the server from responding to excessive simulation test requests and failing to respond to the user request.

Specifically, the target risk level of the risk event information corresponding to the simulation test request can be determined based on the risk type information corresponding to the simulation test request, so that the simulation test request is classified according to the risk level corresponding to the simulation test request, and the classified simulation test request is added into a target test request queue corresponding to the target risk level. Then, according to the priority of the test request queue corresponding to each risk level, the simulation test requests in each test request queue can be sequentially and correspondingly processed.

For example, multiple risk levels, such as a medium risk, a low risk, and a high risk, may be preset, and a corresponding queue may be set for each risk level, for example, the high risk may correspond to an L1 queue, the medium risk corresponds to an L2 queue, and the low risk corresponds to an L3 queue. When the simulation test request does not exist in the L1 queue, responding to the simulation test request in the L2 queue; and when the simulation test requests are not in the L1 and L2 queues, responding to the simulation test requests in the L3 queue.

When determining the target risk level corresponding to the risk event information, the risk level corresponding to the path traversing vulnerability may be high risk according to a preset risk level mapping table; for Cross-site request forgery (Cross-Site Request Forgery, csrf) holes, the vulnerability can be a risk; for log injection holes, then there may be low risk.

After the simulation test request is added to the target test request queue corresponding to the target risk level, the server can set a preset response time length for the simulation test request, and update the preset total response time length of the target test request queue by using the preset response time length.

The preset response time length can control the response time of the simulation test request. And aiming at the first simulation test request which is being responded, if the actual response time of the first simulation test request exceeds the preset response time of the first simulation test request, adding the first simulation test request to the end of the first test request queue corresponding to the first simulation test request.

The preset total response time length can control the time length of the simulation test request in the response target test request queue. If the actual total response time length of the first test request queue exceeds the preset total response time length, ending the response to the simulation test request in the first test request queue, and adding the simulation test request with incomplete response in the first test request queue to the end of the second test request queue; the priority corresponding to the second test request queue is lower than that of the first test request queue. For example, if the first test request queue is an L1 queue, the second test request queue may be an L2 queue.

For example, when the preset response time length is used as the preset total response time length of the target test request queue to update, the preset response time length and the preset total response time length of the target test request queue may be added to obtain a new preset total response time length. If the preset response time length of each simulation test request is n, and m simulation test requests are in total in the L1 queue, the preset total response time length of the L1 queue is n×m.

For each simulation test request in the same queue, a preset response time length is allocated in a First Come First Served (FCFS) mode. For example, in the period of n×m, if a new simulation test request needs to be placed, the new simulation test request is placed at the end of the current L1 queue, and a new allocation time slice n is added, where the preset total response duration of the L1 queue is n×1.

If the actual response time of a simulation test request exceeds the defined preset response time in a test request queue, the simulation test request can be paused and put at the end of the queue; for each simulation test request in the same queue (such as an L1 queue), the preset response time length is n, if the current simulation test request in the L1 is not completed after the time length n is elapsed, the simulation test request is put at the end of the current queue L1, the next simulation test request in the queue is operated, if the simulation test request at the end of the put queue is scheduled again, the actual total response time length of the L1 queue still remains (the operation time of other simulation test requests is smaller than the allocated time n), and the simulation test request is operated until the simulation test request is completed.

For the queues of three different levels L1, L2 and L3, determining the corresponding preset total response time length (such as n x m) of the queue according to the number of the simulation test requests, if the actual total response time length of the current response queue exceeds the preset total response time length of the queue, suspending all subtasks in the current queue, allowing the next priority queue to execute, and adding all the simulation test requests in the current priority queue to the end of the next priority queue. If the simulation test request in the L1 queue cannot be completely responded after the timeout of the L1 queue, the incomplete simulation test request of the L1 queue is put at the end of the next stage L2 queue, and the like until the completion. After the execution of the last queue is completed, responses to the suspended simulation test requests are re-prioritized from high to low.

When it is detected that a new simulation test request is added to the corresponding third test request queue and the priority corresponding to the second simulation test request currently responded is lower than that of the new simulation test request, the response to the second simulation test request can be suspended and the response to the simulation test request in the third test request queue can be started.

Specifically, when the simulation test request in the low-priority queue is responded, the newly arrived simulation test request of the high-priority queue is available, the running simulation test request in the low-priority queue can be suspended, the simulation test request is put back to the head of the current queue, the simulation test request of the high-priority queue is waited to be run, and then the simulation test request is continued to be run. When the simulation test request to the current queue is dispatched again, only the last remaining time is distributed, and the preset response time length corresponding to the queue is not distributed.

Referring to fig. 2, another active vulnerability verification method based on a code vaccine IAST probe according to an embodiment of the present disclosure is provided, where a probe request (i.e. a simulation test request) or a user request is first obtained, and a user service logic is used to respond to the obtained request, where the request may pass through a function related to the request, and possibly also pass through a risk function during the response. When the request arrives at the request related function, the probe can be used for acquiring the request context information, when the request arrives at the risk function, the risk function information can be acquired, and whether the user requests or the probe requests when the request arrives at the risk function can be judged. If the user requests, the vulnerability type (risk type information) to be replayed can be recorded, and the vulnerability type, the risk function information and the request context information are utilized to generate risk event information and store the risk event information in a risk list. Thereafter, the probe request can be constructed using the risk event information in the risk list. When constructing the probe request, the keys of all parameters in the current request can be acquired, a preset POC data set is acquired according to the corresponding vulnerability type, then the value pointed by the key of the parameter to be replaced is acquired, the value is replaced by POC data, the new url instance object is reassembled, and the probe request is started. If the rule context is the same as the rule context, the rule context (verification logic) is constructed, and the rule context is combined with the rule context corresponding to the type of the loophole to judge whether the loophole exists or not.

It will be appreciated by those skilled in the art that in the above-described method of the specific embodiments, the written order of steps is not meant to imply a strict order of execution but rather should be construed according to the function and possibly inherent logic of the steps.

Based on the same inventive concept, the embodiment of the disclosure further provides a code vaccine IAST probe-based vulnerability active verification device corresponding to the code vaccine IAST probe-based vulnerability active verification method, and since the principle of solving the problem by the device in the embodiment of the disclosure is similar to that of the code vaccine IAST probe-based vulnerability active verification method in the embodiment of the disclosure, the implementation of the device can be referred to the implementation of the method, and the repetition is omitted.

Referring to fig. 3, a schematic diagram of a vulnerability active verification device based on a code vaccine IAST probe according to an embodiment of the disclosure is shown, where the device includes:

a first response module 310, configured to respond to a user request for a target application program with a plurality of functions of the target application program in response to acquiring the user request;

a generating module 320, configured to generate risk event information if the objective function currently responding to the user request is a risk function in the process of responding to the user request; the risk event information comprises context information generated in the responded process of the user request, identification information corresponding to the objective function and risk type information;

A second response module 330, configured to generate a simulation test request based on the risk event information, and respond to the simulation test request by using a plurality of functions of the target application program;

and the verification module 340 is configured to verify the security hole corresponding to the risk event information based on the test information generated in the process of responding to the simulation test request.

In an alternative embodiment, the generating module 320 is specifically configured to:

In an alternative embodiment, the generating module 320 is configured to update the parameter information with a test data set, and when obtaining test parameter information, the generating module is configured to:

In an alternative embodiment, the second response module 330 is specifically configured to:

In an alternative embodiment, the verification module 340 is specifically configured to:

determining risk type information corresponding to the simulation test request;

In an alternative embodiment, after the simulation test request is added to the target test request queue corresponding to the target risk level, the second response module 330 is further configured to:

In an alternative embodiment, the second response module 330 is further configured to:

In an alternative embodiment, the second response module 330 is configured to, when responding to the simulated test requests in each test request queue sequentially according to the priorities of the test request queues corresponding to the respective risk levels:

The process flow of each module in the apparatus and the interaction flow between the modules may be described with reference to the related descriptions in the above method embodiments, which are not described in detail herein.

The embodiment of the disclosure further provides a computer device, as shown in fig. 4, which is a schematic structural diagram of the computer device provided by the embodiment of the disclosure, including:

a processor 41 and a memory 42; the memory 42 stores machine readable instructions executable by the processor 41, the processor 41 being configured to execute the machine readable instructions stored in the memory 42, the machine readable instructions when executed by the processor 41, the processor 41 performing the steps of:

In an alternative embodiment, in the instructions executed by the processor 41, the generating a simulation test request based on the risk event information includes:

In an alternative embodiment, in the instructions executed by the processor 41, the updating the parameter information with the test data set to obtain test parameter information includes:

In an alternative embodiment, the responding to the simulation test request by using a plurality of functions of the target application program in the instructions executed by the processor 41 includes:

In an alternative embodiment, in the instructions executed by the processor 41, the verifying the security hole corresponding to the risk event information based on the test information generated in the process of responding to the simulation test request includes:

determining risk type information corresponding to the simulation test request;

In an alternative embodiment, after the simulation test request is added to the target test request queue corresponding to the target risk level in the instructions executed by the processor 41, the method further includes:

In an alternative embodiment, the instructions executed by the processor 41 further include:

In an alternative embodiment, in the instructions executed by the processor 41, the responding to the simulation test request in each test request queue sequentially according to the priority of each risk level corresponding to the test request queue includes:

The memory 42 includes a memory 421 and an external memory 422; the memory 421 is also referred to as an internal memory, and is used for temporarily storing operation data in the processor 41 and data exchanged with the external memory 422 such as a hard disk, and the processor 41 exchanges data with the external memory 422 via the memory 421.

The specific execution process of the above instruction may refer to the steps of the active vulnerability verification method based on the code vaccine IAST probe in the embodiments of the present disclosure, which are not described herein.

The disclosed embodiments also provide a computer readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of the code vaccine IAST probe based vulnerability proactive verification method described in the method embodiments above. Wherein the storage medium may be a volatile or nonvolatile computer readable storage medium.

The embodiments of the present disclosure further provide a computer program product, where the computer program product carries program code, where instructions included in the program code may be used to perform the steps of the active vulnerability verification method based on the code vaccine IAST probe described in the above method embodiments, and specifically, reference may be made to the above method embodiments, which are not repeated herein.

Wherein the above-mentioned computer program product may be realized in particular by means of hardware, software or a combination thereof. In an alternative embodiment, the computer program product is embodied as a computer storage medium, and in another alternative embodiment, the computer program product is embodied as a software product, such as a software development kit (Software Development Kit, SDK), or the like.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described system and apparatus may refer to corresponding procedures in the foregoing method embodiments, which are not described herein again. In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be other manners of division in actual implementation, and for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some communication interface, device or unit indirect coupling or communication connection, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present disclosure may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a non-volatile computer readable storage medium executable by a processor. Based on such understanding, the technical solution of the present disclosure may be embodied in essence or a part contributing to the prior art or a part of the technical solution, or in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in the embodiments of the present disclosure. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Finally, it should be noted that: the foregoing examples are merely specific embodiments of the present disclosure, and are not intended to limit the scope of the disclosure, but the present disclosure is not limited thereto, and those skilled in the art will appreciate that while the foregoing examples are described in detail, it is not limited to the disclosure: any person skilled in the art, within the technical scope of the disclosure of the present disclosure, may modify or easily conceive changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features thereof; such modifications, changes or substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the disclosure, and are intended to be included within the scope of the present disclosure. Therefore, the protection scope of the present disclosure shall be subject to the protection scope of the claims.

Claims

1. A vulnerability initiative verification method based on a code vaccine IAST probe is characterized by comprising the following steps:

verifying security vulnerabilities corresponding to the risk event information based on test information generated in the process of responding to the simulation test request;

the responding to the simulation test request with the plurality of functions of the target application program comprises:

2. The method of claim 1, wherein generating a simulation test request based on the risk event information comprises:

3. The method of claim 2, wherein updating the parameter information with the test data set to obtain test parameter information comprises:

4. The method according to claim 1, wherein verifying the security hole corresponding to the risk event information based on the test information generated in the process of responding to the simulation test request includes:

5. The method of claim 1, wherein responding to the simulation test request with a plurality of functions of the target application program comprises:

determining risk type information corresponding to the simulation test request;

6. The method of claim 5, wherein after adding the simulated test request to the target test request queue corresponding to the target risk level, the method further comprises:

7. The method of claim 6, wherein the method further comprises:

8. The method of claim 5, wherein responding to the simulated test requests in each test request queue in turn according to the priorities of the corresponding test request queues for each risk level, comprises:

9. Vulnerability initiative verifying device based on code vaccine IAST probe, characterized by comprising:

the verification module is used for verifying the security hole corresponding to the risk event information based on the test information generated in the process of responding to the simulation test request;

the second response module is specifically configured to, when responding to the simulation test request by using a plurality of functions of the target application program:

10. A computer device, comprising: a processor, a memory storing machine-readable instructions executable by the processor for executing the machine-readable instructions stored in the memory, which when executed by the processor, perform the steps of the code vaccine IAST probe based vulnerability active verification method as claimed in any one of claims 1 to 8.

11. A computer readable storage medium, characterized in that the computer readable storage medium has stored thereon a computer program which, when run by a computer device, performs the steps of the active vulnerability verification method based on the code vaccine IAST probe according to any one of claims 1 to 8.