Security APP business logic vulnerability detection method and system, medium and server

Abstract

The invention belongs to the technical field of application program security detection, and provides a security APP business logic vulnerability detection method and system, a medium and a server, and the method comprises the steps: constructing a standardized time sequence model of a security transaction process, dynamically collecting instruction sequence data during the actual operation of a security APP, comparing an instruction sequence with the standardized time sequence model, and obtaining a security APP business logic vulnerability detection result. And carrying out risk grade division and sorting on the identified abnormal instruction sequence, carrying out simulation verification on an operation path corresponding to the high-risk abnormal sequence, confirming the validity of the business logic vulnerability, and generating a detection report. According to the method, automatic vulnerability identification and verification of the security transaction service full link are realized, the detection coverage rate and efficiency are improved, the service logic vulnerability detection coverage rate can be improved to about 90% or above, the detection efficiency is improved to about 10 times or above of manual work, the artificial scene construction cost is reduced, different broker APP personalized rules can be adapted, and the security transaction service full link vulnerability identification and verification method is suitable for popularization and application. And the method has high expansibility and adaptability.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of application program security detection, and particularly relates to a security APP business logic vulnerability detection method, system, medium and server. BACKGROUND

[0002] The security transaction APP is a main tool for financial investment users to perform transaction operations such as opening an account, placing an order, canceling an order, closing a position, and fund settlement.

[0003] In the prior art, the detection of the security APP security mainly focuses on code-level vulnerabilities (such as SQL injection, unauthorized access) or general security behaviors (such as permission abuse, sensitive information leakage), and the implementation methods include: 1. Static code scanning The application code is subjected to syntax rule matching to identify hard-coded vulnerabilities, unauthorized access interfaces, and the like.

[0004] 2. Dynamic fuzz testing Interface parameters are automatically generated, and interface abnormal responses are tested through brute-force iteration.

[0005] However, the existing detection methods have the following problems: 1. Unable to identify cross-process business logic vulnerabilities: For example, vulnerabilities such as "executing a closing position without checking the holding position state" and "abnormal fund caused by repeated order cancellation" are not single-interface abnormalities, but depend on the timing and state dependence of the entire transaction process, and traditional scanning or fuzz testing cannot cover them.

[0006] 2. Detection relies on manual construction of scenarios: The current discovery of business logic vulnerabilities mainly relies on security researchers to manually construct specific transaction sequences based on experience, which is inefficient, has insufficient coverage, and is difficult to adapt to the individualized transaction rules of different securities companies APPs. SUMMARY

[0007] The purpose of the present application is to overcome the existing defects and provide a security APP business logic vulnerability detection method, system, medium and server.

[0008] In order to solve the above technical problems, the present application provides the following technical solutions: A security APP business logic vulnerability detection method includes: (1) Constructing a standardized timing model of the security transaction process, the standardized timing model being used to define the legal transaction state, state transition path, transition trigger condition, and timing threshold constraint between states; (2) Hooking the transaction interface of the target security APP through dynamic instrumentation technology to collect transaction instruction sequence data generated during its operation; (3) Comparing the collected transaction instruction sequence data with the standardized time sequence model according to a preset abnormal score rule, and performing risk level division and ordering on the identified abnormal instruction sequence; (4) Simulating and verifying the operation path corresponding to the high-risk abnormal sequence, confirming the effectiveness of the business logic vulnerability, and generating a detection report.

[0009] Further, in step (1), the specific steps of constructing the standardized time sequence model of the securities transaction process include: 1) Node extraction: analyzing the core business process of securities transactions, and identifying key nodes constituting a complete transaction link; 2) Defining legal state transition paths: determining the execution order and dependency relationship between nodes according to business rules, and marking the allowed state transition paths; 3) Establishing transition trigger conditions: setting trigger conditions for each state transition, which are used for input legality judgment in real transaction scenarios; 4) Time sequence threshold setting: introducing time interval constraints between state transitions, and setting the maximum or minimum allowed state residence time; 5) Data normalization and model output: outputting the above state, transition, trigger condition and time sequence threshold as a standardized time sequence model in the form of five-tuple or structured configuration.

[0010] Further, the standardized time sequence model adopts a finite state machine model structure based on time sequence constraints, which is represented as: M=(S,S0,Σ,T,G,τ) Where S is the state set, including key nodes in the core business process of securities transactions; S0 is the initial state; Σ is the instruction set; T is the state transition function; G is the transition trigger condition set, and τ is the time sequence threshold set, which is used to constrain the time interval between state transitions.

