Web unauthorized vulnerability detection system based on large model

Abstract

The invention provides a Web unauthorized vulnerability detection system based on a large model, which comprises a crawler module used for simulating form elements and clickable webpage buttons to crawl comprehensive business URL (Uniform Resource Locator) interface information, the vulnerability verification module is used for carrying out vulnerability detection on a business URL interface by utilizing double accounts with different user identity information to obtain a vulnerability unauthorized interface and an unauthorized vulnerability interface, and is used for generating a report based on the unauthorized vulnerability interface and the vulnerability unauthorized interface, a large model technology is introduced, and the vulnerability verification efficiency is improved while the capability of a single step point is improved. And organic fusion of three steps of crawler crawling, vulnerability verification and report generation is also realized.

Description

Technical Field

[0001] The present application relates to the field of network security, and in particular to a Web unauthorized vulnerability detection system based on a large model. Background Art

[0002] With the rapid development of the Internet, Web applications are widely used, and security issues are becoming increasingly prominent. According to the statistics of OWASP TOP10, an authoritative security risk ranking in the field of network security, unauthorized vulnerabilities are listed as the top ten most serious Web application security risks. Unauthorized vulnerabilities refer to the situation in which users in Web applications can access, operate or obtain resources or functions that they should not access, operate or obtain without authorization or beyond their authorization scope.

[0003] Existing vulnerability scanning tools are excellent in detecting common Web vulnerabilities such as SQL injection, but are often ineffective in dealing with unauthorized access vulnerabilities. This is mainly because the logic of Web unauthorized access vulnerability detection is relatively complex. Although there are some detection tools for unauthorized access vulnerabilities in the industry, most of them are still in the research stage and lack detection accuracy, efficiency, and automation. This situation makes it difficult for many companies to detect vulnerabilities in a timely manner when facing complex permission management issues, thereby increasing the risk of data leakage or system intrusion. Therefore, Web application unauthorized access detection tools are crucial to improving the overall security of Web systems.

[0004] The general process of Web unauthorized vulnerability detection can be divided into three steps. First, the complete web page interface of the Web site needs to be obtained, then the unauthorized vulnerability of these interfaces needs to be accurately identified, and finally a detailed unauthorized vulnerability detection report is generated for the Web site. Regarding the current Web unauthorized vulnerability detection process, the existing Web unauthorized vulnerability detection technology has four defects: (1) Incomplete web interface data acquisition. Autorize relies on manual clicks on the web front-end interface to obtain web interface data. However, some web interfaces may be hidden under complex business logic, and it is difficult to obtain complete interface data through manual operation. In addition, for some large web sites with thousands of interfaces, it is obviously unrealistic to rely on manual clicks to obtain interfaces one by one.

[0005] (2) The accuracy of identifying unauthorized vulnerabilities is not high. Autorize only uses one set of vulnerability identification logic to identify whether a web page interface has an unauthorized vulnerability. However, the business scenarios of web sites are complex and the interfaces are diverse. One set of vulnerability identification logic is not applicable to all web page interfaces. As a result, the accuracy of Autorize's unauthorized vulnerability identification is not high.

[0006] (3) The threshold for writing unauthorized vulnerability detection reports is high and time-consuming. Autorize cannot automatically write unauthorized vulnerability detection reports. It can only provide unauthorized vulnerability detection results for each web page interface. Unauthorized vulnerability detection reports need to be written manually based on the results it provides. This requires certain professional skills and language expression skills of the report writer, and a report usually takes several hours to write, which is time-consuming and labor-intensive.

[0007] (4) The unauthorized vulnerability detection process is incomplete. Autorize does not cover the complete process of unauthorized vulnerability detection and can only implement one step—unauthorized vulnerability identification. The acquisition of interface data and the generation of unauthorized vulnerability detection reports still require manual operation or the assistance of other tools to complete. Summary of the invention

[0008] The embodiment of the present application provides a Web unauthorized vulnerability detection system based on a large model, which carefully constructs three modules: intelligent crawler, precise vulnerability verification and intelligent report generation. The three modules work together to achieve in-depth detection and effective management of Web application unauthorized vulnerabilities, overcome the limitations of traditional detection methods in terms of incomplete interface crawling, inaccurate vulnerability identification, and time-consuming and labor-intensive report writing, and significantly improve the security assurance capability and detection efficiency of Web applications.

