A method and system for verifying the credibility of a vulnerability detection tool

Abstract

The present invention relates to a method and system for verifying the credibility of a vulnerability detection tool. The method includes: sending a function point test request to a test target based on a test-side browser; a manual detection tool intercepts the data packet of the test request, and a security engineer manually detects according to a vulnerability detection strategy to obtain a first detection result corresponding to the function point; an automatic detection tool obtains a mirror data packet of the test request, and performs vulnerability detection on the function point corresponding to the mirror data packet according to a preset detection strategy to obtain a second detection result; comparing the first detection result and the second detection result; and determining the credibility of the automatic detection tool for detecting the function point vulnerability according to the comparison result. The present invention verifies an automatic vulnerability detection tool based on the manual detection result, only requires a security engineer to give confirmation when necessary, does not require too much manual participation, has little influence of human factors, and has high verification efficiency.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and particularly to a method and system for verifying the credibility of vulnerability detection tools. 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 for manual testing 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 reserves, and their 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 native PHP mode, self-written mode based on the MVC framework, 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 and Green Alliance Aurora, 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 traditional automated scanner crawlers can obtain most business function points, they 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 untrustworthy results.

[0007] Fourth, the test environment is limited. 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 method and system for verifying the credibility of a vulnerability detection tool, so as to verify the credibility of the detection tool when performing vulnerability detection, and improve the credibility of the vulnerability detection results.

[0010] To solve the above technical problems, according to one aspect of the present invention, there is provided a method for verifying the credibility of a vulnerability detection tool, which includes: sending a function point test request to a test target based on a test-side browser; the manual detection tool intercepts the data packet of the test request, and a security engineer manually detects according to the vulnerability detection strategy to obtain a first detection result corresponding to the function point; the automatic detection tool obtains the mirror data packet of the test request, and performs vulnerability detection on the function point corresponding to the mirror data packet according to the preset detection strategy to obtain a second detection result; comparing the first detection result and the second detection result; and determining the credibility of the automatic detection tool for the vulnerability detection of the function point according to the comparison result.

[0011] To solve the above technical problems, according to another aspect of the present invention, there is provided a system for verifying the credibility of a vulnerability detection tool, which includes a test-side browser, a manual detection tool, an automatic detection tool and a credibility verification module. Among them, the test-side browser is configured to send a function point test request to a test target through a preset proxy port and receive the response data packet returned from the test target; the manual detection tool is configured to intercept the test request data packet sent to the test target, provide a manual detection interface for a security engineer to manually detect, and obtain a first detection result; the automatic detection tool is configured to obtain the mirror data packet of the function point test request from the test-side browser sent through the proxy port, and perform vulnerability detection on the function point corresponding to the mirror data packet according to the preset detection strategy to obtain a second detection result; the credibility verification module is connected to the manual detection tool and the automatic detection tool, and is configured to compare the first detection result and the second detection result; and determine the credibility of the automatic detection tool according to the comparison result.

[0012] The present invention verifies an automatic vulnerability detection tool based on manual detection results to confirm whether the automatic vulnerability detection tool can accurately detect vulnerability risks during automatic detection, and automatically updates the automatic vulnerability detection tool based on the verification data to ensure the accuracy of vulnerability detection by the automatic detection tool. The verification process only requires confirmation from security engineers when necessary and does not require excessive manual participation, thus having little influence from human factors; and it can be verified in real time during the detection process, and the verification result can be obtained when the detection is completed, with high verification efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

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

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

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

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

[0023] Figure 10 is a schematic block diagram of a detection model unit according to an embodiment of the present invention;

[0024] Figure 11 is a flowchart of a method for verifying the credibility of an automatic detection tool according to an embodiment of the present invention;

[0025] Figure 12 is a flowchart of a verification method during a vulnerability detection process at a functional point according to an embodiment of the present invention;

[0026] Figure 13 is a block diagram of the principle of an automatic detection tool credibility verification system provided according to an embodiment of the present invention; and

