Do you have written a decentralized app (dApp) and you want to check it for potential exploits and hacks? Do you need to prepare your dApp for a security audit and vulnerability analysis?
Don’t worry, we have your back! 🛡️
In this article based on the smart contract security course by Finxter Creator Yogesh, we’ll give you an overview of the eight most common dApp vulnerabilities with references to learning more about them — and video explanations for each.
Overview
Here’s an overview of the eight most common security vulnerabilities of decentralized apps and smart contracts in Solidity and other programming languages:
- Ownership Exploit
- Private Variable Exploit
- Reentrancy Attack
- tx.origin Phishing Attack
- Denial of Service Attack
- Storage Collision Attack
- Randomness Attack
- Replay Attack
Each link opens in a new tab.
Hack #1 – Ownership Exploit
The smart contract ownership exploit appears innocent, however, if you observe closely, you may find that your Solidity function is an external function and can be called by anyone (attacker) apart from the deployer or the owner to update a sensitive variable, for example.
The ownership exploit appears when functions that are public or external can be easily called by the attacker to modify the variables in the contract and the possible solutions.
This is a simple and classic example of an ownership attack where an attacker can call a function to update a value and easily exploit it.
There are two possible solutions to the above-mentioned problem. One uses the custom modifier and the other uses OpenZeppelin’s Owner contract.
🌍 Learn More: Feel free to check out the example code and detailed explanations on our Finxter blog article on the topic.
Hack #2 – Private Variable Exploit
As the name suggests, private means not accessible to anyone outside.
- Can we expect the same in Solidity smart contracts?
- Is any variable declared as ” private” in Solidity is not accessible from the outside world?
If the answer is yes, then the assumption may be wrong. It is possible to access the private variables of smart contracts from the outside world.
To understand the private exploit, you first need to understand the storage structure and its arrangement in Solidity.
The article below details the storage structure, followed by the exploit and its resolution:
🌍 Learn More: Feel free to check out the example code and detailed explanations on our Finxter blog article on the topic.
Hack #3 – Reentrancy Attack
One famous reentrancy attack that occurred in 2016 was the DAO attack leading to losses of $60 million.
In the reentrancy attack, the hacker would typically use a contract to attack the victim.
The reentrancy attack can cause serious damage during the withdrawal of funds. Unknowingly the attacker can withdraw all the funds.
In the referenced tutorial, we’ll look at three possible solutions including the transfer/send methods, changing the sequence in the code, and finally the OpenZeppelin’s ReentrancyGuard.
🌍 Learn More: Feel free to check out the example code and detailed explanations on our Finxter blog article on the topic.
Hack #4 – tx.origin Phishing Attack
In the regular phishing of a website, phishing begins with a phony email or another kind of communication intended to entice a victim.
In this case, the communication done appears as if it came from a reputable sender.
Similarly, the case of smart contracts which use tx.origin for authorizing users is vulnerable to phishing attacks, where a malicious contract can trick the contract’s owner into executing a function that only the owner should be able to call.
🌍 Learn More: Feel free to check out the example code and detailed explanations on our Finxter blog article on the topic.
Hack #5 – Denial of Service Attack
The Denial of Service (hence referred to as DoS) restricts legitimate users from using the smart contracts permanently or for a certain period unusable.
In the blockchain, DoS attacks are of three types, namely:
- Unexpected Revert,
- Block Gas Limit, and
- Block Stuffing.
For this tutorial, the Unexpected Revert will be in detail with an example, and for the other two, a summary highlighting how such types of attacks can be made possible.
More details here:
🌍 Learn More: Feel free to check out the example code and detailed explanations on our Finxter blog article on the topic.
Hack #6 – Storage Collision Attack
Before you can grasp this exploit, you must first understand how Solidity saves state variables as explained here.
In this tutorial, we will see how delegatecall can lead to disastrous results with an incorrect understanding or usage.
While using delegatecall, it is vital to keep it in our minds that delegatecall keeps context intact (storage, caller, etc…).
Even though there are certain problems associated with delegatecall, it is very often used in many contracts such as OpenZeppelin, Solidity libraries, EIP2535 diamonds, and many more.
To conclude, use delegatecall, but with care!
🌍 Learn More: Feel free to check out the example code and detailed explanations on our Finxter blog article on the topic.
Hack #7 – Randomness Attack
The problem in Solidity contracts is finding the true source of randomness.
We will see how generating a random number using on chain data cannot be trusted.
The tutorial starts with exploiting the randomness vulnerability, followed by the possible solutions.
To explain this exploit, you can consider any game where the user is asked to guess a random number such as a dice number, a card from a pack of cards, or an online lottery contract.
Let us begin the exploration!
🌍 Learn More: Feel free to check out the example code and detailed explanations on our Finxter blog article on the topic.
Hack #8 – Replay Attack
This post provides insights into the replay attack in blockchains.
As per the wiki, a replay attack is a valid data transmission that is maliciously or fraudulently repeated or delayed.
In the case of blockchains, a replay attack means taking a transaction on a blockchain and maliciously or fraudulently repeating it on the same or another blockchain.
The post starts with different scenarios where a replay attack can happen, followed by an example contract of a replay attack, and then finally the solution.
Let’s go!
🌍 Learn More: Feel free to check out the example code and detailed explanations on our Finxter blog article on the topic.
Conclusion
This overview article has shown you the most common smart contract hacks used to exploit your smart contract in Solidity. Ignore them at your own perish!🛡️
If you want to become a Blockchain developer, feel free to check out our related introductory courses on the Finxter Computer Science Academy:
Learn Solidity Course
Solidity is the programming language of the future.
It gives you the rare and sought-after superpower to program against the “Internet Computer”, i.e., against decentralized Blockchains such as Ethereum, Binance Smart Chain, Ethereum Classic, Tron, and Avalanche – to mention just a few Blockchain infrastructures that support Solidity.
In particular, Solidity allows you to create smart contracts, i.e., pieces of code that automatically execute on specific conditions in a completely decentralized environment. For example, smart contracts empower you to create your own decentralized autonomous organizations (DAOs) that run on Blockchains without being subject to centralized control.
NFTs, DeFi, DAOs, and Blockchain-based games are all based on smart contracts.
This course is a simple, low-friction introduction to creating your first smart contract using the Remix IDE on the Ethereum testnet – without fluff, significant upfront costs to purchase ETH, or unnecessary complexity.
