#Gate 2025 Semi-Year Community Gala# voting is in progress! 🔥
Gate Square TOP 40 Creator Leaderboard is out
🙌 Vote to support your favorite creators: www.gate.com/activities/community-vote
Earn Votes by completing daily [Square] tasks. 30 delivered Votes = 1 lucky draw chance!
🎁 Win prizes like iPhone 16 Pro Max, Golden Bull Sculpture, Futures Voucher, and hot tokens.
The more you support, the higher your chances!
Vote to support creators now and win big!
https://www.gate.com/announcements/article/45974
Decentralized Finance Security Course: Analysis of Common Vulnerabilities and Prevention Measures
Common Security Vulnerabilities in DeFi and Preventive 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 security incidents and how to avoid them, 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 generally include flash loans, price manipulation, function permission issues, arbitrary external calls, fallback function issues, business logic vulnerabilities, private key leaks, reentrancy, etc. Below, we will focus on explaining 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 the entire arbitrage process, and return the funds, only needing to pay a small Gas fee to obtain huge profits.
In the past two years, many problems have arisen with flash loans. Some DeFi projects appear to have high returns, but in reality, the quality of the project teams varies greatly. Some project codes may have been purchased; even if the code itself has no vulnerabilities, there may still be logical issues. For example, there was once a project that distributed rewards based on the number of tokens held by holders at fixed times, but attackers exploited flash loans to buy large amounts of tokens, resulting in most of the rewards flowing to the attackers at the time of distribution. Additionally, there are some projects that calculate prices based on tokens, which can be influenced by flash loans. Project teams should be vigilant about these issues.
Price Manipulation
The issue of price manipulation is closely related to flash loans. This problem mainly arises because some parameters in price calculation can be controlled by users. There are two common types of issues that occur:
Third-party data is used to calculate prices, but incorrect usage or lack of checks can lead to malicious manipulation of prices.
The number of tokens at some addresses was used as a calculation variable, and 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 unexpected changes to your data by invoking functions.
Since the user's balance is set to 0 only at the end of the function, the second call of ( and subsequent calls of ) will still succeed and repeatedly withdraw the balance.
There are many ways for reentrancy to occur with different contracts, which can involve combining different functions of the contract or functions of multiple different contracts to carry out a reentrancy attack. Therefore, when addressing the reentrancy issue, we need to pay attention to the following points:
Not only prevent the reentrancy issue of a single function;
Follow the Checks-Effects-Interactions pattern for coding;
Use a time-tested anti-reentrancy modifier.
What we really fear is reinventing the wheel, having to write everything ourselves. There are many best security practices in this field that we can adopt, and there is no need to reinvent the wheel. When you create a wheel, it has not been sufficiently validated, and at that point, the probability of issues arising is clearly much greater than that of using a well-established and thoroughly tested solution.
Security Recommendations
Project Party Security Tips
Contract development follows best security practices.
Contracts can be upgraded and paused: Many attacks do not drain all the coins in a single transaction, but rather execute multiple transactions. If there is a relatively sound monitoring mechanism in place, it can be detected. Once detected, assuming the contract can be paused, it effectively reduces the loss.
Use of Time Lock: If there is a time lock, assuming it can be completed within 48 hours, at this time many people can discover that the creator has updated a minting method that anyone can use. Those monitoring will know that the project might have been hacked and can notify the project team to make changes. Even if they notify and no one takes action, at least they can withdraw their portion of funds first to ensure their profits are not compromised. Therefore, if a project does not have a time lock, theoretically, it increases the probability of encountering issues.
Increase investment in security and establish a complete security system: Security is not a point, nor a line; it is a system. Don't think that as a project party, having contracts audited by multiple companies means there are no issues. Try to conduct risk modeling, and then gradually avoid most of the risks. The remaining risks should be acceptable risks, within a bearable range. Security and efficiency cannot be achieved at the same time; some trade-offs need to be made. However, if you completely ignore security and do not invest in it, being attacked is very normal.
Raise the security awareness of all employees: Raising security awareness does not require a lot of technology. In this large environment, just asking a few more why questions and thinking a little more can avoid many issues.
Prevent internal malfeasance while enhancing risk control alongside improving efficiency.
Third-party security introduction: As a part of the ecosystem, project parties will have their own upstream and downstream. There is a principle of "default upstream and downstream are unsafe" in terms of security. Whether for upstream or downstream, verification must be done. It is very difficult for us to control third parties, and the risk exposure is particularly large, so we need to be very cautious about introducing third parties. Contracts are open source and can be introduced and called; if the contract is not open source, it must not be referenced.
How can users/LP determine if a smart contract is safe?
For ordinary users, we judge whether a project is safe mainly by looking at the following six points:
Is the contract open source: Any project with a non-open source contract is to be avoided, as we cannot know what the contract entails.
Does the Owner use multi-signature, and is the multi-signature decentralized? If multi-signature is not used, we cannot assess the project's business logic and content. In the event of a security incident, we cannot determine whether it was caused by a hacker. Even if multi-signature is used, it is necessary to evaluate whether the multi-signature is decentralized.
Existing trading situation of the contract: Especially since there are many phishing scam projects in the market, they may create a relatively similar contract. At this time, we need to look at the contract's deployment time, interaction frequency, etc. These are all metrics for judging whether the contract is safe.
Is the contract a proxy contract, is it upgradeable, and is there a time lock: If the contract cannot be upgraded at all, it is too rigid, and it is still recommended that the project's contract is upgradeable. However, the method of upgrading is important; when there are upgrades or changes to important parameters, there should be a time lock to provide everyone with a time window to assess whether the actual upgrade is harmful or beneficial to users, which is also a way of being open and transparent.
Has the contract been audited by multiple organizations ( Do not blindly trust auditing firms ), Is the Owner's permission too large: First, do not only trust one auditing firm, as different auditing firms and different auditors have varying perspectives on issues. Secondly, check whether the Owner's permissions are too large. The permissions of a normal project Owner should be controllable, so there won't be too many high-risk operations, and operations will be done through time locks to let users know what the operations are.
Pay attention to Oracles: If the project uses leading oracles available on the market, there generally won't be significant issues. However, if it uses a self-built oracle, or an oracle that allows price feeding with casually pledged tokens, caution is warranted. If any problems with the oracle are detected, or if there is a possibility of manipulation, one should refrain from participating even if the project's returns are high.