Common Security Vulnerabilities in DeFi and Prevention Measures

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

Common types of DeFi vulnerabilities include flash loans, price manipulation, function permission issues, arbitrary external calls, fallback function problems, business logic vulnerabilities, private key leaks, reentrancy, and more. Below, we 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 be exploited by hackers to borrow money for arbitrage at no cost. Many DeFi projects appear to offer high returns, but the quality of the teams behind them varies greatly. Even if the code itself is free of vulnerabilities, there may still be logical issues. For example, some projects distribute rewards based on the amount of tokens held by users at a fixed time, but attackers can use flash loans to purchase a large number of tokens and capture most of the rewards when they are distributed. There are also projects that calculate prices using tokens, which can be influenced by flash loans. Project teams should be vigilant about these issues.

Price Manipulation

Price manipulation issues are closely related to flash loans, mainly because certain parameters can be controlled by users during price calculation. There are two common types of problems:

1. When calculating prices, third-party data is used, but incorrect usage or lack of verification leads to malicious manipulation of prices.

2. Use the number of Tokens from certain addresses as calculation variables, while the Token balances of these addresses can be temporarily increased or decreased.

Reentrancy Attack

One of the main dangers of calling external contracts is that they can take over the control flow and make unexpected changes to the data by calling functions. There are many ways that reentrancy can occur with different contracts, which can combine functions from different contracts or multiple functions of a single contract to carry out an attack. To solve the reentrancy problem, it is important to pay attention to:

1. Not only prevent the reentrancy issue of a single function.

2. Follow the Checks-Effects-Interactions coding pattern

3. Use a time-tested anti-reentrancy modifier

The biggest fear is reinventing the wheel. There are many best security practices within this circle that can be used directly, and there is absolutely no need to reinvent the wheel. Creating your own solutions that have not been thoroughly validated has a significantly higher probability of encountering problems than using mature and well-tested solutions.

Project Party Security Recommendations

1. Contract development follows best security practices.

2. Contracts can be upgraded and paused

3. Use time locks

4. Increase investment in security and establish a comprehensive security system.

5. Raise the security awareness of all employees

6. Prevent internal malfeasance while enhancing risk control and improving efficiency.

7. Carefully introduce third parties, verify upstream and downstream.

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

1. Is the contract open source?

2. Does the Owner use multi-signature, and is the multi-signature decentralized?

3. Existing trading situation of the contract

4. Is the contract a proxy contract, is it upgradeable, and does it have a time lock?

5. Has the contract been audited by multiple institutions, and does the Owner have excessive permissions?

6. Pay attention to the selection and use of oracles

In conclusion, users should be especially cautious when participating in DeFi projects, evaluating the project's security from multiple aspects and not being blinded by high returns. Project teams need to build security defenses from multiple levels and continuously monitor and improve the project's safety.