Permission vulnerability detection method and device, equipment and medium

Abstract

The invention discloses a permission vulnerability detection method and device, equipment and a medium. The method comprises the following steps: acquiring a permission request received by an application system; acquiring permission configuration information; the permission configuration information comprises login information of a plurality of simulation users, and permissions of the simulation users are different; performing permission test on the permission request according to the permission configuration information to obtain a response result and a test result of the permission request; the response result comprises a response message of each simulation user; the response result of the permission request is input into a large language model for test result verification, and a verification result of the permission request is obtained; and determining a permission vulnerability detection result of the permission request according to a test result of the permission request and a verification result of the permission request. According to the embodiment of the invention, the accuracy of permission test results can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of vulnerability testing, and in particular to a permission vulnerability detection method, device, equipment and medium. Background Art

[0002] Existing technologies for detecting permission vulnerabilities primarily rely on rule-based matching and manual auditing. Static analysis of code logic and permission controls is performed using pre-set security rules and pattern matching techniques. Manual penetration testing is also used to identify potential unauthorized operations. Manual logins are performed, and tools are used to manipulate request messages. User credentials are then replaced to detect unauthorized vulnerabilities.

[0003] The aforementioned implementations fail to fully cover unknown vulnerabilities and unauthorized paths in complex scenarios, limiting detection efficiency and accuracy, especially in the face of increasingly complex software architectures and dynamically changing permission management mechanisms. Furthermore, the heavy reliance on expert experience and manual operations results in a time-consuming and costly detection process. It also hinders automated security verification within continuous integration and rapid iteration, hindering early vulnerability discovery and remediation within the software development lifecycle. Summary of the Invention

[0004] The present invention provides a permission vulnerability detection method, device, equipment and medium, which can improve the accuracy of permission test results.

[0005] According to one aspect of the present invention, an embodiment of the present invention provides a method for detecting a permission vulnerability, the method comprising:

[0006] Get the permission request received by the application system;

[0007] Obtaining permission configuration information; the permission configuration information includes login information of multiple simulated users, each of which has different permissions;

[0008] Performing a permission test on the permission request according to the permission configuration information to obtain a response result and a test result of the permission request; the response result includes a response message of each simulated user;

[0009] Inputting the response result of the permission request into the large language model for test result verification to obtain the verification result of the permission request;

[0010] Determine a permission vulnerability detection result of the permission request based on the test result of the permission request and the verification result of the permission request.

[0011] According to another aspect of the present invention, an embodiment of the present invention further provides a permission vulnerability detection device, the device comprising:

[0012] The request acquisition module is used to obtain the permission request received by the application system;

[0013] A permission configuration module is used to obtain permission configuration information; the permission configuration information includes login information of multiple simulated users, each of which has different permissions;

[0014] A permission testing module, configured to perform a permission test on the permission request according to the permission configuration information, and obtain a response result and a test result of the permission request; the response result includes a response message of each simulated user;

[0015] a test verification module, configured to perform a permission test on the permission request according to the permission configuration information, and obtain a response result and a test result of the permission request; the permission configuration information includes login information of multiple simulated users, each of the simulated users having different permissions; and the response result includes a response message of each simulated user;

[0016] The test update module is used to determine the permission vulnerability detection result of the permission request based on the test result of the permission request and the verification result of the permission request.

[0017] According to another aspect of the present invention, an embodiment of the present invention further provides a permission vulnerability detection device, the permission vulnerability detection device comprising:

[0018] at least one processor; and

[0019] a memory communicatively connected to at least one processor; wherein,

[0020] The memory stores a computer program that can be executed by at least one processor. The computer program is executed by the at least one processor so that the at least one processor can execute the permission vulnerability detection method of any embodiment of the present invention.

[0021] According to another aspect of the present invention, a computer-readable storage medium is provided. The computer-readable storage medium stores computer instructions, which are used to enable a processor to implement the permission vulnerability detection method of any embodiment of the present invention when executed.

[0022] According to another aspect of the present invention, a computer program product is provided. The computer program product includes a computer program. When the computer program is executed by a processor, the method for detecting a permission vulnerability according to any embodiment of the present invention is implemented.

[0023] The technical solution of the embodiment of the present invention obtains the permission request of the application system, and performs vulnerability detection of different permissions on the permission request to obtain a response result and a test result, verifies the test result according to the response result to obtain a verification result, and combines the test result with the verification result to jointly determine the permission vulnerability detection result. The permission test result can be verified, which solves the problems of low efficiency, low accuracy, long time consumption and high cost of permission vulnerability detection in the prior art. The test result can be verified and corrected, thereby improving the accuracy of permission vulnerability detection, while reducing the cost of manual intervention and improving the efficiency of permission vulnerability detection.

[0024] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0026] Figure 1 This is a flowchart of a permission vulnerability detection method provided by an embodiment of the present invention;

[0027] Figure 2 This is a flowchart of a permission vulnerability detection method provided by an embodiment of the present invention;

[0028] Figure 3 This is a timing diagram of a permission vulnerability detection method provided according to an embodiment of the present invention;

[0029] Figure 4 This is a structural diagram of a permission vulnerability detection device provided according to an embodiment of the present invention;