[0009] In a first aspect, an embodiment of the present application provides a Web unauthorized vulnerability detection system based on a large model, including: The crawler module is used to identify the web page to identify the click element. When the page element corresponding to the click element is a clickable web page button, the clickable web page button is simulated to obtain the business URL interface information. When the page element corresponding to the click element is a form element, a form screenshot including the form element and a URL recognition instruction are sent to the large model for recognition to obtain the form URL recognition data, and the form URL recognition data is simulated to be filled in and submitted to obtain the business URL interface information of the business URL interface. The vulnerability verification module is used to extract user identity information based on the business URL interface information, and use a request without user identity information to request each URL interface to obtain unauthorized vulnerability interfaces and undetermined vulnerability interfaces. For undetermined vulnerability interfaces, the business URL interface information is input into the large model to output the operation type of the current URL interface, and dual accounts are used to perform corresponding horizontal unauthorized vulnerability detection and vertical unauthorized vulnerability detection on URL interfaces of different operation types to obtain vulnerability unauthorized interfaces; The report generation module is used to generate reports based on unauthorized vulnerability interfaces and vulnerability unauthorized interfaces.

[0010] In a second aspect, an embodiment of the present application provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the implementation method of the large model-based Web unauthorized vulnerability detection system.

[0011] The main contributions and innovations of the present invention are as follows: The Web unauthorized vulnerability detection system based on the big model provided by this solution introduces the big model technology on the basis of using the traditional crawler framework and detection method. While improving the capabilities of a single step point, it also realizes the organic integration of the three steps. For example, the interface data and screenshots generated by the crawler module, the detection results generated by the vulnerability verification module and other data will be used as the input of the big model in the report generation module, achieving the effect of 1+1+1>3, greatly improving the efficiency and accuracy of vulnerability detection. Through this system, both enterprise security teams and security researchers can more effectively discover and respond to unauthorized vulnerabilities in Web applications, improve the overall security of the system, and have important application value and broad application prospects in the field of network security.

[0012] Details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 It is a processing logic diagram of the crawler module of the embodiment of the present application identifying the click elements of the web page and performing simulation operations.

[0014] Figure 2 This is a processing logic diagram of the crawler module of the embodiment of the present application for form elements.

[0015] Figure 3 It is a schematic diagram of a form screenshot of an embodiment of the present application.

[0016] Figure 4 It is a schematic diagram of simulating filling out a form URL to identify data in an embodiment of the present application.

[0017] Figure 5 It is a logic diagram for detecting unauthorized vulnerability interfaces and undetermined vulnerability interfaces according to an embodiment of the present application.

[0018] Figure 6 This is a vulnerability detection logic diagram for the view-type URL interface.

[0019] Figure 7 This is a vulnerability detection logic diagram for the deletion type URL interface.

[0020] Figure 8 This is a vulnerability detection logic diagram for the modified type URL interface.

[0021] Fig. 9 It is a vulnerability detection logic diagram for detecting special types of vertical unauthorized vulnerabilities.

[0022] Fig.10 It is a specific example diagram of the report generation model.

[0023] Fig.11 It is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Instead, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0025] It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0026] Embodiment 1 This solution provides a Web unauthorized vulnerability detection system based on a large model, including: The crawler module is used to identify the web page to identify the click element. When the page element corresponding to the click element is a clickable web page button, the clickable web page button is simulated to obtain the business URL interface information. When the page element corresponding to the click element is a form element, a form screenshot including the form element and a URL recognition instruction are sent to the large model for recognition to obtain the form URL recognition data, and the form URL recognition data is simulated to be filled in and submitted to obtain the business URL interface information of the business URL interface. The vulnerability verification module is used to extract user identity information based on the business URL interface information, and use a request without user identity information to request each URL interface to obtain unauthorized vulnerability interfaces and undetermined vulnerability interfaces. For undetermined vulnerability interfaces, the business URL interface information is input into the large model to output the operation type of the current URL interface, and dual accounts are used to perform corresponding horizontal unauthorized vulnerability detection and vertical unauthorized vulnerability detection on URL interfaces of different operation types to obtain vulnerability unauthorized interfaces; The report generation module is used to generate reports based on unauthorized vulnerability interfaces and vulnerability unauthorized interfaces.

[0027] The Web unauthorized vulnerability detection system based on a large model provided by this solution takes the large model as the core driving force, builds a complete closed loop including a crawler module, a vulnerability verification module, and a report generation module, and collaboratively implements the general process of traditional Web unauthorized vulnerability detection to deeply detect and effectively manage Web application unauthorized vulnerabilities. This Web unauthorized vulnerability detection system based on a large model solves many difficulties in traditional Web unauthorized vulnerability detection, including but not limited to the fact that some traditional crawler tools cannot understand the semantic logic of the page and simulate business interactions, resulting in incomplete crawling of the web page interface, the existing vulnerability detection module does not divide the Web scene into fine-grained parts, and adopts a single detection logic, resulting in low accuracy in identifying unauthorized vulnerabilities, and the security report writing relies on manual work, with high thresholds and time-consuming and labor-intensive problems.

