A penetration testing method based on a large model and a security vulnerability library

Abstract

This application discloses a penetration testing method based on a large model and a security vulnerability database, relating to the field of penetration testing technology. The method employs a replayable action chain to reconstruct the real business call context, combines a role-based access control matrix to pre-locate potential unauthorized call interfaces, and determines the corresponding parameter placeholder rules based on the call condition information of the unauthorized call interface. Simultaneously, it automatically generates test operation sequences and authentication context packets based on the large model, and then automatically constructs unauthorized requests to execute unauthorized tests based on these test operation sequences, authentication context packets, and parameter placeholder rules. Combined with a security vulnerability database, it completes intelligent vulnerability assessment, forming a closed-loop, fully automated unauthorized penetration testing system. This method can accurately identify target interfaces exhibiting abnormal call behavior, significantly reducing the workload of preliminary unauthorized testing and lowering testing manpower costs.

Description

Technical Field

[0001] This application relates to the field of penetration testing technology, and in particular to a penetration testing method based on a large model and a security vulnerability database. Background Technology

[0002] Penetration testing is an important means of assessing the security of information systems, aiming to proactively discover potential security vulnerabilities by simulating attack behaviors.

[0003] Current mainstream penetration testing solutions mainly fall into two categories: First, automated scanning tools based on rule engines, such as AppScan and Nessus, can automatically execute repetitive requests. However, the testing strategies are pre-configured, requiring manual configuration of the test scope, entry of account information, and analysis of response results. Second, manual penetration testing relies on the experience of security experts. This can discover complex logical vulnerabilities, but it is inefficient and costly. Therefore, current penetration testing methods still require significant human intervention, resulting in high labor costs.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a penetration testing method based on a large model and a security vulnerability database, aiming to solve the technical problem of how to reduce human intervention in penetration testing and thus reduce labor costs.

[0006] To achieve the above objectives, this application proposes a penetration testing method based on a large model and a security vulnerability database. The penetration testing method based on the large model and the security vulnerability database includes: Obtain the call execution sequence of each interface under test from the replayable action chain, and determine the unauthorized call interface from the interface under test based on the call execution sequence and the preset role permission matrix; Obtain the calling condition information corresponding to the unauthorized calling interface, and determine the parameter placeholder rules corresponding to the unauthorized calling interface based on the calling condition information; Input the invocation condition information, the replayable action chain, the role permission matrix and the test account list into the preset large model, and obtain the test operation sequence and authentication context package corresponding to each test account output by the preset large model; An unauthorized request is constructed based on the authentication context packet corresponding to each test account and the parameter placeholder rules, and an unauthorized test is performed on the unauthorized call interface based on the unauthorized request. Obtain the call response information corresponding to each of the above unauthorized requests, and determine the unauthorized test result based on the call response information.

[0007] In one embodiment, the test operation sequence includes the call request and call order corresponding to each of the unauthorized call interfaces, the authentication context package includes the interface access credentials of each of the test accounts, and the unauthorized test includes horizontal unauthorized test and vertical unauthorized test; The horizontal privilege escalation test refers to simulating the first test account accessing the interface corresponding to the resource instance belonging to the second test account based on the interface access credentials of the first test account. The vertical privilege escalation test refers to simulating the first test account calling an interface that is only allowed to be accessed by a third test account with higher privileges than the first test account in the role permission matrix, based on the interface access credentials of the first test account.

[0008] In one embodiment, the step of constructing an unauthorized access request based on the authentication context packet corresponding to each test account and the parameter placeholder rules, and performing an unauthorized access test on the unauthorized access call interface based on the unauthorized access request, includes: From the test operation sequence corresponding to the first test account, obtain the first call request and the first call order corresponding to each of the unauthorized call interfaces; According to the parameter placeholder rules corresponding to the unauthorized call interface, the resource ownership parameter in the first call request is replaced with the resource instance identifier value corresponding to the second test account, wherein the resource ownership parameter is used to indicate the account to which the requested resource instance belongs; The unauthorized request is constructed based on the replaced first call request and the interface access credentials corresponding to the first test account; Based on the unauthorized request and the first call order, the horizontal unauthorized access test is performed on the unauthorized call interface.

[0009] In one embodiment, the step of constructing an unauthorized access request based on the authentication context packet corresponding to each test account and the parameter placeholder rules, and performing an unauthorized access test on the unauthorized access call interface based on the unauthorized access request, further includes: From the test operation sequence corresponding to the third test account, obtain the third call request and the third call order corresponding to each of the unauthorized call interfaces; The unauthorized request is constructed based on the interface access credentials corresponding to the first test account and the third call request; Based on the unauthorized request and the third call order, the vertical unauthorized test is performed on the unauthorized call interface.

[0010] In one embodiment, the call response information includes a response status code and business response content, and the step of determining the unauthorized access test result based on the call response information includes: The call response information and the role permission matrix are input into the large model so that the large model can determine whether the unauthorized call interface has an unauthorized vulnerability by using the vulnerability knowledge rules in the security vulnerability database. When the unauthorized call interface has an unauthorized vulnerability, a penetration test report is generated based on the call response information, the unauthorized request corresponding to the call response information, and the test account, and the unauthorized test result is obtained.

[0011] In one embodiment, before the step of performing an unauthorized access test on the unauthorized call interface based on the unauthorized request, the method further includes: Based on each test account in the test account list, a login request is sent to the login interface in the interface to be tested, and the session credentials returned by the business system server are obtained from the login response; After successful login, the session remains idle until the maximum idle time of the session is exceeded. Then, based on the session credentials, a timeout access request is sent to the resource interface corresponding to the login interface to obtain the timeout access response information corresponding to the timeout access request. The timeout access response information is input into the large model so that the large model can determine whether the resource interface has a session timeout vulnerability by using the vulnerability knowledge rules in the security vulnerability database. When it is determined that the resource interface does not have a session timeout vulnerability, the step of performing an unauthorized test on the unauthorized call interface based on the unauthorized request is executed.

[0012] In one embodiment, after the step of sending a login request to the login interface of the interface under test based on each of the test accounts in the test account list, and obtaining the session credentials returned by the business system server from the login response, the method further includes: Based on the session credentials, an access request is sent to the resource interface corresponding to the login interface; After successful access, the cancellation interface is called to initiate a cancellation request for the test account in order to perform the test account cancellation operation; After successfully performing the test account cancellation operation, the resource interface is accessed again based on the session credentials to obtain the access response information after cancellation. The post-logout access response information is input into the large model so that the large model can determine whether the resource interface has a logout failure vulnerability by using the vulnerability knowledge rules in the security vulnerability database. When it is determined that the resource interface does not have a cancellation failure vulnerability, the step of performing an unauthorized test on the unauthorized call interface based on the unauthorized request is executed.

[0013] In one embodiment, after the step of sending an access request to the resource interface corresponding to the login interface based on the session credentials, the method further includes: Obtain the request parameters corresponding to the access request, and delete the anti-cross-site token in the request parameters to construct a fake cross-site request; Determine a preset sensitive business interface from the interfaces to be tested, and in a browser environment where the test account is logged in, send the pseudo cross-site request to the preset sensitive business interface and obtain the interface response information corresponding to the pseudo cross-site request. The interface response information is input into the large model so that the large model can determine whether the preset sensitive business interface has a cross-site request forgery vulnerability by using the vulnerability knowledge rules in the security vulnerability database. When it is determined that the resource interface does not have a cross-site request forgery vulnerability, the step of performing an unauthorized test on the unauthorized call interface based on the unauthorized request is executed.