[0030] Figure 5 It is a structural diagram of a permission vulnerability detection device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0031] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0033] In the technical solutions of the embodiments of the present invention, the acquisition, storage and application of driving trajectory points, etc., all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0034] Figure 1 This is a flow chart of a permission vulnerability detection method provided by an embodiment of the present invention. This embodiment of the present invention is applicable to detecting whether an application system has permission vulnerabilities, specifically using a vulnerability detection tool and verifying it using a large language model. This method can be performed by a permission vulnerability detection device, which can be implemented in hardware and / or software.

[0035] See also Figure 1 The permission vulnerability detection method shown includes:

[0036] S101: Obtain the permission request received by the application system.

[0037] The application system can receive requests from users and respond to them. Upon receiving a permission request, the application system needs to obtain the user's permissions and, based on the user's permissions, determine how to respond to the permission request. A permission request can be a request by a user for a service based on their permissions. For example, a permission request can be data that matches the user's access permissions or an application function that matches the user's permissions. In one example, the application system can be a banking system. A permission request can be a request by a user to inquire about their account balance.

[0038] S102 , obtaining authority configuration information; the authority configuration information includes login information of multiple simulated users, each of which has different authority.

[0039] Permission configuration information can refer to user permission configuration information. Permission vulnerability detection is the process of identifying unauthorized access risks within a system through technical means. Its core goal is to determine whether users can bypass permission controls and perform operations beyond their authorized permissions. Permission configuration information is used to simulate users with different permissions. Login information is used by users to log into their accounts within the application system and initiate requests to use the application system's services through their accounts. Login information for multiple simulated users can be provided as needed for testing. An input box can be configured to allow the test user to provide the username and password for the application system being tested.

[0040] For example, permission vulnerability detection can include vertical permission vulnerability detection and / or horizontal permission vulnerability detection. Among them, vertical permission vulnerability detection is used to verify whether low-privilege users can obtain high-privilege functions (such as ordinary users performing administrator operations). Vertical permission vulnerability detection is a cross-level permission vulnerability detection. Horizontal permission vulnerability detection is used to verify whether users with the same permission can illegally access other people's data (such as user A viewing user B's order). Horizontal permission vulnerability detection is a same-level permission vulnerability detection.

[0041] In one example, the permission configuration information includes the login information of user A, user B, and user C. User A is a user of the first bank, user B is a user of the second bank, and user C is an unauthorized user. A horizontal permission violation test is performed using user A and user B. A vertical permission violation test is performed using user A and user C.

[0042] S103: Perform a permission test on the permission request according to the permission configuration information to obtain a response result of the permission request and a test result; the response result includes a response message of each simulated user.

[0043] In this case, performing a permission test on a permission request based on the permission configuration information can involve simulating users with different permissions to initiate the same type of request to the application system, determining whether the application system's responses to the same type of request are identical, and determining the test result based on whether the responses are identical. The permission configuration information and permission request can be provided to a permission vulnerability detection application to obtain the test result output by the permission vulnerability detection application. It should be noted that the simulated user is not a real user and can be a fake user provided for testing purposes, or a real user authorized to access relevant user data. The response message can include data, status, and reason. The response message is used to determine whether the application system correctly processed the permission request initiated by the simulated user according to the permissions of the simulated user. The test result describes whether the application system's handling of the same permission request initiated by simulated users with different permissions complies with the permission control mechanism. The test result can indicate whether an unauthorized vulnerability exists or not. The test result can also include the vulnerability identifier, vulnerability type, vulnerability description, attack method, and solution for any unauthorized vulnerability.

[0044] In one example, the permission configuration information includes the login information of user A and the login information of user B. The permission request is replayed using the login information of user A and the login information of user B to obtain the response message a of user A and the response message b of user B. Here, message replay may refer to causing the interface to resend the message once more. In this process, the traffic and user data of the real user are not used. It is equivalent to using the login information of a simulated user to generate a simulated request with the same request content as the permission request initiated by the real user, and sending the simulated request to the application system. The application system processes the simulated request and feeds back the response message of the simulated request as the response result of the permission request. The similarity between the response message a of user A and the response message b of user B is calculated. When the similarity is greater than the similarity threshold M, it is determined that an unauthorized access vulnerability exists. When the similarity is less than the similarity threshold M, it is determined that an unauthorized access vulnerability does not exist.

[0045] In one example, permission configuration information includes login information for user A, user B, and user C. The permission request is a query request for a database, and the response includes response messages from user A, user B, and user C. For example, user A's response message indicates a query failure. User B's response message indicates a query result. User C's response message indicates a query result.

[0046] S104: Input the response result of the permission request into the large language model to perform test result verification to obtain the verification result of the permission request.

[0047] The response to the permission request describes the result of the application system processing the permission request initiated by the simulated user according to the simulated user's permissions. The response is provided to the large language model, which can determine whether the response is correct. The verification result can refer to the result of determining whether the response satisfies the processing results of the simulated user's permissions. The large language model can extract features from the response to obtain a feature vector, and decode the feature vector to obtain the verification result.

[0048] S105: Determine a permission vulnerability detection result of the permission request according to a test result of the permission request and a verification result of the permission request.

