A vulnerability detection method and system

Abstract

The present invention relates to a vulnerability detection method and system. The method includes: obtaining a mirrored data packet for testing a function point of a request sent from a test-end browser to a test target; parsing the mirrored data packet to obtain the URL, parameters, and parameter values of the current request after removing the parameters; based on the mirrored data packet, sequentially performing initialization vulnerability detection on each vulnerability in the initialization vulnerability group according to the corresponding detection strategy; and according to the verification type of each running-state vulnerability group, constructing an automatic test request data packet based on the mirrored data packet and its parsing result, and sequentially performing coarse-grained detection on one or more vulnerabilities in the vulnerability group; when a suspected risk appears in the coarse-grained detection, performing fine-grained detection or result verification according to the corresponding detection strategy to confirm or eliminate the suspected risk. The present invention reduces the server pressure on the test environment and improves the detection efficiency of vulnerabilities and the system scalability.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and particularly to a vulnerability detection method and system. Background Art

[0002] In the information age, network information security has always been a top priority for enterprises and individuals. Whether it is hardware, software or protocols, when there are defects or insufficient system security policies, vulnerabilities are formed. Attackers can use these vulnerabilities to access or damage the system without authorization, resulting in the information system being attacked or controlled by Trojans, worms, data leakage, data tampering, deletion, etc., thus bringing immeasurable losses to individuals and enterprises. Especially for some Internet enterprises, in order to ensure the normal operation of online services and protect the security of user information, security engineers are usually assigned to conduct security detection of vulnerabilities for online services to discover vulnerabilities and promptly notify relevant departments for repair. Currently, most security engineers use risk scanners and conduct manual tests based on security test project documents. However, this security detection mode faces the following problems:

[0003] First, the influence of human factors is significant. Due to factors such as the working state of security engineers, their security knowledge reserve, and understanding of test projects, it is impossible to ensure that security test strategies are well implemented and full coverage of the business functions to be detected. In addition, different services may adopt different development frameworks, such as the native PHP mode, the self-written mode based on the MVC framework, the third-party framework mode, etc. Different development frameworks have different test strategies. Therefore, security engineers need to load corresponding test strategies according to the development framework of the project. However, in actual operation, security engineers may not pay attention to this, resulting in incorrect loading of security test strategies and ineffective detection.

[0004] Second, the effectiveness of detection tools needs to be improved. Currently, common automated application risk scanners in the security test process, such as Appscan, Green Alliance Aurora, etc., can only cover some simple security risks based on the request-response model, and cannot cover permission-based security vulnerabilities and security vulnerabilities that require interaction, such as stored XSS types.

[0005] Third, missed detections. Although the traditional automated scanner crawler can obtain most business function points, it cannot obtain highly interactive business function points and cannot effectively solve the problem of missed detections of business functions.

[0006] Fourth, security test experience and test strategies cannot be shared. The test experience and test strategies of security engineers for historical projects can only be reused for the next test of the same project by self-recording, and cannot be shared among different engineers. Moreover, it is impossible to know whether there are missed detections. Eventually, it will lead to a long test cycle and unreliable results.

[0007] Fourth, the test environment is restricted. Since the security tests of Party A are usually carried out on the servers in the test environment, the performance of such test servers is poor and they can only support a small number of concurrent test requests. However, the mainstream scanners in the market are all based on a large number of attack simulation requests. If the tests are carried out slowly, it is impossible to complete within the limited test cycle.

[0008] In summary, there is still much room for improvement in the existing vulnerability detection modes, methods and systems. Summary of the Invention

[0009] In view of the technical problems existing in the prior art, the present invention proposes a vulnerability detection method and system, which can reduce the pressure on the servers in the test environment and improve the detection efficiency of vulnerabilities and the scalability of the system when security engineers conduct vulnerability detection.

[0010] To solve the above technical problems, according to one aspect of the present invention, the present invention provides a vulnerability detection method. A variety of vulnerabilities to be detected are divided into an initialization vulnerability group and a running-state vulnerability group. The running-state vulnerability group is divided into multiple different vulnerability groups according to the verification type, and each vulnerability group corresponds to a corresponding detection strategy. The method includes: obtaining an image data packet for testing function points of a request sent by a test-side browser to a test target; parsing the image data packet to obtain the URL, parameters and parameter values of the current request after removing the parameters; based on the image data packet, sequentially performing initialization vulnerability detection on each vulnerability in the initialization vulnerability group according to the corresponding detection strategy; and according to the verification type of each running-state vulnerability group, constructing an automatic test request data packet based on the image data packet and its parsing result, and sequentially performing coarse-grained detection on one or more vulnerabilities in the vulnerability group; when a suspected risk appears in the coarse-grained detection, performing fine-grained detection or result verification according to the corresponding detection strategy to confirm or eliminate the suspected risk

[0011] To solve the above technical problems, according to another aspect of the present invention, the present invention provides a vulnerability detection system, including a data packet acquisition module, a data packet analysis module, and a detection module. Among them, the detection module includes a detection management unit and a plurality of detection model units; the data packet acquisition module is configured to obtain mirror data packets for testing function points sent by a test-end browser to a test target from a preset proxy port, send a test request data packet to the test target, and receive a corresponding response data packet returned by the test target; the data packet analysis module is connected to the data packet acquisition module and is configured to parse the mirror data packet and the response data packet; the detection management unit is connected to the data packet analysis module and coordinates a plurality of detection model units to detect a plurality of vulnerabilities according to a preset scanning strategy. Among them, the plurality of vulnerabilities are divided into an initialization vulnerability group and a running-state vulnerability group. According to the verification type, the running-state vulnerability group is divided into a plurality of different vulnerability groups, and each vulnerability group is set with a corresponding detection strategy; the plurality of detection model units are respectively connected to the detection management unit, the data packet analysis module, and the data packet acquisition module, and each detection model unit completes the detection of a vulnerability group of a verification type according to the instruction of the detection management unit according to the detection strategy.

[0012] The present invention splits the detection process into two steps: initial coarse-grained security detection and fine-grained security detection or result verification during review. Only a small number of optimal test cases are configured for the coarse-grained security detection. If a suspected vulnerability appears, a large number of accurate test cases are called for review. Therefore, the performance requirements for the test server are not high, and the security detection of vulnerabilities can be quickly completed in a test environment with poor performance, with high accuracy and high efficiency. By classifying vulnerabilities into different groups according to the verification type during detection, configuring corresponding detection strategies for different vulnerability groups and respectively executing them by a detection model unit, each model unit runs independently. Therefore, the expandability of vulnerability detection is good. Newly emerging vulnerabilities can be matched to the corresponding vulnerability groups at any time, or a detection model unit with a new verification type can be added for them. This modular detection mode of the present invention improves the scalability of the system. When expanding, security engineers can increase or decrease vulnerabilities or add detection model units through configuration at the front end of the system according to needs, reducing the dependence on developers. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Next, the preferred embodiments of the present invention will be further described in detail with reference to the drawings, where:

[0014] Figure 1 is a principle block diagram of a vulnerability detection system provided according to an embodiment of the present invention;

[0015] Figure 2 is a principle block diagram of a project detection management module provided according to an embodiment of the present invention;

[0016] Figure 3 is a flowchart of a vulnerability detection method provided according to an embodiment of the present invention;

[0017] Figure 4 is a schematic block diagram of the principle of an automatic detection tool provided according to an embodiment of the present invention;

[0018] Figure 5 is a schematic block diagram of the principle of a data packet analysis module provided according to an embodiment of the present invention;

[0019] Figure 6 is a schematic block diagram of the principle of a detection module provided according to an embodiment of the present invention;

[0020] Figure 7 is a flowchart of detecting a function point provided according to an embodiment of the present invention;

[0021] Figure 8 is a flowchart of detecting an initialization vulnerability provided according to an embodiment of the present invention;

[0022] Figure 9 is a flowchart of detecting a vulnerability in a running - state vulnerability group according to an embodiment of the present invention; and

[0023] Figure 10 is a schematic block diagram of the principle of a detection model unit provided according to an embodiment of the present invention. Detailed Embodiments

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0025] In the following detailed description, reference may be made to the various specification drawings that form a part of this application and that illustrate specific embodiments of the application. In the drawings, like reference numerals generally describe substantially similar components in different figures. The various specific embodiments of the present application have been described in sufficient detail below to enable those of ordinary skill in the relevant art and technology to implement the technical solutions of the present application. It should be understood that other embodiments may also be utilized or structural, logical, or electrical changes may be made to the embodiments of the present application.

[0026] Figure 1 is a schematic block diagram of the principle of a vulnerability detection system provided according to an embodiment of the present invention. Refer to Figure 1, the vulnerability detection system includes a test - end browser 1, a manual detection tool 2, an automatic detection tool 3, and a project detection management module 4. Among them, the project detection management module 4 is connected to the manual detection tool 2 and the automatic detection tool 3, the manual detection tool 2 is connected to the test - end browser 1, and the test - end browser 1 is the browser used by security engineers. As Figure 2As shown, the project detection management module 4 includes a management interface 41, a function list generation unit 42, and a monitoring unit 43. The management interface 41 is used to provide the setting of security detection parameter items and the data display of the detection process and results. Among them, through the management interface 41, the test project name can be set or selected, such as the xxx business, and multiple test business lines can be included under this business, and the business line name can be set or selected; the test project domain name can be set or selected, such as xxx.yy.com, which is used to limit the domain name involved in the test project, and non-project-related domain names are not tested to avoid additional performance overhead; the IP address of the test end can be set or selected, such as 10.100.x.x, which is used to limit the IP address of the PC of the security engineer who performs vulnerability detection, thereby specifying the test end browser 1, which can limit the source of using this system and avoid the abuse of the system. It also includes some parameters for automatic detection, such as the request concurrency number, the excluded file types, the excluded domain name list, various keywords for identifying business functions, the relevant configurations of the permission authentication mode, and the relevant parameters about the test target, such as the development framework, the development language, the corresponding parsing logic, etc., as well as various parameters, verification conditions, verification processes, etc. involved in the detection strategy during automatic detection. Among them, in order to reduce test cases and relieve the test pressure on the test environment, the present invention sets the page error echo status to "yes", so that during the detection process of vulnerabilities such as arbitrary file download vulnerabilities and error-displaying SQL injection vulnerabilities, the error echo content can be included in the response returned from the test target, facilitating obtaining the detection results with fewer test cases. The management interface 41 also includes display areas for various data, such as a detection result display area, which is used to display the detection process data and result data of various vulnerabilities, such as the obtained vulnerability risk name, risk level, risk parameters, the corresponding function path, etc., and includes the corresponding detailed information, such as the original request header information, scan information, etc. The function list generation unit 42 is connected to the management interface 41 and generates a list of function points to be tested according to the parameters about the test target configured by the management interface 41 and the source code of the test target. The function point list includes a URL (Uniform Resource Locator) list field, which includes the URLs of each function point to be tested. The function point list can be displayed in the corresponding display area of the management interface. The monitoring unit 43 monitors the detection process according to the monitoring indicators and generates corresponding monitoring notifications according to the monitoring results to be displayed on the management interface 41. For example, when receiving a detection end instruction, it queries whether the function point list is completely detected. When there are still unfinished function points in the function point list, a continue detection reminder notification is issued and displayed on the management interface 41 to remind the security engineer that there are still unfinished function points to be detected, and the vulnerability detection is not allowed to end until all the function points in the function point list are detected.For another example, the function point list further includes a URL identification field, which contains various function identifications to represent the business functions of the current function point. The monitoring unit 43 monitors the URL identification field of the function point. When receiving the detection end instruction, if it detects that a certain identification content in the URL identification field of the function point is not marked, it issues a marking reminder notification to be displayed on the management interface 41 to remind the security engineer to identify the identification content of the identification field of the function point until all the identification content of the function point URL identification field in the function point list is completely identified before allowing the vulnerability detection to end.

[0027] Figure 3 It is a flowchart of a vulnerability detection method provided according to an embodiment of the present invention. The method flow for the security engineer to perform vulnerability detection includes the following steps:

[0028] Step S1, the security engineer makes corresponding configurations or selections through the management interface 41 of the project detection management module 4. Among them, when the test target is not the first detection, the management interface has stored the configurations made during the previous detection. By selecting the corresponding name in the project name parameter item, all the configurations during the previous test can be obtained. The security engineer can directly use the previous configurations or improve the previous configurations according to their own experience. Therefore, the present invention can share detection experience and test strategies among security engineers and can be improved based on the experience of predecessors, so that the test strategy is further improved, thereby improving the test effect, increasing the credibility of the test, and reducing the test cycle.

