Object-level authorization vulnerability automatic detection method and system based on large language model

Abstract

The invention provides an automatic object-level authorization vulnerability detection method based on a large language model, which comprises the following steps of: firstly, identifying a sensitive resource table through SQL (Structured Query Language) grammar analysis, and analyzing an operation path from a tracking request parameter to the sensitive resource table by utilizing a forward data stream; then, performing context sensing analysis on the database operation by adopting LLM to infer object-level sensitive operation; thirdly, recognizing program logic and a conditional protection mechanism in database query through static analysis, and recognizing custom verification logic such as method-level annotation and administrator permission in combination with an LLM and character string matching method; and finally, judging whether the sensitive operation lacks user-defined verification, ownership SQL constraint and access control conditions at the same time or not by integrating the mechanism, and generating a vulnerability report according to the judgment result. The invention further provides an automatic object-level authorization vulnerability detection system based on the large language model. Therefore, the detection precision can be effectively improved, and false alarm and missing alarm are remarkably reduced.

Description

Technical Field

[0001] This invention relates to the field of web application security detection technology, and in particular to an automated detection method, system, storage medium, and electronic device for object-level authorization vulnerabilities based on a large language model, used to identify unauthorized object-level access vulnerabilities in web applications. Background Technology

[0002] Key points for detecting object-level authorization vulnerabilities include: (1) identifying potential points of direct reference to objects; and (2) assessing whether object-level authorization vulnerabilities exist.

[0003] Existing Dynamic Detection Methods: Currently, manual penetration testing is the mainstream method for detecting object-level authorization vulnerabilities. This method mainly verifies access rights to private resources by modifying request parameters of different user roles. Its typical detection process includes three key stages: system interaction testing, suspicious request identification, and vulnerability exploitation verification. Despite the support of professional penetration testing tools such as Burp Suite and OWASP ZAP, traditional manual penetration testing methods still face inherent limitations such as low detection efficiency and over-reliance on expert experience. To overcome these limitations, the existing method IDOT (a semi-automated detection tool or method) innovatively focuses the scope of semi-automated detection on the system interaction stage. This scheme adopts a multi-stage technical path: first, cluster analysis is performed based on request path similarity to filter suspicious API endpoints; then, identity parameters are automatically identified and replaced to generate multi-role test cases; finally, authorization vulnerabilities are determined by analyzing the differences in response content of users with different identities. Experimental results show that compared with traditional penetration testing methods, IDOT significantly improves testing efficiency while maintaining the same detection accuracy, providing a new technical approach for achieving efficient automated dynamic detection.

[0004] Existing static authentication methods: In static object-level authorization detection, the existing BOLARAY tool (a heuristic rule-based static analysis tool) employs a heuristic analysis method. First, it identifies database operations requiring protection within the program based on empirical research results, marking them as potential direct object reference points. Then, based on heuristic rules and internal data dependencies, it locates the permission-checking operations. Finally, through control dependency analysis, it reports the existence of database operation paths not protected by permission checks. Furthermore, existing technologies focusing on the correlation between SQL (Database Query Language) statement types and users, such as the MACE tool, infer user resources by analyzing INSERT statements (SQL commands used to add new records to database tables) and performing object-level permission verification on UPDATE / DELETE statements along the request path. Both of these methods rely on empirically derived heuristic rules, specifically designed for PHP web applications, and have shown some effectiveness in practical detection.

[0005] In terms of dynamic detection, although it can capture runtime state, its detection effectiveness heavily relies on the experience and rules of security experts and is limited by test case coverage. In terms of static analysis, existing static detection solutions generally adopt heuristic rules based on fixed patterns. However, object-level authorization, as a typical application logic vulnerability, is highly dependent on specific business scenarios (such as the huge difference between the object-level permission models of e-commerce orders and medical records). This causes many object-level sensitive operations to be ignored or misidentified, which in turn affects the accuracy of subsequent vulnerability detection. For example, existing methods do not consider SELECT operations in order to reduce false positives.

[0006] Furthermore, modern Java Web applications commonly employ diverse protection mechanisms, which poses a fundamental technical obstacle to detection methods based on unified rules, further increasing the difficulty of unified detection. Summary of the Invention

[0007] To address the detection capability issues caused by the reliance on rigid heuristic rules in existing technologies, this invention proposes an automated detection method, system, storage medium, and electronic device for object-level authorization vulnerabilities based on a large language model. This aims to improve the accuracy of Java Web application object-level vulnerability detection and reduce false positives and false negatives.

