Common Security Vulnerabilities in DeFi and Preventive Measures

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

Common types of DeFi vulnerabilities mainly 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 flash loans, price manipulation, and reentrancy attacks.

Flash Loan

Flash loans are an innovation in Decentralized Finance, but when exploited by hackers, they can borrow large amounts of funds without any cost, execute arbitrage, and return the funds, only needing to pay a small Gas fee to obtain huge profits.

Many DeFi projects seem to offer high returns, but in reality, the levels of the project teams vary significantly. Some projects may have purchased their code, and even if the code itself has no vulnerabilities, there may still be logical issues. For example, a certain project distributes rewards based on the number of tokens held by the holders at a fixed time, but attackers can exploit flash loans to buy a large number of tokens, thereby obtaining most of the rewards when the distribution occurs.

In addition, there are some projects that calculate prices through tokens and can influence prices through flash loans. As project owners, you should be vigilant about these issues.

Price Manipulation

The issue of price manipulation is closely related to flash loans, primarily consisting of two common types:

1. Use third-party data when calculating prices, but improper usage or lack of checks may lead 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 dangers of calling external contracts is that they can take over the control flow and make unforeseen changes to the data by calling functions. For example:

solidity mapping (address => uint) private userBalances;

function withdrawBalance() public { uint amountToWithdraw = userBalances[msg.sender]; (bool success, ) = msg.sender.call.value(amountToWithdraw)(""); require(success); userBalances[msg.sender] = 0; }

Since the user's balance is set to 0 only at the end of the function, the second (and subsequent) calls will still succeed and will repeatedly withdraw the balance.

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

1. Not just preventing the reentrancy issue of a single function
2. Follow the Checks-Effects-Interactions pattern for coding
3. Use time-tested anti-reentrancy modifier

There are many best security practices in this field that we should use directly instead of reinventing the wheel. Using mature, proven solutions has a much lower probability of encountering problems than developing new solutions ourselves.

Project Party Security Recommendations

1. Contract development follows best security practices.

2. Contracts can be upgraded and paused: Many attacks are not one-time events where all coins are transferred at once, but rather executed in multiple transactions. If there is a relatively sound monitoring mechanism, it can promptly detect and pause the contract, effectively reducing losses.

3. Use time locks: If there are time locks, they can provide enough time for people to detect anomalies and take action.

4. Increase security investment and establish a sound security system: Security is systematic, not only including contract audits but also involving multiple aspects such as private key management and economic models.

5. Enhance the security awareness of all employees: Many security issues can be avoided by increasing vigilance.

6. Prevent internal malice, enhance risk control while improving efficiency: Mechanisms such as multi-signature and time locks can improve security while ensuring efficiency.

7. Third-party introduction of security: Security checks must be performed on both upstream and downstream, especially for non-open-source contracts, which require particular caution.

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

1. Is the contract open source: Do not participate in projects that are not open source.

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

3. View the existing trading situation of the contract: including deployment time, number of interactions, etc.

4. Is the contract a proxy contract, is it upgradable, and is there a time lock?

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

6. Pay attention to Oracles: Projects that use well-known oracles are relatively safer, while self-built or easily manipulated oracles should be treated with extra caution.

In summary, in a Web3 environment, staying vigilant and asking several "why" questions can help avoid many potential risks. Whether it is project teams or regular users, everyone should pay attention to security issues and establish a complete security awareness and prevention mechanism.