An evaluation method for smart contract access control vulnerability mutation generation effectiveness

Abstract

This invention proposes an evaluation method for the effectiveness of mutation generation for smart contract access control vulnerabilities. The method first uses an abstract syntax tree to identify functions in the contract containing sensitive operations such as asset transfer and contract self-destruction, and extracts the access control triples protecting these functions to pinpoint existing ACV vulnerabilities. Second, it performs code-level repairs on the faulty access control components, restoring the previously compromised subject identification or authorization verification logic to normal, thus fixing the access control vulnerabilities. Third, the repaired, vulnerability-free contract is given to a mutation tool for mutation, resulting in a mutated vulnerability dataset. Finally, the mutation results are compared to see if the repaired logic is successfully re-destroyed, and the Jaccard similarity coefficient between the mutated vulnerability and the original contract with the vulnerability is calculated, thereby determining the effectiveness of the mutation tool in generating ACV vulnerabilities.

Description

Technical Field

[0001] This invention belongs to the field of information security, focusing on the security of smart contracts, and specifically applicable to the evaluation of the validity of results generated by Access Control Vulnerability (ACV) mutation tools. The core idea is to patch a real-world ACV-vulnerable contract and then use a mutation tool to mutate it. The mutated result is then compared with the original real contract's ACV vulnerability to determine whether the generated vulnerability can effectively simulate a real-world ACV vulnerability. By testing the validity of the vulnerabilities generated by the ACV vulnerability mutation tool, reliable data support is provided for the evaluation and optimization of ACV vulnerability mutation tools. Background Technology

[0002] Smart contracts, as a key component of decentralized applications, control a large amount of digital assets, and their security has always been a major concern. ACV (Automatic Vulnerability) vulnerabilities are among the most damaging vulnerabilities in smart contracts, stemming from design flaws in permission management mechanisms that allow unauthorized users to perform sensitive operations such as fund transfers and modification of contract parameters. Currently, various tools exist for detecting ACV vulnerabilities, and evaluating these tools requires a large number of ACV vulnerabilities. Since manually creating vulnerability datasets is time-consuming and labor-intensive, mutation tools have emerged to automate the generation of ACV vulnerabilities, providing sufficient datasets for evaluation and testing tools. Mutation refers to making minor modifications to parts of the contract code to introduce vulnerabilities into a previously vulnerability-free contract, thus creating a vulnerable contract. However, it is impossible to directly prove whether the vulnerabilities generated by mutation are sufficiently similar to real contracts, i.e., whether they can simulate the effects of real-world vulnerabilities. Therefore, a method is needed to evaluate the effectiveness of the mutated ACV vulnerability dataset.

[0003] To address this issue, this invention proposes an evaluation method for the effectiveness of mutation generation for smart contract access control vulnerabilities. The method first abstracts the access control mechanism in the target contract into a triple encompassing subject identification, authorization verification, and operation execution, and then uses AST analysis to identify defective triples. Secondly, it repairs and refactors the code at the failure level, restoring the previously invalid control or data flow to its original state, thus fixing the ACV vulnerability. Thirdly, the repaired contract is then subjected to mutation using a mutation tool to obtain a mutated vulnerability dataset. Finally, the Jaccard similarity coefficient between the mutated vulnerability and the original target contract vulnerability is calculated to determine the effectiveness of the mutation tool in generating the vulnerability. Summary of the Invention

[0004] This invention comprises three steps: ACV vulnerability location, ACV vulnerability remediation, and effectiveness evaluation of ACV vulnerability mutation results.

[0005] First, the input real-world smart contract containing vulnerabilities is translated into an Abstract Syntax Tree (AST). Since ACV (Active Function Values) primarily targets critical operations, the system first identifies functions containing sensitive operations through static feature matching and establishes these sensitive operations as the operation execution stage (E) of the triplet. Subsequently, the system uses the control flow graph to find the conditional predicate or modifier governing this execution node, establishing it as the authorization verification stage (V); and verifies the identity variables that the logic depends on through data flow tracing, establishing it as the subject identification stage (I). The system then processes the extracted ACM...<I, E V,> Triples are used for defect analysis: if subject identification uses tx.origin instead of msg.sender, it is marked as a subject identification TOA vulnerability; if the authorization verification V step is missing or always true, it is marked as an authorization verification MAC vulnerability; if the execution target E is unexpected, it is marked as an operation execution IOT vulnerability. All vulnerable triple mappings constitute the set TM.