[0008] To achieve the aforementioned technical effects, this invention provides, on the one hand, an automated detection method for object-level authorization vulnerabilities based on a large language model, comprising the following steps:

[0009] Based on SQL syntax analysis, sensitive resource tables associated with user tables are identified from SQL files. These sensitive resource tables store data that are subordinate to users.

[0010] By analyzing the forward data flow, the propagation path of parameters from the request entry point to the sensitive resource table is traced, and the database operation statements that reach the sensitive resource table are detected and identified. Furthermore, using a large language model, the database operation statements are analyzed for context awareness to infer whether they are object-level sensitive operations that require object-level permission protection.

[0011] Static analysis techniques are used to identify condition protection mechanisms along the path from the program entry point to the object-level sensitive operation. These condition protection mechanisms include condition judgments in the program logic and condition constraints in the database query.

[0012] By using a large language model and combining it with string matching methods, custom permission verification logic on the request entry method is identified. The custom permission verification logic includes permission verification constraints and administrator permission protection measures. The permission verification constraints are implemented through method-level annotations.

[0013] Based on the condition protection mechanism and the custom permission verification logic, determine whether the object-level sensitive operation simultaneously satisfies the following conditions: no user-defined permission verification constraints, no SQL condition constraints based on object ownership, and no access control condition restrictions. If so, determine that there is an object-level authorization vulnerability and generate a vulnerability diagnosis report.

[0014] Furthermore, the identification of sensitive resource tables associated with the user table from the SQL file based on SQL syntax analysis includes:

[0015] A thesaurus is constructed based on the pre-defined user table and field keywords generated by the large language model, and a keyword matching strategy is used to identify the user table in the SQL file;

[0016] By analyzing explicit foreign key constraints or implicit semantic relationships, tables that are directly or indirectly related to the user table are located and used as sensitive resource tables for storing user resources.

[0017] Furthermore, the method of using keyword matching to identify user tables in SQL files includes:

[0018] Parse the SQL file to extract all CREATE TABLE statements;

[0019] The table name and field name are matched against the thesaurus using case-insensitive and delimiter variant matching methods to identify the user table.

[0020] Furthermore, in the step of identifying the condition protection mechanism, the identification of condition judgments in the program logic includes:

[0021] Extract all conditional statements along the path from the request entry point to the database operation;

[0022] Backward analysis is performed on each condition variable to verify whether it meets the predetermined data characteristic conditions. If it does, it is determined to be a valid object-level permission check. The data characteristic conditions include: one parameter of the condition variable depends on an uncontrollable input parameter, another parameter depends on the current user, and one of the parameters originates from a database query operation.

[0023] Furthermore, in the step of identifying the condition protection mechanism, the identification of condition constraints in the database query includes:

[0024] Perform a backward analysis on the object-level sensitive operation to determine whether the variables of the object-level sensitive operation depend on the current user variables; if so, determine that the object-level sensitive operation is protected by SQL condition constraints based on object ownership.

[0025] Furthermore, the string matching method includes matching the permission annotation content with the string comparison of the function method name.

[0026] Furthermore, in the step of using a large language model to identify administrator access control measures, a two-stage prompt word framework is adopted, including:

[0027] In the first phase, the large language model is guided to identify access paths that are only accessible to administrators based on application context and configuration information.

[0028] In the second stage, based on the access path identified in the first stage, the large language model is guided to determine whether the corresponding request entry point has implemented an access control mechanism that restricts access to only administrators.

[0029] On the other hand, the present invention also provides an automated detection system for object-level authorization vulnerabilities based on a large language model, including an object-level sensitive operation inference module and an object-level authorization vulnerability detection module, wherein:

[0030] The object-level sensitive operation inference module is used for:

[0031] Based on SQL syntax analysis, sensitive resource tables associated with user tables are identified from SQL files. These sensitive resource tables store data that are subordinate to users.

[0032] By analyzing the forward data flow, the propagation path of parameters from the request entry point to the sensitive resource table is traced, and the database operation statements that reach the sensitive resource table are detected and identified. Furthermore, using a large language model, the database operation statements are analyzed for context awareness to infer whether they are object-level sensitive operations that require object-level permission protection.

[0033] The object-level authorization vulnerability detection module is used for:

[0034] Static analysis techniques are used to identify condition protection mechanisms along the path from the program entry point to the object-level sensitive operation. These condition protection mechanisms include condition judgments in the program logic and condition constraints in the database query.

