A logical vulnerability detection method based on semantic sink to physical sink mapping

Abstract

The application provides a logical vulnerability detection method based on semantic Sink to physical Sink mapping, relies on a configuration process arrangement engine to schedule a verb node, performs preprocessing and architecture exploration on a to-be-tested source code to obtain a project context; a business semantic identification and dynamic logical Sink identification are performed by an audit intelligent agent to generate a semantic Sink list; the semantic Sink is mapped to a physical Sink through a loop retry mechanism; a call link is obtained by performing reverse call tracing on the physical Sink list, and a missing link is supplemented through chain breaking compensation; a code definition is completed link by link, a missing situation of permission verification, parameter filtering and security interception is judged, and a structured vulnerability detection result is output. The application breaks away from the dependence on a preset dangerous API list, can identify sensitive test points at a business semantic level, improves the missed report problem of traditional pollution analysis on logical vulnerabilities, significantly reduces the missed report rate, and realizes automatic and high-precision detection of logical vulnerabilities.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a logical vulnerability detection method based on semantic sink to physical sink mapping. Background Technology

[0002] In the software development process, automated source code auditing is a crucial means of discovering security vulnerabilities and ensuring software security. As software scales and source code complexity continue to increase, there is an urgent need to improve the efficiency and coverage of vulnerability detection through automated code auditing.

[0003] Current automated code auditing commonly employs taint analysis techniques for vulnerability detection. This technique pre-configures a physical sink list consisting of dangerous functions and a list of user-controllable external input points. Based on the constructed code data flow graph and call graph, it retrieves unpurified reachable paths from user-controllable input points to dangerous functions and outputs alerts for the detected paths as vulnerabilities. However, the above approach has the following problems when dealing with logical vulnerabilities:

[0004] 1) Taint analysis detection heavily relies on a pre-built list of dangerous APIs for physical sinks. However, the risk points of logical vulnerabilities lie at the business semantic level, and there are no enumerable, fixed dangerous APIs. Even if a complete data flow reachable path is obtained, the inability to match the list entries may lead to a direct determination that no vulnerability exists, resulting in a large number of missed detections of logical vulnerabilities. 2) Existing technologies rely solely on function signature matching and data flow reachability to determine vulnerabilities. They lack the ability to analyze business context semantics and cannot assess logical flaws such as the actual coverage of interceptors or whether permission annotations truly fulfill their data permission constraints, leading to misjudgments. 3) The sensitive sinks corresponding to logical vulnerabilities are abstract business concepts and cannot be pre-enumerated and entered into the list. Existing detection solutions cannot autonomously identify business security test points, making it difficult to effectively locate logical vulnerabilities.

[0005] Therefore, there is an urgent need for a logic vulnerability detection solution that does not rely on a fixed physical sink list, and can identify sensitive operation points on the business side based on business semantics to achieve effective identification and judgment of logic vulnerabilities. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a logical vulnerability detection method based on semantic sink to physical sink mapping, which solves the problems of easy false negatives and difficulty in locating and judging logical vulnerabilities in existing technologies.

[0007] According to an embodiment of the present invention, a logical vulnerability detection method based on semantic sink to physical sink mapping includes the following steps:

[0008] S1: Obtain the source code of the project to be tested, perform preprocessing and architecture exploration, and obtain the project context including the technology stack, framework type, authentication system and entry point form;

[0009] S2: Perform business semantic recognition and dynamic logic sink recognition on the project context, merge the interfaces carrying resource identifiers, permission verification points and sensitive operation points, and generate a semantic sink list;

[0010] S3: Using a loop retry mechanism, each semantic sink in the semantic sink list is derived one by one and mapped to the corresponding physical sink function in a one-to-many manner. The mapping results are aggregated to generate a physical sink list containing class name, method name, position, type and danger level. The loop exit condition is that the physical sink list is not empty. If the physical sink list is not empty after the loop exits, it is output to S4; otherwise, it is terminated.

[0011] S4: Perform reverse call tracing for each physical sink in the physical sink list, search upwards layer by layer to the top-level method and determine whether the parameters originate from external input, filter user-controllable entry paths, and generate a link list containing entry identifiers and hop-by-hop links;

