DeFi安全课：常见漏洞剖析与防范措施

FlashLoanLarry

2025-07-28 22:52:11

摘要生成中

DeFi 常见安全漏洞及预防措施

近期，一位安全专家为社区成员分享了一堂 DeFi 安全课。专家回顾了过去一年多 Web3 行业遭遇的重大安全事件,探讨了这些安全事件发生的原因以及如何规避,总结了常见智能合约的安全漏洞及预防措施,还对项目方和普通用户给出了一些安全建议。

常见的 DeFi 漏洞类型一般有闪电贷、价格操纵、函数权限问题、任意外部调用、fallback 函数问题、业务逻辑漏洞、私钥泄漏、重入等。下面重点介绍闪电贷、价格操控以及重入攻击这三种类型。

闪电贷

闪电贷本身是 DeFi 的一种创新,但当被黑客利用时,他们可以在不需要任何成本的情况下借到大量资金,执行完整个套利流程后归还,只需支付少量的 Gas 费用就可以获得巨额收益。

过去两年里,闪电贷出现了很多问题。一些 DeFi 项目看起来收益很高,但实际上项目方的水平参差不齐。有的项目代码可能是购买的,即便代码本身没有漏洞,在逻辑上仍可能存在问题。例如,曾经有一个项目会在固定时间根据持仓者持有的代币数量发放奖励,却被攻击者利用闪电贷购买大量代币,在奖励发放时,大部分奖励都流向了攻击者。此外,还有一些通过 Token 来计算价格的项目,可以通过闪电贷影响价格。作为项目方应该对这些问题提高警惕。

价格操控

价格操控问题与闪电贷关系密切,这个问题主要是由于价格计算时其中一些参数可以被用户控制,经常出现的问题类型有两种:

计算价格时使用第三方的数据,但使用方式不正确或检查缺失导致价格被恶意操控。
使用了一些地址的 Token 数量作为计算变量,而这些地址的 Token 余额可以被临时增加或减少。

重入攻击

调用外部合约的主要危险之一是它们可以接管控制流,并对你的数据进行调用函数未预料到的更改。

由于用户的余额直到函数的最后才设置为 0,第二次(和以后的)调用仍然会成功,并且会一遍又一遍地提取余额。

针对不同的合约,重入存在的方式很多,可以结合合约的不同函数或多个不同合约的函数完成重入攻击,所以我们在解决重入问题时需要注意以下几点:

不只是防止单一函数的重入问题;
遵循 Checks-Effects-Interactions 模式进行编码;
使用经过时间验证的防重入 modifier。

其实最怕的就是重复造轮子,需要什么都自己写。在这个圈内有很多最佳安全实践,我们拿来用就好,完全没有必要重复造轮子。当你造一个轮子的时候,是没有通过充分的验证的,这个时候出问题的概率,很明显比用一个非常成熟的久经考验的出问题的概率要大得多。

安全建议

项目方安全 Tips

合约开发遵循最佳安全实践。
合约可升级、暂停:很多攻击不是一次性的把币全转走,而是分多笔交易去执行,如果有一个相对健全的监控机制的话,是可以发现的,发现之后合约假设是可以暂停的,就可以有效的去降低损失。
采用时间锁:如果有时间锁的话,假设是 48 小时之内才能完成,这个时候在时间锁的很多人能发现这个创建者重新更新了一个 mint 的方法,且谁都可以用,监控的人就知道项目应该是被黑了,就可以通知项目方去改变,即使假设通知了也没人管,至少可以先把自己的那部分钱给拿出来,先保证自己的收益不受损。所以说一个项目如果没有时间锁的话,理论上来讲是增加了出问题的概率。
加大安全投入,建立一套完善的安全体系:安全不是一个点,也不是一条线,安全是成体系的。不要觉得作为项目方,合约通过多家公司审计就没问题了。要尽量做风险建模,然后逐步地将大部分风险规避掉,剩余风险也是可接受风险,在可承受范围内。安全和效率是不可能兼得的,要做一定的取舍。但如果完全不管安全,在安全上没有投入的话,被攻击是很正常的。
提高所有员工的安全意识:提高安全意识并不需要很多技术。在这个大环境内,只要稍微多问一些为什么,稍微多想一点就能规避掉很多问题。
预防内部作恶,在提升效率的同时增强风控。
三方引入安全性:作为生态中的一环,项目方都会有自己的上下游。安全上有一个"默认上下游都是不安全"的原则。无论对于上游还是下游,都要做校验。对于三方我们是很难控制,安全的风险敞口实际上特别大,所以要很注意三方的引入。合约是开源的,可以去引入、调用它;如果合约不开源,就绝对不能引用。

用户/LP 如何判断智能合约是否安全?

对于普通用户,我们判断项目是否安全主要看以下六点:

合约是否开源:凡是合约不开源的项目,坚决不碰,因为我们无从得知合约写的是什么。
Owner 是否采用多签,多签是否去中心化:如果不用多签,我们无法判断项目的业务逻辑和内容,一旦出现安全事件,无法判断是否为黑客所为。即便采用多签,也需要判断一下多签是不是去中心化的。
合约已有的交易情况:尤其市面上有很多搞钓鱼诈骗的项目,可能会做一个比较相似的合约,这个时候我们就要看一下合约的部署时间、交互次数等,这些都是判断合约是否是安全的衡量标准。
合约是否为代理合约,是否可升级,是否有时间锁:如果合约完全不能升级,就太死板了,还是推荐项目的合约是可以升级的。但是升级要讲究方法,当升级有升级内容、重要参数更改的时候,要有一个时间锁定,要有给大家一个时间窗口去判断真实升级是对用户有害的还是有利的,这也是公开透明的一种方式。
合约是否接受过多家机构审计(不要盲目信任审计公司), Owner 权限是否过大:首先不要只相信一家审计公司,因为不同的审计公司,不同的审计人员,看问题的角度是不一样的。其次要看 Owner 的权限是否过大。一个正常的项目 Owner 的权限一定是可控的,这样就不会有太多高危操作,操作也会用时间锁的方式,让用户知道操作的是什么。
注意预言机:如果项目使用市面上的龙头预言机,基本上不会有太大问题,但如果使用自建的预言机,或者用一些随便抵押一些代币就可以往里去喂价的预言机,那就要注意了。当发现预言机可能会存在一些问题,或者说存在被操纵可能的时候,即便项目收益再高也不能参与。