API logic vulnerability processing method and device, electronic equipment and storage medium

Abstract

The invention relates to an API logic vulnerability processing method and device, electronic equipment and a storage medium, and the method comprises the steps: constructing a dynamic API application programming interface asset ledger through analyzing API flow, and recognizing a high-risk API from the API asset ledger based on resource access behavior characteristics; carrying out white-box analysis on the high-risk API, and constructing a main body identity propagation atlas comprising a user identity identifier; a multi-agent collaborative reasoning framework is utilized, a knowledge base is generated in combination with modular retrieval enhancement, logic analysis is conducted on the subject identity propagation atlas, and a structured analysis conclusion is output; and based on the structured analysis conclusion, performing consistency verification and threshold judgment through a confidence coefficient decision model to generate a vulnerability report. By means of the method and device, the problems that in the prior art, API logic vulnerability detection is incomplete in coverage, high in false alarm rate and low in automation degree are solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of API logic vulnerabilities, and in particular to an API logic vulnerability processing method and device, an electronic device, and a storage medium. BACKGROUND

[0002] With the popularity of microservice architecture and front-end and back-end separation mode, application programming interface (API) has become the core of modern applications. However, the abuse of API, especially the logic vulnerability caused by the complexity of business logic, has become a major security threat.

[0003] The existing API testing includes the following schemes: Dynamic application security testing (DAST, black box): by simulating an attacker, using pre-set multiple permission credentials to perform replay attacks on online APIs. This method has the following defects: 1) limited coverage: unable to discover APIs not captured in traffic or declared in documents, with detection blind spots; 2) dependent on manual: high cost of test account configuration and maintenance, and final confirmation of vulnerabilities heavily relies on the experience of security experts, which cannot be scaled; 3) production risk: there is a risk of business interruption in performing aggressive testing on production environments.

[0004] Static application security testing (SAST, white box): by scanning source code to identify potential vulnerabilities. This method has the following defects: 1) high false positive rate: unable to distinguish whether the code is truly active in the production environment, and has weak understanding of business logic, resulting in a large number of invalid alarms; 2) logic insensitive: for context-dependent business logic vulnerabilities such as "missing authentication logic", existing SAST based on "taint analysis" is difficult to effectively identify.

[0005] Interactive application security testing (IAST): combining DAST and SAST, through instrumentation technology to monitor runtime data flow. This method has the following defects: although it can improve accuracy, it has an invasive impact on application performance, and also requires effective attack traffic to trigger detection, and does not completely solve the problem of discovering logic vulnerabilities.

[0006] As can be seen, the existing technology has the problems of incomplete coverage of API logic vulnerability detection, high false positive rate, and low automation level. SUMMARY

[0007] The present application provides an API logic vulnerability processing method and device, an electronic device, and a storage medium to solve the problem of incomplete coverage of API logic vulnerability detection, high false positive rate, and low automation level in the prior art.

[0008] In a first aspect, the application provides a method for processing API logic vulnerabilities, comprising: constructing a dynamic API application programming interface asset account book by analyzing API traffic, and identifying high-risk APIs from the API asset account book based on resource access behavior characteristics; performing white-box analysis on the high-risk APIs to construct a subject identity propagation graph including user identity identification; performing logic analysis on the subject identity propagation graph by using a multi-agent collaborative reasoning architecture, combining modular retrieval enhancement to generate a knowledge base, and outputting a structured analysis conclusion; and generating a vulnerability report based on the structured analysis conclusion, performing consistency verification and threshold judgment by a confidence decision model.

[0009] In a second aspect, the application provides an API logic vulnerability identification device, comprising: a first processing module configured to construct a dynamic API application programming interface asset account book by analyzing API traffic, and identify high-risk APIs from the API asset account book based on resource access behavior characteristics; a second processing module configured to perform white-box analysis on the high-risk APIs to construct a subject identity propagation graph including user identity identification; a third processing module configured to perform logic analysis on the subject identity propagation graph by using a multi-agent collaborative reasoning architecture, combining modular retrieval enhancement to generate a knowledge base, and outputting a structured analysis conclusion; and a fourth processing module configured to generate a vulnerability report based on the structured analysis conclusion, performing consistency verification and threshold judgment by a confidence decision model.

[0010] In a third aspect, the application provides an electronic device, comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus, wherein the processor is configured to execute the API logic vulnerability identification method of the first aspect of the application.

[0011] In a fourth aspect, the application further provides a computer storage medium storing computer executable instructions for executing the API logic vulnerability processing method of the first aspect of the application.