[0006] Next, code transformation and remediation are performed for each vulnerability in the TM set. For the TOA vulnerability, tx.origin is replaced with msg.sender in the AST; for the MAC vulnerability, a require guard statement containing identity assertions is inserted before sensitive operations, or the onlyOwner modifier is added; for the IOT vulnerability, the target variable of the sensitive operation is redirected to the expected legitimate address. These operations generate a remediated vulnerability-free contract tcR. Then, the remediated smart contract tcR is passed to the ACV vulnerability mutation tool to be evaluated for mutation, resulting in a code version tcM containing the mutation results.

[0007] Finally, the location and logic of the ACV vulnerabilities detected by tcM are compared with those detected by the original contract. If the mutation tool successfully disrupts the mutated repair logic again, it indicates that the tool can generate the corresponding mutant at the location where the real vulnerability originally occurred, and the mutated result can highly simulate real-world ACV vulnerabilities. The system calculates the intersection of successfully simulated vulnerabilities and performs statistical analysis using the Jaccard similarity coefficient formula.

[0008] Specifically, the method includes the following steps:

[0009] Step 1: Locating ACV vulnerabilities

[0010] Input: target contract tc

[0011] Output: A set of triples containing ACV vulnerabilities (TM)

[0012] Step 1)-1: Initial state;

[0013] Step 1)-2: Input the target contract tc, and use the compiler frontend to parse it into an abstract syntax tree (AST);

[0014] Steps 1)-3: Traverse all FunctionDef nodes in the AST and use pattern matching to find the set of nodes SO containing built-in native transfer, token transfer or contract selfdestruct sensitive operations;

[0015] Step 1)-4: Traverse each sensitive operation node (so) in SO;

[0016] Steps 1)-5: Through backward control flow analysis, find the conditional predicate AST node and modifier invocation node that strictly govern the so, and extract them as the permission verification link V;

[0017] Steps 1)-6: Extract the variables used within the V stage, find the data source on the AST through data flow analysis, and if the source node is a global identity identifier, then establish it as the subject identification stage I;

[0018] Step 1)-7: Construct Access Control Triples (ACM)<I, E V,> ;

[0019] Step 1)-8: Determine if the triple has a defect: If the I stage uses tx.origin, it is a TOA vulnerability; if the V stage is missing, it is a MAC vulnerability; if the fund recipient in the E stage is an abnormal address, it is an IOT vulnerability.

[0020] Step 1)-9: If the triple is defect-free, skip to step 1)-4;

[0021] Step 1)-10: Add the vulnerable triples to the output set TM;

[0022] Step 1)-11: When all SOs in tc have been traversed, output the set TM containing ACV vulnerabilities;

[0023] Step 1)-12: End state.

[0024] Step 2: ACV vulnerability patching

[0025] Input: A set of ACV vulnerabilities TM and the target contract tc

[0026] Output: The fixed vulnerability triplet set TMR and the fixed contract TCR

[0027] Step 2)-1: Initial state; Step 2)-2: Input a set TM containing ACV vulnerabilities;

[0028] Steps 2)-3: Initialize an empty result set TMR = {};

[0029] Steps 2)-4: Deep copy the TC contract in memory to generate the TCR contract, which will serve as a copy of the base code for the repair.

[0030] Step 2)-5: Iterate through each vulnerability triplet element in TM;

[0031] Steps 2)-6: Identify the vulnerability type of the element and generate remediation operations on the corresponding node in the tcR AST: If it is a TOA vulnerability, modify the Identifier node and replace tx.origin with msg.sender; if it is a MAC vulnerability, insert a require(msg.sender == owner) permission judgment statement node at the beginning of the corresponding sensitive function FunctionDef; if it is an IOT vulnerability, modify the execution node parameters and replace the target address with a valid msg.sender or a preset variable.

[0032] Steps 2)-7: Record the specific lines of code and AST nodes involved in the repair operation, form the repaired triplet, add it to the output set TMR, and convert the AST back to Solidity source code to obtain the repaired contract tcR;

[0033] Step 2)-8: When the TM traversal is complete, output the results TMR and tcR;

[0034] Step 2)-9: End state.

[0035] Step 3: Validity assessment of ACV vulnerability mutation results

