Method and system for detecting logical vulnerabilities based on multi-session and dynamic payload

Abstract

The application belongs to the technical field of network security and software security testing, and provides a logical vulnerability detection method and system based on multiple sessions and dynamic Payloads, the method comprising: listening to request messages of at least two users; using a large language model (LLM) to perform semantic analysis on the request messages, and identifying the function type; matching potential logical vulnerability types in a vulnerability knowledge base; dynamically generating test Payloads for each vulnerability type in combination with business data and authentication information; sending the Payloads and checking the responses, and outputting the detection results. The application realizes cross-user difference analysis through multiple session simulation, intelligently understands business functions by using the LLM, and dynamically generates targeted Payloads based on the context, thereby solving the problems of low automation, poor efficiency and insufficient coverage in logical vulnerability detection in traditional methods, and significantly improving the automation, intelligence level and accuracy of logical vulnerability detection.

Description

Technical Field

[0001] This invention belongs to the field of network security and software security testing technology, and relates to a logical vulnerability detection method and system based on multi-session and dynamic payload. Background Technology

[0002] With the rapid development of internet applications, various application systems (such as e-commerce, online finance, and enterprise office systems) are becoming increasingly widespread, making their security paramount. Although these systems generally employ security measures such as identity authentication and access control mechanisms, a type of security risk that is difficult to detect through traditional methods still exists—application logic vulnerabilities. Logic vulnerabilities stem from flaws in business processes, functional design, or operational logic, allowing attackers to gain unauthorized privileges, bypass restrictions, or compromise system security without triggering traditional security measures. Examples include unauthorized access, horizontal privilege escalation, vertical privilege escalation, permission bypassing, and process bypassing.

[0003] Currently, mainstream automated vulnerability scanning tools (such as AWVS and Burp Suite) primarily target input validation vulnerabilities (such as SQL injection and XSS), detecting application interfaces through pre-built payload libraries. However, these tools struggle to simulate the multi-session interaction behavior of real users and cannot understand the application's business logic, thus exhibiting significant shortcomings in detecting logical vulnerabilities. For example, they can detect SQL injection vulnerabilities in an interface, but cannot determine if a regular user has unauthorized access to another user's orders.

[0004] In practice, current logic vulnerability detection largely relies on manual penetration testing. Security personnel need to manually create multiple accounts, simulate operation paths for different roles, and identify anomalies through manual comparison. While this method has a certain degree of accuracy, it suffers from inefficiency, reliance on subjective experience, difficulty in scaling, and difficulty in knowledge accumulation, making it unsuitable for the rapid iteration needs of modern applications.

[0005] Furthermore, some studies attempt to detect logic vulnerabilities through static analysis or single-session replay, but lack the ability to perform cross-user, multi-session correlation analysis. These studies have the following limitations: limitations in single-session detection, failing to effectively discover privilege escalation vulnerabilities in multi-user scenarios; fixed payload generation methods, relying on predefined rules or templates, lacking dynamic adaptability; low levels of automation and intelligence, making it difficult to cope with rapidly iterating applications; and insufficient results verification dimensions, easily leading to false positives and false negatives.

[0006] Therefore, how to design a detection method that can automatically simulate multi-user sessions, intelligently parse data packets, and dynamically generate payloads targeting logical vulnerabilities based on context has become a pressing technical problem to be solved in this field. Summary of the Invention

[0007] To overcome the technical problems of low automation, insufficient coverage, and high false positive rate in existing technologies for logical vulnerability detection, this invention discloses a logical vulnerability detection method based on multi-session and dynamic payload. This method achieves efficient, accurate, and intelligent automated detection of business logic vulnerabilities such as horizontal privilege escalation, vertical privilege escalation, unauthorized access, permission bypass, and process bypass in single-user and multi-user systems such as web applications and mobile backend APIs through large language model semantic parsing, vulnerability type classification and matching, differentiated payload generation, and automated verification.

[0008] Specifically, the logic vulnerability detection method includes the following steps:

[0009] S101. By using a proxy module deployed on the network path, listen to request messages between at least two user terminals and the server in the target application, wherein the request messages include request parameters, authentication information, business data and session identifier.

[0010] S102. Input each of the request messages into the large language model and perform semantic parsing to identify the corresponding function type;

[0011] S103. For the aforementioned function type, match one or more potential logical vulnerability types in a preset vulnerability knowledge base;

[0012] S104. Based on the business data and the authentication information, dynamically generate a test payload to verify the vulnerability type for each logical vulnerability type;

[0013] S105. Send the test payload to the target application, obtain the corresponding response result, automatically verify the response result based on the preset vulnerability judgment conditions, and output the detection result containing the vulnerability type and verification evidence.

[0014] In one embodiment, the method further includes:

[0015] S106. The logic vulnerability detection results are displayed through a visual interface or exported as a standardized vulnerability report. The vulnerability report includes the vulnerability type, the specific request message that triggered the vulnerability, the generated test payload, the master / slave user session identifiers involved, response evidence, and reproduction path.

[0016] This invention also provides a logical vulnerability detection system based on multi-session and dynamic payload, including a proxy module, a request message parsing module, a vulnerability type location module, a test payload dynamic generation module, and a vulnerability verification module.

[0017] The proxy module is deployed on the network path and is used to listen to request messages between at least two user terminals and the server in the target application. The request messages include request parameters, authentication information, business data and session identifier.

[0018] The request message parsing module is used to input each request message into the large language model and perform semantic parsing to identify the corresponding function type.

