Interface logic vulnerability detection method and device, electronic equipment and storage medium
Patent Information
- Application Number
- CN202611131670.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-28
- Publication Date
- 2026-10-30
AI Technical Summary
[0008]在本公开的一些实施例中,所述对所述状态差异集进行噪音过滤处理,得到残留差异项,包括:针对所述状态差异集中的每个差异项,基于字段类型评分、信息熵评分和变化频率评分的加权求和,确定所述差异项的噪音评分;在所述噪音评分超过预设噪音阈值的情况下,将所述差异项判定为噪音并从所述状态差异集中移除;将移除噪音后所述状态差异集中剩余的差异项作为所述残留差异项
[0019]本公开实施例提供的接口逻辑漏洞检测方法,通过"预检查-攻击-后检查"的三步状态差分验证结合噪音过滤与大语言模型语义判决的双引擎机制,有利于在无需数据库权限的黑盒条件下实现接口逻辑漏洞的自动化检测,并有利于降低误报率。
Smart Images

Figure CN123011699A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of data security technology, specifically to a method, apparatus, electronic device, and storage medium for detecting interface logic vulnerabilities. Background Technology
[0002] Typically, in application programming interface (API) security testing, business logic vulnerabilities (such as unauthorized access and state machine bypass) have always been a challenge for security detection due to their diversity and stealth. Unlike injection vulnerabilities, the request packets of these vulnerabilities usually fully comply with protocol specifications, making them difficult to intercept with traditional network protection devices. The core of detection lies in verifying whether the attack has caused unexpected business consequences.
[0003] State difference analysis is a verification method based on black-box observation, which infers the actual impact of an attack by comparing snapshots of the system state before and after the attack. However, in web environments, response data often contains a large number of non-business-related noise fields (such as server timestamps, tracing identifiers, etc.), and direct difference calculations will produce a high false positive rate.
[0004] The detection solutions in related technologies have the following shortcomings: Fuzzy testing solutions based on response status codes only determine success based on HTTP response codes, failing to identify common "soft failure" mechanisms in modern applications (i.e., returning a success status code but the response body contains an error code), and cannot verify whether the attack actually caused business impact. Solutions based on database log auditing require real-time access to the underlying database execution logs. In microservice, containerized, or cloud-native environments, testers typically cannot access the data layer, making deployment under black-box conditions difficult. Detection solutions based on a full-process large language model delegate policy generation, attack execution, and result determination entirely to the large language model. Token consumption increases linearly with the amount of testing, and the probabilistic output characteristics of the large language model can lead to inconsistent results for the same test case, making it difficult to support enterprise regression testing acceptance. Furthermore, simple difference solutions in related technologies cannot distinguish between changes in business fields and changes in noisy fields, resulting in a high false positive rate.
[0005] Therefore, there is an urgent need to provide an interface logic vulnerability detection solution that can solve at least one of the above technical problems. Summary of the Invention
[0006] This disclosure provides at least one solution for detecting interface logic vulnerabilities.
[0007] In a first aspect, this disclosure provides an interface logic vulnerability detection method, comprising: acquiring target interface information; performing a pre-inspection step, including: acquiring a pre-attack state snapshot of the target resource through a probe interface; performing an attack step, including: generating an attack payload and sending an attack request to the target interface; performing a post-inspection step, including: acquiring a post-attack state snapshot of the target resource through the probe interface; calculating a state difference set based on the pre-attack state snapshot and the post-attack state snapshot; performing noise filtering on the state difference set to obtain residual difference items; and performing semantic judgment on the residual difference items using a large language model to obtain a vulnerability determination result.
[0008] In some embodiments of this disclosure, the step of performing noise filtering on the state difference set to obtain residual difference items includes: for each difference item in the state difference set, determining a noise score for the difference item based on a weighted sum of a field type score, an information entropy score, and a change frequency score; if the noise score exceeds a preset noise threshold, determining the difference item as noise and removing it from the state difference set; and using the remaining difference items in the state difference set after removing the noise as the residual difference items.
[0009] In some embodiments of this disclosure, the noise filtering process also applies at least one of the following filtering rules: a time noise filtering rule that identifies and ignores fields that conform to a preset time format; a dynamic token filtering rule that identifies fields with high entropy values that change continuously in multiple requests and adds them to a filtering whitelist; and a harmless state change filtering rule that discards the corresponding difference item if the field change only occurs in a preset set of harmless fields.
[0010] In some embodiments of this disclosure, generating the attack payload includes: performing a complexity assessment on the target parameters of the target interface to obtain a complexity assessment value; if the complexity assessment value exceeds a preset complexity threshold, generating a semantic attack payload using a large language model engine; and if the complexity assessment value does not exceed the preset complexity threshold, generating the attack payload using a rule engine based on a preset mutation matrix.
[0011] In some embodiments of this disclosure, the complexity evaluation value is determined based on a weighted sum of field semantic depth score, context dependency score, and state machine indicator value. The field semantic depth score is determined according to the parameter type: simple types correspond to a first-tier score, enumerated types to a second-tier score, business object reference types to a third-tier score, and state machine fields to a fourth-tier score, with the first-tier score increasing sequentially to the fourth-tier score. The context dependency score is determined based on the number of dependencies between parameters: independent fields correspond to low scores, and cross-interface dependencies correspond to high scores. The state machine indicator value takes a first value when the parameter is a state machine field and a second value when the parameter is a non-state machine field.
[0012] In some embodiments of this disclosure, the generation of semantic attack payloads using a large language model engine includes employing at least one of the following control strategies: an input constraint layer that embeds output format constraints and available value ranges into input prompt information; an output verification layer that performs format verification and type conversion on the output of the large language model engine; a consistency guarantee layer that uses deterministic sampling parameters and a fixed random seed to ensure that the results of multiple outputs are reproducible; and a fallback mechanism layer that, if the output verification of the large language model engine fails, falls back to the rule engine to generate the attack payload.
[0013] In some embodiments of this disclosure, the probe interface is determined by: obtaining the interface specification information of the target interface; extracting interface node and parameter information based on the interface specification information; semantically annotating the parameter information to determine the parameter semantic type; extracting the read-write dependency relationship between interfaces based on the matching relationship between response fields and request parameters; and automatically establishing a probe association mapping between the write interface and the read interface based on the read-write dependency relationship between interfaces to obtain the probe interface.
[0014] In some embodiments of this disclosure, the parameter semantic type includes at least one of the following: resource identifier type, used to match a field of resource identifier pattern; ownership field type, used to match a field of ownership attribute pattern; state machine field type, used to match a field of state or stage attribute pattern; time noise type, used to match a field of timestamp pattern; and dynamic token type, used to match a field of token or request identifier pattern.
[0015] In some embodiments of this disclosure, the step of using a large language model to perform semantic judgment on the residual difference items to obtain a vulnerability determination result includes: generating a difference summary based on the residual difference items; concatenating the difference summary with the context information and semantic type information of the target interface to obtain a hazard assessment prompt; and inputting the hazard assessment prompt into the large language model to obtain the vulnerability determination result and the corresponding determination confidence level.
[0016] Secondly, this disclosure provides an interface logic vulnerability detection device, comprising: a pre-inspection module for obtaining a snapshot of the target resource's pre-attack state through a probe interface; an attack execution module for generating an attack payload and sending an attack request to the target interface; a post-inspection module for obtaining a snapshot of the target resource's post-attack state through the probe interface; a difference calculation module for calculating a state difference set based on the pre-attack state snapshot and the post-attack state snapshot; a noise filtering module for performing noise filtering processing on the state difference set to obtain residual difference items; and a semantic decision module for performing semantic decision on the residual difference items using a large language model to obtain a vulnerability determination result.
[0017] Thirdly, embodiments of this disclosure provide an electronic device, including: a memory and a processor, the memory and the processor being connected; the memory being used to store a computer program; and the processor being used to invoke the computer program stored in the memory to perform any of the methods described above.
[0018] Fourthly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when run by a computer, performs any of the methods described above.
[0019] The interface logic vulnerability detection method provided in this disclosure uses a dual-engine mechanism of "pre-check-attack-post-check" three-step state differential verification combined with noise filtering and large language model semantic judgment. This facilitates the automated detection of interface logic vulnerabilities under black-box conditions without database permissions and helps reduce the false positive rate. Attached Figure Description
[0020] To more clearly illustrate the technical solutions in this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0021] Figure 1 A schematic diagram of the overall system architecture provided in this disclosure embodiment; Figure 2 This is a schematic diagram of a three-step SDA verification process provided in an embodiment of the present disclosure; Figure 3 This is a schematic diagram of an automatic ADG map construction process provided in an embodiment of the present disclosure; Figure 4 This is a schematic diagram of a dual-engine load generation logic provided in an embodiment of the present disclosure; Figure 5A schematic diagram of a large language model illusion control mechanism architecture provided in this embodiment of the disclosure; Figure 6 A schematic diagram of a hybrid state difference analysis architecture provided in this disclosure embodiment; Figure 7 This is a schematic diagram of an interface logic vulnerability detection device provided in an embodiment of this disclosure. Detailed Implementation
[0022] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.
[0023] The terms “first,” “second,” etc., used in this disclosure are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this disclosure can be implemented in orders other than those illustrated or described herein, and that the objects distinguished by “first,” “second,” etc., are generally of the same class.
[0024] The disclosed solution will be explained and illustrated through specific embodiments below.
[0025] This disclosure provides a method for detecting interface logic vulnerabilities, which can be executed by an interface logic vulnerability detection device. This device can be deployed in a security test server, API gateway, Security Orchestration Automation and Response (SOAR) platform, or DevSecOps continuous integration pipeline. This method achieves black-box automated detection of API business logic vulnerabilities through a three-step verification loop using State Differential Analysis (SDA) combined with a dual-engine collaborative architecture of a deterministic rule engine and a Large Language Model (LLM) engine.
[0026] Figure 1This diagram illustrates the overall system architecture according to an embodiment of the present disclosure. In some possible implementations, the system adopts a distributed functional module architecture. Taking the target API service as input, the system is uniformly scheduled by the task orchestration module (Orchestrator) and distributed downwards to the attack execution module (Fuzzer), the knowledge query module (Analyzer), and the state verification module (Oracle). The knowledge query module, located in the middle layer of the architecture, is responsible for extracting resource type and ownership field information from the API dependency graph (ADG), providing context support for attack execution and state verification. The attack execution module receives test instructions from the task orchestration module and generates semantic attack payloads primarily through rule mutation, supplemented by a large language model. The state verification module is responsible for executing the SDA three-step verification process: first, noise is cleaned using differential and rule-based methods; then, semantic decision-making is performed by the large language model when necessary. The above three modules maintain bidirectional interaction with the bottom ADG graph for semantic annotation, dependency relationship, and probe information synchronization, forming a closed-loop verification chain.
[0027] First, the automatic construction process of ADG maps involved in the embodiments of this disclosure will be described in detail. Figure 3 This diagram illustrates the automated ADG graph construction process according to an embodiment of the present disclosure. The process begins with an interface specification (such as the OpenAPI / Swagger specification or interface information obtained through traffic clustering) and sequentially executes four steps: node parsing, semantic annotation, dependency extraction, and probe association discovery.
[0028] In the node resolution step, the system extracts all interface endpoints, request methods, and parameter information, creating a graph node for each interface. In some possible implementations, the node includes information such as the interface path, request method, parameter list, and response mode.
[0029] In the semantic annotation step, the system performs semantic classification on the parameters of each interface node. In some possible implementations, semantic types include the following five: Resource Identifier type (IDENTIFIER), used to match fields that conform to resource identifier patterns (such as "*_id", "id", "uuid"), used to construct unauthorized access tests; Ownership field type (OWNERSHIP), used to match fields that conform to ownership attribute patterns (such as "owner*", "user_id", "created_by"), which is the core annotation for unauthorized access detection; State Machine field type (STATE_MACHINE), used to match fields that conform to state or phase attribute patterns (such as "status", "state", "phase"), used to trigger state machine mutation in the large language model; Temporal Noise type (TEMPORAL), used to match fields that conform to timestamp patterns (such as "*_at", "timestamp", "time"), which are then automatically filtered; Dynamic Token type (DYNAMIC_TOKEN), used to match fields that conform to token or request identifier patterns (such as "token", "trace_id", "request_id"), which are then automatically filtered.
[0030] In the dependency extraction step, the system extracts dependencies between interfaces based on the rule of "matching response fields with request parameters." Specifically, it iterates through each pair of interface nodes. If the response pattern of one interface contains a certain field, and the field name matches the request parameter name of another interface, a directed edge is established between the two interface nodes, and the dependency weight is calculated. The dependency weight can be determined based on the importance of the field in the business logic. For example, matching the resource identifier field corresponds to a high weight, while matching optional query parameters corresponds to a low weight.
[0031] In the probe association discovery step, the system identifies write-to-read probe associations and automatically establishes the probe interface mappings required for state verification. Specifically, for source nodes (write interfaces, such as POST / PUT / DELETE methods) and target nodes (read interfaces, such as GET methods) in a directed edge dependency relationship, the system automatically establishes the probe association between them and injects the output fields of the write interface into the path parameters or query parameters of the read interface. Through the above automatic construction process, the system can automatically generate a complete API dependency graph G = (V, E, A) from the interface specification, where V is the node set, E is the edge set, and A is the annotation set. This graph provides semantic support for subsequent attack execution and state verification.
[0032] In some possible implementations, the probe interface is determined in the following way: Obtain the interface specification information of the target interface; based on the interface specification information, extract the interface node and parameter information; perform semantic annotation on the parameter information to determine the parameter semantic type; based on the matching relationship between response fields and request parameters, extract the read-write dependency relationship between interfaces; based on the read-write dependency relationship between interfaces, automatically establish probe association mapping between the write interface and the read interface to obtain the probe interface.
[0033] The following is combined with Figure 2 The core process of SDA three-step verification in the embodiments of this disclosure will be described in detail. Figure 2 This diagram illustrates a three-step SDA verification process according to an embodiment of the present disclosure. The method may include the following steps: Step 201: Obtain target interface information; Step 202, perform a pre-inspection step, including: obtaining a snapshot of the target resource's pre-attack state through a probe interface; Step 203, execute the attack steps, including: generating an attack payload and sending an attack request to the target interface; Step 204, post-inspection step, includes: obtaining a snapshot of the target resource's post-attack status through the probe interface; Step 205: Calculate the state difference set based on the pre-attack state snapshot and the post-attack state snapshot; Step 206: Perform noise filtering on the state difference set to obtain residual difference items; Step 207: Perform semantic judgment on the residual difference item using a large language model to obtain the vulnerability determination result.
[0034] In steps 201 and 202, target interface information is obtained, and a pre-check step is performed.
[0035] During the pre-check phase, the system calls a probe interface to obtain a snapshot of the target resource's pre-attack state. The probe interface is determined by write-read probes automatically discovered by the ADG graph. In some possible implementations, the probe interface is a read interface that depends on the target write interface. For example, if the target interface is PUT / api / orders / {id} which modifies order status, the ADG graph automatically discovers the associated GET / api / orders / {id} read interface as a probe. The system calls the probe interface to obtain the response and extracts key business field values (such as the status field "status", ownership field "owner_id", etc.) based on ADG annotations, recording this as the pre-attack state snapshot State_A.
[0036] In step 203, the attack step is performed, an attack payload is generated, and an attack request is sent.
[0037] During the attack phase, the system first performs a complexity assessment of the target parameters of the target interface. Figure 4 A schematic diagram of the dual-engine load generation logic according to an embodiment of this disclosure is shown. The system calculates the complexity evaluation value Complexity(f) of the target parameters and selects the load generation engine based on the evaluation result.
[0038] In some possible implementations, the complexity evaluation value is determined by a weighted sum of the following three dimensions: Field semantic depth score, categorized into multiple tiers based on parameter type from low to high—simple types (e.g., integers, strings) correspond to the first tier, enumeration types to the second tier, business object reference types to the third tier, and state machine fields to the fourth tier; Context dependency score, determined by the number of dependencies on the parameter—independent fields without dependencies receive a low score, single dependencies receive a low to medium score, multiple dependencies receive a medium to high score, and cross-interface dependencies receive a high score; State machine indicator value, taking the first value (e.g., 1) when the parameter is a state machine field and the second value (e.g., 0) when the parameter is a non-state machine field. The weights of the three dimensions are configurable parameters, ensuring that the sum of the three is 1.
[0039] When the complexity assessment value exceeds a preset complexity threshold, the system activates the large language model engine (Engine B) to generate semantic attack payloads. The large language model engine combines the interface schema and business context to perform logical reasoning and generate non-standardized attack payloads for specific business scenarios. When the complexity assessment value does not exceed the preset complexity threshold, the system uses the rule engine (Engine A) to generate attack payloads based on a preset mutation matrix, which is suitable for mutations of simple type fields (such as identifier increment, boundary value testing, etc.).
[0040] Figure 5 A schematic diagram of the illusion control mechanism architecture of a large language model according to an embodiment of this disclosure is shown. To address the problem of unstable output of the large language model, the system adopts a four-layer illusion control strategy.
[0041] The first layer is the input constraint layer, which embeds output format constraints (such as JSON Schema) and the range of available values into input prompts, explicitly informing the large language model of the available legal value space, and anchoring the expected output format through a few sample examples.
[0042] The second layer is the output validation layer, which performs format validation (such as JSON Schema validation), type casting, and boundary value checks on the output of the large language model. If the output does not conform to the expected format, it automatically attempts to correct type mismatches or missing fields.
[0043] The third layer is the consistency guarantee layer. It uses low-temperature parameters (such as Temperature=0) for deterministic sampling, combined with a fixed random seed, to ensure that the same input yields reproducible output results in multiple calls. In some possible implementations, a multiple sampling voting mechanism can also be used to select the output with the highest frequency as the final result.
[0044] The fourth layer is the fallback mechanism layer. If the verification of the first three layers fails, it automatically falls back to the rule engine to generate attack payloads, ensuring that the system has usable payload outputs under any circumstances and avoiding detection interruption due to abnormal output of large language models.
[0045] After generating the attack payload, the system sends an attack request to the target interface. The attack request can be constructed in ways including but not limited to: replacing user credentials in the request (such as replacing the Cookie or Authorization header to simulate unauthorized access), modifying parameter values in the request body (such as modifying the resource identifier to attempt to access other users' resources), or sending non-standard status transition parameters (such as skipping the payment step and directly requesting a refund status).
[0046] In steps 204 and 205, a post-check step is performed to calculate the state difference set.
[0047] In the post-check phase, the system again calls the probe interface to obtain the post-attack state snapshot State_B of the target resource. The system compares the pre-attack state snapshot State_A with the post-attack state snapshot State_B, and calculates the state difference set Δ = State_B - State_A. Each difference item di in the difference set records the field path, the pre-attack value, the post-attack value, and the change type (added, modified, deleted).
[0048] In step 206, noise filtering is performed on the state difference set.
[0049] Figure 6 A schematic diagram of a hybrid state difference analysis architecture according to an embodiment of this disclosure is shown. The system adopts a two-layer "funnel" analysis architecture, with the first layer being deterministic rule filtering and the second layer being semantic decision-making based on a large language model.
[0050] In the first layer, the system calculates a noise score for each difference item di in the state difference set Δ. In some possible implementations, the noise score NS(di) is determined based on a weighted sum of the following three dimensions: Type Score: Based on the noise probability of the field type. Field types conforming to timestamp format and UUID / token format correspond to a high noise probability, while business enumeration types correspond to a low noise probability.
[0051] Entropy Score: Noise probability based on information entropy. The information entropy of the field value is calculated using the formula H(di) = -Σ p(x) × log2(p(x)). High entropy values (close to random distribution) correspond to high noise probability, while low entropy values (orderly or regular) correspond to low noise probability.
[0052] Frequency Score: The probability of noise based on the frequency of change. Fields that change with every request correspond to a high probability of noise, while fields that change infrequently or only under specific conditions correspond to a low probability of noise.
[0053] The weights of the three dimensions are configurable parameters, and their sum must be 1. When the noise score of a difference item exceeds a preset noise threshold, the difference item is identified as noise and removed from the difference set.
[0054] In addition, the first layer also applies the following deterministic noise filtering rules: Time noise cancellation rules automatically identify and ignore fields in ISO 8601 or Unix timestamp format (such as "updated_at", "created_at", etc.). Dynamic token filtering rules identify fields with high entropy values that change with each request (such as "trace_id", "csrf_token", "request_id", etc.), add them to a temporary whitelist and filter them; The harmless state change filtering rule is to discard fields directly based on prior knowledge if the change in the difference item only involves fields in the ADG spectrum that have been marked as noise fields.
[0055] In step 207, a large language model semantic decision is made on the residual difference terms.
[0056] The second-layer semantic decision of the large language model is triggered only when there are still unexplained residual differences after the first-layer filtering. The system first generates a difference summary based on the residual differences, describing which fields have changed in what way. Then, the difference summary is concatenated with the context information of the target interface (such as interface endpoint, method, and semantic type annotation) to construct a hazard assessment prompt. The structure of the prompt can include: context information (API endpoint, semantic type), scenario description (description of attack action, description of result change), judgment question (whether the difference indicates unauthorized access or abnormal state change), and output constraints (requiring the judgment result and confidence level to be output in a structured format).
[0057] After inputting the hazard assessment information into the large language model, the vulnerability determination result and the corresponding determination confidence level (ranging from 0.0 to 1.0) are obtained. The determination result can include: vulnerability type (such as BOLA privilege escalation, state machine bypass, etc.), severity level, impact description, and remediation recommendations. Through semantic judgment, the system can translate technical-level field differences into business-level risk descriptions, improving the interpretability of the determination result.
[0058] Steps 201 to 207 above describe the core process of the interface logic vulnerability detection method of this disclosure embodiment. Black-box detection without database permissions is achieved through the SDA three-step verification closed loop, and the false positive rate is reduced while controlling computational costs through a dual-engine funnel-shaped analysis architecture of "rule engine noise filtering + large language model semantic judgment".
[0059] The embodiments of this disclosure will be further described below in conjunction with specific application scenarios.
[0060] Scenario 1: BOLA unauthorized access detection.
[0061] Taking an unauthorized order access scenario as an example. In the pre-inspection phase, user A calls the GET / api / orders / 123 probe interface using their credentials to obtain a snapshot of the pre-attack state, recording owner_id=A and status=pending. In the attack phase, user B calls PUT / api / orders / 123 using their own credentials to attempt to change the order status to shipped (i.e., attempt to modify user A's order). Since the order identifier "123" is a simple integer type, the complexity evaluation value is below the threshold, and the system uses the rule engine to generate the attack payload (credential replacement + status value modification). In the post-inspection phase, GET / api / orders / 123 is called again to obtain a snapshot of the post-attack state, revealing that the status field has changed from pending to shipped. In the noise filtering phase, the "status" field's type score is a business enumeration type (low noise probability), its entropy score is low (limited enumeration values), and its frequency score is low (not changing every time). Therefore, the NS score is below the noise threshold and is retained as a valid difference. During the semantic decision-making phase, the large language model identified an unauthorized change to the status field (user B should not be able to modify user A's order status), and determined that a BOLA privilege escalation vulnerability existed.
[0062] Scenario 2: State machine bypasses attack detection.
[0063] Taking an order refund state machine bypass scenario as an example, the legal state transition defined by the business logic is: pending → paid → shipped → refunded. During the complexity assessment phase, the target parameter "status" has a high semantic depth score (state machine field), a medium context dependency score (state field of a single interface but with business flow constraints), and a state machine indicator value of 1. Therefore, the complexity assessment value exceeds the threshold, triggering the large language model engine. Under the illusion control mechanism (injecting legal state machine values into the input constraint layer, deterministic sampling with Temperature=0, and validating the JSON format in the output verification layer), the large language model generates a semantic attack payload, such as attempting to directly jump from the pending state to the refunded state with a flag indicating skipping payment. After sending this payload, the order status changes directly from pending to refunded, skipping the intermediate states of paid and shipped. During the semantic judgment phase, the large language model identifies that this state change violates the business-defined state transition rules and determines that a state machine bypass vulnerability exists.
[0064] Scenario 3: Automatic discovery of probe interfaces.
[0065] Taking the Order Management API group as an example, this illustrates the probe association discovery process of the ADG graph. The system extracts interface nodes from the OpenAPI specification, identifying POST / api / orders as the write interface (creating orders) and GET / api / orders / {id} as the read interface. In the dependency extraction step, the system discovers that the response to POST / api / orders contains an "id" field, and the path parameters of GET / api / orders / {id} also contain the "{id}" parameter. These match, establishing a write-to-read dependency edge. In the probe association discovery step, the system identifies this dependency relationship as Write→Read type, automatically establishing GET / api / orders / {id} as the probe interface for both POST / api / orders and PUT / api / orders / {id}, and injecting the "id" value from the POST response into the path parameters of the probe interface. This completes the probe mapping required for status verification without manual configuration.
[0066] Figure 7 As shown, this disclosure provides an interface logic vulnerability detection device, which can execute the interface logic vulnerability detection method of any embodiment of this disclosure. The device may include a pre-inspection module 701, an attack execution module 702, a post-inspection module 703, a difference calculation module 704, a noise filtering module 705, and a semantic decision module 706. Wherein: The pre-inspection module 701 is used to obtain a snapshot of the target resource's pre-attack state via a probe interface; Attack execution module 702 is used to generate attack payloads and send attack requests to the target interface; The post-inspection module 703 is used to obtain a snapshot of the target resource's post-attack status through the probe interface; The difference calculation module 704 is used to calculate a set of state differences based on the pre-attack state snapshot and the post-attack state snapshot. Noise filtering module 705 is used to perform noise filtering on the state difference set to obtain residual difference items; The semantic decision module 706 is used to perform semantic decision on the residual difference item using a large language model to obtain the vulnerability determination result.
[0067] Optionally, the step of performing noise filtering on the state difference set to obtain residual difference items includes: for each difference item in the state difference set, determining a noise score for the difference item based on a weighted sum of field type score, information entropy score, and change frequency score; if the noise score exceeds a preset noise threshold, determining the difference item as noise and removing it from the state difference set; and using the remaining difference items in the state difference set after removing noise as the residual difference items.
[0068] Optionally, the noise filtering process also applies at least one of the following filtering rules: a time noise filtering rule that identifies and ignores fields that conform to a preset time format; a dynamic token filtering rule that identifies fields with high entropy values that change continuously in multiple requests and adds them to a filtering whitelist; and a harmless state change filtering rule that discards the corresponding difference item if the field change only occurs in a preset set of harmless fields.
[0069] Optionally, generating the attack payload includes: evaluating the complexity of the target parameters of the target interface to obtain a complexity evaluation value; generating a semantic attack payload using a large language model engine when the complexity evaluation value exceeds a preset complexity threshold; and generating the attack payload based on a preset mutation matrix using a rule engine when the complexity evaluation value does not exceed the preset complexity threshold.
[0070] Optionally, the complexity evaluation value is determined based on a weighted sum of the field semantic depth score, the context dependency score, and the state machine indicator value; wherein, the field semantic depth score is determined according to the parameter type, with simple types corresponding to the first tier score, enumeration types corresponding to the second tier score, business object reference types corresponding to the third tier score, and state machine fields corresponding to the fourth tier score, and the scores from the first tier to the fourth tier score increase sequentially; the context dependency score is determined according to the number of dependencies of the parameter, with independent fields corresponding to low scores and cross-interface dependencies corresponding to high scores; the state machine indicator value takes the first value when the parameter is a state machine field and the second value when the parameter is a non-state machine field.
[0071] Optionally, the generation of semantic attack payloads using a large language model engine includes at least one of the following control strategies: an input constraint layer that embeds output format constraints and available value ranges into input prompt information; an output verification layer that performs format verification and type conversion on the output of the large language model engine; a consistency guarantee layer that uses deterministic sampling parameters and a fixed random seed to ensure that the results of multiple outputs are reproducible; and a fallback mechanism layer that, if the output verification of the large language model engine fails, falls back to the rule engine to generate the attack payload.
[0072] Optionally, the probe interface is determined by: obtaining the interface specification information of the target interface; extracting interface node and parameter information based on the interface specification information; semantically annotating the parameter information to determine the parameter semantic type; extracting the read-write dependency relationship between interfaces based on the matching relationship between response fields and request parameters; and automatically establishing a probe association mapping between the write interface and the read interface based on the read-write dependency relationship between interfaces to obtain the probe interface.
[0073] Optionally, the parameter semantic type includes at least one of the following: resource identifier type, used to match a field with a resource identifier pattern; ownership field type, used to match a field with an ownership attribute pattern; state machine field type, used to match a field with a state or stage attribute pattern; time noise type, used to match a field with a timestamp pattern; and dynamic token type, used to match a field with a token or request identifier pattern.
[0074] Optionally, the step of using a large language model to perform semantic judgment on the residual differences to obtain a vulnerability determination result includes: generating a difference summary based on the residual differences; concatenating the difference summary with the context information and semantic type information of the target interface to obtain a hazard assessment prompt; and inputting the hazard assessment prompt into the large language model to obtain the vulnerability determination result and the corresponding determination confidence level.
[0075] For the apparatus embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The apparatus embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of at least one embodiment of the present disclosure. Those skilled in the art can understand and implement this without creative effort.
[0076] On the other hand, embodiments of this disclosure provide an electronic device, including: a memory and a processor, wherein the memory and the processor are connected; Memory, used to store computer programs; A processor is used to invoke a computer program stored in memory to perform any of the above methods.
[0077] On the other hand, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when run by a computer, performs any of the methods described above.
[0078] The interface logic vulnerability detection method, apparatus, electronic device, and storage medium provided in this disclosure, through a three-step state differential verification of "pre-check-attack-post-check" combined with a dual-engine mechanism of noise filtering and semantic judgment of a large language model, are conducive to achieving automated detection of interface logic vulnerabilities under black-box conditions without database permissions, and are also conducive to reducing false positive rates.
[0079] It should be noted that the content of the method embodiments and device embodiments provided in this disclosure corresponds one-to-one with each other. The content involved in any embodiment can be referenced or combined with other embodiments to form a part of that embodiment. For ease of description, this disclosure focuses on explaining and illustrating the method embodiments. The description of the relevant technical features and solutions of the system, electronic device, and computer-readable storage medium embodiments can be referred to the relevant content in the method embodiments.
[0080] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, apparatus, systems, electronic devices, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.
[0081] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0082] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0083] Obviously, those skilled in the art can make various modifications and variations to this disclosure without departing from its spirit and scope. Therefore, if such modifications and variations fall within the scope of the claims of this disclosure and their equivalents, this disclosure is also intended to include such modifications and variations.
Claims
1. A method for detecting interface logic vulnerabilities, characterized in that, include: Obtain target interface information; Perform pre-inspection steps, including: obtaining a snapshot of the target resource's pre-attack state via a probe interface; The attack steps include: generating an attack payload and sending an attack request to the target interface; The post-attack inspection steps include: obtaining a snapshot of the target resource's post-attack status through the probe interface; Based on the pre-attack state snapshot and the post-attack state snapshot, calculate the state difference set; The state difference set is subjected to noise filtering to obtain residual difference terms; For the residual differences, a large language model is used to perform semantic judgment to obtain the vulnerability determination result.
2. The method according to claim 1, characterized in that, The noise filtering process performed on the state difference set to obtain residual difference items includes: For each difference item in the state difference set, a noise score is determined based on a weighted sum of field type score, information entropy score, and change frequency score. If the noise score exceeds a preset noise threshold, the difference item is identified as noise and removed from the state difference set; The remaining difference items in the state difference set after removing noise are taken as the residual difference items; The noise filtering process also applies at least one of the following filtering rules: Identify and ignore time noise filtering rules for fields that conform to a preset time format; Dynamic token filtering rules that identify fields with high entropy values that change continuously across multiple requests and add them to a filtering whitelist; Additionally, there is a harmless state change filtering rule that discards the corresponding difference item if the field change only occurs in a preset set of harmless fields.
3. The method according to claim 1, characterized in that, The generated attack payload includes: The complexity of the target parameters of the target interface is evaluated to obtain the complexity evaluation value; If the complexity evaluation value exceeds a preset complexity threshold, a semantic attack payload is generated using a large language model engine. If the complexity assessment value does not exceed the preset complexity threshold, the attack payload is generated using a rule engine based on a preset mutation matrix.
4. The method according to claim 3, characterized in that, The complexity evaluation value is determined based on a weighted sum of field semantic depth score, context dependency score, and state machine indication value; The semantic depth score of the field is determined according to the parameter type. Simple types correspond to the first level of score, enumeration types correspond to the second level of score, business object reference types correspond to the third level of score, and state machine fields correspond to the fourth level of score. The scores of the first level to the fourth level increase sequentially. The context dependency score is determined based on the number of dependencies of the parameters, with low scores for independent fields and high scores for cross-interface dependencies; The state machine indication value takes a first value when the parameter is a state machine field and a second value when the parameter is not a state machine field.
5. The method according to claim 3, characterized in that, The generation of semantic attack payloads using a large language model engine includes at least one layer of control strategy: The input constraint layer embeds output format constraints and the range of available values into input prompts. The output validation layer performs format validation and type conversion on the output of the large language model engine; The consistency guarantee layer uses deterministic sampling parameters and a fixed random seed to ensure that the results of multiple outputs are reproducible. In the fallback mechanism layer, if the output verification of the large language model engine fails, the system falls back to the rule engine to generate the attack payload.
6. The method according to claim 1, characterized in that, The probe interface is determined in the following way: Obtain the interface specification information of the target interface; Based on the interface specification information, extract the interface node and parameter information; The parameter information is semantically annotated to determine the parameter semantic type; Based on the matching relationship between response fields and request parameters, extract the read and write dependencies between interfaces; Based on the read / write dependency relationship between the interfaces, a probe association mapping between the write interface and the read interface is automatically established to obtain the probe interface; The parameter semantic type includes at least one of the following: Resource identifier type, a field used to match resource identifier patterns; Ownership field type, used to match ownership attribute patterns; State machine field type, used to match state or stage attribute patterns; Time noise type, used to match fields with timestamp patterns; And a dynamic token type, a field used to match token or request identifier patterns.
7. The method according to claim 1, characterized in that, The step of using a large language model to perform semantic judgment on the residual differences to obtain vulnerability determination results includes: A difference summary is generated based on the residual difference items; The difference summary is concatenated with the context information and semantic type information of the target interface to obtain the hazard assessment prompt information; The hazard assessment information is input into the large language model to obtain the vulnerability determination result and the corresponding determination confidence level.
8. An interface logic vulnerability detection device, characterized in that, include: The pre-inspection module is used to obtain a snapshot of the target resource's pre-attack state via a probe interface; The attack execution module is used to generate attack payloads and send attack requests to the target interface; The post-inspection module is used to obtain a snapshot of the target resource's post-attack status through the probe interface; The difference calculation module is used to calculate the state difference set based on the pre-attack state snapshot and the post-attack state snapshot; A noise filtering module is used to perform noise filtering on the state difference set to obtain residual difference items; The semantic decision module is used to perform semantic decision-making on the residual differences using a large language model to obtain the vulnerability determination result.
9. An electronic device, characterized in that, include: Memory and processor, and the connection between memory and processor; Memory, used to store computer programs; A processor for invoking a computer program stored in memory to perform the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a computer, performs the method as described in any one of claims 1 to 7.