[0035] By using a large language model and combining it with string matching methods, custom permission verification logic on the request entry method is identified. The custom permission verification logic includes permission verification constraints and administrator permission protection measures. The permission verification constraints are implemented through method-level annotations.

[0036] Based on the condition protection mechanism and the custom permission verification logic, determine whether the object-level sensitive operation simultaneously satisfies the following conditions: no user-defined permission verification constraints, no SQL condition constraints based on object ownership, and no access control condition restrictions. If so, determine that there is an object-level authorization vulnerability and generate a vulnerability diagnosis report.

[0037] In addition, a storage medium and a computer device are provided, the storage medium being used to store a computer program for executing the above-described automated detection method for object-level authorization vulnerabilities based on a large language model.

[0038] The computer device includes a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor. When the processor executes the computer program, it implements the above-described automated detection method for object-level authorization vulnerabilities based on a large language model.

[0039] The automated detection method and system for object-level authorization vulnerabilities based on a large language model, as described in this invention, first identifies sensitive resource tables through SQL analysis and locates related operations using data flow tracing. Then, it combines LLM (Language Modeling) to understand the business context and intelligently infers object-level sensitive operation points. Subsequently, it identifies conditional protection mechanisms in the code through static analysis and integrates LLM and string matching methods to identify annotation-level and administrator-level custom protection logic. Finally, it comprehensively judges whether the sensitive operation lacks all three types of protection mechanisms to accurately determine the vulnerability. Thus, this invention effectively overcomes the problems of rigidity and high false positive rates of traditional rule-based methods, significantly improving the detection accuracy and coverage of object-level authorization vulnerabilities in complex Java Web applications. Attached Figure Description

[0040] Figure 1 A flowchart illustrating the steps of the automated detection method for object-level authorization vulnerabilities based on a large language model provided in an embodiment of the present invention;

[0041] Figure 2 A structural block diagram of the automated detection system for object-level authorization vulnerabilities based on a large language model, provided in another embodiment of the present invention;

[0042] Figure 3 This is a schematic diagram of the workflow of the automated detection system for object-level authorization vulnerabilities based on a large language model as described in this invention.

[0043] Figure 4 This is a schematic diagram of the sensitive entry point judgment prompt words used in the automated detection method for object-level authorization vulnerabilities based on a large language model as described in this invention;

[0044] Figure 5 This is a schematic diagram of the custom constraint recognition prompt words used in the automated detection method for object-level authorization vulnerabilities based on a large language model as described in this invention;

[0045] Figure 6 This is a schematic diagram of the administrator privilege recognition prompt words used in the automated detection method for object-level authorization vulnerabilities based on a large language model as described in this invention;

[0046] Figure 7 This is a schematic diagram illustrating the detection results of the object-level authorization vulnerability automated detection method based on a large language model according to the present invention on known vulnerabilities;

[0047] Figure 8 This is a summary chart of vulnerability detection results for the automated detection method for object-level authorization vulnerabilities based on a large language model as described in this invention.

[0048] Figure 9 A schematic diagram of the structure of the computer device provided by the present invention. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0050] It should be noted that references to "an embodiment," "embodiment," "example embodiment," etc., in this specification refer to the described embodiment including specific features, structures, or characteristics, but not every embodiment must include these specific features, structures, or characteristics. Furthermore, such expressions do not refer to the same embodiment. Moreover, when describing specific features, structures, or characteristics in conjunction with embodiments, whether or not explicitly described, it is indicated that incorporating such features, structures, or characteristics into other embodiments is within the knowledge of those skilled in the art.

[0051] Furthermore, certain terms are used in the specification and subsequent claims to refer to specific components or parts. Those skilled in the art will understand that manufacturers may use different names or terms to refer to the same component or part. This specification and subsequent claims do not distinguish components or parts by differences in name, but rather by differences in function. The terms "comprising" and "including" used throughout the specification and subsequent claims are open-ended and should be interpreted as "including but not limited to." Additionally, the term "connection" here includes any direct and indirect electrical connection means. Indirect electrical connection means include connections made through other means.

[0052] During the research on static detection of object-level authorization vulnerabilities in Java Web applications, it was learned that the defect in existing technologies is caused by the failure to combine the specific business logic of the application during static detection. Further research on the principle of object-level authorization vulnerabilities in Java Web applications and existing large language model vulnerability detection technologies revealed that this vulnerability can be solved by using large language models to enhance the understanding of the business logic of Web applications. This approach abandons the use of heuristic rules to uniformly infer the authorization intent of the application in existing static detection methods. Instead, it uses large language models to understand the business logic of each application, inferring more accurate vulnerability occurrence points and existing object-level authorization protection mechanisms.