[0029] Step S2, the function list generation unit 42 of the project detection management module 4 generates a function point list according to the parameters of the test target configured in the management interface 41 and the source code of the test target. In one embodiment, the function point list includes a URL list field, a URL identification field, a function point identity identification field, a detection status field, and so on. Among them, the URL list field records the URLs corresponding to the function points, and the URLs therein include parameters and parameter values. The URL identification field includes various identification contents for indicating business functions, such as one or more of account permissions, information storage, upload functions, sensitive functions, and user private functions, and their status should be marked as "Yes (Y)" or "No (N)". The function point identity identification field can be a hash value calculated based on the URL and parameters in one embodiment, and it is the unique identifier of the identity of this function point. The detection status field can be represented by numbers for different states of this function point, such as the initialization state of not being detected, passing the detection, having risks in detection, having been detected but the detection failed, and so on. Specifically, the function list generation unit 42 obtains the name, development language, and framework of the test project according to the configuration of the test project in the management interface 41, selects the corresponding parsing logic, then reads the source code of the test project from the source code management library, and parses the source code according to the parsing logic to obtain the function points to be detected, thereby generating a function point list. Among them, different development languages and frameworks correspond to different parsing logics. The development languages are, for example, PHP, JAVA,.NET, ASP, Ruby, Python, Vue, and so on, and the development frameworks are, for example, open-source frameworks based on MVC or custom frameworks, custom frameworks based on the three-tier architecture, or some other frameworks. Taking PHP as the development language and an open-source framework based on MVC as an example, the process of generating a function point list is briefly described as follows: First, obtain the Web directory and the starting file through Web container configuration; then parse the starting file index.php, find the application target and name through regular matching, and output the application directory; then obtain the controller path according to the application directory; obtain all file lists of the controller path; then parse the files in the file list to obtain the controller names in the files and the method names in the controllers, and remove private methods such as private, _initialize, and protected; finally, use regular expression matching to obtain the user input parameter names; finally, output the function list, parameters, types, and the unique hash value as the function point identity identification. The hash value is a hash value calculated based on the URL and parameters.

[0030] Step S3, the security engineer sends a test request data packet corresponding to the test target function point through the test terminal browser P. The security engineer can send the test request data packet by clicking the URL in the function point list, or select the corresponding function point through the test terminal browser P in the manual detection tool, and construct the test request data packet by adding or replacing test cases as needed, and then send it through the test terminal browser P.

[0031] Step S4, the test request data packet sent by the test terminal browser 1 is sent to the test target T through the proxy port P, and the response data packet returned by the test target T is received.

[0032] On the one hand, in step S51, as needed, the security engineer performs manual detection, judgment, and determination of whether there are risks based on the security test project document through the manual detection tool 2, and records the detection result, which is called the first detection result. It should be noted that this step is not required for every function point detection. When the security engineer has doubts about the automatic detection result, this step of manual detection can be performed to verify the automatic detection result.

[0033] On the other hand, in step S52, the automatic detection tool 3 connected to the proxy port obtains the test request mirror data packet from the test terminal browser, performs vulnerability detection according to the preset detection policy, and records the detection result, which is called the second detection result.

[0034] Step S6, the security engineer determines whether there are still function points to be detected. If the security engineer decides to end the detection because all function points have been detected, then in step S7, a detection end instruction is issued, such as clicking the end button on the management interface 41. If the security engineer believes that there are still function points not detected, return to step S3 and send a test request data packet for the new function point again.

[0035] When the monitoring unit 43 receives the detection end instruction, it simultaneously executes step S81 and S91, or sequentially executes step S81, S91 or sequentially executes step S91, S81.

[0036] Step S81, query the detection completion progress of the function point list. For example, view the detection status field of each function point.

[0037] Step S82: Determine whether all the function points in the function point list have been detected. Specifically, it can be determined whether the detection is completed by checking the detection status field of each function point. If the number in the detection status field represents the initialization state, it means that the function point has not been detected. Then, a reminder notice for continued detection is sent in step S83 and displayed on the management interface 41. If all the function points in the function point list have been detected, the detection ends. When the security engineer finds that the detection does not end when they press the end button and a notice for continued detection appears, they perform step S3 to complete the corresponding detection according to the undetected function points in the notice. This can avoid missed detections due to human reasons.

[0038] Step S91: Monitor the URL identification field corresponding to each function point. In one embodiment, each function point URL identification field includes URL identification contents such as account permissions, information storage, upload function, sensitive function, and user private function, etc., to indicate the business function of the function point. Each URL identification content has two states, "yes" and "no", and each function point is marked either "yes" or "no". By querying whether each URL identification content of each function point has been marked with "yes" or "no", it can be monitored whether the function point has completed the identification of the business function.

[0039] Step S92: Determine whether the URL identification field of each function point is marked. If the URL identification field of a certain function point or some function points in the function point list is not marked, a marking reminder notice is sent in step S93 and displayed on the management interface 41. If the URL identification field of each function point has been marked, the detection process ends. When the security engineer finds that the detection does not end when they press the end button and a notice for marking the URL identification field appears, they identify the URL identification field of the function point in the function point list in step S94 according to the function point indicated in the notice. Then, step S92 is executed again. In some embodiments, the identification contents of the URL identification fields that need to be identified by the security engineer include sensitive functions and account functions. In these embodiments, each function point in the function list is identified through the manual judgment of the security engineer.

[0040] By parsing the source code of the test target, the present invention can obtain a list of function points, and the detection can only end after all function points in the function point list are detected, thus achieving full coverage of business function points. After each detection, all configurations are stored in the corresponding parameter items, which can accumulate the research results and experience of security engineers and share them with other security engineers. The present invention can collect historical information of test projects and provide a basis for subsequent security tests. For a test project, after the function points are functionally identified, the identification is stored in the identification field. After being identified and reviewed by engineers during the first test, engineer identification is no longer required, simplifying the process for subsequent detections and reducing dependence on engineers, enabling the system to automatically and accurately perform automatic detections.

[0041] Figure 4 FIG. is a schematic block diagram of the principle of an automatic detection tool according to an embodiment of the present invention. Among them, the automatic detection tool includes a data packet acquisition module 31, a data packet analysis module 32, and a detection module 33. Among them, the data packet acquisition module 31 is connected to the proxy port P, obtains the mirror data packet corresponding to the function point sent by the test-end browser 1 to the test target T from the preset proxy port P, sends an automatic test request data packet constructed by the automatic detection tool to the test target T, and receives the response data packet returned by the test target T. The data packet analysis module 32 is connected to the data packet acquisition module 31 and is used to parse the mirror data packet and the response data packet, and at least obtain the URL without parameters, parameters and parameter values, function point identity identification, and function point detection identification from the mirror data packet; at least obtain the response content from the response data packet. Among them, as Figure 5 shown, the data packet analysis module 32 includes a request packet parsing unit 321, a response packet parsing unit 322, a marking unit 323, a hash value calculation unit 324, and a cleaning unit 325.