[0049] The permission vulnerability detection result may refer to the result of the application system's detection of whether there is a permission vulnerability in response to the permission request. The permission vulnerability detection result may include: the existence of an unauthorized vulnerability or the absence of an unauthorized vulnerability. If the test result and the verification result are consistent, the test result is determined as the permission vulnerability detection result. If the test result and the verification result are inconsistent, the test result is updated, and the updated test result is determined as the permission vulnerability detection result. For example, the opposite test result may be determined as the updated test result, or an alert may be issued to the test user, who then updates the test result.

[0050] After determining the permission vulnerability detection results, a security test report is generated. This report may include vulnerability address, vulnerability name, request method, parameters, credentials, attack vectors, warnings, vulnerability description, solution, permission request, and response results. Based on permission security knowledge, relevant information about the detected vulnerability can be queried and added to the security test report. Users can identify and resolve the permission vulnerability based on the permission vulnerability detection results and the security test report.

[0051] The technical solution of the embodiment of the present invention obtains the permission request of the application system, and performs vulnerability detection of different permissions on the permission request to obtain a response result and a test result, verifies the test result according to the response result to obtain a verification result, and combines the test result with the verification result to jointly determine the permission vulnerability detection result. The permission test result can be verified, which solves the problems of low efficiency, low accuracy, long time consumption and high cost of permission vulnerability detection in the prior art. The test result can be verified and corrected, thereby improving the accuracy of permission vulnerability detection, while reducing the cost of manual intervention and improving the efficiency of permission vulnerability detection.

[0052] In an optional embodiment, obtaining the permission request received by the application system includes: screening each of the alternative requests received by the application system according to parameter information of the alternative requests to obtain at least one permission request.

[0053] Among them, alternative requests can refer to all requests received by the application system. Alternative requests refer to requests generated during the testing process. During the development and maintenance of the Internet, network applications, websites, or mobile applications, engineers will perform various testing tasks to ensure system performance, functionality, and stability. These testing tasks include but are not limited to functional testing, performance testing, stress testing, and load testing. In these testing tasks, simulations of user access, data transmission, and request responses will generate alternative requests. A security user can initiate a permission vulnerability detection process and enable a packet capture tool to capture alternative requests received by the application system. The capture process is authorized by the application system and the user and is legal and compliant. Alternative requests can be captured for SMS interfaces and for user login interfaces.

[0054] The parameter information of the alternative request may refer to the information carried by the alternative request itself. The parameter information is used to simply and directly filter alternative requests that are not related to the permission operation.

[0055] For example, you can distinguish application systems by the domain name of the candidate request. Requests with the domain name of the application system to be tested are used as candidate requests for that application system. A hash value is generated based on the domain name and request parameter name of the candidate request. After deduplication and filtering based on the hash value, it is stored in the database for subsequent use.

[0056] In fact, some alternatives are not suitable for unauthorized vulnerability detection, such as requests for obtaining static pages and images. In some embodiments, alternative requests that do not involve user permissions: requests for obtaining static pages and requests for obtaining images, etc. Alternative requests that only process non-sensitive data: requests for obtaining public news information, announcement information (such as requests including the fields GET (get data), api (Application Programming Interface) or news) and queries for non-user-specific public data (such as weather information and product lists). Requests that require dynamic parameters or session binding: requests using CSRF Token (Cross-Site Request Forgery Token) or one-time verification codes (such as POST (submit data) or login (login)), etc.

[0057] In some embodiments, the parameter information may include a field. When the field includes at least one of the following: get, api, new, public data, non-sensitive information, static page, image, one-time verification code, and CSRF token, the alternative request is determined not to be a permission request and is discarded; when the field does not include any of the aforementioned fields, the alternative request is determined to be a permission request and is retained. By preliminarily screening the alternative requests, requests for obtaining static pages and images are filtered out. The permission request, including the resource location information and the content of the request message, is stored in a data collection for subsequent processing.

[0058] In some embodiments, a request feature can be generated based on parameter information, and based on the request feature, the permission request corresponding to the request feature can be queried from the alternative requests. For example, if an SMS permission vulnerability only attacks the SMS interface, the alternative request corresponding to the request feature can be queried from all the alternative requests based on the request feature of the SMS interface to determine if it is a permission request. For another example, if a username traversal permission vulnerability only attacks the user login interface, the alternative request corresponding to the request feature can be queried from all the alternative requests based on the request feature of the user login interface to determine if it is a permission request.

[0059] It can be seen that by screening the alternative requests to obtain permission requests, requests that are not related to permissions can be filtered out, redundant data that needs to be detected can be reduced, and the efficiency of permission vulnerability detection can be improved.

[0060] In an optional embodiment, the permission vulnerability detection method further includes: inputting each of the permission requests into a large language model for permission semantic screening to obtain a permission screening result for each of the permission requests; and updating each of the permission requests according to the permission screening result of each of the permission requests.

[0061] Semantic permission filtering refers to detecting whether a request is relevant to a permission operation based on the semantics of the request. The permission filtering result is used to determine whether a permission request is relevant to a permission operation based on semantics. The permission filtering result can include requests that are relevant to the permission or requests that are not relevant to the permission. Permission requests that are relevant to the permission are retained, while requests that are not relevant to the permission are eliminated.