[0014] This application provides a penetration testing method based on a large model and a security vulnerability database. It employs a replayable action chain to reconstruct the real business call context, combines a role-based access control matrix to pre-locate potential unauthorized call interfaces, and determines the corresponding parameter placeholder rules based on the call condition information of the unauthorized call interface. Simultaneously, it automatically generates test operation sequences and authentication context packets based on the large model, and then automatically constructs unauthorized requests based on these sequences, context packets, and parameter placeholder rules to execute unauthorized tests. This is further enhanced by a security vulnerability database to complete intelligent vulnerability assessment, forming a closed-loop, fully automated unauthorized penetration testing system. Compared to traditional methods that rely on manually writing test cases or manually constructing unauthorized requests at single points, this embodiment extracts the test object based on the real business operation chain. This avoids the problems of incomplete manual analysis of interface call relationships or missing scenario coverage, accurately identifies target interfaces exhibiting abnormal call behavior, significantly reduces the workload of pre-test analysis, and lowers testing manpower costs. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating an embodiment of the penetration testing method based on a large model and a security vulnerability database provided in this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the penetration testing method based on a large model and a security vulnerability database in this application. Figure 3 This is a flowchart illustrating the third embodiment of the penetration testing method based on a large model and a security vulnerability database in this application. Figure 4 This is a flowchart illustrating Embodiment 4 of the penetration testing method based on a large model and a security vulnerability database in this application. Figure 5 This is a flowchart illustrating Embodiment 5 of the penetration testing method based on a large model and a security vulnerability database in this application. Figure 6 This is a flowchart illustrating Embodiment Six of the penetration testing method based on a large model and a security vulnerability database in this application. Figure 7 This is a schematic diagram of the overall process provided in Embodiment 7 of the penetration testing method based on a large model and a security vulnerability database in this application; Figure 8 This is a flowchart illustrating the scheduling and execution of detection tasks provided in Embodiment 7 of this application; Figure 9 This is a schematic diagram of the device structure of the hardware operating environment involved in the penetration testing method based on a large model and a security vulnerability database in the embodiments of this application.

[0018] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments. It should be noted that all actions involving the acquisition of signals, information, or data in this application are performed in accordance with the relevant data protection laws and regulations of the country where the application is located, and with authorization from the owner of the corresponding device.

[0021] Penetration testing is an important means of assessing the security of information systems, aiming to proactively discover potential security vulnerabilities by simulating attack behaviors.

[0022] Current mainstream penetration testing solutions mainly fall into two categories: First, automated scanning tools based on rule engines, such as AppScan and Nessus, can automatically execute repetitive requests. However, the testing strategies are pre-configured, requiring manual configuration of the test scope, entry of account information, and analysis of response results. Second, manual penetration testing relies on the experience of security experts. This can discover complex logical vulnerabilities, but it is inefficient and costly. Therefore, current penetration testing methods still require significant human intervention, resulting in high labor costs.

[0023] In view of the above problems, this application proposes a penetration testing method based on a large model and a security vulnerability database. The method involves obtaining the call execution sequence of each interface under test from a replayable action chain, identifying unauthorized call interfaces based on the call execution sequence and a preset role-permission matrix, obtaining the call condition information corresponding to the unauthorized call interfaces from the interface description document, and determining the parameter placeholder rules for the unauthorized call interfaces based on the call condition information, and then inputting the interface description document, replayable action chain, role-permission matrix, and test account list into a preset large model to obtain the test operation sequence and authentication context packet corresponding to each test account output by the preset large model. Further, an unauthorized request is constructed based on the authentication context packet and parameter placeholder rules corresponding to each test account, and unauthorized testing is performed on the unauthorized call interfaces based on the unauthorized requests. Finally, the call response information corresponding to each unauthorized request is obtained, and the unauthorized test result is determined based on the call response information.

[0024] The above method employs a replayable action chain to reconstruct the real business call context, combines a role-based permission matrix to pre-locate potential unauthorized call interfaces, and determines the corresponding parameter placeholder rules based on the call condition information of the unauthorized call interface. Simultaneously, it automatically generates test operation sequences and authentication context packages based on a large model, and then automatically constructs unauthorized requests based on these test operation sequences, authentication context packages, and parameter placeholder rules to execute unauthorized tests. Furthermore, it utilizes a security vulnerability database to complete intelligent vulnerability assessment, forming a closed-loop, fully automated unauthorized penetration testing system. Compared to traditional methods that involve manually writing test cases or manually constructing unauthorized requests at single points, this embodiment extracts the test object based on the real business operation chain. This avoids the problems of incomplete manual analysis of interface call relationships or missing scenario coverage, accurately identifies target interfaces exhibiting abnormal call behavior, significantly reduces the workload of pre-test analysis for unauthorized testing, and lowers testing manpower costs.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer or personal computer, or an electronic device and penetration testing system capable of performing the above functions. The following description uses a penetration testing system as an example to illustrate this embodiment and the subsequent embodiments.

[0026] Example 1 Embodiment 1 of this application provides a penetration testing method based on a large model and a security vulnerability database, referring to... Figure 1 In this embodiment, the penetration testing method based on a large model and a security vulnerability database includes steps S10 to S50: Step S10: Obtain the call execution sequence of each interface to be tested from the replayable action chain, and determine the unauthorized call interface from the interface to be tested based on the call execution sequence and the preset role permission matrix.

[0027] It should be noted that the replayable action chain refers to the actual business operation process data of each user account obtained through recording or import. It records the complete HTTP request chain when different account roles execute specific business tasks in the business system. The call execution sequence is extracted from the replayable action chain and is the ordered call operation data for a specific interface, describing the context data of the specific interface being called in the business scenario.

[0028] For example, the call execution sequence may include the call interface corresponding to each call operation, call request data, response data corresponding to the call request, call operation sequence identifier, data dependency relationship, call operation semantic label, and authentication context of the user account executing the call operation.

[0029] The data dependencies described above indicate how the output fields of the previous call are used as input parameters for the next call. For example, in an e-commerce order scenario, the token returned by the e-commerce website login interface needs to be injected into the Authorization header of all subsequent call requests; the shopping cart ID (Identification) required by the create order interface comes from the return value of the previous call to the add shopping cart interface. The authentication context refers to the authentication credentials used for each call and how they are obtained, including but not limited to: the value of the interface access credentials such as Token or Cookie, the validity period and refresh rules of the interface access credentials, and the injection location of the interface access credentials. The call operation semantic tags are semantic descriptions of the call operations extracted from the large model, such as "user login", "query order", and "submit approval".

[0030] It should also be noted that the role-permission matrix is ​​predefined and used to clarify the access permissions of different account roles in the business system, such as ordinary users and administrators, for various interfaces or resources. This includes the interface access permissions of each test account and the range of response content obtained from calling each interface. Unauthorized interface calls refer to interfaces that are defined in the role-permission matrix as being inaccessible to a specific account role, but are successfully called by that specific account role in the replayable action chain. These unauthorized interface calls are potential targets for privilege escalation vulnerability detection.

[0031] As one possible method for identifying unauthorized API calls, the penetration testing system parses the role-based access control matrix to determine the list of all allowed accounts for each API, resulting in a mapping dictionary of {API ID: [List of Legitimate Accounts]}. For example, API A is allowed by "Administrator" and "Auditor," while API B is only allowed by "Administrator." Next, the penetration testing system parses the replayable action chain to extract the call execution sequence of the API under test. From this sequence, it extracts the API ID and the account that initiated the access request to that API, resulting in a mapping dictionary of {API ID: [List of Actual Calling Accounts]}. This list of actual calling accounts contains all account roles that have actually called the API under test in real business operations. Then, iterate through each interface in the above mapping dictionary {interface identifier: [list of legitimate accounts]}, retrieve the [list of actual calling accounts] corresponding to the current interface in the mapping dictionary {interface identifier: [list of actual calling accounts]}, and then iterate through each account in the [list of actual calling accounts] to check if the account exists in the [list of legitimate accounts] of the current interface. If it does not exist, it means that the account has made an unauthorized call to the current interface, and the current interface is treated as an unauthorized call interface.

[0032] Step S20: Obtain the calling condition information corresponding to the unauthorized calling interface, and determine the parameter placeholder rules corresponding to the unauthorized calling interface based on the calling condition information.

