Logic vulnerability detection method and system based on multiple sessions and dynamic Payload

Abstract

The invention belongs to the technical field of network security and software security testing, and provides a logic vulnerability detection method and system based on multiple sessions and dynamic Payload, and the method comprises the steps: monitoring request messages of at least two users; performing semantic analysis on the request message by using a large language model (LLM), and identifying a function type; matching potential logic vulnerability types in the vulnerability knowledge base; dynamically generating a test Payload for each vulnerability type in combination with the service data and the authentication information; and the Payload is sent, the response is verified, and a detection result is output. According to the method, cross-user difference analysis is realized through multi-session simulation, intelligent understanding of a service function is realized by utilizing LLM, and the targeted Payload is dynamically generated based on the context, so that the problems of low automation degree, poor efficiency and insufficient coverage rate in logic vulnerability detection of a traditional method are solved, and the method is suitable for large-scale popularization and application. The automation level, the intelligence level and the accuracy of logic vulnerability detection are remarkably improved.

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. 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.

[0004] 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.

[0005] 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

[0006] In order to overcome the low degree of automation, insufficient coverage, high false positive rate and other technical problems existing in the prior art in logical vulnerability detection, the present application discloses a logical vulnerability detection method based on multiple sessions and dynamic Payloads, which realizes efficient, accurate and intelligent automatic detection of business logic vulnerabilities such as horizontal privilege escalation, vertical privilege escalation, unauthorized access, privilege bypass and process bypass of single user and multiple users in Web applications, mobile backend APIs and other systems through large language model semantic analysis, vulnerability type classification matching, differentiated Payload generation and automatic verification.

[0007] Specifically, the logical vulnerability detection method comprises the following steps: S101, through the proxy module deployed on the network path, listening to the request message of the interaction between at least two user terminals and the server in the target application, the request message comprising request parameters, authentication information, business data and session identifier; S102, input each request message into a large language model for semantic analysis to identify the corresponding function type; S103, for the function type, matching one or more potential logical vulnerability types in the preset vulnerability knowledge base; S104, based on the business data and the authentication information, dynamically generating a test Payload for each logical vulnerability type to verify the vulnerability type; S105, sending the test Payload to the target application, obtaining the corresponding response result, automatically checking the response result based on the preset vulnerability judgment condition, and outputting the detection result containing the vulnerability type and the verification evidence.

[0008] In one embodiment, the method further comprises: S106, the logical vulnerability detection result is displayed through a visual interface or exported as a standardized vulnerability report, the vulnerability report comprising the vulnerability type, the specific request message triggering the vulnerability, the generated test Payload, the involved master / slave user session identifier, the response evidence and the reproduction path.

[0009] The present application also provides a logical vulnerability detection system based on multiple sessions and dynamic Payloads, comprising a proxy module, a request message analysis module, a vulnerability type positioning module, a test Payload dynamic generation module and a vulnerability verification module.

[0010] The proxy module is deployed on the network path and is used for listening to the request message of the interaction between at least two user terminals and the server in the target application, the request message comprising request parameters, authentication information, business data and session identifier; The request message analysis module is configured to input each of the request messages into a large language model to perform semantic analysis and identify a corresponding function type. The vulnerability type positioning module is configured to match one or more potential logical vulnerability types for the function type in a preset vulnerability knowledge base. The test payload dynamic generation module is configured to dynamically generate a test payload for verifying each of the logical vulnerability types based on the business data and the authentication information. The vulnerability verification module is configured to send the test payload to the target application, obtain a corresponding response result, perform automatic verification on the response result based on a preset vulnerability judgment condition, and output a detection result containing a vulnerability type and verification evidence.

[0011] In one embodiment, the system further includes a result output module configured to display the logical vulnerability detection result through a visual interface or export the logical vulnerability detection result as a standardized vulnerability report, wherein the vulnerability report contains a vulnerability type, a specific request message triggering the vulnerability, a generated test payload, a main / slave user session identifier involved, response evidence, and a reproduction path.

[0012] Compared with the prior art, the present application has at least the following remarkable beneficial effects: 1. By using a multi-session simulation mechanism, the requests of different users (main users and slave users) can be differentiated and compared, thereby directly realizing the automatic detection of typical logical vulnerabilities in multi-user scenarios such as horizontal privilege escalation and vertical privilege escalation, solving the problem that traditional tools cannot perform cross-session analysis, and significantly improving the accuracy and coverage of detection.

[0013] 2. By introducing a large language model (LLM) to perform semantic analysis on the request message, the business function type of the request message is automatically identified, and the application behavior is understood from the business logic level. Based on the function semantics, the vulnerability is matched, thereby avoiding indiscriminate full blind detection on all requests, greatly reducing redundant detection, and improving the detection efficiency. Meanwhile, the introduction of the LLM makes the detection process more intelligent.

