Method and medium for detecting business logic vulnerabilities based on large models

Abstract

The application discloses a large model-based business logic vulnerability detection method and medium. It includes: screening high-risk interfaces to be detected; extracting the code fragments of the Controller layer, the Service layer and the DAO layer corresponding to the high-risk interfaces by recursively tracking the method call link to build a business logic code context; inputting the business logic code context into a large language model to perform authentication logic analysis on the business logic code context and output a determination result; when the determination result is that there is a missing function, automatically positioning the code position of the missing function, extracting the complete code of the missing function as a supplementary context, and inputting the supplementary context and the business logic code context into the large language model again for authentication logic analysis until the large language model outputs a deterministic determination result; and generating a structured detection result according to the deterministic determination result. The application can improve the accuracy and coverage of business logic vulnerability detection.

Description

Technical Field

[0001] This application relates to the field of network security technology, particularly to the field of access control vulnerability detection technology in web application security, and specifically to a method, device, system, medium, and product for detecting business logic vulnerabilities based on a large model. Background Technology

[0002] Business logic vulnerabilities are a common security risk in web applications. Essentially, they arise from the application's failure to adequately validate the validity, legality, or ownership of business operations when processing user requests. This allows attackers to manipulate request parameters, bypass business workflows, or abuse normal functions to gain unauthorized data access or manipulation. In enterprise applications, business logic vulnerabilities often directly lead to sensitive data leaks, user privacy violations, and even financial losses, making them a high-risk type. With the advancement of enterprise digital transformation, the volume of user data and transactions handled by business systems is growing rapidly. The accuracy and coverage of business logic detection directly impact an enterprise's compliant operations and user trust. Therefore, developing efficient and intelligent business logic detection solutions is of significant practical importance.

[0003] In related technologies, traditional business logic detection techniques mainly rely on Static Application Security Testing (SAST) tools and manual penetration testing. SAST tools typically use rule engines based on regular expression matching or Abstract Syntax Tree (AST) to scan source code using a pre-defined vulnerability pattern library, attempting to discover potential business logic flaws. However, this rule-driven approach is essentially a mechanical matching of code structure and cannot understand the underlying business logic semantics. On the other hand, while manual penetration testing can leverage the tester's experience to some extent to reason about business logic, it is inefficient, costly, and limited by the tester's subjective cognitive boundaries, making it difficult to cover all possible business branches and abnormal paths. Especially when facing complex business flows, deeply nested permission checks, or non-explicit correlation checks, traditional manual testing methods fall short.

[0004] In summary, the accuracy, coverage, and automation of existing business logic vulnerability detection solutions fall short of practical requirements. Therefore, improving the accuracy and coverage of business logic vulnerability detection is a pressing issue that needs to be addressed in this field. Summary of the Invention

[0005] In view of this, embodiments of this application provide a business logic vulnerability detection method, device, system, medium, and product based on a large model, which can solve at least one of the above-mentioned technical problems.

[0006] In a first aspect, embodiments of this application provide a business logic vulnerability detection method based on a large model. The method includes: extracting API routing paths through static analysis of the target application's source code files, and filtering out high-risk interfaces to be detected from the API routing paths; for each high-risk interface, recursively tracing the method call chain to extract code fragments from the Controller, Service, and DAO layers corresponding to the high-risk interface, constructing a complete business logic code context; inputting the business logic code context into a large language model, and using pre-configured security audit prompts to guide the large language model to perform authentication logic analysis on the business logic code context, outputting a judgment result, wherein the judgment result includes whether a vulnerability exists, whether a vulnerability does not exist, or whether a missing function exists; when the judgment result indicates a missing function exists, automatically locating the code position of the missing function, extracting the complete code of the missing function as a supplementary context, and inputting the supplementary context and the business logic code context together into the large language model for another authentication logic analysis, until the large language model outputs a deterministic judgment result indicating whether a vulnerability exists or does not exist; generating a structured detection result containing vulnerability type, risk level, and remediation suggestion fields based on the deterministic judgment result.

[0007] Secondly, embodiments of this application provide a business logic vulnerability detection device based on a large model. The system includes: a filtering module, used to extract API routing paths through static analysis of the source code files of a target application, and to filter out high-risk interfaces to be detected from the API routing paths; a construction module, used to extract code fragments of the Controller layer, Service layer, and DAO layer corresponding to each high-risk interface by recursively tracing the method call chain, and to construct a complete business logic code context; and an authentication analysis module, used to input the business logic code context into a large language model and guide the user using pre-configured security audit prompts. The large language model performs authentication logic analysis on the business logic code context and outputs a judgment result, which includes whether a vulnerability exists, whether a vulnerability does not exist, or whether a missing function exists. The authentication analysis module is also used to automatically locate the code position of the missing function when the judgment result is that a missing function exists, extract the complete code of the missing function as supplementary context, and input the supplementary context and the business logic code context together into the large language model for authentication logic analysis again, until the large language model outputs a deterministic judgment result of whether a vulnerability exists or does not exist. The generation module is used to generate a structured detection result containing vulnerability type field, risk level field, and remediation suggestion field based on the deterministic judgment result.

[0008] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the steps of the business logic vulnerability detection method based on a large model as described in the first aspect.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the business logic vulnerability detection method based on a large model as described in the first aspect.

[0010] Fifthly, embodiments of this application provide a computer program product, which is stored in a non-volatile storage medium, and when executed by a processor, the computer program product implements the steps of the business logic vulnerability detection method based on a large model as described in the first aspect.

[0011] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the steps of the business logic vulnerability detection method based on a large model as described in the first aspect.

[0012] This application provides a method, device, system, medium, and product for detecting business logic vulnerabilities based on a large-scale model. It enables semantic-level authentication logic analysis based on the complete business logic code context. This business logic code context aggregates code fragments from the Controller, Service, and DAO layers according to their call relationships through recursive tracing of method call chains, avoiding interference from irrelevant code in the large-scale language model's judgment. This allows the large-scale language model to focus on the code structure directly related to the authentication logic, thereby improving the accuracy of understanding complex business logic. Furthermore, when the large-scale language model discovers that a function is called for authentication / verification during analysis, but the complete definition of that function is not in the current context, it automatically locates the missing function, supplements its complete code, and re-inputs it into the large-scale language model for iterative analysis. This allows the large-scale language model to re-verify after obtaining complete authentication-related information, effectively improving the uncertainty of the large-scale language model's output caused by incomplete information and enhancing the authenticity and accuracy of vulnerability determination. This can improve the problem of insufficient detection accuracy and limited coverage caused by the inability of related technologies to understand business logic semantics, enhance the ability to understand the semantics of business logic code, and thus improve detection accuracy and coverage while automating the detection of business logic vulnerabilities. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings of the embodiments of this application will be briefly described below.