[0027] Figure 14 is a block diagram of the principle of a credibility verification module provided according to an embodiment of the present invention. Detailed implementation manners

[0028] 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.

[0029] In the following detailed description, reference may be made to the various specification drawings that form a part of this application and 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 application are described in sufficient detail below to enable those of ordinary skill in the relevant art and technology to implement the technical solutions of the 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 application.

[0030] Figure 1 is a 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, an optional 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 test-end browser 1, the manual detection tool 2, and the automatic detection tool 3. The test-end browser 1 is a browser used by security engineers. By configuring the browser proxy server on the computer used by the security engineer to set the specified proxy port P, the test-end browser 1 connects to the proxy port P. For example, in one embodiment, select proxy scanning through FoxyProxy and specify the proxy IP address. Under this configuration, the test requests sent through the test-end browser 1 can be intercepted by the automatic detection tool 3. The manual detection tool 2 is an optional existing manual vulnerability detection device. When the manual detection tool 2 is needed, select the manual detection tool bump configured on the security engineer's computer through FoxyProxy, and then set the proxy server in the operation interface provided by the manual detection tool bump. Under this configuration, when the test-end browser 1 sends a test request, the manual detection tool bump intercepts the data packet of the test request and provides it to the security engineer through the operation interface. The security engineer manually tampers with the data packet of the test request, manually views the returned results, and manually determines whether there is a vulnerability risk..

[0031] Such as Figure 2As shown in the figure, 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, the display of detection process and result data, and notifications. Among them, through the management interface 41, the test project name can be set or selected, such as 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 names involved in the test project, and non-project-related domain names are not tested to avoid additional performance overhead; the test end IP address 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 performing 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 number of concurrent requests, excluded file types, excluded domain name lists, various keywords for identifying business functions, relevant configurations of permission authentication modes, and relevant parameters regarding the test target, such as development frameworks, development languages, corresponding parsing logics, etc., as well as the detection strategies used during automatic detection, which involve various parameters, test request construction methods, verification conditions, verification / detection processes, etc. 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 detection results with fewer test cases. The management interface 41 also provides the setting of verification metrics and their reference data, such as verification metrics such as the number of function points, vulnerability verification types and their detection strategies, the number of vulnerabilities of each vulnerability verification type, the consistency of detection strategies, the consistency of detection risks of the same vulnerability, etc. 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 names, risk levels, risk parameters, corresponding function paths, etc., and includes corresponding detailed information, such as original request header information, scan information, etc.

[0032] 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 regarding 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.

[0033] The monitoring unit 43 monitors the detection process according to the monitoring indicators, and generates corresponding monitoring notifications based on the monitoring results to be displayed on the management interface 41. For example, when receiving the detection end instruction, it queries whether the function point list has been completely detected. When there are still unfinished function points in the function point list, a reminder notification for continued detection is issued and displayed on the management interface 41 to remind the security engineer that there are still unfinished function points to be detected. The vulnerability detection is not allowed to end until all the function points in the function point list have been detected. Another example is that the function point list also includes a URL identification field, and there are various function identifications in the URL identification field 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, when it detects that a certain identification content in the URL identification field of the function point is not marked, a marking reminder notification is issued and displayed on the management interface 41 to remind the security engineer to identify the identification content of the identification field of the function point. The vulnerability detection is not allowed to end until all the identification contents of the URL identification fields of the function points in the function point list have been identified.

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

[0035] 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 configuration or improve the previous configuration according to his 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.

[0036] Step S2, the function list generation unit 42 of the project detection management module 4 generates a function point list according to the parameters regarding the test target configured in the management interface 41 and the source code of the test target. In an embodiment, the function point list includes a URL list field, a URL identification field, a function point identity identification field, a detection status field, etc. 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 function, sensitive function, and user private function, etc., and their status should be marked as "Yes (Y)" or "No (N)". The function point identity identification field can be, in an embodiment, a hash value calculated based on the URL and parameters, which 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, etc. 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, etc., 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 the 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, protected, etc.; 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.

