CN113868659A

CN113868659A - Vulnerability detection method and system

Info

Publication number: CN113868659A
Application number: CN202111220415.6A
Authority: CN
Inventors: 马弘煜; 张炎; 杨向勇
Original assignee: Qianjin Network Information Technology (shanghai) Co ltd
Current assignee: Qianjin Network Information Technology (shanghai) Co ltd
Priority date: 2021-10-20
Filing date: 2021-10-20
Publication date: 2021-12-31
Anticipated expiration: 2041-10-20
Also published as: CN113868659B

Abstract

The invention relates to a vulnerability detection method and a vulnerability detection system, wherein the method comprises the following steps: configuring test parameters based on test items, wherein the test parameters at least comprise a target domain name to be tested, a test end browser IP address, a proxy server port, a vulnerability and a detection strategy thereof; sending a function point test request data packet to a test target through a proxy server port based on the test end browser and receiving a returned response data packet; the automatic detection tool obtains the mirror image data packet of the test request, and performs vulnerability detection on the function points one by one according to the configured vulnerabilities and the corresponding detection strategies; and in response to meeting the termination condition, terminating the vulnerability detection. The invention avoids the condition of missing detection of the function points, and the safety engineers can share the detection experience and strategy, thereby obviously reducing the dependence on the safety engineers in the detection process and further reducing the influence of human factors.

Description

Vulnerability detection method and system

Technical Field

The present invention relates to the field of network security technologies, and in particular, to a vulnerability detection method and system.

Background

In the information age, network information security is always a top concern for enterprises and individuals. Whether hardware, software or protocol exists, when the system has defects or the system security strategy is insufficient, a bug is formed, an attacker can access or destroy the system by using the bug without authorization, so that the information system is attacked or controlled by trojan and worm viruses, data is leaked, data is tampered and deleted, and the like, thus bringing immeasurable loss to individuals and enterprises, especially some internet enterprises, in order to ensure the normal operation of the online service and protect the security of user information, a security engineer is usually provided to perform security detection on the online service to discover the bug and timely inform related departments of repairing.

Currently, most safety engineers use risk scanners to perform manual testing based on safety test project documents. However, this security detection mode faces the following problems:

first, human factors have a large impact. Due to the factors of the working state of the safety engineer, the safety knowledge storage, the understanding of the test project and the like, it cannot be guaranteed that the safety test strategy is well executed and the full coverage of the service function to be detected is achieved. In addition, different development frameworks may be adopted for different services, such as a native PHP mode, a self-programming mode based on an MVC framework, a third-party framework mode, and the like, and have different test strategies, so that a security engineer is required to load a corresponding test strategy for the development framework of a project, but in an actual operation process, the security engineer does not necessarily pay attention to the test strategy, which results in invalid detection of a security test strategy loading error.

Second, the performance of the detection tool needs to be improved. At present, common automatic application risk scanners in a security test process, such as Appscan and Luma aurora, can only cover some simple security risks based on a request response model, and cannot cover permission type security holes and security holes needing interaction, such as a storage type XSS type security hole.

And thirdly, missing detection. Although the traditional automatic scanner crawler can acquire most of the service function points, the high-interaction service function points cannot be acquired, and the condition of missing detection of the service functions cannot be effectively solved.

Fourth, security testing experience and testing strategies cannot be shared. The test experience and the test strategy of the historical project can be reused for the next test of the same project only in a self-recording mode by a safety engineer, sharing among different engineers cannot be realized, and whether missing detection occurs or not cannot be known, so that the test period is long and the result is not credible.

Fourth, the test environment is limited. Because the safety test of the first party is usually performed on a server in a test environment, the performance of the test server is poor and only a small number of concurrent test requests can be supported, but the mainstream scanners in the market are performed on the basis of massive attack simulation requests and cannot be completed in a limited test period if the test is performed slowly.

In summary, the existing vulnerability detection modes, methods and systems have much room for improvement.

Disclosure of Invention

Aiming at the technical problems in the prior art, the invention provides a vulnerability detection method and system, which can complete the full-scale detection of the vulnerability and reduce the influence of human factors in the detection process when a security engineer performs vulnerability detection.

In order to solve the above technical problem, according to an aspect of the present invention, there is provided a vulnerability detection method, including: configuring test parameters based on test items, wherein the test parameters at least comprise a target domain name to be tested, a test end browser IP address, a proxy server port, a vulnerability and a detection strategy thereof; sending a function point test request data packet to a test target through a proxy server port based on the test end browser and receiving a returned response data packet; the automatic detection tool obtains the mirror image data packet of the test request, and performs vulnerability detection on the function points one by one according to the configured vulnerabilities and the corresponding detection strategies; and in response to meeting the termination condition, terminating the vulnerability detection.

In order to solve the above technical problem, according to another aspect of the present invention, the present invention provides a vulnerability detection system, which includes a test-end browser, an automatic detection tool, and an item detection management module; the project detection management module is configured to provide configuration of various parameters, conditions and detection strategies required for safety detection of a test project, monitor a test process, store and display detection results, and finish vulnerability detection when a finishing condition is met; the test end browser is connected with the project detection management module, is configured to send a function point test request data packet to a test target through a configured proxy port, and receives a response data packet returned from the test target; the automatic detection tool is connected with the project detection management module and configured to acquire the mirror image data packet of the test request and perform vulnerability detection on the function points one by one according to configured vulnerabilities and corresponding detection strategies.

The invention can carry out full-scale and automatic safety detection on the function points of the test target, can finish the detection when the detection process reaches the preset finishing condition, and can avoid the condition of missing detection of the function points when the finishing condition is set as the coverage of the function points; the system can store various configurations in the last detection, so that safety engineers can share detection experience and strategies, dependence on the safety engineers in the detection process can be obviously reduced through various set standardized parameter items and strategies, and influence of human factors is reduced.

Drawings

Preferred embodiments of the present invention will now be described in further detail with reference to the accompanying drawings, in which:

FIG. 1 is a schematic block diagram of a vulnerability detection system provided in accordance with an embodiment of the present invention;

FIG. 2 is a functional block diagram of an item detection management module provided in accordance with one embodiment of the present invention;

FIG. 3 is a flowchart of a vulnerability detection method provided according to an embodiment of the present invention;