[0014] Figure 1 This is a flowchart illustrating a business logic vulnerability detection method based on a large model provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a business logic vulnerability detection device based on a large model provided in an embodiment of this application; Figure 3 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0015] The principles and spirit of this application will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided to make the principles and spirit of this application clearer and more thorough, enabling those skilled in the art to better understand and implement the principles and spirit of this application. The exemplary embodiments provided herein are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments described herein without inventive effort are within the scope of protection of this application.

[0016] In this document, terms such as first, second, and third are used only to distinguish one entity (or operation) from another entity (or operation), and are not intended to require or imply any order or relationship between these entities (or operations).

[0017] Before describing the technical solutions provided in the embodiments of this application, in order to facilitate understanding of the embodiments of this application, this application first specifically explains the problems existing in the related technologies: Currently, business logic testing technology mainly relies on two methods: static application security testing tools and manual penetration testing. Both of these methods have significant limitations in practical applications.

[0018] On the one hand, static application security testing tools operate based on rule engines using regular expression matching or abstract syntax trees. These tools can only identify syntactic features at the code level, such as function call relationships and variable assignment paths, but cannot understand the actual business functionality carried by the code. For example, when two interfaces are used for "querying public information" and "querying personal privacy" respectively, their code structures may be extremely similar, and static tools cannot semantically distinguish the differences in their authentication requirements. Therefore, such tools can only perform mechanical matching through preset static rules, which easily leads to a large number of false positives and false negatives when faced with customized and diverse business logic, resulting in low reliability of the detection results.

[0019] On the other hand, because automated tools cannot understand business logic, enterprises have to rely on senior security engineers for manual penetration testing. However, manual testing is slow, time-consuming, and limited by the testers' energy and experience, making it difficult to achieve full regression testing during rapid version iterations. This manual-dependent model is not only costly but also has limited coverage, easily leading to the omission of some business scenarios.

[0020] Taking horizontal privilege escalation detection as a specific scenario as an example, traditional automated detection methods are more primitive, mainly relying on token replacement or brute-force traversal of resource IDs for verification. For instance, changing the user ID in the request from 1 to 2 might be used to determine if unauthorized access exists. However, when the system uses UUIDs, hash IDs, or performs non-explicit association verification on the backend, the mechanical traversal method immediately fails, causing hidden privilege escalation vulnerabilities to be overlooked. Furthermore, because automated tools cannot understand the business logic of the interface, they cannot determine whether a particular interface is sensitive or whether horizontal privilege escalation detection needs to be performed, further exacerbating the false positive problem.

[0021] In summary, the relevant technologies lack an intelligent business logic detection solution that can understand business logic semantics and has context awareness capabilities, resulting in the accuracy, coverage, and automation of detection failing to meet actual needs.

[0022] In view of the inventors’ above-mentioned research findings, this application provides a business logic vulnerability detection method, device, system, medium and product based on a large model, which aims to solve at least one of the above-mentioned technical problems.

[0023] The following description, in conjunction with the accompanying drawings, details the business logic vulnerability detection method based on a large model provided in this application through specific embodiments and application scenarios.

[0024] Figure 1 This is a flowchart illustrating a business logic vulnerability detection method based on a large model provided in an embodiment of this application. The execution entity of this business logic vulnerability detection method based on a large model can be a business logic vulnerability detection device based on a large model.

[0025] The following example uses a large-model-based business logic vulnerability detection device as the execution subject of the method to illustrate the large-model-based business logic vulnerability detection method of this application. It should be noted that the above-mentioned execution subject and application scenario do not constitute a limitation on this application.

[0026] like Figure 1 As shown, the business logic vulnerability detection method based on a large model provided in this application embodiment may include steps 110-150.

[0027] Step 110: Extract API routing paths by performing static analysis on the source code files of the target application, and filter out high-risk interfaces to be detected from the API routing paths. Step 120: For each high-risk interface, recursively trace the method call chain to extract code snippets from the Controller, Service, and DAO layers corresponding to the high-risk interface, and construct a complete business logic code context. Step 130: Input the business logic code context into the large language model, and use the pre-configured security audit prompt words to guide the large language model to perform authentication logic analysis on the business logic code context and output the judgment result; Step 140: When the determination result is that a missing function exists, the code position of the missing function is automatically located, the complete code of the missing function is extracted as a supplementary context, and the supplementary context and the business logic code context are input together into the big language model for authentication logic analysis again until the big language model outputs a deterministic determination result of whether a vulnerability exists or not. Step 150: Generate a structured detection result containing vulnerability type, risk level, and remediation suggestion fields based on the deterministic judgment result.

[0028] The business logic vulnerability detection method based on a large model provided in this application extracts API routing paths through static analysis of the target application's source code files and focuses the detection scope on high-risk interfaces by filtering, reducing the complexity of subsequent processing. Based on this, by recursively tracing the method call chain, code fragments from the Controller, Service, and DAO layers corresponding to the high-risk interfaces are extracted. This merges the authentication logic, originally scattered across different layers and methods, into a single text block, obtaining a complete business logic code context. This overcomes the limitation of static analysis tools that cannot correlate code fragments across layers, leading to semantic breaks. The business logic code context is input into a large language model, and pre-configured security audit prompts guide the large language model to perform authentication logic analysis. This allows the large language model to identify the presence or absence of authentication logic based on a complete understanding of the business logic, avoiding interference from irrelevant code. This enables the large language model to focus on the code structure directly related to the authentication logic, thereby improving the accuracy of understanding code semantics and complex business logic.

[0029] Meanwhile, when the large language model discovers during analysis that a function is called in the code for authentication / verification, but the complete definition of the function is not in the current context, it automatically locates the missing function, supplements its complete code, and then re-inputs it into the large language model for iterative analysis. This allows the large language model to re-verify after obtaining complete authentication-related information, effectively improving the uncertainty of the large language model's output caused by incomplete information and enhancing the authenticity and accuracy of vulnerability determination.