[0042] The request packet parsing unit 321 is used to parse the request header, request parameters and user credentials of the mirror data packet. By parsing the request header of the mirror data packet, parameters in the request header, such as Cookie, x-forward, refer and user-agent, can be obtained. First, the parameter name is verified according to the corresponding configuration in the management interface 41, and then the parameters that do not need to be detected are removed, and then it is determined whether there is a Cookie field in the remaining parameters. If so, Cookie is removed, and the request header parameters are obtained at this time, and the marking unit 323 is notified to mark "found authentication mark" in the URL identification field of the corresponding function point in the function point list; if there is no Cookie parameter in the parameter, the marking unit 323 is notified to mark the URL identification field of the corresponding function point in the function point list as "not found authentication mark". When parsing the request parameters, firstly, according to the request type, such as GET request type or POST request type, the corresponding URL parsing is performed to obtain GET parameters or POST parameters. The cleaning unit 325 is connected to the request packet parsing unit 321 to determine whether the parameter value includes a test case. If the test case is included, it is deleted, thereby obtaining the URL, parameters and corresponding parameter values without the parameters. When parsing the user credentials, first read the permission authentication mode configured in the management interface 41, such as Cookie mode or API mode, and read the authentication identification keywords in the configuration, such as sign, token or key. If the authentication mode in the mirror data packet is Cookie mode, parse the Cookie field to obtain the parameter name, such as username, ci_session. Among them, ci_session is an authentication credential parameter, which will be inaccessible after tampering, so it is necessary to perform permission detection, and therefore it is necessary to mark "discover authentication identification" in the URL identification field. At this time, remove the authentication credentials, thereby obtaining the request parameter without the fixed value. If the authentication mode in the mirror data packet is API mode, query whether the parameter name matches the authentication keyword configured in the management interface. If it matches, remove the authentication keyword, and notify the marking unit 323 to mark "discover authentication identification" in the URL identification field of the corresponding function point in the function point list. If the parameter name does not match the authentication keyword configured in the management interface, the notification marking unit 323 marks "no authentication identifier found" in the URL identifier field of the corresponding function point in the function point list. The request packet parsing unit 321 parses the URL, parameters and parameter values without parameters.

[0043] The response packet parsing unit 322 obtains a response status code from the response packet, such as a code indicating success, redirection, client error or server error, and obtains information such as the response packet length and the response packet content through header parsing.

[0044] The marking unit 323 is connected to the request packet parsing unit 321. After the parsing by the request packet parsing unit 321 is completed, it reads the parsed parameters and parameter values, and determines whether the business function of the function point is an upload function and whether it belongs to a private function according to the parameters configured in the management interface 41. And it marks the upload function and user private function in the URL identification field of the function point as "yes" or "no" according to the determined result. Further, when the marking unit 323 marks "authentication identifier found" according to the notification of the request packet parsing unit 321, it sends a confirmation notice to the management interface 41 to remind the security engineer to identify the "account permission" in the URL identification field of this function point according to the marking. In addition, during the detection process of the marking unit 323, when an open-source crawler engine is required to crawl function points, if a function point can be crawled, the "account permission" in the URL identification field of this function point is marked as "no". For example, an A account user can access the URL of his own private function and the function URL on the public home page; when using a NoAuth (unlogged user) account to access the private function URL of the A account and the public home page function, the result should be that the access to the private function URL of the A account fails and the access to the public home page function URL is successful. Therefore, if it is found during the detection process that both the A account and the NoAuth account can access a function point URL, there may be a permission risk. To verify such permission risks, the detection module enables the crawler engine to use a NoAuth (unlogged user) account or a General Auth (ordinary user) to crawl function links. If a function link can be crawled, it means that this function point does not have a permission function, and this function point may be the aforementioned public home page function. Therefore, it notifies the marking unit 323 to mark the "account permission" in the URL identification field of this function point as "no".

[0045] The hash value calculation unit 324 is connected to the request packet parsing unit 321, calculates a first hash value according to the URL and parameters after removing the parameters, and calculates a second hash value according to the URL, parameters and parameter values after removing the parameters. The first hash value is used as the identity identifier of the function point, and the second hash value is used as the function point detection identifier.

[0046] The detection module 33 is connected to the data packet analysis module 32, and performs vulnerability detection based on the mirror data packet and its parsing result according to the preset detection strategy. In the present invention, various vulnerabilities to be detected are grouped according to the verification type of the vulnerabilities, and corresponding detection processes are set for different vulnerability groups. And the corresponding detection model unit executes the detection process corresponding to the verification type. Such as Figure 6As shown in the figure, the detection module 33 includes a detection management unit 330 and multiple detection model units 331, 332, …… 33n. The detection management unit 330 controls the multiple detection model units to perform vulnerability detection orderly according to the detection process. For example, according to the running state of the detection, the detection management unit 330 divides the multiple vulnerability groups into an initialization vulnerability group and a running-state vulnerability group, and sets different detection strategies. For example, first detect the initialization vulnerability group, and then detect the running-state vulnerability group. The initialization vulnerability group is detected by one request. For the running-state vulnerability group, according to the vulnerability type, a detection strategy combining coarse-grained and fine-grained detection, or a detection strategy of coarse-grained and result verification is implemented. When performing coarse-grained detection, a small number of test cases, such as 1-5, are used to complete the detection through one request. After obtaining a suspected risk, fine-grained detection or verification according to the vulnerability type is performed. The detection management unit 330 also maintains a request record table that can be displayed through the management interface 41, which records details of vulnerability detection, such as the original test request data packet, URL, function point identity identifier, function point detection status identifier, risk status, risk type, risk level, etc. Each detection model unit is used to complete the detection of a vulnerability group of a verification type. The detection management unit 330 coordinates multiple detection model units to detect the vulnerabilities of their verification types according to the scanning strategy, and each detection model unit completes the detection of a vulnerability group of a verification type according to the instructions of the detection management unit and the detection strategy.

[0047] As Figure 7 shown, the following is the process of the detection module 33 detecting a function point, which includes the following steps:

[0048] Step S1a, the detection management unit 330 receives the mirror data packet and its parsing result from the data packet analysis module 32.

[0049] Step S2a, the detection management unit 330 compares the first hash value with the hash value in the identity identifier field in the function point list.