[0012] S5: Based on the link list, trace the data flow and complete the missing definitions, analyze the missing information of permission verification, parameter filtering and security interception at each link, and generate a structured vulnerability detection result containing vulnerability type, defect location and verification process.

[0013] Furthermore, the business semantic recognition and dynamic logic sink recognition are performed by the audit agent based on the project's business functions:

[0014] The system identifies interfaces carrying object resource identifiers, ownership verification points before resource read / write operations, and sensitive interfaces in the interceptor whitelist. The identification results are merged, and the semantic sink list, which stores individual business security test points line by line, is output.

[0015] Furthermore, the semantic sink list is split, deduplicated, and truncated in number. It adopts an item-by-item derivation method to independently perform physical sink mapping for each semantic sink; wherein, a single semantic sink mapping yields one or more physical sinks.

[0016] Furthermore, the maximum number of loop rounds configured in the loop retry mechanism is 3. The loop exits when the physical sink list is produced and is not empty; if the physical sink list is not produced, the mapping operation is repeated until the maximum number of loop rounds is reached, at which point the loop is forcibly terminated.

[0017] Furthermore, after the loop retry is completed, a branching decision is made:

[0018] When the physical sink list is not empty, perform a reverse call tracing of the physical sink;

[0019] When the physical sink list is empty, jump directly to the vulnerability collection output.

[0020] Furthermore, the reverse call tracing is performed by splitting the data line by line and processing it in parallel, wherein the maximum concurrency of the parallel processing is 3.

[0021] Furthermore, the specific process of the reverse call tracing is as follows:

[0022] Use a text search tool to locate the class, method and line number of the physical Sink, and then search upwards layer by layer for its caller until you reach the top-level method with no caller.

[0023] The parameters of the top-level method are determined to be from external inputs such as HTTP requests, message queues, RPCs, or file uploads, in order to determine whether there is a user-controllable entry point.

[0024] Furthermore, for unlinked physical sinks that failed to be traced back in the reverse call, the validity of the link is verified through semantic compensation inference, and the valid links obtained through compensation are incorporated into the link list.

[0025] Furthermore, the step-by-step analysis includes:

[0026] Read the complete code of the entry method and extract the source of the parameters; trace the data flow hop by hop along the link, and use language-level definition parsing tools to retrieve and complete the definitions of any missing intermediate methods or classes in the link;

[0027] The system checks each step to determine if there are missing permissions verification, missing parameter filtering, or missing security interception. It also considers the controllability of entry parameters, defects in intermediate processing, and the sensitivity of the sink to determine whether a logical vulnerability exists. The system outputs a structured detection result that includes the vulnerability type, defect location, risk level, and verification process.

[0028] Furthermore, the defect location in the structured detection result is taken from the code location corresponding to the last hop physical sink of the link; when no valid code location is found, a preset placeholder is filled in.

[0029] The technical principle of this invention is as follows: This invention is based on a two-stage conversion mechanism from semantic sink identification to physical sink mapping. First, an auditing agent performs business semantic analysis on the project context to identify non-enumerable logical security test points and generate a semantic sink list. Using a loop retry and item-by-item derivation mechanism, each semantic sink is mapped to a real physical sink and its location in the code. Reverse call tracing is performed on the physical sinks to construct a complete call chain from the user-controllable entry point to the sink. Finally, the code definition is completed link by link, and the deficiencies in permission verification, parameter filtering, and security interception are analyzed at each stage, outputting structured detection conclusions.

[0030] Compared with the prior art, the present invention has the following beneficial effects:

[0031] 1. This invention uses an auditing agent to perform business semantic recognition to generate a semantic sink list, and then maps it to obtain a physical sink. It no longer relies on a pre-set list of dangerous APIs, which solves the technical problem of missed reports due to the lack of enumerable fixed dangerous APIs for logical vulnerability risk landing points, and realizes the autonomous identification of sensitive security test points at the business level.

[0032] 2. This invention completes the missing code definition in the call chain, and analyzes the missing permission verification, parameter filtering and security interception at each link of the call chain. It solves the technical problems of existing technologies that lack business context semantic parsing and cannot identify permission-related logical defects, and realizes vulnerability analysis at the business logic level.

[0033] 3. This invention relies on a configurable process orchestration engine, keeping the verb node sequence and field contract unchanged, and only replacing the underlying execution tool. It solves the technical problems of abstract business-sensitive sinks not being able to be pre-enumerated and the large amount of repetitive development work for multi-language detection, and realizes cross-programming language reuse of upper-level business processes. Attached Figure Description