[0053] To address this issue, this invention provides an automated detection method and system for object-level authorization vulnerabilities based on a large language model (LLM), overcoming the technical bottleneck of traditional methods' inability to adapt to changing business logic. Specifically, it achieves accurate detection through a triple analysis: first, sensitive data operation paths are located by tracing data flow; then, LLM (Large Language Model) is introduced for business context awareness, intelligently identifying sensitive object-level operations requiring authorization protection; finally, a hybrid detection model is constructed, which identifies conditional protection logic in the code through static analysis and identifies annotation-level permission constraints by combining LLM and rule matching. This dual-track architecture of static analysis + LLM semantic understanding achieves deep perception of business logic vulnerabilities, fundamentally breaking through the technical barriers of traditional rule-based detection methods in complex Java Web application scenarios.

[0054] To enable those skilled in the art to reproduce and implement the present invention, the following detailed description, in conjunction with the accompanying drawings and specific embodiments, will illustrate each step of the automated detection method and system for object-level authorization vulnerabilities based on a large language model. These embodiments are specific illustrations of the present invention, and their descriptions are helpful in understanding the present invention, but should not be construed as limiting the present invention.

[0055] Figure 1This invention illustrates an automated detection method for object-level authorization vulnerabilities based on a large language model, comprising the following steps:

[0056] S101: Based on SQL syntax analysis, identify sensitive resource tables associated with user tables from SQL files. These sensitive resource tables store data that are subordinate to users.

[0057] Furthermore, step S101 includes: constructing a thesaurus based on the pre-defined user table and field keywords generated by the large language model, and identifying the user table in the SQL file using a keyword matching strategy; and locating tables that are directly or indirectly related to the user table by analyzing explicit foreign key constraints or implicit semantic relationships, as sensitive resource tables for storing user resources.

[0058] The step of using a keyword matching strategy to identify user tables in an SQL file includes: parsing the SQL file to extract all CREATE TABLE statements; and matching table names and field names with the dictionary using case-insensitive and delimiter variant matching methods to identify user tables.

[0059] Modern web applications commonly employ normalized database design, using Entity-Relationship Mapping (ORM) to transform core business objects into structured data tables. Their metadata characteristics (including table structure, field attributes, and constraints) effectively reflect business semantics and data dependencies. Development teams typically explicitly express business rules through SQL comments or naming conventions (such as table / column name prefix and suffix rules). Based on this characteristic, this embodiment specifically employs a sensitive resource table identification method based on SQL syntax analysis. First, the user table is located, preferably using a keyword matching strategy to identify the user table in the SQL file. Then, a thesaurus is constructed based on common user table names and field keywords generated by LLM. Subsequently, the SQL file is parsed to extract all CREATE TABLE statements to obtain the complete table structure. Finally, tables that simultaneously meet the table name and field name conditions are matched using case insensitivity and delimiter variants (such as _, -, or no delimiter), while irrelevant tables (such as user_logs) are excluded. Then, based on the user table, the associated tables storing user resources (i.e., sensitive resource tables) are identified. Sensitive resource tables refer to data tables that store data with a subordinate relationship to users, and their relationships map the logical connections between business entities. The key to identifying such tables lies in analyzing data relationships and locating tables that are directly or indirectly related to user tables. Table relationships in a database are mainly achieved in two ways: (1) explicit foreign key constraints (FOREIGN KEY); (2) implicit semantic relationships (based on field naming or business logic). Sensitive resource tables usually form a relationship path to user tables through direct (foreign key or semantic relationship) or indirect (such as join tables) methods.

[0060] S102: Through forward data flow analysis, trace the propagation path of parameters from the request entry point to the sensitive resource table, detect and identify the database operation statements that reach the sensitive resource table; and use a large language model to perform context-aware analysis on the database operation statements to infer whether they are object-level sensitive operations that require object-level permission protection.

[0061] The specific implementation process of step S102 is as follows:

[0062] First, reachable operations are identified. The triggering of object-level authorization vulnerabilities relies on externally controllable parameters operating on sensitive resources, specifically the process of these parameters propagating from the request entry method to the database operation statement. To address this, this embodiment employs a forward data flow analysis method, starting from the request entry method and tracing the parameter propagation path along the inter-process control flow to detect whether it ultimately reaches the database statement that operates on the sensitive resource table. It should be noted that this process fully considers the encapsulation characteristics of database operations in ORM frameworks commonly used in Java Web applications. Compared to existing detection methods that only focus on the raw SQL statement, this solution can more comprehensively cover the actual architecture of modern Java Web applications.

[0063] Then, the large language model is used to infer object-level sensitive operations. In this process, carefully designed prompts guide the large language model's analysis, specifically employing the following techniques: first, using a prompting method with a small sample size; second, mandating that the large language model provide analytical explanations and output them in a prescribed format, thereby reducing the risk of model illusion; prompts include... Figure 4 As shown. To avoid code implementation details interfering with business logic judgment, a two-stage questioning strategy is adopted: the first stage requires the large language model to summarize the core business purpose of the request entry point based on the business context, stripping away the technical implementation details; the second stage, based on the action and resource information output in the first stage, performs a business-level permission assessment. When the large language model determines that a user should not be allowed to perform a specific operation through a given resource identifier, it can infer that the endpoint needs to be protected by object-level permissions, thereby accurately identifying the object-level sensitive operations that need to be detected. This method effectively solves the problem of misjudgment of sensitive operations caused by multi-table operations and complex business scenarios in modern Java Web applications.

[0064] S103: Through static analysis techniques, identify the condition protection mechanisms along the path from the program entry point to the object-level sensitive operation path. The condition protection mechanisms include condition judgments in the program logic and condition constraints in the database query.

[0065] In the step of identifying the condition protection mechanism, the identification of condition judgments in the program logic includes: extracting all condition statements on the path from the request entry point to the database operation; performing backward analysis on each condition variable to verify whether it meets the predetermined data feature conditions, and if it does, determining it as a valid object-level permission check; wherein, the data feature conditions include: one parameter of the condition variable depends on an uncontrollable input parameter, another parameter depends on the current user, and one of the parameters originates from a database query operation.

[0066] Furthermore, in the step of identifying the condition protection mechanism, when identifying the condition constraints in the database query, the following steps are included: performing backward analysis on the object-level sensitive operation to determine whether the variable of the object-level sensitive operation depends on the current user variable; if so, it is determined that the object-level sensitive operation is protected by SQL condition constraints based on object ownership.

[0067] Conditional constraints are primarily implemented in two forms: conditional judgments in program logic (such as if statements) and conditional constraints in database queries (such as WHERE clauses). When analyzing if statements, variables can be categorized into two types based on their data source: one type depends on current user session variables, and the other depends on externally uncontrollable input parameters; at least one variable in these conditions must depend on the return result of a database query (SELECT). Therefore, this embodiment first extracts all conditional statements along the path from the request entry point to the database operation, and then performs backward analysis on each conditional variable to verify whether the following conditions are met: one parameter depends on an uncontrollable variable (such as an input parameter), another parameter depends on the current user, and one parameter originates from a database query. For SQL conditional constraints, if the variable in a sensitive database operation depends on a current user variable, then the operation is protected by SQL constraints. Specifically, backward analysis of the database operation statement is required to determine whether its data depends on current user variables.

[0068] By combining the two technical approaches described above, this solution achieves comprehensive identification of condition protection mechanisms at the program logic layer and database layer, providing accurate technical basis for subsequent vulnerability assessment.

[0069] S104: Using a large language model and a string matching method, identify the custom permission verification logic on the request entry method. This custom permission verification logic includes permission verification constraints and administrator permission protection measures. The permission verification constraints are implemented through method-level annotations. The string matching method includes matching the permission annotation content with the string comparison of the function method name.

[0070] Furthermore, in the step of using a large language model to identify administrator access control measures, a two-stage prompt word framework is adopted, including:

[0071] In the first phase, the large language model is guided to identify access paths that are only accessible to administrators based on application context and configuration information.

[0072] In the second stage, based on the access path identified in the first stage, the large language model is guided to determine whether the corresponding request entry point has implemented an access control mechanism that restricts access to only administrators.

[0073] Custom constraints are typically implemented through method-level annotation configuration, essentially dynamically triggering pre-defined check logic before the target method executes. While Large Language Models (LLMs) can infer some access control mechanisms based on a given code snippet, the entry method often only contains constraint declarations and lacks specific implementation details. Directly applying LLM analysis may lead to misjudgments due to incomplete context. To address this issue, this embodiment employs a string comparison method that precisely matches annotation content with function / method names, providing supplementary judgment criteria for LLM access control analysis (specific prompt word design is as follows). Figure 5 (As shown).