[0037] Step S3: The security engineer sends a test request data packet corresponding to the test target function point through the test - end 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 - end browser P in the manual detection tool, construct the test request data packet by adding or replacing test cases as needed, and then send it through the test - end browser P.

[0038] Step S4: The test request data packet sent by the test - end browser 1 is sent to the test target T through the proxy port P and receives the response data packet returned by the test target T.

[0039] On the one hand, in step S51, as needed, the security engineer conducts manual detection, judgment, and determines 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 executed to verify the automatic detection result.

[0040] 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 - end browser, conducts vulnerability detection according to the preset detection policy, and records the detection result, which is called the second detection result.

[0041] Step S6: The security engineer determines whether there are still function points that have not been 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 sent, such as clicking the end button on the management interface 41. If the security engineer believes that there are still function points not detected, then return to step S3 and send a new test request data packet for the new function point.

[0042] 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.

[0043] Step S81: Query the detection completion progress of the function - point list. For example, view the detection - status field of each function point.

[0044] Step S82: Determine whether all function points in the function point list have been detected. Among them, 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 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 he presses the end button and a notice for continued detection appears, according to the undetected function points in the notice, step S3 is executed to complete the corresponding detection. Thus, it is possible to avoid missed detection due to human reasons.

[0045] 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 as either "yes" or "no". By querying whether each URL identification content of each function point has been marked as "yes" or "no", it can be monitored whether the function point has completed the identification of the business function.

[0046] Step S92: Determine whether the URL identification field of each function point is marked. If the URL identification field of a certain or certain 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 he presses the end button and a notice for marking the URL identification field appears, according to the function points indicated in the notice, in step S94, the URL identification field of the function point is marked in the function point list. Then step S92 is executed again. Among them, in some embodiments, the identification contents of the URL identification fields that need to be marked by the security engineer include sensitive functions and account functions. In these embodiments, each function point in the function list is identified by the human judgment of the security engineer.

[0047] The present invention can obtain a list of function points through the parsing of the source code of the test target, and the detection can only end after all the function points in the function point list are detected, thereby achieving full coverage of business function points. After each detection is completed, 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 the dependence on engineers, enabling the system to automatically and accurately perform automatic detections.

[0048] Figure 4 FIG. 4 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 identifier, and function point detection identifier 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.

[0049] 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.

[0050] 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.

[0051] The marking unit 323 is connected to the request packet parsing unit 321. After the request packet parsing unit 321 finishes parsing, 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 according to the determined result, mark the upload function and user private function in the URL identification field of the function point as "yes" or "no". Further, when the marking unit 323 marks "discovering the authentication identifier" 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 mark. 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, mark the "account permission" in the URL identification field of this function point as "no". For example, an A account user can access his own private function URL and the function URL on the public home page; when using a NoAuth (unlogged user) account to access the private function URL and the public home page function of the A account, 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 a permission risk, the detection module enables the crawler engine to use a NoAuth (unlogged user) account or a General Auth (ordinary user) to crawl the function link. If the 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, notify the marking unit 323 to mark the "account permission" in the URL identification field of this function point as "no".

[0052] The hash value calculation unit 324 is connected to the request packet parsing unit 321, calculates the first hash value according to the URL and parameters after removing the parameters, and calculates the 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.

[0053] 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 in an orderly manner according to the detection process. For example, according to the running state of the detection, the detection management unit 330 divides 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 is performed or verification is carried out according to the vulnerability type. 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, and so on. Each detection model unit is used to complete the detection of a vulnerability group of one verification type. The detection management unit 330 coordinates multiple detection model units to detect vulnerabilities of their verification types according to the scanning strategy. Each detection model unit completes the detection of a vulnerability group of one verification type according to the instructions of the detection management unit and the detection strategy.

[0054] As Figure 7 shown in the figure, the following are the steps for the detection module 33 to detect a function point:

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

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