[0012] Compared with the prior art, the technical solution provided in the embodiments of the present application has the following advantages: the method provided in the embodiments of the present application first analyzes API traffic, constructs a dynamic API application programming interface asset ledger, identifies high-risk APIs from the API asset ledger based on resource access behavior characteristics, and performs white-box analysis on the high-risk APIs to construct a subject identity propagation graph including user identity identifiers; then, a multi-agent collaborative reasoning architecture is used, a knowledge base is generated by combining modular retrieval enhancement, logical analysis is performed on the subject identity propagation graph, a structured analysis conclusion is output, and based on the structured analysis conclusion, consistency verification and threshold judgment are performed through a confidence decision model to generate a vulnerability report. As can be seen, in the embodiments of the present application, high-risk APIs can be actively and accurately identified, and then corresponding subject identity propagation graphs are constructed by analyzing them, and finally logical vulnerabilities can be determined through consistency verification and threshold judgment by the confidence decision model by using the agent collaborative reasoning architecture. In other words, the embodiments of the present application can automatically and accurately complete the whole process from risk discovery, code positioning, logical analysis to final confirmation, which shows its high feasibility. BRIEF DESCRIPTION OF DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and serve to explain the principles of the present application together with the specification.

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows. Obviously, those skilled in the art can obtain other drawings from these drawings without any creative effort.

[0014] One or more embodiments are exemplarily illustrated by pictures in the corresponding drawings, which do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, unless otherwise specified. The drawings in the drawings do not constitute a proportional limitation.

[0015] Figure 1 A flowchart of an API logic vulnerability processing method provided in the embodiments of the present application; Figure 2 A flowchart of an API ledger feature mining and large model reasoning logic vulnerability automatic processing method provided in the embodiments of the present application; Figure 3 A structural schematic diagram of an API logic vulnerability processing device provided in the embodiments of the present application; Figure 4 A structural schematic diagram of an electronic device provided in the embodiments of the present application. DETAILED DESCRIPTION

[0016] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] The following disclosure provides numerous different embodiments or examples for implementing various structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of the invention. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0018] To address the issues of incomplete API logic vulnerability detection coverage, high false positive rates, and low automation in existing technologies, this application provides a method for handling API logic vulnerabilities, such as... Figure 1 As shown, the steps of this method include: Step 101: By analyzing API traffic, construct a dynamic API application programming interface asset ledger, and identify high-risk APIs from the API asset ledger based on resource access behavior characteristics. In this embodiment, the API asset ledger refers to a systematic tool that records the entire lifecycle information of all API interfaces, covering data such as API registration, usage, maintenance, changes, and security status, used to achieve asset transparency, risk control, and compliance management. Furthermore, resource access behavior characteristics include whether the API contains public or private data; therefore, this method can identify high-risk APIs that carry private core data.

[0019] Step 102: Perform white-box analysis on high-risk APIs and construct a subject identity propagation graph including user identity identifiers; As can be seen, for high-risk APIs, constructing a propagation path associated with their identity identifier allows for the direct determination of the complete propagation path of the high-risk API based on a modified identity propagation graph. This method is more lightweight than the data flow graph in existing technologies and meets subsequent analysis needs. In other words, this method only tracks the propagation path of the user's identity identifier (PIN) in the code, rather than performing full taint analysis as in existing technologies, thereby efficiently and accurately locating code segments related to authentication.

[0020] Step 103, using a multi-agent collaborative reasoning architecture, combining a modular search enhancement to generate a knowledge base, performing logical analysis on the subject identity propagation graph, and outputting a structured analysis conclusion; To this end, in a specific example, a modular retrieval augmentation generation (RAG) knowledge base is combined. Different AIAgent (AI agent) plays different expert roles (such as business analysis, security research and judgment), retrieves the necessary context (such as company internal authentication specifications, historical vulnerability patterns) from the knowledge base, and performs in-depth logical analysis on the "subject identity propagation graph" to determine whether the authentication behavior exists and is effective.

[0021] Step 104, based on the structured analysis conclusion, consistency verification and threshold judgment are performed through a confidence decision model to generate a vulnerability report.

[0022] Through the above steps 101 to 104, first, the API traffic is analyzed to construct a dynamic API application programming interface asset ledger, and high-risk APIs are identified from the API asset ledger based on resource access behavior characteristics, and white-box analysis is performed on the high-risk APIs to construct a subject identity propagation graph including user identity identification. Then, using a multi-agent collaborative reasoning architecture, combining a modular search enhancement to generate a knowledge base, logical analysis is performed on the subject identity propagation graph, and a structured analysis conclusion is output. Based on the structured analysis conclusion, consistency verification and threshold judgment are performed through a confidence decision model to generate a vulnerability report. As can be seen, in the embodiments of the present application, high-risk APIs can be actively and accurately identified, and then the corresponding subject identity propagation graph is constructed by analyzing them. The proxy collaborative reasoning architecture is used for analysis, and finally the consistency verification and threshold judgment can be performed through the confidence decision model to determine the final logical vulnerability. In other words, the embodiments of the present application can automatically and accurately complete the whole process from risk discovery, code positioning, logical analysis to final confirmation, and exhibit its high feasibility.