[0019] The vulnerability type location module is used to match one or more potential logical vulnerability types for the function type in a preset vulnerability knowledge base;

[0020] The test payload dynamic generation module is used to dynamically generate a test payload to verify the vulnerability type for each logical vulnerability type based on the business data and the authentication information.

[0021] The vulnerability verification module is used to send the test payload to the target application, obtain the corresponding response result, automatically verify the response result based on preset vulnerability judgment conditions, and output the detection result containing the vulnerability type and verification evidence.

[0022] In one embodiment, the system further includes a result output module, which displays the logical vulnerability detection results through a visual interface or exports them as a standardized vulnerability report. The vulnerability report includes the vulnerability type, the specific request message that triggered the vulnerability, the generated test payload, the master / slave user session identifiers involved, response evidence, and reproduction path.

[0023] Compared with the prior art, the present invention has at least the following significant beneficial effects:

[0024] 1. Through a multi-session simulation mechanism, it can perform differentiated comparisons of requests from different users (master / slave users), directly realizing automated detection of typical logical vulnerabilities in multi-user scenarios such as horizontal and vertical privilege escalation. This solves the problem that traditional tools cannot perform cross-session analysis, significantly improving the accuracy and coverage of detection.

[0025] 2. By introducing a Large Language Model (LLM) to perform semantic parsing of request messages, the system automatically identifies their business function types, enabling an understanding of application behavior from a business logic perspective. Vulnerability matching based on functional semantics avoids indiscriminate full-scale blind testing of all requests, significantly reducing redundant probing and improving detection efficiency. Furthermore, the introduction of LLM makes the detection process more intelligent.

[0026] 3. By combining collected multi-user authentication information and business data, a verification payload targeting specific vulnerability types is dynamically generated. This mechanism does not rely on a fixed template, but intelligently combines functional semantics, vulnerability types, and session differences to make the generated payload closer to real attack scenarios, thereby enhancing the payload's targeting and effectiveness. It can effectively cover complex logic vulnerabilities such as process bypass and concurrency competition, improving the completeness and reliability of detection.

[0027] 4. Through automated verification and result output mechanisms, the system not only outputs the vulnerability type but also records the complete trigger request, test payload, involved session identifiers, and response evidence. The generated standardized vulnerability report facilitates security personnel's rapid reproduction and verification of vulnerabilities, greatly improving the efficiency of vulnerability remediation and ensuring the traceability and reproducibility of detection results.

[0028] In summary, the method and system proposed in this invention, through the organic combination of multi-session simulation, LLM semantic parsing, and dynamic payload generation, achieve automation, intelligence, and efficiency in application logic vulnerability detection, effectively overcoming many shortcomings of existing technologies and promoting the development of logic vulnerability detection technology. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This is a flowchart of the logical vulnerability detection method based on multi-session and dynamic payload of the present invention;

[0031] Figure 2 This is an architecture diagram of the logical vulnerability detection system based on multi-session and dynamic payload of the present invention;

[0032] Figure 3 This is a schematic diagram of a computer device disclosed in an embodiment of the present invention;

[0033] Among them, 201 is the proxy module; 202 is the request message parsing module; 203 is the vulnerability type location module; 204 is the dynamic generation module of test payload; 205 is the vulnerability verification module; 206 is the result output module; 301 is the memory; and 302 is the processor. Detailed Implementation

[0034] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0035] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features of the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] To facilitate understanding of the technical solutions of this invention, key terms and abbreviations used in this specification are explained below. Unless otherwise specified, the terms in this specification should be understood according to the definitions in this section.

[0037] Logic vulnerabilities refer to flaws in an application's business processes, functional design, or operational logic. These flaws typically allow attackers to gain unauthorized privileges, bypass access control restrictions, or compromise system security and data integrity by exploiting logical oversights without triggering traditional security mechanisms (such as firewalls and WAFs). Typical logic vulnerabilities include unauthorized access, horizontal privilege escalation, vertical privilege escalation, permission bypass, and process bypass.

[0038] Large Language Models (LLMs) are artificial intelligence models trained on massive amounts of text data, capable of understanding and generating human language. In this invention, it uses deep learning techniques (such as the Transformer architecture) to learn the statistical patterns of language, performs semantic analysis on network request messages, and identifies their corresponding specific business functions (such as "modify user information" or "get order details"). Typical examples include, but are not limited to, ChatGPT, Gemini, Claude, and Llama.

[0039] Payload: In the fields of network security and penetration testing, payload refers to the actual data payload sent by an attacker or detection tool to a target system to trigger specific operations or verify the existence of vulnerabilities. In this invention, it specifically refers to test request data dynamically constructed by the "Test Payload Dynamic Generation Module" based on vulnerability type and session data, used to verify application logic vulnerabilities.

[0040] SQL injection: A common web security vulnerability, which refers to an attacker inserting malicious SQL code snippets into user input (such as forms, URL parameters, cookies, etc.), causing the application to unexpectedly execute the attacker's preset SQL commands when performing database queries, which may lead to data leakage, tampering, or deletion.

[0041] Cross-site scripting (XSS): A common web security vulnerability where attackers inject malicious script code (usually JavaScript) into a webpage. When other users browse the page, the embedded script executes in the user's browser, allowing them to steal user session credentials, redirect pages, or launch phishing attacks.