[0030] In summary, this application effectively improves the understanding of the semantics of business logic code by constructing a complete business logic code context and using a large language model for semantic-level authentication logic analysis, thereby improving the accuracy and coverage of business logic detection.

[0031] The specific implementation of the above steps will be described in detail below with reference to specific embodiments.

[0032] Step 110 involves extracting API routing paths through static analysis of the target application's source code files and filtering out high-risk interfaces to be detected from the API routing paths.

[0033] In step 110, the target application is the web application whose business logic is to be tested, and its source code files can be stored in a local or remote file system; the API routing path can be the interface address exposed by the web application, which is usually composed of HTTP method and URL path, such as GET / api / user / {id} or POST / api / order / create.

[0034] Specifically, without running the target application, the source code files are parsed and scanned to identify all defined API routing paths.

[0035] This application can filter high-risk interfaces from API routing paths based on preset risk rules. These preset risk rules can include conditions to determine whether an API routing path might involve access to sensitive resources. For example, if the URL of an API routing path contains user identifiers or resource identifiers, then that routing path may involve verification of resource ownership and requires close attention. By applying preset risk rules, interfaces most likely to have horizontal privilege escalation vulnerabilities can be filtered from all API routing paths as high-risk interfaces to be detected, thereby narrowing the scope of subsequent analysis.

[0036] For example, if the target application is a backend service of an e-commerce platform, its source code contains multiple Controller classes, each defining several API interfaces. Static analysis of the source code can extract API routing paths such as GET / api / user / profile, POST / api / order / cancel, and GET / api / product / list. Preset risk rules can include: if the URL of an API routing path contains variables appearing as path parameters, it is marked as a high-risk interface. For example, GET / api / user / {userId} / profile contains {userId}, and POST / api / order / {orderId} / cancel contains {orderId}; these two interfaces will be filtered as high-risk interfaces. GET / api / product / list, however, does not contain such parameters and is therefore not considered a high-risk interface.

[0037] According to an embodiment of this application, step 110 above, which extracts API routing paths by performing static analysis on the source code file of the target application and filters out high-risk interfaces to be detected from the API routing paths, may include: performing abstract syntax tree parsing on the source code file of the target application, identifying methods annotated with routing annotations, obtaining the HTTP method and URL path from the parameters of the routing annotations, and generating an API routing path list; for each API routing path in the API routing path list, if the HTTP method corresponding to the API routing path is a CRUD method, and the URL path of the API routing path contains target user identifier parameters and / or target resource identifier parameters, then the API routing path is marked as a high-risk interface.

[0038] Specifically, through abstract syntax tree parsing, all methods annotated with routing annotations in the source code can be identified, and the HTTP method (such as GET, POST) and URL path (such as / api / user / {userId}) can be extracted from the annotation parameters, thereby generating a list of API route paths. Routing annotations can include annotations used in the Java Spring framework or other web frameworks to mark the mapping relationship between HTTP request handling methods and URL paths, such as @GetMapping, @PostMapping, and @RequestMapping. If the HTTP method is any one of GET, POST, PUT, or DELETE, it is confirmed to be a CRUD (Create, Read, Update, Delete) method.

[0039] The target user identifier parameter can be a path segment in the URL path marked with a path parameter placeholder and whose parameter name contains any of the keywords user, userId, account, or member. The target resource identifier parameter is a path segment in the URL path marked with a path parameter placeholder and whose parameter name contains any of the keywords id, resourceId, or docId. Path parameter placeholders are the syntax used in web frameworks to represent dynamic path segments, such as {userId} in the Spring framework.

[0040] In a specific example, if the following API routing path is obtained through abstract syntax tree parsing: GET / api / user / {userId} / profile, its HTTP method is GET, the URL path contains a path parameter placeholder in the form of {userId}, and the parameter name is userId, which belongs to the target user identification parameter, therefore this API routing path is marked as a high-risk interface; POST / api / order / {orderId} / cancel, the HTTP method is POST, the URL path contains {orderId}, and the parameter name is orderId, which does not belong to the target user identification parameter or the target resource identification parameter (orderId does not contain the keywords id, resourceId, or docId), therefore it is not marked as a high-risk interface.

[0041] In the implementation of this application, it is possible to automatically and accurately filter out the high-risk interfaces most likely to involve resource ownership verification from a large number of API routing paths, focusing the scope of subsequent analysis on the interfaces that truly require authentication logic checks, thus narrowing the scope of subsequent analysis and avoiding the waste of computing resources and interference from irrelevant interfaces caused by full interface analysis, thereby improving the targeting and efficiency of detection.

[0042] According to an embodiment of this application, before step 110, which extracts API routing paths by performing static analysis on the source code files of the target application, the method may further include: obtaining the commit records of the version management system of the target application; determining the source code files that have changed relative to the last detection based on the commit records; determining the call chains affected by the changed source code files by recursively tracing the method call chains; and performing static analysis, recursively tracing the method call chains, inputting the data into a large language model, and generating structured detection results only on the changed source code files and the source code files involved in the affected call chains.

[0043] In this embodiment of the application, during CI / CD pipeline integration, only incremental code scanning is supported. Specifically, by comparing Git commit records, AI analysis is performed only on the changed code files and their affected call chains, rather than performing a full scan every time. This reduces the time taken for a single scan from hours to minutes, enabling real-time security feedback during the development process.

[0044] Step 120 involves recursively tracing the method call chain for each high-risk interface, extracting code snippets from the Controller, Service, and DAO layers corresponding to the high-risk interface, and constructing a complete business logic code context.

[0045] In step 120, the method call chain can start from the Controller method corresponding to the high-risk interface, and after multiple method calls, finally reach the complete call path of the database operation method. The Controller layer is used to receive and process HTTP requests, the Service layer is used to encapsulate business logic, and the DAO layer is used to interact with the database. Recursive tracing can include the following steps: starting from the Controller method, searching for the methods it calls layer by layer, and continuing to perform the same search operation for each method found, until the DAO layer is reached.

[0046] The code snippet can be the complete method body code extracted from the source code and corresponding to the methods at each layer of the method call chain. Combine the code snippets of the Controller, Service and DAO layers corresponding to the high-risk interface to obtain the business logic code context. This business logic code context contains complete business logic code information from receiving a request to executing database operations, so that subsequent analysis can be based on complete code semantics.