[0036] Input: Repaired contract tcR, repaired triplet set TMR, mutation tool to be evaluated

[0037] Output: Jaccard similarity coefficient (JSC) of mutation tool mutation vulnerabilities

[0038] Step 3)-1: Initial state;

[0039] Step 3)-2: Using tcR as input, call the mutation testing tool to be evaluated and obtain its output set of mutation contracts tcM;

[0040] Step 3)-3: Initialize the evaluation index variables M1, M2 and M3, and set their initial values ​​to 0; wherein, M1 is used to represent the number of real vulnerabilities successfully identified by the tool, M2 is used to represent the number of non-original vulnerabilities that the tool autonomously mutates, and M3 is used to represent the number of real vulnerabilities that have not been mutated.

[0041] Steps 3)-4: Input the TMR result obtained in Step 2;

[0042] Steps 3)-5: Iterate through each repair element in the TMR;

[0043] Steps 3)-6: Check the corresponding functions and lines of code in the mutation set tcM to determine whether the previous mutation repair defenses have been destroyed by the mutation tool;

[0044] Step 3)-7: If the destruction conditions are met, it means that the mutation tool has successfully generated a reasonable ACV vulnerability in the actual business scenario of the contract, incremented the M1 count by one, and marked the mutation point in tcM.

[0045] Step 3)-8: If the repair defense is not broken in all tcM variants, it means that the real vulnerability has not been covered by the mutation tool, and the number of M3 is incremented by one;

[0046] Step 3)-9: After all elements in TMR have been traversed, count the number of remaining unmarked mutation vulnerabilities in tcM and assign them to M2;

[0047] Step 3)-10: Calculate the Jaccard similarity coefficient JSC = M1 / ​​(M1 + M2 + M3) between the set of mutated vulnerabilities generated by the mutation tool and the actual set of vulnerabilities in the original contract;

[0048] Step 3)-11: Output the Jaccard similarity coefficient (JSC). The closer the JSC value is to 1, the closer the vulnerability generated by the mutation tool is to the real-world vulnerability distribution of the dataset.

[0049] Step 3)-12: End state. Attached Figure Description

[0050] Figure 1 This is a flowchart illustrating an evaluation method for the effectiveness of smart contract access control vulnerability mutation generation in an embodiment of the present invention.

[0051] Figure 2 for Figure 1 A flowchart for locating ACV vulnerabilities in China.

[0052] Figure 3 for Figure 1 A flowchart for fixing the ACV vulnerability in China.

[0053] Figure 4 for Figure 1 A flowchart for evaluating the validity of ACV vulnerability mutation results. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0055] This invention proposes an evaluation method for the effectiveness of mutation generation for smart contract access control vulnerabilities. In a specific implementation scenario, this method can be automatically executed by a computer device equipped with a smart contract static analysis engine. The specific implementation process is as follows:

[0056] Step 1: Locating and remediating access control vulnerabilities based on abstract syntax trees:

[0057] The computer device receives the source code of a target smart contract containing real-world business logic and potential access control vulnerabilities, and calls the compiler front-end tool to parse it into an abstract syntax tree. The system traverses all function definition nodes in the abstract syntax tree, and uses preset pattern matching rules to identify sensitive execution nodes involving asset transfer and contract self-destruction, marking them as operation execution stages. Next, the system performs backward slice analysis along the control flow of the abstract syntax tree, extracting the conditional predicate nodes and permission modifier nodes that govern the sensitive operation, marking them as permission verification stages. Furthermore, through data flow tracing technology, the system extracts the identity source nodes that the permission verification stage depends on, marking them as subject identification stages.

[0058] The system automatically reviews the constructed triples: if an insecure transaction initiator identifier is detected in the entity identification stage, it is classified as a TOA (Transaction Initiator) vulnerability; if the authorization verification stage lacks effective verification, it is classified as a MAC (Machine Access Control) vulnerability; if the funds flow to an unexpected address in the operation execution stage, it is classified as an IoT (Internet of Things) vulnerability. The system packages the detected vulnerability triples and their precise location coordinates on the abstract syntax tree into a vulnerability mapping set.