[0057] Step S3a, determine whether the first hash value serving 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 of 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.

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

[0059] 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, so the detection of this function point ends, thus avoiding duplicate detection of function points. If not, execute step S7a.

[0060] 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 according to the vulnerability type in sequence. 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 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.

[0061] 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:

[0062] 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.

[0063] 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.

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

[0065] Step S5b, analyze the response content to determine whether there is a risk. Corresponding to the server fingerprint leakage vulnerability, use a regular expression to identify whether the parameter value in the response content contains a number. When the parameter value in the response content contains a number, 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 number "5.2.5", so it is confirmed that there is a risk; when the response content does not contain a number, such as when the response content is "X-Powered-By:PHP", it is confirmed that there is no risk.

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

[0067] Step S8a, the running state vulnerability group is scanned and vulnerability detection is performed in sequence. 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:

[0068] Step S1c, construct a first automatic test data packet based on the vulnerability verification type. Among them, for vulnerabilities of the response content verification type and the request replay verification type, the first automatic test data packet is the original mirror data packet; for vulnerabilities of the 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 vulnerabilities of the 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 vulnerabilities of the 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.

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

[0070] 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.

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

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

[0073] Step S7c: Determine whether the requirements for suspected risks are met. If not, it indicates that there is no risk, so confirm that the detection is passed in Step S8c and record the detection result in the request record form. If met, it indicates that there may be a risk, and 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.

[0074] 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 and the sensitive information leakage vulnerability belonging to the response verification test. Some test conditions stipulate that the verification needs to be carried out according to the status of the relevant marker content in the URL marker field.

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

[0076] 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.

[0077] In Step S10c, for different test conditions, the processes of secondary testing or verification and the bases for judgment 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 conduct 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".

[0078] 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 the rough detection of unauthorized access vulnerabilities, 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 horizontal privilege escalation vulnerabilities. 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".

[0079] For the case where during the parsing of the function point, it is determined that the function point has a user authentication credential, but the "account permission" of this function point has not been marked by the security engineer yet, start the crawler engine, and use the NoAuth (unlogged-in user) account or GeneralAuth (ordinary user) to crawl the function link. If the function link can be crawled, it indicates that this function point does not have a permission function, and this function point may be the aforementioned public home page function. Thus, 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, exclude the suspected risk with the "account permission" marked as "No".

[0080] Among them, the moment of verification can occur during the detection process or before the end of the test after the detection process is completed. 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 marking of the "information storage function" of the function point is "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.

[0081] 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 the test target. Among them, the test request data packet is an image data packet used for detecting vulnerabilities in the initialized vulnerability group, or 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 by 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.

[0082] 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 image data packet, combines the added test cases with the original parameter values into the attack payload, and together constitutes the test request data packet. The number of test cases can vary according to the vulnerability type, whether it is coarse-grained (level 1) 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.

[0083] 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 different levels of users to form multiple said automatic test request data packets. For example, for the unauthorized access vulnerability belonging to the login credential replacement verification type, the user authentication credentials in the mirror data packet are replaced with the authentication credentials of an unlogged user account and 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.

[0084] 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 the 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 of the two times are different, the vulnerability is confirmed. Another example is for the suspected risk 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.

[0085] For the suspected risks of some 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. 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.

[0086] 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 marker field that is the marker of account permissions. When there is no marker 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 marker field are marked as "no", and the risk is excluded, that is, the current risk status is changed from "suspected" to "false positive".

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

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

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

[0090] The detection management unit 330 checks whether all the identification contents in the URL tag fields are marked after the detection of all function points is completed, and queries the identification content marked as information storage in the URL tag field of each function point. For the function points marked as "no", the detection of stored cross-site scripting vulnerabilities is re-performed. 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 reissues 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 rough detection, and determines whether it is a risk according to the comparison result.