FIG. 4 is a functional block diagram of an automated detection tool provided in accordance with one embodiment of the present invention;

FIG. 5 is a functional block diagram of a packet analysis module provided in accordance with one embodiment of the present invention;

FIG. 6 is a functional block diagram of a detection module provided in accordance with one embodiment of the present invention;

FIG. 7 is a flow chart providing detection of a function point according to an embodiment of the present invention;

FIG. 8 is a flow diagram providing for detection of an initialization vulnerability according to an embodiment of the present invention;

FIG. 9 is a flow diagram providing for detection of a vulnerability of a run-state vulnerability group according to one embodiment of the present invention; and

FIG. 10 is a functional block diagram of a detection model unit provided in accordance with an embodiment of the present invention.

Detailed Description

In order to make the objects, 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 drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

In the following detailed description, reference is made to the accompanying drawings that form a part hereof and in which is shown by way of illustration specific embodiments of the application. In the drawings, like numerals describe substantially similar components throughout the different views. Various specific embodiments of the present application are described in sufficient detail below to enable those skilled in the art to practice the teachings of the present application. It is to be understood that other embodiments may be utilized and structural, logical or electrical changes may be made to the embodiments of the present application.

Fig. 1 is a schematic block diagram of a vulnerability detection system provided according to an embodiment of the present invention. Referring to fig. 1, the vulnerability detection system includes a test end browser 1, an optional manual detection tool 2, an automatic detection tool 3, and an item detection management module 4, where the item 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 a safety engineer, and a designated proxy port P is set by configuring a browser proxy server on a computer used by the safety engineer, so that the test end browser 1 is connected with the proxy port P. In this configuration, the test request sent through the test browser 1 may be intercepted by the automatic detection tool 3, as in one embodiment, by selecting a proxy scan by FoxyProxy and specifying a proxy IP address. The manual detection tool 2 is an optional existing manual vulnerability detection device, when the manual detection tool 2 needs to be used, a manual detection tool bump configured on a security engineer computer is selected through Foxyproxy, and then a proxy server is arranged in an operation interface provided by the manual detection tool bump. Under the 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 the data packet to the security engineer through the operation interface, and the security engineer manually tamps the data packet of the test request, manually checks a returned result, and manually judges whether a vulnerability risk exists.

As shown in fig. 2, the item detection management module 4 includes a management interface 41, a function list generating unit 42, and a monitoring unit 43, where the management interface 41 is configured to provide data display of setting of security detection parameter items, detection processes, and results. The management interface 41 can set or select a test item name, such as xxx service, and under the service, a plurality of tested service lines can be included, and the service line name is set or selected; setting or selecting a domain name of a test item, such as xxx.yy.com, to limit the domain name related to the test item, and not testing the domain name related to a non-item, so as to avoid extra performance overhead; the IP address of the testing end is set or selected, for example, 10.100.x.x, to limit the IP address of the PC of the security engineer performing vulnerability detection, so that the testing end browser 1 is designated, the source of using the system can be limited, and the system is prevented from being abused. The parameters include parameters for automatic detection, such as request concurrency number, excluded file type, excluded domain name list, various keywords for identifying service function, related configuration of authority authentication mode, related parameters related to test target, such as development framework, development language, corresponding parsing logic, and the like, and various parameters, verification conditions, verification processes, and the like, related to detection strategy during automatic detection. In order to reduce test cases and reduce the test pressure on the test environment, the page fault echoing state is set to be 'yes', so that in the detection process of vulnerabilities such as any file downloading vulnerability and fault-revealing type SQL injection vulnerability, the response returned from a test target can contain fault echoing content, and the detection result can be obtained by using fewer test cases. The management interface 41 further includes a display area for various data, such as a detection result display area, for displaying detection process data and result data of various vulnerabilities, such as obtained vulnerability risk names, risk levels, risk parameters, corresponding function paths, and the like, and includes corresponding detailed information, such as original request header information, scanning information, and the like. The function list generating unit 42 is connected to the management interface 41, and generates a to-be-tested function point list according to the parameter of the test target and the source code of the test target configured by the management interface 41, where the function point list includes a URL (Uniform Resource Locator) list field including URLs of each function point to be tested; the system also comprises a detection state field used for indicating whether the current function point is detected or not; the function point list also includes a URL function identification field, wherein the URL function identification field includes a plurality of function identifications to indicate the service functions of the current function point, such as account authority, information storage, upload function, sensitive function, user private function, and the like. The function point list can be displayed in a corresponding display area of the management interface. The monitoring unit 43 monitors the detection process according to the monitoring index, and generates a corresponding monitoring notification according to the monitoring result to be displayed on the management interface 41. For example, the total number of vulnerabilities, the detected number of vulnerabilities, vulnerabilities at risk, detected functional points, undetected functional points, detailed data in the detection process, etc. are displayed in a graphical manner. One of the monitoring indexes is whether the current detection on the test target meets an end condition, wherein the end condition comprises that a detection end instruction is received, all detection of the function points is completed, and all marks of the URL function marks are completed. Therefore, when the detection end instruction is received, the monitoring unit 43 inquires whether the function point list is completely detected, and if there are unfinished function points in the function point list, the detection end flow is prohibited, and a continuous detection reminding notification is sent and displayed on the management interface 41. And reminding a security engineer of the existence of the functional points which are not detected completely, and allowing the vulnerability detection to be finished until all the functional points in the functional point list are detected completely. The monitoring unit 43 further monitors the URL function identification field of the function point, when receiving a detection ending instruction, when monitoring that a certain identification content in the URL function identification field of the function point is not marked, forbids ending of the detection process, and sends a mark reminding notification to be displayed on the management interface 41 to remind a security engineer to identify the identification content of the identification field of the function point, and the vulnerability detection is not allowed to end until all the identification contents of the URL function identification field of the function point in the function point list are identified.

Fig. 3 is a flowchart of a vulnerability detection method according to an embodiment of the present invention, where the method for security engineers to perform vulnerability detection includes the following steps:

in step S1, the security engineer configures or selects the item through the management interface 41 of the item detection management module 4. When the test target is not the first detection, the management interface stores the configuration performed in the last detection, and all the configurations in the last test can be obtained by selecting the corresponding name in the project name parameter item. The safety engineer can directly use the last configuration and can also improve the last configuration according to own experience. Therefore, the invention can share the detection experience and the test strategy among safety engineers, and can improve the test strategy on the basis of the experience of predecessors, thereby further improving the test strategy, further improving the test effect, increasing the reliability of the test and reducing the test period. If the test target is detected for the first time, setting a domain name of the test target, setting an IP address of a test end browser used by a security engineer, setting a port of a proxy server, setting bugs to be detected, and setting a verification type and a corresponding detection strategy for each bug. The detection strategy comprises a verification condition, a verification process, various parameters used in verification and the like. Of course, relevant parameters related to the test target, such as the address where the source code is located, the resolution logic, and the like, are also included.

In step S2, the function list generating unit 42 of the item inspection management module 4 generates a function point list based on the parameters about the test targets and the source codes of the test targets configured by the management interface 41. In one embodiment, the function point list includes a URL list field, a URL function identification field, a function point identity field, a detection status field, and the like. The URL list field records a URL corresponding to the function point, and further comprises a parameter field and a parameter value field. The URL function identification field includes various identification contents for indicating the service function, such as one or more of account authority, information storage, upload function, sensitive function, and user private function, which should be marked as a state of "yes (Y)" or "no (N)". The function point identity field may in one embodiment be a hash value calculated based on the URL and the parameters, which is a unique identification of the identity of the function point. The detection status field may represent by a number that the function point is in an undetected initialization state, in a different state of passing detection, at risk of detection, detected but failed detection, and so on. Specifically, the function list generating unit 42 obtains the name, development language, and framework of the test item according to the configuration of the test item in the management interface 41, selects a corresponding parsing logic, reads the source code of the test item from the source code management library, and parses the source code according to the parsing logic to obtain the function point to be detected, thereby generating the function point list. Wherein, different development languages and frames correspond to different analysis logics. The development language is, for example, PHP, JAVA,. NET, ASP, Ruby, Python, Vue, etc., and the development framework is, for example, an MVC-based open source framework or a custom framework, a three-layer architecture-based custom framework, or some other framework. A procedure for generating a function point list will be briefly described, taking PHP as a development language and MVC-based open source framework as an example:

php is obtained by configuring a Web container.

Php, finding out an application target and a name through regular matching, and outputting the application directory.

And then obtaining a Controller path according to the application directory, and obtaining all file lists of the Controller path.

And then analyzing the files in the file list to obtain the names of the controllers in the files and the names of the methods in the controllers, and removing privatization methods such as private, initial and protected.

And adopting regular expression matching to obtain the user input parameter name. And finally outputting a function list, parameters, a request type and a unique hash value serving as the function point identity. The hash value is calculated based on the URL and the parameter.

In step S3, the security engineer clicks a function point of the test target through the test end browser 1 to send a test request.

In step S4, the test request sent by the test browser 1 is sent to the test target T through the proxy port P, and a response packet returned by the test target T is received.

When the manual detection tool 2 is configured, in step S51, the security engineer intercepts the test request packet through the manual detection tool 2, determines whether there is a risk based on the results returned by manual tampering and manual judgment of the security test item document, and records the detection result, which is referred to as a first detection result, as needed. It should be noted that this step is not necessarily performed for each function point detection, and when the safety engineer doubts about the automatic detection result, the manual detection in this step may be performed, the automatic detection result may be verified by the manual detection result, or the manual detection result may be verified by the automatic detection result. The accuracy of vulnerability detection can be determined through mutual verification, the reliability of an automatic detection result is determined, and the detection level of a safety engineer can be determined through the automatic detection result when the reliability of an automatic detection tool is determined, so that the service capability of the safety engineer can be detected.

Step S52, the automatic detection tool 3 obtains the mirror image data packet of the test request from the test end browser from the proxy port P, performs vulnerability detection according to a preset detection policy, and records a detection result, which is referred to as a second detection result.

In step S6, the safety engineer determines whether there are any functional points that have not been detected, and if the safety engineer determines to end the detection by considering that all the functional points have been detected, a detection end command is issued in step S7, such as clicking an end button on the management interface 41. If the safety engineer considers that there are any function points without detection, the method returns to step S3 to re-send the test request for the new function point.

In step S81, the monitoring unit 43 inquires about the detection completion progress of the function point list when receiving the detection end instruction. For example, look at the detection status field of each function point.

In step S82, it is determined whether all the function points in the function point list have been detected. Wherein, it can be determined that the detection is completed by looking at the detection status field of each function point, if the number in the detection status field represents the initialization status, it indicates that the function point is not detected, then a notification for reminding to continue detection is sent out in step S83 and displayed on the management interface 41; if all the function points in the function point list have been detected, step S91 is executed. When the safety engineer finds that the detection is not ended when the safety engineer presses the end button and a notification requesting the safety engineer to continue the detection occurs, the step S3 is executed to complete the corresponding detection according to the undetected function point in the notification, so that the omission of the detection due to human reasons can be avoided.

In step S91, the monitoring unit 43 monitors the URL function identification field corresponding to each function point. In one embodiment, each function point URL function identification field includes URL identification contents such as account authority, information storage, upload function, sensitive function, and user private function, etc. to indicate the service function of the function point, and the corresponding URL identification contents include two states of "yes" and "no", and each function point is marked as "yes" or "no". Whether the function point completes the identification of the service function can be monitored by inquiring whether each URL identification content of each function point identifies yes or no.

Step S92, determining whether the URL function id field of each function point is marked, if the URL function id field of one or some function points in the function point list is not marked, then a mark reminding notification is sent in step S93, and displayed on the management interface 41. If the URL function identification field of each function point is marked, the detection process is ended. When the security engineer finds that his detection is not finished when he presses the end button and a notification is presented that requires him to mark the URL function identification field, the URL function identification field of the function point is identified in the function point list in step S94, according to the function point indicated in the notification. And then performs step S92. Wherein, in some embodiments, the identification content of the URL function identification field that requires the security engineer to identify includes sensitive functions and account functions. In these embodiments, each function point in the function list is identified by human judgment of the safety engineer.

In other embodiments, upon receiving the end-of-detection command, steps S91-93 may be performed before steps S81-83 are performed. Or the two processes are executed simultaneously, namely the two steps are not in sequence.

