Security Testing Smart Contracts

As we’ve previously discussed, we know that smart contracts are immutable meaning that once they are deployed to the blockchain they cannot be changed. If the smart contract has not been through the appropriate security audit and testing phase it could contain vulnerabilities which remain to be discovered by a malicious threat actor.

Auditing and Testing smart contracts is one of the most critical components and is often the last step to take place in the development phase in the test network. This is the last opportunity to discover vulnerabilities and other issues.

Auditing Smart Contracts

This process check is the smart contract is working according to specifications that were initially fulfilled by the contract. The process of auditing checks the contract logic that could potentially harm or change the working of the contract.

Typically, things that are being looked for are:

• Unexpected outputs
• Contract and Control flow
• Vulnerabilities that could lead to exploitation.

Auditing is also split into phases to help manage the process, with Phase 1 consisting of the following

• To gather the specifications and understand the workflow of the smart contract
• Understand output and the flow of the smart contract
• Understand the functionalities of the smart contract
• Includes collection of code and research

Phase two is all about code review, checking and verifying logic, checking that the code aligns with previous specification gathered. In this phase also checks for bugs and vulnerabilities will happen.  Phase two consists mainly of the following

• Automated review is done with tools such as, Oyente, Chai, Solograph, Manticore, Mythril and Mocha. Identifying errors humans can miss.
• Automation includes writing test cases and creating test environments
• Benefits are less time consuming and increase code coverage.

Types of Vulnerabilities in smart contracts

Some common vulnerabilities which can be and have been found in smart contracts to be aware of are listed below. We will discuss each one of these further in future posts as we delve into the practical implications.

• unsafe type inference;
• timestamp dependence;
• reentrancy;
• implicit visibility level;
• gas limit and loops;
• transaction-ordering dependence;
• unchecked external call – unchecked math;
• DoS with block gas limit;
• DoS with (unexpected) throw;
• byte array vulnerabilities;
• malicious libraries;
• style guide violation;
• ERC20 API violation;
• uninitialised state/storage/local variables;
• compile version not fixed.

If you want to learn more about blockchain/web3 we go into much further detail in our blockchain hacking course HERE