[0062] For example, public requests that do not require permission judgment, such as https: / / xx.xx.xx.xx:xx / xx / sys / getLoginStatus, http: / / xx.xx.xx.xx:xx / xx / lang / zh-cn.json, http: / / xx.xx.xx.xx:xx / xx / getDefaultSysdate?timeZone=1&datetime=xxxxx, and https: / / xx.xx.xx.xx:xx / xx / getPublicKey, can be detected by a large language model to determine that the permission screening results are not related to permissions.

[0063] It can be seen that secondary fine-grained screening of permission requests through a large language model can provide a fine-grained screening step for permission requests, further reduce redundant data, prevent requests unrelated to permission operations from entering the permission vulnerability testing process, and prevent misjudgment of permission vulnerability testing, thereby improving the accuracy of permission vulnerability testing.

[0064] In an optional embodiment, the large language model is trained in the following manner: obtaining a security sample, the security sample including: permission security knowledge and permission security test report, the security test report including: vulnerability name, vulnerability resource location, vulnerability request and request response result, the permission security knowledge and the permission security test report are marked with the relationship between the vulnerability entity and the associated entity, the associated entity including at least one of the following: application identification, application version and attack method; training the large language model according to the security sample to obtain a trained large language model.

[0065] Permission security knowledge refers to knowledge gathered in the field of permission security. For example, permission security knowledge includes, but is not limited to, publicly available or authorized knowledge, such as academic papers, technical documentation, security reports, blog posts, forum discussions, and regulatory documents. Academic papers provide definitions and types of network security; technical documents provide technical principles, testing methods, and solutions for security vulnerabilities; security reports provide testing methods for security vulnerabilities; blog posts provide definitions, testing methods, and specific code examples for resolving vulnerabilities; forum discussions provide public opinion and testing methods for emerging vulnerabilities; and regulatory documents provide authoritative official security and data security specifications.

[0066] Among them, the security test report may refer to the historical test content of permission vulnerabilities. Permission vulnerabilities may refer to vulnerabilities that can bypass normal permission control mechanisms and enable the application system to perform unauthorized operations. The vulnerability name is used to identify permission vulnerabilities. Vulnerability resource location is used to determine the location information of resources with permission vulnerabilities. Vulnerability requests may refer to requests that detect permission vulnerabilities, that is, requests that the application system cannot execute normal permission control mechanisms. Request response results may refer to the response results of the application system with permission vulnerabilities to the vulnerability request. Security test reports can be extracted from security testing methods, security test vulnerabilities, and security test cases. In addition, security test reports can also include vulnerability descriptions, attack methods, defense strategies or compliance requirements.

[0067] Source data is collected and permission security knowledge and security test reports are extracted from it. Permission security knowledge and security test reports can also be preprocessed and annotated. In some embodiments, the collected data requires preprocessing, such as cleaning and format conversion to remove noise, correct errors, and unify the format. Furthermore, the collected data needs to be segmented and converted to the input format required by the model (extracting text and filtering out meaningless paragraphs) to ensure that the data is suitable for training.

[0068] In some embodiments, the pre-processed data is annotated, and the relationship between vulnerability entities and associated entities can be annotated. A vulnerability entity can refer to a permission vulnerability, and a vulnerability entity can be represented by a permission vulnerability identifier or a permission vulnerability category. An associated entity can be an entity related to a permission vulnerability. An application identifier can refer to the identification information of the application with the permission vulnerability. For example, a permission vulnerability is associated with a specific application, and specifically, the permission vulnerability is frequently found in that specific application. An application version can refer to the version information of the application with the permission vulnerability. For example, a permission vulnerability is associated with a specific application version, and specifically, the permission vulnerability is frequently found in that specific application version. An attack method can refer to the attack method used to exploit the permission vulnerability. For example, a permission vulnerability is associated with a specific attack method, and specifically, the attack method is often used to trigger the permission vulnerability. Vulnerability categories also need to be annotated, for example, vulnerabilities can be categorized as "unauthorized vulnerability" and "sensitive information leakage vulnerability." Sensitive information leakage: For example, the user's private data in plain text on a bank card is not confidential, which can lead to the leakage of the user's sensitive information.

[0069] Horizontal privilege escalation: Horizontal privilege escalation occurs when a user is able to access or manipulate the resources of users with the same privilege level. If a regular user is able to access the account information of another regular user or perform operations with the same privileges, then a horizontal privilege escalation issue exists. This attack typically occurs in web applications, where the attacker attempts to access the resources of another user by modifying the user ID or other identifiers in the request. For example, user A can view the balance of user B by logging into Alipay; user A can check the balance of user B by logging into their bank card account, or manipulate user B's balance to transfer money to user B.

[0070] Vertical privilege escalation: Vertical privilege escalation refers to a user being able to access or operate resources or functions that exceed their privilege level. Ordinary users can perform operations that administrators or other high-privilege users can perform, such as viewing the administrator panel and modifying system settings. This attack usually involves insufficient permission verification, allowing low-privilege users to perform high-privilege operations. For example, if a user without approval permission performs an approval operation, User A and User B, a colleague at the same level, cannot approve their own leave applications, but User C, a superior colleague, can approve User A's leave application. If User A can approve his own leave, it is equivalent to a vertical privilege escalation vulnerability.