[0074] Furthermore, as privileged users of the system, administrators typically possess unrestricted operational permissions, requiring developers to implement strict access control policies. Given that the administrator role has distinct identifying characteristics in the code implementation (such as specific naming conventions or annotation markers), LLM can effectively identify and locate relevant security protection code. For example... Figure 6 As shown, this embodiment designs a two-stage prompt word framework: the first stage guides the LLM to identify protected access paths, while the second stage focuses on the permission verification mechanism at the request entry point. This design enables the LLM to intelligently determine the administrator permission protection measures implemented by the system based on the specific business context.

[0075] S105: Based on the aforementioned condition protection mechanism and custom permission verification logic, determine whether the object-level sensitive operation simultaneously satisfies the following conditions: no user-defined permission verification constraints, no SQL condition constraints based on object ownership, and no access control condition restrictions. If so, determine that there is an object-level authorization vulnerability and generate a vulnerability diagnosis report.

[0076] In practice, an object-level authorization vulnerability is determined to exist when the operation interface and request entry point of a sensitive resource simultaneously meet the following three conditions:

[0077] 1. The interface method does not implement user-defined permission verification constraints;

[0078] 2. Database operations lack SQL condition constraints based on object ownership;

[0079] 3. The business logic does not implement the necessary access control restrictions.

[0080] The detection method proposed in this embodiment uses static code analysis technology to traverse and scan the program execution path from the program entry point to the sensitive operation, accurately identifying the aforementioned vulnerability patterns. Specifically, based on the conditional protection mechanism identified in step S103 and the custom permission verification logic inferred in step S104, a comprehensive vulnerability determination is made: the system determines an object-level authorization vulnerability only if an object-level sensitive operation lacks all three of the above protection mechanisms.

[0081] For endpoints identified as vulnerable, the system automatically generates a detailed vulnerability diagnostic report. This report includes the vulnerability location, vulnerability type, missing protection mechanism type, and related code path information, providing developers with a complete basis for remediation. This multi-condition verification mechanism ensures the accuracy and reliability of vulnerability detection results, effectively reducing the probability of false positives and false negatives.

[0082] In the experimental analysis of the method provided in this embodiment, 10 open-source Java Web applications were selected as the test set, including 5 projects on GitHub that were marked with known vulnerabilities and 5 projects that had not publicly reported BOLA vulnerabilities; the experimental results are as follows. Figures 7-8 As shown.

[0083] Figure 7 The detection results of the method described in this embodiment for known vulnerabilities are presented, with the second column listing the number of reported vulnerabilities for each project. Detection effectiveness is evaluated using recall (True Positive, TP), false positives (False Positive, FP), and false negatives (False Negative, FN). Experimental results show that the method provided in this embodiment achieves an overall recall rate of 94.44% across five projects, with one false negative and one false positive, both occurring in the constructed test project Hello-Java-Sec. The false negative in this project stemmed from the vulnerability not involving database operations, causing the model to fail to recognize it; the false positive occurred because this project treated direct UUID queries as a secure operation, a flagging behavior that does not comply with existing security guidelines.

[0084] Figure 8This document presents all the detection results of the method described in this embodiment. By manually constructing attack requests to verify the authenticity of vulnerabilities, it was confirmed that a total of 88 results were reported across 10 projects, of which 69 were genuine vulnerabilities (including 52 newly discovered vulnerabilities). There were 19 false positives (a false positive rate of 21.59%), distributed across 4 projects. Apart from Hello-Java-Sec, which has already been discussed, the remaining false positives all stemmed from issues with the identification of custom constraints, including LLM's misunderstanding of permission protection mechanisms and LLM's inability to statically interpret permissions hidden within database content. Existing methods do not consider these custom permission constraints. Existing static detection methods also cannot handle this situation.

[0085] Furthermore, this embodiment also conducted a comparative experiment with the existing method MACE on the same test set. The results showed that MACE only reported 16 results, of which 7 were correct and 9 were false positives. Regarding false positives, MACE-JAVA only identifies resource protection mechanisms through cross-validation and cannot parse custom permission check logic. MACE's failure to detect false positives compared to this embodiment is due to MACE's inability to infer sensitive resource tables; specifically, there is a lack of explicit data flow association between INSERT statements and users. These experimental results demonstrate that the method provided in this embodiment can achieve more accurate object-level vulnerability detection in Java Web applications compared to traditional static detection methods using heuristic rules.