[0014] 3. The authentication information and business data of multiple users are combined to dynamically generate a verification payload for a specific vulnerability type. This mechanism does not rely on fixed templates, but intelligently combines the function semantics, vulnerability types, and session differences, so that the generated payload is closer to the real attack scenario, thereby enhancing the relevance and effectiveness of the payload, effectively covering complex logical vulnerabilities such as process bypassing and concurrent competition, and improving the integrity and reliability of the detection.

[0015] 4. Through the automatic verification and result output mechanism, the system not only outputs the vulnerability type, but also records the complete trigger request, test Payload, involved session identification and response evidence. The generated standardized vulnerability report facilitates the security personnel to quickly reproduce and verify the vulnerability, greatly improves the efficiency of vulnerability repair, and realizes the traceability and reproducibility of the detection result.

[0016] To sum up, the method and system provided by the application realize the automation, intelligence and high efficiency of application logic vulnerability detection through the organic combination of multi-session simulation, LLM semantic analysis and dynamic Payload generation, effectively overcome many defects of the prior art, and promote the development of logic vulnerability detection technology. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0018] Figure 1 The flowchart of the logic vulnerability detection method based on multi-session and dynamic Payload of the present application; Figure 2 The architecture diagram of the logic vulnerability detection system based on multi-session and dynamic Payload of the present application; Figure 3 The schematic diagram of the computer device disclosed in the embodiments of the present application; Among them, 201, proxy module; 202, request message analysis module; 203, vulnerability type positioning module; 204, test Payload dynamic generation module; 205, vulnerability verification module; 206, result output module; 301, memory; 302, processor. DETAILED DESCRIPTION

[0019] The embodiments of the present application will be described in detail below with reference to the drawings.

[0020] The present application will be described with particularity and detail in conjunction with specific specific examples, and other advantages and features of the present application will be readily appreciated by persons of ordinary skill in the art in view of the disclosure. Obviously, the described embodiments are only a part of the embodiments of the present application, and are not all the embodiments. The present application can also be implemented or applied by other different specific embodiments, and the details in the specification can be modified or changed based on different views and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features of the embodiments can be combined with each other without conflict. Based on the embodiments in the present application, all other embodiments obtained by persons of ordinary skill in the art without creative labor are within the scope of protection of the present application.

[0021] In order to facilitate the understanding of the technical solutions of the present application, the key terms and abbreviations involved in the specification are explained. Unless otherwise specified, the terms in the specification should be understood according to the definition of this part.

[0022] Logic flaw: refers to the defects of the application in business process, function design or operation logic. Such defects usually allow attackers to obtain improper permissions, bypass access control restrictions or damage system security and data integrity by reasonably exploiting the loopholes in system logic without triggering traditional security protection mechanisms (such as firewalls, WAFs). Typical logic flaws include unauthorized access, horizontal privilege escalation, vertical privilege escalation, privilege bypass and process bypass, etc.

[0023] Large language model (LLM): a kind of artificial intelligence model trained based on massive text data, which can understand and generate human language. In this invention, it learns the statistical rules of language through deep learning technology (such as Transformer architecture) to analyze the semantics of network request messages and identify their corresponding specific business functions (such as "modify user information" and "get order details"). Typical representatives include but are not limited to ChatGPT, Gemini, Claude, Llama, etc.

[0024] Payload: in the field of network security and penetration testing, it refers to the actual data payload sent by attackers or detection tools to target systems to trigger specific operations or verify the existence of vulnerabilities. In this invention, it specifically refers to the test request data dynamically constructed by the "test Payload dynamic generation module" according to the vulnerability type and session data to verify the application logic vulnerability.

[0025] SQL injection: A common web security vulnerability, refers to an attacker inserting malicious SQL code fragments in user input (such as forms, URL parameters, cookies, etc.), so that the application accidentally executes the attacker's preset SQL commands when performing database queries, which may cause data leakage, tampering or deletion.

[0026] Cross-site scripting (XSS): A common web security vulnerability, refers to an attacker injecting malicious script code (usually JavaScript) into a web page. When other users browse the page, the embedded script will be executed in the user's browser, achieving the purpose of stealing user session credentials, redirecting pages or phishing attacks.

[0027] Session: refers to a series of information sets used to maintain state and identify user identity during user interaction with application system within a period of time, which is used to identify user identity and maintain the continuity of user operation. Usually contains a unique session identifier (Session ID), the server associates the user's multiple requests through the identifier to maintain the login state and operation continuity.

