An Analysis of Ontology Smart Contract Security and Loopholes —Part 3
Foreword: The security of smart contracts is one of the hottest topics in blockchain technology. All the existing smart contract systems have shown some types of loopholes, whether they are backed by the Ethereum Virtual Machine (EVM) or the EOS WASM Virtual Machine. These loopholes have caused huge losses for projects and users, and have called into question the security of blockchain technology.
Chapter 1: Introduction
In the previous two articles, we introduced two types of security threats that may occur when developing smart contracts on Ontology: cross-contract call attack and force transaction failure attack. And we have given the solutions respectively. To help smart contract developers avoid these security loopholes, we will keep collecting cases from the community. Developers in our community can also discuss with us if they encounter other security threats when developing smart contracts on Ontology, together we will build a more secure smart contract system.
In this article, we will introduce another type of security threat: storage injection attack. Before diving into this security threat, we will first introduce the persistent storage interface of the Ontology smart contract:
def Put(context, key, value)
The interface mainly includes the following three parameters:
1. Context — The context in which the current smart contract is running and normally is the hash of the current smart contract;
2. Key — The key of the data that needs to be stored;
3. Value — The value of the data that needs to be stored.
Normally, developers will not encounter any issue when using this interface to store persistent data, but they may face the risk of being attacked in some complex applications.
Chapter 2: Storage Injection Attack
When developers write smart contracts, they normally need to use persistent storage to store the data. Developers need to call the persistent storage method provided by the smart contract back-end to store the data. To better illustrate this point, here is an example.
Before issuing an OEP-4 token, we need to realize all OEP-4 interfaces. To make it simpler, we will only list two methods here: transfer() and totalSupply().
At first glance, these two methods are perfectly fine. transfer() can realize transfer from from_acct address to to_acct address, and totalSupply() can obtain the total asset supply. But a closer look at transfer() shows the method does not check to_acct address in any way.
If the to_acct address the malicious user provides is a string, for example, “TotalSupply”, then they will obtain an incorrect total asset supply. Since we have just listed two methods, the damage this will cause seems limited. However, if the smart contract utilizes other persistent storage, then all the persistent storage may be affected.
Chapter 3: Prevention of Storage Injection Attack
How do smart contract developers prevent such attacks? As can be seen, the main problem is the key of persistent storage, we can divide the key of Put into two types:
Static key — The key defined in the contract;
Active key — The key that needs to be imported from outside.
The static key does not change as it is defined in the contract, while the active key is unpredictable as it is imported from outside. In special cases, if the active key equals a certain static key, then the storage injection attack will occur. To prevent such attacks, developers can add the prefix field for the key.
As can be seen, if the imported to_acct address adds the prefix field in persistent storage, then it will not be confused with other persistent storage. A better solution is to add the prefix field to all persistent storages. In this case, as there are only two persistent storages, we only need to make sure they will affect each other.
Chapter 4: Afterword
This article introduced the third type of potential attack Ontology smart contract developers may encounter and gave the solution. Ontology smart contract developers can also use VaaS-ONT, an automatic smart contract formal verification platform integrated into SmartX, the Ontology smart contract IDE, to locate risky code and find out the cause in one click, which can verify common security loopholes, security properties, and function correctness of smart contracts or blockchain applications, thus improving security.
