Ethereum smart contracts are extremely flexible, capable of both holding large amounts of tokens (often over $1 billion) and executing immutable logic on previously deployed smart code. While this has created a vibrant and creative ecosystem of interconnected and trustless smart contracts, it is also the perfect ecosystem to attract attackers looking to profit by exploiting vulnerabilities in smart contracts and unexpected behaviors in Ethereum. The code of a smart contract audit cannot usually not be modified to fix security flaws, assets stolen from smart contracts are unrecoverable and extremely difficult to trace. The total amount of money stolen or lost due to smart contract issues easily reaches $1 billion. Here are some of the most prominent issues caused by smart contract coding errors:
HOW TO WRITE MORE SECURE SMART CONTRACTS CODE
Before launching any code on the mainnet, it is important to take sufficient precautions to protect anything of value that is entrusted to your smart contract. In this article, we'll discuss a few specific attacks, provide resources to learn more about the types of attacks, and give you some basic tools and best practices to keep your contracts running smoothly and securely.
AUDITS ARE NOT A SILVER BULLET
Years ago, tools for writing, compiling, testing and deploying smart contracts were immature, resulting in many messy projects of writing Solidity code, code that was then handed off to a expert for review to ensure it was working securely and as expected. In 2020, the development processes and tools that support writing Solidity are significantly better. Leveraging best practices not only ensures that your project is more manageable, but it is an essential part of its security. An audit at the end of writing your smart contract security audit is no longer sufficient as a sole security consideration. Safety begins long before it starts with proper design and development processes .
SMART CONTRACT DEVELOPMENT PROCESS
It is necessary at least that:
all code is stored in a version control system like git;
all code changes are made via PR (Pull Requests);
all PRs have at least one reviewer; If you're working on a solo project, consider finding another solo author to negotiate code reviews!
a single command compiles, deploys and runs a suite of tests on your code using an Ethereum development environment (See: Truffle);
you've run your code through basic analysis tools like Mythril and Slither, ideally before each PR is merged, comparing output differences;
Solidity does not issue compile-time warnings;
your code is well documented.
There are many more things to say about development processes, but these are a good place to start. Check out the DeFiSafety-provided process quality checklist for more items and in-depth explanations. DefiSafety is an unofficial public service that publishes reviews of various large public Ethereum DApps. Part of DeFiSafety's rating system includes how well the project adheres to this process quality checklist. By following these processes:
you will produce more secure code, through reproducible and automated tests;
experts will be able to check your project more efficiently;
the integration of new developers will be easier;
developers will be able to iterate, test, and get feedback on changes quickly;
your project will probably register fewer regressions.
ATTACKS AND VULNERABILITIES
Now that you're writing Solidity code using an efficient development process, let's look at some common Solidity vulnerabilities to see what can go wrong.
Reentrancy
Reentrancy is one of the most important security issues to consider when developing smart contracts. Since the EVM cannot execute multiple contracts at the same time, a contract calling another contract pauses the execution of the calling contract and the state of memory until the call returns, at which point the execution resumes normally. This pausing and resuming can create a vulnerability known as "reentrancy".
To allow a user to withdraw the ETH they previously stored in the contract, this function:
reads the user's balance;
sends him the balance in ETH;
resets the balance to 0, so the user cannot withdraw the balance again.
If called from a normal account (like your own MetaMask account), it works as expected: msg.sender.call.value() just sends ETH to your account. However, smart contracts can also make calls. If a custom, malicious contract calls the function withdraw(), msg.sender.call.value() will not send the amount of ETH (via amount)