[0028] The crawler module proposed in this solution can automatically crawl the business interface of the web page based on the multimodal page recognition capability of the big model. Compared with traditional crawler tools, the crawler module can use the big model to support the processing of form forms to achieve deep interaction of complex business logic, capture more comprehensive interfaces, and reduce the risk of underreporting.

[0029] Specifically, the crawler module provided by the present solution further includes an event click submodule and a form recognition submodule, wherein the event click submodule is used to identify the Web page to identify the click element, and for the click element of the clickable web page button, simulate the clickable web page button to obtain the business URL interface information; wherein the form recognition submodule is used to send the form screenshot including the form element and the URL recognition instruction to the large model for recognition to obtain the form URL recognition data when the click element corresponds to the form element, and simulate the addition of the form URL recognition data to obtain the business URL interface information.

[0030] In the step of "identifying the Web page to identify the click element", the page elements corresponding to the click element include clickable web page buttons and form elements, wherein the form element is a form.

[0031] The "clickable web buttons" mentioned in this solution refer to elements that are intuitively visible and directly operable by users when browsing web pages. Their main purpose is to trigger specific operations or navigate to other pages. For example, in an e-commerce website, the "Add to Cart" button, "Buy Now" button, "View Details" button, etc. are typical clickable web buttons. When users click these buttons, corresponding JavaScript events will be triggered, such as sending a request to the server to obtain more product information, adding products to the shopping cart, or jumping to the order settlement page. The "form" mentioned in this solution is a comprehensive page element, which contains multiple input fields (such as text boxes, password boxes, drop-down menus, etc.) and one or more buttons for submitting form data. For example, on a user login page, after identifying the login form, it is necessary to further identify the user name and password input boxes in the form, as well as the "Login" submit button, so as to simulate the user entering the login information and clicking the submit button, so as to obtain relevant information of the login interface and determine whether there is an unauthorized vulnerability.

[0032] In some embodiments, a large model is used to identify click elements on a Web page, or HTML parsing technology is used to identify click elements on a Web page, or JavaScript page analysis technology is used to identify click elements on a Web page.

[0033] It should be noted that the URL obtained by simulating clicking on a clickable web page button or simulating filling in a form URL identification data is divided into two categories according to the content: one is the front-end URL, which does not generate a corresponding interface but is used for deep crawling; the second is the back-end URL, which generates a corresponding business URL interface. Therefore, in "simulating a clickable web page button to obtain business URL interface information" and "simulating filling in a form URL identification data to obtain business URL interface information", when the URL obtained by simulating a clickable web page button and / or simulating filling in a form URL identification data is a front-end URL, deep crawling is performed based on the page of the front-end URL; when the URL obtained by simulating a clickable web page button and / or simulating filling in a form URL identification data is a back-end URL, the business URL interface information of the back-end URL is obtained.

[0034] Specifically, Figure 1As shown, for the Web page to be processed, a certain Web page is selected for identification. When a clickable Web page button is identified, the clickable Web page button is simulated to obtain a new Web page. When a form element is identified, the form filling is simulated to obtain a new Web page. If the new Web page is a front-end URL, it is deduplicated from the Web page to be processed and then deeply crawled again. In other words, this solution will also maintain an array to record the crawled front-end URLs.

[0035] In the step of "when the page element corresponding to the clicked element is a form element, sending the form screenshot including the form element and the URL recognition instruction to the large model for recognition to obtain the form URL recognition data", the content of the URL recognition instruction is to instruct the large model to recognize the form URL recognition data in the form screenshot.

[0036] In the step of "simulating filling in and submitting form URL identification data to obtain business URL interface information", the form URL identification data is automatically filled in and submitted through the crawler framework to obtain the form URL identification data corresponding to the submitted form.

[0037] like Figure 2 As shown, the form screenshot is input into the large model to obtain the form URL identification data, and the form URL identification data is simulated and submitted to obtain the corresponding form URL identification data. Of course, if it cannot be submitted, the form URL identification data is manually entered.

[0038] like Figure 3 The form screenshot of a specific example is shown. The form screenshot and the URL identification instruction are sent to the big model to obtain the form URL identification data. The form URL identification data is as follows: example@example.com ", then simulate filling in the form URL data to get the following Figure 4 The interface shown in the figure will be displayed, and the API interface for obtaining the email will be automatically submitted: " / identity / api / v2 / user / change-email".

[0039] The business URL interface information obtained by the crawler module is passed to the vulnerability verification module in the form of a JSON file. The vulnerability verification module extracts user identity information and interface information from the business URL interface information to provide auxiliary data for subsequent detection. Specifically, in the step of "extracting user identity information based on business URL interface information", an identity information parameter list that lists various types of identity information parameters is set in the vulnerability verification module, and the URL interface information is compared with the identity information parameter list. If the identity information parameter in the identity information parameter list exists in the URL interface information, the user identity information corresponding to the identity information parameter is extracted.