[0033] It should be noted that the API call condition information includes structured information such as the API path, request method, request parameter structure, authentication method, and response format. This information is used to limit the request information required to call the API and can be obtained from the pre-defined API description document. The aforementioned request parameter structure may include basic attributes for each parameter field, such as parameter position, parameter name, parameter type, whether it is required, and business meaning comments, as well as field constraint rules for each parameter field. Parameter placeholder rules refer to the rules for replacing, filling, or modifying the request parameters corresponding to the call request when constructing an unauthorized request. These rules clarify which parameters need to be replaced, the source of the replacement values, the replacement logic (e.g., direct assignment, concatenation, or encryption), and the timing of the replacement.

[0034] For example, the invocation condition information corresponding to the aforementioned unauthorized invocation interface can be input into the large model. Preset prompts guide the large model to output parameter placeholder rules for the unauthorized invocation interface based on the invocation condition information. The aforementioned large model can be a pre-trained general-purpose large model or a large model trained based on the enterprise's own security vulnerability database. For instance, by collecting historical interface description documents and corresponding manually annotated parameter placeholder rules as training data, the open-source large model can be fine-tuned, either fully or partially, to obtain the aforementioned large model.

[0035] Step S30: Input the invocation condition information, the replayable action chain, the role permission matrix, and the test account list into the preset large model, and obtain the test operation sequence and authentication context package corresponding to each test account output by the preset large model.

[0036] It should be noted that the test account list is a pre-defined list of accounts used for this privilege escalation test. Each test account corresponds to a specific account role, such as a regular user or administrator, and includes its identity credentials such as username and password. The test operation sequence refers to a series of calls generated by a pre-defined large model to simulate each test account performing specific business operations in the business system. This includes the privilege escalation API calls to be made by each test account, the corresponding call order, and the call requests. The authentication context package consists of authentication credentials for each test account generated by the pre-defined large model. This includes the session establishment sequence for each test account, API access credentials such as Token, Cookie, and Session ID, API access credential injection rules such as injection location and injection template, and API access credential refresh strategies.

[0037] For example, the invocation condition information, replayable action chain, role permission matrix, and test account list are sent to a preset large model. Preset prompts then instruct the large model to extract or generate the aforementioned test operation sequence and authentication context package from the invocation condition information, replayable action chain, role permission matrix, and test account list.

[0038] Step S40: Construct an unauthorized request based on the authentication context packet corresponding to each test account and the parameter placeholder rules, and perform an unauthorized test on the unauthorized call interface based on the unauthorized request.

[0039] Step S50: Obtain the call response information corresponding to each of the unauthorized requests, and determine the unauthorized test result based on the call response information.

[0040] An unauthorized access request (UART) is an HTTP request constructed based on the authentication context of a test account and according to the parameter placeholder rules of that UART, targeting a specific API call that should not be authorized. The purpose of constructing an UART request is to determine whether the test account can access an API it should not have permission to access, or retrieve data from that API that it should not have permission to retrieve. The response information refers to the response data returned from the UART after the UART request is sent.

[0041] As an alternative approach to performing privilege escalation testing, test accounts can be switched one by one, and privilege escalation requests for all privilege escalation calls to the API can be constructed and sent sequentially for each test account, so as to facilitate step-by-step debugging and result tracking.

[0042] Specifically, the automated detection component of the penetration testing system iterates through each test account in the test account list. For the current test account, it loads its corresponding authentication context package, including the interface access credentials and the injection rules for those credentials. Then, the automated detection component iterates through each unauthorized access interface and loads the parameter placeholder rules for each. Based on the parameter placeholder rules for the current unauthorized access interface, it processes the request parameters corresponding to that interface. For example, based on the request parameter structure of the unauthorized access interface, it determines the target parameter position corresponding to the authentication parameter type and extracts the corresponding interface access credentials from the current test account's authentication context package. According to the injection rules, these credentials are injected into the target parameter position of the request parameters for the unauthorized access interface, constructing an unauthorized request for the current test account. This unauthorized request is then sent to the current unauthorized access interface to perform the unauthorized access test. The system then obtains the call response information returned by the current unauthorized access interface and, based on the access permissions defined in the role-permission matrix for the current test account to the current unauthorized access interface, or the range of response content obtained from accessing the current unauthorized access interface, determines whether the current unauthorized access interface has an unauthorized vulnerability.

[0043] To better understand the optional solutions provided in this embodiment, further explanations of these optional solutions will be given in conjunction with specific application scenarios.

[0044] Assume test account A has the role of a regular user with the identifier userId=1001 and the API access credential token="userA_token_abc123". The injection rule is to include the API access credential in the request header Authorization:Bearer{token}. Assume there is an unauthorized API call with the path "GET / api / admin / users / {userId} / details". Its parameter placeholder rule defines the request header parameter Authorization as the authentication parameter, and its value is extracted from the current test account's authentication context packet and assembled according to the injection rule. The automated detection component extracts the credential token="userA_token_abc123" from the authentication context packet and assembles it according to the injection rule Authorization:Bearer {token}, resulting in the request header: Authorization:Bearer userA_token_abc123, which simulates test account A's identity to initiate the request. Based on the above processing results, an unauthorized request is constructed, and its request line and header can be shown below: Request line: GET / api / admin / users / 1001 / details HTTP / 1.1 Request headers: Host: example.com; Authorization: Bearer userA_token_abc123 If test account A is allowed to access the aforementioned unauthorized API call, the API call should return a successful access status code and the relevant business response content within test account A's access permissions. If test account A is not allowed to access the aforementioned unauthorized API call, the API call should return an access failure status code. Therefore, the existence of an unauthorized vulnerability can be determined based on the actual call response information returned by the unauthorized API call.

[0045] Furthermore, the aforementioned call response information includes a response status code and business response content. The response status code is a standardized numerical status identifier defined by the HTTP protocol, used to characterize the overall communication result and server-side processing status of this network request. Common response status codes include 200 (successful request), 403 (authorization denied), 500 (server error), and 400 (incorrect request parameters), which can quickly distinguish whether network communication is normal and whether the request has been legally received and intercepted by the server. The business response content is the specific data carrier returned by the business system server based on business logic. It is generated based on the interface's preset return format and can take various forms such as JSON structured data, HTML pages, text prompts, and business error descriptions, used to provide feedback on the business processing result of this unauthorized request.

[0046] For example, taking a test scenario of a user accessing another person's order without authorization: after the automated detection component sends an unauthorized request, the business system server returns a 403 response status code, indicating that the server has blocked the unauthorized request at the permission level and refuses to provide the corresponding service; the corresponding business response content is standardized JSON data {"code":"PERMISSION_DENIED","msg":"No permission to access other people's order data","data":null}, which clearly indicates the specific business reason for the failure of this request through structured business data, and fully restores the server response result of the unauthorized request.

[0047] Based on this, the above step S50 includes steps S51 to S52: Step S51: Input the call response information and the role permission matrix into the large model so that the large model can determine whether the unauthorized call interface has an unauthorized vulnerability by using the vulnerability knowledge rules in the security vulnerability database.

[0048] For example, the vulnerability knowledge rules in the security vulnerability database include abnormal response status codes and abnormal business response content corresponding to the determination of unauthorized access vulnerabilities in interfaces under each role's permission dimension. The large model performs matching analysis and verification on the input call response information based on the vulnerability knowledge rules, comparing the actual call response information of this unauthorized request with the access permissions and response content range of the test account to determine whether the current unauthorized call interface contains unauthorized security vulnerabilities such as permission bypass and unauthorized access.

[0049] Specifically, if a test account does not have the access permission to call an API without authorization, but the test account obtains a 200 success status code upon accessing the API, then the API is confirmed to have an authorization vulnerability. Alternatively, if the business response content obtained by the test account from accessing the API exceeds the response content range corresponding to the test account in the role-permission matrix, then the API is confirmed to have an authorization vulnerability.

[0050] Step S52: When the unauthorized call interface has an unauthorized vulnerability, a penetration test report is generated based on the call response information, the unauthorized request corresponding to the call response information, and the test account, to obtain the unauthorized test result.