The invention can obtain the function point list by analyzing the test target source code, and can finish the detection only when the detection of all the function points in the function point list is finished, thereby realizing the full coverage of the service function points. All configurations are stored in corresponding parameter items after detection is completed each time, research results and experiences of safety engineers can be accumulated and shared with other safety engineers. The invention can collect the historical information of the test items and provide a basis for subsequent safety tests. For a test project, after the function point is subjected to function identification, the identification is stored in the identification field, and after the identification and rechecking of an engineer are carried out during the first test, the engineer identification is not needed any more, so that the flow is simplified for subsequent detection, the dependence on the engineer is reduced, and the system can automatically and accurately execute automatic detection.

Fig. 4 is a schematic block diagram of an automatic detection tool according to an embodiment of the present invention, where the automatic detection tool includes a packet obtaining module 31, a packet analyzing module 32, and a detection module 33, where the packet obtaining module 31 is connected to a proxy port P, obtains a mirror image packet sent by a test browser 1 to a corresponding function point of a test target T from the preset proxy port P, sends an automatic test request packet constructed by the automatic detection tool to the test target T, and receives a response packet returned by the test target T. The data packet analysis module 32 is connected to the data packet acquisition module 31, and is configured to analyze the mirror image data packet and the response data packet, and acquire at least a URL of a removed parameter, a parameter and a parameter value, a function point identity identifier, and a function point detection identifier from the mirror image data packet; and at least acquiring response content from the response data packet. As shown in fig. 5, 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.

The request packet parsing unit 321 is configured to parse a request Header (Header), request parameters, and user credentials of a mirror data packet. Parameters in the request Header (Header) such as Cookie, x-forward, refer, user-agent and the like can be obtained by analyzing the request Header of the mirror image data packet. Checking parameter names according to corresponding configuration in a management interface 41, then eliminating parameters which do not need to be detected, then judging whether the remaining parameters have Cookie fields, if so, eliminating the Cookie, obtaining a request header parameter at this moment, and informing a marking unit 323 to mark 'discovery authentication marks' in URL function identification fields of corresponding function points in a function point list; if there is no Cookie parameter in the parameters, the notification marking unit 323 marks "authentication identity not found" in the URL function identification field of the corresponding function point in the function point list. When analyzing request parameters, firstly, according to request types, such as a GET request type or a POST request type, corresponding URL analysis is performed, and GET parameters or POST parameters from the URL analysis. The cleaning unit 325 is connected to the request packet parsing unit 321, and determines whether the parameter value includes a test case, and if so, deletes the test case, thereby obtaining the URL from which the parameter is removed, the parameter, and a corresponding parameter value. When the user credentials are analyzed, the authority authentication mode, such as a Cookie mode or an API mode, configured in the management interface 41 is read, and the authentication identification keyword, such as a sign, token, or key, in the configuration is read. And if the authentication mode in the mirror image data packet is the Cookie mode, analyzing the Cookie field to obtain parameter names such as username and ci _ session. Wherein ci _ session is an authentication credential parameter, which cannot be accessed after being tampered, so that the authority class detection is required, and therefore, the URL function identification field needs to be marked with a "discovery authentication identification", and at this time, the authentication credential is removed, so as to obtain a request parameter with a fixed value removed. If the authentication mode in the mirror image data packet is the API mode, inquiring whether the parameter name matches with the authentication keyword configured in the management interface, if so, removing the authentication keyword, and notifying the marking unit 323 to mark the "found authentication mark" in the URL function 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 "authentication not found" in the URL function identification field of the corresponding function point in the function point list. The URL, the parameter and the parameter value of the removed parameter are obtained through the analysis of the request packet analyzing unit 321.

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

The marking unit 323 is connected to the request packet parsing unit 321, and after the parsing by the request packet parsing unit 321 is completed, reads the parsed parameters and parameter values, and determines whether the service function of the function point is an upload function or not and whether the service function belongs to a private function according to the configured parameters of the management interface 41. And marking the uploading function and the user private function of the function point URL function identification field as 'yes' or 'no' according to the determined result. Further, when the marking unit 323 marks "find the authentication identifier" according to the notification of the request packet parsing unit 321, a confirmation notification is sent to the management interface 41 to remind the security engineer to identify "account permission" in the URL function identifier field of the function point according to the mark. In addition, in the detection process, the marking unit 323 uses an open-source crawler engine to crawl the function point according to needs, and if the function point can be crawled, the 'account authority' of the function point URL function identification field is marked as 'no'. For example, an A account user may access its own private function URL and a function URL on a public home page; when accessing the private function URL of the a account and the public home function using the NoAuth (unregistered user) account, the result should be that the access to the function URL private to the a account fails and the access to the public home function URL succeeds. Therefore, in the detection process, if it is found that both the account number a and the account number NoAuth can access one function point URL, there is a possibility of an authority risk, in order to check such an authority risk, the detection module starts the crawler engine to use the NoAuth (unregistered user) account or General Auth (General user) to grab the function link, and if the function link can be grabbed, it indicates that the function point does not have the authority function, and the function point may be the aforementioned common home page function, so that the marking unit 323 is notified to mark the "account authority" of the function point URL function identification field as "no".

The hash value calculation unit 324 is connected to the request packet parsing unit 321, and calculates a first hash value according to the URL of the removed parameter and the parameter, and calculates a second hash value according to the URL of the removed parameter, the parameter, and the parameter value. The first hash value is used as the identity of the function point, and the second hash value is used as the detection identity of the function point.

The detection module 33 is connected to the packet analysis module 32, and performs vulnerability detection based on the mirror image packet and its analysis result according to a preset detection strategy. In the invention, a plurality of loopholes to be detected are grouped according to the verification types of the loopholes, and corresponding detection processes are set for loophole groups of different verification types. And the corresponding checking model unit executes the checking process of the corresponding checking type. As shown in fig. 6, the detection module 33 includes a detection management unit 330 and a plurality of

detection model units

