A state machine-based application testing method, electronic device, and storage medium

Abstract

The application relates to the technical field of vulnerability detection, in particular to an application testing method based on a state machine, an electronic device and a storage medium, the method comprises the following steps: automatically collecting behavior data of a target application from a plurality of preset collection dimensions, and constructing a state machine behavior model based on the behavior data; generating a plurality of test cases based on a variation strategy library constructed based on states and operations in the state machine behavior model, executing the plurality of test cases, and performing deep vulnerability analysis on test response results corresponding to each test case to obtain a vulnerability detection result of the target application; and based on the vulnerability detection result, outputting an API mapping list of the target application and a knowledge graph representing an internal entity relationship network of the target application; the application can automatically generate high-value test cases, efficiently and accurately and automatically mine deep business logic vulnerabilities, and has the characteristics of high automation degree and low false alarm rate.

Description

Technical Field

[0001] This invention relates to the field of vulnerability detection technology, and in particular to an application testing method, electronic device and storage medium based on a state machine. Background Technology

[0002] As enterprises deepen their digital transformation, web applications and APIs that carry core business processes have become critical information infrastructure. However, traditional security testing techniques that focus on common vulnerabilities such as code injection and cross-site scripting show significant limitations when facing business logic vulnerabilities deeply embedded in business rules and processes. These vulnerabilities are deeply embedded in business flows and, compared to traditional injection vulnerabilities, have the following characteristics: their triggering is highly dependent on specific business scenarios and states, and their manifestation may be indistinguishable from normal business responses, making them impossible to identify through simple signatures or tags. Furthermore, traditional static and dynamic application security testing tools cannot understand business semantics, resulting in extremely low detection rates and high false positive rates for these vulnerabilities.

[0003] To address the aforementioned business logic vulnerabilities, current automated detection solutions suffer from the following limitations: Static analysis-based methods search for potential vulnerabilities through code and data flow analysis, but due to their inability to understand business semantics and handle complex state transitions, they suffer from extremely high false positive rates; Dynamic crawling and fuzzing-based methods can discover vulnerabilities by crawling application interfaces and fuzzing parameters, but their test cases are highly unpredictable, have low coverage, and struggle to maintain session states during multi-step operations; Model-based detection methods require pre-defined security protocols or normal behavior models, have low automation levels, heavily rely on expert knowledge, and lack scalability and practicality.

[0004] Therefore, there is an urgent need to provide an application testing method that can automatically understand application business logic, has a low false positive rate, and can accurately and efficiently discover vulnerabilities. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides an application testing method, electronic device, and storage medium based on a state machine. This method can automatically generate high-value test cases, enabling efficient, accurate, and automated discovery of deep business logic vulnerabilities. It features a high degree of automation and a low false positive rate.

[0006] According to a first aspect of the present invention, an application testing method based on a state machine is provided, comprising the following steps:

[0007] Behavioral data of the target application is automatically collected from several preset collection dimensions, and a state machine behavioral model is constructed based on the behavioral data; the state machine behavioral model is constructed based on several business states and the operation transitions between business states.

[0008] Based on the state machine behavior model, several test cases are generated using a preset mutation strategy library; the preset mutation strategy library is built on the basis of business semantic analysis of the several business states and the operation transitions between business states.

[0009] Several test cases are executed, and vulnerability analysis is performed on the test response results corresponding to each test case to obtain the vulnerability detection results of the target application; the vulnerability analysis includes the analysis of response content, the analysis of session state changes, and the business impact assessment based on the analysis results of response content and session state changes.

[0010] Based on the vulnerability detection results, the API mapping list of the target application and the knowledge graph representing the internal entity relationship network of the target application are output.

[0011] According to a second aspect of the present invention, a non-transitory computer-readable storage medium is provided, wherein at least one instruction or at least one program is stored therein, the at least one instruction or the at least one program being loaded and executed by a processor to implement the above-described state machine-based application testing method.

[0012] According to a third aspect of the present invention, an electronic device is provided, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0013] The present invention has at least the following beneficial effects:

[0014] This invention provides an application testing method based on a state machine. First, it automatically collects behavioral data of the target application from several preset dimensions and constructs a state machine behavioral model based on this data. With business states and operations as the core, it provides a precise and computable business logic context for subsequent testing, enabling a deep extension of security testing from the interface level to the business logic level. Then, based on a mutation strategy library constructed through business semantic analysis of the states and operations in the state machine behavioral model, several test cases are generated. These test cases are high-value test cases targeting business logic vulnerabilities and are highly automated, improving the targeting and efficiency of testing, which is conducive to the efficient and automated discovery of deep business logic vulnerabilities. Executing these test cases and performing multi-dimensional deep vulnerability analysis on the test response results for each test case enables accurate vulnerability identification, effectively distinguishing between real business vulnerabilities and superficial anomalies, thereby effectively reducing the false positive rate. Finally, based on the vulnerability detection results, it outputs an API mapping list of the target application and a knowledge graph representing the internal entity relationship network of the target application, providing meaningful data references for security architecture assessment and risk governance. Attached Figure Description

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

[0016] Figure 1 A flowchart of an application testing method based on a state machine provided in an embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] This invention provides an application testing method based on a state machine, such as... Figure 1 As shown, the method includes the following steps:

[0019] S1 automatically collects behavioral data of the target application from several preset collection dimensions, and constructs a state machine behavioral model based on the behavioral data.

[0020] Specifically, the state machine behavior model is constructed based on several business states and the operation transitions between business states; the obtained multi-dimensional behavior data is fused, each business state represents an application interface or data snapshot, and each operation will trigger a state transition, such as clicking a button or calling an API.

[0021] Specifically, the preset data collection dimensions include front-end code parsing, static crawling, interactive traffic monitoring, and API specification document parsing; this can be understood as obtaining behavioral data of the target application from at least four dimensions. Static crawling refers to the process of extracting data from static pages.

[0022] Furthermore, the aforementioned front-end code parsing refers to parsing the target code and constructing a front-end functional tree. Parsing the target code includes extracting front-end routes, API call interfaces, component properties, and state management logic. This can be understood as constructing a front-end functional tree based on the parsed front-end routes, API call interfaces, component properties, and state management logic. In specific implementations, parsing the target code refers to parsing the JavaScript code corresponding to the target application, especially the code corresponding to the front-end framework React or Vue.

[0023] Furthermore, the aforementioned interaction traffic monitoring and API specification document parsing refer to monitoring the interaction traffic between users and the target application in the test environment, and parsing the API specification document to extract several key pieces of information. These key pieces of information include API endpoints, request methods, parameter structures, and response formats. For example, the API specification document could be an OpenAPI specification document or an Owagger specification document. OpenAPI is a standardized API description specification that allows developers to define the structure, parameters, responses, and other information of APIs in a machine-readable manner. Owagger is a suite of tools built around OpenAPI for API documentation generation, testing, and code generation. Those skilled in the art are familiar with the specific implementation methods for parsing API specification documents to obtain the aforementioned key information, and will not be elaborated upon here.

[0024] The above-mentioned approach achieves a comprehensive and structured understanding of complex application behaviors, especially front-end dynamic interactions and back-end APIs, by automatically collecting behavioral data from multiple dimensions. Furthermore, the state machine behavior model built based on the complete behavioral data, with business states and operations at its core, provides accurate and computable business logic context for subsequent testing, enabling security testing to extend deeply from the interface level to the business logic level.

[0025] S2, based on the state machine behavior model, generates several test cases using a preset mutation strategy library; the preset mutation strategy library is built on the basis of business semantic analysis of the several business states and the operation transitions between business states; it can be understood as: by analyzing the business logic corresponding to each business state and each operation in the state machine behavior model, the direction that can be modified or mutated is determined in advance, and based on different mutation directions, several test cases are generated by users or large models.

[0026] Specifically, the preset mutation strategy library includes identity substitution testing, process sequence modification, target parameter tampering, and state anomaly simulation. In specific implementation, identity substitution testing refers to dynamically replacing parameters such as session tokens, user IDs, and accounts in a test sequence to attempt to simulate the identities of users with different permissions, in order to detect horizontal or vertical privilege escalation vulnerabilities. For example, in an order query request, the order ID can be replaced with another user's order ID. Process sequence modification refers to scrambling the order of critical operations or attempting to skip certain verification steps, such as directly attempting to send a payment request in the "add product - checkout - payment" process. Target parameter tampering refers to rule-based modification of business parameters, such as changing the payment amount to a negative number or a very small positive number, or changing the product quantity to a very large value to trigger integer overflow. State anomaly simulation refers to attempting to perform operations in abnormal application states, such as repeatedly submitting forms or accessing the system using expired tokens.