[0042] A session is a collection of information used to maintain state and identify a user during interactions with an application system over a period of time. It identifies the user and maintains the continuity of user operations. It typically includes a unique session ID, which the server uses to associate multiple user requests, maintaining login state and operational continuity.

[0043] This invention provides a logical vulnerability detection method based on multi-session and dynamic payload. See [link to relevant documentation]. Figure 1 As shown, the logic vulnerability detection method includes the following steps:

[0044] S101. By using a proxy module deployed on the network path, listen to request messages between at least two user terminals and the server in the target application, wherein the request messages include request parameters, authentication information, business data and session identifier.

[0045] S102. Input each of the request messages into the large language model and perform semantic parsing to identify the corresponding function type;

[0046] S103. For the aforementioned function type, match one or more potential logical vulnerability types in a preset vulnerability knowledge base;

[0047] S104. Based on the business data and the authentication information, dynamically generate a test payload to verify the vulnerability type for each logical vulnerability type;

[0048] S105. Send the test payload to the target application, obtain the corresponding response result, automatically verify the response result based on the preset vulnerability judgment conditions, and output the detection result containing the vulnerability type and verification evidence.

[0049] In one embodiment, in step S101 above, when at least two user terminals' interactive traffic is detected, the session of one user terminal is selected as the master user session, and the sessions of the remaining user terminals are slave user sessions. The slave user's privileges are less than or equal to the master user's privileges. The implementation of a vertical privilege escalation vulnerability depends on the slave user's privileges being lower than the master user's, while the implementation of a horizontal privilege escalation vulnerability depends on the master and slave users having equal privileges.

[0050] The session identifiers of the primary user session and the secondary user session are marked and stored respectively for cross-session differential analysis and test payload generation.

[0051] The proxy module uses man-in-the-middle technology to perform traffic mirroring and monitoring without blocking or intercepting normal communication. The proxy module is configured with multiple monitoring ports, each monitoring port corresponding to the collection of interactive traffic from a user terminal. The collected interactive traffic is tagged with the corresponding user and then a tagged request message is generated and stored in the database.

[0052] In one embodiment, in step S102 above, the function type includes at least one of adding a user, registering, logging in, modifying user information, verifying a verification code, obtaining data, or performing a process operation.

[0053] In one embodiment, in step S103 above, the potential logical vulnerability types include logical vulnerabilities in single-user scenarios and logical vulnerabilities in multi-user scenarios. Specifically, logical vulnerabilities in single-user scenarios include unauthorized access, permission bypass, and process bypass, while logical vulnerabilities in multi-user scenarios include horizontal privilege escalation, vertical privilege escalation, and permission bypass.

[0054] The vulnerability knowledge base is a structured database or rule engine that stores the mapping relationship between functional types and potential logical vulnerability types. Each logical vulnerability type is associated with a corresponding payload generation strategy and vulnerability judgment conditions.

[0055] Dynamically generated test payloads include, but are not limited to: parameter replacement based on different user identity information, request replay based on cross-user resource references, access path construction based on user role differences, and request simulation based on timing control, etc. By dynamically generating test payloads, accurate verification of different logical vulnerability types can be achieved, improving the coverage and accuracy of vulnerability detection.

[0056] In one embodiment of dynamically generating test payloads, step S104 above, the method for dynamically generating test payloads for logical vulnerabilities in a multi-user scenario, includes:

[0057] S1041. For horizontal privilege escalation vulnerabilities, under the condition that the master user and the slave user have the same privileges, extract the key resource identifier parameter in the request message of the master user session, replace it with the corresponding resource identifier in the request message of the slave user session, and construct a test payload to simulate the master user accessing the slave user's resources.

[0058] S1042. For vertical privilege escalation vulnerabilities, based on the difference in privilege levels between master users and slave users, construct a test payload that calls the functional interfaces of high-privilege users using the authentication information of low-privilege users.

[0059] S1043. For privilege bypass vulnerabilities, the authentication field is processed by deleting, tampering with or replacing it with invalid values. Combined with parameter obfuscation or abnormal request structure, a test payload is constructed to bypass the system privilege check.

[0060] In another embodiment of dynamically generating test payloads, the method for dynamically generating test payloads for logic vulnerabilities in a single-user scenario in step S104 above includes:

[0061] S1044. For unauthorized access vulnerabilities, construct test payloads that delete, clear, tamper with, or replace authentication fields with invalid credentials.

[0062] S1045. For privilege bypass vulnerabilities, construct test payloads that modify request paths, HTTP methods, or header fields to attempt to access restricted resources.

[0063] S1046. For process bypass vulnerabilities, based on the semantic understanding of normal business processes using a large language model, the function call order is automatically derived, and the pre-verification steps are skipped to directly construct a test payload for subsequent sensitive operation interfaces. The pre-verification steps include verification code verification, identity confirmation, or operation confirmation.

[0064] In one embodiment, the automated verification in step S105 above includes:

[0065] S1051. Determine whether the response result contains data belonging to the user. If it does, it is identified as a horizontal privilege escalation vulnerability.

[0066] S1052. Determine whether the user has successfully executed the master user's authorized operation. If it is successfully executed, it is identified as a vertical privilege escalation vulnerability.

[0067] S1053. Determine whether a legitimate response or sensitive data was obtained without valid authentication information. If so, identify it as an unauthorized access vulnerability.

[0068] S1054. Determine whether the critical business process was completed without the necessary pre-verification steps. If it was completed, it is identified as a process bypass vulnerability.