[0071] Based on pre-processed and annotated data based on permission security knowledge and security test reports, security samples are generated. The annotated security samples are fed into the large language model, which then conducts self-learning and pre-training, resulting in a trained large language model. The trained large language model can be published and deployed online. The response results can be fed into the large language model, which then detects whether permission requests contain permission vulnerabilities and outputs verification results.

[0072] Furthermore, after training is complete, the large language model can be fine-tuned. Fine-tuning can be performed on specific tasks to meet the specific needs of the permission security field. For different responses from the large language model to the same question, the correct or superior answer is annotated and fed into the large language model. This ensures that subsequent responses from the large language model are more inclined toward the annotated answer. Furthermore, the large language model's knowledge base on permission security can be continuously enhanced.

[0073] It can be seen that by pre-training the large language model based on permission security knowledge and permission security test reports, and using the trained large language model to verify the test results of permission tests, permission test problems that are difficult to discover with traditional permission tests can be identified, and new vulnerabilities and new attack methods can be dynamically adapted to improve the accuracy of the verification results of permission tests.

[0074] Figure 2A flowchart of a permission vulnerability detection method provided by an embodiment of the present invention. Based on the above embodiment, the present embodiment of the present invention further specifies "inputting the response result of the permission request into a large language model for test result verification to obtain the verification result of the permission request" as "adding the response result to a verification prompt template to obtain input data; the verification prompt template includes: a business error detection template and / or a time misjudgment detection template; inputting the input data into a large language model for test result verification to obtain the verification result of the permission request."

[0075] It should be noted that for parts not described in detail in the embodiments of the present invention, reference may be made to the descriptions of other embodiments.

[0076] See also Figure 2 The permission vulnerability detection method shown includes:

[0077] S201: Obtain the permission request received by the application system.

[0078] S202 , obtaining authority configuration information; the authority configuration information includes login information of multiple simulated users, each of which has different authority.

[0079] S203: Perform a permission test on the permission request according to the permission configuration information to obtain a response result and a test result of the permission request; the response result includes a response message of each simulated user.

[0080] S204: Add the response result to a verification prompt template to obtain input data; the verification prompt template includes: a service error detection template and / or a time misjudgment detection template.

[0081] The verification prompt template may be a prompt template input to the large language model. The verification prompt template is used to guide the large language model to generate a verification result based on the response result. The verification prompt template includes a slot for the response result, and the response result is added to the slot to obtain the input data.

[0082] Among them, the business error detection template may refer to a prompt template for detecting whether there is a business error in the response result. The business error detection template is used to detect errors that are mistakenly judged to be the existence of an unauthorized vulnerability but are actually business errors. Among them, a business error may refer to an error due to the business service itself, not an error caused by the authorization control mechanism, and these business errors will cause users with different permissions to receive the same response message, and the general way to determine whether there is an unauthorized vulnerability is to perform a similarity test on the response messages of users with different permissions. If they are similar, it is determined that there is an unauthorized vulnerability, and if they are not similar, it is determined that there is no unauthorized vulnerability. Therefore, a business error will cause the similarity test result to be similar, thereby determining that the test result is the existence of an unauthorized vulnerability, but in fact it is caused by a business error, which has nothing to do with whether there is an unauthorized vulnerability. At this time, the test result of this type of situation is wrong. For example, business errors may include "cannot find resources" and "please log in again".

[0083] In an example, the business error detection template is as follows:

[0084] Determine whether the following message body is a business error. Messages typically contain fields such as a, b, and c to indicate standard or custom status codes. For example, 0 is not an error, but negative numbers are usually errors. Note: If the message contains clear error-related text, it is an error. Common error text includes: unauthorized, login expired, resource not found, information acquisition failure, and business logic failure. Please answer yes or no directly. Examples of business errors include: messages returning "Server cannot find resource" and messages returning "Please log in again."

[0085] The message is as follows:

[0086] {XX(response result slot)}

[0087] Among them, the time misjudgment detection template can refer to a prompt template for detecting whether the response result does not detect an unauthorized access vulnerability due to a time error. The time misjudgment detection template is used to detect that an unauthorized access vulnerability does not exist due to a time error. A large time difference will cause users with different permissions to receive the same response message to have dissimilar similarity detection results, thereby determining that the test result does not contain an unauthorized access vulnerability. However, in fact, it is caused by the time dissimilarity. However, the actual effective response content for different permissions is similar. In this case, an unauthorized access vulnerability actually exists, but it will lead to a misjudgment that the unauthorized access vulnerability does not exist. At this time, the test result of this type of situation is wrong.

[0088] In an example, the time misjudgment detection template is as follows:

[0089] Determine whether the following message bodies are time misjudgments. Messages typically include time information. For example, time information can be represented by dates, timestamps, or durations. Note: If the time information differs between messages but the rest of the content is similar, this is a time misjudgment. Please answer yes or no directly.

[0090] The message is as follows:

[0091] {XX(response result slot)}

[0092] S205: Input the input data into a large language model to perform test result verification to obtain a verification result of the permission request.

[0093] The verification result corresponding to the service error detection template may be the presence of a service error or the absence of a service error. The verification result corresponding to the time misjudgment detection template may be the presence of a time misjudgment or the absence of a time misjudgment.