[0091] The foregoing vulnerability detection method classifies vulnerabilities into different groups according to the verification type. 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 version updates 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 fixed 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. Therefore, the dependence on developers is greatly reduced, and the intervention and workload of developers are reduced. 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 review fine-grained security detection. 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.

[0092] As can be seen from the above description, the detection accuracy and integrity of the automatic detection tool for vulnerabilities are crucial parts of this system. In order to verify whether the automatic detection tool meets the requirements and is trustworthy, a method for verifying its credibility was provided before.

[0093] Figure 11 It is a flowchart of a method for verifying the credibility of an automatic detection tool according to an embodiment of the present invention. The method includes the following steps:

[0094] Step S100, obtaining reference data for verification metrics. In the present invention, verification metrics are configured through the management interface 41, and corresponding reference data is set. For example, the verification metric is "number of function points", and a corresponding value is set as its reference data; the verification metric is "vulnerability verification type", and a corresponding type name and its detection strategy are set; the verification metric is "number of vulnerabilities of the vulnerability verification type", and a corresponding value is set. The verification metrics include "consistency of detection strategies", "consistency of detection risks of the same vulnerability", etc. Some of these verification metrics can be carried out during the detection process. For example, after detecting a vulnerability of a function point, the "consistency of detection risks of the same vulnerability" and "consistency of detection strategies" can be verified; after all detections of a function point are completed, the types of "vulnerability verification types" and the "number of vulnerabilities of each vulnerability verification type" can be verified, etc. After the entire test project is completed, the "number of function points" can be verified.

[0095] Step S200, obtaining a manual detection strategy. When a security engineer performs manual detection on different vulnerabilities, the detection data of the manual detection tool is obtained and analyzed. The detection data includes the test request data packet data modified by the security engineer in the manual detection interface, the response data returned from the test target, the basis data when the security engineer makes a judgment, and the final detection result data, such as no risk, passing the test, or having a risk. From the above data, the function point URL, parameters, and / or test cases added or replaced by the security engineer are obtained. According to the test cases, response data, judgment data, and test results, the relationship between the two is obtained, and thus it is used as the manual detection strategy for this vulnerability.

[0096] Step S300, obtaining a verification metric and its reference data.

[0097] Step S400: Analyze the second detection result according to the verification index to obtain the index data corresponding to the verification index. For example, when the verification index is "number of function points", the detection results of the automatic detection tool will be counted to determine the number of function points that have been detected, and compare it with the value of "number of function points". The corresponding index data is whether they are the same or different. If they are different, while making a mark, determine whether the number of function points detected by the automatic detection tool is more than or less than the reference value. Another example, when the verification index is "consistency of detection strategy", compare whether the detection strategy used by the automatic detection tool is consistent with the manual detection strategy, including: whether the test cases, detection processes, verification methods, etc. are the same or similar. Another example, when the verification index is "consistency of detection risks of the same vulnerability", compare whether the first detection result obtained by the manual detection tool is consistent with the second detection result obtained by the automatic detection tool.

[0098] Step S500: Determine whether there is still a verification index not analyzed. If there is, return to step S300. If not, in step S600, generate a credibility report based on the index data and the detection credibility of each vulnerability of each function point. It includes in detail the data of each verification index and displays it in various forms. For example, display each verification index in the form of a table, graph, etc., and record the corresponding detailed information in a multi-level link manner.

[0099] Figure 12 It is a flowchart of the verification method during the detection process of a certain vulnerability at a function point according to an embodiment of the present invention. It specifically includes the following steps:

[0100] Step S100a: The security engineer sends a test request for a function point of the corresponding test target through the test merchant browser.

[0101] Step S201a: The manual detection tool intercepts the test request data packet. Step S202a: The security engineer performs manual detection based on the test request data packet and obtains the first detection result in step S203a.

[0102] Meanwhile, in step S301a, the automatic detection tool obtains the mirror data packet of the test request for automatic detection, constructs an automatic test request for automatic detection in step S302a, and obtains the second detection result in step S303a.