[0051] For example, for each unauthorized call interface identified as having an unauthorized call vulnerability, the unauthorized request associated with the unauthorized call interface, the corresponding call response information, and the test account are extracted to generate a penetration test report and obtain the unauthorized call test results.

[0052] In other optional solutions for generating privilege escalation test results, the confidence level and judgment conclusions output by the large model in matching and verifying the call response information can be added to the penetration test report, and the privilege escalation test results can be fed back to the security vulnerability database for system iteration. Furthermore, preset prompts can be used to control the large model to generate remediation suggestions based on the privilege escalation test results and send them to the testing personnel, and the relevant data for each test can be recorded as a test log for auditing and traceability.

[0053] In this embodiment, a replayable action chain is used to reconstruct the real business call context. A role-based permission matrix is ​​used to pre-locate potential unauthorized call interfaces, and the corresponding parameter placeholder rules are determined based on the call condition information of the unauthorized call interface. Simultaneously, a test operation sequence and authentication context package are automatically generated based on a large model. Then, unauthorized requests are automatically constructed and unauthorized test is performed based on the aforementioned test operation sequence, authentication context package, and parameter placeholder rules. This is combined with a security vulnerability database to complete intelligent vulnerability assessment, forming a closed-loop, fully automated unauthorized penetration testing system. Compared to traditional methods of manually writing test cases or manually constructing unauthorized requests at single points, this embodiment extracts the test object based on the real business operation chain. This avoids the problems of incomplete manual analysis of interface call relationships or missing scenario coverage, accurately identifies target interfaces with abnormal call behavior, significantly reduces the workload of pre-test analysis, and reduces testing manpower costs.

[0054] Example 2 Based on Embodiment 1 above, the penetration testing method based on a large model and security vulnerability database proposed in Embodiment 2 includes horizontal privilege escalation testing. Horizontal privilege escalation testing refers to simulating the first test account accessing an interface corresponding to a resource instance belonging to a second test account, based on the interface access credentials of the first test account. In other words, horizontal privilege escalation testing refers to testing whether the first test account can access or operate a resource instance owned by a second test account at the same privilege level. The first and second test accounts have the same roles or privilege levels, but each possesses independent, non-shared resource instances. Horizontal privilege escalation highlights cross-identity replay between accounts at the same level based on resource identifiers, parameter anchors, or resource ownership parameters.

[0055] For example, in an online document management system, ordinary user A and ordinary user B are both ordinary users with the same permission level. User A can only view and edit their own documents, let's assume the document ID is 1001; user B can only view and edit their own documents, let's assume the document ID is 2001. The process of testing for horizontal privilege escalation is as follows: Log in to the system using ordinary user A's interface access credential Token_A, construct an unauthorized request, and attempt to access user B's document details interface: GET / api / documents / 2001. Observe the online document management system server response. If it returns the content of document 2001, or the response status code is 200, it indicates that a horizontal privilege escalation vulnerability exists, meaning that user A can access resource instances that do not belong to them.

[0056] Based on this, refer to Figure 2 The steps in step S40 above include steps S41 to S44: Step S41: Obtain the first call request and first call order corresponding to each of the unauthorized call interfaces from the test operation sequence corresponding to the first test account.

[0057] Step S42: According to the parameter placeholder rules corresponding to the unauthorized call interface, replace the resource ownership parameter in the first call request with the resource instance identifier value corresponding to the second test account, wherein the resource ownership parameter is used to indicate the account to which the requested resource instance belongs.

[0058] Resource ownership parameters are parameters in a call request used to indicate which user the accessed resource instance belongs to. For example, the userId parameter in an order query interface or {userId} in the path determines which user's data is returned. Resource instance identifier values ​​are values ​​that uniquely identify a user or its resource instance, such as userId=1002 or orderId=2001.

[0059] For example, the automated detection component iterates through each unauthorized call interface from the test operation sequence of the first test account. For the current unauthorized call interface, it extracts its corresponding first call request and first call sequence, determines the position of the resource ownership parameter in the request parameters corresponding to the call request from the parameter placeholder rules of the unauthorized call interface, and replaces the original value of that parameter position in the first call request, i.e., the resource instance identifier value of the first test account, with the resource instance identifier value of the second test account.

[0060] Step S43: Construct the unauthorized request based on the replaced first call request and the interface access credentials corresponding to the first test account.

[0061] Step S44: Based on the unauthorized request and the first call order, perform the horizontal unauthorized access test on the unauthorized call interface.

[0062] For example, the automated detection component extracts the interface access credentials and their injection rules from the authentication context packet of the first test account. The interface access credentials are then injected into the corresponding location in the replaced first call request, such as the Authorization field in the request header, according to the injection rules, to construct an unauthorized request. Based on the first call order, the constructed unauthorized request is sent to the corresponding unauthorized call interface.

[0063] This embodiment, based on the general automated privilege escalation penetration testing solution in Embodiment 1, specifically implements horizontal privilege escalation testing logic. It focuses on detecting security risks associated with users accessing private resources across different roles with the same privilege level. Leveraging the core capabilities of the existing replayable action chain, role-permission matrix, large model, and security vulnerability database, and based on the business call sequence of the same-level permission test account, it locates the exclusive resource ownership parameter in the interface used to bind resource ownership. By automatically replacing the resource instance identifier values ​​of different same-level users, while preserving the original account authentication credentials and normal call order, it batch constructs horizontal privilege escalation test requests. This simulates real attack scenarios where same-level users access others' private resources without authorization, avoiding the inefficiency of manually modifying parameters and constructing test requests in traditional testing, thus achieving the technical effect of reducing testing manpower costs.

[0064] Example 3 Based on Embodiments 1 and 2 above, the penetration testing method based on a large model and security vulnerability database proposed in Embodiment 3 further includes vertical privilege escalation testing. Vertical privilege escalation testing involves simulating the first test account's interface access credentials to call an interface that is only accessible to a third test account with higher privileges than the first test account in the role-permission matrix. In vertical privilege escalation testing, the tester uses the interface access credentials of a low-privilege account to call an interface explicitly marked as only accessible to high-privilege roles in the role-permission matrix. Whether the business system server allows access is observed to determine if there are any missing permission checks. Vertical privilege escalation highlights the use of low-privilege account credentials to call high-privilege interfaces or execute high-privilege account operation sequences.

[0065] Based on this, refer to Figure 3 The above step S40 also includes steps S45 to S47: Step S45: Obtain the third call request and third call order corresponding to each of the unauthorized call interfaces from the test operation sequence corresponding to the third test account.

[0066] Step S46: Construct the unauthorized access request based on the interface access credentials corresponding to the first test account and the third call request.

[0067] Step S47: Based on the unauthorized request and the third call order, perform the vertical unauthorized access test on the unauthorized call interface.

[0068] For example, from the test operation sequence of the third test account, each unauthorized call interface is traversed. For the current unauthorized call interface, its corresponding third call request and third call order are extracted. Interface access credentials and their injection rules are extracted from the authentication context packet of the first test account. The original interface access credentials in the third call request are removed entirely, and then, according to the injection rules of the first test account, the interface access credentials of the first test account are injected into the corresponding position of the third call request, such as replacing the value of the Authorization header, to obtain the unauthorized request. According to the third call order, the constructed unauthorized request is sent to the corresponding unauthorized call interface to execute the vertical unauthorized test.

[0069] To better understand the solution presented in this example, we will further explain this example in conjunction with specific application scenarios.

[0070] Assume the first test account is a regular user account with the API access credential `token="A_token_abc"`. The injection rule is to include the API access credential in the request header `Authorization: Bearer {token}`. The third test account is an administrator account, and its test operation sequence includes an API that can only be called by the administrator: `DELETE / api / orders / {orderId}`. The corresponding third call request is: `DELETE / api / orders / 5001 HTTP / 1.1; Host:example.com; Authorization: Bearer admin_token_xyz; Content-Type: application / json`. This third call request is used to delete order 5001. Extract the original request for the `DELETE / api / orders / 5001` API from the third test account's test operation sequence; this is the aforementioned third call request. Remove the authentication-related part of the third call request, specifically `Authorization: Bearer admin_token_xyz` in this example. Extract the interface access credential token="A_token_abc" from the authentication context packet of the first test account, and construct a new request header according to its injection rules: Authorization: Bearer A_token_abc, while keeping other request content unchanged, thus obtaining an unauthorized request.