[0028] The embodiment of the present application is a logical vulnerability detection method based on multiple sessions and dynamic Payload, as shown in Figure 1 The logical vulnerability detection method comprises the following steps: S101, through the proxy module deployed on the network path, listen to the request message of the interaction between at least two user terminals and the server in the target application, the request message includes request parameters, authentication information, business data and session identifier; S102, input each of the request message into a large language model, and perform semantic analysis to identify the corresponding function type; S103, for the function type, match one or more potential logical vulnerability types in the preset vulnerability knowledge base; S104, based on the business data and the authentication information, dynamically generate a test Payload for each of the logical vulnerability types to verify the vulnerability type; S105, send the test Payload to the target application, obtain the corresponding response result, and automatically check the response result based on the preset vulnerability judgment condition, and output the detection result containing the vulnerability type and the verification evidence.

[0029] In one embodiment, in the step S101, 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. The privilege of the slave user is less than or equal to the privilege of the master user. The implementation of the vertical privilege escalation depends on the privilege of the slave user being lower than that of the master user, and the implementation of the horizontal privilege escalation depends on the privileges of the master and slave users being equal.

[0030] The session identifiers of the master user session and the slave user session are marked and stored respectively for cross-session difference analysis and generation of test Payloads.

[0031] The proxy module uses a man-in-the-middle technique to mirror and monitor the traffic without blocking or intercepting normal communication. The proxy module is configured with multiple monitoring ports, each of which collects the interaction traffic of a user terminal. The collected interaction traffic is tagged with the corresponding user label to generate a tagged request message, which is stored in a database.

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

[0033] In one embodiment, in the step S103, the potential logical vulnerability types include logical vulnerabilities in a single-user scenario and logical vulnerabilities in a multi-user scenario. The logical vulnerabilities in the single-user scenario include unauthorized access, privilege bypass, and process bypass. The logical vulnerabilities in the multi-user scenario include horizontal privilege escalation, vertical privilege escalation, and privilege bypass.

[0034] The vulnerability knowledge base is a structured database or a rule engine, which stores the mapping relationship between the function types and the potential logical vulnerability types. Each logical vulnerability type is associated with a corresponding Payload generation strategy and a vulnerability judgment condition.

[0035] The dynamically generated test Payloads include, but are not limited to, parameter substitution 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, and the coverage and accuracy of vulnerability detection can be improved.

[0036] In one embodiment of dynamically generating test Payloads, in the step S104, the method for dynamically generating test Payloads for logical vulnerabilities in a multi-user scenario includes: S1041, for horizontal privilege-escalation vulnerabilities, under the condition that the main user has the same privileges as the slave user, extract the key resource identification parameters in the request message of the main user session, replace them with the corresponding resource identification in the request message of the slave user session, and construct a test Payload for simulating the main user accessing the slave user resources; S1042, for vertical privilege-escalation vulnerabilities, based on the difference in privilege levels between the main user and the slave user, use the authentication information of the low-privilege user to construct a test Payload that calls the function interface of the high-privilege user; S1043, for privilege-bypass vulnerabilities, use deletion, tampering, or replacement with invalid values to process the authentication field, combined with parameter obfuscation or abnormal request structure, to construct a test Payload for bypassing system privilege checks.

[0037] In another embodiment of dynamically generating test Payloads, the method for dynamically generating test Payloads for logical vulnerabilities in single-user scenarios in step S104 above includes: S1044, for unauthorized access vulnerabilities, construct a test Payload that deletes, clears, tampers with, or replaces with invalid credentials the authentication field; S1045, for privilege-bypass vulnerabilities, construct a test Payload that modifies the request path, HTTP method, or Header field to attempt to access restricted resources; S1046, for process-bypass vulnerabilities, based on the semantic understanding of normal business processes by large language models, automatically derive the order of function calls and skip the pre-check steps, and directly construct test Payloads for subsequent sensitive operation interfaces, the pre-check steps including verification code verification, identity confirmation, or operation confirmation.

[0038] In one embodiment, the automatic verification in step S105 above includes: S1051, determine whether the response result contains data belonging to the slave user, if it does, identify that there is a horizontal privilege-escalation vulnerability; S1052, determine whether the slave user successfully performed the privilege operation of the main user, if it did, identify that there is a vertical privilege-escalation vulnerability; S1053, determine whether valid authentication information is obtained in the absence of valid authentication information, if it is, identify that there is an unauthorized access vulnerability; S1054, determine whether the key business process is completed without the necessary pre-check steps, if it is, identify that there is a process-bypass vulnerability; S1055, compare the response result with the main user historical session response and the slave user historical session response, if an abnormal state transition or privilege escalation behavior is found, identify that there is a privilege-bypass vulnerability.

[0039] In one embodiment, referring to Figure 1 The method further includes: S106, the logical vulnerability detection result is displayed through a visual interface or exported as a standardized vulnerability report, and the vulnerability report includes a vulnerability type, a specific request message triggering the vulnerability, a generated test Payload, involved master / slave user session identification, response evidence, and a reproduction path.