[0069] S1055. Compare the response results with the historical session responses of the master user and the slave user. If abnormal state transfer or unauthorized behavior is found, it is identified as a privilege bypass vulnerability.

[0070] In one embodiment, see Figure 1 As shown, the method further includes:

[0071] S106. The logic vulnerability detection results are displayed through a visual interface or exported as a standardized vulnerability report. The vulnerability report includes the vulnerability type, the specific request message that triggered the vulnerability, the generated test payload, the master / slave user session identifiers involved, response evidence, and reproduction path.

[0072] Based on the same inventive concept, this invention also provides a logic vulnerability detection system based on multi-session and dynamic payload, as described in the following embodiments. Since the principle by which the application logic vulnerability detection system solves the problem is similar to the logic vulnerability detection method based on multi-session and dynamic payload provided in the above embodiments, the implementation of the application logic vulnerability detection system can refer to the implementation of the application logic vulnerability detection method disclosed in the above embodiments, and repeated details will not be elaborated further. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0073] Figure 2 This is a structural block diagram of a logical vulnerability detection system based on multi-session and dynamic payload disclosed in an embodiment of the present invention, such as... Figure 2 As shown, the application logic vulnerability detection system includes a proxy module 201, a request message parsing module 202, a vulnerability type location module 203, a test payload dynamic generation module 204, and a vulnerability verification module 205. The structure is described below.

[0074] (1) Agent module 201

[0075] This module is deployed on a network path to monitor request messages between at least two client and server interfaces in the target application. These request messages include request parameters, authentication information, business data, and session identifiers. The core function of this module is to simulate multiple sessions and monitor the interaction traffic between the client and server of the target application in real time. This module supports starting multiple listening ports, and the number and purpose of the ports can be managed through a configuration file.

[0076] When a single listening port is configured, that port is used by default for listening to traffic from the main user session.

[0077] When configuring two or more listening ports, you must explicitly specify which port is used for listening to primary user session traffic and which ports are used for listening to secondary user session traffic.

[0078] The collected multi-port traffic is tagged with corresponding user tags (session tags) by the system and stored in the database, providing basic data for subsequent vulnerability detection. Through this multi-session simulation and tokenized storage, this invention can reproduce complex user interaction relationships in real business scenarios, thereby achieving higher-precision logic vulnerability detection.

[0079] By simulating multi-user sessions, the system can not only acquire single-user behavior data but also construct multi-user interaction scenarios, thus providing a data foundation for detecting logical vulnerabilities (such as horizontal privilege escalation, vertical privilege escalation, and privilege bypass). This multi-session simulation capability differs from traditional single-session packet capture or traffic analysis methods, improving the coverage and accuracy of vulnerability detection.

[0080] (2) Request message parsing module 202

[0081] This module is used to input each request message into the Large Language Model (LLM) for semantic parsing and identification of the corresponding function type. This module enables semantic understanding of the request messages at the business logic level, providing a basis for accurate vulnerability type localization. In specific implementation, a custom prompt can be used to input the request messages collected by the proxy module 201 into the Large Language Model (LLM). The LLM utilizes its mature semantic analysis capabilities to locate the function implemented by each request message. For example, when a request message corresponds to the "modify user information" operation, the LLM will output the function type information, record it in the database, and establish an association with the corresponding request message.

[0082] The configuration of the request message parsing module 202 allows for the selective generation of payloads targeting potential logical vulnerabilities in specific functions based on the function types recorded in the database during subsequent vulnerability detection, without requiring a full vulnerability scan of every request message. Compared to traditional vulnerability scanning methods, it offers the following significant advantages:

[0083] a. Reduce the number of packets sent: Only perform verification requests for functions that may have vulnerabilities, avoiding unnecessary full testing.

[0084] b. Improve detection efficiency: Vulnerability location and screening are performed through functional semantics to speed up the detection process.

[0085] c. Enhance accuracy: Conduct targeted testing based on business logic functions to improve the detection rate of logic vulnerabilities.

[0086] In this invention, the semantic understanding capability of the Large Language Model (LLM) is applied to the function recognition of request messages, forming a function-driven vulnerability detection method. This breaks through the traditional blind testing mode of message-by-message in vulnerability scanning tools and realizes intelligent vulnerability localization that is function-oriented and efficiency-first.

[0087] (3) Vulnerability type location module 203

[0088] This module is used to match one or more potential logical vulnerability types for the stated function type in a preset vulnerability knowledge base. During vulnerability detection, the parsed function type is input into the vulnerability type location module 203. This module calls the system's built-in vulnerability knowledge base or matching library to search and compare each type of function in the knowledge base, which can yield vulnerability types such as horizontal privilege escalation, vertical privilege escalation, unauthorized access, permission bypass, and process bypass.

[0089] Through comparative analysis, this module can determine the potential logical vulnerability types that may be associated with each target function, and output these results as input to the test payload dynamic generation module 204 to obtain the test payload output list. Each output item in the output list includes: the request message identifier corresponding to the function; a list of potential vulnerability types; and additional information related to vulnerability detection (such as suspicious parameters, user role restrictions, etc.).

[0090] Function-driven vulnerability matching enables a direct mapping from business functions to vulnerability types, rather than the traditional rule- or template-based blind testing approach. This method offers the following significant advantages:

[0091] a. Reduce invalid vulnerability testing and improve detection efficiency;

[0092] b. Through multi-session functional difference analysis, we can provide a basis for identifying horizontal and vertical privilege escalation vulnerabilities.