[0071] This third embodiment, based on the overall automated privilege escalation penetration testing framework of embodiments one and two, adds a vertical automated detection capability for privilege escalation. It constructs standardized testing logic for security vulnerability scenarios where low-privilege accounts illegally call high-privilege exclusive interfaces. Based on a preset role permission matrix, it accurately distinguishes the interface access boundaries of high-privilege and low-privilege roles. It reuses the standard call request and call order of the high-privilege account obtained by replayable action chain parsing, and only replaces it with the interface access credentials of the first low-privilege test account to complete the construction of the privilege escalation request. Under the premise of completely retaining the real call parameters, business scenarios and request logic of the high-privilege interface, it reproduces the attack behavior of low-privilege users attempting to call high-level interfaces without authorization, reducing manual intervention in testing.

[0072] Example 4 Based on the above embodiments, referring to Figure 4 In the penetration testing method based on a large model and a security vulnerability database proposed in Embodiment 4, before the step of performing an unauthorized access test on the unauthorized call interface based on the unauthorized request, steps S60 to S90 are further included: Step S60: Based on each test account in the test account list, send a login request to the login interface in the interface to be tested, and obtain the session credentials returned by the business system server from the login response.

[0073] The login interface is used for user authentication in the business system, typically via the path POST / api / login. The login interface receives the interface access credentials from the call request and returns a session credential. The session credential is a unique credential returned by the business system server after a successful user login, used to identify the user's session. It includes a SessionID stored in a cookie and a Token stored in the response body or header. Subsequent calls must carry this session credential to maintain the login status.

[0074] For example, iterate through each test account in the test account list. For the current test account, construct a login request based on the login interface call conditions information in the interface description document and send it to the login interface to obtain the session credentials returned by the login interface. If the session credentials are returned in the form of a cookie, parse the SessionID from the Set-Cookie header of the response; if the session credentials are returned in the form of a token, extract them from a specified field in the response body, such as data.token.

[0075] Step S70: After successful login, maintain the session idle state until the maximum idle time of the session is exceeded, and then send a timeout access request to the resource interface corresponding to the login interface based on the session credentials to obtain the timeout access response information corresponding to the timeout access request.

[0076] The maximum idle time for a session is the session timeout threshold configured on the business system server; that is, the length of time after which a session will automatically expire if a user remains inactive for a specified period. Resource interfaces refer to business interfaces that require login to access, such as order inquiries and personal information viewing.

[0077] For example, after successful login, a timer is started. The timer's waiting duration is equal to the maximum idle time of the session. Once the timer is triggered, a resource interface corresponding to the login interface is selected from the interface description document, such as the order query interface in an e-commerce webpage. Based on the calling conditions of this resource interface and the previously obtained session credentials, the session credentials are added to the request according to its injection rules. A timeout access request is then constructed and sent to the resource interface, and the timeout access response information returned by the resource interface is collected. The timeout access response information includes the response status code and business response content returned by the business system server to the timeout access request.

[0078] Step S80: Input the timeout access response information into the large model so that the large model can determine whether the resource interface has a session timeout vulnerability by using vulnerability knowledge rules in the security vulnerability database.

[0079] The collected timeout access response information, along with relevant contextual data such as test account information, resource interface paths, and maximum session idle time, are input into the large model. The large model then compares the actual timeout access response information with pre-defined abnormal response status codes and abnormal business response content corresponding to session timeout vulnerabilities in the security vulnerability database to determine whether a session timeout vulnerability exists in the resource interface. For example, "If the business system server returns a 200 status code and normal business data after a session timeout, then a session timeout vulnerability exists"; "If a 401 status code is returned or the user is redirected to the login page, then no session timeout vulnerability exists," etc. The model analyzes the timeout access response information and outputs a conclusion and confidence level regarding the existence of a session timeout vulnerability.

[0080] Step S90: When it is determined that the resource interface does not have a session timeout vulnerability, perform the step of performing an unauthorized test on the unauthorized call interface based on the unauthorized request.

[0081] After determining that the resource interface does not have a session timeout vulnerability, the next step is to perform an unauthorized access test on the unauthorized call interface based on the unauthorized request. This ensures that the corresponding authentication context remains valid and available throughout the entire process of replaying the unauthorized request, preventing the authentication context packet from becoming invalid due to session timeout or premature session expiration, thus ensuring the validity of the unauthorized access test results.

[0082] In other embodiments, the above-mentioned session timeout vulnerability detection may also be performed multiple times during the execution of privilege escalation testing to verify the validity of each session.

[0083] This fourth embodiment, based on the aforementioned privilege escalation penetration testing system, adds an automated detection process for session timeout vulnerabilities. Each test account completes system login authentication and captures session credentials. It simulates the maximum idle time of a session preset by the server to simulate a real user's long period of inactivity. After the session naturally times out, it re-accesses the business resource interface protected by the login state with the expired session credentials, collecting complete timeout access response information under the timeout scenario. Finally, through a large model combined with the session timeout vulnerability knowledge rules built into the security vulnerability library, it intelligently analyzes the interface response status code and business response content after the timeout, automatically identifying session security vulnerabilities such as server-side session expiration verification failure, failure to destroy timed-out sessions in a timely manner, and the ability to access business resources normally with expired credentials. This reduces manual intervention in testing and saves testing manpower costs.

[0084] Example 5 Based on the above embodiments, referring to Figure 5 In the penetration testing method based on a large model and security vulnerability database proposed in this embodiment five, after step S60, steps S100 to S140 are also included: Step S100: Send an access request to the resource interface corresponding to the login interface based on the session credentials.

[0085] Step S110: After successful access, call the cancellation interface to initiate a cancellation request for the test account, and perform the test account cancellation operation.

[0086] The logout interface refers to the interface in the business system used to actively log out of the current account login status and invalidate the session credentials. After calling the logout interface, the business system server will clear the login information of the current session, making the session credentials no longer valid.

[0087] For example, select a resource interface from the interface description document that requires login to access. Based on the call conditions of the resource interface and the aforementioned session credentials, construct an access request and send it to the resource interface. If the resource interface returns a success code 200, the access is confirmed to be successful. Based on the call conditions of the logout interface in the interface description document, construct a logout request, inject the currently valid session credentials into the logout request, send the logout request to the logout interface, and obtain the response status code returned by the logout interface. If the response status code is a success code 200, it is confirmed that the business system server has received the logout request and cleared the login information of the test account.

[0088] Step S120: After successfully performing the test account cancellation operation, access the resource interface again based on the session credentials to obtain the access response information after cancellation.

[0089] Step S130: Input the post-logout access response information into the large model so that the large model can determine whether the resource interface has a logout failure vulnerability by using vulnerability knowledge rules in the security vulnerability database.

[0090] The post-logout access response information refers to the response data returned by the business system server when accessing the resource interface again using expired session credentials after a successful logout operation. This response includes the response status code and the business response content.

[0091] For example, using the same session credentials as in step S100—that is, session credentials that have been logged out—an access request is reconstructed and sent to the same resource interface. The access response information returned by the resource interface after logging out is collected. The access response information after logging out, along with relevant context such as test account information, resource interface path, and session credentials, is input into the large model. The large model combines session timeout vulnerability knowledge rules from the security vulnerability database, such as "If a user logs out and accesses the resource interface using the original session credentials, and the interface returns a 200 status code containing normal business data, then there is a logout failure vulnerability"; "If a 401 status code, a 403 status code, or a redirect to the login page is returned, then the login status has been correctly cleared, and there is no vulnerability," etc., to analyze the current access response information after logging out and output a conclusion and confidence level regarding the existence of a logout failure vulnerability.