[0040] Based on the same inventive concept, the embodiments of the present application also provide a logical vulnerability detection system based on multiple sessions and dynamic Payloads, as described in the following embodiments. Since the principle of solving problems by the logical vulnerability detection system is similar to the logical vulnerability detection method based on multiple sessions and dynamic Payloads provided in the above embodiments, the implementation of the logical vulnerability detection system can be referred to the implementation of the logical vulnerability detection method disclosed in the above embodiments, and the repeated parts will not be described herein. The term "unit" or "module" used below can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware is also possible and is conceived.

[0041] Figure 2 is a structural block diagram of the logical vulnerability detection system based on multiple sessions and dynamic Payloads disclosed in the embodiments of the present application, as Figure 2 The logical vulnerability detection system includes a proxy module 201, a request message analysis module 202, a vulnerability type positioning module 203, a test Payload dynamic generation module 204, and a vulnerability verification module 205, as shown in the following structure.

[0042] (1) Proxy module 201 The module is deployed on a network path, and is used to listen to request messages exchanged between at least two user terminals and a server in a target application, wherein the request messages include request parameters, authentication information, business data, and session identification. The core function of the module is to realize multiple session simulation and to perform real-time monitoring on the interaction traffic between the user terminals and the server of the target application. The module supports starting multiple listening ports, and the number and purpose of the ports can be managed through a configuration file: When a single listening port is configured, the port is used by default for master user session traffic listening; When two or more listening ports are configured, it is necessary to specify which port is used for master user session traffic listening and which ports are used for slave user session traffic listening.

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

[0044] Through multi-user session simulation, the system can not only obtain single-user behavior data, but also build a multi-user interaction scenario, thereby providing a data foundation for detecting logical vulnerabilities (such as horizontal privilege escalation, vertical privilege escalation, and privilege bypass). This multi-session simulation capability distinguishes it from traditional single-session packet capture or traffic analysis methods, improving the coverage and accuracy of vulnerability detection.

[0045] (2) Request message analysis module 202 This module is used to input each request message into a large language model for semantic analysis to identify the corresponding function type. This module can achieve semantic understanding of request messages at the business logic level, providing a basis for subsequent accurate positioning of vulnerability types. In specific implementation, a custom prompt can be used to input the request message collected by the proxy module 201 into the large language model LLM. The large language model LLM uses its mature semantic analysis capabilities to locate the function implemented by each request message. For example, when the request message corresponds to the operation of "modifying user information", the large language model LLM will output the function type information and record it in the database, associating it with the corresponding request message.

[0046] The setting of the request message analysis module 202 can selectively generate payloads for possible logical vulnerabilities of specific functions in the subsequent vulnerability detection process without the need for full vulnerability scanning of each request message. Compared with traditional vulnerability scanning methods, it has the following significant advantages: a. Reduce the number of packets: Only perform verification requests for functions that may have vulnerabilities, avoiding unnecessary full testing.

[0047] b. Improve detection efficiency: Locate and filter vulnerabilities through function semantics to speed up detection.

[0048] c. Enhance accuracy: Perform targeted testing based on business logic functions to improve the discovery rate of logical vulnerabilities.

[0049] In the present application, the semantic understanding capability of the large language model LLM is applied to request message function identification, forming a function-driven vulnerability detection method that breaks through the traditional blind testing mode of vulnerability scanning tools for each message, achieving intelligent vulnerability positioning with a function-oriented and efficiency-first approach.

[0050] (3) Vulnerability type positioning module 203 This module is used to match one or more potential logical vulnerability types in the pre-set vulnerability knowledge base for the function type. When performing vulnerability detection, the parsed function type is input into the vulnerability type positioning module 203, which calls the built-in vulnerability knowledge base or matching library of the system to search and compare each type of function in the knowledge base, and can obtain vulnerability types such as horizontal privilege escalation, vertical privilege escalation, unauthorized access, privilege bypass, and process bypass.

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

[0052] Through function-driven vulnerability matching, direct mapping from business function to vulnerability type can be realized, rather than the traditional blind measurement based on rules or templates. This method has the following significant advantages: a. Reduce invalid vulnerability testing and improve detection efficiency; b. Provide the basis for horizontal privilege escalation and vertical privilege escalation through multi-session function difference analysis; c. Provide targeted inputs for subsequent dynamic payload generation and achieve high-precision vulnerability verification.

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

[0054] (4) Test Payload dynamic generation module 204 This module is used to dynamically generate a test Payload for each logical vulnerability type based on the business data and the authentication information to verify the vulnerability type.