[0040] It should be noted that this solution takes into account that the parameters of user identity information are diverse, including but not limited to cookies, Authorization, etc. The website may use one or several of the user identity information parameters as parameters for identity authentication. In order to ensure that all user identity information in the corresponding web page is obtained, an identity information parameter list that lists various types of identity information parameters is set in the vulnerability verification module of this solution. If there are multiple identity information parameters in the current web page at the same time, all identity information parameters will be processed as part of the user identity information. If an identity information parameter in the identity information list does not exist in the current page, the corresponding user identity information will not be extracted. The advantage of this is that it can effectively improve the accuracy and security of permission control.

[0041] In order to reduce the cost of subsequent detection, such as Figure 5 As shown, the vulnerability verification module of this solution uses a request packet that does not carry user identity information to request each URL interface to obtain an unauthorized vulnerability interface, wherein when the request is responded normally by the server, the current URL interface is an unauthorized vulnerability interface, and when the request cannot be responded normally by the server, the current URL interface is an undetermined vulnerability interface.

[0042] In some embodiments, the vulnerability verification module uses the requests function to request each URL interface using a request that does not carry user identity information. If the request of the current URL interface can be responded to normally (for example, the response code is 2xx), it proves that the current URL interface can be accessed normally without user identity information. If there is an unauthorized vulnerability, there must also be a horizontal / vertical authority override vulnerability. For unauthorized vulnerabilities, there is no need to perform subsequent horizontal authority override detection and vertical authority override detection. Otherwise, it is considered that the current URL interface does not have an unauthorized vulnerability, and the current URL interface is an undetermined vulnerability interface.

[0043] This solution is aimed at the subsequent horizontal unauthorized vulnerability detection and vertical unauthorized vulnerability detection for the undetermined vulnerability interface. It should be noted that the operation types of different URL interfaces are different. For example, under normal circumstances, GET requests are considered to be viewing operations, but in some websites, the URL may contain parameters representing specific operations. For example, a URL like http: / / xxx / delete=1, although using a GET request, may actually perform a deletion operation. Therefore, there is a large error in judging the operation type based solely on the request method, and the method of regular matching or enumerating special parameters in the URL is not applicable due to the diversity of parameters. Therefore, this solution uses a large model to identify the operation type of the undetermined vulnerability interface. Correspondingly, in the step of "inputting the business URL interface information into the large model to output the operation type of the current URL interface", the business URL interface information of the undetermined vulnerability interface is input into the large model with preset identification operation types for identification, so as to output the operation type of the current undetermined vulnerability interface.

[0044] In some embodiments, the operation types of the URL interface include: viewing type, deletion type, modification type and upload type. Different detection logics are used for URL interfaces of different operation types, thereby effectively reducing the false alarm rate and missed alarm rate.

[0045] Specifically, in the step of "using dual accounts to perform corresponding horizontal unauthorized access vulnerability detection and vertical unauthorized access vulnerability detection on URL interfaces of different operation types to obtain vulnerability unauthorized access interfaces", dual accounts with the same authority are used to perform horizontal unauthorized access vulnerability detection on URL interfaces of different operation types, and dual accounts with different authority are used to perform vertical unauthorized access vulnerability detection on URL interfaces of different operation types, wherein the dual accounts used for horizontal unauthorized access vulnerability detection include a first account and a second account with different user identity information but the same authority, and the current URL interface is located in the interface list of the first account; wherein the dual accounts used for vertical unauthorized access vulnerability detection include a first account and a second account with different user identity information and different authority, the authority of the first account is higher than the authority of the second account, and the current URL interface is located in the interface list of the first interface.

[0046] The detection logic for horizontal privilege escalation vulnerability detection and vertical privilege escalation vulnerability detection is the same: For the viewing type URL interface, a first account is used to initiate a normal request to the URL interface to obtain first response data, and a second account is used to issue the same normal request to the URL interface to obtain second response data. If the response codes corresponding to the first response data and the second response data are the same, it is determined whether the response packets of the first response data and the second response data are the same and whether the length of the response packets is greater than 5. If the response packets are the same and the length of the response packets is greater than 5, it is determined whether the current URL interface exists in the interface list of the second account. If not, the current URL interface is defined as a vulnerable and unauthorized interface.

[0047] like Figure 6 As shown, first use the first account A to initiate a normal request to the URL interface, then replace the user identity information of the first account A with the second account B and initiate a normal request again, compare the response codes and response packets of the two normal requests, if the response codes of the two normal requests are different or not 2xx, it is determined that there is no vulnerability, if the response codes of the two normal requests are the same, then further compare the response packets of the two normal requests, if the contents of the two response packets are the same and the length exceeds 5 bytes, then check whether the URL of the current URL interface exists in the interface list of the second account B, the purpose of this is to determine whether the current URL interface is a public resource interface, if the current URL interface exists in the interface lists crawled by the first account A and the second account B at the same time, then it is considered that the current URL interface is a non-unauthorized public resource interface, if not, then it can be determined that the current URL interface is a vulnerability unauthorized interface.