[0027] As mentioned above, since the quality of test cases directly determines the coverage, depth, and accuracy of vulnerability detection, this application, based on the construction of a state machine behavior model, combines business semantics to build a mutation strategy library, which can generate high-value test cases targeting business logic vulnerabilities. This is significantly different from the traditional Fuzzer software testing technology that uses random mutation and random fuzzing, greatly improving the targeting and efficiency of testing. Moreover, this method ensures the legitimacy of test cases in the business context, enabling test simulation to reach the core business logic, thereby achieving efficient and automated discovery of deep business logic vulnerabilities.

[0028] S3, execute several test cases, and perform vulnerability analysis on the test response results corresponding to each test case to obtain the vulnerability detection results of the target application; the vulnerability analysis includes the analysis of the response content, the analysis of session state changes, and the business impact assessment based on the analysis results of the response content and the analysis results of the session state changes.

[0029] Specifically, the analysis of the response content includes the following steps:

[0030] S301, for any test case, compare the test response result of the test case with the given normal response result, and detect whether the test response result contains preset sensitive keywords or operation success keywords. In specific implementations, natural language processing technology or similarity algorithms can be used to analyze the textual differences between the test response result and the given normal response result. For example, it can detect whether the test response result contains data that is not from the current user; sensitive information appearing in the test response result may be other people's email addresses, etc.

[0031] Specifically, the "operation success keyword" refers to the textual identifier that appears in the test response result within the corresponding test context, indicating that the operation that should have failed was successfully executed.

[0032] S302. If a content difference that does not meet the preset conditions is detected based on the difference comparison, or if a preset sensitive keyword or operation success keyword is detected, then a vulnerability is determined to exist; otherwise, a vulnerability is determined not to exist.

[0033] Specifically, content differences that do not meet the preset conditions refer to differences that are determined to be semantically significantly different or have a similarity less than the preset similarity threshold after natural language processing.

[0034] As mentioned above, when analyzing the response content, intelligent comparison and keyword detection can accurately identify potential information leakage and signs of successful unauthorized operations directly from the response data to obtain vulnerability detection results.

[0035] Specifically, the analysis of session state changes includes the following steps:

[0036] S310: For any test case, when the test response result of the test case indicates that the operation corresponding to the test case has been successfully executed, a verification request is initiated based on the operation corresponding to the test case and the target business state corresponding to the operation itself in the state machine behavior model. This can be understood as: the target business state is the expected state, that is, the result that should be achieved in business logic after executing the corresponding operation, obtained from the state machine behavior model. For example, if the operation is "change password", its target business state is "the specified user's password is updated to a new value".

[0037] S320, if the response result of the verification request indicates that the target business state has been achieved, and the execution behavior to achieve the target state conflicts with the permission constraints in the context corresponding to the operation, then a vulnerability is determined to exist; otherwise, no vulnerability is determined to exist. For example, if the operation in the state machine behavior model is "change password," and the test case is "using A's identity to send a request to the change password interface to try to change B's password," and the target business state has been achieved, meaning B's password has been changed, a verification request still needs to be initiated, such as logging into B's account with the new password. If the login is successful, then a vulnerability exists.

[0038] As mentioned above, after executing test cases, such as unauthorized password changes, it is necessary to verify whether the target application can log in with the new password. Through the attack-verification chain, it is verified whether a single operation has truly changed the system's business state, fundamentally eliminating false alarms caused by false success responses, which helps improve the accuracy of vulnerability detection.

[0039] Based on the analysis of response content and session status, it is also necessary to assess whether the abnormal response has indeed caused a security impact on business logic. For example, analysis can be conducted based on expert experience or a trained large model, combining technical anomalies with business context to determine the actual severity of the vulnerability, and transforming security findings into business risk conclusions that can guide the prioritization of remediation.

[0040] The above-mentioned multi-layered in-depth analysis technology, which includes response content, session state, and business impact, rather than relying on HTTP status codes, can accurately determine vulnerabilities, effectively distinguish between real business vulnerabilities and apparent anomalies, thereby effectively reducing the false positive rate. Furthermore, through business impact assessment, technical anomalies are correlated with real business security risks, and vulnerability classifications and evidence with clear business significance are output, which helps to improve the operability of test results and the rationality of remediation strategies.

