Solidity Smart Contract Vulnerabilities and Ways To Mitigate Them

---

This blog entails the vulnerabilities in Solidity smart contract codes and different ways to mitigate them.

Solidity Smart Contract Vulnerabilities and Their Solutions

In traditional software development, there are various security issues that we can fix by patching. When you find a bug in a traditional system, a fix can be written and deployed to prevent future exploits. Essentially, you can easily and frequently use Patches.

However, patching security vulnerabilities in Ethereum blockchain-based decentralized applications is not so straightforward. It is because of the unalterable nature of smart contracts. Indeed, the upgrade of the already deployed smart contract is complex and sometimes impossible.

Explore | Why Use Solidity for Smart Contracts Development

Let’s analyze a few common security vulnerabilities in Solidity smart contracts and how to address them.

Here is a list of common vulnerabilities in Solidity code written for smart contracts:

a) Unprotected Function

For all your publically accessible smart contract functions, you need to add further modifiers on them like in the example, which require the msg.sender to be the current owner.

Here in this example, the modifier-only owner does the above work. Code Reference (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/math/SafeMath.sol)

function changeOwner(address newOwner) public onlyOwner {
    _changeOwnership(newOwner);
}

modifier onlyOwner() {
    require(msg.sender == _owner);
    _;
}

function _changeOwnership(address newOwner) internal {
    require(newOwner != address(0), "Ownable: new owner is the zero address");
    emit OwnershipTransferred(_owner, newOwner);
    _owner = newOwner;
}

The function _changeOwnership is internal, which means it can be called from within our smart contract or its derivatives.

Also, Visit | Analyzing Solidity and Vyper for Smart Contracts Programming

b) Integer Overflow and Underflow

This error is related to simple Math functions that you use in your contracts with solidity data types, like addition, division, etc.

For example data type uint8, ha a range 0 to 255 ,but adding 1 to 255 will result in overflowing to 0 value and similarly underflow errors if you subtract 1 from 0 value.

Instead one should use the following SafeMath library, which keeps care of these issues, for example

function add(uint256 a, uint256 b) internal pure returns (uint256) {
        uint256 c = a + b;
        require(c >= a, "SafeMath: addition overflow");

        return c;
}

For more info on SafeMath library, follow this link - SafeMath Library

c) Transaction Dependence

This type of attack takes place when a user compares the gas price value sent per unit by all the transactions in the tx pool. Subsequently, he updates the gas price in such a way that his transaction gets the highest priority. It is common in the case of contracts related to auctions.

Also, Read | Ethereum Smart Contracts | An In-depth Review of the Potential

d) Reentrancy

These attacks are related to state changes in your smart contract functions. 

An example of this is a contract where your balance is reset to 0 only after the transfer occurs. So a hacker could keep calling this even after they’ve received the withdrawal to hack more Ether from the contract. Basically, they can call another function halfway through the first function’s execution to hack your contract.

Here’s an example:

function withdrawFunds() external {
    uint256 withdrawAmount = balances[msg.sender];
    require(msg.sender.call.value(withdrawAmount)());
    balances[msg.sender] = 0;
}

function withdrawFunds() external {
    uint256 withdrawAmount = balances[msg.sender];
    balances[msg.sender] = 0;
    require(msg.sender.call.value(withdrawAmount)());
}

The balance is not set to 0 until after the other function is called. The attacker can call this recursively and successfully hack the smart contract. One way to protect against this attack is to update the balance before executing call.value on the sending address.

e) Gas Limits

Each operation on the EVM results in the consumption of the gas amount you send when initiating the transaction. If your functions consist of too many steps, or an increasing number of steps with the data you hold, each transaction made to execute that function will result in out-of-gas errors and make your contract unusable.

Also, Check | Ethereum Smart Contract Development | Discovering the Potential

Conclusion

Minor issues in smart contracts can cost plenty of money. Businesses must boost their security to avoid potential smart contract vulnerabilities. You can trust our smart contract developers if you need any assistance regarding your smart contract security. Contact us for more information.