[0093] c. Provides targeted input for subsequent dynamic payload generation, enabling high-precision vulnerability verification.

[0094] Through the processing of the above modules, the system can generate clear and structured vulnerability detection targets for each target function, providing a complete data foundation for subsequent dynamic payload generation and vulnerability verification steps.

[0095] (4) Test the Payload dynamic generation module 204

[0096] This module is used to dynamically generate a test payload to verify the vulnerability type for each logical vulnerability type based on the business data and the authentication information.

[0097] During implementation, this module can locate the function of the request message output by the vulnerability type and its corresponding potential vulnerability type. Combining multi-user session information and authentication data, it automatically and dynamically constructs detection requests for verifying logical vulnerabilities. The implementation process of this module includes:

[0098] First, the module receives the target information output by the vulnerability type location module. This target information includes: the request message identifier corresponding to the function; the vulnerability type that the function may be associated with; and parameter information related to the vulnerability (such as user identity identifier, resource ID, role identifier, etc.).

[0099] Secondly, the module employs different dynamic generation strategies based on different vulnerability types, for example:

[0100] For horizontal privilege escalation vulnerabilities: Under the condition that the master user and the slave user have the same permissions, the authentication information and resource identifiers collected from multiple user sessions are used to automatically replace the key parameters in the master session request message with the resource identifiers or credentials of the slave session, and construct a test payload for cross-session resource access to detect whether there is a risk of illegally obtaining or manipulating other people's data.

[0101] For vertical privilege escalation vulnerabilities: By identifying the difference in privilege levels between the master session user and the slave session user, a request message is constructed in which a low-privilege user attempts to call a high-privilege operation. A test payload is dynamically generated to simulate a non-administrator role performing sensitive management operations, thereby detecting whether the privilege boundaries are correctly constrained.

[0102] For unauthorized access and permission bypass vulnerabilities: When generating the test payload, the module will delete or tamper with authentication fields (such as tokens and cookies), or replace them with invalid credentials, to verify whether the target function can still be called or accessed without providing valid credentials.

[0103] For process bypass vulnerabilities: Based on the function call order obtained from the Large Language Model (LLM) analysis, the module automatically skips certain pre-verification steps in the normal business logic (such as the verification step and the payment confirmation step), directly constructs access requests to subsequent sensitive interfaces, generates and sends such test payloads, and is used to detect whether there are critical business process defects in the system.

[0104] In addition, the payload generation module supports the following features in its implementation:

[0105] a. Dynamic parameter combination: Supports dynamic replacement, addition, deletion and recombination of parameters in the request message to ensure the diversity and targeting of the payload;

[0106] b. Multi-session cross-referencing: When generating the payload, make full use of the differences between the main session and the slave session to form a cross-session comparison, thereby more accurately triggering horizontal privilege escalation or role difference vulnerabilities.

[0107] c. Timing and Concurrency Simulation: In specific scenarios, the module can also generate payloads with concurrency characteristics, such as submitting multiple requests simultaneously, to detect possible race conditions or timing bypass vulnerabilities.

[0108] Finally, all generated payloads will be uniformly tagged with the corresponding vulnerability type and bound to the original request message and user session information for storage, serving as input data for the vulnerability verification module.

[0109] This module generates test payloads without relying on fixed templates. Instead, it utilizes a large language model (LLM) to parse functional information, map vulnerabilities to a vulnerability knowledge base, and leverage multi-user session data differences to achieve a dynamic, intelligent, and targeted payload generation mechanism. Compared to traditional vulnerability detection tools that rely on static rules or exhaustive methods, this module significantly reduces redundant detection requests, improves detection efficiency, and enhances the ability to discover business logic vulnerabilities.

[0110] (5) Vulnerability verification module 205

[0111] This module sends the test payload to the target application, obtains the corresponding response, automatically verifies the response based on preset vulnerability determination conditions, and outputs a detection result containing the vulnerability type and verification evidence. The determination process is as follows:

[0112] First, the different types of test payloads generated by the dynamic test payload generation module 204 are sent one by one to the server of the target application, and the corresponding response messages are obtained in real time. The obtained responses include, but are not limited to: HTTP status codes, response body content, redirection information, business return codes, and changes in data fields.

[0113] Secondly, the system's built-in vulnerability assessment criteria (also known as logical vulnerability verification rules) are invoked to automatically verify the target application's response results. This specifically includes the following process:

[0114] 1) Rule matching: Select the corresponding verification rule based on the vulnerability type, for example:

[0115] Horizontal privilege escalation vulnerability: Determine whether the returned result contains data belonging to other users;

[0116] Vertical privilege escalation vulnerability: Determining whether a low-privilege user can successfully execute a high-privilege operation;

[0117] Unauthorized access vulnerability: Detects whether a legitimate response or sensitive data is still obtained without valid credentials;

[0118] Process bypass vulnerability: Determine whether the target function is still executed even when the necessary pre-verification steps are missing.

[0119] 2) Result comparison: The module will compare the response to the verification request with the original session data of the main session and the slave session to identify cross-session data inconsistencies, permission boundary breaches, or abnormal state transfers.

[0120] 3) Evidence Recording: If the verification results indicate the existence of a logical vulnerability, the module will automatically record relevant information, including the vulnerability type, the specific request message that triggered the vulnerability, the master / slave user session identifiers involved, and the corresponding response evidence, and store them in the database.

[0121] Finally, the module outputs the verification results in a structured format for use by the results output module. The verification results can be displayed to security personnel via the console or graphical interface, or exported as a standardized vulnerability report for subsequent reproduction and remediation.