[0041] In another embodiment, the method further includes the following steps:

[0042] S10, for any operation in the state machine behavior model, generate at least one set of test cases; wherein each test case in each group is obtained by combining and modifying at least two different business parameters based on a mutation strategy of business semantics. For example, test cases that modify 2 parameters are grouped into one group, test cases that modify 3 parameters are grouped into another group, and each test case includes modifications to the parameters corresponding to the operation itself.

[0043] S20 executes each test case set in the sandbox environment and obtains the execution response of each test case in each test case set.

[0044] S30, perform feature matching on each acquired execution response, and count the number k of abnormal responses that match the preset vulnerability characteristics among several execution responses. For example, the preset vulnerability characteristics are returning data that is not from this user or the appearance of unexpected success keywords, and the corresponding normal responses are returning that the order does not exist or empty data.

[0045] S40, perform statistical hypothesis testing based on the total number of test cases n and the number of abnormal responses k corresponding to all test case sets, and calculate the statistical significance index; the statistical significance index is the probability value P of at least k abnormal responses occurring in the total number of test cases n based on a preset baseline random probability P0; it can be understood that: the baseline random probability is a preset maximum acceptable random probability of an abnormal response that meets the characteristics of a vulnerability in a single test under the condition of no vulnerability. For example, when the baseline random probability P0 is 0.01, the statistical significance index is the probability of ≥k abnormal responses occurring under the assumption that P0=0.01.

[0046] Specifically, the statistical significance index meets the following conditions:

[0047] , where the value of i ranges from k to n.

[0048] S50, when the probability value is less than a preset significance level threshold, the occurrence of the abnormal response is considered statistically significant, and the test case corresponding to the abnormal response is determined to have a vulnerability. Those skilled in the art can set the significance level threshold according to actual needs, which will not be elaborated here.

[0049] As described above, by combining parameter mutations to generate a high-coverage test case set, and using statistical significance tests to adjudicate batch abnormal responses, it is possible to accurately and comprehensively uncover deep business logic vulnerabilities that require multiple conditions to trigger and are difficult to find with traditional single-point testing, and effectively filter false alarms caused by accidental failures, thereby improving the accuracy and reliability of vulnerability detection.

[0050] S4, based on the vulnerability detection results, output the API mapping list of the target application and a knowledge graph representing the internal entity relationship network of the target application. The API mapping list is a structured data asset catalog that records all exposed interfaces of the target application and their attribute information, and includes rich context, such as API endpoints, HTTP methods, function descriptions, parameter lists, response specifications, metadata, etc. The knowledge graph is a semantic relationship graph representing the complex relationships between APIs, users, data, states, and business logic. For example, node types may include API nodes, user nodes, data entity nodes, business state nodes, front-end page nodes, operation nodes, etc., and relationship types may include call relationships, permission relationships, data flow relationships, state transition relationships, etc.

[0051] As described above, after identifying vulnerabilities through in-depth vulnerability analysis of the response results, the output API mapping list and knowledge graph are comprehensive and structured in-depth analysis results of the tested application. The API mapping list provides enterprises with a continuously updated vulnerability management foundation, and the knowledge graph reveals the location, propagation path and impact scope of the vulnerability in the business context, providing meaningful data reference for security architecture assessment and risk governance.

[0052] In one specific implementation of the extension, the method further includes the following steps:

[0053] P1, based on the vulnerability detection results, locates the vulnerability in the source code of the target application, and obtains the source code containing the vulnerability.

[0054] P2 parses the source code containing vulnerabilities, obtaining an abstract syntax tree (AST) and a control flow graph (CLP). Based on the AST, CLP, and corresponding vulnerability location information, a given graph neural network model is used to extract the semantic representation of the vulnerability context, generating a vulnerability context feature vector. In practical implementation, the parser uses mature existing technologies to parse the source code containing vulnerabilities. For example, modern compilers such as GCC and Roslyn, or language parsing tools such as ANTLR and Java's JDT module, all have built-in functions to parse source code into ASTs. Existing tools such as Soot for Java and the CodeQL engine can automatically generate a control flow graph after parsing the source code.