[0103] Step S400a: Compare the first detection result with the second detection result. In step S500a, determine whether they are consistent. If they are consistent, write the comparison result into the credibility verification report and end the verification of the vulnerability detection. If they are not consistent, in step S501a, the automatic detection tool reconstructs different automatic detection test request data packets with different test cases to repeat the detection of the vulnerability. For example, repeat the detection 3 - 5 times.

[0104] Step S502a: Determine whether the multiple detection results are consistent. If they are consistent, in step S503a, use the detection result as the final second detection result and execute step S505a. If they are not consistent, in step S504a, send a notification to the security engineer.

[0105] Step S505a: Compare the first detection result with the final second detection result, and in step S506a, write the comparison result into the credibility verification report. When the first detection result is consistent with the final second detection result, mark the detection result of the vulnerability as trustworthy in the credibility verification report. If they are not consistent, mark it as suspicious and send a notification to the security engineer, waiting for further confirmation.

[0106] When the security engineer receives a notification of different results during the repeated detection of the same vulnerability by the automatic detection tool in the management interface 41 during the detection process, determine the reason by viewing the detection data of the automatic detection tool, and modify the detection strategy of the automatic detection tool according to the reason.

[0107] When the security engineer receives a notification that the detection results of the automatic detection tool and the manual detection tool are different in the management interface 41, determine which result is correct by viewing the detection data of the automatic detection tool and the manual detection tool. If necessary, manually detect the vulnerability again. When it is determined that the detection result of the manual detection tool is correct, confirm the manual detection result. At this time, after receiving the confirmation message, the automatic detection tool updates the detection strategy of the automatic detection tool for the vulnerability with the manual detection strategy, such as replacing the test cases and the corresponding verification parameters.

[0108] Figure 13 It is a principle block diagram of a vulnerability detection tool credibility verification system according to an embodiment of the present invention. The system is in Figure 1Based on the system shown, it further includes a credibility verification module 5. Among them, the test-side browser 1 sends a function point test request to the test target through a preset proxy port and receives a response data packet returned from the test target; the manual detection tool 2 is configured to intercept the test request data packet sent to the test target, provide a manual detection interface for security engineers to manually detect, and obtain a first detection result; the automatic detection tool 3 is configured to obtain a mirror data packet of the function point test request from the test-side browser sent through the proxy port, and perform vulnerability detection on the function point corresponding to the mirror data packet to obtain a second detection result; the credibility verification module 5 is connected to the manual detection tool 2 and the automatic detection tool 3, and is configured to receive the first detection result and the second detection result; determine the credibility of the automatic detection tool according to the comparison result. Among them, the project detection management module 4 provides a management interface 41, and can configure detection strategies, verification metrics and their reference data.

[0109] See Figure 14 , the credibility verification module 5 includes a data acquisition unit 51, a vulnerability credibility unit 52 and a comprehensive analysis unit 53. Among them, the data acquisition unit 51 is respectively connected to the manual detection tool 2, the automatic detection tool 3 and the project detection management module 4, obtains the first detection result from the manual detection tool 2, obtains the second detection result from the automatic detection tool 3, or when the manual detection tool 2 and the automatic detection tool 3 send their detection result data to the project detection management module 4, the data acquisition unit 51 obtains the first detection result and the second detection result from the project detection management module 4. In addition, the data acquisition unit 51 obtains manual detection data from the manual detection tool or the project detection management module 4, and obtains a manual detection strategy therefrom. The data acquisition unit 51 obtains verification metrics and corresponding reference data from the project detection management module 4 according to verification needs.

[0110] The vulnerability credibility unit 52 is connected to the data acquisition unit 51, and is used to compare the first detection result and the second detection result, and determine the credibility of the automatic detection tool for the function point vulnerability detection according to the comparison result. The specific process can be seen in Figure 12 .

[0111] The comprehensive analysis unit 53 analyzes the second detection result according to the preset verification metrics, and generates a credibility report based on the verification metric data and the detection credibility of each vulnerability of each function point. Specifically, it can be seen in Figure 11 and the foregoing description of the method part, which will not be repeated here.