[0023] In the embodiments of the present application, the way of identifying high-risk APIs from the API asset ledger based on resource access behavior characteristics in the above step 101 can further include: Step 11, extracting resource identification and user identity identification from the API asset ledger; In the API traffic analysis, the API in the real-time or offline log stream from the API gateway, WAF, RASP probe and the like system can be analyzed. Specifically, one or more adapters (Adapter) can be started to connect different data sources. Each adapter parses the original log in different formats (such as JSON, Nginx Log Format) into a unified and structured "API call event" object. The object contains key fields: timestamp (timestamp), httpMethod (request method), requestPath (request path), requestHeaders (request header), requestBody (request body), responseCode (response code), sourceIp (source IP), etc. to unify the data format.

[0024] Step 12, based on the access relationship between the resource identifier and the user identifier, the risk level of the API is quantitatively calculated; In this regard, in specific embodiments, path normalization is performed first, specifically, a predefined regular expression template can be applied (such as normalizing / users / 123 and / users / 456 to / users / {id} ) to obtain normalizedPath (a function for normalizing file paths, its core function is to convert the path to a standard format, solve the problem of symbolic links, redundant separators, etc.). Then, the identity (PIN) and resource identifier are extracted, wherein the identity extraction is: according to the configurable rule set, the user unique identifier is extracted from the requestHeaders (HTTP request header carrying meta information), the requestBody (HTTP request component for carrying client data) or the QueryString (standardized format for passing parameters) to obtain the identity, which can be extracted based on priority, for example: first get X-User-PIN header, then decode JWT to get sub field. The resource identifier extraction is: the resource identifier is obtained from the path variable in the normalizedPath (such as / orders / {orderId}) or the key field in the requestBody.

[0025] The way of quantitatively calculating the risk level of the API in step 12 can further include: Step 21, calculating the concentration of resource identifiers accessed by different user identifiers; Step 22, based on the comparison result of the concentration and the preset threshold, distinguishing the type of API, the type of API including public data and private data; Step 23, according to the request method type of the API, the API is weighted after type differentiation to obtain the risk level of the API.

[0026] For the above steps 21 to 23, in a specific example, first in a configurable time window (for example, the past 24 hours), the system uses a memory database (such as Redis) or a stream processing engine (such as Flink) for aggregation, and the key for aggregation is normalizedPath. Then, for each normalizedPath, a data structure is maintained to record all resourceId (resource identifier) and its corresponding pin set of visitors under it. The calculation logic is: traverse all resourceIds under the path, calculate how many different pins each resourceId is accessed by, that is, distinct_pin_count. Finally, risk assessment is performed: calculate the average user concentration of a path avg_pin_per_resource = SUM(distinct_pin_count_for_each_resource) / COUNT(total_resources). According to the preset threshold T_private (for example, 1.2) and T_public (for example, 50) to classify. If avg_pin_per_resource<= T_private, it is determined as "private data operation", and a high basic risk score (for example, 80 points) is given. According to the risk weighting of httpMethod. If the method is POST, PUT, DELETE, PATCH, etc. write operation, the risk score is multiplied by a weight factor (for example, 1.2) to generate the final riskScore (risk level score).

[0027] Step 13, according to the risk level, the API is sorted, and the API with a risk level exceeding the preset level in the sorting result is input to the high-risk API list.

[0028] As can be seen, the final output high-risk list can be [{"normalizedPath": " / api / v2 / order / updateAddress","riskScore":96.0,"classification":"Private_Write"},...].

[0029] It can be seen that in the embodiments of the present application, by mining the behavior characteristics of real-time API traffic, a dynamic API asset ledger is constructed, and high-risk APIs carrying private core data are automatically identified based on the user relationship of resource access (1:1 vs 1:N). That is, the analysis resource is focused on the core API that is most likely to have a high-risk privilege violation vulnerability, greatly improving the detection efficiency and input-output ratio, and solving the noise problem caused by SAST full-scan in the prior art.

