2025 年令 Web3 蒙受逾 10 亿美元损失的隐形安全失误
- ancilartech
- 发布于 13小时前
- 阅读 34
文章回顾了2025年Web3领域的重大安全损失，指出许多漏洞并非传统代码Bug，而是源于经济逻辑缺陷、前端基础设施漏洞、预言机延迟及供应链风险。强调安全应被视为贯穿系统生命周期的持续性过程，而非仅仅是上线前的审计。
如果你只看头条新闻，2025 年似乎是 Web3 强劲发展的一年。现实世界资产代币化（Tokenizing real world assets）势头正劲，机构参与度更高，DeFi 也在持续增长。
但在这些进展背后，一些起初并未引起太多关注的事情正在发生。
到年底时，不同协议的总损失已超过 34 亿美元。引人注目的不仅是数字，还有这些损失发生的实际方式。其中超过 10 亿美元源于那些并不明显的问题。它们不是那种会出现在标准审计报告中或被自动化工具标记出来的 bug。
在许多情况下，代码看起来很整洁。系统已经过审查。一切似乎都很好，直到问题爆发。
这些失败存在于逻辑、基础设施和人类行为之间的缝隙中。这正是它们的危险之处。
对于任何在进入 2026 年时构建或投资 Web3 的人来说，这改变了对话。安全不再是你在发布前“完成”的任务。它是你在系统运行的整个过程中需要持续投入的工作。
当代码运行正常但系统失效时
2025 年一个比较令人惊讶的模式是，一些最大的损失来自于技术上完全正确的代码。
它通过了编译。它通过了测试。它甚至通过了审计。
然而，它在经济逻辑上仍然崩溃了。
一个著名的案例是 Cetus Protocol 的漏洞利用。位移操作（bitwise shift）处理中的一个小问题允许攻击者迅速抽干了大约 2.23 亿美元。当时并没有明显的漏洞利用模式。代码完全按照编写的方式运行。
真正的问题在于，它被编写出的行为与它在经济上应该表现出的行为不匹配。
从根本上说，一个系统永远不应该允许流出的价值超过它实际持有的价值。这听起来很简单，但并没有被强制执行。
如今大多数工具都集中在技术漏洞上。它们寻找已知的模式，如重入（reentrancy）或溢出（overflow）问题。它们通常不会检查在压力或极端情况下，财务逻辑是否仍然合理。
这种差距正是许多破坏发生的地方。
越来越多的团队开始通过定义必须始终成立的明确规则来应对这一问题。他们不再假设数学是正确的，而是在每次重要操作后验证结果。如果某些操作破坏了这些规则，交易就根本无法通过。
这听起来显而易见，但缺失的情况比预期的要多。
问题并不总是在链上
2025 年的另一个转变是攻击者关注的重点。
直接攻破智能合约很难，特别是当它们经过多次审计时。因此，攻击者寻找更简单的路径。
他们在系统中那些感觉不太关键的部分找到了这些路径。
前端、域名注册商和基础账户安全成为了常见的切入点。在影响 Aerodrome Finance 等攻击中，用户被重定向到了合法网站的虚假版本。
看起来没有任何可疑之处。界面很熟悉。流程感觉很正常。
但当用户批准交易时，他们实际上是将控制权交给了攻击者。
这类攻击之所以奏效，是因为团队往往将大部分时间和预算花在保护合约上，而将基础设施视为次要问题。
实际上，如果攻击者可以控制用户看到的内容，他们根本不需要攻破合约。
当数据正确但依然危险时
预言机（Oracles）是另一个表面看起来没问题但在实践中失效的领域。
许多协议依赖外部价格喂价。假设很简单：如果数据是准确的，系统就是安全的。
2025 年的情况表明，仅有准确性是不够的。
时效性同样重要。
如果在快速的市场波动中，价格喂价稍微有些过时，就会在实际价值和链上价值之间产生缺口。这个缺口可以被利用。
一些协议，特别是那些处理现实世界资产的协议，因此措手不及。它们的系统继续正常运行，但它们使用的是陈旧的数据。
记住我以便更快登录
攻击者注意到了这一点并加以利用。
对数据新鲜度的一个简单检查本可以防止许多此类案例。然而，这种检查通常是缺失的。
访问控制不仅仅关乎钱包
人们还倾向于认为使用多签（multisig）钱包就能解决大多数访问控制问题。
2025 年表明事实并非如此。
在其中一起最大的事件中，攻击者获得了访问权限并潜伏了一段时间。他们没有匆忙行动。他们观察系统的运行方式，学习模式，并等待合适的时机。
这种“潜伏时间”的概念令人不安，但很重要。
这意味着攻击不仅仅是关于进入。它还关于进入之后发生了什么。
如果多个签名者使用相同的设备、相同的网络或相同的密码管理器，那么要求多个签名并不能像人们想象的那样增加保护。
系统在纸面上看起来是去中心化的，但在实践中并非如此。
你从依赖项中继承的风险
引起问题的另一个领域是第三方代码的使用。
现代开发严重依赖开源库。这不会改变。它让事情变得更快、更高效。
但这也意味着你正在信任你没有编写的代码。
在 2025 年的几个案例中，攻击者成功地将恶意代码插入到常用的软件包中。开发人员像往常一样更新了他们的依赖项，没有意识到任何异常。
问题仅在部署后才变得可见。
到那时，已经太晚了。
这种攻击更难被发现，因为在开发过程中看起来一切正常。一切都按预期运行，直到它不再按预期运行。
真正需要改变的是什么
所有这一切最大的启示是，安全不仅仅是防止已知问题。
它是关于以系统的角度思考。
这包括代码的行为方式、基础设施的管理方式、人与工具的交互方式，以及当出现问题时团队的响应速度。
一些团队已经开始转向这个方向。
他们更加认真地对待运营安全，通过更强的身份验证方法锁定对域名和内部工具的访问。
他们正在建立监控系统，实时监控异常活动，而不是仅仅依赖审计。
他们还在构建必要时减缓操作速度的方法。允许系统暂停或延迟重大动作的功能，在发生意外情况时可以产生巨大的影响。
最后的思考
2025 年的损失之所以令人沮丧，是因为其中许多损失是可以预防的。
不是通过更多的审计或更复杂的代码，而是通过更好的假设。
失败源于当时感觉微不足道的事情。一个缺失的检查。一个被忽视的依赖项。基础设施中的一个薄弱环节。
就其本身而言，每一个似乎都不关键。
但合在一起，它们足以耗尽数十亿资金。
进入 2026 年，表现出色的团队将是那些不再将安全视为一个独立步骤，而是将其视为构建和运营万物的一部分的团队。
因为在这个领域，最昂贵的问题往往是起初最难看出的问题。
如果你认真考虑长期构建，我们随时准备提供帮助。
Email: hello@ancilar.com
Website: https://www.ancilar.com
- 原文链接： medium.com/@ancilartech/...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