331, 332, and … … 33n, and the detection management unit 330 controls the plurality of detection model units to sequentially perform vulnerability detection according to a detection flow. For example, according to the detected operating state, the detection management unit 330 divides a plurality of vulnerability groups into an initialization vulnerability group and an operating state vulnerability group, and sets different detection strategies. For example, the initial vulnerability group is detected first, and then the operation state vulnerability group is detected. And the initialized vulnerability group completes detection by one-time request, and for the operation state vulnerability group, a detection strategy combining coarse granularity and fine granularity or a detection strategy combining coarse granularity and result verification is implemented according to the vulnerability type. When coarse-grained detection is carried out, a small number of test cases, such as 1-5, are used, detection is completed through one request, and after suspected risks are obtained, fine-grained detection is carried out or result verification is carried out according to vulnerability types. The detection management unit 330 also maintains a request record table that can be displayed through the management interface 41, in which details of vulnerability detection are recorded, such as original test request data packet, URL, function point identity, function point detection status, risk type, risk level, and so on. Each detection model unit is used for completing the detection of the vulnerability group of one check type. The detection management unit 330 coordinates a plurality of detection model units to detect the vulnerabilities of the verification types thereof according to the scanning strategy, 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 and the detection strategy.

As shown in fig. 7, the process of detecting a function point by the detection module 33 includes the following steps:

in step S1a, the detection management unit 330 receives the mirror image packet and the analysis result thereof from the packet analysis module 32.

In step S2a, the detection management unit 330 compares the first hash value with the hash value in the id field in the function point list.

Step S3a, judging whether the first hash value as the function point identity is in the function point list, if not, adding the data such as URL address, parameters and the like in the mirror image data packet into the corresponding fields of the function point list in step S4a, thereby making up the function points which are missed when the function point list is generated; if so, step S5a is performed.

In step S5a, the detection management unit 330 refers to the function point detection identification field in the request record table.

Step S6a, determining whether the second hash value is located in the request record table, that is, whether the second hash value is already included in the function point detection identifier field, and if the second hash value is located in the function point detection identifier field, it indicates that the function point has been detected, at this time, no detection is needed, and the detection of the function point is ended, so that repeated detection of the function point can be avoided. If not, step S7a is performed.

Step S7a, scanning the initialization leak group for initialization detection. The detection management unit 330 controls the detection model units corresponding to the initialized vulnerability group to sequentially perform vulnerability detection according to vulnerability types. In one embodiment, the initialized vulnerability group is an initialized response content verification type, and the corresponding detection model unit 331 sends a test request to the vulnerability types included in the initialized vulnerability group based on the mirror image data packet (i.e., the original data packet) respectively, and then completes the detection. The corresponding vulnerability types are server fingerprint leakage vulnerability, HTTP request mode vulnerability and sensitive information plaintext transmission vulnerability.

Taking the example of detecting a server fingerprint leakage vulnerability as an example, the flow of the detection model unit 331 is described, as shown in fig. 8:

in step S1b, the inspection model unit 331 puts the mirror image packet in the request queue. In the actual detection process, the mirror image data packets of multiple function points may need to perform initial response content check type vulnerability detection, so the mirror image data packets detected by the function points are placed in a request queue for queuing.

Step S2b, determining whether the mirror image data packet reaches the top of the request queue, and if so, sending the mirror image data packet to the test target T through the data packet obtaining module 31 in step S3 b; if not, wait.

Step S4b, the response content of the response packet obtained after the analysis by the received packet analysis module 32.

Step S5b, the response content is analyzed to determine if there is a risk. Corresponding to server fingerprint leakage loopholes, whether parameter values of response content contain numbers or not is identified through a regular expression, and when the parameter values of the response content contain the numbers, risks are determined to exist, for example: when PHP 5.2.5 is included in the response, the specific version of the number "5.2.5" is included, confirming that there is a risk; when no number is contained in the response contents, no risk is confirmed, for example, when the response contents are "X-Power-By: PHP".

Step S6b, records the detection result in the request record table.

And step S8a, scanning the operation state vulnerability groups to sequentially detect vulnerabilities. The detection management unit 330 controls the plurality of detection model units to sequentially complete the detection of the corresponding vulnerabilities. One vulnerability detection flow of the run-state vulnerability group is shown in fig. 9:

step S1c, constructing a first automatic test data packet based on a vulnerability verification type, wherein the first automatic test data packet is an original mirror image data packet for vulnerabilities of a response content verification type and a request replay verification type; for the loophole of the request response verification type, a first automatic test data packet is formed by adding a preset test case in the parameter value of the original mirror image data packet; for the bug of the replacement request response verification type, a first automatic test data packet is formed by replacing the parameter value of the original mirror image data packet with a preset test case; for the loophole of the login certificate replacement check type, a first automatic test data packet is formed by replacing the original user authentication certificate in the original mirror image data packet with a preset authentication certificate.

Step S2c, the corresponding inspection model unit puts the first automatic test packet into its internal request queue.

Step S3c, determining whether the first automatic test packet reaches the top of the request queue, and if so, sending the first automatic test packet to the test target T through the packet obtaining module 31 in step S4 c; if not, wait.

Step S5c, the response content of the response packet obtained after the analysis by the received packet analysis module 32.

Step S6c, the response content is analyzed. And when analyzing the response content, analyzing according to the verification type of the vulnerability and the corresponding strategy. For example, for vulnerabilities such as a request response verification type, a replacement request response verification type, a response content verification type and the like, whether the response content contains content preset in the detection strategy is analyzed; for the login certificate replacement check type, comparing the contents of the two responses; for the request replay check type, a response to the original request and a response to the replay request are compared.

Step S7c, judging whether the requirement of suspected risk is satisfied, if not, indicating no risk, confirming the detection is passed in step S8c, and recording the detection result into the request record table; if so, indicating that there is a possible risk, execution is step S9 c. For example, for a reflective cross-site scripting risk belonging to a request response verification type, when the response content shows back the original form, the suspected risk requirement is considered to be met, and the suspected risk is determined; for the unauthorized access loophole belonging to the login certificate replacement verification type, when the contents of the two responses are highly similar, the suspected risk requirement is considered to be met, and the suspected risk is confirmed; for cross-site request forgery bugs belonging to a request replay check type, when two request responses are completely consistent, the suspected risk requirement is considered to be met, and the possibility of risk is confirmed.

And step S9c, acquiring a secondary test condition of the vulnerability with the suspected risk. The secondary test conditions are different according to different vulnerability types and are recorded in the detection strategy, and the secondary test conditions can be obtained by inquiring the detection strategy. For example, some have no limitation of test conditions, such as a reflection-type cross-site scripting risk belonging to a request response verification type, a sensitive information leakage vulnerability belonging to a response verification test, and the like; some test conditions provide for verification based on the status of the relevant tag content in the URL tag field.