[0047] For example, for the high-risk interface GET / api / user / {userId} / profile selected in step 110, its corresponding Controller method is UserController.getProfile(), which internally calls UserService.getUserProfile(), which in turn calls UserDao.selectById(). Through recursive tracing, the complete method body code of UserController.getProfile(), UserService.getUserProfile(), and UserDao.selectById() can be extracted and combined to obtain the business logic code context corresponding to this high-risk interface.

[0048] According to the embodiments of this application, step 120 above, by recursively tracing the method call chain and extracting code fragments of the Controller, Service, and DAO layers corresponding to the high-risk interface, may include: taking the Controller method corresponding to the high-risk interface as the entry point, traversing all method call expressions within the method, and for each method call expression, searching for the corresponding target method definition in the project's class dependency graph based on its method name and parameter type; if the found target method definition is located under the Service layer package name, then the target method is determined as the next-level calling method, and the traversal and search steps are repeated using the target method as the new entry point until the preset maximum recursion depth is reached or no subsequent target method definition belonging to the Service layer is found; for the DAO layer method finally reached, its complete SQL statement or database operation code is extracted, and the complete method body code of the Controller layer method, the complete method body code of the intermediate Service layer methods, and the complete method body code of the DAO layer method are determined as independent code fragments.

[0049] The class dependency graph is a graphical representation of the calling relationships between classes in the project, used to record the other class methods called by each method. Through the above recursive tracing, we can start from the starting method, search for the called methods layer by layer, and repeat the same search operation for each called method until the termination condition is met.

[0050] For example, the Controller method corresponding to the high-risk interface GET / api / user / {userId} / profile is UserController.getProfile(), which internally calls UserService.getUserProfile(), which in turn calls UserDao.selectById(). Through recursive tracing in this application, the definition of UserService.getUserProfile() is first found in the class dependency graph. It is located under the Service layer package name and is thus used as the next-level calling method. Using this method as the entry point, the traversal continues until the definition of UserDao.selectById() is found, confirming that it is under the DAO layer package name, and the search stops there. The complete method body code of UserController.getProfile(), UserService.getUserProfile(), and UserDao.selectById() is extracted and treated as three independent code snippets.

[0051] Through the embodiments of this application, the complete call chain from the Controller layer to the DAO layer can be automatically and completely traced, ensuring that no authentication logic code that may exist in any layer is missed. This improves the semantic breakage problem caused by the inability of traditional static analysis tools to associate code fragments across layers, and provides accurate and comprehensive materials for the subsequent construction of code context containing complete business logic.

[0052] According to an embodiment of this application, the construction of a complete business logic code context in step 120 above may include: concatenating the complete method body code of the Controller layer method, the intermediate Service layer methods at each level, and the DAO layer method in the order of invocation, and adding comment lines before each code fragment; and determining the continuous code text block generated after concatenation as the business logic code context.

[0053] The comment line content can include the fully qualified class name and method signature of the method to which the code snippet belongs. The fully qualified class name can be the fully qualified class name including the package name, such as com.example.controller.UserController, and the method signature can be the method name and a list of parameter types, such as getProfile(Long userId).

[0054] For example, the three extracted code snippets are: the code of the Controller method UserController.getProfile(), the code of the Service method UserService.getUserProfile(), and the code of the DAO method UserDao.selectById().

[0055] Following the call order, first concatenate the Controller method code, adding a comment line before it: / / com.example.controller.UserController.getProfile(Long userId); then concatenate the Service method code, adding a comment line before it: / / com.example.service.UserService.getUserProfile(Long userId); finally, concatenate the DAO method code, adding a comment line before it: / / com.example.dao.UserDao.selectById(Long userId). The resulting continuous block of code text constitutes the business logic code context.

[0056] This application embodiment adds comment lines before code snippets, enabling the large language model to clearly identify the source level and method of each code snippet when receiving the business logic code context. This allows for a more accurate understanding of the code's organizational structure and calling relationships, avoiding semantic confusion caused by disordered code snippets, and ultimately improving the accuracy of subsequent authentication logic analysis.

[0057] In step 130, the business logic code context is input into the large language model, and the pre-configured security audit prompts are used to guide the large language model to perform authentication logic analysis on the business logic code context and output the judgment result.

[0058] In step 130, the security audit prompt can be a pre-written instruction text used to guide the large language model to focus on specific security elements when performing analysis tasks, such as user identity verification logic, resource ownership verification logic, or permission judgment logic; the authentication logic analysis can be the large language model determining, based on the input code context, whether it contains code logic used to verify whether the current user has the right to access the requested resource.

[0059] The judgment result can include three situations: a vulnerability exists, indicating that the code context lacks the necessary authentication logic; no vulnerability exists, indicating that the code context contains complete authentication logic; a missing function exists, indicating that although the code context does not directly contain authentication logic, it calls a function to complete authentication, and the definition of that function is not in the current code context.

[0060] In a specific example, security audit prompts could include the following instructions: Please analyze the following code to see if it contains logic for user authentication or resource ownership verification. Before outputting the final conclusion, please first generate the reasoning process, which should be checked step by step according to the following steps: The first step is to check if there is any token verification or session verification logic in the code; The second step is to check if there is any logic in the code to verify the ownership of the resource ID and the current user's identity; The third step is to check if there is any logic in the code that controls the return of data based on the validation result.

[0061] After completing the above reasoning process, the judgment result is output. If authentication logic exists, the output "No vulnerability" is output; if authentication logic does not exist, the output "Vulnerability exists" is output; if the code calls an external function to perform the verification but the function is not provided, the output "Missing function exists" is output.

[0062] Based on this, the large language model analyzes the context of the input code, first generating a step-by-step reasoning process, and then outputting the corresponding judgment result.

[0063] In this way, the analysis process of the large language model is no longer an invisible internal operation, but is presented in the form of readable reasoning steps, which facilitates the subsequent review and verification of the analysis conclusions.

[0064] According to embodiments of this application, the aforementioned security audit prompts may include at least the following components: system role setting text, used to instruct the large language model to act as a security code analysis expert with preset security knowledge, wherein the preset security knowledge includes at least the vulnerability types and protection logic involved in Web application security risks; task description text, used to instruct the large language model to analyze whether user identity verification logic, resource ownership verification logic, or permission judgment logic exists in the model input text, and to require the output judgment result; output format constraint text, used to instruct the large language model to output in JSON structure, wherein the JSON structure includes result, reason, and missing_function; and example text, used to provide at least one set of input and output examples for the large language model to learn the expected output format.