[0086] Figure 2 This invention illustrates an automated detection system 100 for object-level authorization vulnerabilities based on a large language model, comprising an object-level sensitive operation inference module 10 and an object-level authorization vulnerability detection module 20, wherein:

[0087] The object-level sensitive operation inference module 10 is used to: based on SQL syntax analysis, identify sensitive resource tables associated with user tables from SQL files, wherein the sensitive resource tables store data that are subordinate to users; through forward data flow analysis, trace the propagation path of parameters from the request entry point to the sensitive resource tables, detect and identify database operation statements that reach the sensitive resource tables; and use a large language model to perform context-aware analysis on the database operation statements to infer whether they are object-level sensitive operations that require object-level permission protection.

[0088] The object-level authorization vulnerability detection module 20 is used to: identify the condition protection mechanism along the path from the program entry point to the object-level sensitive operation using static analysis technology; the condition protection mechanism includes condition judgments in the program logic and condition constraints in the database query; identify the custom permission verification logic on the request entry method using a large language model combined with string matching methods; the custom permission verification logic includes permission verification constraints and administrator permission protection measures; the permission verification constraints are implemented through method-level annotations; and determine whether the object-level sensitive operation simultaneously satisfies the following conditions: no user-defined permission verification constraints, no SQL condition constraints based on object ownership, and no access control condition restrictions. If so, an object-level authorization vulnerability is determined to exist, and a vulnerability diagnosis report is generated.

[0089] See Figure 3 This embodiment uses two core modules to implement the method described in the above embodiment, wherein:

[0090] In the object-level sensitive operation inference phase, a segmented analysis method based on keyword matching is first used to accurately identify the sensitive resource tables that need to be protected from the project's SQL file. Then, static analysis technology is used to trace the sensitive resource table operations that can be reached by the request entry parameters. Finally, combined with the project description document, the powerful semantic understanding capabilities of LLM are used to perform context-aware analysis on the operations of each resource table to accurately determine whether they constitute object-level sensitive operations in the current business scenario.

[0091] In the vulnerability detection phase, static analysis is first used to comprehensively collect various protection mechanisms from the program entry point to the sensitive operation path, including security measures such as conditional statements, SQL constraints, and custom permission verification logic. Then, based on the static analysis results, the system systematically verifies whether there are missing or insufficient protection mechanisms in sensitive operations, thereby effectively identifying potential object-level authorization vulnerabilities. This method achieves accurate detection of object-level authorization vulnerabilities in Java Web applications through multi-layered analysis and verification.

[0092] The specific implementation and operation process of each module in the system 100 described in this embodiment can be understood by referring to the relevant descriptions in the foregoing method embodiments, and all of them can achieve the functions and effects achieved by the corresponding method steps. For the sake of simplicity and to avoid repetition, they will not be described again here.

[0093] This invention also provides a storage medium for storing a computer program for executing the above-described automated detection method for object-level authorization vulnerabilities based on a large language model. For example, computer program instructions, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. The program instructions for invoking the methods of this application may be stored in a fixed or removable storage medium, and / or transmitted via data streams in broadcast or other signal carrying media, and / or stored in the storage medium of a computer device operating according to the program instructions. Here, in one embodiment according to this application, it includes a... Figure 9 The computer device 400 shown preferably includes a memory 200 for storing computer programs and a processor 300 for executing computer programs. When the computer program is executed by the processor 300, the computer device 400 is triggered to execute the methods and / or technical solutions based on the foregoing embodiments.

[0094] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0095] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of the present invention is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0096] Of course, the present invention may have other various embodiments. Without departing from the spirit and essence of the present invention, those skilled in the art can make various corresponding changes and modifications according to the present invention, but these corresponding changes and modifications should all fall within the protection scope of the appended claims.

Claims