[0055] In implementation, this module can automatically and dynamically construct a detection request for verifying a logical vulnerability based on the request message function and its corresponding potential vulnerability type output by the vulnerability type positioning module, in combination with multi-user session information and authentication data. The implementation process of this module includes: First, the module receives the target information output by the vulnerability type positioning module, which includes: the request message identifier corresponding to the function; the vulnerability type that the function may be associated with; and the parameter information related to the vulnerability (such as user identity, resource ID, role identifier, etc.).

[0056] Secondly, the module adopts different dynamic generation strategies according to different vulnerability types, for example: For horizontal privilege class vulnerabilities: under the condition that the main user and the slave user have the same permissions, the authentication information and resource identifiers collected in multiple user sessions are used to automatically replace the key parameters in the main session request message with the resource identifiers or credentials of the slave session, and a test payload for cross-session resource access is constructed to detect whether there is a risk of illegally obtaining or operating others' data.

[0057] For vertical privilege class vulnerabilities: by identifying the permission level difference between the main session user and the slave session user, a request message for the low-privilege user to attempt to call high-privilege operations is constructed, and a test payload is dynamically generated to simulate a non-administrator role performing sensitive management operations, thereby detecting whether the permission boundary is correctly constrained.

[0058] For unauthorized access and privilege bypass class vulnerabilities: when generating the test payload, the module will delete or tamper with the authentication fields (such as Token, Cookie), or replace them with invalid credentials, to verify whether the target function can still be called or accessed without providing a valid credential.

[0059] For process bypass class vulnerabilities: according to the function call sequence obtained by analyzing the large language model LLM, the module automatically skips certain pre-check steps (such as verification links, payment confirmation links) in the normal business logic, directly constructs access requests for subsequent sensitive interfaces, generates and sends such test payloads, and detects whether the system has key business process defects.

[0060] In addition, in terms of implementation, the Payload generation module supports the following features: a. Dynamic parameter combination: supports dynamic replacement, addition, deletion, and recombination of parameters in the request message to ensure the diversity and pertinence of the payload; b. Multi-session cross-reference: when generating the payload, the differences between the main session and the slave session are fully utilized to form cross-session comparisons, thereby more accurately triggering horizontal privilege or role difference class vulnerabilities; c. Timing and concurrency simulation: in certain scenarios, the module can also generate payloads with concurrency features, such as submitting multiple requests simultaneously, to detect possible race conditions or timing bypass vulnerabilities.

[0061] Finally, all generated payloads will be labeled with corresponding vulnerability type tags and stored in association with the original request message and user session information as input data for the vulnerability verification module.

[0062] The module generates test Payloads without relying on fixed templates, but through a large language model LLM parsing function information + vulnerability knowledge base mapping + multi-user session data difference, realizing a dynamic, intelligent, and targeted Payload generation mechanism. Compared with traditional vulnerability detection tools that rely on static rules or exhaustive methods, this module can significantly reduce redundant detection requests, improve detection efficiency, and improve the ability to discover business logic vulnerabilities.

[0063] (5) Vulnerability verification module 205 This module is used to send the test Payload to the target application, obtain the corresponding response result, and automatically check the response result based on the preset vulnerability judgment condition, and output the detection result containing the vulnerability type and verification evidence. Its judgment process is as follows: First, different types of test Payloads generated by the test Payload dynamic generation module 204 are sent to the server of the target application one by one, and the corresponding response messages are obtained in real time. The obtained response includes but is not limited to: HTTP status code, response body content, redirection information, business return code, and data field change.

[0064] Second, call the system built-in vulnerability judgment condition (also known as logical vulnerability verification rule) to automatically check the response result of the target application. Specifically, the following process is included: 1) Rule matching: select the corresponding verification rule according to the vulnerability type, for example: Horizontal privilege escalation vulnerability: judge whether the returned result contains data belonging to other users; Vertical privilege escalation vulnerability: judge whether a low-privilege user can successfully perform a high-privilege operation; Unauthorized access vulnerability: detect whether valid credentials are still obtained or sensitive data is still obtained when there are no valid credentials; Process bypass vulnerability: judge whether the target function is still executed in the absence of necessary pre-check steps.

[0065] 2) Result comparison: the module compares the response of the verification request with the original session data of the master session and the slave session to identify cross-session data inconsistencies, privilege boundary breakthroughs, or abnormal state transitions.

[0066] 3) Evidence recording: if the verification result indicates that there is a logical vulnerability, the module will automatically record relevant information, including vulnerability type, specific request message that triggers the vulnerability, involved master / slave user session identifier, and corresponding response evidence, and store it in the database.

[0067] Finally, the module outputs the verification results in a structured form for the result output module to call. The verification results can be displayed to security personnel through a console or a graphical interface, or exported as a standardized vulnerability report for subsequent reproduction and repair.

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

[0069] In one embodiment, referring to FIG. 6, Figure 2 The system further includes a result output module 206 that displays the logical vulnerability detection results through a visual interface or exports them as a standardized vulnerability report, which includes vulnerability types, specific request messages that trigger vulnerabilities, generated test payloads, involved master / slave user session identifiers, response evidence, and reproduction paths.