[0034] Figure 1 This is an overall flowchart of an embodiment of the present invention.

[0035] Figure 2 This is a one-to-many mapping diagram from semantic sink to physical sink in an embodiment of the present invention.

[0036] Figure 3 This is an overall system block diagram of an embodiment of the present invention. Detailed Implementation

[0037] The technical solutions of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0038] like Figure 1 As shown in the figure, this invention proposes a logical vulnerability detection method based on semantic sink to physical sink mapping, including the following steps:

[0039] S1: Obtain the source code of the project to be tested, perform preprocessing and architecture exploration, and obtain the project context including the technology stack, framework type, authentication system and entry point form;

[0040] S2: Perform business semantic recognition and dynamic logic sink recognition on the project context, merge interfaces carrying resource identifiers, permission verification points and sensitive operation points, and generate a semantic sink list;

[0041] S3: A loop retry mechanism is used to map each semantic sink in the semantic sink list to a physical sink. The list is not empty as the exit condition, and a physical sink list containing class name, method name, location, type and danger level is generated.

[0042] S4: Perform reverse call tracing for each physical sink in the physical sink list, search upwards layer by layer to the top-level method and determine whether the parameters originate from external input, filter user-controllable entry paths, and generate a link list containing entry identifiers and hop-by-hop links;

[0043] S5: Based on the link list, trace the data flow and fill in the missing definitions. Analyze the missing information in permission verification, parameter filtering and security interception at each stage, and generate structured vulnerability detection results that include vulnerability type, defect location and verification process.

[0044] The detailed working process of this embodiment is as follows:

[0045] In step S1, the source code is read to complete preprocessing, the architecture is explored, basic project information is collected, and the project context is generated and output downstream.

[0046] Existing static detection methods directly scan the source code, lacking a global understanding of the project framework and authentication system, and rely solely on function signature matching for detection. This invention constructs the project context through preprocessing and architecture exploration, providing basic information support for business semantic recognition at the project dimension.

[0047] Read all source code of the project to be tested and perform source code preprocessing. The preprocessing stage completes the source code file screening, filtering out compiled output files and third-party dependency library files, and retaining only the business source code; unifying the file encoding format, removing invalid comments and redundant whitespace characters, and obtaining a clean set of source code to be analyzed.

[0048] After preprocessing, architecture exploration is performed. Architecture exploration is part of the language adaptation processing logic, which calls the corresponding architecture parsing verb node for different programming languages. For example, in the Java environment, the corresponding verb node is java.arch.explore. Architecture exploration reads project configuration files, source code directory structure, framework annotations, route definitions, and authentication component configurations, and parses and extracts the project's technology stack, the types of frameworks used, the authentication system implementation method, and the form of external service entry points.

[0049] All the information obtained from the above parsing is structured and encapsulated to generate a project context. The project context then flows to the downstream semantic sink recognition module.

[0050] This step constructs a complete project context describing the project's characteristics, eliminating information blind spots in subsequent business semantic recognition stages and providing project-level factual evidence for semantic sink recognition.

[0051] In step S2, the audit agent performs business semantic recognition and dynamic logic sink recognition based on the project context, merges the recognition results, and generates a semantic sink list that records business security test points line by line.

[0052] Since existing taint analysis relies on a pre-built list of physically hazardous APIs, the risk points corresponding to logical vulnerabilities are abstract business concepts and cannot be pre-entered into the list. This invention identifies security test points from the business semantic dimension through an auditing agent and generates a semantic sink list, thus eliminating the reliance on pre-built hazardous APIs.

[0053] This step is completed collaboratively by two verb nodes: the business semantic recognition node `full.sink.business` and the dynamic logic sink recognition node `full.sink.dynamic`. The audit agent is responsible for the recognition calculation. The audit agent receives the project context output from the upstream and performs the two tasks of business semantic recognition and dynamic logic sink recognition in parallel based on the project's business functions.

[0054] Business semantic recognition: Using "identify business security test points from business semantics" as the execution command, it locates risk points at the business semantic level, identifying interfaces carrying object resource identifiers, ownership verification points before resource read / write operations, and sensitive interfaces in the interceptor whitelist. These types of points are the risk sources of logical vulnerabilities and do not have fixed, enumerable dangerous API function signatures.