[0048] For the deletion type URL interface, a reconstruction request package is constructed with the same request content as the request package of the first account A but the user identity information is the second account B. Based on the reconstruction request package, a request is made to the current URL interface. If the request is successfully executed, the user identity information of the reconstruction request package is replaced with the first account A to obtain a secondary request package. Based on the secondary request package, a request is made to the current URL interface. If the request fails to be successfully executed, the current URL interface is a vulnerable and unauthorized interface.

[0049] like Figure 7As shown, a reconstruction request packet with user identity information of the second account B is sent to the current URL interface. All contents in the reconstruction request packet are the same as the request contents of the first account A, except that the user identity information is replaced by the second account B. After the reconstruction request packet is sent, if the request is not successfully executed (the response code is not 2xx), it means that the second account B has no right to access the URL interface, so there is no unauthorized behavior, because the current detection is for the URL interface of the first account A. If the request is successfully executed, there may be two situations: one is that the second account B deleted the resources of the first account A, and the second is that the second account B deleted its own resources. Therefore, this solution replaces the user identity information of the reconstruction request packet with the first account A to obtain a secondary request packet and send the request again. If the request can be successfully executed, it means that the second account B deleted its own resources, and at this time, there is no unauthorized behavior in the URL interface. If the request fails to be successfully executed, it means that the second account B deleted the resources of the first account A, and at this time, there is unauthorized behavior in the URL interface.

[0050] For modification type and upload type URL interfaces, use the request package of the first account A to initiate a normal request to the current URL interface, obtain the baseline response package returned by the current URL interface, replace the user identity information in the request package with the second account B, and then initiate a secondary request to the current URL interface again. If the secondary request is successfully executed, obtain the secondary response package returned by the current URL interface. If the baseline response package and the secondary response package are the same and the data length is greater than 5, the current URL interface is a vulnerable and unauthorized interface.

[0051] like Figure 8 As shown, first use the first account A to initiate a normal request to the current URL interface and obtain a baseline response package, then replace the user identity in the request package of the first account A with the second account B and request the current URL interface again. If the second request fails to execute successfully, it means that the current URL interface does not allow other user identities to perform modification operations, so there is no unauthorized access vulnerability; if the second request can be successfully executed, if the baseline response package and the secondary response package are the same and the data length is greater than 5 bytes, it means that the second request returns the resources of the first account A, which indicates that the current URL interface has not verified the user identity information, and the current URL interface is a vulnerable unauthorized access interface; on the contrary, if the data of the baseline response package and the secondary response package are different, it means that the second account B has the right to perform the request operation to modify and return the resources of the second account B, which indicates that there is no vulnerability in the current URL interface.

[0052] Unauthorized access vulnerabilities usually arise from requests or operations not being bound to user identity information. When a modification-type request is successfully executed, the URL interface usually returns the modified data, and the account to which the returned data belongs is generally associated with the user identity information. Therefore, for the second request initiated to the current URL interface after replacing the user identity information in the request package with the second account B, if the returned data belongs to the second account B, it means that the request to modify the second account B is also for the second account B, which indicates that the interface has been bound to the identity according to the user identity information. In this case, there is no unauthorized access problem; however, if the data returned by the second request still belongs to the first account A, it means that the request of the second account B has modified the resources of the first account A, indicating that the interface has not performed appropriate permission verification based on the user identity information, thus there is an unauthorized access vulnerability. It should be noted that, since both upload operations and modification operations are performed by uploading data and returning system resources, based on this similarity, this solution uses the same vulnerability detection logic for modification-type URL interfaces and upload-type URL interfaces.

[0053] In addition, there is a special type of vertical privilege escaping vulnerability in the actual testing process. Specifically, when analyzing URLs such as http: / / xxx / user / xxx, it is found that the URL contains a parameter user that may represent a user identity. Under normal circumstances, accessing the URL may fail, but when the value of the user parameter is replaced with a higher-level user identity (such as admin), the system allows the request to succeed. This shows that the URL interface determines access rights through the identity parameters in the URL, thus exposing a vertical privilege escaping vulnerability. Therefore, for this special type of vertical privilege escaping vulnerability, the vulnerability detection module of the large-model-based Web privilege escaping vulnerability detection system provided by this solution additionally implements the following steps: Determine whether there is an ordinary user parameter representing an ordinary user in the URL of the current URL interface. If so, replace the ordinary user parameter with the administrator user parameter to obtain the update URL. Use a request package without user identity information to request the update URL in different request methods. If the update URL can respond successfully, the current URL interface is an unauthorized vulnerability interface. If the update URL cannot respond successfully, use a request package with user identity information to request the update URL. If the update URL can respond successfully, the current URL interface is a vulnerability and unauthorized interface.