[0070] The main function of this module is to summarize, format, and visually output the detection results generated by the vulnerability verification module 205, so that security personnel or developers can analyze, reproduce, and repair them. Specifically, the following processes are included: First, the module obtains structured vulnerability records from the vulnerability verification module 205, which include vulnerability types, request messages that trigger vulnerabilities and their corresponding payloads, involved master / slave user session identifiers, application returned response results and verification evidence, vulnerability detection time, detection rule sources, and additional information.

[0071] Second, the module processes the above detection results, which specifically include: According to the vulnerability types, affected functional modules, or user sessions, the results are classified and aggregated to avoid repeated output and improve readability. In the output content, the system will attach key request messages that trigger vulnerabilities, corresponding payloads, verification response fragments, and other information, so that security personnel can directly reproduce the vulnerability scenario and avoid unverifiable results.

[0072] Unlike traditional vulnerability detection tools that only output vulnerability names or simple descriptions, this module can combine multi-session context and business semantic information to provide more fine-grained and reproducible vulnerability detection results. This not only improves the practicality of the detection results, but also significantly improves the efficiency of the vulnerability repair process.

[0073] The present application takes horizontal privilege escalation vulnerability detection and process bypass vulnerability detection as examples to illustrate the logical vulnerability detection in single-user scenarios and multi-user scenarios as described in the above method and system: Embodiment 1: Detection of horizontal privilege violation in multi-user scenario Step 1, the proxy module 201 respectively listens to the interaction traffic between the client of the master user A and the slave user B and the target application server, and sets the interaction traffic of user A as the master session traffic. The request message captured by the proxy module includes authentication credentials, request parameters, and session ID, etc. business data. Assume that the message of user A contains the operation path / user / update, the request parameter is userId=A123, newEmail=xxx@xxx.com, which indicates that user A is modifying the mailbox address of itself.

[0074] Step 2, the request message analysis module 202 performs semantic analysis on the above request message, and identifies that the function corresponding to the message is "modify user information". The analysis result is stored and associated with the request message, which is used for subsequent vulnerability detection steps.

[0075] Step 3, after receiving the function information, the vulnerability type positioning module 203 searches the potential logical vulnerability types related to the "modify user information" function in the vulnerability knowledge base. The search result shows that the possible vulnerability types of this function include horizontal privilege violation and vertical privilege violation. The module generates vulnerability detection targets accordingly, and lists horizontal privilege violation as the priority detection item.

[0076] 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 for horizontal privilege violation.

[0077] Specifically, replace the parameter userId=A123 in the master session request message with the userId=B456 extracted from the slave user session to form a new request message " / user / update userId=B456&newEmail=xxx@xxx.com". This message simulates that the master session user A tries to modify the mailbox information of the slave session user B, in order to verify whether there is a horizontal privilege violation.

[0078] Step 5, the vulnerability verification module 205 sends the above payload to the target application and obtains the return result. If the response result returned by the application shows that the modification is successful, or the returned information contains the mailbox field of the slave user B, it means that the system does not correctly verify the user identity, and there is a horizontal privilege violation. The module records the detection result, including the vulnerability type (horizontal privilege violation), the triggering request (the constructed payload), the related session (user A, user B), and the verification evidence (the response message contains the mailbox of user B).

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

[0080] As can be seen from the embodiment, the method can utilize multi-session simulation and large language model LLM semantic analysis to efficiently locate and verify horizontal privilege escalation vulnerabilities. Unlike traditional black box scanning, the method dynamically generates payloads driven by functions, significantly reducing redundant detection traffic and improving detection efficiency and accuracy.

[0081] Embodiment 2: Detection of password recovery process bypass vulnerability in single user scenario Take the password reset process at the "Forgot Password" function in the login page as an example.

[0082] Step 1, the proxy module 201 listens to the password reset operation of user F in the target application and captures the complete interaction process. The password recovery process includes the following steps: Step 1, the proxy module 201 listens to the password reset operation of user F in the target application and captures the complete interaction process. The password recovery process includes the following steps: Step 2, the request message analysis module 202 analyzes the messages and identifies their functions as "request password reset", "send verification code", "verification code verification", and "submit new password". The analysis results are stored one-to-one with the messages for subsequent vulnerability analysis. Step 2, the request message analysis module 202 analyzes the messages and identifies their functions as "request password reset", "send verification code", "verification code verification", and "submit new password". The analysis results are stored one-to-one with the messages for subsequent vulnerability analysis. Step 3, the vulnerability type positioning module 203 receives the semantic information and searches the vulnerability knowledge base to find that the process belongs to the password reset process. If the application does not perform mandatory verification of the verification code when the user submits a new password, there may be a process bypass vulnerability. The system identifies "process bypass" as the detection target.

