Automated payment vulnerability detection system and method
By recording user operations to generate a finite state machine and automating the execution of attack test cases, the problem of low efficiency and high false positive rate in payment vulnerability detection in existing technologies is solved, realizing fully automated payment vulnerability detection and improving detection efficiency and accuracy.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHANGHAI JIAOTONG UNIV
- Filing Date
- 2022-07-28
- Publication Date
- 2026-05-19
AI Technical Summary
Existing automated logic vulnerability detection technologies in payment systems suffer from low detection efficiency, high false positive rate, and high false negative rate. In particular, black-box detection technologies lack source code information, resulting in poor detection performance, and are complex for users, making them difficult to widely apply in production environments.
An automated payment vulnerability detection system based on user operation is adopted. The behavior control module records user operations and generates a finite state machine. The attack case generation module performs vulnerability testing, the test case execution module executes attack phrases, and the reporting module generates a detection report, thus achieving fully automated vulnerability detection.
It improves the universality and efficiency of payment vulnerability detection, reduces false positive and false negative rates, provides detailed vulnerability reports and remediation solutions, simplifies user operations, and enhances the system's usability in production environments.
Smart Images
Figure CN115203707B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to a technology in the field of information security, specifically an automated payment vulnerability detection system and method. Background Technology
[0002] Existing automated logic vulnerability detection technologies mainly include white-box and black-box techniques. White-box testing-based techniques, given the software system's source code or binary files, can use symbolic execution frameworks and taint analysis to achieve semantic tree abstraction of the source code and further uncover logic vulnerabilities. Black-box testing-based techniques, as a dynamic detection method, do not involve the source code and therefore lack a significant amount of usable information compared to white-box testing. However, black-box testing can intuitively adjust inputs and obtain outputs, and its lower barrier to entry means it doesn't require source code. Computer software programs, in their design and operation, share certain commonalities in system control and data transmission; dynamic detection leverages these commonalities to perform the detection. Summary of the Invention
[0003] This invention addresses the shortcomings of existing technologies by proposing an automated payment vulnerability detection system and method. It eliminates the need for additional user operations and specialized knowledge, relying solely on user actions to automate the entire process of test case generation, execution, and feedback for payment logic vulnerability detection, significantly improving its ease of use and usability in production environments. Furthermore, this invention is user-driven, and by separating information collection from testing operations, it comprehensively analyzes user behavior and the software system to achieve more systematic and timely logic vulnerability detection.
[0004] This invention is achieved through the following technical solution:
[0005] This invention relates to an automated payment vulnerability detection system based on user operation collection and finite state machines, comprising: a behavior control module, an attack case generation module, an execution module, and a reporting module. The behavior control module records normal user operations on the platform under test, acquiring user operation information. The attack case generation module replays normal operations while monitoring user operation traffic, generating a corresponding finite state machine for user behavior, and performing comprehensive analysis on the user behavior finite state machine. It also generates vulnerability test cases based on the expert attack knowledge base of the attack case generation module. The execution module intercepts, modifies, and releases data packets for corresponding steps based on the parameter information within the test cases, executing all attack phrases in a loop. The reporting module acquires feedback information, analyzes and determines whether a vulnerability has been triggered, statistically analyzes the detection results, and generates a complete detection report.
[0006] The normal operations mentioned include, but are not limited to: clicking, inputting, and redirecting to purchase goods on the platform under test.
[0007] The replay refers to: re-executing the recorded operation once.
[0008] The aforementioned monitoring refers to recording the traffic data corresponding to the operation while ensuring that the normal operation is performed during replay.
[0009] The aforementioned overall analysis refers to: using the constructed finite state machine to generate parameter propagation chains and read the traffic data corresponding to each operation, extracting WEB parameters, and filtering out sensitive parameters for mutation to generate test cases for vulnerability attacks.
[0010] The aforementioned expert attack knowledge base contains data on variations of payment vulnerability attack parameters.
[0011] This invention relates to an automated payment logic vulnerability detection method based on the above-mentioned system. The method collects normal operation information and executes it to obtain corresponding traffic data, and then constructs a finite state machine based on this data. Then, it generates several attack cases based on the state diagram and transition parameters and inputs them into the executor to perform parameter tampering attack tests. Finally, it generates a system vulnerability report based on the attack results.
[0012] Technical effect
[0013] This invention employs a method of collecting and executing user behavior information to simulate user operations, thereby enabling the simulation of a normal user completing the shopping process and improving the universality of payment vulnerability detection across different online shopping mall systems. Furthermore, this approach simulates real user operations as closely as possible, preventing the detection results from being affected by various security measures of the system under test, and more closely resembles the manual discovery of payment vulnerabilities by testers.
[0014] This invention employs a method for generating attack parameter chains by constructing a finite state machine and a sensitive parameter detection method based on key-value collaborative judgment. This method can detect common vulnerability parameters in payment vulnerabilities to the greatest extent possible, reduce the generation of irrelevant test cases, and improve detection efficiency.
[0015] This invention provides two methods for obtaining vulnerability assessment information: database query and webpage order parsing. Testers can choose the appropriate method according to different usage scenarios, which can improve the accuracy of vulnerability assessment and reduce false positive and false negative rates.
[0016] This invention provides detailed vulnerability information and remediation solutions when generating reports. Furthermore, if no vulnerabilities are detected after executing test cases, the test information will be recorded in a vulnerability-free report for testers to review, further reducing the possibility of missed detections and improving usability. Attached Figure Description
[0017] Figure 1 This is an overall flowchart of the present invention;
[0018] Figure 2 Flowchart for the user information collection module;
[0019] Figure 3 Flowchart for generating attack phrase sequences;
[0020] Figure 4 Flowchart for the attack phrase execution and reporting module. Detailed Implementation
[0021] like Figure 1 As shown in this embodiment, an automated payment vulnerability detection system includes: a behavior control module, an attack case generation module, an execution module, and a reporting module. The behavior control module records normal user operations on the platform under test, acquiring user operation information. The attack case generation module replays normal operations while monitoring user operation traffic, generating a corresponding finite state machine of user behavior, performing comprehensive analysis on the finite state machine, and generating vulnerability test cases based on the expert attack knowledge base of the attack case generation module. The execution module intercepts, modifies, and releases data packets for corresponding steps based on the parameter information within the test cases. The reporting module acquires feedback information, analyzes and determines whether a vulnerability has been triggered, statistically analyzes the detection results, and generates a complete detection report.
[0022] The behavior control module includes a behavior collection unit and a behavior parsing unit, wherein: the behavior collection unit collects the user's clicks and input operations by popping up a browser window and converts them into corresponding behavior codes; the behavior parsing unit parses and stores the corresponding specific operations based on the behavior codes.
[0023] The data collection was achieved through, but not limited to, the codegen function of the open-source project PlayWright.
[0024] The aforementioned storage refers to storing behavioral information using a data interface that can be parsed in subsequent execution phases. Specifically, the behavioral information is encoded into a dictionary format as follows: {'locator':"",'action':"",'popup':-1,'page':0,'nth':0,'to_have_url':"",'UAcounter':0}, and then stored in memory for use by subsequent modules.
[0025] The attack test case generation module includes: a parameter propagation chain generation unit, a sensitive parameter detection unit, and an attack parameter mutation unit. Specifically: the parameter propagation chain generation unit analyzes parameters with the same value but different key names using an established finite state machine, and then determines whether the values of parameters with different key names represent an attack type; the sensitive parameter detection unit uses key values in conjunction with regular expressions to jointly determine whether a parameter represents an attack type; and the attack parameter mutation unit mutates the parameters that have been determined to have attack types, generating attack phrases.
[0026] The attack types mentioned include: monetary, quantitative, payment interface, status, and user ID types.
[0027] The attack phrase refers to an interface with the execution module, specifically a dictionary-type data structure: {'vultype':'xxxAttack','phrase':[[ua_seq,modifyvalue,[post / get,params key],[…],[…]],…]}.
[0028] The execution module executes, intercepts, modifies, and releases the attack phrases generated by the attack case generation module, and executes all attack phrases in a loop.
[0029] The reporting module includes a database query unit, an order page parsing unit, a vulnerability identification unit, and a report generation unit. Specifically: the database query unit uses fields defined by the tester to retrieve the corresponding order number, amount, quantity, and status information; the order page parsing unit parses the order page information of the webpage to extract the order number, amount, quantity, and status information, suitable for detection in unknown database situations; the vulnerability identification unit determines the success of the attack by detecting whether the order status is abnormal, whether the amount is less than the initial normal order, and whether the quantity is abnormal; the report generation unit writes the attack information determined by the vulnerability identification unit to be vulnerable into the vulnerability report.
[0030] like Figures 2-4 As shown, this embodiment illustrates an automated payment vulnerability detection method for the aforementioned system. It collects normal operation information and executes it to obtain corresponding traffic data, and then constructs a finite state machine based on this data. Next, it generates several attack cases based on the state diagram and transition parameters, and inputs them into the executor to perform parameter tampering attack tests. Finally, it generates a system vulnerability report based on the attack results. The specific steps include:
[0031] Step 1: Use the PlayWright codegen function to collect user behavior information. A built-in browser will pop up, collecting user clicks, inputs, and other behaviors within the browser. These behaviors will be extracted into a sequence of executable operations and stored. Then, the system will automatically execute the collected user behaviors once, while simultaneously intercepting corresponding data packets. After all user behaviors have been executed, the system will automatically construct a finite state machine and store it in the database for later use.
[0032] The specific steps for using the PlayWright codegen feature include: downloading the open-source PlayWright component, placing it in the project folder, and using Python's built-in subprocess method to create a subprocess to run `playwrightcodegen -oUA_module / UA_record / filename --device CONFIG_DICT["device"] –target python CONFIG_DICT["url"]`, where the simulated device can be a mobile device or a computer device, depending on the user configuration, and `url` represents the first page entered when user information collection is started.
[0033] The collection of user behavior in the browser refers to extracting specific user operation information from the behavior file generated by codegen. The extracted information includes the location of clicked or entered elements, clicked content, entered content, whether a redirect occurred, etc., which facilitates the subsequent execution of the operation by the executor.
[0034] The interception of data packets after simulating user operation refers to adding a callback function in the browser context when the browser sends a request. This callback function is called every time a request is sent to obtain the request and response data for that request, until the simulated normal user operation is completed.
[0035] The construction of a finite state machine refers to the automatic construction of a finite state machine by using Python's transitions library to define the state transitions of relevant traffic.
[0036] Step 2: Analyze the parameters in the finite state machine, analyze the parameter propagation chain, and add them to the list of parameters to be processed. Then, use a key-value collaborative judgment-based regular expression matching mechanism to filter out common parameters for specific payment vulnerabilities, and add them to the list of parameters to be processed as well. Next, perform mutation processing on each parameter related to different payment vulnerability types in the list of parameters to be processed based on expert knowledge, and then identify the payment vulnerability type to generate attack phrases.
[0037] The aforementioned analysis parameter propagation chain refers to: filtering out a series of WEB parameters with the same value but not in the same state.
[0038] The regular expression matching mechanism refers to the following: using the regular expression "[+-]?\d+\.\d+" to match floating-point type parameters, which will be identified as a monetary parameter; using the regular expression "[+-]?^\d+$" to match integer type parameters, which will be identified as a quantity parameter.
[0039] The aforementioned mutation processing refers to: mutating the monetary parameter to values such as 0.01 or -1.00, which are prone to causing payment vulnerabilities related to monetary amounts; and mutating the quantity parameter to values such as 1, -1, or 2. 64 Values that are prone to causing payment vulnerabilities related to quantity; parameters of payment interfaces that are prone to causing payment vulnerabilities related to payment interfaces, such as alipay, wxpay, free, pp_pay; parameters of order status that are prone to causing payment vulnerabilities related to order status, such as 0, 1, true, false; parameters of user ID that are prone to causing payment vulnerabilities related to order status, such as mutating user ID parameters to other users' IDs.
[0040] The identification of payment vulnerability types refers to classifying payment vulnerabilities into types such as amount tampering, quantity tampering, payment interface error, payment status tampering, and unauthorized payment, based on the type of tampering generated, while generating attack phrases. The type identifier is then added to the attack dictionary to facilitate the reporting module in distinguishing which type of vulnerability it belongs to.
[0041] The attack phrase refers to an interface with the execution module, specifically a dictionary-type data structure: {'vultype':'xxxAttack','phrase':[[ua_seq,modifyvalue,[post / get,params key],[…],[…]],…]}.
[0042] Step 3: The attack phrase generated in the previous step is handed over to the executor for execution. Each time the executor executes an attack test case, it will simulate the execution of the user behavior information collected in Step 1. When it executes the parameter that needs to be tampered with, it will intercept the data packet after the simulated user operation, replace the corresponding parameter value with the attack parameter in the attack phrase, and then release the data packet.
[0043] The executor refers to: reading in formatted user behavior information, determining the type of user operation based on different user actions, and using PlayWright to perform operations such as clicking a button or entering information in an input box; after each round of execution, it loads an attack phrase from the attack phrase queue and performs data tampering at the corresponding request based on the attack phrase.
[0044] The interception of data packets after simulating user operations refers to using PlayWright's built-in interface context.route to intercept and process data packets. This involves modifying the original normal data into attack data within the attack phrase. Specifically, the intercepted data is separated according to different types such as POST / GET. Based on the parameter type, GET parameters and parameters of types such as application / json, application / x-www-form-urlencoded, and multipart / form-data in POST are parsed. After parsing, the corresponding parameter keys are found and their values are modified. Finally, the processed data packets are released.
[0045] Step 4: After each attack phrase is executed, the order information is parsed after the last user operation. Order parsing is done in two ways. One way is for the tester to test the internal system and define the backend database field information. At this time, the order information generated by the database will be used to determine whether there are any problems such as reduced amount, reduced unit price, or incorrect quantity in the order of normal operation. If no database information is defined, the default method is to obtain the order information by parsing the web page order. The order number, amount, quantity, payment status and other key information are extracted from the historical order page using regular expression matching and form parsing. The vulnerability judgment is then carried out in the same way as the database query. When a vulnerability is detected, the test case and the judgment basis are recorded and written into the vulnerability report.
[0046] The definition of backend database field information refers to the username, password, database name, form name, field name, and other information for defining the database connection used to store order information.
[0047] The aforementioned webpage order parsing refers to parsing the data information of the historical order interface. The historical order interface provides users with information such as order number, amount, purchase time, and status, mostly displayed in the form of HTML tables. This system uses table parsing technology to analyze the required order information and uses this information to determine vulnerabilities. When encountering pages that cannot be parsed using tables, regular expressions are used to match the data following the corresponding fields.
[0048] The table parsing mentioned above refers to using the python-pandas toolkit to parse table data.
[0049] The aforementioned vulnerability report refers to the process of using the Python-docx toolkit to write a vulnerability summary, vulnerability type, vulnerability point, judgment criteria, payload, and remediation suggestions into the vulnerability report. When no vulnerability is detected, a "no vulnerability" report will be generated, and the report will be presented in the form of an Office document.
[0050] Based on specific practical experiments, the types of vulnerabilities detected and the number of test cases generated by the above system on the OpenCart online marketplace testing platform are shown in the following table:
[0051] Vulnerability type Number of test cases generated Number of vulnerabilities detected Number of false alarms Amount tampering 12 2 0 Quantity tampering 9 2 0 Payment interface tampering 5 1 0 Payment status tampering 10 1 0 Unauthorized payment 6 0 0
[0052] This demonstrates that the system can detect payment vulnerabilities with a very low false alarm rate.
[0053] Simultaneously, experiments were conducted on some online shopping websites, and a payment vulnerability was discovered in an online bookstore on the internet. The types of vulnerabilities detected by this system and the number of test cases generated are shown in the table below:
[0054] Vulnerability type Number of test cases generated Number of vulnerabilities detected Number of false alarms Amount tampering 18 0 0 Quantity tampering 12 1 0 Payment interface tampering 0 0 0 Payment status tampering 3 0 0 Unauthorized payment 2 0 0
[0055] Compared with existing technologies, this system can achieve full automation of payment vulnerability detection and reporting, and its efficiency is significantly improved compared with existing manual detection techniques and some semi-automated techniques. At the same time, this method has a low false positive rate, and even if no vulnerability is found after testing with generated test cases, a vulnerability-free report will be generated, which is convenient for testers to check and provides vulnerability remediation solutions, making it easier for security personnel to fix the vulnerabilities.
[0056] This invention addresses the high efficiency and cost issues of traditional manual payment vulnerability discovery by collecting and executing user actions and constructing finite state machines. Furthermore, it allows for switching vulnerability detection methods based on usage scenarios, improving the accuracy of payment logic vulnerability detection. This invention also supports retesting; after recording user actions, users can directly select previously recorded user behavior files to verify whether vulnerabilities have been patched, avoiding the need for users to re-enter behavior information and simplifying the work of security personnel.
[0057] This invention covers most types of payment vulnerabilities, including those involving amount tampering, quantity tampering, payment interface tampering, and unauthorized payments, solving the problems of low efficiency and high cost in manually discovering payment vulnerabilities. This invention uses user behavior-driven methods to construct a finite state machine, automatically collect traffic packets and analyze them to generate a series of attack cases, then automatically execute the attack cases and identify vulnerabilities, write the details of the detected vulnerabilities into a report, and provide remediation solutions for security personnel to patch the vulnerabilities.
[0058] The specific implementations described herein may be partially adjusted by those skilled in the art in different ways without departing from the principles and purpose of this invention. The scope of protection of this invention is defined by the claims and is not limited by the specific implementations described herein. All implementation schemes within the scope thereof are subject to the constraints of this invention.
Claims
1. An automated payment vulnerability detection system based on user operation collection and finite state machines, characterized in that, include: The system comprises a behavior control module, an attack case generation module, an execution module, and a reporting module. Specifically: the behavior control module records normal user operations on the platform under test, acquiring user operation information; the attack case generation module replays normal operations while monitoring user operation traffic, generating a corresponding finite state machine of user behavior, performing comprehensive analysis on the finite state machine, and generating vulnerability test cases based on the expert attack knowledge base of the attack case generation module; the execution module intercepts, modifies, and releases data packets for corresponding steps based on the parameter information within the test cases, cyclically executing all attack phrases in the attack cases; and the reporting module acquires the execution results, analyzes and determines whether a vulnerability has been triggered, statistically analyzes the detection results, and generates a complete detection report. The aforementioned overall analysis refers to: using the constructed finite state machine to analyze the parameter propagation chain and read the traffic data corresponding to each operation, extracting WEB parameters, and filtering out sensitive parameters for mutation to generate test cases for vulnerability attacks; The reporting module includes a database query unit, an order page parsing unit, a vulnerability identification unit, and a report generation unit. Specifically: the database query unit uses fields defined by the tester to retrieve the corresponding order number, amount, quantity, and status information; the order page parsing unit parses the order page information of the webpage to extract the order number, amount, quantity, and status information, suitable for detection in unknown database situations; the vulnerability identification unit determines the success of the attack by detecting whether the order status is abnormal, whether the amount is less than the initial normal order, and whether the quantity is abnormal; the report generation unit writes the attack information determined by the vulnerability identification unit to be vulnerable into the vulnerability report.
2. The automated payment vulnerability detection system based on user operation collection and finite state machine as described in claim 1, characterized in that, The behavior control module includes a behavior collection unit and a behavior parsing unit, wherein: the behavior collection unit collects the user's clicks and input operations by popping up a browser window and converts them into corresponding behavior codes; the behavior parsing unit parses and stores the corresponding specific operations based on the behavior codes.
3. The automated payment vulnerability detection system based on user operation collection and finite state machine as described in claim 1, characterized in that, The attack test case generation module includes: a parameter propagation chain generation unit, a sensitive parameter detection unit, and an attack parameter mutation unit. Specifically: the parameter propagation chain generation unit analyzes parameters with the same value but different key names using an established finite state machine, and then determines whether the values of the parameters with different key names represent an attack type; the sensitive parameter detection unit uses key-value pairs combined with regular expressions to jointly determine whether a parameter represents an attack type; and the attack parameter mutation unit mutates the parameters that have been determined to have attack types, generating attack phrases. The attack phrase refers to an interface with the execution module, specifically a dictionary-type data structure: {'vultype':'xxxAttack','phrase': [[ua_seq, modify value, [post / get, paramskey], […], […]], …]}.
4. An automated payment logic vulnerability detection method based on the system described in any one of claims 1 to 3, characterized in that, By collecting normal operation information and executing it to obtain the corresponding traffic data, a finite state machine is constructed based on this data. Then, based on the state diagram and transition parameters, several attack cases are generated and input into the executor to perform attack tests that tamper with parameters. Finally, a system vulnerability report is generated based on the execution results.
5. The payment logic vulnerability detection method according to claim 4, characterized in that, specifically... include: Step 1: Use the PlayWright codegen function to collect user behavior information. Pop up the built-in browser, collect the user's behavior in the browser, extract the behavior into a sequence of executable operations and store it; then initialize and automatically execute the collected user behavior once, while intercepting the corresponding data packets. After all user behaviors have been executed, the system automatically constructs a finite state machine and then stores the finite state machine in the database for later use. Step 2: Analyze the parameters in the finite state machine, analyze the parameter propagation chain, add them to the list of parameters to be processed, and then use a regular expression matching mechanism based on key-value collaborative judgment to filter out common parameters of specific payment vulnerabilities, and add them to the list of parameters to be processed as well; then, perform mutation processing on each parameter related to different payment vulnerability types in the list of parameters to be processed according to expert knowledge, and then identify the payment vulnerability type and generate attack phrases. Step 3: The attack phrase generated in the previous step is handed over to the executor for execution. Each time the executor executes an attack case, it will simulate the execution of the user behavior information collected in Step 1. When it executes the parameter that needs to be tampered with, it will intercept the data packet after the simulated user operation, replace the corresponding parameter value with the attack parameter in the attack phrase, and then release the data packet. Step 4: After each attack phrase is executed, the order information is parsed after the last user operation. Order parsing is done in two ways. One way is for the tester to test the internal system and define the backend database field information. At this time, the order information generated by the database will be used to determine whether there are any issues such as reduced amount, reduced unit price, or incorrect quantity in the order of normal operation. If no database information is defined, the order information is obtained by default through web page order parsing. Regular expression matching and form parsing are used to extract key information such as order number, amount, quantity, and payment status from the historical order page. The vulnerability judgment is then performed in the same way as the database query. When a vulnerability is detected, the test case and the judgment basis are recorded and written into the vulnerability report.
6. The payment logic vulnerability detection method according to claim 5, characterized in that, The aforementioned mutation processing refers to: mutating class-amount parameters to values that are prone to causing payment vulnerabilities related to amount; mutating class-quantity parameters to values that are prone to causing payment vulnerabilities related to quantity; mutating class-payment interface parameters to values that are prone to causing payment vulnerabilities related to payment interfaces; mutating class-order status parameters to values that are prone to causing payment vulnerabilities related to order status; and mutating class-user ID tampering parameters to the IDs of other users.
7. The payment logic vulnerability detection method according to claim 5, characterized in that, The executor refers to: reading in formatted user behavior information, determining the type of user operation based on different user operations, and using PlayWright to perform operations such as clicking a button or entering information in an input box; After each round of execution, an attack phrase is loaded from the attack phrase queue, and data tampering is performed at the corresponding request based on the attack phrase.
8. The payment logic vulnerability detection method according to claim 5, characterized in that, The interception of data packets after simulating user operations refers to using PlayWright's built-in interface context.route to intercept and process data packets. This involves modifying the original normal data into attack data within the attack phrase. Specifically, the intercepted data is separated according to different POST / GET types. Based on the parameter type, GET parameters and parameters of type application / json, application / x-www-form-urlencoded, and multipart / form-data in POST are parsed. After parsing, the corresponding parameter keys are found and their values are modified. Finally, the processed data packets are released.