Common Security Vulnerabilities and Preventive Measures in Decentralized Finance

Recently, a security expert shared a DeFi security course for community members. The course reviewed significant security incidents that the Web3 industry has encountered over the past year, explored the causes and avoidance methods of these incidents, summarized common security vulnerabilities in smart contracts and preventive measures, and provided some security advice for project parties and ordinary users.

Common types of DeFi vulnerabilities include flash loans, price manipulation, function permission issues, arbitrary external calls, fallback function issues, business logic vulnerabilities, private key leaks, and reentrancy attacks. This article will focus on three types: flash loans, price manipulation, and reentrancy attacks.

Flash Loan

Flash loans are an innovation in Decentralized Finance, but they can also be exploited by hackers. Attackers typically borrow large amounts of funds through flash loans to manipulate prices or attack business logic. Developers need to consider whether contract functions could behave abnormally due to large amounts of funds, or whether it is possible to interact with multiple functions in a single transaction to obtain improper rewards through large amounts of funds.

Many DeFi projects seem to offer high returns, but the quality of the project teams varies greatly. Some projects may use purchased code, and even if the code itself has no vulnerabilities, there may still be logical issues. For example, some projects distribute rewards based on the number of tokens held at a fixed time, which could be exploited by attackers using flash loans to purchase a large number of tokens and receive most of the rewards when the rewards are distributed.

Price Manipulation

The issue of price manipulation is closely related to flash loans, primarily because certain parameters can be controlled by users during price calculation. There are two common types of problems:

1. Third-party data is used to calculate prices, but incorrect usage or lack of checks leads to price manipulation.
2. Use the number of tokens at certain addresses as calculation variables, while the token balance at these addresses can be temporarily increased or decreased.

Reentrancy Attack

One of the main risks of calling external contracts is that they may take control flow and make unexpected changes to the data. For example, in the withdrawal function, if the user's balance is set to 0 only at the end of the function, then a second (and subsequent) call will still succeed, leading to a repeated withdrawal.

To solve the reentrancy issue, the following points need to be noted:

1. Not only should we prevent the reentrancy issue of a single function.
2. Follow the Checks-Effects-Interactions pattern for coding.
3. Use a time-tested reentrancy guard modifier.

It is worth noting that reinventing the wheel may bring more risks. Using well-validated best security practices is often safer than developing new methods on your own.

Security Recommendations for Project Teams

1. Follow best security practices for contract development.
2. Implement contract upgradability and pausing functions.
3. Adopt a time-lock mechanism.
4. Increase investment in security and establish a comprehensive security system.
5. Improve the security awareness of all employees.
6. Prevent internal malfeasance while enhancing risk control and improving efficiency.
7. Exercise caution when introducing third parties; assume that both upstream and downstream are not secure.

How Users/LPs Can Determine If a Smart Contract Is Secure

1. Confirm whether the contract is open source.
2. Check whether the Owner uses multi-signature and whether the multi-signature is decentralized.
3. View the existing trading situation of the contract.
4. Confirm whether the contract is a proxy contract, whether it is upgradable, and whether there is a time lock.
5. Check whether the contract has been audited by multiple institutions and whether the Owner permissions are overly extensive.
6. Pay attention to the usage of oracles.

By focusing on these aspects, users can better assess the security of smart contracts and reduce the likelihood of participating in risky projects.