And step S10c, performing secondary test or verification according to the corresponding test conditions.

Step S11c, judging whether the structure of the secondary test or check is risk, if yes, modifying the risk state in the request record table from 'suspected' to 'confirmed' in step S12c, and ending the detection; if the risk is not detected after the secondary test or verification, step S13c modifies the risk status in the request record table from "suspected" to "false positive" and ends the detection.

In step S10c, the flow and judgment criteria of the secondary test or verification are different for different test conditions. For example, for a reflective cross-site scripting risk belonging to a request response verification type and a sensitive information leakage vulnerability belonging to a response verification test, no test condition is needed, and then a secondary test is directly performed, for example, a test request data packet is reconstructed and sent to a test target, and returned response content is analyzed. And according to whether the requirement of the risk is met, modifying the suspected risk state in the request record table into confirmation or false report.

For a vulnerability which needs to be checked against the mark state of the mark content in the URL function identification field, for example, when a suspected risk is found by performing a coarse detection on an unauthorized access vulnerability, whether the mark of the mark content of the account right in the URL function identification field of the function point is "yes" (Y) or "no" (N) is inquired, if the mark of the "account right" is "yes" (Y), it is determined that the risk of the vulnerability type really exists, the risk state in the request record table is modified from "suspected" to "confirmed", and if the mark of the "account right" is "no" (N), the risk state is modified from "suspected" to "false alarm". For another example, when a suspected risk occurs in the detection of the horizontal override hole, firstly, whether the mark of the identification content "account authority" in the URL function identification field of the function point is "yes (Y)" or "no (N)" is queried, and if the mark of "account authority" is "no (N)", the risk state is modified from "suspected" to "false alarm". If the mark of the account authority is 'Y', then inquiring whether the mark of the user private function is 'Y' or 'N', if the mark is 'N', then modifying the risk state from 'suspected' to 'false positive'. If yes, then confirm that the risk of the vulnerability type does exist, and modify the risk status in the request record table from "suspected" to "confirmed".

When the parsing function point determines that the function point has the user authentication credentials and the "account authority" of the function point is not marked by the security engineer, the crawler engine is started, the NoAuth (unregistered user) account or General Auth (General user) is used for grabbing the function link, if the function link can be grabbed, the function point does not have the authority function, the function point may be the aforementioned common home page function, and therefore the marking unit 323 is notified to mark the "account authority" of the function point URL function identification field as "no". According to the aforementioned verification process, the suspected risk that the "account authority" is marked as "no" is eliminated.

The checking time may occur during the detection process, or may be before the detection process is completed and the test is finished. For example, for the verification of the "information storage function", after the detection is completed and the security engineer marks all URL functions, if the "information storage function" of the function point is marked as "yes", the security engineer needs to manually write a specified payload in the form item: sectxs' "< >. The system automatically replays all the test requests with the information storage function marked as N and checks the response packet of each test request.

In one embodiment, as shown in FIG. 10, one inspection model unit 331 includes a request queue 3311, a sending subunit 3312, a receiving subunit 3313, and a checking subunit 3314. The request queue 3311 is configured to store a test request data packet sent to a test target, where the test request data packet is a mirror image data packet used when detecting a vulnerability in an initialized vulnerability group, and may also be a test request data packet constructed when performing coarse-grained detection on a vulnerability in a running vulnerability or a new test request data packet used for fine-grained detection. The sending subunit 3312 takes out the test request data packets from the request queue in sequence, and sends the test request data packets to the test target through the agent port via the data packet obtaining module 31. The receiving subunit 3313 is connected to the packet analysis module 32, and receives the response content analyzed by the packet analysis module with respect to the response packet returned from the test target. The checking subunit 3314 is provided with a detection policy corresponding to the type of checking it detects, checks the returned response data according to the detection policy to determine whether there is a risk of a corresponding bug, and sends the checking result to the detection management unit 330. For example, for a reflective cross-site scripting risk vulnerability of a request response verification type, 4 test cases are included in the transmitted test request data packet, and the verification subunit 3314 verifies whether the response content is echoed back as it is, and if so, determines that the response content is a suspected risk.

Among some inspection model units, such as an inspection model unit for performing vulnerability group inspection of request response verification type, replacement request response verification type, and login credential replacement verification type, a test request constructing subunit 3310 is further included, which constructs a new test request packet according to an inspection policy. For example, in the detection model unit for detecting the request response verification-type vulnerability group, the test request construction subunit 3310 adds test cases to the parameter values of the mirror image data packet, and combines the added test cases and the original parameter values into an attack load to form the test request data packet. The number of test cases may vary depending on the vulnerability type, coarse (level 1) or fine (level 2). For example, for any file download bug belonging to a 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 reflection-type cross-site script 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 a replacement request response verification type, 3 test cases are used in coarse grain detection.

In the detection model unit for detecting the replacement request response verification-type vulnerability group, the test request construction subunit 3310 replaces the parameter values in the mirror image data packet with test cases, thereby forming a test request data packet. When the verification type of the leaky port group is a login credential replacement verification type, 3310 replaces the user authentication credentials in the mirror image data packet with authentication credentials of users of different levels, respectively, to form a plurality of automatic test request data packets. For example, for an unauthorized access vulnerability belonging to a login credential replacement verification type, the user authentication credentials in the mirror image data packet are replaced by the authentication credentials of a high-level authority user such as an unregistered user account credential and an administrator, respectively, to obtain two test request data packets. Correspondingly, the checking subunit 3314 compares the response contents returned by the two test requests, and if the response contents are highly similar, it determines that the two test requests are suspected to be bugs.

The detection management unit 330 receives the verification result obtained by the detection model unit 331, and determines whether to perform fine-grained detection or result verification according to the vulnerability type when the detection management unit 330 receives that the verification result sent by the detection model unit is suspected risk. For example, for a request response verification type leak group, such as a reflection-type cross-site scripting risk, an error-display-type SQL injection leak, an arbitrary file download leak, and the like, when a coarse-grained detection result is a suspected risk, a certain amount of test cases are reused to construct a test request data packet, fine-grained detection is performed, and if the coarse-grained detection result is still a risk according to a detection strategy, the current suspected risk can be confirmed to have the leak. For example, for suspected risks of any file download vulnerability and error-prone SQL injection vulnerability, a new test case is used for verification in the fine-grained (level 2) detection process, and the vulnerability is confirmed if the contents of two requests and responses are different. For another example, in the case of a suspected risk of a reflection-type cross-site scripting risk, if a new test case is used in the fine-grained (level 2) detection process, the returned response content is returned and displayed as it is, and then a vulnerability is confirmed. When the suspected risk is detected as any file upload vulnerability, the detection management unit 330 directly determines the suspected risk as a risk.