[0112] In another embodiment, as Figure 13As shown by the dashed line, the system further includes an update module 6, which is respectively connected to the credibility verification module 5 and the project detection management module 4. When the credibility verification module 5 confirms a vulnerability missed by the automatic detection tool, it sends an update notice to the update module 6. The update module 6 adds the missed vulnerability and the corresponding manual detection strategy to the automatic detection according to the update notice. When the security engineer confirms through the management interface 41 that the detection result of a vulnerability is correct and credible by manual detection, a notice is sent to the update module 6. The update module 6 updates the corresponding detection strategy in the automatic detection tool with the manual detection strategy used to detect the vulnerability according to the update notice.

[0113] Through the above verification method and system, the accuracy of the automatic detection tool for vulnerability detection can be ensured, without the need for excessive manual participation. Only the security engineer needs to give confirmation when necessary, so the influence of human factors is small; and verification can be carried out in real time during the detection process, and the verification result can be obtained when the detection is completed, so the efficiency is high.

[0114] 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 fields can also 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 method for verifying the credibility of a vulnerability detection tool, wherein it includes: generating a list of function points according to the parameters of the test target configured by a security engineer and the source code of the test target, the list of function points including a URL list field, a URL identification field, a function point identity identification field, and a function point detection identification field; sending a function point test request to the test target based on the test-side browser; manually intercepting the data packet of the test request by a manual detection tool, and manually detecting by the security engineer according to the vulnerability detection policy to obtain a first detection result corresponding to the function point; an automatic detection tool obtaining a mirror data packet of the test request, and performing vulnerability detection on the function point corresponding to the mirror data packet according to a preset detection policy to obtain a second detection result; comparing the first detection result and the second detection result; and determining the credibility of the automatic detection tool for the vulnerability detection of the function point according to the comparison result; the automatic detection tool also parses the mirror data packet, at least obtaining the URL without parameters, parameters, and parameter values from the mirror data packet, calculating a first hash value according to the URL without parameters and the parameters, and calculating a second hash value according to the URL without parameters, parameters, and parameter values; the performing vulnerability detection on the function point corresponding to the mirror data packet according to the preset detection policy includes: comparing the first hash value with the hash value in the function point identity identification field in the function point list to determine whether the first hash value as the function point identity is in the function point list; if not, adding the URL and parameters in the mirror data packet to the corresponding fields in the function point list; if so, querying whether the second hash value is located in the function point detection identification field of the request record table, if not, scanning the initialization vulnerability group and the running-state vulnerability group for vulnerability detection, if located, determining that the function point has been detected, and the request record table records the details of the vulnerability detection, including the original test request data packet, URL, function point identity, function point detection identification, risk status, risk type, and risk level.

2. The method according to claim 1, wherein further it includes: loading a detection policy corresponding to the test project into the automatic detection tool; wherein the detection policy includes a detection process corresponding to the vulnerability type, a test request construction method, test cases, and parameter values for determining risks.

3. The method according to claim 2, wherein further it includes: obtaining and analyzing the detection data of the manual detection tool; determining test request data, response data, and first detection result data from the detection data; obtaining the function point URL, parameters, and / or test cases from the test request data; and determining the relationship between the test case and its response value corresponding to the risk from the response data and the first detection result data to obtain a manual detection policy for the vulnerability.

4. The method according to claim 1, wherein further it includes: Provide reference data for verification metrics; the verification metrics include one or more of the number of function points, vulnerability verification types and their detection strategies, the number of vulnerabilities of each vulnerability verification type, the consistency of detection strategies, and the consistency of detection risks of the same vulnerability.

5. The method according to claim 4, wherein further comprises: Obtain reference data for verification metrics; Analyze the second detection result according to the verification metrics to obtain metric data corresponding to the verification metrics; and Generate a credibility report based on the metric data and the detection credibility of each vulnerability of each function point.