[0055] Specifically, the given graph neural network model is the GNN model.

[0056] Specifically, step P2 includes the following steps:

[0057] P201, based on the vulnerability points in the source code, maps the corresponding vulnerability location information from the abstract syntax tree and the control flow graph respectively; it can be understood that the vulnerability points in the source code are the node locations of the vulnerability in the source code.

[0058] On page 202, the abstract syntax tree, control flow graph, and corresponding vulnerability location information are input into the given graph neural network model so that the given graph neural network model aggregates the node information in the abstract syntax tree and control flow graph through the message passing mechanism; this can be understood as: the given graph neural network model aggregates the global syntax and structure information corresponding to the source code.

[0059] P203, the vulnerability location information is injected as an initial feature or attention weight into a given graph neural network model to generate a vulnerability context feature vector corresponding to the source code; it can be understood that the vulnerability context feature vector is a high-dimensional, numerical vulnerability depth representation vector that encodes the global syntax, structure and complete contextual semantics of the vulnerability.

[0060] In practical implementation, when using vulnerability location information as initial features as input, when constructing the initial features of the nodes in the graph, for nodes marked as vulnerability points in the abstract syntax tree or the basic block nodes corresponding to vulnerabilities in the control flow graph, a special dimension representing the vulnerability type or the existence of a vulnerability is added to the feature vector. When using vulnerability location information as attention weights as input, the vulnerability location information serves as an attention-guiding signal; for example, in a given graph neural network model, it makes the model pay more attention to message propagation paths originating from or reaching the vulnerability point.

[0061] As described above, by obtaining the abstract syntax tree and control flow graph, the syntactic structure and execution logic of the source code can be obtained. Based on this, combined with precise vulnerability location information, a high-dimensional context vector is generated. This vector encodes the complete contextual semantics of the vulnerability, enabling the system to deeply understand the semantics. This method transforms discrete code and vulnerability information into a unified semantic representation that can be understood by the machine, providing a reliable data foundation for subsequent accurate retrieval and intelligent generation.

[0062] P3, based on the vulnerability context feature vector, determines the historical vulnerability remediation cases corresponding to the vulnerability context feature vector from the pre-built vulnerability-remediation knowledge base; the vulnerability-remediation knowledge base stores several historical vulnerability remediation cases.

[0063] Specifically, the P3 step includes the following steps:

[0064] P301 calculates the semantic similarity between the vulnerability context feature vector and the historical vulnerability context feature vector in each historical vulnerability remediation case; for example, it calculates the cosine similarity between the vulnerability context feature vector and each historical vulnerability context feature vector.

[0065] Each historical vulnerability remediation case includes a historical vulnerability code snippet, a corresponding remediated code snippet, and a historical vulnerability context feature vector corresponding to the historical vulnerability code snippet.

[0066] P302, the historical vulnerability repair case with the highest corresponding semantic similarity is used as the historical vulnerability repair case corresponding to the determined vulnerability context feature vector.

[0067] The above method performs efficient similarity matching between the semantic vector of the current vulnerability and historical vulnerability remediation cases. The retrieved historical vulnerability remediation cases are the most similar historical cases at the semantic level. This method breaks through the limitations of traditional keyword matching, that is, simple matching that is not literal, and realizes case-based analogical reasoning, which can draw accurate remediation strategy references from massive historical experience.

[0068] P4 generates structured suggestions based on vulnerability context feature vectors and retrieved historical vulnerability remediation cases, which are then input into a pre-trained code generation model to generate a set of candidate remediation codes corresponding to the source code.

[0069] Specifically, code generation models can be based on Transformer, such as CodeT5 and InCoder.

[0070] As mentioned above, the code big model, based on its deep understanding of code syntax and semantics, automatically infers and generates repair code according to the questions and cases in the prompts. This process is not a simple template filling, but rather guides the model to integrate the current vulnerability issues with historical experience, creatively generating multiple syntactically correct repair solutions that are adapted to the current vulnerability context, thus achieving true code generation and adaptation.

[0071] P5 evaluates each candidate fix code in the candidate fix code set and selects the optimal fix code to automatically fix the source code vulnerability.

[0072] In one specific embodiment, step P5 includes the following steps:

[0073] On page 501, each candidate code in the candidate code set undergoes a compilation test and a pre-defined regression test in sequence. Based on the test results, candidate code that passes the tests is selected. This can be understood as selecting syntactically correct code that does not introduce functional regression. Specifically, the compilation test verifies whether the generated candidate code is syntactically and semantically correct, that is, whether the candidate code can be successfully accepted by the compiler or interpreter of the programming language without producing compilation errors or interpreter syntax errors. In practice, the source code file containing the candidate code is submitted to the standard compiler of the corresponding language, such as gcc or javac, for construction. Regression testing is used to verify the functional correctness of candidate fixes. Its core purpose is to ensure that the fix does not break the original correct functionality of the program, i.e., it does not introduce functional regression. During implementation, a pre-defined test suite is run, and the test results before and after the fix are compared. Tests that passed before the fix must still pass after the fix. Automatically generated code may have the following problems: over-fixing, such as modifying code unrelated to the vulnerability, causing other functions to malfunction; inaccurate fixing, such as patching the vulnerability but changing interface behavior or algorithm logic; and side effects, such as introducing concurrency issues, performance degradation, or resource leaks. Regression testing effectively captures these problems, ensuring the correctness of the fix and minimizing its impact.

[0074] P502, for each candidate code patch that passes the test, calculate the evaluation scores for the candidate code patch in three dimensions: code style consistency, code complexity, and patch minimization principle. In the specific implementation, when obtaining the code style consistency evaluation score S1, the candidate code patch and several code files randomly sampled from the corresponding project are parsed to extract several preset style feature vectors. The mean cosine similarity between the style feature vector corresponding to the candidate code patch and the style feature vectors corresponding to the several code files is calculated. The calculation result is used as the code style consistency evaluation score. The preset style feature vectors include lexical features such as identifier naming patterns and constant naming patterns, layout features such as line length distribution, operator spacing habits, tab characters and width, and comment features such as comment density and comment position patterns.

[0075] Furthermore, the calculation steps for the code complexity evaluation score S2 are as follows:

[0076] Based on the control flow graph corresponding to the constructed candidate repair code, the cyclomatic complexity of the candidate repair code is calculated; whereby the cyclomatic complexity satisfies the following condition:

[0077] C = E - N + 2P, where C is the cyclomatic complexity, E and N are the number of edges and nodes in the control flow graph corresponding to the candidate repair code, respectively, and P is the number of connected components, which is usually set to 1.

[0078] Based on the cyclomatic complexity and the preset maximum complexity threshold, the code complexity evaluation score S2 is calculated; wherein the code complexity evaluation score S2 meets the following conditions:

[0079] S2=1-C / C max , where C max This is a preset maximum complexity threshold.

[0080] Preferably, the calculation steps for the evaluation score S3 of the patch minimization principle are as follows:

[0081] P5021, construct the abstract syntax tree corresponding to the candidate repair code, and calculate the degree of difference between the abstract syntax tree corresponding to the source code and the abstract syntax tree corresponding to the candidate repair code; where the degree of difference is represented by the edit distance; it can be understood that the edit distance refers to the minimum number of nodes that need to be inserted, deleted and updated in the original abstract syntax tree.

[0082] P5022, based on the degree of difference and the preset maximum tolerable difference, the evaluation score S3 of the patch minimization principle is calculated; wherein, the evaluation score S3 of the patch minimization principle meets the following conditions:

[0083] S3 = 1 - D / D max Where D represents the degree of difference between the abstract syntax tree corresponding to the source code and the abstract syntax tree corresponding to the candidate fix code. max This is the preset maximum tolerance difference.

[0084] P503, the evaluation scores of each candidate repair code that passes the test are normalized in the three dimensions respectively, and weighted and fused based on the preset weight coefficients corresponding to each dimension to calculate the comprehensive quality score corresponding to each candidate repair code that passes the test; it can be understood that: in each dimension, the evaluation score of the candidate repair code corresponding to the dimension is normalized to between 0 and 1, for example, min(1, S3) is used as the normalized result of S3, or the min-max normalization method is used, which will not be elaborated here.

[0085] Preferably, W1 < W2 < W3, and W3 > 0.5, where W1 is the preset weight coefficient corresponding to code style consistency, W2 is the preset weight coefficient corresponding to code complexity, and W3 is the preset weight coefficient corresponding to the patch minimization principle.