For suspected risks of some vulnerabilities, the coarse-grained detection result needs to be checked according to the service function of the function point. Thus, in one embodiment, the detection module 33 further comprises a result checking unit 334, connected to the detection management unit 330, configured to receive a result checking instruction from the detection management unit 330, and check the suspected risk according to a checking policy. The vulnerabilities to be checked are, for example, vulnerabilities related to an authority class, such as a horizontal override vulnerability, an unauthorized access vulnerability and a vertical override vulnerability, and also vulnerabilities related to sensitive functions, such as a cross-site request forgery vulnerability. Therefore, the result checking unit 334 may be one unit, and check the vulnerabilities requiring result checking one by one according to a corresponding checking mechanism. The result verification unit 334 may be a plurality of units, and each unit corresponds to different bug result verifications.

For permission type vulnerabilities such as a horizontal override vulnerability, an unauthorized access vulnerability and a vertical override vulnerability, the result verification unit 334 queries the identification content in the URL mark field as a mark of the account permission, and starts the crawler engine to capture the functional point link when the account permission is not marked. For example, for an unauthorized access vulnerability, starting a crawler engine to capture the function point link using an unregistered account; and for the vertical unauthorized vulnerability, starting a crawler engine to capture the function point link by using a common account. When the function point link is grabbed, the account authority in the function point URL mark field is marked as 'no', and the risk is eliminated, namely the current risk state is modified from 'suspected' to 'false positive'.

For the horizontal override vulnerability and the vertical override vulnerability, when the result verification unit 334 queries that the mark responding to the account authority in the URL mark field is "yes", the mark of the user private function is queried; and when the mark of the user private function is 'yes', confirming the risk, namely, modifying the current risk state from 'suspected' to 'confirmed', and eliminating the risk when the mark of the user private function is 'no'.

For unauthorized access vulnerabilities, the risk is excluded when the result verification unit 334 queries a flag "yes" in response to the account permissions in the URL flag field.

In addition, for the cross-site request forgery vulnerability, the result verification unit 334 queries the sensitive function of the URL mark field of the current function point, and when the function is marked as "yes", confirms the risk; when it is marked "no", the risk is excluded.

The detection management unit 330 detects all functional points and determines whether all the identification contents in the URL marking fields are completely marked, queries the identification contents in the URL marking fields of each functional point as a mark for information storage, and performs detection of the storage-type cross-site script vulnerability again for the functional points marked as "no". The method comprises the steps that a replay request instruction is sent to a detection model unit for detecting the storage type cross-site scripting vulnerability, the detection model unit for detecting the storage type cross-site scripting vulnerability sends out a test request data packet again according to the instruction, a check subunit of the detection model unit compares the response content of the current request with the response content during rough detection, and whether the risk exists or not is confirmed according to the comparison result.

The vulnerability is divided into different groups according to the verification type, such as a request response verification type, a replacement request response verification type, a login credential replacement verification type, a response content verification type or a request replay verification type. And the loopholes of different verification types have different detection strategies aiming at the loophole types and are respectively executed by one detection model unit. Because the types of the vulnerabilities are continuously changed along with the version updating of the test target and other reasons, new vulnerabilities can appear at any time, and when the new vulnerabilities appear, the method only needs to match the corresponding check types for the new vulnerabilities and add the new vulnerabilities to the corresponding groups because of the adoption of the detection model unit mode. Or, when there is no existing verification type matched with the verification type, one detection model unit can be added to the verification type, and the operation of other detection model units is not influenced. The modularized detection mode has good expansibility, and certain vulnerability detection can be added or deleted at any time. Because the detection flow of the detection model unit is standardized, the detection items are also fixed in a standardized form, and when vulnerability detection is added, a security engineer only needs to modify related parameter items at the front end (such as a management interface provided by the invention), such as adding vulnerability names and types, setting corresponding verification types, or adding new verification types, and the like, so that the dependence on developers is greatly reduced, and the intervention and workload of the developers are reduced. And because of the standardization of the detection process and the strategy, a primary security engineer only with basic knowledge can complete final vulnerability review, and a high-level engineer concentrates on detection strategy formulation and new rule research. The invention divides the detection flow into two steps of initial coarse-grained safety detection and rechecked fine-grained safety detection, the coarse-grained safety detection is only configured with a small amount of optimal test cases, for example, a large amount of accurate test cases are called for rechecking after suspected bugs appear, so the requirement on the performance of the test server is not high, the security detection of the bugs can be completed quickly under the test environment with poor performance, the accuracy is high, and the efficiency is high.

The above embodiments are provided only for illustrating the present invention and not for limiting the present invention, and those skilled in the art can make various changes and modifications without departing from the scope of the present invention, and therefore, all equivalent technical solutions should fall within the scope of the present invention.

Claims

1. A vulnerability detection method includes:

configuring test parameters based on the test items, wherein the test parameters at least comprise a test target domain name, a test end browser IP address, a proxy server port, a vulnerability and a detection strategy thereof;

sending a function point test request data packet to a test target through a proxy server port based on the test end browser and receiving a returned response data packet;

the automatic detection tool obtains the mirror image data packet of the test request, and performs vulnerability detection on the function points one by one according to the configured vulnerabilities and the corresponding detection strategies; and

and in response to the end condition being met, ending the vulnerability detection.

2. The method of claim 1, further comprising configuring a manual detection tool that intercepts a functional point test request packet sent to a test target, upon which a security engineer manually performs vulnerability detection.

3. The method of claim 2, further comprising comparing the vulnerability detection results of the automatic detection tool and the vulnerability detection results of the manual detection tool, and checking the two detection results with each other to determine the vulnerability detection accuracy.

4. The method of claim 1, further comprising:

analyzing the test target source code to generate a list of function points to be tested; wherein the function point list comprises the following fields: a function point URL field, a detection state field and a URL function identification field.