[0030] In an optional implementation of the embodiments of the present application, the method of constructing the subject identity propagation graph including the user identity involved in the above step 102 can further include: Step 31, locating the source code entry method corresponding to the high-risk API; In this regard, in specific embodiments, if an API entry in the high-risk API list is {"normalizedPath": " / api / v2 / order / updateAddress",...}. Then, a code index database (Code Index Database) pre-constructed by a SAST tool is queried, which stores the mapping relationship between all API routes annotations (such as Spring's @RequestMapping) of the project and corresponding classes and methods. Through accurate matching or fuzzy matching, the normalizedPath is located to the specific source code file and method, for example, com.example.controller.OrderController.updateAddress(...).

[0031] Step 32, based on the source code entry method, starting from the source code to identify the acquisition point of the user identity as a source node; In combination with the specific example of the above step 31, for step 32 in the specific example, a temporary function call graph (Call Graph) can be constructed based on the located method. Depth-first search is performed on this graph to check whether there is a predefined "data persistence dangerous function library" (such as *.save, *.update, *.delete, Mybatis's <update>The API is identified as an "operation class". Then, the identity source is identified: in the entry method and its pre-call chain (e.g. Filter, Interceptor), it is scanned whether there is a call to a predefined "trusted identity acquisition function library" (e.g. UserContext.getCurrentPin(), SecurityContextHolder.getAuthentication()). The call point is marked as the **"source node" (Source Node)** of the graph.

[0032] Step 33, tracking the propagation path of the user identity in the source code, generating a directed graph describing the flow relationship of the identity variable, wherein the directed graph represents the subject identity propagation graph.

[0033] In combination with the specific examples of steps 31 and 32 described above, step 33 in the specific example can be: starting a directed and context-sensitive data flow analysis engine. Unlike traditional taint analysis, the "source" (Source) of this engine is fixed as the identity variable identified above. Then, based on the graph generation algorithm, the graph is constructed, specifically: create a directed graph G, and add the method where the "source node" is located to G. Starting from the identity variable currentUserPin, track its flow within the method. When the variable is passed as a parameter to another method method_B (e.g. orderService.process(currentUserPin)), add method_B as a new node to the graph G, and create an edge from the current method to method_B. The attribute of the edge records the parameter passing relationship. Recursively enter method_B and continue to track the flow of the parameter. The tracking process records all code lines, method bodies, class names and file paths containing the identity variable. The tracking continues until the end of the variable scope or the end of the program execution path, and finally a structured "subject identity propagation graph" object (e.g. a JSON file) is obtained. The object includes the source code fragments of all related methods and clearly describes the transmission relationship of the identity variable between these methods.

[0034] As can be seen, in the embodiments of the present application, the trusted user identity acquisition point (e.g. LoginContext.getPin()) is taken as the "source" (Source), and the complete propagation path of the identity in the code is tracked, that is, only the propagation path of the user identity (PIN) in the code is tracked, rather than the full taint analysis in the prior art. Through the method in the embodiments of the present application, the code fragments related to authentication can be efficiently and accurately located.

[0035] In an optional implementation of the embodiments of the present application, for the logical analysis using the multi-agent collaborative reasoning architecture in step 103, the output structured analysis conclusion can further include: Step 41, the Coordinator Agent retrieves technical specifications, business rules, and historical vulnerability information associated with the high-risk API from the modular search enhancement generated knowledge base; The Coordinator Agent is the core component in the multi-agent system, responsible for coordinating the collaboration and task allocation of multiple Agents.

[0036] In this regard, in a specific example, the Coordinator Agent extracts key entities from the graph: entry method name, identity variable name, external input parameter name (such as orderId). Based on these entities, generate multiple semantic query vectors. For example, vector("company standard authentication method"), vector("order modification business security specification"). Submit these query vectors to the modular RAG knowledge base. The knowledge base is a vector database, which internally divides the namespace according to "technical layer", "business layer", "experience layer". Retrieve and return the most relevant Top-K knowledge fragments.

[0037] Step 42, the Security Analyst Agent performs thought chain reasoning on the subject identity propagation graph based on the retrieved knowledge to determine whether the authentication logic is flawed; In this regard, in a specific example, the Security Analyst Agent dynamically constructs a structured prompt word containing rich context according to the standard template.

[0038] Prompt word structure: •<System Role>: "You are a senior application security expert, good at finding logical vulnerabilities in code, especially horizontal privilege escalation." •<Task Definition>: "Your task is to analyze the following code path and determine whether the variable {pin_variable_name} representing the current user has the right to operate the resource identified by the external parameter {resource_variable_name}." •<Knowledge Context>: "Please refer to the following internal knowledge for judgment: [insert all knowledge fragments retrieved in step 3.1 here]" • <code context>"Below is the complete propagation path of the user identity variable {pin_variable_name} in the program and the related source code: [Insert all code snippets formatted in the graph here]".

[0039] •<Instruction&Output Format>: "Please follow the Chain-of-Thought reasoning and finally give a JSON-formatted conclusion containing the verdict, confidence (0-1), and reasoning fields." Finally, the complete prompt word built is sent to the designated large language model (such as GPT-4, Claude 3, etc.) through the API.

[0040] Step 43, output the structured analysis conclusion including vulnerability judgment, confidence and reasoning process.

[0041] Based on the specific examples of steps 41 and 42 above, for this step 43, use regular expressions or JSON parsers to strictly extract the required JSON object from the response <Instruction&Output Format>. The text of the Chain-of-Thought part is also extracted as evidence for subsequent audits, resulting in a standardized analysis result object containing the conclusion, confidence and reasoning process.

[0042] As can be seen in the embodiments of the present application, a multi-Agent collaborative reasoning architecture is used in combination with a modular Retrieval Augmentation Generation (RAG) knowledge base. Different AI Agents play different expert roles (such as business analysis, security research and judgment), retrieve necessary context (such as company internal authentication specifications, historical vulnerability patterns) from the knowledge base, and perform in-depth logical analysis on the "subject identity propagation graph". The behavior of whether the authentication is present and effective is judged. This process simulates the collaboration mode of a team of human experts, provides accurate and reliable "prior knowledge" for LLM (large language model), effectively suppresses model hallucinations, and enables the model to understand complex internal technical specifications and business logic, thereby making highly accurate judgments.

[0043] In the optional implementation of the embodiments of the present application, for the structured analysis conclusion involved in the above step 104, the consistency verification and threshold judgment are performed through the confidence decision model to generate the vulnerability report, which can further include: Step 51, perform multiple parallel reasoning tasks and self-consistency voting on the structured analysis conclusion to generate a consensus conclusion; Step 52, based on the comparison result of the average confidence and the preset threshold, the consensus conclusion is classified, wherein the classified consensus conclusion includes confirming vulnerability, suspected vulnerability and confirming security; Step 53, in the case of confirming that the consensus conclusion is a vulnerability, a repair suggestion is generated and included in the vulnerability report.

[0044] For the above steps 51 to 53, in a specific example, for performing the reasoning task and self-consistent voting, generating the consensus conclusion means that the reasoning task is executed N times (for example, 3 times) in parallel using the same input with different temperature parameters (for example, 0.2, 0.4, 0.6). Collect N analysis results. Vote on the verdict field. For example, if 2 or more of the 3 results are "VULNERABLE", the consensus conclusion is "there is a vulnerability".

[0045] For the comparison of confidence and preset threshold, the average confidence of the results reaching consensus is calculated based on the consensus conclusion and the confidence of N results. A predefined double threshold T_high (for example, 0.90) and T_low (for example, 0.40) is applied. The decision logic is as follows: If the consensus is "VULNERABLE" AND avg_confidence>T_high -> final decision: Confirmed_Vulnerable (confirmed vulnerability).

[0046] If there is no clear consensus OR (avg_confidence is between T_low and T_high) -> final decision: Buffer_Needs_Review (suspected vulnerability / buffer).

[0047] Other cases -> final decision: Considered_Safe (confirmed security).

[0048] Finally, report compilation and repair suggestion generation: start the report generator and create a report template containing standard fields. Automatically fill in the evidence: fill in all the codes of API information, risk score, subject identity propagation graph, knowledge retrieved by RAG, complete thought chain reasoning process of LLM, etc. into the report. Generate repair suggestions: if the decision is Confirmed_Vulnerable, call LLM again, provide vulnerability code and analysis conclusion, and ask it to generate repaired code fragments, and add this suggestion to the report. Finally, a structured vulnerability report (in HTML or PDF format) with detailed content and complete evidence chain is obtained.

[0049] It can be seen that in the embodiment of the present application, a three-section confidence decision model is introduced to convert the probabilistic output of the LLM into a deterministic engineering conclusion (determining a vulnerability, a suspected vulnerability / buffer, and confirming safety), thereby solving the unpredictability problem of AI and improving the practicality and reliability of the system.

[0050] The present application will be explained and described below in conjunction with the specific implementation of the embodiments of the present application, in which the embodiments of the present application take a "modify order delivery address" function of a typical Internet e-commerce platform as a detection target.

[0051] Among them, API interface: POST / api / v2 / order / updateAddress; Request parameters: { "orderId": "ORD123456", "newAddress": "..."}; Business logic requirement: Only the owner of the order (i.e., the user who placed the order) has the right to modify the delivery address of the order.

[0052] Security risk: If there is no effective authentication, an attacker User_A can modify the order address of User_B by guessing or obtaining the orderId, causing property loss.

[0053] Based on this, the specific implementation provides a logic vulnerability automatic processing method based on API account feature mining and large model reasoning, as shown in Figure 2 The method steps in the specific implementation include: Step 201, API account construction and risk identification.

[0054] The specific process is: the system has accessed the traffic log of the online API gateway. The API account construction module continuously analyzes the request traffic of POST / api / v2 / order / updateAddress. Among them, the time window: the past 7 days. Resource ID: the orderId extracted from the request body. User ID: the pin parsed from the request credentials (such as JWT). Based on this, it is calculated that 99.5% of the orderIds (such as ORD123456) have been accessed only by a unique pin (such as User_B) in the past 7 days. Therefore, it is determined that the orderId is private data, and therefore / api / v2 / order / updateAddress is marked as a high-risk operation API, and the next step of analysis is triggered.

[0055] Step 202, white box analysis and subject identity propagation graph construction.

[0056] The specific process is: the source code of the Java project of the business line has been obtained, and then the white box analysis and graph generation module is started. First, API association: the path / api / v2 / order / updateAddress is mapped to the updateAddress method of the OrderController.java file in the source code. For operation type identification: the engine analyzes the call chain of the updateAddress method and finds that it finally calls an <update>The tag, thus confirming it as an "operation class". For identity origin identification: the engine identifies the line of code that acquires the user identity in the updateAddress method or its preceding interceptor: String currentUserPin = UserContext.getCurrentPin(); Then, it performs propagation path tracking: the engine traces the propagation of the currentUserPin variable from this line of code: currentUserPin is passed to orderService.updateAddress(orderId, newAddress, currentUserPin). Inside the orderService.updateAddress method, this variable is used in the logic following Order order = orderDao.findById(orderId); Finally, a "subject identity propagation graph" is formed, containing the source code of the OrderController.updateAddress, OrderService.updateAddress, etc. methods, and the flow path of the currentUserPin in these codes.

[0057] Step 203, multi-Agent collaborative reasoning.

[0058] The specific process is: after the graph has been generated and the modular knowledge base has been prepared, the multi-Agent collaborative reasoning module receives the graph.

[0059] Agent 1 (Coordinator): The above graph and request information (orderId is an external input), initiates a query to the modular knowledge base, and retrieves from the "technical layer" knowledge base: "the company's standard authentication method is AuthManager.checkPermission(pin, resource)". From the "business layer" knowledge base, it retrieves: "the Order object contains the ownerPin attribute, representing the order owner". Finally, the graph source code, external input parameter information, and the two pieces of retrieved knowledge are packaged together into a context.

[0060] Agent 2 (Security Analyst): For the context output by Agent 1, perform Chain-of-Thought reasoning, specifically verify if the currentUserPin has the right to modify the order represented by orderId. "Checkpoint 1 - Standard Authentication: In the provided code snippet, was AuthManager.checkPermission called? -> Conclusion: No call found." "Checkpoint 2 - Business Logic Authentication: Does the code perform a check like if(order.getOwnerPin().equals(currentUserPin))? -> Analysis: The code in orderService.updateAddress gets the Order object but does not compare the ownerPin with the currentUserPin. Instead, it directly executes order.setAddress(...) and orderDao.update(order). -> Conclusion: Business logic authentication is missing." As a result, Agent 2 outputs a structured JSON with the conclusion "Horizontal privilege escalation vulnerability exists" and a confidence level of 95%. It also points out that "Before the data update operation, the current user currentUserPin was not verified as the owner of the order orderId."

[0061] Step 204, Decision and Report Generation.

[0062] Self-consistency verification: The system repeatedly performs this task three times, each time obtaining the same "vulnerability exists" conclusion. Three-part decision: Since the confidence level (95%) is much higher than the threshold, the system determines this as "definitely escalation." The system automatically generates a vulnerability report containing: API path, risk description, code snippet as evidence, complete reasoning process of LLM, and suggests a repair solution: "Before orderDao.update(order) is executed, add the code: if (!order.getOwnerPin().equals(currentUserPin)) { throw new NoPermissionException();}."

[0063] It can be seen that, by the logical vulnerability automatic processing method based on API account feature mining and large model reasoning in the specific embodiment, the method fuses dynamic traffic analysis, white box code analysis and large language model (LLM) reasoning, and high-risk APIs carrying private core data are automatically identified by behavior feature mining of real-time API traffic, construction of a dynamic API asset account, and user relationship (1:1 vs 1:N) based on resource access. Then, for the high-risk API, a "principal identity propagation graph (PIN Data Flow Graph)" construction method is proposed in the present application. This method innovatively only tracks the propagation path of the user identity (PIN) in the code, rather than traditional full-quantity taint analysis, thereby efficiently and accurately locating and authenticating code segments related to authentication. In addition, a multi-agent collaborative reasoning architecture is used in combination with a modular retrieval augmented generation (RAG) knowledge base. Different AI agents play different expert roles (such as business analysis and security research and judgment), retrieve necessary context (such as company internal authentication specifications and historical vulnerability patterns) from the knowledge base, perform in-depth logical analysis on the "principal identity propagation graph", and determine whether the authentication behavior exists and is effective. Finally, a three-stage confidence decision model is introduced to convert the probabilistic output of the LLM into a deterministic engineering conclusion (determining a vulnerability, a suspected vulnerability / buffer, and confirming security), solving the problem of AI unpredictability and improving the practicality and reliability of the system.

[0064] Corresponding to the above Figure 1 , the present application embodiment also provides an API logic vulnerability identification device, as shown in Figure 3 , the device comprises: A first processing module 302 is configured to construct a dynamic API application programming interface asset account by analyzing API traffic, and identify high-risk APIs from the API asset account based on resource access behavior characteristics. A second processing module 304 is configured to perform white box analysis on the high-risk APIs to construct a principal identity propagation graph including user identity. A third processing module 306 is configured to use a multi-agent collaborative reasoning architecture in combination with a modular retrieval augmented generation knowledge base to perform logical analysis on the principal identity propagation graph and output a structured analysis conclusion. A fourth processing module 308 is configured to perform consistency verification and threshold judgment based on the structured analysis conclusion through a confidence decision model to generate a vulnerability report.

[0065] In an optional implementation of the embodiment of the application, the first processing module in the embodiment of the application further can include: a first processing unit configured to extract a resource identifier and a user identity identifier from an API asset ledger; a second processing unit configured to quantitatively calculate a risk level of the API based on an access relationship between the resource identifier and the user identity identifier; and a third processing unit configured to sort the API according to the risk level and input an API with a risk level exceeding a preset level in the sorting result to a high-risk API list.

[0066] In an optional implementation of the embodiment of the application, the second processing unit in the embodiment of the application further can include: a calculation subunit configured to calculate a concentration of access of the resource identifier by different user identity identifiers; a distinguishing subunit configured to distinguish a type of the API based on a comparison result of the concentration and a preset threshold, wherein the type of the API includes public data and private data; and a processing subunit configured to perform a weighted calculation on the API of the distinguished type to obtain the risk level of the API in combination with a request method type of the API.

[0067] In an optional implementation of the embodiment of the application, the second processing module in the embodiment of the application further can include: a positioning unit configured to position a source code entry method corresponding to the high-risk API; an identification unit configured to identify a source node as an acquisition point of the user identity identifier from the source code based on the source code entry method; and a fourth processing unit configured to track a propagation path of the user identity identifier in the source code and generate a directed graph describing a flow relationship of the identity variable, wherein the directed graph represents a subject identity propagation graph.

[0068] In an optional implementation of the embodiment of the application, the third processing module in the embodiment of the application further can include: a fifth processing unit configured to retrieve technical specifications, business rules and historical vulnerability information associated with the high-risk API from a modular retrieval enhancement generation knowledge base by a coordination agent; and a sixth processing unit configured to perform a thought chain reasoning on the subject identity propagation graph based on the retrieved knowledge by a security analysis agent to determine whether the authentication logic has defects; and output a structured analysis conclusion including a vulnerability determination, a confidence level and a reasoning process.

[0069] In an optional implementation of the embodiment of the application, the modular retrieval enhancement generation knowledge base in the embodiment of the application divides a namespace according to a technical layer, a business layer and an experience layer.

[0070] In an optional implementation of the embodiment of the application, the fourth processing module in the embodiment of the application further can include: a seventh processing unit, configured to perform a plurality of parallel reasoning tasks and self-consistency voting on the structured analysis conclusion to generate a consensus conclusion; an eighth processing unit, configured to classify the consensus conclusion based on a comparison result of the average confidence and a preset threshold, wherein the classified consensus conclusion includes confirmed vulnerability, suspected vulnerability and confirmed security; and a ninth processing unit, configured to generate a repair suggestion and incorporate the repair suggestion into a vulnerability report in a case where the consensus conclusion is confirmed as a vulnerability.

[0071] As shown in Figure 4 the embodiment of the application provides an electronic device, including a processor 411, a communication interface 412, a memory 413 and a communication bus 414, wherein the processor 411, the communication interface 412, the memory 413 complete mutual communication through the communication bus 414, the memory 413 is used for storing a computer program; In an embodiment of the application, the processor 411 is used for executing the program stored in the memory 413, and the API logic vulnerability processing method provided by any one of the preceding method embodiments is implemented, and the role is similar, which will not be repeated here.

[0072] The embodiment of the application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the API logic vulnerability processing method provided by any one of the preceding method embodiments.

[0073] The device embodiments described above are only schematic, wherein the units described as separate components can or can not be physically separated, and the components displayed as units can or can not be physical units, that is, they can be located in one place, or distributed on multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0074] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be realized by means of software plus a general hardware platform, and of course can also be realized by hardware. Based on such understanding, the above technical solutions can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in each embodiment or some parts of the embodiments.

[0075] It is to be understood that the terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises", "comprising", "includes", "including" and "has" are inclusive and therefore specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order

[0076] The above description is merely that of the specific embodiments of the application and as such is not to be taken in a limiting sense. Various modifications and alterations of the embodiments described herein will become apparent to those skilled in the art from the foregoing description, which does not limit the generality presented by the foregoing description. Accordingly, the drawings and descriptions are illustrative embodiments only.< / update> < / code> < / update>

Claims

1. A method for handling API logic vulnerabilities, characterized in that, include: By analyzing API traffic, a dynamic API application programming interface asset ledger is constructed, and high-risk APIs are identified from the API asset ledger based on resource access behavior characteristics. White-box analysis was performed on the high-risk APIs to construct a subject identity propagation graph that includes user identification identifiers; By utilizing a multi-agent collaborative reasoning architecture and combining modular retrieval to enhance the knowledge base generation, logical analysis is performed on the subject identity propagation graph, and structured analysis conclusions are output. Based on the structured analysis results, a confidence decision model is used to perform consistency verification and threshold judgment in order to generate a vulnerability report.

2. The method according to claim 1, characterized in that, High-risk APIs identified from the API asset ledger based on resource access behavior characteristics include: Extract resource identifiers and user identity identifiers from the API asset ledger; Based on the access relationship between resource identifiers and user identity identifiers, the risk level of the API is quantitatively calculated. The APIs are sorted according to their risk level, and the APIs with risk levels exceeding the preset level are entered into the high-risk API list.

3. The method according to claim 2, characterized in that, The risk levels of the quantization calculation API include: The concentration of computing resource identifiers accessed by different user identities; Based on the comparison results between the concentration degree and the preset threshold, the types of APIs are distinguished, including public data and private data; The risk level of an API is obtained by weighting the APIs after classifying their request method types.

4. The method according to claim 1, characterized in that, The construction of the subject identity propagation graph, which includes user identity identifiers, includes: The source code entry point method for high-risk APIs; Based on the aforementioned source code entry method, the point from which the user's identity is identified is taken as the source node from the source code; The propagation path of the user identity identifier in the source code is traced to generate a directed graph describing the flow relationship of identity variables, wherein the directed graph represents the propagation spectrum of the subject identity.

5. The method according to claim 1, characterized in that, The logical analysis using a multi-agent collaborative reasoning architecture outputs structured analysis conclusions, including: The coordinating agent retrieves technical specifications, business rules, and historical vulnerability information associated with high-risk APIs from a modularly enhanced knowledge base; Based on the retrieved knowledge, the security analysis agent performs thought chain reasoning on the subject identity propagation graph to determine whether there are defects in the authentication logic; The output includes structured analysis conclusions such as vulnerability determination, confidence level, and reasoning process.

6. The method according to claim 5, characterized in that, The modular retrieval enhancement knowledge base is divided into namespaces based on the technical layer, business layer, and experience layer.

7. The method according to claim 1, characterized in that, Based on the structured analysis conclusions, a confidence-based decision model is used for consistency verification and threshold determination to generate a vulnerability report, including: The structured analysis conclusions are subjected to multiple parallel inference tasks and self-consistent voting to generate a consensus conclusion; Based on the comparison results between the average confidence level and the preset threshold, the consensus conclusions are classified, wherein the classified consensus conclusions include confirmed vulnerabilities, suspected vulnerabilities, and confirmed security. If the consensus conclusion is confirmed as a vulnerability, a remediation suggestion is generated and included in the vulnerability report.

8. A device for identifying API logic vulnerabilities, characterized in that, include: The first processing module is used to construct a dynamic API application programming interface asset ledger by analyzing API traffic, and to identify high-risk APIs from the API asset ledger based on resource access behavior characteristics. The second processing module is used to perform white-box analysis on the high-risk API and construct a subject identity propagation graph including user identity identifiers; The third processing module is used to perform logical analysis on the subject identity propagation graph by utilizing a multi-agent collaborative reasoning architecture and combining modular retrieval enhancement to generate a knowledge base, and output structured analysis conclusions. The fourth processing module is used to perform consistency verification and threshold judgment based on the structured analysis conclusions through a confidence decision model to generate a vulnerability report.

9. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory is used to store computer programs; the processor is used to implement the API logic vulnerability identification method according to any one of claims 1-7 when executing the computer programs.

10. A storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the method for handling API logic vulnerabilities as described in any one of claims 1-7.

Images