[0050] Step S3a, determine whether the first hash value as the function point identity identifier is in the function point list. If not, in step S4a, add data such as the URL address and parameters in the mirror data packet to the corresponding fields in the function point list, so as to make up for the function points missed when generating the function point list; if so, execute step S5a.

[0051] Step S5a, the detection management unit 330 queries the function point detection identifier field in the request record table.

[0052] Step S6a, determine whether the second hash value is in the request record table, that is, whether the second hash value is already included in the function point detection identification field. If the second hash value is in the function point detection identification field, it indicates that the function point has been detected and there is no need to detect it again at this time, and the detection of this function point ends, thus avoiding duplicate detection of function points. If not, execute step S7a.

[0053] Step S7a, scan the initialization vulnerability group for initialization detection. The detection management unit 330 controls the detection model unit corresponding to the initialization vulnerability group to perform vulnerability detection in sequence according to the vulnerability type. In one embodiment, the initialization vulnerability group is the initialization response content verification type, and the corresponding detection model unit 331 sends a test request once for each vulnerability type included in the initialization vulnerability group based on the mirror data packet (i.e., the original data packet) to complete the detection. The corresponding vulnerability types are, for example, server fingerprint leakage vulnerability, HTTP request mode vulnerability, and sensitive information plaintext transmission vulnerability.

[0054] Taking the detection of the server fingerprint leakage vulnerability as an example, illustrate the process of the detection model unit 331, as Figure 8 shown:

[0055] Step S1b, the detection model unit 331 puts the mirror data packet into the request queue. In the actual detection process, there may be mirror data packets of multiple function points that need to perform vulnerability detection of the initialization response content verification type. Therefore, these mirror data packets for function point detection are put into the request queue for queuing.

[0056] Step S2b, determine whether the mirror data packet reaches the top of the request queue. If it reaches the top of the request queue, then in step S3b, send it to the test target T through the data packet acquisition module 31; if it does not reach the top, wait.

[0057] Step S4b, receive the response content of the response packet parsed by the data packet analysis module 32.

[0058] Step S5b, analyze the response content to determine whether there is a risk. Corresponding to the server fingerprint leakage vulnerability, identify whether the parameter value in the response content contains numbers through regular expressions. When the parameter value in the response content contains numbers, it is determined that there is a risk. For example: when the response content contains "X-Powered-By:PHP 5.2.5", it contains the specific version of the number "5.2.5", and it is confirmed that there is a risk; when the response content does not contain numbers, such as when the response content is "X-Powered-By:PHP", it is confirmed that there is no risk.

[0059] Step S6b, record the detection result in the request record table.

[0060] Step S8a, the vulnerability detection is sequentially performed on the running state vulnerability group. The detection management unit 330 controls multiple detection model units to sequentially complete the detection of corresponding vulnerabilities. One vulnerability detection process of the running state vulnerability group is as follows Figure 9 shown as:

[0061] Step S1c, construct a first automatic test data packet based on the vulnerability verification type. Among them, for the vulnerabilities of response content verification type and request replay verification type, the first automatic test data packet is the original mirror data packet; for the vulnerabilities of request-response verification type, the first automatic test data packet is formed by adding a preset test case to the parameter value of the original mirror data packet; for the vulnerabilities of replacement request-response verification type, the first automatic test data packet is formed by replacing the parameter value of the original mirror data packet with a preset test case; for the vulnerabilities of login credential replacement verification type, the first automatic test data packet is formed by replacing the original user authentication credential in the original mirror data packet with a preset authentication credential.

[0062] Step S2c, the corresponding detection model unit puts the first automatic test data packet into its internal request queue.

[0063] Step S3c, determine whether the first automatic test data packet reaches the top of the request queue. If it reaches the top of the request queue, then in step S4c, send it to the test target T through the data packet acquisition module 31; if it does not reach the top, then wait.

[0064] Step S5c, receive the response content of the response packet parsed by the data packet analysis module 32.

[0065] Step S6c, analyze the response content. When analyzing the response content, analyze it according to the corresponding policy based on the verification type to which the vulnerability belongs. For example, for the vulnerabilities of request-response verification type, replacement request-response verification type, response content verification type, etc., analyze whether the response content contains the content preset in the detection policy; for the vulnerabilities of login credential replacement verification type, compare the two response contents; for the vulnerabilities of request replay verification type, compare the response to the original request and the response to the replayed request.

[0066] Step S7c: Determine whether the requirements for suspected risks are met. If not, it indicates no risk, then confirm the detection as passed in Step S8c and record the detection result in the request record form; if met, it indicates possible risks, then execute Step S9c. For example, for the reflected cross-site scripting risk belonging to the request-response verification type, when the original echo appears in the response content, it is considered that the requirements for suspected risks are met and confirmed as a suspected risk; for the unauthorized access vulnerability belonging to the login credential replacement verification type, when the two response contents are highly similar, it is considered that the requirements for suspected risks are met and confirmed as a suspected risk; for the cross-site request forgery vulnerability belonging to the request replay verification type, when the two request responses are exactly the same, it is considered that the requirements for suspected risks are met and confirmed as a possible risk.

[0067] Step S9c: Obtain the secondary test conditions for the vulnerability with the suspected risk. The secondary test conditions vary according to different vulnerability types and are recorded in the detection strategy. The secondary test conditions can be obtained by querying the detection strategy. For example, some have no restrictions on test conditions, such as the reflected cross-site scripting risk belonging to the request-response verification type, the sensitive information leakage vulnerability belonging to the response verification test, etc.; some test conditions stipulate that the verification needs to be performed according to the status of the relevant marker content in the URL marker field.

[0068] Step S10c: Perform secondary testing or verification according to the corresponding test conditions.

[0069] Step S11c: Determine whether the result of the secondary testing or verification is a risk. If so, in Step S12c, modify the risk status in the request record form from "suspected" to "confirmed" and end this detection; if it is not a risk after the secondary testing or verification, in Step S13c, modify the risk status in the request record form from "suspected" to "false positive" and end this detection.

[0070] In Step S10c, for different test conditions, the processes and judgment bases of the secondary testing or verification are also different. For example, for the reflected cross-site scripting risk belonging to the request-response verification type and the sensitive information leakage vulnerability belonging to the response verification test that do not require any test conditions, directly perform secondary testing, such as reconstructing the test request data packet, sending it to the test target, and analyzing the returned response content. According to whether the requirements for risks are met, modify the risk status "suspected" in the request record form to "confirmed" or "false positive".