[0055] Dynamic logic sink identification: Scan the source code to identify logic sink points that take effect dynamically at runtime, which can be used to supplement sensitive operation points that are missed in business semantic identification.

[0056] The business semantic recognition results and dynamic logic sink recognition results are merged, and duplicate business security test points are removed. A text-formatted semantic sink list (semantic_sink_list) is output, where each line stores an independent business security test point, with one line corresponding to one semantic sink. The semantic sink list is then passed to the downstream physical sink mapping stage.

[0057] This step bypasses the pre-built list of dangerous APIs, locates business security test points from the business semantic level, generates a semantic sink list, and solves the technical obstacle that logical vulnerability sinks cannot be pre-enumerated.

[0058] In step S3, the semantic sink list is cleaned, and the semantic-physical sink mapping is completed by item-by-item derivation and loop retry. After the mapping is completed, branching is performed to obtain the physical sink list.

[0059] Considering that semantic sinks are abstract business concepts and do not have a natural one-to-one correspondence with source code functions, a single mapping is prone to producing empty results; therefore, this invention transforms abstract semantic sinks into analyzable physical sinks by using item-by-item derivation fan-out and loop retry flow splitting, and supports one-to-many mapping.

[0060] The core verb node in this step is `full.sink.find`, and its input binding configuration is as follows:

[0061] json

[0062] "inputs": { "logic_sink": {

[0063] "from": "<semantic sink source node>", "key": "semantic_sink_list",

[0064] "split": "lines", "unique": true, "limit": 100, "each": true}}

[0065] Receive the semantic sink list output from the upstream, and perform preprocessing on the list according to the configuration: split the list content by line using split:lines, perform deduplication using unique:true, and truncate the number of entries using limit:100 to avoid excessive number of entries causing pressure on subsequent processing.

[0066] like Figure 2As shown, the business semantic layer identifies the business security test point as "querying / modifying defective resources by defect identifier," which does not contain any fixed dangerous APIs. After semantic-physical sink one-to-many mapping and distribution processing, a single semantic sink ultimately derives and maps three independent physically sensitive operations: defective resource query, defective resource update, and defective resource deletion. In this embodiment, the above three physically sensitive operations correspond sequentially to three physical sink functions at the source code level: query interface, update interface, and delete interface, and each physical sink is marked with corresponding operation type and danger level information.

[0067] The mapping process is entirely encapsulated within the kind:loop loop node:

[0068] "loop_body": ["full_sink_find"],"loop_max": 3,

[0069] "loop_exit": { "logic":"any","conds":[

[0070] {"node":"full_sink_find","key":"physical_sink_functions","op":"exists",

[0071] "value":""} ]}

[0072] The loop retry mechanism is configured with a maximum loop count of 3. After each round of mapping is completed, an exit condition is determined: based on the loop_exit configuration, if physical_sink_functions satisfy op:exists (i.e., a non-empty physical sink list is produced), the loop exits directly; if no physical sink list is produced in this round, the mapping is re-executed; when the loop reaches the maximum count of 3, the loop is forcibly terminated without retrying.

[0073] The node configuration "record":"artifact:sink" saves the mapped output to disk as a Sink artifact. The mapping results of each item-by-item derived output are aggregated and merged using agg:join to generate a complete physical Sink list (physical_sink_functions). Each record in the physical Sink list contains the physical Sink's class name, method name, code location (sink_locations), Sink type, and danger level.

[0074] After the loop ends, the `kind:decision` routing node is connected, and the routing rules are as follows:

[0075] If a sink: physical_sink_functions satisfies op:len_gtvalue:0, and a match is found, the process flows to the downstream reverse call tracing stage;

[0076] If there is no sink: if physical_sink_functions satisfy op:not_exists, the process will directly jump to the vulnerability aggregation and output step and will not execute subsequent link analysis to avoid downstream modules performing invalid operations on empty data.

[0077] This step successfully transforms the abstract semantic sink list into a precise and traceable physical sink list through a loop retry and item-by-item derivation mapping mechanism, and achieves intelligent routing of "continue when there is a sink, converge when there is no sink", thus improving the efficiency and robustness of the process.