[0092] Step S140: When it is determined that the resource interface does not have a cancellation failure vulnerability, the step of performing an unauthorized test on the unauthorized call interface based on the unauthorized request is executed.

[0093] The account cancellation failure vulnerability manifests as the original session identifier not being destroyed by the server after the account cancellation operation, allowing old credentials to still access the interface normally. Pre-confirmation that the cancellation operation can properly destroy the session and that the session lifecycle flows in accordance with design specifications ensures that all subsequent unauthorized requests are established on a compliant and valid authentication context. The response behavior of unauthorized requests is determined solely by the interface's own permission verification mechanism, eliminating ambiguity caused by abnormal session cancellation and improving the accuracy of unauthorized vulnerability identification. Simultaneously, it avoids the test environment disorder caused by abnormal sessions, improving the stability and operational efficiency of the automated penetration testing process.

[0094] This fifth embodiment, building upon the aforementioned unauthorized access detection and session timeout detection, adds an automated detection mechanism for logout failure vulnerabilities. Using valid session credentials obtained after logging in with a test account, it first accesses the resource interface normally to confirm session validity, then calls the system's logout interface to actively destroy the current login session. Finally, it uses the expired session credentials to access the resource interface again, collecting the interface response information after logout. By matching the security vulnerability database rules with a large model, it intelligently determines whether the system has logout failure vulnerabilities such as incomplete logout status cleanup and reusable expired sessions. This eliminates the need for testers to manually perform login, logout, and secondary access steps, and eliminates the need for manual vulnerability assessment, reducing manual intervention and saving time and manpower costs associated with manual testing.

[0095] Example 6 Based on the above embodiments, referring to Figure 6 In the penetration testing method based on a large model and security vulnerability database proposed in Embodiment Six, after step S100, steps S150 to S180 are also included: Step S150: Obtain the request parameters corresponding to the access request, and delete the anti-cross-site token in the request parameters to construct a fake cross-site request.

[0096] A cross-site request (CSRF) token, also known as a cross-site request forgery token, is a security mechanism generated by the business system server and embedded in a page or request. It is used to verify whether a request originates from a legitimate user session, preventing CSRF attacks. It is typically a random string that changes with each request or session. CSRF tokens usually appear as a parameter in the request body or request header.

[0097] For example, the access request in step S100 is parsed, and its request parameters are extracted to find parameters whose names contain keywords such as "csrf", "token" and "nonce", or the anti-cross-site token field name marked in the calling condition information in the interface document is identified. The identified anti-cross-site token is deleted from the request parameters, while the remaining parameters remain unchanged, thus obtaining a pseudo cross-site request.

[0098] Step S160: Determine a preset sensitive business interface from the interfaces to be tested, and in a browser environment where the test account is logged in, send the pseudo cross-site request to the preset sensitive business interface and obtain the interface response information corresponding to the pseudo cross-site request.

[0099] Step S170: Input the interface response information into the large model so that the large model can determine whether the preset sensitive business interface has a cross-site request forgery vulnerability by using vulnerability knowledge rules in the security vulnerability database.

[0100] For example, the automated detection component opens a browser instance, logs into the system using the username and password of the test account, and obtains and maintains the browser's login session. Then, within the same browser session, the pseudo cross-site request (XPS) constructed above is sent to a preset sensitive business interface, and the interface response information returned by the preset sensitive business interface is obtained. Afterwards, the interface response information, along with relevant context such as the path of the preset sensitive business interface and the test account information, and the request parameters of the pseudo XPS, are input into the large model. The large model combines session timeout vulnerability knowledge rules from the security vulnerability database, such as "if the sensitive business interface successfully executes business operations without a valid anti-XPS token, such as returning a 200 status code and changing business data, then there is a cross-site request forgery vulnerability"; "if a 403 status code, a 400 status code, or an invalid token is returned, then there is no cross-site request forgery vulnerability," etc., to analyze the current interface response information and output a conclusion and confidence level regarding the existence of a cross-site request forgery vulnerability.

[0101] Step S180: When it is determined that the resource interface does not have a cross-site request forgery vulnerability, the step of performing an unauthorized test on the unauthorized call interface based on the unauthorized request is executed.

[0102] Cross-site request forgery (XPS) vulnerabilities essentially stem from the lack of cross-site token and source header verification mechanisms at the interface. They can exploit the browser's automatic use of session cookies to abnormally complete request calls. By verifying the effectiveness of the interface's cross-site protection mechanisms beforehand, and confirming the absence of XPS vulnerabilities, it can be determined that interface access is solely controlled by internal permission verification rules. The subsequent response to unauthorized requests will accurately reflect any flaws in the unauthorized access verification logic, preventing interference between different types of permission vulnerabilities and improving the accuracy of unauthorized access vulnerability identification. Furthermore, by isolating two types of permission security checks step-by-step, the cross-site security anomaly scenario prevents contamination of the unauthorized access testing baseline environment. This facilitates subsequent large-scale model-based individual attribution and classification of various vulnerabilities, simplifies the test evidence processing process, and enhances the rigor and reliability of the automated penetration testing process.

[0103] This sixth embodiment, building upon the aforementioned multi-dimensional interface security detection system, adds an automated detection process for cross-site request forgery (CSP) vulnerabilities. Based on normal, valid business access requests, it automatically identifies and removes anti-CSP tokens from request parameters, constructs fake CSP requests without valid verification credentials, maintains a legitimate user login session within the browser environment, and initiates fake requests to preset sensitive business interfaces, collecting corresponding interface response information. Finally, a large-scale model, combined with standardized knowledge rules from a security vulnerability database, intelligently assesses whether the interface can perform business operations normally when anti-CSP token verification is missing, accurately identifying CSP vulnerabilities. This eliminates the need for testers to manually construct fake requests, set up browser test environments, and manually verify results, significantly reducing manual steps and effectively saving on testing costs.

[0104] Example 7 Based on the above embodiments, the overall process of the penetration testing method based on a large model and a security vulnerability database proposed in Embodiment Six can be as follows: Dual-drive unified input modeling: Semantic parsing of interface description documents to obtain the calling condition information corresponding to each interface; extraction of replayable action chains and alignment with the calling condition information corresponding to the interface to be tested, outputting a list of measurable interface objects with detection type labels and risk scores.

[0105] Testing task orchestration and execution: Based on the list of testable interface objects, sub-tasks are split according to testing type. The automated testing component is scheduled to build and send testing requests to the target interfaces in the list of testable interface objects, collect the testing requests and the corresponding response data, and obtain test data.

[0106] The system employs a dual-engine approach of rule matching and large language model verification for collaborative analysis: test data is matched against vulnerability knowledge rules in a pre-built security vulnerability database to obtain rule matching confidence. Test data that reaches a preset high confidence threshold directly outputs vulnerability conclusions. For test data that falls within a preset medium confidence range or does not match any vulnerability knowledge rules, large language model verification or exploratory verification is triggered. The large language model outputs the analysis conclusion and model confidence, and the rule matching confidence and model confidence are fused using preset weights to obtain the final test result.

[0107] Evidence consolidation and report generation: Based on the final test results, a detection evidence package is constructed, which includes the original detection request and the response data corresponding to the detection request, as well as the dual-engine collaborative analysis record, and a standardized penetration test report is generated according to the preset template.

[0108] Reference Figure 7 , Figure 7 A schematic diagram of the overall process of penetration testing methods based on large models and security vulnerability databases is given, specifically: The process begins with a dual-drive input phase, acquiring raw data through two methods: parsing interface description documents and collecting replayable action chains from recorded operations. This is followed by a unified modeling phase, where the two types of raw data are merged to form a standardized internal data model. Based on this, an interface-object-scenario-action mapping is executed to establish multi-dimensional relationships between interfaces, business objects (account roles), business scenarios, and specific call actions. Next, the task orchestration engine automatically generates specific test operation sequences based on the interface-object-scenario-action mapping, and the automated detection component simulates and executes these sequences, interacting with the target business system. The test response results are sent to the collaborative analysis module, where a comprehensive judgment is made using the semantic analysis capabilities of the large model and a pre-built security vulnerability database. After the judgment is completed, the process moves to the evidence visualization and false positive suppression phase. The analysis results are formatted and displayed to extract evidence, while false positive filtering is performed simultaneously. If further verification is required, the process reverts to the automated detection component's test phase for iterative verification. Once confirmed, the final penetration test report is automatically generated. Finally, the report results and newly discovered vulnerability characteristics are fed back into the penetration testing system to update the security vulnerability database and rules, driving the continuous optimization of subsequent testing strategies.