[0071] For vulnerabilities that require verifying the marking status of the identification content in the URL identification field, for example, when a suspected risk is found during a rough detection of an unauthorized access vulnerability, query whether the marking of the identification content "account permission" in the URL identification field of the function point is "Yes (Y)" or "No (N)". If the marking of "account permission" is "Yes (Y)", it is confirmed that the risk of this vulnerability type actually exists, and the risk status in the request record table is modified from "suspected" to "confirmed". If the marking of "account permission" is "No (N)", the risk status is modified from "suspected" to "false positive". Another example is when a suspected risk occurs during the detection of a horizontal privilege escalation vulnerability. First, query whether the marking of the identification content "account permission" in the URL identification field of the function point is "Yes (Y)" or "No (N)". If the marking of "account permission" is "No (N)", the risk status is modified from "suspected" to "false positive". If the marking of "account permission" is "Yes (Y)", then query whether the marking of "user private function" is "Yes (Y)" or "No (N)". If it is "No (N)", the risk status is modified from "suspected" to "false positive". If it is "Yes (Y)", it is confirmed that the risk of this vulnerability type actually exists, and the risk status in the request record table is modified from "suspected" to "confirmed".

[0072] When it is determined that the function point has a user authentication credential during the parsing of the function point and the "account permission" of this function point has not been marked by the security engineer, start the crawler engine and use the NoAuth (unlogged-in user) account or GeneralAuth (ordinary user) to capture the function link. If the function link can be captured, it indicates that this function point does not have a permission function, and this function point may be the aforementioned public home page function. Therefore, notify the marking unit 323 to mark the "account permission" in the URL identification field of this function point as "No". According to the aforementioned verification process, the suspected risk with the "account permission" marked as "No" is excluded.

[0073] Among them, the verification moment can occur during the detection process or before the end of the detection process and the test. For example, for the verification of the "information storage function", after the detection is completed and the security engineer marks all URL functions, when the "information storage function" of the function point is marked as "Yes", the security engineer needs to manually write the specified payload: sectxss'"<> in the form item. This system automatically replays all test requests with the "information storage function" marked as N and verifies the response packet for each test request.

[0074] In one embodiment, as Figure 10As shown in the figure, a detection model unit 331 includes a request queue 3311, a sending subunit 3312, a receiving subunit 3313, and a verification subunit 3314. The request queue 3311 is used to store test request data packets sent to a test target. Among them, the test request data packet is a mirror data packet used for detecting vulnerabilities in the initialized vulnerability group, or can also be a test request data packet constructed for coarse-grained detection of vulnerabilities in the running state vulnerabilities or a new test request data packet for fine-grained detection. The sending subunit 3312 sequentially extracts test request data packets from the request queue and sends them to the test target system through the proxy port via the data packet acquisition module 31. The receiving subunit 3313 is connected to the data packet analysis module 32 and receives the response content parsed from the response packet returned from the test target. The verification subunit 3314 is built-in with a detection strategy corresponding to the verification type it detects, and verifies the returned response data according to the detection strategy to determine whether there is a risk of corresponding vulnerabilities, and sends the verification result to the detection management unit 330. For example, for the reflected cross-site scripting risk vulnerability of the request-response verification type, 4 test cases are included in the sent test request data packet. The verification subunit 3314 verifies whether the original echo appears in the response content. If the original echo appears, it is determined as a suspected risk.

[0075] In some detection model units, such as the detection model units used for detecting vulnerability groups of the request-response verification type, the replacement request-response verification type, and the login credential replacement verification type, there is also a test request construction subunit 3310, which is used to construct new test request data packets. For example, in the detection model unit used for detecting the vulnerability group of the request-response verification type, the test request construction subunit 3310 adds test cases to the parameter values of the mirror data packet, combines the added test cases with the original parameter values into an attack payload, and together constitutes a test request data packet. The number of test cases can vary according to the vulnerability type, whether it is coarse-grained (level1) or fine-grained (level 2). For example, for any file download vulnerability belonging to the request-response verification type, 1 test case is used in coarse-grained detection, and more than 1 test case is used in fine-grained detection. For the reflected cross-site scripting risk belonging to the request-response verification type, 4 test cases are used in coarse-grained detection, and more than 4 test cases are used in fine-grained detection. For any file upload vulnerability belonging to the replacement request-response verification type, 3 test cases are used in coarse-grained detection.

[0076] In the detection model unit for detecting replacement request response verification vulnerability groups, the test request construction subunit 3310 replaces the parameter values in the mirror data packet with test cases to form a test request data packet. When the verification type of the vulnerability group is login credential replacement verification, 3310 replaces the user authentication credentials in the mirror data packet with the authentication credentials of users at different levels to form multiple said automatic test request data packets. For example, for unauthorized access vulnerabilities belonging to the login credential replacement verification type, the user authentication credentials in the mirror data packet are replaced with the credentials of an unlogged-in user account and the authentication credentials of a high-privilege user such as an administrator to obtain two test request data packets. Correspondingly, the verification subunit 3314 compares the response contents returned by these two test requests. If the response contents are highly similar, it is determined as a suspected vulnerability.

[0077] The detection management unit 330 receives the verification result obtained by the detection model unit 331. When the detection management unit 330 receives a verification result of suspected risk sent by the detection model unit, it determines whether to perform fine-grained detection or result verification according to the vulnerability type. For example, for request response verification vulnerability groups such as reflected cross-site scripting risks, error-displaying SQL injection vulnerabilities, arbitrary file download vulnerabilities, etc., when the coarse-grained detection result is a suspected risk, a certain amount of test cases are reused to construct test request data packets for fine-grained detection. If it is still a risk according to the detection strategy, the current suspected risk can be confirmed to have this vulnerability. For example, for suspected risks of arbitrary file download vulnerabilities and error-displaying SQL injection vulnerabilities, when verifying with new test cases during the fine-grained (level 2) detection process, if the request response contents are different for the two times, the vulnerability is confirmed. Another example is for suspected risks of reflected cross-site scripting risks. When using new test cases during the fine-grained (level 2) detection process, if the original echo still appears in the returned response content, the vulnerability is confirmed. When the suspected risk is obtained from detecting an arbitrary file upload vulnerability, the detection management unit 330 directly confirms it as a risk.