[0054] like Fig. 9As shown, first determine whether there are ordinary user parameters such as user representing ordinary users in the URL of the current URL interface. If not, this special type of vertical unauthorized access vulnerability does not exist. If it exists, replace the ordinary user parameters such as user representing ordinary users with administrator parameters such as admin representing administrators, and use request packets without user identity information such as cookies to try to access using different request methods. If a request with a response code such as 2xx can be generated, the current URL interface is an unauthorized vulnerability interface; if a request with a response code such as 2xx is not generated, continue to use the request packet carrying user identity information to access. If a request with a response code such as 2xx can be generated, the current URL interface is a vulnerability unauthorized access interface. If a request with a response code such as 2xx cannot be generated, this special type of vertical unauthorized access vulnerability does not exist in the current URL interface.

[0055] This solution uses the first account and the second account with different user identities to simulate user operations to perform vulnerability detection on the URL interface. This vulnerability detection method can identify and exclude public resource interfaces. For URL interfaces that are not public resource interfaces, targeted vulnerability detection can be performed based on the different data operation types of the URL interface. In terms of vulnerability detection, this system performs better than the Autorize tool in Burp Suite. The Autorize tool relies on manual clicks during the detection process, and is prone to false positives for public interfaces, and there are omissions for deletion-type interface variants. This system effectively reduces the false positive rate (from 58.3% to 4.2%) and the omission rate (to 0%) by optimizing the detection logic, such as adding a public interface filtering mechanism and formulating a special deletion interface detection logic.

[0056] The report generation module of the present solution can automatically generate reports based on the large model. Specifically, the report generation module includes an image acquisition submodule and a report generation submodule loaded with the large model, wherein the image acquisition submodule is used to obtain screenshots of web pages and interface front-end screenshots of unauthorized vulnerability interfaces and vulnerability overriding interfaces, wherein the report generation submodule is used to generate reports based on the screenshots of web pages, interface front-end screenshots of unauthorized vulnerability interfaces and vulnerability overriding interfaces, and vulnerability information of unauthorized vulnerability interfaces and vulnerability overriding interfaces, wherein the vulnerability information includes vulnerability types, vulnerability detection methods, and response data of unauthorized vulnerability interfaces and vulnerability overriding interfaces.

[0057] It should be noted that vulnerability information can be obtained through the vulnerability verification module. When the vulnerability verification module detects vulnerability unauthorized interfaces and unauthorized vulnerability interfaces, the corresponding vulnerability information is generated synchronously.

[0058] The big model-based Web unauthorized vulnerability detection system of this solution is a Scrapy+playwright framework combined with a big model. Specifically, the image acquisition submodule of the report generation module uses Playwright's screenshot function to take screenshots when clicking on clickable web page buttons and submitting form URLs to identify data, and records the screenshot path and related information in JSON format to provide an intuitive business scenario display for the report; the report output submodule combines screenshots of web pages and interface front-end screenshots of unauthorized vulnerability interfaces and vulnerability unauthorized vulnerability interfaces, and vulnerability information of unauthorized vulnerability interfaces and vulnerability unauthorized interfaces, and uses the multimodal processing capabilities and natural language generation capabilities of the big model to generate a security report that includes a website introduction, web interface function description, and vulnerability description. Fig.10 The figure shows a specific example. The Web unauthorized vulnerability detection system based on the big model uses the corresponding prompt with the help of the big model to generate a website introduction based on the screenshot of the Web page, generate a web page interface function description based on the interface front-end screenshots of the unauthorized vulnerability interface and the vulnerability unauthorized interface, and generate a vulnerability description based on the vulnerability information. The vulnerability description analyzes various vulnerabilities in detail from the aspects of URL, request method, page screenshot, function description, request and response information and vulnerability description, and finally generates a report based on the website introduction, web page interface function description and vulnerability description.

[0059] The report generation module of this system overcomes the difficulty of traditional manual report writing, which is time-consuming, labor-intensive and requires high professional skills. This system can automatically generate customized reports, improve the efficiency and quality of report generation, and provide security personnel with a faster and more accurate basis for vulnerability assessment.