[0011] Further, the trigger condition includes parameter constraints of account available funds, position quantity, transaction period and account state, which are used for input legality judgment in real transaction scenarios.

[0012] Further, in step (2), the transaction instruction sequence data includes instruction type, instruction parameter, timestamp and node jump path; The instruction type includes buy, sell, cancel order, close position and fund settlement; The instruction parameter includes account ID, transaction quantity, timestamp and account state.

[0013] Further, in step (3), the abnormal scoring rule is an abnormal scoring mechanism based on a rule type scoring model, a basic scoring factor is set for different types of abnormal features, a risk weight is allocated to each type of factor, and a comprehensive risk score of the abnormal instruction sequence is obtained through cumulative calculation.

[0014] Further, each abnormal instruction sequence E i The corresponding abnormal features are structured and extracted, denoted as a feature vector: F i ={f i1 ,f i2 ,f i3 ,…,f in} Wherein f i1 indicates whether the trigger condition is violated, f i2 indicates the parameter out-of-range degree, f i3 indicates the timing interval threshold degree, and n is the number of features. The following weighted cumulative scoring formula is used: Each weight W j is determined during model initialization according to the severity of the impact of the abnormal type on the business logic, and the weights satisfy ∑W j =1, indicates the abnormal quantization result of the i th instruction under the j th detection rule.

[0015] Another object of the present application is to provide a security APP business logic vulnerability detection system, comprising: A model construction module for constructing a standardized timing model of a security transaction process; A dynamic instruction acquisition module for hooking a security APP transaction interface through dynamic instrumentation technology to acquire transaction instruction sequence data during security APP operation; An instruction comparison module for comparing the acquired instruction sequence with the constructed timing model using a preset abnormal scoring rule, and performing risk level division and sorting on the identified abnormal instruction sequence; A vulnerability verification module for verifying high-risk abnormal sequences in the scoring results of the instruction comparison module, simulating a hacker attack path, monitoring whether the business logic is invalid, and outputting a detection report.

[0016] Another object of the present application is to provide a computer readable storage medium having a computer program stored thereon, wherein the computer program is executed by a processor to implement the security APP business logic vulnerability detection method provided in the first object of the present application.

[0017] Another object of the present application is to provide a server comprising at least one processor and a memory connected in communication with the processor, the memory storing instructions executable by the at least one processor, the instructions being executed by the processor to cause the at least one processor to perform the security APP business logic vulnerability detection method provided by the first object of the present application.

[0018] In combination with the above technical solution, the present application has the following beneficial effects compared with the prior art: The present application proposes an automatic detection scheme for business logic vulnerabilities based on transaction timing characteristics to solve the technical problems of existing securities trading mobile applications, such as difficulty in detecting cross-process business logic vulnerabilities, reliance on manual verification, and low detection coverage. Through the following key technical steps, the present application achieves the following direct technical effects: 1. Construction of standardized timing model: The present application abstracts core processes such as opening an account, placing an order, canceling an order, closing a position, and clearing funds into a standardized timing model, defines trigger conditions, parameter constraints, node dependencies, and timing thresholds, forms a cross-process and reusable detection benchmark, and covers the entire chain of securities trading business logic, solving the problem of traditional detection that cannot discover timing-dependent vulnerabilities.

[0019] 2. Dynamic instruction collection: Through dynamic instrumentation hooking transaction interfaces, real-time collection of instruction types, parameters, and path information, acquisition of transaction timing data consistent with user real operations, guarantee of detection authenticity and integrity, and avoidance of missed detection problems caused by insufficient simulation.

[0020] 3. Instruction sequence and model comparison and abnormal scoring: By using an abnormal scoring model based on weighted accumulation, conditions such as "not meeting conditions but executing", "parameter out of range", and "timing interval abnormality" are quantitatively scored, enabling multi-dimensional measurement of abnormalities and prioritization of vulnerabilities, improving detection accuracy and coverage (more than about 90%), and solving the problem of traditional detection that can only find single node errors and cannot quantify cross-process abnormalities.

[0021] 4. Vulnerability verification and report output: By simulating hacker attack paths to replay abnormal sequences, verifying whether vulnerabilities cause account funds or position abnormalities, and outputting a hierarchical report, a closed loop from detection to verification is achieved, improving the credibility and operability of the results, reducing manual review costs, and solving the problem of existing detection remaining in the vulnerability prompt stage and lacking verification of vulnerability exploitability.