[0065] The common security risks in web applications involve vulnerability types such as horizontal privilege escalation, vertical privilege escalation, and SQL injection, while the protection logic includes at least authentication, permission verification, and data filtering. The task description text clearly informs the large language model of the specific analysis task to be performed. The `result` value can be either "vulnerability exists," "vulnerability does not exist," or "missing function exists"; the `reason` value can be a string explaining the situation; and the `missing_function` value can be a string representing the name of a missing function or an empty string.

[0066] In a specific example, security audit prompts can be constructed as follows: The system role setting text is "You are a code auditing expert with extensive knowledge of web security, familiar with the principles and defense measures of various vulnerabilities in the OWASP Top Ten." The task description text is "Please analyze whether the following code contains user authentication logic, resource ownership authentication logic, or permission judgment logic. If it exists, output 'No vulnerability exists'; if it does not exist, output 'Vulnerability exists'; if the code calls an external function to perform the verification but the function is not provided, output 'Missing function exists'." The output format constraint text is "Please output in JSON format, with the format: {"result": "Vulnerability exists / Vulnerability does not exist / Missing function exists", "reason": "Analysis reason", "missing_function": "Function name or empty string"}". The example text can provide a set of samples, such as inputting a piece of code containing authentication logic, expecting the output {"result": "Vulnerability does not exist", "reason": "The code verified the user ID through the checkUserOwnership function", "missing_function": ""}.

[0067] In this embodiment of the application, by designing the above-mentioned prompt words, the large language model has a clear task orientation and output specifications when performing authentication logic analysis. It not only improves the model's analytical capabilities through role setting and the injection of professional knowledge, but also ensures the structured and parsable nature of the output results through format constraints and sample guidance, thereby improving the stability of the analysis process and the usability of the output results.

[0068] In step 140, when the determination result is that a missing function exists, the code location of the missing function is automatically located, the complete code of the missing function is extracted as a supplementary context, and the supplementary context and the business logic code context are input together into the large language model for authentication logic analysis again, until the large language model outputs a deterministic determination result of whether a vulnerability exists or not.

[0069] In step 140, the missing function can be a function identified by the large language model in step 130 that has been called but does not have a complete definition in the current business logic code context.

[0070] Specifically, by parsing the output of the large language model, the name of the missing function is obtained, the definition of the function is found in the source code file of the target application, and the code location of the missing function is determined; the complete code of the function is read from the source code file, and this complete code is used as a supplementary context, which is input into the large language model together with the business logic code context.

[0071] In this way, the large language model can simultaneously see the original code context and the complete definition of the missing function during the second analysis, thus determining whether the missing function contains the necessary authentication logic. If the result of the second analysis still indicates the presence of a missing function, the steps of locating, extracting, and re-analyzing are repeated until the large language model can give a definitive conclusion as to whether a vulnerability exists or not.

[0072] For example, if the large language model outputs a judgment result indicating the existence of a missing function, and specifies that the missing function is named checkUserOwnership, the system automatically searches for the function named checkUserOwnership in the source code file of the target application. After finding its definition location, it extracts the complete code of the function, for example: private boolean checkUserOwnership(Long userId, Long currentUserId) { return userId.equals(currentUserId); } The complete code of this function is used as supplementary context and input together with the business logic code context from step 120 into the large language model. After further analysis, the large language model identifies that the checkUserOwnership function contains user ID comparison logic, thus determining that the interface has authentication logic and outputting that there is no vulnerability. Conversely, if the checkUserOwnership function is empty or only returns true, the large language model will determine that the interface has a vulnerability.

[0073] According to an embodiment of this application, the automatic location of the missing function code in step 140 above may include: parsing the missing_function field in the judgment result output by the large language model to obtain the name of the missing function; querying the global symbol table of the source code file of the target application for a function definition node that matches the name of the missing function; if the query is successful, determining the file name and starting line number corresponding to the function definition node as the code location of the missing function; if the query fails, continuing to search in each external dependency library based on the target retrieval method until a function definition information matching the name of the missing function is found or the retrieval of each external dependency library is completed.

[0074] The global symbol table is an index structure used to store all function definition information in the project. External dependency libraries can be third-party libraries or modules referenced by the project, usually existing in the form of JAR files. Therefore, the target retrieval method is to decompress the JAR file, scan the .class files inside, and decompile to extract function definition information.

[0075] For example, the value of the `missing_function` field in the judgment result output by the large language model is "checkUserOwnership". The system first searches for a function named "checkUserOwnership" in the global symbol table. If the function is defined in the project source code, for example, on line 45 of the file UserService.java, its file name and starting line number are recorded as the code location of the missing function; if it is not found in the global symbol table, it iterates through all external dependency libraries that the project depends on, such as common-utils.jar, decompresses and scans the class files within them, and searches for the existence of a function named checkUserOwnership; if found, the path of its JAR file and function definition information are recorded; if it is not found in any external dependency library, the search is complete, and the missing function cannot be located.

[0076] In this embodiment, a two-level retrieval mechanism using a global symbol table and external dependency libraries covers both functions defined within the project itself and functions in third-party libraries. This allows for accurate location of missing functions in the source code or dependency libraries, avoiding location failures caused by functions being defined in external dependencies. It provides accurate location information for extracting the complete code of missing functions and ensures the smooth execution of subsequent iterative analysis processes.

[0077] According to an embodiment of this application, the step 140 above, which extracts the complete code of the missing function, may include: determining the line of code corresponding to the starting line number in the code position of the missing function as the first line of the function definition; based on the nested matching rules of code block delimiters, starting from the first line of the function definition, determining the line containing the ending code block delimiter that matches the first starting code block delimiter in the first line of the function definition as the code block ending line; and determining all lines of code from the first line of the function definition to the code block ending line as the complete code of the missing function.

