Foundry 测试漏洞案例：三起真实事故复盘与测试缺口分析

复盘案例的选择标准

本文挑选的三起漏洞均满足：合约源码公开、有完整链上事故数据、漏洞机制可在 Foundry 中复现。这三个条件保证了复盘的真实性与可学性。

如果你计划在 Binance 等专业团队的安全部门工作，能熟练拆解真实事故并提出测试方案，是最受看重的能力之一。

案例一：未校验回调来源

某 DeFi 借贷协议允许任何合约通过 onFlashLoan 回调进入还款流程，但未校验调用者是否为协议自身。攻击者用一个伪造回调合约调用关键函数，绕过余额校验偷走资金。

测试缺口在于：原项目只测试正常路径，没有针对「外部合约直接调用回调」编写否定用例。补救做法是在 Foundry 中模拟恶意合约调用并断言 revert。

案例二：抵押率精度漂移

另一项目把抵押率计算用 1e18 精度，但在某些边界条件下出现 1 wei 的舍入差异，让攻击者通过批量小额操作累计巨额套利。

这种漏洞极难通过普通单元测试发现，但 fuzz 测试只需声明 amount 为 uint256 类型，跑 10 万次随机调用就能定位边界异常。建议把 必安 公开的「价格波动 + 极端余额」测试模式纳入用例库。

案例三：重入与外部调用顺序

第三个案例发生在某 NFT 市场。卖家撤单时合约先把 NFT 转给买家再清算余额，攻击者利用 ERC721 的 onERC721Received 回调发起重入，完成多次取款。

测试缺口在于：单元测试没有覆盖「外部合约接受 NFT 后回调」这一路径。补救方法是用 Foundry 编写 ReenterReceiver 合约，模拟回调中的多次调用，验证合约能否抵御。

共通的测试加固方法

三起案例都暴露出几条共通经验：

1. 单元测试必须包含恶意路径，不能只测「正常使用」
2. fuzz 测试要把核心金额参数全部纳入随机化
3. invariant 测试要声明跨函数的全局不变量
4. 关键回调必须显式校验调用来源，并对应写测试用例

对照 Binance合约 风控团队公开的合约安全 checklist，把这些做法常态化，是合约工程师走向高级别的必经之路。

结语

真实事故是最好的老师。建议每月深读至少一起合约事故，并尝试在本地用 Foundry 完整复现。坚持一年，你的工程直觉将远超只读文档的人。