Common Security Vulnerabilities in DeFi and Preventive Measures

Recently, a security expert shared a DeFi security course for community members. He reviewed the significant 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 preventive measures, and provided some security advice for project teams 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 these three types: flash loans, price manipulation, and reentrancy attacks.

Flash Loan

Flash loans are an innovation in Decentralized Finance, but are often exploited by hackers:

• Attackers manipulate prices or attack business logic by borrowing large amounts of funds through flash loans.
• Developers need to consider whether the contract functions will be affected by large amounts of funds, leading to anomalies or being exploited to gain improper rewards.
• Some projects did not consider the impact of flash loans during the design phase, leading to funds being stolen.

Over the past two years, flash loans have caused quite a few issues. Some high-yield DeFi projects have various vulnerabilities due to inconsistent development levels. For example, some projects distribute rewards based on holdings at fixed times, which attackers exploit by using flash loans to purchase large amounts of tokens to obtain most of the rewards. Additionally, some projects that calculate prices through tokens can have their prices affected by flash loans. Project teams should remain vigilant about these issues.

Price Manipulation

The issue of price manipulation is closely related to flash loans, mainly involving two types:

1. Using third-party data to calculate prices, but improper usage or lack of checks can lead to malicious manipulation of prices.

2. Use the Token balances of certain addresses as calculation variables, which can be temporarily increased or decreased.

Reentrancy Attack

The main risk of calling external contracts is that they may take over the control flow and make unexpected modifications to the data. 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 balance is only cleared at the end of the function, repeated calls will still successfully withdraw the balance.

Reentrancy attacks come in various forms and may involve multiple functions or contracts. To address reentrancy issues, it is important to pay attention to:

1. Not only prevent reentrancy of a single function
2. Follow the Checks-Effects-Interactions pattern
3. Use a verified reentrancy modifier

It is best to use existing best security practices rather than reinventing the wheel. Mature solutions are more secure and reliable than newly developed ones.

Project Security Recommendations

1. Follow best security practices for contract development
2. Implement contract upgradability and pause functionality
3. Adopt a time lock mechanism
4. Increase investment in security and establish a完善的安全体系.
5. Enhance the security awareness of all employees
6. Prevent internal malice while enhancing efficiency and strengthening risk control.
7. Be cautious when introducing third parties and ensure proper security checks.

How Users Can Assess Smart Contract Security

1. Confirm whether the contract is open source
2. Check if the Owner has adopted Decentralized Finance multi-signature.
3. Check the existing trading status of the contract
4. Determine whether the contract is upgradeable and whether there is a time lock.
5. Confirm whether the contract has been audited by multiple institutions and whether the Owner's permissions are too extensive.
6. Pay attention to the usage of oracle.

In conclusion, both project parties and users in the DeFi ecosystem need to maintain a high level of security awareness, take necessary precautions, and work together to ensure the healthy development of the ecosystem.