Good contract growth: Widespread errors to keep away from

Constructing sensible contracts for the blockchain may be very totally different from constructing purposes for Web2. First, sensible contracts are immutable after they’re deployed on the blockchain, whereas Web2 purposes are scalable and loosely coupled. Second, sensible contract code has precise financial worth, making safety throughout growth much more important.

Sadly, the Web3 area has suffered quite a few assaults and great losses on account of exploited bugs and vulnerabilities, in addition to improperly written code.

Vulnerabilities or bugs that exist in a sensible contract will spell hassle for anybody who interacts with it after it’s deployed on the mainnet.

On this article, I’ll share important info for bettering the safety of your sensible contract growth. I’ll present detailed directions that will help you determine and forestall frequent sensible contract vulnerabilities and assault vectors.

Bounce forward:

Reentrancy assaults

The reentrancy assault is without doubt one of the earliest sensible contract vulnerabilities; it was first detected on the Ethereum blockchain in 2016.

A wise contract should have a fallback operate in an effort to obtain Ether. The fallback operate is named by the sensible contract that’s sending the Ether. If the code of the sending sensible contract just isn’t written correctly, the receiving sensible contract may have a chance to use the sender.

Right here’s an instance of an insecure sending sensible contract:

// INSECURE
mapping (deal with => uint) non-public userBalances;

operate withdrawBalance() public {
    uint amountToWithdraw = userBalances[msg.sender];
    (bool success, ) = msg.sender.name.worth(amountToWithdraw)(""); 
        // At this level, the caller's code is executed, and may name withdrawBalance once more
    require(success);
    userBalances[msg.sender] = 0;
}

The code above employs a mapping knowledge construction to maintain observe of userBalances which have Ether on this contract. The code resets the worth of the userBalances again to zero after they name the withdrawBalance operate.

This operate is susceptible to reentrancy assaults as a result of it sends Ether to the person earlier than updating the person’s stability within the userBalances mapping. That is unsafe as a result of it provides the receiver a chance to name the withdrawBalance operate once more in its fallback operate earlier than the person’s stability is up to date. In different phrases, the receiver may withdraw greater than they’ve within the contract.

Right here’s a greater solution to write the sensible contract:

mapping (deal with => uint) non-public userBalances;

operate withdrawBalance() public {
    uint amountToWithdraw = userBalances[msg.sender];
    userBalances[msg.sender] = 0;
    // The person's stability is already 0, so future invocations will not withdraw something
    (bool success, ) = msg.sender.name.worth(amountToWithdraw)("");
    require(success);
}

Now let’s have a look at a extra sensible instance of an insecure sensible contract that might fall prey to a reentrancy assault. The code is for an insecure Solidity contract known as EtherStore:

// SPDX-License-Identifier: MIT
pragma solidity >=0.4.22 <0.9.0;

contract EtherStore {
        // Mapping Knowledge construction to maintain observe of balances of customers 
    mapping(deal with => uint256) public balances;

        // Because the title suggests, you need to use this operate to deposit Ether to the contract
    operate deposit() public payable {
        balances[msg.sender] += msg.worth;
    }

        // For withdrawing the Ether saved by customers
    operate withdraw() public {

                // Will get the stability of the person calling the withdraw operate
        uint256 bal = balances[msg.sender];

                // Checks if the person/caller has Ether on this contract
        require(bal > 0);

                // Transfers the Ether to the person 
                // Vulnerability level
        (bool despatched, ) = msg.sender.name{worth: bal}("");
        require(despatched, "Did not ship Ether");

        balances[msg.sender] = 0;
    }

    // Helper operate to test the stability of this contract
    operate getBalance() public view returns (uint256) {
        return deal with(this).stability;
    }
}

This contract allows customers to deposit Ether after which withdraw their stability after they please. The contract makes use of a mapping to trace the balances of customers, but it surely makes the error of sending Ether out earlier than updating the person’s stability. This makes the contract susceptible to reentrancy assaults.