[0122] Unlike traditional vulnerability scanning, this module introduces cross-session comparison and business logic-level rule verification mechanisms during the verification process. It can not only detect low-level protocol or interface errors, but also identify complex permission bypasses and logical defects in multi-user scenarios, thereby significantly improving the accuracy and practicality of vulnerability verification.

[0123] In one embodiment, see Figure 2 As shown, the system also includes a result output module 206, which displays the logical vulnerability detection results through a visual interface or exports them as a standardized vulnerability report. The vulnerability report includes the vulnerability type, the specific request message that triggered the vulnerability, the generated test payload, the master / slave user session identifiers involved, response evidence, and reproduction path.

[0124] The main function of this module is to summarize, format, and visualize the detection results generated by the vulnerability verification module 205, so that security personnel or developers can analyze, reproduce, and remediate them. Specifically, it includes the following processes:

[0125] First, the module obtains structured vulnerability records from the vulnerability verification module 205. These records include: vulnerability type; the request message that triggered the vulnerability and its corresponding payload; the master / slave user session identifiers involved; the response results and verification evidence returned by the application; and additional information such as vulnerability detection time and detection rule source.

[0126] Secondly, the module processes the above detection results, specifically including:

[0127] The results are categorized and aggregated according to vulnerability type, affected functional modules, or user sessions to avoid duplicate output and improve readability. The output includes key request messages triggering the vulnerability, the corresponding payload, and verification response snippets, enabling security personnel to directly reproduce the vulnerability scenario and avoiding issues with unverifiable results.

[0128] Unlike traditional vulnerability detection tools that only output vulnerability names or simple descriptions, this module combines multi-session context and business semantic information to provide more granular and reproducible vulnerability detection results. This not only improves the usability of the detection results but also significantly enhances the efficiency of the vulnerability remediation process.

[0129] This invention takes horizontal privilege escalation vulnerability detection and process bypass vulnerability detection as examples to illustrate the logical vulnerability detection in single-user and multi-user scenarios described in the above methods and systems:

[0130] Example 1: Detection of Horizontal Privilege Escalation Vulnerabilities in Multi-User Scenarios

[0131] Step 1: Proxy module 201 monitors the interaction traffic between the client of primary user A and secondary user B and the target application server, and sets user A's interaction traffic as the primary session traffic. The request messages captured by the proxy module include authentication credentials, request parameters, and business data such as session ID. For example, if user A's message contains the operation path / user / update and request parameters userId=A123,newEmail=xxx@xxx.com, it indicates that user A is modifying their email address.

[0132] Step 2: The request message parsing module 202 performs semantic analysis on the above request message and identifies the function corresponding to the message as "modify user information". The parsing result is stored and associated with the request message for subsequent vulnerability detection steps.

[0133] Step 3: After receiving the function information, the vulnerability type location module 203 searches the vulnerability knowledge base for potential logical vulnerability types related to the "Modify User Information" function. The search results show that the possible vulnerability types for this function include horizontal privilege escalation and vertical privilege escalation. Based on this, the module generates vulnerability detection targets and prioritizes horizontal privilege escalation as the detection item.

[0134] Step 4: In the payload generation stage, the test payload dynamic generation module 204 uses the multi-user session information collected in the proxy module 201 to construct a payload against horizontal privilege escalation.

[0135] Specifically, the parameter `userId=A123` in the main session request message is replaced with `userId=B456` extracted from the user session, forming a new request message " / user / update userId=B456&newEmail=xxx@xxx.com". This message simulates main session user A attempting to modify the email information of secondary session user B to verify the existence of a horizontal privilege escalation vulnerability.

