Solidity Smart Contract Vulnerabilities and Ways To Mitigate Them

Solidity Smart Contract Vulnerabilities and Ways To Mitigate Them

Posted By : Amit Kumar | 31-Mar-2020

In traditional software development, there are various security issues that we can fix by patching. When you find a big in a traditional system, a fix can be written, deployed, and prevented from 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. So, 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.

 

b) Integer Overflow and Underflow

 

This error is related to simple Math functions that you use in your contracts with soliidty 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, and updates the gas price in such a way that his transaction gets the highest priority. This can be seen in contracts related to auctions etc.

 

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 consumption of the gas amount you send when initiating the transaction, if your functions consist of too many steps, or increasing number of steps with the data you hold, each transaction made to execute that function will result in out of gas errors and making your contract unusable.

About Author

Amit Kumar

Amit is a Backend Developer and previously created web apps using javascript, HTML, CSS, Jquery . His hobbies are playing football and listening music.

Leave a Comment

Name is required

Comment is required

Leave a Comment

    Request For Proposal

    Cookies are important to the proper functioning of a site. To improve your experience, we use cookies to remember log-in details and provide secure log-in, collect statistics to optimize site functionality, and deliver content tailored to your interests. Click Agree and Proceed to accept cookies and go directly to the site or click on View Cookie Settings to see detailed descriptions of the types of cookies and choose whether to accept certain cookies while on the site.

    We would love to hear from you!

    Oodles | Blockchain Development Company

    Please enter a valid Phone Number

    Please remove URL from text

    Recaptcha is required.