[0022] In summary, the application solves the problem of difficult detection of cross-process business logic vulnerabilities by the linkage of four core schemes of standardized timing model, dynamic instruction collection, weighted abnormal score, and vulnerability verification output, improves the business logic vulnerability detection coverage to more than about 90%, improves the automation degree of the detection process, and improves the overall efficiency by about 10 times compared with manual detection, shortens the detection time from 24 hours to 2 hours, reduces false positives and false negatives through the abnormal score and verification mechanism, improves the accuracy of vulnerability discovery, has strong expansibility, and can adapt to personalized business rules of different securities company APPs. BRIEF DESCRIPTION OF DRAWINGS

[0023] The accompanying drawings are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and serve to explain the principles of the application, and do not constitute limitations on the application. In the drawings: Figure 1 is a flowchart of a security APP business logic vulnerability detection method provided by an embodiment of the application; Figure 2 is a schematic diagram of a standardized timing model of a security transaction process provided by an embodiment of the application; Figure 3 is a schematic diagram of a dynamic instruction collection architecture provided by an embodiment of the application; Figure 4 is an abnormal score logic flowchart provided by an embodiment of the application; Figure 5 is a vulnerability verification and report output flowchart provided by an embodiment of the application. DETAILED DESCRIPTION

[0024] The preferred embodiments of the application are described below in conjunction with the accompanying drawings, and it should be understood that the preferred embodiments described herein are only used to illustrate and explain the application, and do not limit the application.

[0025] Embodiment 1: As shown in Figure 1 , it is an embodiment of a security APP business logic vulnerability detection method provided by the application, which specifically includes the following steps: S1: constructing a standardized timing model of a security transaction process, the standardized timing model being used to define a legal transaction state, a state transition path, a transition trigger condition, and a time threshold constraint between states; S2: hooking a transaction interface of a target security APP through dynamic instrumentation technology to collect transaction instruction sequence data generated during running; S3: comparing the collected transaction instruction sequence data with the standardized timing model according to a preset abnormal score rule, and performing risk level division and ordering on the identified abnormal instruction sequence; S4: Simulate and verify the operation path corresponding to the high-risk abnormal sequence, confirm the effectiveness of the business logic vulnerability, and generate a detection report.

[0026] Specifically, the present application realizes the automatic detection of the business logic vulnerability of the securities APP by constructing a standardized timing model of the securities transaction process, dynamically collecting the instruction sequence data in actual operation, comparing the instruction sequence with the model, using abnormal scoring rules to identify vulnerabilities, and further simulating the attack path to verify the effectiveness of the vulnerability.

[0027] Step 1: Construct a standardized timing model The core transaction process of the securities transaction APP (account opening verification, order placement, order cancellation, position closing, and fund settlement) is standardized modeled.

[0028] In the present application, in order to realize the automatic detection of the business logic vulnerability of the securities transaction, a standardized timing model of the core business process of the securities transaction mobile application is first constructed. The model uses a timed finite state machine (TFSM) model structure based on timing constraints, which has clear state definition, state transition path, transition trigger condition, and timing threshold constraint, and can be used to depict the complex dependency relationship across nodes in the transaction link.

[0029] The specific modeling steps include: 1) Node extraction: As shown in Figure 2 , the core business process of the securities transaction is analyzed to identify the key nodes that constitute a complete transaction link, including but not limited to "account opening verification", "order placement", "trade / failed trade", "order cancellation", "position closing", "fund settlement", etc., which are defined as state nodes (State) in the model.

[0030] 2) Define the legal state transition path: According to the business rules, determine the execution order and dependency relationship between nodes, and label the allowed state transition (Transition) path. For example, the "account opening completion" state can be legally transferred to the "order placement" state, and the "order placement" state can be transferred to the "order cancellation" or "position closing" state according to whether the trade is completed.

[0031] 3) Establish the transition trigger condition (Guard Condition): Each state transition is triggered by specific conditions, including business parameter constraints such as available funds, open positions, trading session, and account status. These conditions are used to simulate input validity checks in real-world trading scenarios. For example: the trigger condition for placing an order is: Account status = Normal, parameter constraint: Order amount ≤ Available funds; the trigger condition for canceling an order is: No confirmation received from the exchange, parameter constraint: Cancellation amount ≤ Order amount; "Transfer from order placement to closing position" requires "Open position quantity ≥ Closing position quantity, parameter constraint: Closing position amount ≤ Open position amount"; the trigger condition for fund settlement is: Closing execution completed.