A malicious actor may deploy a contract with the deal with of EtherStore, exploit the reentrancy vulnerability, after which withdraw extra Ether than they initially deposited.

Defending in opposition to reentrancy

To mitigate in opposition to the chance of reentrancy assaults by malicious actors, comply with Solidity’s Examine-Impact-Interplay sample while you write the operate that sends out Ether from a contract:

• Examine: affirm if the caller is eligible to name the operate
• Impact: make state adjustments that the operate will set off earlier than sending out Ether
• Interplay: ship out Ether

Discover that the susceptible EtherStore contract does one thing comparable however within the mistaken order. It checks if the caller is eligible to make use of the operate, however then skips to the interplay part with out implementing the Results.

Right here’s an instance of a safe EtherStore contract that follows the Examine-Impact-Interplay sample:

// SPDX-License-Identifier: MIT
pragma solidity >=0.4.22 <0.9.0;

contract EtherStore {
        // Mapping Knowledge construction to maintain observe of balances of customers 
    mapping(deal with => uint256) public balances;

        // Because the title suggests, you need to use this operate to deposit Ether to the contract
    operate deposit() public payable {
        balances[msg.sender] += msg.worth;
    }

        // For withdrawing the Ether saved by customers
    operate withdraw() public {

                // Will get the stability of the person calling the withdraw operate
        uint256 bal = balances[msg.sender];

                // Examine
        require(bal > 0);
                
                // Impact
                balances[msg.sender] = 0;

                // Interplay 
        (bool despatched, ) = msg.sender.name{worth: bal}("");
        require(despatched, "Did not ship Ether");
    }

    // Helper operate to test the stability of this contract
    operate getBalance() public view returns (uint256) {
        return deal with(this).stability;
    }
} 

Arithmetic overflows and underflows

Arithmetic overflows and underflows are points that stem from Solidity itself. Newer variations of Solidity (0.8.0 and better) can detect one of these error.

The uint knowledge sort in Solidity is used to declare unsigned integers beginning at 0. This knowledge sort is restricted to sure ranges, together with uint8, uint16, uint32, uint64, uint128, and uint256. For instance, uint8 represents all unsigned integers ranging from 0 to 2^8 – 1 (i.e., 0 to 255).

If we need to use a quantity larger than 255, we’d first contemplate adopting a uint8 subtype with a wider vary. Nonetheless, this answer can be suboptimal as it might not work for numbers outdoors the vary of the biggest uint subtype.

uint256 represents all unsigned integers from 0 to 2^256-1. If we wished to symbolize a uint out of its vary we’d haven’t any different uint sort to make use of. This will likely not seem to be an enormous downside. In any case, 2^256-1 is a really giant quantity, so the probabilities of eager to work with one thing out of its vary are fairly low.

Nonetheless, if we study the problem extra rigorously, we’ll discover that the problem is extra important.

Solidity compilers with variations decrease than 0.8.0 don’t give a warning for utilizing unsigned integers which are out of the vary of the uint sort that’s in use. As an alternative, the Solidity compiler does one thing a bit humorous. It converts the out-of-range quantity to zero – with out warning!

Let’s have a look at an instance.

Let’s say we’re utilizing a uint8 sort to retailer the quantity 256, which is clearly larger than 2^8-1(255);

uint8 num = 256;

The Solidity compiler would react by overflowing the unsigned integer.

In different phrases, since uint8 solely represents integers from 0 to 255, an unsigned integer larger than this vary would reset to the distinction between its worth and the higher restrict of the uint sort (i.e., 256-255 or 1 on this instance). The brand new integer (1, on this case) “overflows” to the primary integer of the uint8 vary; the vary is 0 to 255, so the primary integer is 0.

Once more, this solely occurs in Solidity variations decrease than 0.8.0.

Now, let’s check out a contract with an arithmetic overflow/underflow vulnerability to get a sensible understanding of the menace that one of these vulnerability can pose:

// SPDX-License-Identifier: MIT
pragma solidity ^0.7.6;

contract TimeLock {
    mapping(deal with => uint) public balances;
    mapping(deal with => uint) public lockTime;

    operate deposit() exterior payable {
        balances[msg.sender] += msg.worth;
        lockTime[msg.sender] = block.timestamp + 1 weeks;
    }

    operate increaseLockTime(uint _secondsToIncrease) public {
        lockTime[msg.sender] += _secondsToIncrease;
    }

    operate withdraw() public {
        require(balances[msg.sender] > 0, "Inadequate funds");
        require(block.timestamp > lockTime[msg.sender], "Lock time not expired");

        uint quantity = balances[msg.sender];
        balances[msg.sender] = 0;

        (bool despatched, ) = msg.sender.name{worth: quantity}("");
        require(despatched, "Did not ship Ether");
    }
}

The above code is for a TimeLock sensible contract. This contract is supposed to lock the person’s Ether for a length of 1 week; it additionally has the performance to extend the length. This can be a fairly good utility for a sensible contract. Sadly, this contract is susceptible to overflow/underflow assaults as a result of the withdraw operate logic depends on a uint.

A malicious actor may write code to deposit Ether to the contract after which withdraw a bigger quantity earlier than the lock interval is over by “overflowing” (basically, resetting) the lock time operate to zero.

Defending in opposition to arithmetic overflows and underflows

In Solidity variations larger than 0.8.0, the compiler will detect and modify for an arithmetic overflow/underflow vulnerability.

When you’re utilizing a Solidity model decrease than 0.8.0, you possibly can defend in opposition to this vulnerability with the SafeMath library.

Right here’s a safe model of our TimeLock contract utilizing SafeMath:

// SPDX-License-Identifier: MIT
pragma solidity ^0.7.6;

library SafeMath {

  operate mul(uint256 a, uint256 b) inner pure returns (uint256) {
    if (a == 0) {
      return 0;
    }
    uint256 c = a * b;
    assert(c / a == b);
    return c;
  }

  operate div(uint256 a, uint256 b) inner pure returns (uint256) {
    // assert(b > 0); // Solidity routinely throws when dividing by 0
    uint256 c = a / b;
    // assert(a == b * c + a % b); // There isn't any case during which this does not maintain
    return c;
  }

  operate sub(uint256 a, uint256 b) inner pure returns (uint256) {
    assert(b <= a);
    return a - b;
  }

  operate add(uint256 a, uint256 b) inner pure returns (uint256) {
    uint256 c = a + b;
    assert(c >= a);
    return c;
  }
}

contract TimeLock {
    utilizing SafeMath for uint; // use the library for uint sort
    mapping(deal with => uint256) public balances;
    mapping(deal with => uint256) public lockTime;

    operate deposit() public payable {
        balances[msg.sender] = balances[msg.sender].add(msg.worth);
        lockTime[msg.sender] = now.add(1 weeks);
    }

    operate increaseLockTime(uint256 _secondsToIncrease) public {
        lockTime[msg.sender] = lockTime[msg.sender].add(_secondsToIncrease);
    }

    operate withdraw() public {
        require(balances[msg.sender] > 0);
        require(now > lockTime[msg.sender]);
        uint transferValue = balances[msg.sender];
        balances[msg.sender] = 0;
        msg.sender.switch(transferValue);
    }
}

Cross-function race situations

Race situations are a fairly basic downside in programming they usually floor in sensible contract growth in varied shapes and kinds. the reentrancy vulnerability we talked about beforehand is, in actual fact, a kind of race situation in Solidity.

Cross-function race situations happen in conditions during which two or extra Solidity capabilities try to entry the identical state variable for his or her particular person computation earlier than both has the possibility to make the replace.

Let’s take a look at a Solidity sensible contract the place this vulnerability is noticed:

mapping(deal with => uint256) public userBalances;