[0059] The system reads vulnerability records from the vulnerability mapping set and creates an abstract syntax tree copy of the target contract in memory. For different types of vulnerabilities, the system performs node-level automated reconstruction and remediation on the abstract syntax tree copy: for TOA-type vulnerabilities, the system locates the corresponding identity node and securely replaces it with the direct caller's identity; for MAC-type vulnerabilities, the system dynamically inserts permission assertion nodes containing privileged variable comparison logic into the pre-control flow path of sensitive operations; for IoT-type vulnerabilities, the operation target parameters are redirected to a legitimate preset entity.

[0060] After the repair is complete, the system will convert the modified abstract syntax tree back into smart contract source code and output a completely secure repair contract. Simultaneously, the system will encapsulate the coordinates of all abstract syntax tree nodes that have undergone the repair operation, generating a repair location mapping set.

[0061] Step two: Generation and mutation of repair results:

[0062] The system inputs the aforementioned generated security remediation contract as a benchmark sample into the vulnerability mutation generation tool to be evaluated. This mutation tool, based on its internal algorithm, automatically generates vulnerability mutations on the security contract, outputting a set of mutated contracts containing several variants.

[0063] Step 3: Evaluation of the effectiveness of variation based on location consistency:

[0064] The system initiates automated location consistency comparison. The system initializes evaluation metric variables M1, M2, and M3, all with an initial value of 0. The system iterates through the repair location mapping set, extracts the precise coordinates of previously mutated repair logic, and retrieves the corresponding location in the mutation contract set. If the system finds that the mutation tool has implemented a mutation operator precisely at the coordinates of the mutated repair logic—for example, by tampering with the recently repaired security identity again, or by removing or modifying an inserted permission assertion node to a tautology—then the system determines that the mutation tool has successfully captured an access control vulnerability in the real business logic. At this point, the system increments the M1 variable, representing the number of successfully identified real vulnerabilities.

[0065] If, during the traversal, some repair coordinates are found to remain intact in the mutated contract set, it indicates that the mutation tool failed to identify the actual vulnerability location. The system increments the M3 variable, representing the number of actual vulnerabilities not mutated. After comparing all repair coordinates, the system counts any additional mutated nodes in the mutated contract set that do not coincide with the repair location set. These are considered invalid, blind mutations deviating from the actual business logic and are added to the M2 variable, representing the number of non-original vulnerabilities mutated autonomously. Finally, the system uses the formula... Calculate the Jaccard similarity coefficient. The system outputs the score result. The closer the score is to 1, the more accurately it reflects the complex distribution characteristics of smart contracts, and the higher the effectiveness of its mutation generation is demonstrated.

Claims