[0032] 4) Timing threshold setting (Timer): Introduce time interval constraints between state transitions, setting a maximum or minimum allowed state dwell time. For example, if the "Order Placement" state does not enter the "Transaction" state within 10 seconds, it will automatically transition to the "Cancellation" state to simulate the "timeout cancellation" rule in a real trading environment.

[0033] 5) Data normalization and model output: The aforementioned states, transitions, triggering conditions, and time series thresholds are output as a standardized time series model in either quintuple or structured configurable form. The model can be described as follows: M = (S, S0, Σ, T, G, τ) Where S is the set of states, S0 is the initial state, Σ is the set of instructions (event inputs), T is the state transition function, G is the set of transition triggering conditions, and τ is the set of timing thresholds.

[0034] 6) Matching and detection applications: In the actual testing process, the transaction instruction sequence collected from the application runtime is mapped to a (event, timestamp, parameter) sequence, which drives the TFSM model in real time. If the collected sequence cannot complete a valid transition on the model, or if a transition path that violates the guard conditions / timing threshold appears, it is judged as a business logic anomaly and marked as a suspected vulnerability path for subsequent verification.

[0035] Step 2: Dynamic command acquisition: like Figure 3 As shown, dynamic instrumentation technology (such as Frida, Xposed) is used to link the securities APP trading interface to collect runtime instruction sequence data, including: instruction type (buy, sell, cancel order, close position, clear); instruction parameters (account ID, quantity, timestamp, account status); node jump path.

[0036] Step 3: Compare the instruction sequence with the timing model: The system uses preset anomaly scoring rules for comparison: commands are executed even though the triggering conditions are not met, parameters exceed the constraint range, and time intervals exceed the threshold. The abnormal sequences are scored and sorted.

[0037] Anomaly scoring rules can be configured according to different brokerage apps to adapt to personalized trading rules. In this invention, in order to classify and sort the risk levels of abnormal instruction sequences identified during the detection process and further determine the priority of vulnerability verification, an anomaly scoring mechanism based on a rule-based scoring model is constructed to quantify and score various abnormal states, thereby achieving automated risk assessment.

[0038] (1) Scoring model type like Figure 4 As shown, the scoring model belongs to the interpretable multi-factor linear weighted scoring model (AdditiveWeighted Scoring Model). Its core idea is to set basic scoring factors for different types of abnormal features (such as violation of triggering conditions, parameter anomalies, and timing anomalies), assign risk weights to each factor, and calculate the comprehensive risk score of the abnormal sequence through cumulative calculation. A higher score indicates a higher risk of business logic vulnerabilities, and the detection system can sort the abnormal sequences based on the scores.

[0039] (2) Scoring principle Each abnormal instruction sequence E i The corresponding abnormal features are extracted in a structured manner and denoted as feature vectors: F i ={f i1 ,f i2 ,f i3 ,…,f in} Where f i1 Indicates whether the trigger condition has been violated, f i2 Indicates the degree to which the parameter is out of range, f i3 The time interval represents the degree to which the threshold is exceeded, ..., n represents the number of features. The following weighted cumulative scoring formula is used: Weights W j The severity of the impact of the exception type on the business logic is determined during model initialization, where the weights satisfy ∑W j =1.

[0040] (3) Scoring criteria Triggering condition violation factors (such as "positions not meeting the condition of being open for more than one position, etc."): Assign high weight to W 1， The scoring criteria are as follows: Once → 0.5, continuously → 0.8, cause transaction execution success → 1.0 Parameter out-of-constraint range factor (such as amount, quantity parameter out-of-bound): assign medium-high weight W2, score standard: Out-of-range ≤10% → 0.2, out-of-range ≤50% → 0.4, out-of-range >50% → 0.6 Timing threshold abnormality factor (such as operation timeout, submission interval abnormality fast): assign medium weight W3, score standard: Out-of-threshold 2-10s → 0.1, 10-60s → 0.3, >60s → 0.5 Multiple repeated submission factor (DoS type) (optional enhancement): triggered when repeated calling instructions in a short time exceed the threshold, score standard: Single repetition adds 0.1 points, repetition ≥10 times → maximum 0.8 According to the comprehensive score value, set the risk level threshold: Score interval Risk level Suggested action ≥0.8 High risk Priority vulnerability verification 0.5–0.8 Medium risk Candidate for further analysis ≤0.5 Low risk Record archiving for backup Step 4: vulnerability verification: As shown in Figure 5 , the high-risk sequence in the score result is verified for vulnerability: simulate a hacker attack path (such as repeatedly sending a flat position instruction without checking the position), monitor whether it causes business logic failure (such as abnormal deduction of fund account), output a detection report, including: vulnerability location and description, vulnerability level, repair suggestion.