/* makes use of userBalance to switch funds */
operate switch(deal with to, uint256 quantity) public {
    if (userBalances[msg.sender] >= quantity) {
        userBalances[to] += quantity;
        userBalances[msg.sender] -= quantity;
    }
}

/* makes use of userBalances to withdraw funds */
operate withdrawalBalance() public {
    uint256 amountToWithdraw = userBalances[msg.sender];
        // makes exterior name to the deal with receiving the ether
    (bool despatched, ) = msg.sender.name{worth: amountToWithdraw}("");
    require(despatched, "Did not ship Ether");
    userBalances[msg.sender] = 0;
}

Within the contract above now we have two capabilities: switch and withdrawalBalance. There’s a cross-function bug that could possibly be triggered with this contract.

A foul actor may write a contract to name withdrawal and switch capabilities almost concurrently. If profitable, the attacker would be capable to switch Ether to a different deal with and in addition withdraw it on the similar time.

To know this vulnerability higher, let’s contemplate an off-chain instance. Think about you could have $100 in your checking account and need to make each a switch and a withdrawal. An instance of a race situation happens while you switch $50 and withdraw $50 concurrently earlier than your account stability is up to date. On this occasion, you find yourself (at the very least briefly) having $50 in your account although you spent $100. That is known as double spending, and it’s an instance of the varieties of points the blockchain was supposed to unravel.

Defending in opposition to cross-function race situations

As I discussed earlier, there are some similarities between a cross-function bug and a reentrancy assault. Each of those vulnerabilities are varieties of race situations, and each come up from the improper use of exterior calls.

One other similarity will be discovered of their options. When coping with race situations usually in programming, it’s advisable to put a lock on the actual variable that’s getting used for computation till the method is accomplished. Happily, Solidity has the Examine-Impact-Interplay sample which we mentioned beforehand.

As an example how the Examine-Impact-Interplay sample works, let’s say a operate is meant to withdraw a specific quantity of Ether and the contract in query has a variable to trace person balances.

First, we test that the caller is eligible to name this operate. Then, within the impact part, we make adjustments to the variable earlier than making the exterior name. Lastly, within the interplay part, we make the exterior name that sends out Ether.

When applied appropriately, this sample is sufficient to cease a cross-function race situation in a sensible contract.

Right here’s a safe model of the cross-function race situations contract we examined earlier:

mapping(deal with => uint256) public userBalances;

/* makes use of userBalance to switch funds */
operate switch(deal with to, uint256 quantity) public {
    if (userBalances[msg.sender] >= quantity) {
        userBalances[to] += quantity;
        userBalances[msg.sender] -= quantity;
        return true;
    }
}

/* makes use of userBalances to withdraw funds */
operate withdrawalBalance() public {
    // Not likely a test however shut sufficient
    uint256 amountToWithdraw = userBalances[msg.sender];

    // Impact 
    userBalances[msg.sender] = 0;

    // Interplay
    (bool despatched, ) = msg.sender.name{worth: amountToWithdraw}("");
    require(despatched, "Did not ship Ether");
}

Transaction order dependence

Since Ethereum is a public blockchain, some vulnerabilities that come up are associated to race situations during which malicious actors use the knowledge offered by customers to run transactions that profit themselves on the expense of others.

Every transaction made on Ethereum is distributed to the Mempool earlier than it’s mined. Miners choose the transactions that they need to add to a block and mine to the blockchain. Miners are incentivized to select transactions with the next gasoline worth since these transactions translate to larger rewards. Beneath this situation, it’s doable for a transaction that got here into the Mempool final to be mined first if the gasoline worth of the final transaction is larger than that of the primary transaction.

This loophole provides dangerous actors entry to delicate info from sure transactions and the chance to make use of that info to their profit earlier than the preliminary transaction is mined.

To make clear this additional, let’s have a look at an instance.