[0078] In step S4, the physical sink list is split line by line, and reverse call tracing is carried out in parallel to trace the call chain, filter user-controllable entry paths, and generate a chain list.

[0079] Traditional taint analysis often employs forward data flow analysis, which is costly and lacks the ability to trace back the entry link from the risk point. This invention uses parallel reverse call tracing to trace back from the physical sink to the top layer, filtering out links that truly have user-controllable input.

[0080] In this step, the Java-side verb node is java.chain.link. Input the following configuration:

[0081] "inputs": { "sink": {

[0082] "from":"full_sink_find","key":"physical_sink_functions",

[0083] "split":"lines","unique":true,"limit":50,"each":true},

[0084] "fanout_max": 3}

[0085] Receive the physical sink list output from the upstream, split the physical sink list line by line according to the configuration, each:true declares that each item is fan-out processed in parallel, and the maximum concurrency of parallel processing is configured fanout_max=3 to control the consumption of hardware resources.

[0086] For each physical sink record, a text search tool is used to locate the class, method, and line number of the physical sink; the caller is searched upwards layer by layer, continuously traversing the call relationship until the top-level method with no upper-level caller is found.

[0087] Determine the source of parameters for the top-level method: determine whether the input parameters of the top-level method come from one of the four types of external inputs: HTTP request, message queue, RPC, or file upload; set the exist_source flag to indicate whether there is a user-controllable entry point for this link.

[0088] Node output aggregation declarations are filtered by conditions:

[0089] "outputs": { "passthrough": true, "fields": [

[0090] {"as":"links","from":"links","agg":"join","where":{"key":"exist_source","op":"contains","value":"is"}} ]}

[0091] After all parallel subtasks are processed, aggregation filtering is performed based on the output configuration. Links whose `exist_source` flag is not "yes" are filtered out, and only links with user-controllable entry points are retained, resulting in a link list. Each record in the link list contains an entry identifier and hop-by-hop link information; the format of each hop in the hop-by-hop link record is relative file path, line number, package name, class name, and method name. The link list flows downstream to the link break compensation module.

[0092] This step traces the entire call chain backward from the physical sink, filters out invalid paths that are not affected by external user input, reduces the data scale for subsequent analysis, and improves overall detection efficiency.

[0093] In this preferred embodiment, considering the complexity of source code call relationships, some links cannot be fully traced back through retrieval, resulting in broken links and loss of logical vulnerability links; the present invention fills in the broken links through semantic compensation inference, while performing validity verification, taking into account both recall rate and false positive suppression.

[0094] The verb node for this step is full.chain.augment. Read the chain list output from step S4 and identify unlinked physical sinks that failed to connect due to reverse call tracing failures or the lack of valid call chains.

[0095] For physical sinks that have not been successfully linked, semantic compensation inference is performed: combining the project context and the business semantics of the original semantic sink, the potential candidate call entry paths of the physical sink are inferred.

[0096] The candidate links obtained from the inference are validated to verify whether they actually exist in the source code call relationships. Valid compensation links that have been verified are added to the original link list; candidate links that are verified as invalid are discarded and not added to the link list to avoid introducing false links and causing false alarms.

[0097] The complete list of links, updated after the link breakage compensation, is then transmitted to the downstream link-by-link analysis stage.

[0098] This invention effectively overcomes the limitations of static analysis tools, improves the link discovery rate of complex code structures, and enables more potential attack paths to be discovered and analyzed.

[0099] In step S5, the list of links is parsed one by one, the missing class and method definitions are filled in, the security control deficiencies are analyzed at each link, and the structured vulnerability detection results are output.

[0100] Because existing technologies rely solely on data flow reachability and function signature matching to determine vulnerabilities, they cannot assess business logic flaws related to permissions, parameters, and interception. This invention completes the code context link by link, conducts security assessments at the business logic level, and outputs standardized vulnerability results.

[0101] Specific content:

[0102] The verb node for this step is java.audit.logic, the underlying layer is the analytical agent, and the input configuration is as follows:

[0103] "inputs": { "link":

[0104] {"from":"n_6","key":"links","split":"lines","unique":true,"limit":50,

[0105] "each":true}, "fanout_max": 3}

[0106] Read each link in the link list item by item, read the complete code of the corresponding entry point of the link, and extract the entry parameters and parameter source information.