[0094] S206: Determine a permission vulnerability detection result of the permission request according to the test result of the permission request and the verification result of the permission request.

[0095] Specifically, a permission request with a business error as a result of the permission vulnerability detection can be determined as not having an unauthorized access vulnerability. Alternatively, a permission request with a time misjudgment and no unauthorized access vulnerability as a result of the permission vulnerability detection can be determined as having an unauthorized access vulnerability. Permission vulnerability detection results in other situations can be test results.

[0096] In an optional embodiment, the permission vulnerability detection result of the permission request is determined based on the test result of the permission request and the verification result of the permission request, including: when the test result includes the existence of an unauthorized vulnerability, and the verification result includes the existence of a business error, determining that the permission vulnerability detection result of the permission request is that there is no unauthorized vulnerability; when the test result includes the existence of an unauthorized vulnerability, and the verification result includes the existence of a time misjudgment, determining that the permission vulnerability detection result of the permission request is that there is an unauthorized vulnerability.

[0097] Among them, the test result includes the existence of an unauthorized vulnerability, and the verification result includes the existence of a business error, indicating that a business error unrelated to the unauthorized vulnerability occurred, resulting in an error in the similarity detection of the unauthorized vulnerability. At this time, there is no unauthorized vulnerability. Therefore, the permission vulnerability detection result can be determined as a result different from the test result, that is, the permission vulnerability detection result is determined to be that there is no unauthorized vulnerability.

[0098] The test results include that there is no unauthorized access vulnerability, and the verification results include that there is a time misjudgment, indicating that the low time similarity causes a similarity detection error of the unauthorized access vulnerability. At this time, an unauthorized access vulnerability exists. Therefore, the permission vulnerability detection result can be determined to be different from the test result, that is, the permission vulnerability detection result is determined to be the existence of an unauthorized access vulnerability.

[0099] In some embodiments, when the test result includes the existence of an unauthorized vulnerability, and the verification result includes the absence of a business error, the permission vulnerability detection result of the permission request is determined to be the existence of an unauthorized vulnerability. When the test result includes the existence of an unauthorized vulnerability, and the verification result includes the existence of a time misjudgment, the permission vulnerability detection result of the permission request is determined to be the existence of an unauthorized vulnerability. When the test result includes the existence of an unauthorized vulnerability, and the verification result includes the absence of a time misjudgment, the permission vulnerability detection result of the permission request is determined to be the existence of an unauthorized vulnerability. When the test result includes the existence of an unauthorized vulnerability, the verification result includes the absence of a business error, and the verification result includes the presence of a time misjudgment, the permission vulnerability detection result of the permission request is determined to be the existence of an unauthorized vulnerability. When the test result includes the existence of an unauthorized vulnerability, the verification result includes the absence of a business error, and the verification result includes the absence of a time misjudgment, the permission vulnerability detection result of the permission request is determined to be the existence of an unauthorized vulnerability.

[0100] When the test result includes that there is no unauthorized access vulnerability, and the verification result includes that there is no time misjudgment, the permission vulnerability detection result of the permission request is determined to be that there is no unauthorized access vulnerability. When the test result includes that there is no unauthorized access vulnerability, and the verification result includes that there is no business error, the permission vulnerability detection result of the permission request is determined to be that there is no unauthorized access vulnerability. When the test result includes that there is no unauthorized access vulnerability, and the verification result includes that there is a business error, the permission vulnerability detection result of the permission request is determined to be that there is no unauthorized access vulnerability. When the test result includes that there is no unauthorized access vulnerability, the verification result includes that there is no time misjudgment, and the verification result includes that there is no business error, the permission vulnerability detection result of the permission request is determined to be that there is no unauthorized access vulnerability. When the test result includes that there is no unauthorized access vulnerability, the verification result includes that there is no time misjudgment, and the verification result includes that there is a business error, the permission vulnerability detection result of the permission request is determined to be that there is no unauthorized access vulnerability.

[0101] It can be seen that when the test result includes the existence of an unauthorized vulnerability and the verification result includes the existence of a business error, the permission vulnerability detection result is determined to be different from the test result, which can eliminate the misjudgment of the permission vulnerability caused by the business error; and when the test result includes the absence of an unauthorized vulnerability and the verification result includes the existence of a time misjudgment, the permission vulnerability detection result is determined to be different from the test result, which can eliminate the misjudgment of the permission vulnerability caused by the time misjudgment, thereby improving the detection accuracy of the permission vulnerability.

[0102] In an optional embodiment, the service error detection template includes a service error field; the time misjudgment detection template includes prompt content for time similarity judgment.

[0103] The service error field may refer to the content of the service error. The service error field may include "the server cannot find the resource" or "please log in again". The prompt content of the time similarity judgment is used to guide the large language model to determine whether the time is similar.

[0104] It can be seen that by configuring the business error detection template to include the business error field, the detection accuracy of the business error can be improved, and by configuring the time misjudgment detection template to include the prompt content of time similarity judgment, the detection accuracy of time misjudgment can be improved, thereby improving the accuracy of unauthorized vulnerability detection.