5. The method of claim 4, wherein the URL function identification field includes one or more URL identifying content of account permissions, information storage, upload functions, sensitive functions, and user private functions.

6. The method of claim 5, wherein the automatic detection tool further comprises after obtaining the mirror image data packet of the test request:

analyzing the mirror image data packet to obtain a URL (uniform resource locator) of a corresponding function point, parameters, parameter values and function point identity marks in the data packet; and

and determining URL function identification content of the point based on the URL of the function point, the parameters, the parameter values and the corresponding configuration parameters in the data packet, and marking the URL function identification content of the function point in the function list.

7. The method according to claim 6, wherein the step of performing vulnerability detection on the function points one by one according to the configured vulnerabilities and the corresponding detection strategies comprises:

constructing an automatic test request data packet according to the bugs and the detection strategies thereof based on the URL of the function point, the parameters and the parameter values in the data packet;

sending the automatic test request data packet to a test target;

receiving a corresponding response packet returned by the test target, and analyzing response data from the response packet;

verifying the response data by adopting a corresponding verification method according to the verification type of the vulnerability;

determining that the current vulnerability is risk-free in response to the verification result meeting the passing condition; in response to the verification result not meeting the passing condition, determining suspected risk of the current vulnerability;

inquiring the mark of the URL function identification content of the function point;

responding to the mark of the URL function identification content of the function point to be no, reconstructing an automatic test request data packet, and performing risk confirmation or elimination on the suspected risk according to the verification result of the response data of the reconstructed automatic test request data packet; and

and responding to the content marked as yes in the URL function identification field of the function point, performing result verification by adopting a result verification strategy corresponding to the function identification content, and performing risk confirmation or elimination on the suspected risk according to the result verification.

8. The method of claim 7, wherein the automatic detection tool modifies the state of the function point in the detection state field in the function point list to be detected each time all vulnerability detections of one function point are completed.

9. The method of claim 7, further comprising: inquiring a detection state field and a URL function identification field of the function point list when a detection ending instruction is received;

responding to the detection states of all the function points in the function point list being detected and the contents in the URL function identification fields of all the function points being marked, and confirming that the end condition is met; and

and in response to the detection state of the functional point in the functional point list being undetected or the content in the URL function identification field of the functional point being unmarked, prohibiting to stop detection and sending out a reminding message.

10. The method according to claim 6, wherein the function point list further includes a function point identity field, and further comprising, when parsing the mirror data packet to obtain a current function point identity:

inquiring the function point identity identification field of the function point list; and

and in response to the fact that the function point identification of the mirror image data packet cannot be inquired in the function point identification field of the function point list, storing the URL, the parameter value and the function point identification of the mirror image data packet into the corresponding field in the function list.

11. The method of claim 6, wherein the function point identity is a hash value computed based on the URL and the parameter name.

12. The method of claim 6, wherein in parsing the mirrored data packet further comprises:

inquiring whether the currently analyzed parameter values contain test cases; and

and responding to the test case contained in the parameter value, and deleting the test case.

13. The method according to claim 6, wherein the automatic detection tool records the detection result and the function point detection identifier into a request record table after completing the vulnerability detection of the current function point based on the mirror image data packet; when the mirror image data packet is analyzed, calculating a second hash value by using the URL, the parameter name and the parameter value of the removed parameter as a function point detection identifier;

detecting and identifying a query request record table according to the function point; and

and responding to the functional point detection identification inquired in the request record table, and finishing the vulnerability detection of the functional point.

14. A vulnerability detection system, comprising:

the project detection management module is configured to provide configuration of various parameters, conditions and detection strategies required for safety detection of the test project, monitor the test process, store and display the detection result, and finish vulnerability detection when the finishing condition is met;

the test end browser is connected with the project detection management module, is configured to send a function point test request data packet to a test target through a configured proxy port, and receives a response data packet returned from the test target; and

and the automatic detection tool is connected with the project detection management module and is configured to acquire the mirror image data packet of the test request and carry out vulnerability detection on the function points one by one according to the configured vulnerabilities and the corresponding detection strategies.

15. The system of claim 14, further comprising a manual detection tool connected to the test-side browser and configured to intercept a feature point test request packet sent to a test target, and provide a manual detection interface for a security engineer to manually perform vulnerability detection based on the feature point test request packet.

16. The vulnerability detection system of claim 14, wherein the item detection management module comprises:

a management interface configured to provide parameter configuration of the test item, display of various data;

the function list generating unit is connected with the management interface and is configured to generate a list of function points to be tested according to a source code of a test target; and

and the monitoring unit is connected with the management interface and the function list generation unit, is configured to monitor the detection process according to the monitoring index, and generates a corresponding monitoring notice according to the monitoring result.

17. The vulnerability detection system of claim 14, wherein the automated detection tool further comprises:

the data packet acquisition module is configured to acquire a mirror image data packet of a test request sent to a test target from a configured agent port, send an automatic test request data packet to the test target and receive a corresponding response data packet returned by the test target;

a data packet analysis module connected with the data packet acquisition module and configured to parse the mirror image data packet and a response data packet returned from the test target; and

and the detection module is respectively connected with the data packet acquisition module and the data packet analysis module, is configured to construct an automatic test data packet based on the mirror image data packet and the analysis result, and performs vulnerability detection according to a configured detection strategy.

18. The vulnerability detection system of claim 17, wherein the packet analysis module comprises:

the request packet analysis unit is configured to analyze a request header, request parameters and user credentials of the mirror image data packet to obtain a URL (uniform resource locator), parameters and parameter values of the removed parameters;

a response packet parsing unit configured to parse a response data packet returned from the test target to obtain response content;

the marking unit is connected with the request packet analyzing unit and is configured to determine the service function of the function point according to the analyzed parameters and the configured parameters and mark corresponding identification contents of the URL function identification fields of the function points in the function point list; and

and the hash value calculation unit is connected with the request packet analysis unit and is configured to calculate a function point identity according to the URL and the parameter name of the removed parameter and calculate a function point detection identity according to the URL, the parameter name and the parameter value of the removed parameter.

19. The vulnerability detection system of claim 17, wherein the detection module comprises a detection management unit and a plurality of detection model units, the detection management unit configured to trigger the plurality of detection model units to implement detection of one or more vulnerabilities corresponding to their verification types according to a detection policy.