[0109] Reference Figure 8 , Figure 8 A flowchart illustrating the orchestration and execution of detection tasks is provided. Specifically: First, a list of testable interface objects and detection type strategy configurations are obtained. Task subsets are then split according to detection type and risk priority. Target automated detection components are selected based on the mapping relationship between detection types and the capability types of automated detection components. Next, it is determined whether the current detection type requires a multi-identity authentication context. If so, the large model generates authentication contexts for test accounts to perform multi-identity switching tests based on these contexts. If not, the configured session credentials are reused to execute the test. After obtaining authentication information, the target automated detection component is concurrently / serially scheduled to execute the test and collect response data. After the test is executed, the test results are verified to determine whether the test failed or the component is unavailable. If the test fails or the component is unavailable, a fault tolerance mechanism is triggered, performing exponential backoff retry or switching to a backup component, and returning to the test execution phase. If the test is completed normally, the collected response data is output to the dual-engine collaborative analysis, entering the subsequent in-depth analysis stage.

[0110] Furthermore, in the above-mentioned task scheduling and execution steps, the detection types may include unauthorized access testing, timeout access testing, post-logout access testing, and pseudo cross-site request testing.

[0111] When the detection type is an unauthorized test, the steps S30~S40 described in Embodiments 1 to 3 above are executed to "schedule the automated detection component to construct and send a detection request to the target interface in the list of testable interface objects, collect the detection request and the response data corresponding to the detection request, and obtain the test data".

[0112] When the detection type is timeout access test, the steps of “scheduling the automated detection component to construct and send a detection request to the target interface in the list of testable interface objects, collecting the detection request and the response data corresponding to the detection request, and obtaining the test data” are executed based on steps S60~S70 described in the above embodiment four.

[0113] When the detection type is post-logout access test, the steps of “scheduling the automated detection component to construct and send a detection request to the target interface in the list of testable interface objects, collecting the detection request and the response data corresponding to the detection request, and obtaining the test data” are executed based on the steps S100~S130 described in the above embodiment five.

[0114] When the detection type is a pseudo cross-site request test, the steps of “scheduling the automated detection component to construct and send a detection request to the target interface in the list of testable interface objects, collecting the detection request and the response data corresponding to the detection request, and obtaining the test data” are executed based on the steps S150~S170 described in the above embodiment six.

[0115] Other alternative solutions may include the following detection types: Middleware version information leakage detection: The automated detection component is responsible for collecting the service fingerprint, response header, and banner information of the interface under test, and comparing it with the pre-defined known version-vulnerability mapping rules in the security vulnerability database to identify the risk of version information leakage. The large model is used to perform auxiliary normalization processing on unstructured error information or hybrid stack fingerprints to improve the identification accuracy.

[0116] Weak password detection: The automated detection component performs login attempts using dictionary or combination methods based on preset policy templates, and records the response result of each attempt. The large model can generate a variant dictionary within compliance limits based on password policy hints from the business system to expand test coverage.

[0117] Weak password detection: The automated detection component executes login attempts using dictionary or combination methods based on preset policy templates, and records the response result of each attempt. The large model can generate variant dictionaries within compliance limits based on password policy hints from the business system to expand test coverage. The brute-force intensity and account scope must be manually approved before task orchestration, and a circuit breaker mechanism must be configured to prevent impact on the target system.

[0118] Username enumeration test: The automated detection component submits differentiated usernames in batches and collects the differences in response information corresponding to each request. The large model judges the validity of the enumeration results based on response semantics, such as prompts, response latency, and status code combinations.

[0119] Login page brute-force test: The automated detection component performs login attempts within the frequency and account range approved by manual intervention. The large model does not participate in sending high-frequency requests; it is only used to interpret the response results of the locking strategy and CAPTCHA-linked strategy. A traffic interception mechanism and alarm rules must be configured before testing.

[0120] SMS bomb vulnerability testing: An automated detection component performs repeated and concurrent calls to the SMS delivery interface. A large model assists in identifying patterns where rate limiting at the business layer is lacking.

[0121] CAPTCHA testing: The automated detection component collects CAPTCHA data from the API and its verification process. Large-scale model analysis identifies bypassable paths, such as fixed CAPTCHAs, predictable CAPTCHAs, and unbound sessions.

[0122] Authentication error message: The automated detection component triggers an erroneous login and matches it against "username / password enumeration hint" rules in the vulnerability database. The large model performs a semantic determination on whether the message reveals the existence of the account. Finally, manual verification is required to determine whether it falls under the category of information leakage defects.

[0123] Lockout policy testing: The automated detection component triggers failed login attempts within a controllable number of attempts and observes the locking and unlocking behaviors. Lockout thresholds and account recovery strategies are manually set to expected values. A large model is used to demonstrate consistency between response text and status code combinations.

[0124] Authentication bypass testing: The rule base performs initial screening for common bypass features. The large model generates unconventional parameters, headers, and path variations to explore scenarios where rules are not hit. High-risk bypass links must be manually reviewed and confirmed.

[0125] Arbitrary file upload test: The automated detection component sends multiple types of samples based on MIME (Multipurpose Internet Mail Extensions) type, extension, and content characteristics, and parses the responses. Large models generate bypass payload variants. WebShell deployment verification is only performed in isolated environments with manual authorization.

[0126] Cross-Site Scripting (XSS) Attack Testing: The automated detection component works in conjunction with vulnerability database rules to perform reflected and stored XSS attack detection. A large-scale model generates context-sensitive encoding to bypass the payload and interprets the response.

[0127] File upload bypass testing: The automated detection component executes templated test cases such as double extensions, null bytes, and Content-Type tampering. The large model dynamically combines bypass sequences based on filtering logic.

[0128] Unauthorized file download test: An automated detection component replays unauthorized access attempts to file or object storage interfaces. A large model determines whether the response body contains sensitive file characteristics. The path dictionary can be derived from the interface documentation parsing results.

[0129] Decrypted login request test: The automated detection component captures whether TLS (Transport Layer Security) is enabled throughout the login process, and whether plaintext transmission or protocol degradation occurs. The large model provides supplementary explanations for situations such as mixed content and missing HSTS (HTTP Strict Transport Security).

[0130] Sensitive information disclosure testing: Vulnerability database rules are used to match features such as keys, tokens, and personally identifiable information in the response. A large model performs semantic-level sensitive field identification on unstructured logs or JSON data. Anonymization rules for classified samples are manually configured.

[0131] Structured Query Language (SCL) injection testing: Automated injection verification components perform multi-path probing, including error-based injection, Boolean injection, and delayed injection. Vulnerability database rules handle initial screening, while a large model handles dynamic verification and fusion judgment, ultimately outputting detection conclusions with confidence levels.

[0132] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the penetration testing method based on the large model and security vulnerability database of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0133] This application provides a penetration testing device based on a large model and a security vulnerability database. The penetration testing device based on a large model and a security vulnerability database includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the penetration testing method based on the large model and security vulnerability database in the above embodiment 1.

[0134] The following is for reference. Figure 9This diagram illustrates a structural schematic of a penetration testing device based on a large model and a security vulnerability database, suitable for implementing embodiments of this application. The penetration testing device based on a large model and a security vulnerability database in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, and tablets (PADs), as well as fixed terminals such as desktop computers. Figure 9 The penetration testing device based on a large model and security vulnerability database shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0135] like Figure 9 As shown, a penetration testing device based on a large model and security vulnerability database may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the penetration testing device based on the large model and security vulnerability database. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the penetration testing equipment based on large models and security vulnerability databases to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a penetration testing equipment based on large models and security vulnerability databases with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