[0105] The embodiment of the present invention configures the verification prompt template as an error detection template and a time misjudgment detection template, and adds the response result to the corresponding verification prompt template to obtain input data, and inputs it into a large language model for processing to obtain a verification result. The test results of the permission test can be verified from the two dimensions of business error and time misjudgment, and the semantics in the response result can be deeply analyzed to accurately identify the detection results of misjudged permission vulnerabilities, thereby improving the accuracy of the permission vulnerability detection results.

[0106] In a scenario, such as Figure 3 As shown, the permission vulnerability detection method may include: 1. The security test user obtains the alternative requests received by the application system and performs a preliminary screening of the alternative requests to obtain the permission request. 2. The security test user provides permission configuration information. 3. The permission vulnerability detection device performs permission semantic screening on the permission request based on the large language model, and updates the permission request to implement secondary screening of the permission request. 4. The permission vulnerability detection device uses the permission vulnerability tool to perform permission vulnerability detection on the secondary screened permission request based on the permission configuration information to obtain test results and response results. 5. The permission vulnerability detection device uses the large language model to verify the test result according to the response result to obtain the verification result, and obtains the permission vulnerability detection result based on the test result and the verification result. 6. The permission vulnerability detection device generates a security test report based on the permission vulnerability detection result and provides it to the security test user.

[0107] Figure 4 This is a schematic diagram of the structure of a permission vulnerability detection device provided by an embodiment of the present invention. This embodiment of the present invention is applicable to detecting whether an application system has permission vulnerabilities, specifically using a vulnerability detection tool and verifying it using a large language model. The device can execute a permission vulnerability detection method and can be implemented in hardware and / or software.

[0108] See also Figure 4The permission vulnerability detection device shown includes:

[0109] Request acquisition module 401, used to obtain permission requests received by the application system;

[0110] The permission configuration module 402 is used to obtain permission configuration information; the permission configuration information includes login information of multiple simulated users, each of which has different permissions;

[0111] The permission testing module 403 is configured to perform a permission test on the permission request according to the permission configuration information, and obtain a response result and a test result of the permission request; the response result includes a response message of each simulated user;

[0112] a test verification module 404 configured to perform a permission test on the permission request according to the permission configuration information, and obtain a response result and a test result of the permission request; the permission configuration information includes login information of multiple simulated users, each of which has different permissions; and the response result includes a response message of each simulated user;

[0113] The test update module 405 is configured to determine a permission vulnerability detection result of the permission request based on a test result of the permission request and a verification result of the permission request.

[0114] The technical solution of the embodiment of the present invention determines the grayscale traffic ratio of the target server based on the operating data of the target server, can adjust the grayscale traffic ratio in real time according to the real-time processing situation of the target server, and send the first task screened according to the grayscale traffic ratio to the target server for response processing, so as to realize real-time adjustment of the number of grayscale processing tasks in the process of grayscale release of new version functions, solves the technical problem of the lag in traffic adjustment caused by the failure to adjust the traffic ratio in time due to the fixed rules or fixed ratios of grayscale traffic ratios in the prior art, avoids the abnormal expansion of new versions, and can expand the scope of reliable new version releases in real time, reduce the lag in grayscale release adjustments, and improve the reliability and flexibility of task processing in the grayscale release process.

[0115] Optionally, the test and verification module 404 includes:

[0116] A prompt template filling unit is used to add the response result to the verification prompt template to obtain input data; the verification prompt template includes: a business error detection template and / or a time misjudgment detection template;

[0117] The prompt verification unit is used to input the input data into the large language model to perform test result verification and obtain the verification result of the permission request.

[0118] Optionally, the test update module 405 is specifically configured to:

[0119] When the test result includes that there is an unauthorized vulnerability, and the verification result includes that there is a business error, determining that the permission vulnerability detection result of the permission request is that there is no unauthorized vulnerability;

[0120] When the test result includes that there is no unauthorized vulnerability, and the verification result includes that there is a time misjudgment, it is determined that the permission vulnerability detection result of the permission request is that there is an unauthorized vulnerability.

[0121] Optionally, the service error detection template includes a service error field; the time misjudgment detection template includes prompt content for time similarity judgment.

[0122] Optionally, request acquisition module 401 includes:

[0123] The request initial screening unit is used to screen each candidate request according to parameter information of the candidate request received by the application system to obtain at least one permission request.

[0124] Optionally, the permission vulnerability detection device further includes:

[0125] a request fine screening unit, configured to input each permission request into a large language model for permission semantic screening, and obtain a permission screening result for each permission request;

[0126] The request updating unit is configured to update each of the permission requests according to the permission screening result of each of the permission requests.

[0127] Optionally, the permission vulnerability detection device further includes: a model training module for:

[0128] Obtain a security sample, the security sample including: permission security knowledge and a permission security test report, the security test report including: a vulnerability name, a vulnerability resource location, a vulnerability request, and a request response result, the permission security knowledge and the permission security test report annotated with a relationship between a vulnerability entity and an associated entity, the associated entity including at least one of the following: an application identifier, an application version, and an attack method;

[0129] The large language model is trained according to the security sample to obtain a trained large language model.

[0130] The permission vulnerability detection device provided by the embodiment of the present invention can execute the permission vulnerability detection method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the permission vulnerability detection method.

[0131] Example 4

[0132] Figure 5A schematic structural diagram of a permission vulnerability detection device 500 that can be used to implement an embodiment of the present invention is shown.