[0078] For some suspected risks of vulnerabilities, it is only necessary to verify the coarse-grained detection results according to the business functions of the function points. Therefore, in one embodiment, the detection module 33 further includes a result verification unit 334, which is connected to the detection management unit 330 and is configured to receive the result verification instruction of the detection management unit 330 and verify the suspected risks according to the verification policy. Among them, the vulnerabilities that need to be verified are, for example, some vulnerabilities related to permissions, such as horizontal privilege escalation vulnerabilities, unauthorized access vulnerabilities, and vertical privilege escalation vulnerabilities, and can also be some vulnerabilities related to sensitive functions, such as cross-site request forgery vulnerabilities, etc. Therefore, the result verification unit 334 can be one, and verify the vulnerabilities that need result verification one by one according to the corresponding verification mechanism. The result verification unit 334 can also be multiple, corresponding to different vulnerability result verifications respectively.

[0079] Among them, for permission-related vulnerabilities such as horizontal privilege escalation vulnerabilities, unauthorized access vulnerabilities, and vertical privilege escalation vulnerabilities, the result verification unit 334 queries the identification content in the URL mark field that is the mark of account permissions. When there is no mark for account permissions, the crawler engine is started to capture the function point links. For example, for the unauthorized access vulnerability, the crawler engine is started to capture the function point links using an unlogged-in account; for the vertical privilege escalation vulnerability, the crawler engine is started to capture the function point links using a normal account. When the function point links are captured, the account permissions in the function point URL mark field are marked as "no", and the risk is excluded, that is, the current risk status is changed from "suspected" to "false positive".

[0080] For horizontal privilege escalation vulnerabilities and vertical privilege escalation vulnerabilities, when the result verification unit 334 queries that the mark of the account permissions in the URL mark field is "yes", it queries the mark of the user's private function; when the mark of the user's private function is "yes", the risk is confirmed, that is, the current risk status is changed from "suspected" to "confirmed", and when the mark of the user's private function is "no", the risk is excluded.

[0081] For the unauthorized access vulnerability, when the result verification unit 334 queries that the mark of the account permissions in the URL mark field is "yes", the risk is excluded.

[0082] In addition, for the cross-site request forgery vulnerability, the result verification unit 334 queries the sensitive function of the current function point URL mark field. When its mark is "yes", the risk is confirmed; when its mark is "no", the risk is excluded.

[0083] The detection management unit 330 checks whether all identification contents in the URL tag fields are marked after the detection of all function points is completed, and queries the identification contents marked as information storage in the URL tag fields of each function point. For the function points marked as "no", the detection of stored cross-site scripting vulnerabilities is performed again. That is, an instruction to send a replay request is sent to the detection model unit for detecting stored cross-site scripting vulnerabilities. The detection model unit for detecting stored cross-site scripting vulnerabilities resends a test request data packet according to the instruction, and its verification subunit compares the response content of the current request with the response content during the rough detection to confirm whether it is a risk according to the comparison result.

[0084] The present invention classifies vulnerabilities into different groups according to the verification type, and the verification type is, for example, request-response verification type, replacement request-response verification type, login credential replacement verification type, response content verification type or request replay verification type. For vulnerabilities of different verification types, different detection strategies are adopted according to their vulnerability types, and each is executed by a detection model unit. Due to reasons such as the version update of the test target, the types of vulnerabilities are constantly changing, and new vulnerabilities may appear at any time. When new vulnerabilities appear, since the present invention adopts the detection model unit mode, only the corresponding verification type needs to be matched for the new vulnerabilities and added to the corresponding group. Or, when there is no existing verification type that matches it, a separate detection model unit can be added for it, which will not affect the operation of other detection model units. This modular detection mode has good scalability and can add or delete certain vulnerability detections at any time. Since the detection process of the detection model unit is made standardized and the detection items are also in a standardized form, when adding vulnerability detections, security engineers only need to modify relevant parameter items at the front end (such as the management interface provided by the present invention), such as adding vulnerability names, types, setting their corresponding verification types, or adding new verification types, etc., thus greatly reducing the dependence on developers and reducing the intervention and workload of developers. And due to the standardization of the detection process and strategies, even junior security engineers with only basic knowledge can complete the final vulnerability review, while senior engineers focus on formulating detection strategies and researching new rules. The present invention splits the detection process into two steps: initial coarse-grained security detection and fine-grained security detection during review. Only a small number of optimal test cases are configured for the coarse-grained security detection. If a suspected vulnerability appears, a large number of accurate test cases are called for review. Therefore, the performance requirements for the test server are not high, and the security detection of vulnerabilities can be quickly completed in a test environment with poor performance, with high accuracy and efficiency.

[0085] The above embodiments are only for illustrating the present invention and are not intended to limit the present invention. Those of ordinary skill in the relevant technical field can still make various changes and modifications without departing from the scope of the present invention. Therefore, all equivalent technical solutions should also fall within the scope of the disclosure of the present invention.

Claims

1. A vulnerability detection method, in which multiple vulnerabilities to be detected are divided into an initialization vulnerability group and a running-state vulnerability group. The running-state vulnerability group is divided into multiple different vulnerability groups according to the verification type, and each vulnerability group corresponds to a corresponding detection strategy. The method includes: Obtaining an image data packet for testing a function point from a request sent by a test-end browser to a test target; Parsing the image data packet to obtain the URL without parameters, parameters, and parameter values of the current request; Based on the image data packet, sequentially performing initialization vulnerability detection on each vulnerability in the initialization vulnerability group according to the corresponding detection strategy; And According to the verification type of each running-state vulnerability group, constructing an automatic test request data packet based on the image data packet and its parsing result, and sequentially performing coarse-grained detection on one or more vulnerabilities in the vulnerability group; when a suspected risk occurs in the coarse-grained detection, querying the detection strategy of the vulnerability, and in response to no restrictions on the test conditions set in the detection strategy, performing fine-grained detection; in response to the test conditions and verification mechanism set in the detection strategy, performing corresponding result verification to confirm or exclude the suspected risk; the verification mechanism includes verifying according to the marking status of the corresponding identification content in the function point URL marking field; wherein the identification content in the URL marking field includes account permissions, information storage, upload function, sensitive function, and user private function, and the marking status is "yes" or "no"; The number of test cases used in the coarse-grained detection is at least one, and the number of test cases used in the coarse-grained detection is less than the number of test cases used in the fine-grained detection; Among them, when a suspected risk occurs in the coarse-grained detection, result verification is performed on permission-type vulnerabilities; the method further includes: after all function points are detected and all identification contents in the URL marking field are marked, querying the marking of the identification content in the URL marking field of each function point as information storage, and re-detecting the stored cross-site scripting vulnerability for the function points marked as "no".

