Common Security Vulnerabilities in Decentralized Finance and Preventive Measures

Recently, a security expert shared a DeFi security course for community members. The expert reviewed significant security incidents that the Web3 industry has encountered over the past year and discussed in depth the reasons behind these incidents and how to avoid them. He summarized common security vulnerabilities in smart contracts and preventive measures, and also provided some security advice for project teams and ordinary users.

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

Flash Loan

Flash loans are an innovation in Decentralized Finance, but they are also often 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 the contract's functionality could lead to anomalies due to large amounts of funds, or be exploited to interact with multiple functions in a single transaction to gain improper rewards.

Many DeFi projects seem to offer high returns, but in reality, the quality of the project teams varies greatly. Some projects may have bought their 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 by holders at fixed times, but attackers can exploit this by using flash loans to purchase a large number of tokens, resulting in most of the rewards flowing to the attackers.

Price Manipulation

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

1. When calculating prices, third-party data is used, but the method of use is incorrect or checks are missing, leading to price manipulation.
2. Use the number of tokens at certain addresses as calculation variables, while the token balances 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 over the control flow and make unexpected changes to the data. A typical example of a reentrancy attack is found in withdrawal functions, where the user's balance is set to 0 only at the end of the function, allowing multiple calls to succeed in withdrawing.

For different contracts, the methods of reentrancy attacks are varied and may involve multiple different functions or multiple contracts. When addressing reentrancy issues, the following points should 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

It is worth noting that reinventing the wheel is often dangerous. There are already many best security practices in the Web3 space, and directly adopting these mature solutions is safer than developing them on your own.

Security Recommendations

Project Party Security Suggestions

1. Follow best security practices for contract development
2. Implement contract upgradeability and pause functionality
3. Use of time-lock mechanism
4. Increase investment in security and establish a complete security system.
5. Raise the security awareness of all employees
6. Prevent internal malfeasance while enhancing risk control and improving efficiency.
7. Exercise caution when introducing third-party components and adhere to the principle that "default upstream and downstream are not safe".

How can users/LP determine if a smart contract is secure?

1. Confirm whether the contract is open source
2. Check whether the Owner adopts a decentralized multi-signature mechanism.
3. Check the existing trading situation of the contract
4. Understand whether the contract is a proxy contract, whether it is upgradeable, and whether there is a time lock.
5. Confirm whether the contract has been audited by multiple institutions and assess whether the Owner's permissions are too extensive.
6. Pay attention to the type and reliability of the oracle used by the project.

In a Web3 environment, security awareness is crucial. Users should think more and stay vigilant to avoid potential security risks. Especially during adverse market conditions, one must be wary of various possible scams.