[0133] like Figure 5 As shown, the permission vulnerability detection device 500 includes at least one processor 501, and a memory connected to the at least one processor 501, such as a read-only memory (ROM) 502, a random access memory (RAM) 503, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 501 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 502 or the computer program loaded from the storage unit 508 to the random access memory (RAM) 503. Various programs and data required for the operation of the permission vulnerability detection device 500 can also be stored in RAM503. The processor 501, ROM502 and RAM503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0134] Multiple components in the permission vulnerability detection device 500 are connected to the I / O interface 505, including: an input unit 506, such as a keyboard, mouse, etc.; an output unit 507, such as various types of displays, speakers, etc.; a storage unit 508, such as a magnetic disk, optical disk, etc.; and a communication unit 509, such as a network card, modem, wireless communication transceiver, etc. The communication unit 509 allows the permission vulnerability detection device 500 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0135] Processor 501 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of processor 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processor, controller, microcontroller, etc. Processor 501 executes the various methods and processes described above, such as the permission vulnerability detection method.

[0136] In some embodiments, the permission vulnerability detection method can be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on the permission vulnerability detection device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by processor 501, one or more steps of the permission vulnerability detection method described above can be performed. Alternatively, in other embodiments, processor 501 can be configured to execute the permission vulnerability detection method in any other appropriate manner (for example, by means of firmware).

[0137] Various embodiments of the systems and techniques described above can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0138] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0139] In the context of the present invention, computer-readable storage media can be tangible media that can contain or store a computer program for use with an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Computer-readable storage media can include but are not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, computer-readable storage media can be machine-readable signal media. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0140] To provide interaction with a user, the systems and techniques described herein can be implemented on an operation detection device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball), through which the user can provide input to the permission vulnerability detection device. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0141] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0142] A computing system may include clients and servers. The clients and servers are generally remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within a cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS (Virtual Private Server) services.

[0143] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.

[0144] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A permission vulnerability detection method, characterized in that: The method comprises: Get the permission request received by the application system; Obtaining permission configuration information; the permission configuration information includes login information of multiple simulated users, each of which has different permissions; Performing a permission test on the permission request according to the permission configuration information to obtain a response result and a test result of the permission request; the response result includes a response message of each simulated user; Inputting the response result of the permission request into the large language model for test result verification to obtain the verification result of the permission request; Determine a permission vulnerability detection result of the permission request based on the test result of the permission request and the verification result of the permission request.

2. The method according to claim 1, characterized in that The step of inputting the response result of the permission request into the large language model for test result verification to obtain the verification result of the permission request includes: Adding the response result to a verification prompt template to obtain input data; the verification prompt template includes: a business error detection template and / or a time misjudgment detection template; The input data is input into a large language model to perform test result verification to obtain a verification result of the permission request.

3. The method according to claim 2, characterized in that The determining, based on the test result of the permission request and the verification result of the permission request, a permission vulnerability detection result of the permission request includes: When the test result includes that there is an unauthorized vulnerability, and the verification result includes that there is a business error, determining that the permission vulnerability detection result of the permission request is that there is no unauthorized vulnerability; When the test result includes that there is no unauthorized vulnerability, and the verification result includes that there is a time misjudgment, it is determined that the permission vulnerability detection result of the permission request is that there is an unauthorized vulnerability.

4. The method according to claim 2, characterized in that The service error detection template includes a service error field; the time misjudgment detection template includes prompt content for time similarity judgment.

5. The method according to claim 1, wherein The obtaining of the permission request received by the application system includes: According to the parameter information of the candidate requests received by the application system, each candidate request is screened to obtain at least one permission request.

6. The method according to claim 5, characterized in that Also includes: Inputting each of the permission requests into a large language model for permission semantic screening to obtain permission screening results for each of the permission requests; Each of the permission requests is updated according to the permission screening result of each of the permission requests.

7. The method according to claim 1, characterized in that The large language model is trained in the following way: Obtain a security sample, the security sample including: permission security knowledge and a permission security test report, the security test report including: a vulnerability name, a vulnerability resource location, a vulnerability request, and a request response result, the permission security knowledge and the permission security test report annotated with a relationship between a vulnerability entity and an associated entity, the associated entity including at least one of the following: an application identifier, an application version, and an attack method; The large language model is trained according to the security sample to obtain a trained large language model.

8. A permission vulnerability detection device, characterized in that: The device comprises: The request acquisition module is used to obtain the permission request received by the application system; A permission configuration module is used to obtain permission configuration information; the permission configuration information includes login information of multiple simulated users, each of which has different permissions; A permission testing module, configured to perform a permission test on the permission request according to the permission configuration information, and obtain a response result and a test result of the permission request; the response result includes a response message of each simulated user; a test verification module, configured to perform a permission test on the permission request according to the permission configuration information, and obtain a response result and a test result of the permission request; the permission configuration information includes login information of multiple simulated users, each of the simulated users having different permissions; and the response result includes a response message of each simulated user; The test update module is used to determine the permission vulnerability detection result of the permission request based on the test result of the permission request and the verification result of the permission request.

9. A permission vulnerability detection device, characterized in that: The permission vulnerability detection device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the permission vulnerability detection method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the permission vulnerability detection method according to any one of claims 1 to 7 when executed.

Images