[0136] Step 5: The vulnerability verification module 205 sends the payload to the target application and obtains the return result. If the application's response indicates successful modification, or if the returned information contains the email address of user B, it indicates that the system has not correctly verified the user's identity, and a horizontal privilege escalation vulnerability exists. The module records the detection results, including the vulnerability type (horizontal privilege escalation), the triggering request (the constructed payload), the relevant sessions (user A, user B), and verification evidence (the response message contains user B's email address).

[0137] Step 6: The results output module 206 summarizes and displays the detection results. The system intuitively displays the detected horizontal privilege escalation vulnerabilities on the interface, and the report includes vulnerability details, triggering process, and evidence of reproduction, for security personnel or developers to fix.

[0138] As demonstrated in this embodiment, the method of the present invention can efficiently locate and verify horizontal privilege escalation vulnerabilities by utilizing multi-session simulation and large language model (LLM) semantic parsing. Unlike traditional black-box scanning that attempts each vulnerability one by one, this method dynamically generates a function-driven payload, significantly reducing redundant detection traffic and improving detection efficiency and accuracy.

[0139] Example 2: Detection of Password Retrieval Process Bypass Vulnerability in Single-User Scenario

[0140] Take the password reset process in the "Forgot Password" function on the login page as an example.

[0141] Step 1: Proxy module 201 listens for user F's password reset operation in the target application and captures their complete interaction process. This password recovery process includes the following steps:

[0142] Step 1 / forgetpwd: User F initiates a password reset request;

[0143] Step 2 / sendcode: User F requests to send a verification code to their email or SMS.

[0144] Step 2 / verifycode: The target application requires user F to submit a correct verification code for verification.

[0145] Step 3 / resetpwd: User F submits a new password to the system, completing the password reset operation.

[0146] The proxy module 201 obtains the above request message, which includes information such as session ID, verification parameters, email or mobile phone number and verification code.

[0147] Step 2: The request message parsing module 202 performs semantic parsing on these messages, identifying their functions as "request password reset", "send verification code", "verification code verification", and "submit new password". The parsing results are stored in a one-to-one correspondence with the messages for subsequent vulnerability analysis.

[0148] Step 3: After receiving the semantic information, the vulnerability type location module 203 searches the vulnerability knowledge base and finds that the process belongs to the password reset process. If the application does not enforce verification of the verification code when the user submits a new password, there may be a process bypass vulnerability. Based on this, the system selects "process bypass" as the detection target.

[0149] Step 4: During the payload generation phase, the payload dynamic generation module 204 tests how to construct a payload that bypasses the process based on the collected message data. Specifically, it skips the / verifycode step and directly uses the account information submitted by / sendcode and the returned user identifier to construct a / resetpwd request.

[0150] For example: / resetpwd userphone=phone number&username=F&newpwd=123456, carrying user F's session credentials.

[0151] This payload is used to simulate a scenario where a user resets their password without verifying the CAPTCHA.

[0152] Step 5: The vulnerability verification module 205 sends the payload to the target application and obtains the response. If the system returns a successful password reset, it indicates that the application does not strictly control the process sequence and has a process bypass vulnerability. The module records the detection results accordingly, including the vulnerability type (process bypass), triggering request, related sessions, and verification evidence (response message).

[0153] Step 6: The results output module 206 summarizes and displays the detection results. The system intuitively displays the detected report on the interface, including the trigger path (missing CAPTCHA verification step) and verification evidence (password has been reset but no CAPTCHA record), for security personnel or developers to fix.

[0154] As can be seen from this embodiment, the method of the present invention can utilize the semantic parsing capability of the Large Language Model (LLM) combined with the dynamic generation of payload driven by cross-session data. The present invention can automatically discover and verify process bypass vulnerabilities in various business logic links, demonstrating the versatility and innovation of the detection method.

[0155] In summary, compared with the prior art, the present invention has at least the following significant beneficial effects:

[0156] 1. Through a multi-session simulation mechanism, it can perform differentiated comparisons of requests from different users (master / slave users), directly realizing automated detection of typical logical vulnerabilities in multi-user scenarios such as horizontal and vertical privilege escalation. This solves the problem that traditional tools cannot perform cross-session analysis, significantly improving the accuracy and coverage of detection.

[0157] 2. By introducing a Large Language Model (LLM) to perform semantic parsing of request messages, the system automatically identifies their business function types, enabling an understanding of application behavior from a business logic perspective. Vulnerability matching based on functional semantics avoids indiscriminate full-scale blind testing of all requests, significantly reducing redundant probing and improving detection efficiency. Furthermore, the introduction of the Large Language Model (LLM) makes the detection process more intelligent.

[0158] 3. By combining collected multi-user authentication information and business data, a verification payload targeting specific vulnerability types is dynamically generated. This mechanism does not rely on a fixed template, but intelligently combines functional semantics, vulnerability types, and session differences to make the generated payload closer to real attack scenarios, thereby enhancing the payload's targeting and effectiveness. It can effectively cover complex logic vulnerabilities such as process bypass and concurrency competition, improving the completeness and reliability of detection.

[0159] 4. Through automated verification and result output mechanisms, the system not only outputs the vulnerability type but also records the complete trigger request, test payload, involved session identifiers, and response evidence. The generated standardized vulnerability report facilitates security personnel's rapid reproduction and verification of vulnerabilities, greatly improving the efficiency of vulnerability remediation and ensuring the traceability and reproducibility of detection results.

[0160] In summary, the method and system proposed in this invention, through the organic combination of multi-session simulation, LLM semantic parsing, and dynamic payload generation, achieve automation, intelligence, and efficiency in application logic vulnerability detection, effectively overcoming many shortcomings of existing technologies and promoting the development of logic vulnerability detection technology.

[0161] In this embodiment, a computer device is provided, such as... Figure 3 As shown, it includes a memory 301, a processor 302, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned logical vulnerability detection methods based on multi-session and dynamic payload.

[0162] Specifically, the computer device can be a computer terminal, a server, or a similar computing device.

[0163] In this embodiment, a computer-readable storage medium is provided, which stores a computer program that executes any of the above-described logical vulnerability detection methods based on multi-session and dynamic payload.

[0164] Specifically, computer-readable storage media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer-readable storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable storage media does not include transient media, such as modulated data signals and carrier waves.

[0165] Obviously, those skilled in the art should understand that the modules or steps of the above-described embodiments of the present invention can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of the present invention are not limited to any particular hardware and software combination.

[0166] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations can be made to the embodiments of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for detecting logical vulnerabilities based on multi-session and dynamic payload, characterized in that, The application comprises: Through the proxy module deployed on the network path, the request messages exchanged between at least two user terminals and the server in the target application are monitored, and the request messages include request parameters, authentication information, business data and session identifiers; Each of the request messages is input into a large language model to identify the corresponding function type through semantic analysis, and the function type includes at least one of adding a user, registering, logging in, modifying user information, verifying a verification code, obtaining data or process operation; For the function type, one or more potential logic vulnerability types are matched in a preset vulnerability knowledge base, and the potential logic vulnerability types include single-user scenario logic vulnerabilities and multi-user scenario logic vulnerabilities, the single-user scenario logic vulnerabilities include unauthorized access, permission bypass and process bypass, and the multi-user scenario logic vulnerabilities include horizontal privilege escalation, vertical privilege escalation and permission bypass; Based on the business data and the authentication information, a test Payload for verifying each of the logic vulnerability types is dynamically generated; The test Payload is sent to the target application to obtain a corresponding response result, the response result is automatically checked based on a preset vulnerability determination condition, and a detection result containing a vulnerability type and verification evidence is output.

2. The method for multi-session and dynamic payload based logical vulnerability detection as claimed in claim 1, wherein, The proxy module uses a man-in-the-middle technology to mirror and monitor traffic without blocking or intercepting normal communication; the proxy module is configured with multiple listening ports, each listening port collects the interaction traffic of a user terminal, and the collected interaction traffic is labeled with a corresponding user label to generate a labeled request message and stored in a database.

3. The method for multi-session and dynamic payload based logical vulnerability detection as claimed in claim 1 or 2 wherein, When the interaction traffic of at least two user terminals is monitored, a session of one of the user terminals is selected as a master user session, and the sessions of the remaining user terminals are slave user sessions, wherein the permissions of the slave users are less than or equal to the permissions of the master user; The session identifiers of the master user session and the slave user session are marked and stored respectively for cross-session difference analysis and test Payload generation.

4. The method for multi-session and dynamic payload based logical vulnerability detection as claimed in claim 1, wherein, The method for dynamically generating a test Payload for a multi-user scenario logic vulnerability comprises: For horizontal privilege escalation, under the condition that the permissions of the master user and the slave user are the same, a key resource identifier parameter in the request message of the master user session is extracted and replaced with the corresponding resource identifier in the request message of the slave user session to construct a test Payload for simulating the master user accessing the slave user resources; For vertical privilege escalation, based on the permission level difference between the master user and the slave user, the authentication information of the low-permission user is used to construct a test Payload for calling the function interface of the high-permission user; For permission bypass, the authentication field is processed by deleting, tampering or replacing with an invalid value, combined with parameter confusion or abnormal request structure, to construct a test Payload for bypassing the system permission check.

5. The method for multi-session and dynamic payload based logical vulnerability detection as claimed in claim 1, wherein, The method for dynamically generating a test Payload for a single-user scenario logic vulnerability comprises: For unauthorized access vulnerability, a test Payload that deletes, clears, tampers or replaces the authentication field with an invalid credential is constructed; For the privilege bypass vulnerability, a test Payload is constructed to modify the request path, HTTP method or Header field to attempt to access restricted resources; For the process bypass vulnerability, based on the semantic understanding of the normal business process by the large language model, the function call sequence is automatically derived, and the subsequent sensitive operation interface is directly constructed to test the Payload, and the pre-checking step includes verification code verification, identity confirmation or operation confirmation.

6. The method for multi-session and dynamic payload based logical vulnerability detection as claimed in claim 1, wherein, The vulnerability knowledge base is a structured database or rule engine, which stores the mapping relationship between function type and potential logical vulnerability type, and each logical vulnerability type is associated with a corresponding Payload generation strategy and vulnerability judgment condition.

7. The method for multi-session and dynamic payload based logical vulnerability detection as claimed in claim 1, wherein, Automatic verification, including: determine whether the response result contains data belonging to the user, if it contains, it is identified as there is a horizontal privilege violation; determine whether the secondary user successfully performs the primary user's privilege operation, if it is successfully executed, it is identified as there is a vertical privilege violation; determine whether the legal response or sensitive data is obtained without valid authentication information, if it is obtained, it is identified as there is an unauthorized access vulnerability; determine whether the key business process is completed without the necessary pre-checking step, if it is completed, it is identified as there is a process bypass vulnerability; compare the response result with the primary user historical session response and the secondary user historical session response, if abnormal state transition or privilege violation is found, it is identified as there is a privilege bypass vulnerability.

8. The method for multi-session and dynamic payload based logical vulnerability detection as claimed in claim 1, wherein, Also includes: the logical vulnerability detection result is displayed through a visual interface or exported as a standardized vulnerability report, the vulnerability report includes vulnerability type, specific request message triggering vulnerability, generated test Payload, involved primary / secondary user session identifier, response evidence and reproduction path.

9. A multi-session and dynamic payload based logical vulnerability detection system, characterized in that, It includes: a proxy module deployed on a network path for listening to request messages between at least two user terminals and a server in a target application, the request message including request parameters, authentication information, business data and session identifier; a request message analysis module for inputting each request message into a large language model for semantic analysis to identify a corresponding function type, the function type including at least one of adding a user, registering, logging in, modifying user information, verifying a verification code, obtaining data or process operation; a vulnerability type positioning module for matching one or more potential logical vulnerability types in a preset vulnerability knowledge base based on the function type, the potential logical vulnerability type including a single-user scenario logical vulnerability and a multi-user scenario logical vulnerability, the single-user scenario logical vulnerability including unauthorized access, privilege bypass and process bypass, and the multi-user scenario logical vulnerability including horizontal privilege violation, vertical privilege violation and privilege bypass; a test Payload dynamic generation module for dynamically generating a test Payload for each logical vulnerability type based on the business data and the authentication information to verify the vulnerability type; The vulnerability verification module is configured to send the test payload to the target application, obtain a corresponding response result, automatically check the response result based on a preset vulnerability judgment condition, and output a detection result containing a vulnerability type and verification evidence.

Images