[0086] Since the principle of patch minimization aims to fix only vulnerabilities without making any irrelevant changes, it directly relates to the security and correctness of the fix, ensuring the accuracy and security of the fix, which is the primary prerequisite for the patching process. Code complexity affects the readability, testability, and probability of introducing defects in the future. While ensuring the correctness of the fix, controlling complexity is beneficial to maintaining the long-term health and sustainable security of the software. Code style consistency mainly affects the readability of the code and the efficiency of team collaboration, hence the above weighting coefficients are set.

[0087] P504, the candidate repair code with the highest overall quality score is selected as the optimal repair code.

[0088] The above-mentioned automated compilation and regression testing of multiple candidate repair codes can verify their syntactic correctness without breaking the original functionality. Furthermore, the comprehensive evaluation and ranking based on multi-dimensional indicators avoid the bias that may be caused by a single indicator, ensuring that the optimal repair solution is selected. On the basis of ensuring the correctness of the repair, the reliability, security and engineering usability of the final repair solution are significantly improved.

[0089] Specifically, the method further includes the following steps:

[0090] P6. Add the source code, the corresponding optimal fix code, and the corresponding vulnerability context feature vector as new historical vulnerability fix cases to the vulnerability-fix knowledge base.

[0091] As described above, by automatically storing successfully verified remediation cases and their complete context as new cases into the knowledge base, the system possesses the ability to continuously learn and evolve, which can be used for subsequent retrieval and reasoning, thereby effectively improving the accuracy and efficiency of handling similar or even new vulnerabilities in the future.

[0092] Furthermore, the method also includes the following steps:

[0093] P100: After selecting the optimal fix code and automatically fixing the source code vulnerability, return to step S3 to obtain new vulnerability detection results.

[0094] P200: If the new vulnerability detection result indicates that the patched source code still contains vulnerabilities, the patched target code is treated as the source code containing the vulnerabilities, and steps P2-P5 are executed again to select the new optimal patch code for automated vulnerability patching. Note that when the patched target code is used as the source code containing the vulnerabilities, the vulnerability location information in the source code has changed.

[0095] P300 iterates through steps P100-P200 until a new vulnerability detection result indicates that the repaired source code does not contain vulnerabilities, or the number of iterations reaches a preset iteration threshold. At this point, the final repair result and vulnerability detection result are fed back to the user. Those skilled in the art can set the preset iteration threshold according to actual needs; details are omitted here.

[0096] As described above, by introducing a closed loop of re-detection and iterative repair, we can address secondary vulnerabilities or incomplete repairs caused by improper patching, enabling the entire system to have self-verification and continuous optimization capabilities, and significantly improving the reliability and security of the final repair solution.

[0097] Embodiments of the present invention also provide a non-transitory computer-readable storage medium that can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiments, wherein the at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided in the above embodiments.

[0098] Embodiments of the present invention also provide an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0099] While specific embodiments of the invention have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. It should also be understood that various modifications can be made to the embodiments without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.

Claims

1. An application testing method based on a state machine, characterized in that, The method includes the following steps: S1, automatically collect behavioral data of the target application from several preset collection dimensions, and construct a state machine behavioral model based on the behavioral data; the state machine behavioral model is constructed based on several business states and operation transitions between business states; S2, Based on the state machine behavior model, several test cases are generated using a preset mutation strategy library; the preset mutation strategy library is constructed based on business semantic analysis of the several business states and the operation transitions between business states; S3, execute several test cases, and perform vulnerability analysis on the test response results corresponding to each test case to obtain the vulnerability detection results of the target application; the vulnerability analysis includes the analysis of response content, the analysis of session state changes, and the business impact assessment based on the analysis results of response content and the analysis results of session state changes. S4. Based on the vulnerability detection results, output the API mapping list of the target application and the knowledge graph representing the internal entity relationship network of the target application; The method further includes the following steps: S10, For any operation in the state machine behavior model, generate at least one set of test cases; wherein each test case in each set is obtained by combining and modifying at least two different business parameters based on a mutation strategy of business semantics. S20: Execute each test case set in the sandbox environment and obtain the execution response of each test case in each test case set; S30, perform feature matching on each obtained execution response, and count the number k of abnormal responses that match the preset vulnerability characteristics among several execution responses; S40, Perform statistical hypothesis testing based on the total number of test cases n and the number of abnormal responses k corresponding to all test case sets, and calculate the statistical significance index; the statistical significance index is the probability value of at least k abnormal responses occurring in the total number of test cases n based on a preset baseline random probability. S50, when the probability value is less than the preset significance level threshold, it indicates that the occurrence of the abnormal response is statistically significant, and the test case corresponding to the abnormal response is determined to have a vulnerability.

