Smart contracts are specialized programs stored on a blockchain typically used to automate the execution of an agreement so that all parties can be certain of the outcome without the need to trust one another or any intermediaries. A smart contract guarantees that its execution will correspond exactly to the logic that was originally written in it. And after the execution of said predetermined logic, the final state on the network will stay immutable.
But unfortunately, the correct execution of the smart contract code cannot guarantee its complete safety. Let’s take a closer look at some of the common security vulnerabilities in ERC20 token contracts and possible solutions to them-
-
Overflow/Underflow vulnerabilities
Overflow vulnerabilities are based on exploiting an ERC20 token standard vulnerability called integer overflow or underflow. This problem happens when the result of a math operation is outside the range that can be represented by a variable. For example, if you subtract anything from zero, you’ll get a very large value. If you add two large values together, the result will wrap around and will be close to zero.
Solution - Solidity 0.8.0 natively handles overflows. The same can be managed through Safe math(One of the most popular implementation is OpenZepplins’s SafeMath Library) and override default arithmetic operations if using solidity version <0.8.0 . -
Unprotected function vulnerability - The second type of ERC20 token security problem is unprotected functions. This occurs only when an appropriate modifier that restricts access to a function is not present. As a result, some critical core functions can be left exposed for any random user to call freely.
Solution - Explicitly mark visibility in functions and state variables to avoid leaving anything unprotected. Also custom modifiers, likeonlyOwner, can be created to restrict function call through specific addresses. -
Reentrancy - Ethereum smart contracts have the functionality to call and execute code in other smart contracts. These can be used to handle ether, like sending ether to various external addresses, among other things. These operations require the contracts to submit external calls and as such can be hijacked by attackers, who can force the contracts to execute further code (through a fallback function), including calls back into themselves, or "re-enter" the contract execution again.
Solution - Handling all state variables modifications before invoking external function call and using function modifiers to prevent reentrancy