[0041] The application will be further described below in combination with specific application examples.

[0042] Take "flat business logic vulnerability detection" as an example: 1, build a model: The flat instruction needs to meet: (1) Position quantity ≥ flat quantity; (2) Account status is normal; (3) Trigger time is within the trading period; (4) Flat 10 seconds after the trigger fund clearing instruction.

[0043] 2, collect data: hook "flat interface" "clearing interface", get user instruction sequence: (1) Flat (quantity 100 shares, position only 50 shares); (2) Clearing (deduct 100 shares of funds).

[0044] 3, compare abnormalities: Flat quantity > position quantity, trigger abnormal score (80 points, high risk).

[0045] 4. Vulnerability verification: Simulate the operation, confirm that the fund account is deducted incorrectly, and determine that it is a high-risk vulnerability.

[0046] The technical effects of the present application are further illustrated below in comparison with prior art.

[0047] (1) Purpose of the experiment: To verify the improvement effect of the automatic detection scheme of the present application in terms of "detection coverage" and "detection efficiency" compared with manual detection and traditional tools.

[0048] Project Parameter System under test Dragonfly App (version 9.5.0) Business scope Opening an account, placing an order, canceling an order, closing a position, and clearing Data set 100 different combinations of trading scenarios Artificial detection team 5 people (with more than 2 years of business logic experience) Inventive systematic system Constructed using TFSM model + dynamic instruction collection + abnormal score engine (2) Experimental data and comparison results 1) Comparison of detection coverage Detection method Number of vulnerability scenario detections / total number of scenarios Coverage rate Artificial detection (traditional method) 28 / 100 28% General-purpose fuzzing tool (prior art) 35 / 100 35% Inventive method (time sequence model) 91 / 100 91% 2) Comparison of detection efficiency Detection method Average detection time per scenario Total time for testing 100 scenarios Artificial detection 0.24 hours 24 hours General-purpose fuzzing 0.18 hours 18 hours Inventive automated detection system 0.02 hours 2 hours Example 2 The embodiment of the present application provides a security APP business logic vulnerability detection system, comprising: A model construction module for constructing a standardized time sequence model of a security transaction process; A dynamic instruction collection module for hooking a security APP transaction interface through dynamic instrumentation technology to collect transaction instruction sequence data during security APP operation; An instruction comparison module for comparing the collected instruction sequence with the constructed time sequence model using a preset abnormal scoring rule, and dividing and sorting the identified abnormal instruction sequence into risk levels; A vulnerability verification module for verifying high-risk abnormal sequences in the scoring results of the instruction comparison module, simulating a hacker attack path, monitoring whether it causes business logic failure, and outputting a detection report.

[0049] Example 3 The embodiment of the present application provides a computer readable storage medium having a computer program stored thereon, wherein the computer program is executed by a processor to realize the security APP business logic vulnerability detection method provided in embodiment 1 of the present application.

[0050] Example 4 The embodiment of the present application provides a server comprising at least one processor and a memory communicatively connected to the processor, wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor to cause the at least one processor to execute the security APP business logic vulnerability detection method provided in embodiment 1 of the present application.

[0051] It should be understood that, although the steps in the flowcharts of the embodiments of the present application are shown in a certain order according to the arrows, the steps are not necessarily executed in the order of the arrows. Unless otherwise specified in the present application, the execution of the steps is not strictly limited in order, and the steps can be executed in other orders. Moreover, at least some of the steps in the embodiments can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of the sub-steps or stages is not necessarily sequential, but can be alternated or interlaced with at least part of other steps or sub-steps or stages of other steps.