[0136] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0137] The penetration testing device based on a large model and a security vulnerability database provided in this application, employing the penetration testing method based on a large model and a security vulnerability database as described in the above embodiments, can solve the technical problem of how to reduce manual intervention in penetration testing to lower labor costs. Compared with the prior art, the beneficial effects of the penetration testing device based on a large model and a security vulnerability database provided in this application are the same as those of the penetration testing method based on a large model and a security vulnerability database provided in the above embodiments, and other technical features in this penetration testing device based on a large model and a security vulnerability database are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0138] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0139] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0140] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the penetration testing method based on a large model and a security vulnerability database in the above embodiments.

[0141] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0142] The aforementioned computer-readable storage medium may be included in a penetration testing device based on a large model and a security vulnerability database; or it may exist independently and not be assembled into a penetration testing device based on a large model and a security vulnerability database.

[0143] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a penetration testing device based on a large model and security vulnerability database, enable the penetration testing device to write computer program code for performing the operations of this application in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, or as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., using an internet connection provided by an internet service).

[0144] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0145] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0146] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned penetration testing method based on a large model and a security vulnerability database. This addresses the technical problem of reducing human intervention in penetration testing to lower labor costs. Compared to existing technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the penetration testing method based on a large model and a security vulnerability database provided in the above embodiments, and will not be repeated here.

[0147] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the penetration testing method based on a large model and a security vulnerability database as described above.

[0148] The computer program product provided in this application solves the technical problem of how to reduce human intervention in penetration testing to lower labor costs. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the penetration testing method based on a large model and security vulnerability database provided in the above embodiments, and will not be repeated here.

[0149] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A penetration testing method based on a large model and a security vulnerability database, characterized in that, The penetration testing method based on large models and security vulnerability databases includes: Obtain the call execution sequence of each interface under test from the replayable action chain, and determine the unauthorized call interface from the interface under test based on the call execution sequence and the preset role permission matrix; Obtain the calling condition information corresponding to the unauthorized calling interface, and determine the parameter placeholder rules corresponding to the unauthorized calling interface based on the calling condition information; Input the invocation condition information, the replayable action chain, the role permission matrix and the test account list into the preset large model, and obtain the test operation sequence and authentication context package corresponding to each test account output by the preset large model; An unauthorized request is constructed based on the authentication context packet corresponding to each test account and the parameter placeholder rules, and an unauthorized test is performed on the unauthorized call interface based on the unauthorized request. Obtain the call response information corresponding to each of the above unauthorized requests, and determine the unauthorized test result based on the call response information.

2. The penetration testing method based on a large model and security vulnerability database as described in claim 1, characterized in that, The test operation sequence includes the call request and call order corresponding to each of the unauthorized call interfaces, the authentication context package includes the interface access credentials of each of the test accounts, and the unauthorized test includes horizontal unauthorized test and vertical unauthorized test; The horizontal privilege escalation test refers to simulating the first test account accessing the interface corresponding to the resource instance belonging to the second test account based on the interface access credentials of the first test account. The vertical privilege escalation test refers to simulating the first test account calling an interface that is only allowed to be accessed by a third test account with higher privileges than the first test account in the role permission matrix, based on the interface access credentials of the first test account.

3. The penetration testing method based on a large model and security vulnerability database as described in claim 2, characterized in that, The step of constructing an unauthorized request based on the authentication context packet corresponding to each test account and the parameter placeholder rules, and performing an unauthorized test on the unauthorized call interface based on the unauthorized request, includes: From the test operation sequence corresponding to the first test account, obtain the first call request and the first call order corresponding to each of the unauthorized call interfaces; According to the parameter placeholder rules corresponding to the unauthorized call interface, the resource ownership parameter in the first call request is replaced with the resource instance identifier value corresponding to the second test account, wherein the resource ownership parameter is used to indicate the account to which the requested resource instance belongs; The unauthorized request is constructed based on the replaced first call request and the interface access credentials corresponding to the first test account; Based on the unauthorized request and the first call order, the horizontal unauthorized access test is performed on the unauthorized call interface.

4. The penetration testing method based on a large model and security vulnerability database as described in claim 2 or 3, characterized in that, The step of constructing an unauthorized request based on the authentication context packet corresponding to each test account and the parameter placeholder rules, and performing an unauthorized test on the unauthorized call interface based on the unauthorized request, further includes: From the test operation sequence corresponding to the third test account, obtain the third call request and the third call order corresponding to each of the unauthorized call interfaces; The unauthorized request is constructed based on the interface access credentials corresponding to the first test account and the third call request; Based on the unauthorized request and the third call order, the vertical unauthorized test is performed on the unauthorized call interface.

5. The penetration testing method based on a large model and security vulnerability database as described in claim 1, characterized in that, The call response information includes a response status code and a business response content. The step of determining the unauthorized access test result based on the call response information includes: The call response information and the role permission matrix are input into the large model so that the large model can determine whether the unauthorized call interface has an unauthorized vulnerability by using the vulnerability knowledge rules in the security vulnerability database. When the unauthorized call interface has an unauthorized vulnerability, a penetration test report is generated based on the call response information, the unauthorized request corresponding to the call response information, and the test account, and the unauthorized test result is obtained.

6. The penetration testing method based on a large model and security vulnerability database as described in claim 1, characterized in that, Before the step of performing an unauthorized access test on the unauthorized call interface based on the unauthorized request, the method further includes: Based on each test account in the test account list, a login request is sent to the login interface in the interface to be tested, and the session credentials returned by the business system server are obtained from the login response; After successful login, the session remains idle until the maximum idle time of the session is exceeded. Then, based on the session credentials, a timeout access request is sent to the resource interface corresponding to the login interface to obtain the timeout access response information corresponding to the timeout access request. The timeout access response information is input into the large model so that the large model can determine whether the resource interface has a session timeout vulnerability by using the vulnerability knowledge rules in the security vulnerability database. When it is determined that the resource interface does not have a session timeout vulnerability, the step of performing an unauthorized test on the unauthorized call interface based on the unauthorized request is executed.

7. The penetration testing method based on a large model and security vulnerability database as described in claim 6, characterized in that, After the step of sending a login request to the login interface of the interface under test based on each of the test accounts in the test account list, and obtaining the session credentials returned by the business system server from the login response, the method further includes: Based on the session credentials, an access request is sent to the resource interface corresponding to the login interface; After successful access, the cancellation interface is called to initiate a cancellation request for the test account in order to perform the test account cancellation operation; After successfully performing the test account cancellation operation, the resource interface is accessed again based on the session credentials to obtain the access response information after cancellation. The post-logout access response information is input into the large model so that the large model can determine whether the resource interface has a logout failure vulnerability by using the vulnerability knowledge rules in the security vulnerability database. When it is determined that the resource interface does not have a cancellation failure vulnerability, the step of performing an unauthorized test on the unauthorized call interface based on the unauthorized request is executed.

8. The penetration testing method based on a large model and security vulnerability database as described in claim 7, characterized in that, After the step of sending an access request to the resource interface corresponding to the login interface based on the session credentials, the method further includes: Obtain the request parameters corresponding to the access request, and delete the anti-cross-site token in the request parameters to construct a fake cross-site request; Determine a preset sensitive business interface from the interfaces to be tested, and in a browser environment where the test account is logged in, send the pseudo cross-site request to the preset sensitive business interface and obtain the interface response information corresponding to the pseudo cross-site request. The interface response information is input into the large model so that the large model can determine whether the preset sensitive business interface has a cross-site request forgery vulnerability by using the vulnerability knowledge rules in the security vulnerability database. When it is determined that the resource interface does not have a cross-site request forgery vulnerability, the step of performing an unauthorized test on the unauthorized call interface based on the unauthorized request is executed.

Images