[0107] Data flow tracing is performed hop-by-hop along the link; when there are missing intermediate methods or classes in the link, the language-level definition parsing tools java_class_define and java_function_define are called to retrieve the source code, complete the missing class and method definitions in the link, and ensure that the analysis process has a complete code context.

[0108] After completing the definition, security assessment is carried out step by step along each node of the link, checking whether there are missing permissions verification, missing parameter filtering, or missing security interception in each link. Taking into account the controllability of the entry parameters, defects in the intermediate processing of the link, and the sensitivity of the physical sink itself, a comprehensive judgment is made on whether there are logical vulnerabilities in the link.

[0109] The defect location is preferentially taken from the last hop of the link, that is, the code location corresponding to the physical sink; if no valid code location is found, a preset placeholder flag unknown:0 is filled in, and it is forbidden to fabricate or make up code line numbers.

[0110] The `has_vulnerability` flag is set to indicate whether a vulnerability exists in this link; the aggregation stage filters links whose `has_vulnerability` flag is not set to indicate no vulnerability. For links determined to have vulnerabilities, a structured vulnerability detection result is output. The structured vulnerability detection result fields include: `has_vulnerability`, `vulnerability_type`, `vulnerability_desc`, `level`, `yanzheng` (verification process / PoC), `location`, and `cwe`.

[0111] This step enables in-depth and intelligent security analysis of each attack chain, not only discovering vulnerabilities but also outputting structured results including type, location, level, and verification process, greatly improving the accuracy and usability of logic vulnerability detection.

[0112] In this preferred embodiment, since the source code syntax and parsing tools of different programming languages ​​differ, it would be costly to completely rewrite the entire detection process for each language. This invention relies on a configurable process orchestration engine, keeping the upper-level process logic unchanged and only replacing the underlying language adaptation tools to achieve cross-language compatibility.

[0113] The verb node in this step is the kind:outcome conclusion node. It receives the structured vulnerability detection results output from the upstream, completes vulnerability aggregation, filters confirmed vulnerabilities, summarizes and generates the final audit report, and can also write confirmed vulnerabilities into the audit knowledge base, recording the vulnerability type and CWE number.

[0114] All processing steps in this invention are scheduled as a whole by a configurable process orchestration engine; each processing unit S1-S5 corresponds to a verb node within the engine, and the verb node implements the business processing logic of the corresponding module; the verb nodes complete field binding, data splitting, item-by-item derivation fan-out, condition aggregation, looping, and branching to complete the data flow.

[0115] When adapting source code inspection tasks for different programming languages, the execution sequence of verb nodes and the field contracts between nodes remain completely unchanged. Only the underlying execution tools for language adaptation in the physical sink mapping and reverse call tracing modules are replaced. Taking C# as an example, the corresponding verb nodes are replaced with full.sink.business, full.sink.dynamic, full.sink.find, cs.chain.link, and cs.audit.logic; Java uses a text retrieval tool, while C# uses a call graph closure reachability tool; the upper-level business logic and input / output fields do not need to be modified, and there is no need to redevelop the business processing flow.

[0116] This step configures the orchestration engine to uniformly schedule all processing logic. Upper-layer business logic is developed once, and multiple programming languages ​​are adapted by replacing the underlying execution tools, which reduces the development and maintenance costs of multi-language adaptation.

[0117] like Figure 3 As shown, this invention can be divided into seven processing modules, with data flowing unidirectionally from top to bottom: the preprocessing and architecture probing module outputs the project context to the semantic sink identification module, which outputs the semantic_sink_list semantic sink list to the physical sink mapping module, the physical sink mapping module outputs the physical_sink_functions physical sink list to the reverse call tracing module, the reverse call tracing module outputs the links list to the link break compensation module, the link break compensation module outputs the updated links list to the link-by-link analysis module, and the link-by-link analysis module outputs the structured vulnerability detection results carrying the has_vulnerability and cwe fields to the vulnerability collection and output module. The inputs and outputs of each module form a complete dependency relationship.