[0060] In summary, in terms of crawler capabilities, this system performs excellently. Taking the test of the Crapi range as an example, compared with the AWVS tool, the number of web page interfaces obtained increased from 29 to 36, and the number of vulnerability interfaces included increased from 9 to 12, which is consistent with the number of real vulnerability interfaces, effectively reducing the risk of missed reports. In terms of vulnerability detection accuracy, compared with the Autorize tool in BurpSuite, the false alarm rate of this system has dropped significantly from 58.3% to 4.2%, and the missed alarm rate has dropped from 8.3% to 0%. For example, when processing viewing interfaces, the Autorize tool generates 13 false alarms due to public interface identification and response code judgment problems. This system avoids false alarms through public interface filtering mechanisms and precise response code judgment logic; when processing deletion interfaces, the Autorize tool misses the "delete video" vulnerability, and this system accurately identifies it with special detection logic. In addition, this solution enables efficient security report generation. The report generation module uses the big model capability, combined with detection and crawling data, to automatically generate customized reports covering system introduction, detection result summary and vulnerability details, shortening the writing time, lowering the technical threshold, and improving the response speed of security analysis and vulnerability confirmation. The innovation is outstanding. In terms of intelligent crawling technology, the big model is combined with JavaScript scripts. The event click submodule automatically simulates clicks to obtain the backend interface. The form recognition submodule uses the big model to process complex form business. The deep recursive crawling submodule uses the deduplication mechanism to fully crawl multi-level pages, overcome the shortcomings of traditional crawlers, and solve the problem of incomplete interface crawling. In terms of intelligent vulnerability identification technology, the semantic understanding ability of the big model is used to fine-grainedly divide Web business scenarios, and differentiated detection logic is designed for different types of interfaces, such as public interface processing of viewing interfaces, and modifying interfaces to determine unauthorized access by associating the response body with identity information, etc., to improve detection accuracy. In terms of intelligent report generation technology, relying on the multimodal capabilities of large models, security knowledge base and natural language generation capabilities, based on preset prompt templates and related data, high-quality reports are output in multiple dimensions to solve the difficulties of traditional report writing and improve the efficiency of security assessment and vulnerability management.

[0061] Embodiment 2 This embodiment also provides an electronic device, referring to Fig.11 , including a memory 404 and a processor 402, wherein the memory 404 stores a computer program, and the processor 402 is configured to run the computer program to execute the steps in the embodiment of the above-mentioned large model-based Web unauthorized vulnerability detection system.

[0062] Specifically, the processor 402 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0063] The memory 404 may include a large-capacity memory 404 for data or instructions. By way of example and not limitation, the memory 404 may be used to store or cache various data files that need to be processed and / or used for communication, as well as possible computer program instructions executed by the processor 402.

[0064] The processor 402 implements the embodiment of the Web unauthorized vulnerability detection system based on a large model in the above embodiment by reading and executing the computer program instructions stored in the memory 404 .

[0065] Optionally, the electronic device may further include a transmission device 406 and an input / output device 408 , wherein the transmission device 406 is connected to the processor 402 , and the input / output device 408 is connected to the processor 402 .

[0066] Transmission device 406 may be used to receive or send data via a network.

[0067] The input / output device 408 is used to input or output information. In this embodiment, the input information may be a web page, etc., and the output information may be a report, etc.

[0068] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0069] Embodiments of the present invention can be implemented by computer software, which is executable by a data processor of a mobile device, such as in a processor entity, or implemented by hardware, or implemented by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets and / or macros can be stored in any device readable data storage medium, and they include program instructions for performing specific tasks. Computer program products can include one or more computer executable components configured to perform embodiments when the program is running. One or more computer executable components can be at least one software code or a part thereof. In addition, at this point, it should be noted that any box of the logic flow in the figure can represent a program step, or interconnected logic circuits, boxes and functions, or a combination of program steps and logic circuits, boxes and functions. Software can be stored in physical media such as memory chips or storage blocks implemented in processors, magnetic media such as hard disks or floppy disks, and optical media such as, for example, DVDs and data variants thereof, CDs. Physical media are non-transient media.

[0070] Those skilled in the art should understand that the technical features of the above embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0071] The above embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A Web unauthorized vulnerability detection system based on a large model, characterized in that: include: The crawler module is used to identify the web page to identify the click element. When the page element corresponding to the click element is a clickable web page button, the clickable web page button is simulated to obtain the business URL interface information. When the page element corresponding to the click element is a form element, a form screenshot including the form element and a URL recognition instruction are sent to the large model for recognition to obtain the form URL recognition data, and the form URL recognition data is simulated to be filled in and submitted to obtain the business URL interface information of the business URL interface. The vulnerability verification module is used to extract user identity information based on the business URL interface information, and use a request without user identity information to request each URL interface to obtain unauthorized vulnerability interfaces and undetermined vulnerability interfaces. For undetermined vulnerability interfaces, the business URL interface information is input into the large model to output the operation type of the current URL interface, and dual accounts are used to perform corresponding horizontal unauthorized vulnerability detection and vertical unauthorized vulnerability detection on URL interfaces of different operation types to obtain vulnerability unauthorized interfaces; The report generation module is used to generate reports based on unauthorized vulnerability interfaces and vulnerability unauthorized interfaces.