Think about a contract that was deployed with a certain quantity of Ether, and the primary particular person to go a specific string to a operate of that contract will get the Ether that’s saved within the contract. Consumer A discovers the string wanted to entry the Ether within the contract, so that they name the operate and go the string. The transaction of Consumer A calling the operate should go to the Mempool first, so the enter they go to the operate shall be seen to everybody who has entry to view the Mempool.

Now, think about {that a} malicious actor (Consumer B) can view the string that Consumer A used of their transaction. Consumer B runs the identical operate with that string however with the next gasoline worth, inflicting miners to select Consumer B’s string first. Consumer B seems to be like the primary particular person to find the string, they usually get the Ether from the contract.

Transaction order dependence assaults are extra generally known as front-running. Entrance-running can take many kinds. In one other situation, a contract could possibly be arrange in order that whoever solves the operate receives all of the Ether within the contract, however with the stipulation that to run that operate the person has to go a Require which checks if the string they handed into the operate as an enter matches the pre-image of the actual hash.

Ordinarily, this may be an excellent safeguard in opposition to an assault, as a result of it’s tough to calculate the pre-image of a hash. Nonetheless, a nasty actor may monitor the Mempool for any person with the right answer, copy the person’s enter, after which run the operate with the next gasoline worth in an effort to get the Ether from the contract.

One other instance of front-running is the place Consumer A approves Consumer B to spend a sure variety of their tokens with the Approve and TransferFrom capabilities, however then later reduces the quantity. Now, let’s say Consumer B was monitoring the Mempool and noticed Consumer A’s transaction to rescue their allotted variety of tokens. Consumer B may ship their very own transaction (with the next gasoline worth) to the Mempool, spending the unique variety of allotted tokens. Since Consumer B’s transaction was mined earlier than Consumer A may scale back their tokens, Consumer B will get the unique allocation. Plus, in addition they obtain the decreased variety of tokens when Consumer A’s transaction is lastly mined!

Defending in opposition to transaction order dependence

Entrance-running, or transaction order dependence, assaults are tough, however not unattainable, to cease.

One technique to stop front-running is to create an higher sure on gasoline worth within the sensible contract in order that customers can’t alter the gasoline worth. Nonetheless, this technique solely stops regular customers since miners can nonetheless bypass the higher sure. In lots of cases, there could also be no trigger for alarm, since it’s tough for miners to focus on a single block.

A second technique is for a person to make use of a commit/reveal scheme. The primary transaction a person sends can be encrypted in a specific means (the commit part. Then, when the transaction will get mined, the person sends one other transaction decrypting the knowledge that was despatched within the first (the reveal part). With this technique, neither regular customers nor miners can pull a front-running assault.

Timestamp dependence

It could be tempting to make use of the block.timestamp operate to get the present time after which use this knowledge to carry out some enterprise logic in your sensible contract. Nonetheless, this isn’t advisable attributable to Ethereum’s decentralized nature.

The time offered by the block.timestamp operate is inaccurate and will be manipulated by malicious miners.

Defending in opposition to timestamp dependence

Listed here are some necessary factors to recollect about timestamp dependence:

• Don’t depend on block.timestamp or blockhash as a supply of randomness, except you recognize what you might be doing; each of those capabilities will be influenced by miners to a point
• The present block timestamp have to be strictly bigger than the timestamp of the final block, however the one assure is that it is going to be someplace between the timestamps of two consecutive blocks within the canonical chain
• When you should use time in your sensible contract’s enterprise logic, contemplate using using oracles, reminiscent of Chainlink, which combination timestamp knowledge off-chain

Conclusion

On this article, we reviewed a number of frequent sensible contract vulnerabilities in addition to some sensible contract growth errors to keep away from: reentrancy, arithmetic overflows and underflows, cross-function race situations, transaction order dependence, and timestamp dependence.

All the sensible contract examples reviewed on this article have been written in Solidity.

When you discover this text useful, please share it with different sensible contract builders. In fact, we will’t predict new vulnerabilities which will come up sooner or later. However, within the meantime, we will mitigate in opposition to threats by studying from latest losses within the Web3 area.