[0118] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A logical vulnerability detection method based on semantic sink to physical sink mapping, characterized in that: Includes the following steps: S1: Obtain the source code of the project to be tested, perform preprocessing and architecture exploration, and obtain the project context including the technology stack, framework type, authentication system and entry point form; S2: Perform business semantic recognition and dynamic logic sink recognition on the project context, merge the interfaces carrying resource identifiers, permission verification points and sensitive operation points, and generate a semantic sink list; S3: Using a loop retry mechanism, each semantic sink in the semantic sink list is derived one by one and mapped to the corresponding physical sink function in a one-to-many manner. The mapping results are aggregated to generate a physical sink list containing class name, method name, position, type and danger level. The loop exit condition is that the physical sink list is not empty. If the physical sink list is not empty after the loop exits, it is output to S4; otherwise, it is terminated. S4: Perform reverse call tracing for each physical sink in the physical sink list, search upwards layer by layer to the top-level method and determine whether the parameters originate from external input, filter user-controllable entry paths, and generate a link list containing entry identifiers and hop-by-hop links; S5: Based on the link list, trace the data flow and complete the missing definitions, analyze the missing information of permission verification, parameter filtering and security interception at each link, and generate a structured vulnerability detection result containing vulnerability type, defect location and verification process.

2. The logical vulnerability detection method based on semantic sink to physical sink mapping as described in claim 1, characterized in that: The business semantic recognition and dynamic logic sink recognition are performed by the audit agent based on the project's business functions. The system identifies interfaces carrying object resource identifiers, ownership verification points before resource read / write operations, and sensitive interfaces in the interceptor whitelist. The identification results are merged, and the semantic sink list, which stores individual business security test points line by line, is output.

3. The logical vulnerability detection method based on semantic sink to physical sink mapping as described in claim 1, characterized in that: The semantic sink list is split, deduplicated, and truncated in number. It adopts a step-by-step derivation method to independently perform physical sink mapping for each semantic sink; wherein, a single semantic sink mapping results in one or more physical sinks.

4. The logical vulnerability detection method based on semantic sink to physical sink mapping as described in claim 1, characterized in that: The maximum number of loop rounds configured for the loop retry mechanism is 3, and the loop exits when the physical Sink list is not empty. If the physical sink list is not generated, the mapping operation is repeated until the maximum number of loops is reached, at which point the loop is forcibly terminated.

5. The logical vulnerability detection method based on semantic sink to physical sink mapping as described in claim 4, characterized in that: After the loop retry is completed, branch and flow determination is performed: When the physical sink list is not empty, perform a reverse call tracing of the physical sink; When the physical sink list is empty, jump directly to the vulnerability collection output.

6. The logical vulnerability detection method based on semantic sink to physical sink mapping as described in claim 1, characterized in that: The reverse call tracing is performed by splitting the data line by line and processing each item in parallel, with a maximum concurrency of 3.

7. The logical vulnerability detection method based on semantic sink to physical sink mapping as described in claim 6, characterized in that: The specific process of the reverse call tracing is as follows: Use a text search tool to locate the class, method and line number of the physical Sink, and then search upwards layer by layer for its caller until you reach the top-level method with no caller. The parameters of the top-level method are determined to be from external inputs such as HTTP requests, message queues, RPCs, or file uploads, in order to determine whether there is a user-controllable entry point.

8. The logical vulnerability detection method based on semantic sink to physical sink mapping as described in claim 1, characterized in that: For unlinked physical sinks that failed to trace back to the reverse call, the validity of the link is verified through semantic compensation inference, and the valid links obtained through compensation are added to the link list.

9. The logical vulnerability detection method based on semantic sink to physical sink mapping as described in claim 1, characterized in that: The step-by-step analysis includes: Read the complete code of the entry method and extract the source of the parameters; trace the data flow hop by hop along the link, and use language-level definition parsing tools to retrieve and complete the definitions of any missing intermediate methods or classes in the link; The system checks each step to determine if there are missing permissions verification, missing parameter filtering, or missing security interception. It also considers the controllability of entry parameters, defects in intermediate processing, and the sensitivity of the sink to determine whether a logical vulnerability exists. The system then outputs a structured detection result that includes the vulnerability type, defect location, risk level, and verification process.

10. The logical vulnerability detection method based on semantic sink to physical sink mapping as described in claim 9, characterized in that: The defect location in the structured detection result is taken from the code location corresponding to the last hop physical sink of the link; If no valid code location is found, a preset placeholder identifier is filled in.

Images