[0083] Step 3, the vulnerability type positioning module 203 receives the semantic information and searches the vulnerability knowledge base to find that the process belongs to the password reset process. If the application does not perform mandatory verification of the verification code when the user submits a new password, there may be a process bypass vulnerability. The system identifies "process bypass" as the detection target.

[0084] Step 3, the vulnerability type positioning module 203 receives the semantic information and searches the vulnerability knowledge base to find that the process belongs to the password reset process. If the application does not perform mandatory verification of the verification code when the user submits a new password, there may be a process bypass vulnerability. The system identifies "process bypass" as the detection target.

[0085] Step 3, the vulnerability type positioning module 203 receives the semantic information and searches the vulnerability knowledge base to find that the process belongs to the password reset process. If the application does not perform mandatory verification of the verification code when the user submits a new password, there may be a process bypass vulnerability. The system identifies "process bypass" as the detection target.

[0086] Step 4, in the Payload generation phase, the test Payload dynamic generation module 204 constructs a Payload for process bypassing based on the collected message data. The specific implementation is as follows: skip the / verifycode step, directly use the account information submitted by / sendcode and the returned user identifier to construct the / resetpwd request.

[0087] For example: / resetpwd userphone=telephone number&username=F&newpwd=123456, and carry the session certificate of user F.

[0088] The Payload is used to simulate the situation that the user resets the password without performing the verification code check.

[0089] Step 5, the vulnerability verification module 205 sends the Payload to the target application and obtains the response result. If the system returns a password reset success, it indicates that the application does not strictly control the process order, and there is a process bypassing vulnerability. The module records the detection result accordingly, including the vulnerability type (process bypassing), trigger request, related session and verification evidence (response message).

[0090] Step 6, the result output module 206 summarizes and displays the detection result. The system visually displays the trigger path (lack of verification code check link) and verification evidence (password has been reset but no verification code record) in the report detected on the interface, for security personnel or developers to repair.

[0091] As can be seen from the embodiment, the method of the application can utilize the semantic analysis capability of the large language model LLM in combination with the Payload dynamic generation driven by cross-session data. The application can automatically discover and verify process bypassing vulnerabilities in various business logic links, which embodies the generality and innovation of the detection method.

[0092] In summary, compared with the prior art, the application has at least the following remarkable beneficial effects: 1. Through the multi-session simulation mechanism, the requests of different users (master / slave users) can be differentiated and compared, directly realizing the automatic detection of typical logic vulnerabilities in multi-user scenarios such as horizontal privilege escalation and vertical privilege escalation, solving the problem that traditional tools cannot perform cross-session analysis, and significantly improving the accuracy and coverage of detection.

[0093] 2. By introducing a large language model (LLM) to perform semantic analysis on the request message, the business function type is automatically identified, and the application behavior is understood from the business logic level. Based on the function semantics, the vulnerability matching is performed, avoiding indiscriminate full blind detection on all requests, greatly reducing redundant detection, and improving detection efficiency. At the same time, the introduction of the large language model LLM makes the detection process more intelligent.

[0094] 3. Combined with the collected multi-user authentication information and business data, the verification Payload for specific vulnerability types is dynamically generated. This mechanism does not rely on fixed templates, but intelligently combines according to function semantics, vulnerability types and session differences, so that the generated Payload is closer to the real attack scene, enhancing the relevance and effectiveness of the Payload, effectively covering complex logic vulnerabilities such as process bypass and concurrent competition, and improving the integrity and reliability of the detection.

[0095] 4. Through the automatic verification and result output mechanism, the system not only outputs the vulnerability type, but also records the complete trigger request, test Payload, involved session identifier and response evidence. The generated standardized vulnerability report facilitates security personnel to quickly reproduce and verify vulnerabilities, greatly improves the efficiency of vulnerability repair, and realizes the traceability and reproducibility of the detection results.

[0096] In summary, the method and system proposed in the present application realize the automation, intelligence and efficiency of application logic vulnerability detection through the organic combination of multi-session simulation, LLM semantic analysis and dynamic Payload generation, effectively overcoming many defects of the prior art, and promoting the development of logic vulnerability detection technology.

[0097] In the present embodiment, a computer device is provided, as shown in Figure 3 including a memory 301, a processor 302, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to implement any of the above-mentioned multi-session and dynamic Payload-based logic vulnerability detection methods.

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

[0099] In the present embodiment, a computer readable storage medium is provided, which stores a computer program for executing any of the above-mentioned multi-session and dynamic Payload-based logic vulnerability detection methods.