6. The method according to claim 5, wherein it further comprises the step of updating the automatic detection tool: In response to a vulnerability missed by the automatic detection tool, obtain the manual detection strategy for detecting the vulnerability by the manual detection tool and add it to the automatic detection tool; or In response to the confirmation of the first detection result by the security engineer, update the corresponding detection strategy in the automatic detection tool with the manual detection strategy of the vulnerability.

7. The method according to claim 5, wherein when the vulnerability risk detected by the manual detection tool is inconsistent with the vulnerability risk detected by the automatic detection tool when detecting the same vulnerability, the automatic detection tool replaces the test case and repeats the detection of the preset number of times for the vulnerability; in response to obtaining the same detection result of the preset re-detection number, use the detection result as the final second detection result.

8. The method according to claim 7, wherein further comprises: When the vulnerability risks corresponding to the first detection result and the final second detection result are different, send a reminder notice.

9. A system for verifying the credibility of a vulnerability detection tool, wherein comprises: A function list generation unit, configured to generate a function point list according to the parameters of the test target configured by the security engineer and the source code of the test target, the function point list including a URL list field, a URL identification field, a function point identity identification field, and a function point detection identification field; A test-side browser, configured to send a function point test request to the test target through a preset proxy port and receive a response data packet returned from the test target; A manual detection tool, configured to intercept the test request data packet sent to the test target, provide a manual detection interface for the security engineer to manually detect, and obtain a first detection result; An automatic detection tool, configured to obtain a mirror data packet of the function point test request from the test-side browser sent through the proxy port, and perform vulnerability detection on the function point corresponding to the mirror data packet according to a preset detection strategy to obtain a second detection result; and A credibility verification module, connected to the manual detection tool and the automatic detection tool, configured to compare the first detection result and the second detection result; Determine the credibility of the automatic detection tool according to the comparison result; An automatic detection tool, configured to parse the mirror data packet, at least obtain the URL without parameters, parameters and parameter values from the mirror data packet, calculate a first hash value according to the URL without parameters and the parameters, and calculate a second hash value according to the URL without parameters, parameters and parameter values; The automatic detection tool is specifically configured to: Compare the first hash value with the hash value in the function point identity field in the function point list to determine whether the first hash value serving as the function point identity is in the function point list; If not, add the URL and parameters in the mirror data packet to the corresponding fields of the function point list; If so, query whether the second hash value is in the function point detection identity field of the request record table. If not, scan the initialization vulnerability group and the running vulnerability group for vulnerability detection. If it is, determine that the function point has been detected, and the request record table records the vulnerability detection details, including the original test request data packet, URL, function point identity, function point detection identity, risk status, risk type, and risk level.

10. The system according to claim 9, further comprising a project detection management module, which provides a management interface and is configured to provide the display of the configuration, detection process, result data, and notification of the security test project; Wherein, The configuration includes the detection strategy and verification metrics corresponding to the test project and their reference data.

11. The system according to claim 9, wherein the credibility verification module Comprises: A data acquisition unit configured to acquire the manual detection strategy, verification metrics and their reference data, the first detection result obtained by the manual detection tool, and the second detection result of the automatic detection tool; A vulnerability credibility unit connected to the data analysis unit and configured to compare the first detection result and the second detection result, and determine the credibility of the automatic detection tool for detecting function point vulnerabilities according to the comparison result; And A comprehensive analysis unit configured to analyze the second detection result according to the preset verification metrics, and generate a credibility report based on the verification metric data and the detection credibility of each vulnerability of each function point.

12. The system according to claim 11, further comprising an update module connected to the credibility verification module. When it is confirmed that there is a vulnerability missed by the automatic detection tool, add the manual detection strategy to the automatic detection tool; when detecting a vulnerability, if the first detection result is different from the final second detection result and a confirmation message for the first detection result is received, update the corresponding detection strategy in the automatic detection tool with the manual detection strategy.

Images