2. The application testing method based on a state machine according to claim 1, characterized in that, The preset collection dimensions include front-end code parsing, static crawler, interactive traffic monitoring, and API specification document parsing. The aforementioned front-end code parsing refers to parsing the target code and constructing a front-end functional tree; the parsing of the target code includes extracting front-end routes, API call interfaces, component attributes, and state management logic; The interaction traffic monitoring and API specification document parsing refer to monitoring the interaction traffic between users and the target application in the test environment, and parsing the API specification document to extract several key pieces of information, including API endpoints, request methods, parameter structures, and response formats.

3. The application testing method based on a state machine according to claim 1, characterized in that, The preset mutation strategy library includes identity replacement testing, process sequence modification, target parameter tampering, and state anomaly simulation.

4. The application testing method based on a state machine according to claim 1, characterized in that, The analysis of the response content includes the following steps: S301, for any test case, compare the test response result of the test case with the given normal response result, and detect whether the test response result contains preset sensitive keywords or operation success keywords; S302. If a content difference that does not meet the preset conditions is detected based on the difference comparison, or if a preset sensitive keyword or operation success keyword is detected, then a vulnerability is determined to exist. Otherwise, it is determined that there is no vulnerability.

5. The application testing method based on a state machine according to claim 1, characterized in that, The analysis of session state changes includes the following steps: S310, For any test case, when the test response result of the test case indicates that the operation corresponding to the test case has been successfully executed, a verification request is initiated based on the operation corresponding to the test case and the target business state corresponding to the operation itself in the state machine behavior model; S320, if the response result of the verification request indicates that the target business state has been achieved, and the execution behavior of achieving the target state conflicts with the permission constraints in the context corresponding to the operation, then it is determined that there is a vulnerability; otherwise, it is determined that there is no vulnerability.

6. The application testing method based on a state machine according to claim 1, characterized in that, The method further includes the following steps: P1, based on the vulnerability detection results, locate the vulnerability in the source code of the target application to obtain the source code containing the vulnerability; P2 parses the source code containing the vulnerability to obtain an abstract syntax tree and a control flow graph. Based on the abstract syntax tree, the control flow graph, and the corresponding vulnerability location information, a given graph neural network model is used to extract the semantic representation of the vulnerability context and generate a vulnerability context feature vector. P3, based on the vulnerability context feature vector, determines the historical vulnerability remediation cases corresponding to the vulnerability context feature vector from the pre-built vulnerability-remediation knowledge base; the vulnerability-remediation knowledge base stores several historical vulnerability remediation cases; P4 generates structured suggestions based on vulnerability context feature vectors and retrieved historical vulnerability remediation cases, which are then input into a pre-trained code generation model to generate a set of candidate remediation codes corresponding to the source code. P5 evaluates each candidate fix code in the candidate fix code set and selects the optimal fix code to automatically fix the source code vulnerability.

7. The application testing method based on a state machine according to claim 6, characterized in that, The method further includes the following steps: P100: After selecting the best fix code and automatically fixing the source code vulnerability, return to step S3 to obtain new vulnerability detection results. P200: If the new vulnerability detection result indicates that the repaired source code still contains vulnerabilities, the repaired target code is regarded as the source code containing vulnerabilities, and the P2-P5 steps are returned to be executed to select the new optimal repair code for automated repair of source code vulnerabilities. P300 iterates through steps P100-P200 until a new vulnerability detection result indicates that the repaired source code does not contain vulnerabilities or the number of iterations reaches a preset threshold. Then, the final repair result and vulnerability detection result are fed back to the user.

8. A non-transitory computer-readable storage medium, wherein the storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one program segment is loaded and executed by the processor to implement the state machine-based application testing method as described in any one of claims 1-7.

9. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 8.

Images