[0052] It can be understood by those skilled in the art that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the program can be stored in a non-volatile computer readable storage medium. When the program is executed, it can include the processes of the above-mentioned embodiments of the methods. Any reference to memory, storage, database or other medium used in the embodiments provided by the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0053] Finally, it should be noted that: the above only describes the preferred embodiments of the present application, and is not used to limit the present application, although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method for detecting security APP business logic vulnerability, characterized in that, The method comprises: (1) constructing a standardized time sequence model of a security transaction process, the standardized time sequence model being used to define a legal transaction state, a state transition path, a transition trigger condition, and a time sequence threshold constraint between states; (2) hooking a transaction interface of a target security APP through a dynamic instrumentation technology to collect transaction instruction sequence data generated at runtime; (3) comparing the collected transaction instruction sequence data with the standardized time sequence model according to a preset abnormality scoring rule, and performing risk level division and sorting on the identified abnormal instruction sequence; (4) simulating and verifying an operation path corresponding to a high-risk abnormal sequence to confirm the effectiveness of a business logic vulnerability, and generating a detection report. 2.The method of claim 1, wherein, In step (1), the specific steps of constructing the standardized time sequence model of the security transaction process comprise: 1) node extraction: analyzing a core business process of security transaction to identify key nodes constituting a complete transaction link; 2) defining a legal state transition path: determining an execution order and a dependency relationship between nodes according to a business rule, and demarcating an allowed state transition path; 3) establishing a transition trigger condition: setting a trigger condition for each state transition, which is used to simulate input legality judgment in a real transaction scenario; 4) time sequence threshold setting: introducing a time interval constraint between state transitions, and setting a maximum or minimum allowed state residence time; 5) data normalization and model output: outputting the above-mentioned states, transitions, trigger conditions, and time sequence thresholds in a five-tuple or structured configuration form as a standardized time sequence model. 3.The method of claim 2, wherein, The standardized time sequence model adopts a finite state machine model structure based on time sequence constraints, and is represented as: M=(S,S0,Σ,T,G,τ); wherein S is a state set, the state comprising key nodes in a core business process of security transaction; S0 is an initial state; Σ is an instruction set; T is a state transition function; G is a transition trigger condition set, and τ is a time sequence threshold set for constraining a time interval between state transitions.

4. The method of claim 2, wherein, The trigger condition comprises parameter constraints of account available funds, position quantity, transaction period, and account state, and is used to simulate input legality judgment in a real transaction scenario.

5. The method of claim 1, wherein, In step (2), the transaction instruction sequence data comprises: an instruction type, an instruction parameter, a timestamp, and a node jump path; the instruction type comprises buying, selling, canceling, closing, and fund settlement; the instruction parameter comprises an account ID, a transaction quantity, a timestamp, and an account state.

6. The method of claim 1, wherein, In step (3), the abnormality scoring rule is an abnormality scoring mechanism based on a rule-type scoring model, basic scoring factors are respectively set for different types of abnormal features, and a risk weight is allocated to each type of factor, and a comprehensive risk score of an abnormal instruction sequence is obtained through cumulative calculation.

7. The method of claim 6, wherein, Each sequence of exception instructions E i The corresponding exception features are structured extracted, denoted as feature vector: F i ={f i1 ,f i2 ,f i3 ,…,f in}; where f i1 represents whether the trigger condition is violated, f i2 represents the extent of parameter out-of-range, f i3 represents the extent of timing interval out-of-threshold, n is the number of features; The following weighted cumulative scoring formula is adopted: ； Each weight W j The severity of the impact of the type of exception on the business logic is determined at the initialization of the model, where the weights satisfy ∑W j =1, represents the quantitative result of the exception of the ith instruction under the jth detection rule.

8. A security APP business logic vulnerability detection system, characterized in that, The system comprises: a model construction module configured to construct a standardized time sequence model of a security transaction process; a dynamic instruction collection module configured to hook a transaction interface of a security APP through a dynamic instrumentation technology to collect transaction instruction sequence data at runtime of the security APP; and a risk analysis module configured to compare the collected transaction instruction sequence data with the standardized time sequence model according to a preset abnormality scoring rule, perform risk level division and sorting on an identified abnormal instruction sequence, simulate and verify an operation path corresponding to a high-risk abnormal sequence to confirm the effectiveness of a business logic vulnerability, and generate a detection report. The instruction comparison module is configured to compare the collected instruction sequence with the constructed timing model using preset abnormal score rules, and divide and sort the identified abnormal instruction sequence according to risk levels. The vulnerability verification module is configured to verify high-risk abnormal sequences in the score result of the instruction comparison module, simulate a hacker attack path, monitor whether the hacker attack path causes business logic failure, and output a detection report.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by a processor to implement the security APP business logic vulnerability detection method in any one of claims 1 to 7.

10. A server, characterized by: The computer program is executed by a processor to implement the security APP business logic vulnerability detection method in any one of claims 1 to 7. The computer program is executed by a processor to implement the security APP business logic vulnerability detection method in any one of claims 1 to 7.

Images