[0078] Among them, code block delimiters are symbols or keywords used to mark the beginning and end of code blocks, such as curly braces {}, begin / end, etc.; nesting matching rules are methods to determine the scope of a code block by matching the nesting level of the start delimiter and the end delimiter. Specifically, the initial value of the nesting level counter can be set to 1; starting from the first line after the first line of the function definition, scan line by line. For each line scanned, count the number of occurrences of the start code block delimiter and the end code block delimiter in that line; add the current value of the nesting level counter to the number of occurrences of the start code block delimiter in that line, and then subtract the number of occurrences of the end code block delimiter in that line to obtain the updated value of the nesting level counter; when the updated value of the nesting level counter becomes 0, the currently scanned line is determined as the line containing the end code block delimiter.

[0079] For example, if the missing function `checkUserOwnership` starts on line 45, with the code `private boolean checkUserOwnership(Long userId, Long currentUserId) {`, and the first block delimiter in that line is "{", then starting from line 46, we scan line by line, maintaining a nested level counter: incrementing the counter by 1 for each "{" and decrementing it by 1 for each "}". When the counter reaches 0 from its initial value of 1, the current line is the line containing the ending "}" that pairs with the starting "{". Assuming this line is line 50, with the code `}`, then all lines of code from line 45 to line 50 will be extracted as the complete code for the missing function.

[0080] In this embodiment, the nested matching rules of code block delimiters can accurately extract the complete code of functions with arbitrarily complex nested structures. No matter how many levels of nested code blocks or multiple conditional branches are contained in the function body, the boundary of the function body can be correctly identified through the nested matching rules of delimiters, avoiding truncation errors or redundant extraction caused by code block nesting. This ensures that the large language model can obtain complete and accurate missing function code in subsequent iterative analysis, thereby improving the accuracy of the judgment results.

[0081] According to an embodiment of this application, in step 140 above, the supplementary context and the business logic code context are jointly input into the large language model for authentication logic analysis again until the large language model outputs a deterministic judgment result indicating whether a vulnerability exists or not. This may include: iterating based on the obtained preset maximum number of iterations; wherein, before each iteration, the complete code of the missing function in the previous iteration is added to the business logic code context to obtain the updated model input text; if the result field output by the large language model in two consecutive iterations both indicate the presence of a missing function and the missing_function field is exactly the same, then the iteration stops, and the result field in the judgment result output by the last iteration is set to indicate the presence of a vulnerability, and the reason field is updated to indicate that the vulnerability is determined due to the repeated missing function.

[0082] The preset maximum number of iterations is the maximum number of iterations allowed in advance to prevent infinite loops. The model input text is the text content input to the large language model during each iteration.

[0083] For example, if the maximum number of iterations is set to 3. In the first iteration, the complete code of the first missing function is added to the business logic code context and input into the large language model. The output result is that a missing function exists, and the missing_function is "checkUserOwnership". In the second iteration, the complete code of the second missing function is added to the business logic code context and input into the large language model. The output result is still that a missing function exists, and the missing_function is still "checkUserOwnership". At this point, the result and missing_function are exactly the same for two consecutive iterations, so the iteration terminates, and the result in the output result of the second iteration is set to have a vulnerability, and the reason is set to "vulnerable due to repeated missing functions". If the third iteration still does not converge, it will also stop because the maximum number of iterations has been reached.

[0084] Through the embodiments of this application, the analysis of missing functions can be completed step by step within a limited number of iterations. At the same time, the repeated missing function detection mechanism avoids infinite iterations caused by incomplete missing function definitions or circular dependencies. When more effective information cannot be obtained, a reasonable vulnerability judgment conclusion can be given based on existing evidence. Thus, while ensuring the accuracy of the analysis, the analysis time and the consumption of computing resources are controlled, and the practicality and robustness of the business logic detection solution are improved.

[0085] Step 150 involves generating a structured detection result containing vulnerability type, risk level, and remediation suggestion fields based on the deterministic judgment result.

[0086] In step 150, the structured detection result refers to data organized in a predetermined format, containing multiple fields, each carrying specific information. The vulnerability type field identifies the type of vulnerability discovered, such as horizontal or vertical privilege escalation. The risk level field assesses the severity of the vulnerability, such as high, medium, or low; its value is determined by the large language model based on the vulnerability's impact scope, including the range of affected users and the number of categories involving sensitive data. The remediation suggestion field provides code completion suggestions generated by the large language model for missing authentication logic. These suggestions are presented as code snippets with the line number offset of the insertion position, helping developers quickly fix the problem. After generating the structured detection result, it can be output to a user interface, saved to a file, or sent to other systems for subsequent processing and tracking.

[0087] For example, if the final determination is that a vulnerability exists, the generated structured detection result may include the following information: the vulnerability type field is set to "horizontal privilege escalation," the risk level field is set to "high," and the remediation suggestion field is set to "suggest adding a consistency check between the current user ID and the request parameter userId in the UserController.getProfile() method." This structured detection result can be displayed on the security detection platform's report page for security engineers to view and process.

[0088] According to embodiments of this application, the structured detection results may further include an affected code location field. This field records code location information related to the detected vulnerability, facilitating developers to quickly locate problematic code. The field content includes the URL path of the high-risk interface, the Controller method name, the file path and line number of the missing function, and a list of fully qualified class names of methods at each level of the call chain.

[0089] In this embodiment, the structured detection results not only include information such as vulnerability type, risk level, and remediation suggestions, but also provide fine-grained location information from the interface entry point to the missing function definition and then to the complete call chain. After receiving the detection report, developers can directly jump to the problematic code based on the path and line number in the affected code location field, and quickly understand the context of the vulnerability occurrence by combining the list of fully qualified class names of methods at each level in the call chain, thereby shortening the time for vulnerability confirmation and remediation and improving the operability of the detection results.

[0090] Corresponding to the method embodiments of this application, this application also provides a business logic vulnerability detection device based on a large model.

[0091] Figure 2 This is a schematic diagram of the structure of a business logic vulnerability detection device based on a large model provided in an embodiment of this application.Figure 2 As shown, the business logic vulnerability detection device 200 based on a large model may include: a screening module 210, a construction module 220, an authentication analysis module 230, and a generation module 240.