1. A method for evaluating the effectiveness of mutation generation for smart contract access control vulnerabilities, characterized in that, This invention comprises three main steps: ACV vulnerability localization, ACV vulnerability remediation, and validity evaluation of ACV vulnerability mutation results. First, the input contract is transformed into an Abstract Syntax Tree (AST), and sensitive operations within the smart contract are located and abstracted into a triple ACM containing subject identification (I), permission verification (V), and operation execution (E).<I, E V,> The method involves analyzing whether access control failures exist in the triples and grouping vulnerable ACMs into a set TM. Next, vulnerabilities in the TM set are repaired. For TOA, MAC, and IoT vulnerabilities, the correct access control logic is restored at the code level to achieve the effect of repairing access control vulnerabilities. The repaired smart contract is then given to an ACV vulnerability mutation tool for mutation. The mutation result is compared with the ACV vulnerabilities detected in the original contract. If the location of the mutation damage matches the location of the repair logic mutation, it indicates that the mutation result can simulate real-world ACV vulnerabilities. Finally, the Jaccard similarity coefficient between the mutation tool's mutated vulnerabilities and the original contract with vulnerabilities is calculated. Specifically, this method includes the following steps: 1) ACV vulnerability localization: The target contract tc is taken as input and the output is a set of access control triples TM containing ACV vulnerabilities. First, the input contract is transformed into an abstract syntax tree. Sensitive operations in the target contract are identified through pattern matching, including asset transfer, contract destruction and permission change. Then, the subject identification node and permission verification node protecting the sensitive operation are extracted through control flow and data flow analysis, and the ACM triple is constructed. Observe each ACM triple. If the subject identification uses tx.origin, the permission verification node is missing, or the target object of the operation is maliciously set, it is considered that there is a corresponding TOA, MAC or IOT type ACV vulnerability. Add the vulnerable ACM triple to the set TM. After all sensitive operations are processed, return to TM. 2) ACV Vulnerability Repair: The input is the set of triples TM containing ACV vulnerabilities generated in the previous step, and the output is the repaired set of ACV vulnerabilities TMR and the repaired contract tcR. First, an empty set is initialized to store the result TMR. Then, the elements in TM are traversed, and targeted repairs are performed for each vulnerability triple: if it is a TOA type vulnerability, tx.origin in the code is replaced with the correct msg.sender; if it is a MAC type vulnerability, a require statement or modifier is added before the sensitive operation function for permission checking; if it is an IOT type vulnerability, the incorrect receiver is replaced with the expected legitimate address. Finally, the repaired triples are added to TMR. After all the elements in TM have been processed, the result TMR and the repaired contract tcR obtained by replacing the original code are output. 3) Validity Evaluation of ACV Vulnerability Mutation Results: Using the TMR and tcR generated in the previous step as input, output the Jaccard similarity coefficients of the original contract with ACV vulnerabilities and the vulnerabilities mutated by the ACV vulnerability mutation tool. First, let A be the set of ACV vulnerabilities mutated by the mutation tool, and B be the set of ACV vulnerabilities in the original contract. Create three integer variables M1, M2, and M3, with initial values ​​of 0: M1 = A∩B, M2 = AB, and M3 = BA. The Jaccard similarity coefficient is calculated as JSC = |A∩B| / |A∪B| = M1 / (M1 + M2 + M3). Second, input the tcR into the mutation tool to obtain the mutation result tcM. Then, iterate through the elements in the TMR to find the security verification statement modified or written when fixing the vulnerability. If the security verification statement is destroyed by the mutation tool in tcM, it is considered that the mutation tool has successfully mutated the real ACV vulnerability in the original contract, and the count of M1 is incremented by one. If the repair statement injected in the TMR is not broken in the TCR, it is considered that the vulnerability has not been identified by the mutation tool, and the number of M3 is incremented by one; after all elements in all TMRs have been traversed, the remaining vulnerabilities mutated in the TCR are considered as vulnerabilities mutated autonomously by the mutation tool, and their number is assigned to M2; finally, the Jaccard similarity coefficient JSC = M1 / ​​(M1 + M2 + M3) between the mutation tool's mutated vulnerabilities and the original contract with vulnerabilities is given.

2. The method for locating access control vulnerabilities according to claim 1, characterized in that, In step 1), taking the target contract tc as input, identify all functions containing sensitive operations, denoted as SO; traverse the SO set, extract the type, function, AST node, and target object of the sensitive operation through the abstract syntax tree; find the conditional predicate or modifier that governs the operation to form the authorization verification V, and find the identity source to form the subject identification I through data flow analysis; if the I link in the triple depends on tx.origin, or the V link is missing, or the target of the E link is unexpected, it is considered that there is an ACV vulnerability; add the vulnerable triple to the set TM; finally, after all traversals are completed, output the result TM.

3. The method for fixing access control vulnerabilities according to claim 1, characterized in that, In step 2), the set of triples TM containing ACV vulnerabilities is taken as input, and each vulnerability ACM triple is traversed. The corresponding code fix is ​​implemented in tcR. For TOA vulnerabilities, the Identifier node on AST is modified to msg.sender. For MAC vulnerabilities, a valid require permission assertion mechanism is inserted into the sensitive function. For IOT vulnerabilities, the operation target is modified to the expected variable. Once the repair operation is complete, the repaired triplet is added to the output set TMR, and the original code segment in TMR is replaced with the repaired code. When the TM traversal is complete, the output results are TMR and tcR.

4. The method for analyzing variation test results according to claim 1, characterized in that, In step 3), with TMR and tcR as input, initialize M1, M2, M3 = 0; M1 represents the number of real vulnerabilities successfully identified by the tool, M2 represents the number of vulnerabilities autonomously mutated by the mutation tool, and M3 represents the number of real ACV vulnerabilities that the mutation tool did not mutate; by comparing whether the repair statements in tcR and TMR are broken, obtain the respective numbers of M1, M2, and M3, calculate the Jaccard similarity coefficient JSC = M1 / ​​(M1 + M2 + M3) between the vulnerabilities mutated by the mutation tool and the vulnerabilities in the original contract; finally, output the Jaccard similarity coefficient JSC.

Images