2. The large model-based Web unauthorized vulnerability detection system according to claim 1 is characterized in that: In "Simulate clickable webpage buttons to obtain business URL interface information" and "Simulate filling in form URL identification data to obtain business URL interface information", when the URL obtained by simulating clickable webpage buttons and / or simulating filling in form URL identification data is a front-end URL, deep crawling is performed based on the page of the front-end URL; When the URL obtained by simulating a clickable webpage button and / or simulating filling in a form URL identification data is a backend URL, the business URL interface information of the backend URL is obtained.

3. The large model-based Web unauthorized vulnerability detection system according to claim 1 is characterized in that: In the step of "inputting the business URL interface information into the big model to output the operation type of the current URL interface", the business URL interface information of the undetermined vulnerability interface is input into the big model with preset identification operation types for identification to output the operation type of the current undetermined vulnerability interface. The operation types of the URL interface include view type, delete type, modify type and upload type.

4. The large model-based Web unauthorized vulnerability detection system according to claim 1 is characterized in that: Two accounts with the same authority are used to perform horizontal unauthorized access vulnerability detection on URL interfaces of different operation types, and two accounts with different authority are used to perform vertical unauthorized access vulnerability detection on URL interfaces of different operation types, wherein the two accounts used for horizontal unauthorized access vulnerability detection include a first account and a second account with different user identity information but the same authority, and the current URL interface is located in the interface list of the first account; wherein the two accounts used for vertical unauthorized access vulnerability detection include a first account and a second account with different user identity information and different authority, the authority of the first account is higher than that of the second account, and the current URL interface is located in the interface list of the first interface.

5. The large model-based Web unauthorized vulnerability detection system according to claim 4 is characterized in that: For the viewing type URL interface, a first account is used to initiate a normal request to the URL interface to obtain first response data, and a second account is used to issue the same normal request to the URL interface to obtain second response data. If the response codes corresponding to the first response data and the second response data are the same, it is determined whether the response packets of the first response data and the second response data are the same and whether the length of the response packets is greater than 5. If the response packets are the same and the length of the response packets is greater than 5, it is determined whether the current URL interface exists in the interface list of the second account. If not, the current URL interface is defined as a vulnerable and unauthorized interface.

6. The large model-based Web unauthorized vulnerability detection system according to claim 4 is characterized in that: For the deletion type URL interface, a reconstruction request package is constructed with the same request content as the request package of the first account but the user identity information is the second account. Based on the reconstruction request package, a request is initiated to the current URL interface. If the request is successfully executed, the user identity information of the reconstruction request package is replaced with the first account to obtain a secondary request package. Based on the secondary request package, a request is initiated to the current URL interface. If the request fails to be successfully executed, the current URL interface is a vulnerable and unauthorized interface.

7. The large model-based Web unauthorized vulnerability detection system according to claim 4 is characterized in that: For modification type and upload type URL interfaces, use the request package of the first account A to initiate a normal request to the current URL interface, obtain the baseline response package returned by the current URL interface, replace the user identity information in the request package with the second account B, and then initiate a secondary request to the current URL interface again. If the secondary request is successfully executed, obtain the secondary response package returned by the current URL interface. If the baseline response package and the secondary response package are the same and the data length is greater than 5, the current URL interface is a vulnerable and unauthorized interface.

8. The large model-based Web unauthorized vulnerability detection system according to claim 1 is characterized in that: Determine whether there is an ordinary user parameter representing an ordinary user in the URL of the current URL interface. If so, replace the ordinary user parameter with the administrator user parameter to obtain the update URL. Use a request package without user identity information to request the update URL in different request methods. If the update URL can respond successfully, the current URL interface is an unauthorized vulnerability interface. If the update URL cannot respond successfully, use a request package with user identity information to request the update URL. If the update URL can respond successfully, the current URL interface is a vulnerability and unauthorized interface.

9. The large model-based Web unauthorized vulnerability detection system according to claim 1 is characterized in that: The report generation module includes an image acquisition submodule and a report generation submodule loaded with a large model, wherein the image acquisition submodule is used to obtain screenshots of web pages and interface front-end screenshots of unauthorized vulnerability interfaces and vulnerability overriding interfaces, wherein the report generation submodule is used to generate a report in combination with the screenshots of web pages, interface front-end screenshots of unauthorized vulnerability interfaces and vulnerability overriding interfaces, and vulnerability information of unauthorized vulnerability interfaces and vulnerability overriding interfaces, wherein the vulnerability information includes the vulnerability type, vulnerability detection method, and response data of the unauthorized vulnerability interface and the vulnerability overriding interface.

10. An electronic device comprising a memory and a processor, characterized in that: The memory stores a computer program, and the processor is configured to run the computer program to execute the implementation method of the large model-based Web unauthorized vulnerability detection system according to any one of claims 1 to 9.

Images