[0092] The filtering module 210 is used to extract API routing paths through static analysis of the target application's source code files and filter out high-risk interfaces to be detected from the API routing paths; the construction module 220 is used to extract code fragments of the Controller, Service, and DAO layers corresponding to each high-risk interface by recursively tracing the method call chain, and construct a complete business logic code context; the authentication analysis module 230 is used to input the business logic code context into the large language model and guide the large language model to process the business logic code context using pre-configured security audit prompts. The authentication logic analysis module 230 performs authentication logic analysis and outputs a judgment result, which includes whether a vulnerability exists, whether a vulnerability does not exist, or whether a function is missing. When the judgment result is that a function is missing, the authentication analysis module 230 automatically locates the code position of the missing function, extracts the complete code of the missing function as supplementary context, and inputs the supplementary context and the business logic code context into the large language model for authentication logic analysis again until the large language model outputs a deterministic judgment result that a vulnerability exists or does not exist. The generation module 240 generates a structured detection result containing vulnerability type field, risk level field, and remediation suggestion field based on the deterministic judgment result.

[0093] In some embodiments, the filtering module is specifically used to: perform abstract syntax tree parsing on the source code file of the target application, identify methods annotated with routing annotations, and obtain the HTTP method and URL path from the parameters of the routing annotations to generate an API routing path list; for each API routing path in the API routing path list, if the HTTP method corresponding to the API routing path is a CRUD method, and the URL path of the API routing path contains a target user identifier parameter and / or a target resource identifier parameter, then the API routing path is marked as a high-risk interface; wherein, the target user identifier parameter is a path segment in the URL path marked with a path parameter placeholder and whose parameter name contains any of the keywords user, userId, account, or member, and the target resource identifier parameter is a path segment in the URL path marked with a path parameter placeholder and whose parameter name contains any of the keywords id, resourceId, or docId.

[0094] In some embodiments, the construction module is specifically used to: take the Controller method corresponding to the high-risk interface as the entry point, traverse all method call expressions inside the method, and for each method call expression, search for the corresponding target method definition in the project's class dependency graph based on its method name and parameter type; if the found target method definition is located under the Service layer package name, then the target method is determined as the next level calling method, and the traversal and search steps are repeated with the target method as the new entry point until the preset maximum recursion depth is reached or no subsequent target method definition belonging to the Service layer is found; for the DAO layer method that is finally reached, extract its complete SQL statement or database operation code, and determine the complete method body code of the Controller layer method, the complete method body code of the intermediate Service layer methods, and the complete method body code of the DAO layer method as independent code segments.

[0095] In some embodiments, the building module is specifically used to: concatenate the complete method body code of the Controller layer method, the intermediate Service layer methods at each level, and the DAO layer method in the order of invocation, and add a comment line before each code fragment, wherein the comment line content includes the fully qualified class name and method signature of the method to which the code fragment belongs; and determine the concatenated continuous code text block as the business logic code context.

[0096] In some embodiments, the security audit prompt includes at least the following components: system role setting text, used to instruct the large language model to act as a security code analysis expert with preset security knowledge, wherein the preset security knowledge includes at least the vulnerability types and protection logic involved in web application security risks; task description text, used to instruct the large language model to analyze whether user identity verification logic, resource ownership verification logic, or permission judgment logic exists in the model input text, and to output the judgment result; output format constraint text, used to instruct the large language model to output in JSON structure, wherein the JSON structure includes result, reason, and missing_function; and example text, used to provide at least one set of input and output examples for the large language model to learn the expected output format.

[0097] In some embodiments, the authentication analysis module is specifically used to: parse the missing_function field in the judgment result output by the large language model to obtain the name of the missing function; query the global symbol table of the source code file of the target application for a function definition node that matches the name of the missing function, wherein the global symbol table contains a hash index constructed by traversing all source files of the project and collecting the name, class, file name and starting line number of each function; if the query is successful, the file name and starting line number corresponding to the function definition node are determined as the code location of the missing function; if the query fails, the search continues in each external dependency library based on the target retrieval method until a function definition information matching the name of the missing function is found or the search of each external dependency library is completed.

[0098] In some embodiments, the authentication analysis module is specifically used to: determine the line of code corresponding to the starting line number in the code location of the missing function as the first line of the function definition; based on the nested matching rules of code block delimiters, starting from the first line of the function definition, determine the line containing the ending code block delimiter that is paired with the first starting code block delimiter in the first line of the function definition as the code block ending line; and determine all lines of code from the first line of the function definition to the code block ending line as the complete code of the missing function.

[0099] In some embodiments, the authentication analysis module is specifically used to: perform iterations based on the obtained preset maximum number of iterations; wherein, before each iteration, the complete code of the missing function in the previous iteration is added to the business logic code context to obtain the updated model input text; if the result field output by the large language model in two consecutive iterations both have missing functions and the missing_function field is exactly the same, then the iteration is stopped, and the result field in the judgment result output by the last iteration is set to have a vulnerability, and the reason field is updated to be judged as a vulnerability due to repeated missing functions.

[0100] In some embodiments, the structured detection results also include an affected code location field, which includes the URL path of the high-risk interface, the Controller method name, the file path and line number of the missing function, and a list of fully qualified class names of methods at each level in the call chain.

[0101] The business logic vulnerability detection device based on a large model provided in this application embodiment can achieve... Figure 1 The various processes implemented in the method embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0102] Figure 3 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.

[0103] likeFigure 3 As shown, the electronic device 300 includes a memory 301, a processor 302, and a computer program stored in the memory 301 and executable on the processor 302.

[0104] In one example, the processor 302 described above may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0105] Memory 301 may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the business logic vulnerability detection method based on a large model according to the embodiments of the first aspect of this application.

[0106] The processor 302 runs a computer program corresponding to the executable program code by reading the executable program code stored in the memory 301, in order to implement the business logic vulnerability detection method based on a large model in the embodiments of the first aspect above.

[0107] In some examples, the electronic device 300 may also include a communication interface 303 and a bus 310. For example, Figure 3 As shown, the memory 301, processor 302, and communication interface 303 are connected through bus 310 and complete communication with each other.

[0108] The communication interface 303 is mainly used to realize communication between various modules, systems, units and / or devices in the embodiments of this application. Input devices and / or output devices can also be connected through the communication interface 303.

[0109] Bus 310 includes hardware, software, or both, that couples components of electronic device 300 together. For example, and not limitingly, bus 310 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 310 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0110] The electronic device provided in this application embodiment is capable of achieving Figure 1 The various processes implemented in the method embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0111] In conjunction with the business logic vulnerability detection method based on a large model in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any step in the above method embodiments. In conjunction with the business logic vulnerability detection method based on a large model in the above embodiments, this application embodiment can provide a computer program product for implementation. This (computer) program product is stored in a non-volatile storage medium, and when executed by at least one processor, it implements any step in the above method embodiments.