[0100] In particular, computer readable storage media tangibly embody the 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 technology, compact disc read-only memory (CD-ROM), digital versatile discs (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In this context, computer readable storage media can include a non-transitory storage medium. However, in some contexts a transitory medium can be used to store computer readable instructions, data structures, program modules or other data.

[0101] It is apparent that, for the skilled in the art, the modules or steps of the above-mentioned embodiments of the present application can be realized by general computing devices, which can be centralized on a single computing device or distributed on a network composed of multiple computing devices, and optionally, they can be realized by program codes executable by computing devices, so that they can be stored in storage devices and executed by computing devices, and in some cases, the steps shown or described can be executed in different order, or they can be respectively manufactured as individual integrated circuit modules, or multiple modules or steps among them can be manufactured as a single integrated circuit module. Thus, the embodiments of the present application are not limited to any particular combination of hardware and software.

[0102] The above only describes the preferred embodiments of the present application and is not intended to limit the present application. The embodiments of the present application can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for detecting logical vulnerabilities based on multi-session and dynamic payload, characterized in that, The application comprises the following steps: By deploying a proxy module on the network path, the request messages exchanged between at least two user terminals and a server in a 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 for semantic analysis to identify the corresponding function type; For the function type, one or more potential logical vulnerability types are matched in a preset vulnerability knowledge base; Based on the business data and the authentication information, a test Payload for verifying each of the logical vulnerability types is dynamically generated; The test Payload is sent to the target application to obtain a corresponding response result, which is automatically checked based on a preset vulnerability determination condition, and a detection result containing the 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 the traffic without blocking or intercepting normal communication; the proxy module is configured with multiple listening ports, each of which 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, the session of one of the user terminals is selected as the main user session, and the sessions of the remaining user terminals are the slave user sessions, wherein the authority of the slave user is less than or equal to that of the main user; The session identifiers of the main 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 3, wherein, 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, and the potential logical vulnerability type includes a logical vulnerability in a single-user scenario and a logical vulnerability in a multi-user scenario; Wherein, the logical vulnerability in a single-user scenario includes unauthorized access, privilege bypass and process bypass, and the logical vulnerability in a multi-user scenario includes horizontal privilege escalation, vertical privilege escalation and privilege bypass.

5. The method for multi-session and dynamic payload based logical vulnerability detection as claimed in claim 4, wherein, The method for dynamically generating a test Payload for a logical vulnerability in a multi-user scenario comprises: For horizontal privilege escalation, when the authorities of the main user and the slave user are the same, the key resource identifier parameter in the request message of the main 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 main user accessing the slave user resource; For vertical privilege escalation, based on the authority level difference between the main user and the slave user, the authentication information of the low-privilege user is used to construct a test Payload for calling the function interface of the high-privilege user; For privilege bypass, the authentication field is processed by deleting, tampering or replacing it with an invalid value, combined with parameter confusion or abnormal request structure, to construct a test Payload for bypassing the system privilege check.

6. The method for multi-session and dynamic payload based logical vulnerability detection as claimed in claim 4, wherein, The method for dynamically generating a test Payload for a logical vulnerability in a single-user scenario comprises: For unauthorized access, 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 pre-checking step is skipped to directly construct a test Payload for the subsequent sensitive operation interface, wherein the pre-checking step includes verification code verification, identity confirmation or operation confirmation.

7. 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 a rule engine, which stores the mapping relationship between function types and potential logical vulnerability types, and each logical vulnerability type is associated with a corresponding Payload generation strategy and vulnerability judgment condition.

8. 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 does, identify that there is a horizontal privilege violation; determine whether the secondary user successfully performed the primary user's privilege operation, if so, identify that there is a vertical privilege violation; determine whether the secondary user successfully performed the primary user's privilege operation, if so, identify that there is a vertical privilege violation; determine whether the key business process is completed without the necessary pre-checking step, if so, identify that there is a process bypass vulnerability; compare the response result with the primary user's historical session response and the secondary user's historical session response, if an abnormal state transition or privilege violation is found, identify that there is a privilege bypass vulnerability.

9. 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, which includes vulnerability type, specific request message triggering vulnerability, generated test Payload, involved primary / secondary user session identifier, response evidence and reproduction path.

10. A multi-session and dynamic payload based logical vulnerability detection system, characterized in that, Includes: The proxy module is deployed on the network path to listen to the request message between at least two user terminals and the server in the target application, wherein the request message includes request parameters, authentication information, business data and session identifier; The request message analysis module inputs each request message into the large language model for semantic analysis to identify the corresponding function type; The vulnerability type positioning module matches one or more potential logical vulnerability types in the preset vulnerability knowledge base based on the function type; The test Payload dynamic generation module dynamically generates 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 sends the test Payload to the target application, obtains the corresponding response result, and automatically verifies the response result based on the preset vulnerability judgment condition, and outputs the detection result including the vulnerability type and the verification evidence.

Images