Unprotected Function

As you write your smart contracts, you should always ask yourself what roles should be allowed to invoke the function. If only certain addresses or addresses with specific roles can perform a function, then make sure to use appropriate require statements or modifiers to prevent unauthorized access.

In addition to what addresses can perform certain functions, you should consider what context can invoke the function and then use the appropriate visibility modifier. For a refresher, refer to Chapter 4 where we discussed visibility modifiers during the creation of our Greeter contract.

As an example of how to protect your functions, let’s examine the Ownable contract from OpenZeppelin. The following snippet is for the transferOwnership function:

function transferOwnership(address newOwner) public onlyOwner {
    _transferOwnership(newOwner);
}

Notice the function visibility of public and the onlyOwner modifier. This means it can be called from anywhere, but this is restricted to the owner of the contract. The function then delegates to _transferOwnership, which is shown in our next snippet:

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

The function visibility has been marked internal, which means it can be called from within the contract or one of its derivatives. This is a great practice for locking down who can call a function.

Now that we can protect our functions, let’s talk about transaction ordering.

Transaction Ordering Dependence

Transaction ordering is a race condition attack where the attacker raises the gas price of a transaction in an attempt to have their transaction executed first. The more you pay in gas, the higher priority your transaction receives from miners. This means someone observing the mempool of pending transactions could jump the line if they see a transaction come in that would be detrimental to their interests.

This attack is very difficult to defend against and commonly targets applications in which timing is important, such as auctions or marketplaces. To mitigate this attack, try batching transactions or separating the details into a separate request.

Integer Overflow and Underflow

Integer overflow and underflow is an issue where a result is produced that is larger than the maximum or smaller than the minimum value of an integer. For instance, if we have a variable with the uint8 data type, its maximum value is 255. If you were to add 1 to 255, an overflow would occur and the result would be 0. Now that we have 0, if we were to subtract 1 from it, we would underflow and return 255. Instead of allowing overflows and underflows, we recommend using SafeMath when performing arithmetic operations.

For an example of how to use SafeMath, refer back to Chapter 6, Example 6-15, where we were adding the donate functionality to our Fundraiser contract.

The next vulnerability we will look into is reentrancy.

Reentrancy

A reentrancy attack occurs when an important state variable is changed after a contract calls a function of another contract or invokes the fallback function of another contract. In these cases, the malicious contract is able to call back into the original contract, invoking the same function again before the state has been updated.

To avoid this attack update the state of your contract before calling a function on any contract you do not own or before sending or transferring to any address that may be added by your users. It is also best to avoid using lower-level functions on addresses like call when dealing with unknown or untrusted addresses.

Here’s an example of a reentrancy. The attacker finds the vulnerability in the contract where two functions rely on the same state. And the hacker is able to call the function again before the balance is set to 0. This was the attack used by hackers in the DAO attack in 2016. The attacker recursively called certain functions to hack the contract, thus exploiting a reentrancy vulnerability in the contract.

Let’s take a look at cross-function race conditions, which is another type of reentrancy.

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)());
}

Block Gas Limit

The Ethereum network, specifically the EVM, can only process a certain computational load at a time. This restriction is conceptualized in the form of the block gas limit, as discussed in Chapter 1. If you surpass the limit, the transaction fails. This can happen when a function processes a significant number of state changes like when iterating over a large array.

To avoid exceeding the gas limit, break large—or potentially large—operations into batches. The pagination function we implemented in Chapter 7, Example 7-12, could be a great example for how to break things up into smaller chunks.

Timestamp Dependence

Because the blockchain is decentralized, it relies on the computational power of distributed nodes (miners) instead of centralized servers to process transactions. The timestamp of the miner can therefore be manipulated by their owners in an attempt to circumvent any logic based on timestamps within a contract.

In order to avoid this vulnerability, make sure your contract does not use timestamps for randomization seeds. It is also a good idea to make sure that your conditional logic can tolerate 15 second variance and still provide the desired behavior. If you are wondering why 15 seconds are required, it is because both Parity and Geth would reject a block that is more than 15 seconds into the future.

And Many More

These are just a few of the common attacks against smart contracts. It’s important to stay updated on the latest types of hacks and keep your contracts secure. ConsenSys provides a list of common smart contract attacks that you should review when writing your smart contracts.

If you intend to release your smart contract to the public, it’s important to have a smart contract audit.

External Auditing

One of the best ways to mitigate security vulnerabilities in your smart contract is to hire an external auditor or a smart contract auditing company. An external auditing company will look at your contract with fresh eyes and run it through different auditing programs to find any security issues. The smart contract auditor will provide you with a list of issues found in your contract and ways you can fix them. Securing smart contracts has become such a large issue that entire companies now exist to audit and provide ways to secure smart contracts.

Auditing Companies

Some of the larger smart contract auditing-focused companies provide public audits of past smart contracts. One example of that is Authio where you can see examples of vulnerabilities they found and recommendations of how to fix them. If you’re interested in smart contract security, many auditing companies make these audits public, and you can read through them to get better at spotting out potential security issues in your own smart contracts.

Solidified

Another way to check if your smart contract is secure is to post it on Solidified. Solidified is a platform where you can post your smart contract and a group of Solidity experts, bounty hunters, and developers will work together to scout out vulnerabilities. If you’re interested in becoming an auditor, you can become one at Solidified.io as well. Solidified is great because it first provides a team of Solidity experts to find vulnerabilities in your contract. After they’ve finished their report, they’ll provide suggestions on how to fix the issues in your smart contract. Once you’ve fixed the issues in the contract, your contract is posted on the Solidified Bounty platform where it is public to the entire Solidified community.

There are also a number of free resources available to help you keep your smart contract secure.