[0112] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0113] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0114] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0115] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0116] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or systems. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0117] The foregoing flowcharts and / or block diagrams of methods, systems (systems), and computer program products according to embodiments of this disclosure have described various aspects of the present disclosure. It should be understood that each block in the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing system to produce a machine such that these instructions, executed via the processor of the computer or other programmable data processing system, enable the implementation of the functions / actions specified in one or more blocks of the flowcharts and / or block diagrams. Such a processor may be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions. The above descriptions are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the scope of the technology disclosed in this application, and such modifications or substitutions should be covered within the scope of protection of this application.

Claims

1. A business logic vulnerability detection method based on a large model, characterized in that, include: The API routing paths are extracted by static analysis of the source code files of the target application, and high-risk interfaces to be detected are filtered out from the API routing paths. For each high-risk interface, the method call chain is traced recursively to extract the code snippets of the Controller, Service and DAO layers corresponding to the high-risk interface, and to construct a complete business logic code context. The business logic code context is input into the large language model, and the pre-configured security audit prompts guide the large language model to perform authentication logic analysis on the business logic code context and output the judgment result, wherein the judgment result includes whether there is a vulnerability, whether there is no vulnerability, or whether there is a missing function. When the determination result is that a missing function exists, the code position of the missing function is automatically located, the complete code of the missing function is extracted as a supplementary context, and the supplementary context and the business logic code context are input together into the big language model for authentication logic analysis again until the big language model outputs a deterministic determination result of whether there is a vulnerability or not. Based on the deterministic judgment result, a structured detection result containing vulnerability type field, risk level field, and remediation suggestion field is generated.

2. The method according to claim 1, characterized in that, By performing static analysis on the target application's source code files to extract API routing paths, high-risk interfaces to be detected are identified from these API routing paths, including: The source code file of the target application is parsed using an abstract syntax tree, the methods annotated with route annotations are identified, and the HTTP method and URL path are obtained from the parameters of the route annotations to generate an API route path list. For each API routing path in the API routing path list, if the HTTP method corresponding to the API routing path is a CRUD method, and the URL path of the API routing path contains the target user identifier parameter and / or the target resource identifier parameter, then the API routing path will be marked as a high-risk interface. The target user identifier parameter is a path segment in the URL path marked with a path parameter placeholder and whose parameter name contains any one of the keywords user, userId, account, or member. The target resource identifier parameter is a path segment in the URL path marked with a path parameter placeholder and whose parameter name contains any one of the keywords id, resourceId, or docId.

3. The method according to claim 1, characterized in that, By recursively tracing the method call chain, code snippets from the Controller, Service, and DAO layers corresponding to the high-risk interfaces were extracted, including: Taking the Controller method corresponding to the high-risk interface as the entry point, iterate through all method call expressions inside the method, and for each method call expression, search for the corresponding target method definition in the project's class dependency graph based on its method name and parameter type; If the target method definition is located under the Service layer package name, then the target method is determined as the next level calling method, and the target method is used as the new entry point. The traversal and search steps are repeated until the preset maximum recursion depth is reached or no subsequent target method definition belonging to the Service layer is found. For the DAO layer method that is finally reached, extract its complete SQL statement or database operation code, and identify the complete method body code of the Controller layer method, the complete method body code of the intermediate Service layer methods, and the complete method body code of the DAO layer method as independent code segments.

4. The method according to claim 3, characterized in that, Construct a complete business logic code context, including: Concatenate the complete method body code of the Controller layer method, the intermediate Service layer methods, and the DAO layer methods in the order of their calls, and add a comment line before each code snippet. The comment line includes the fully qualified class name and method signature of the method to which the code snippet belongs. The concatenated continuous code text block is identified as the business logic code context.

5. The method according to claim 1, characterized in that, The security audit prompts must include at least the following components: The system role setting text is used to instruct the large language model to act as a security code analysis expert with preset security knowledge, wherein the preset security knowledge includes at least the vulnerability types and protection logic involved in Web application security risks; The task description text is used to instruct the large language model analysis model whether there is user identity verification logic, resource ownership verification logic, or permission judgment logic in the input text, and requires the output of the judgment result; Output format constraint text, used to instruct the large language model to output in JSON structure, wherein the JSON structure contains result, reason, and missing_function; Example text is provided to offer at least one set of input-output samples for the large language model to learn the expected output format.

6. The method according to claim 1 or 5, characterized in that, Automatically locate the code position of missing functions, including: The missing function name is obtained by parsing the missing_function field in the judgment result output by the large language model; The function definition node matching the missing function name is queried in the global symbol table of the source code file of the target application. The global symbol table contains a hash index constructed by traversing all source files of the project and collecting the name, class, file name and starting line number of each function. If the query is successful, the filename and starting line number corresponding to the function definition node will be used to determine the code location of the missing function; If the query fails, the search continues in each external dependency library based on the target retrieval method until a function definition matching the missing function name is found or the search of each external dependency library is completed.

7. The method according to claim 1, characterized in that, Extract the complete code of the missing function, including: The line of code corresponding to the starting line number in the code location of the missing function is determined as the first line of the function definition; Based on the nested matching rules of code block delimiters, starting from the first line of the function definition, the line containing the ending code block delimiter that matches the first starting code block delimiter in the first line of the function definition is determined as the code block ending line; The complete code of the missing function is determined from the first line of the function definition to the last line of the code block.

8. The method according to claim 1 or 5, characterized in that, The supplementary context and the business logic code context are input together into the large language model for further authentication logic analysis until the large language model outputs a deterministic judgment result indicating whether a vulnerability exists or not, including: Iterate based on the preset maximum number of iterations; Before each iteration, the complete code of the missing function from the previous iteration is added to the business logic code context to obtain the updated model input text; If the result field output by the large language model is identical to the missing function field in two consecutive iterations, then the iteration stops, the result field in the judgment result of the last iteration is set to indicate the presence of a vulnerability, and the reason field is updated to indicate that the vulnerability is due to the duplicate missing function.

9. The method according to claim 1, characterized in that, The structured detection results also include an affected code location field, which includes the URL path of the high-risk interface, the controller method name, the file path and line number of the missing function, and a list of fully qualified class names of methods at each level in the call chain.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the method as described in any one of claims 1-9.

Images