2. The method according to claim 1, wherein the verification types of the running-state vulnerability group include one or more of request-response verification type, replacement request-response verification type, login credential replacement verification type, response content verification type, and request replay verification type; Among them, When the verification type of the vulnerability group is the response content verification type and the request replay verification type, using the original image data packet as the automatic test request data packet; When the verification type of the vulnerability group is the request-response verification type, adding 1-5 test cases to the image data packet to form the automatic test request data packet; When the verification type of the vulnerability group is the replacement request-response verification type, replacing the parameter values in the image data packet with 1-5 test cases to form the automatic test request data packet; When the verification type of the vulnerability group is the login credential replacement verification type, replacing the user authentication credentials in the image data packet with the authentication credentials of different-level users respectively to form multiple automatic test request data packets.

3. The method according to claim 1, wherein the fine-grained detection includes: Change the test cases in the automatic test request data packet, and perform one or more detections based on the new automatic test request data packet according to the detection strategy corresponding to the verification type.

4. The method according to claim 1, wherein when performing result verification, for privilege - type vulnerabilities, in response to the flag of the account privilege in the URL flag field being "no", the suspected risk is excluded.

5. The method according to claim 4, wherein when performing result verification, for unauthorized access vulnerabilities, the crawler engine is enabled to use an unlogged - in account to crawl the function - point link, and for vertical privilege escalation vulnerabilities, the crawler engine is enabled to use a normal account to crawl the function - point link; and when the function - point link is crawled, the suspected risk is excluded.

6. The method according to claim 5, further comprising: In response to the crawler engine crawling the function - point link and the account privilege in the function - point URL flag field not being marked, mark the account privilege in the function - point URL flag field as "no".

7. The method according to claim 4, wherein when performing result verification, for horizontal privilege escalation vulnerabilities, in response to the flag of the account privilege in the URL flag field being "yes", query the flag of the user - private function; and in response to the flag of the user - private function being "yes", confirm the suspected risk, and in response to the flag of the user - private function being "no", exclude the suspected risk.

8. The method according to claim 1, wherein when performing result verification, for cross - site request forgery vulnerabilities, in response to the flag of the sensitive function in the URL flag field being "no", exclude the suspected risk, and in response to the flag of the sensitive function being "yes", confirm the suspected risk.

9. The method according to claim 1, wherein after all vulnerability detections are completed, query whether all the identification contents in the function - point URL flag field are all marked; and In response to the flag of the information storage in the URL flag field being "no", perform detection according to the response - content verification - type strategy.

10. The method according to claim 1, further comprising: At least set the page error echo mode in the detection strategy of the request - response verification - type vulnerability group.

11. A vulnerability detection system, which includes a data packet acquisition module, a data packet analysis module, and a detection module, where, The detection module includes a detection management unit and a plurality of detection model units; The data - packet acquisition module is configured to obtain from a preset proxy port an image data packet for testing a function - point sent by a test - end browser to a test target, send a test - request data packet to the test target, and receive a corresponding response data packet returned by the test target; The data - packet analysis module is connected to the data - packet acquisition module and is configured to parse the image data packet and the response data packet; The detection management unit is connected to the data packet analysis module, and coordinates multiple detection model units to detect multiple vulnerabilities according to a preset scanning strategy. Among them, the multiple vulnerabilities are divided into an initialization vulnerability group and a running-state vulnerability group. The running-state vulnerability group is divided into multiple different vulnerability groups according to the verification type, and each vulnerability group is set with a corresponding detection strategy. For the running-state vulnerability group, based on the verification type of each running-state vulnerability group, an automatic test request data packet is constructed based on the mirror data packet and its parsing result, and coarse-grained detection is sequentially performed on one or more vulnerabilities in this vulnerability group. When a suspected risk occurs in the coarse-grained detection, the detection strategy of the vulnerability is queried, and fine-grained detection is performed in response to the test conditions set in the detection strategy without restrictions. In response to the test conditions and verification mechanism set in the detection strategy, corresponding result verification is performed to confirm or eliminate the suspected risk. The verification mechanism includes verifying according to the marking status of the corresponding identification content in the URL marking field of the function point. The identification content in the URL marking field includes account permissions, information storage, upload function, sensitive function, and user private function, and the marking status is "yes" or "no". The multiple detection model units are respectively connected to the detection management unit, the data packet analysis module, and the data packet acquisition module. Each detection model unit completes the detection of a vulnerability group of one verification type according to the instruction of the detection management unit and the detection strategy. The number of test cases used in the coarse-grained detection is at least one, and the number of test cases used in the coarse-grained detection is less than the number of test cases used in the fine-grained detection. The detection module further includes a result verification unit, which performs result verification on permission-type vulnerabilities when a suspected risk occurs in the coarse-grained detection. After all function points are detected and all identification contents in the URL marking field are marked, the detection management unit queries the marking of the identification content in the URL marking field of each function point as information storage, and re-detects the stored cross-site scripting vulnerability for the function points marked as "no".

12. The vulnerability detection system according to claim 11, wherein the data packet analysis module includes: A request packet parsing unit, configured to parse the request header, request parameters, and user credentials of the mirror data packet to obtain the URL without parameters, parameters, and parameter values. A response packet parsing unit, configured to parse the response packet returned from the test target to obtain the response packet content. A marking unit, configured to identify and mark the URL identification field of the function point according to the parsed parameters. And A cleaning unit, configured to identify and clean the test cases in the mirror data packet.

13. The vulnerability detection system according to claim 11, wherein the detection model unit at least includes: A request queue, configured to store the test request data packets sent to the test target, where the test request data packets are the mirror data packets, automatic test data packets for coarse-grained detection, or new automatic test request data packets for fine-grained detection. A sending subunit, configured to sequentially retrieve test request data packets from the request queue and send them to a test target system through a proxy port; A receiving subunit, configured to receive the response content of the response packet returned by the data packet analysis module; and A verification subunit, configured to verify the returned response content according to the detection policy corresponding to the verification type, and determine the risk of corresponding vulnerabilities according to the verification result.

14. The vulnerability detection system according to claim 13, wherein when the verification type corresponding to the detection model unit is request-response verification type, replacement request-response verification type or login credential replacement verification type, the detection model unit further includes a test request construction subunit, configured to add test cases to the parameter values of the mirror data packet or replace the original parameter values with corresponding test cases to construct an automatic test request data packet.

15. The vulnerability detection system according to claim 11, wherein the result verification unit is connected to the detection management unit, configured to receive the result verification instruction of the detection management unit, and verify the vulnerabilities with suspected risks according to the verification policy.

16. The vulnerability detection system according to claim 15, wherein there are multiple result verification units, and they respectively verify different vulnerabilities with suspected risks according to the identification content of the corresponding URL identification field.

Images