1. An automated detection method for object-level authorization vulnerabilities based on a large language model, characterized in that, Including the following steps: Based on SQL syntax analysis, sensitive resource tables associated with user tables are identified from SQL files. These sensitive resource tables store data that are subordinate to users. By analyzing the forward data flow, the propagation path of parameters from the request entry point to the sensitive resource table is traced, and the database operation statements that reach the sensitive resource table are detected and identified. Furthermore, by utilizing a large language model, context-aware analysis is performed on the database operation statements to infer whether they are object-level sensitive operations that require object-level permission protection. Static analysis techniques are used to identify condition protection mechanisms along the path from the program entry point to the object-level sensitive operation. These condition protection mechanisms include condition judgments in the program logic and condition constraints in the database query. By using a large language model and combining it with string matching methods, custom permission verification logic on the request entry method is identified. The custom permission verification logic includes permission verification constraints and administrator permission protection measures. The permission verification constraints are implemented through method-level annotations. Based on the condition protection mechanism and the custom permission verification logic, determine whether the object-level sensitive operation simultaneously satisfies the following conditions: no user-defined permission verification constraints, no SQL condition constraints based on object ownership, and no access control condition restrictions. If so, determine that there is an object-level authorization vulnerability and generate a vulnerability diagnosis report.

2. The method according to claim 1, characterized in that, The process of identifying sensitive resource tables associated with the user table from the SQL file based on SQL syntax analysis includes: A thesaurus is constructed based on the pre-defined user table and field keywords generated by the large language model, and a keyword matching strategy is used to identify the user table in the SQL file; By analyzing explicit foreign key constraints or implicit semantic relationships, tables that are directly or indirectly related to the user table are located and used as sensitive resource tables for storing user resources.

3. The method according to claim 2, characterized in that, The keyword matching strategy for identifying user tables in SQL files includes: Parse the SQL file to extract all CREATE TABLE statements; The table name and field name are matched against the dictionary using case-insensitive and delimiter variant matching methods to identify the user table.

4. The method according to claim 1, characterized in that, In the step of identifying the condition protection mechanism, the identification of condition judgments in the program logic includes: Extract all conditional statements along the path from the request entry point to the database operation; Backward analysis is performed on each condition variable to verify whether it meets the predetermined data characteristic conditions. If it does, it is determined to be a valid object-level permission check. The data characteristic conditions include: one parameter of the condition variable depends on an uncontrollable input parameter, another parameter depends on the current user, and one of the parameters originates from a database query operation.

5. The method according to claim 1, characterized in that, In the step of identifying the condition protection mechanism, the identification of condition constraints in the database query includes: Perform a backward analysis on the object-level sensitive operation to determine whether the variables of the object-level sensitive operation depend on the current user variables; if so, determine that the object-level sensitive operation is protected by SQL condition constraints based on object ownership.

6. The method according to claim 1, characterized in that, The string matching method includes matching the content of permission annotations with the string comparison of function method names.

7. The method according to claim 1, characterized in that, In the step of identifying administrator privilege protection measures using a large language model, a two-stage prompt word framework is adopted, including: In the first phase, the large language model is guided to identify access paths that are only accessible to administrators based on application context and configuration information. In the second stage, based on the access path identified in the first stage, the large language model is guided to determine whether the corresponding request entry point has implemented an access control mechanism that restricts access to only administrators.

8. An automated detection system for object-level authorization vulnerabilities based on a large language model, characterized in that, It includes an object-level sensitive operation inference module and an object-level authorization vulnerability detection module, wherein: The object-level sensitive operation inference module is used for: Based on SQL syntax analysis, sensitive resource tables associated with user tables are identified from SQL files. These sensitive resource tables store data that are subordinate to users. By analyzing the forward data flow, the propagation path of parameters from the request entry point to the sensitive resource table is traced, and the database operation statements that reach the sensitive resource table are detected and identified. Furthermore, using a large language model, the database operation statements are analyzed for context awareness to infer whether they are object-level sensitive operations that require object-level permission protection. The object-level authorization vulnerability detection module is used for: Static analysis techniques are used to identify condition protection mechanisms along the path from the program entry point to the object-level sensitive operation. These condition protection mechanisms include condition judgments in the program logic and condition constraints in the database query. By using a large language model and combining it with string matching methods, custom permission verification logic on the request entry method is identified. The custom permission verification logic includes permission verification constraints and administrator permission protection measures. The permission verification constraints are implemented through method-level annotations. Based on the condition protection mechanism and the custom permission verification logic, determine whether the object-level sensitive operation simultaneously satisfies the following conditions: no user-defined permission verification constraints, no SQL condition constraints based on object ownership, and no access control condition restrictions. If so, determine that there is an object-level authorization vulnerability and generate a vulnerability diagnosis report.

9. A storage medium, characterized in that, Used to store a computer program for executing the automated detection method for object-level authorization vulnerabilities based on any one of claims 1 to 7.

10. A computer device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the automated detection method for object-level authorization vulnerabilities based on a large language model as described in any one of claims 1 to 7.

Images