T28 · Smart Contract Security

一个现实问题

一个金库合约，二十行。存进去，取出来。

function withdraw() external {
    uint256 amount = balances[msg.sender];
    require(amount > 0, "nothing to withdraw");

    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "transfer failed");

    balances[msg.sender] = 0;
}

你逐行读一遍：

第一行，读出这个人的余额。对的。 第二行，没有余额就拒绝。对的。 第三行，把这笔钱转给他。对的。 第四行，转账失败就整笔回滚。对的。 第五行，把他的余额清零。对的。

五行，每一行单独拎出来都完全正确。编译零警告，单元测试全绿，分支覆盖率 100%。

上线第二天，金库被搬空了。不是被搬走一个人的钱，是所有人的钱。

你把那笔交易的调用轨迹拉出来，看到的东西很反常：一次交易里，withdraw 被进入了几十次，每一次都成功，每一次都转出了同样的金额。而发起的那个账户，一开始只存了一笔很小的钱。

到这里，问题已经不是「哪一行写错了」，因为没有一行写错。

问题是：这五行之间发生了什么，是我逐行读代码时没有看见的？

思想实验

把这段代码翻译成柜台业务。

你去银行取钱，柜员做三件事：

1. 翻开账本，看你名下有多少钱
2. 从抽屉里数出这么多现金，递给你
3. 在账本上把你的余额划掉

三个动作，顺序看起来天经地义。绝大多数时候它也确实没问题。

现在加一个条件：在第 2 步「递给你」的那一瞬间，你有机会立刻再提一次要求，而柜员必须先处理这个新要求，才能回来做第 3 步。

于是：

柜员翻账本：你有 100      →  数 100 给你
在这一刻又收到一次请求    →  柜员翻账本：账上还是 100（还没划！）
                          →  又数 100 出去
再收到一次请求            →  账本上还是 100
                          →  又数 100 出去
...
抽屉空了，柜员终于回过头来，把账本上的 100 划掉

账本最后只被划了一次，现金出去了几十次。

柜员一笔账都没算错。 每一次他都认真翻了账本，每一次给出的金额都和账本一致。他做错的只有一件事：

在「钱已经出去、账还没记」的那个瞬间，他允许了一次新的请求插进来。

这就是开头那五行代码的全部问题。第三行 msg.sender.call 不只是「把钱转过去」——它把执行权交给了对方。对方的代码在那一刻开始运行，而此时账本还停在旧值上。

再做第二个思想实验，它对应这一章的另一半。

一栋办公楼，前门有保安查证件，一次都没查错，楼里的人很放心。问题在侧门：设计的时候大家觉得「侧门只有员工知道」，就没派保安。

保安的检查从来没出过错，楼还是被进去了。 因为安全性不取决于你检查得多严，而取决于有没有一条路绕过了检查。

两个实验合起来，就是这一章的全部：

漏洞不在某一行代码里，它在两行之间的顺序里，和没被把守的那条路径上。

你来决定

给开头那个金库修一刀。只能先改一处，你改哪一处？

观察结果

四刀的对照：

第一条结论：

顺序是根治，锁是保险。两个都要。

不要因为加了锁就不管顺序——锁有盲区。也不要因为顺序对了就不加锁——顺序会在后续迭代里被别人改回去，而锁会在那一刻救你一次。

第二条结论更重要，它是这一章真正的主轴：

任何一次对外部地址的调用，都是把执行权交了出去。在交还执行权之前，你的状态必须已经是自洽的。

这句话的威力在于它不只适用于转原生代币。把「执行权会被交出去」的位置列全，你会发现它比想象的多得多——而这正是 T7、T9、T12 一路预告到这里的那份清单。

第三条结论来自第二个思想实验：

安全性不由「检查得多严」决定，由「有没有一条路绕过了检查」决定。

所以审合约的方式不是逐行读代码，而是逐条路径地问：这条路上谁在把关。

建立模型

执行权会在哪些地方被交出去

先把清单列全。这是这一章最该打印出来贴在显示器上的一张表。

最后一行是整张表的总结：

任何一个地址参数，都可能是一份合约。

T9 讲 NFT 标准时留过一句话：那个「转给合约时会回调确认」的设计，是为了防止 NFT 被转进取不出来的地址，但它同时意味着转账过程中会把执行权交给接收方。现在把它说完整：

// 一个看起来很常规的铸造函数
function mint(uint256 qty) external payable {
    require(qty <= MAX_PER_TX, "too many");
    require(minted[msg.sender] + qty <= MAX_PER_WALLET, "wallet limit");
    require(msg.value == qty * PRICE, "wrong value");

    for (uint256 i = 0; i < qty; i++) {
        _safeMint(msg.sender, nextId++);   // 这一行会回调接收方
    }

    minted[msg.sender] += qty;             // 计数在回调之后才更新
}

接收方在回调里再次进入 mint，此时 minted[msg.sender] 还是旧值，钱包上限检查形同虚设。每一行都对，顺序错了。

同一个形状的四种形态

大多数人只认识第一种，而真正出事的常常是第三种。

第三种值得单独写一段，因为它是近年来出事最多的一类，而且它伤害的往往不是你，是集成你的人。

// 一个按「总资产 除以 总份额」报价的金库
function pricePerShare() external view returns (uint256) {
    return (address(this).balance * 1e18) / totalShares;
}

function redeem(uint256 shares) external nonReentrant {
    uint256 amount = (address(this).balance * shares) / totalShares;
    sharesOf[msg.sender] -= shares;

    (bool ok, ) = msg.sender.call{value: amount}("");   // 执行权在这里交出去
    require(ok, "transfer failed");

    totalShares -= shares;      // 分母在这之后才更新
}

redeem 上有锁，所以没人能重新进入它。但是在那次 call 期间：

分子（合约余额）：已经减少了
分母（totalShares）：还没减少
→ pricePerShare 返回一个比真实值偏低的数

在这段时间里，外部合约不去碰这个金库，而是去调用另一个把 pricePerShare 当预言机用的借贷协议。那个协议读到偏低的价格，于是 T21 讲过的那条预言机操纵的路就通了。

三条教训：

1. view 函数没有锁，也不可能有锁。 保护它的唯一方式是保证它读到的状态永远自洽。
2. CEI 的「状态」包括所有会被外部读取的派生量，不只是你在这个函数里显式改的那几个变量。
3. 集成方要问一句：我读的这个数，在被读的那一刻是不是中间状态。 这是上一章那句「上游不可信时，防线画在自己这一侧」的又一次应用。

CEI：三个字母的顺序

Checks        先做全部检查与参数校验
Effects       再把本合约的状态改成「这件事已经发生了」
Interactions  最后才和外部世界交互

对照着看：

T19 提过一个例外：真实的 AMM 实现常常是「先转出，再检查不变量」，这样才能支持闪电兑换。那不是违反 CEI，而是把 Effects 换成了「交互之后校验不变量」。 这条路走得通，但它要求你能明确写出那条不变量，并且在交互返回后逐一验证。

允许在交互之后再收口，前提是你写得出那条不变量。写不出来，就老老实实按 CEI 的顺序来。

权限边界

上一节是顺序问题，这一节是边界问题。两者加起来占了漏洞的大多数。

第五行最隐蔽，因为它跨了两份合约，单独审任何一份都看不出问题：

// 金库：只信任策略合约
function pull(uint256 amount) external {
    require(msg.sender == strategy, "only strategy");
    token.transfer(strategy, amount);
}

// 策略：一个「任何人都能触发」的再平衡函数
function rebalance(address to, uint256 amount) external {   // 没有任何检查
    vault.pull(amount);
    token.transfer(to, amount);
}

金库的检查完全正确。策略是它信任的地址。而策略把这份信任无条件转给了所有人。

审权限的正确方式不是读修饰符，是画一张图：谁能调到这个函数，经过几跳。 只要有一跳是「任何人」，整条链就是「任何人」。

最后一条实践规则：

默认拒绝。 新增一个外部函数时，先假设它需要权限，再去论证为什么可以公开；而不是反过来。

精度与取整方向

这一类问题的特征是：它不需要任何攻击技巧，只需要有人比你更仔细地算了一遍账。

整数除法永远向下取整，这不是 bug。问题在于误差落在谁那一边。

一条可以直接抄的规则：

每一次取整的误差，都必须落在协议这一边，不能落在用户那一边。

展开成表：

还有一条硬规则：先乘后除。 写成「先除再乘」会先损失精度再放大它，这是最常见的一种自伤。

现在看这两件事结合起来的经典后果——第一个存款人问题：

初始状态：totalShares = 0，金库里没有钱

1. 首个存款人存入 1 wei
   首存通常按 1:1  →  拿到 1 份额，totalShares = 1

2. 同一个人【不走 deposit】，直接给合约转 10000 个代币
   合约余额 = 10000e18 + 1，而 totalShares 仍然是 1

3. 下一个存款人存入 10000 个代币
   份额 = 10000e18 * totalShares / 合约余额
        = 10000e18 * 1 / (10000e18 + 1)
        = 0          ← 整数除法向下取整

4. 这个人拿到 0 份额。他的 10000 个代币成了金库资产，
   而金库的全部份额（1 份）在第一个存款人手里

这个问题需要三个条件同时成立，每一个单独看都很无辜：

- 份额按「资产 乘以 总份额 除以 总资产」计算，且向下取整
- 总资产是直接读合约余额，因此可以被「直接转账」污染
- 允许极小的首次存款，使 totalShares 可以是 1

对应三种防御，通常一起用：

1. 内部记账：总资产用一个自己维护的变量，而不是直接读余额。直接转进来的钱不计入。
2. 虚拟份额与虚拟资产：在分子分母上各加一个固定偏移，让「份额算出来是 0」这件事在经济上不划算。
3. 死份额：初始化时铸一笔份额给一个无法取出的地址，让 totalShares 永远不会小到危险的量级。

同时加一条兜底：算出来的份额是 0 就直接 revert。 一行代码，堵住这一类问题的最后一步。

升级风险

T8 推出了代理模式的三条铁律，这里逐条兑现，并补上第四条。

第一，存储布局只能尾部追加。 不能插入、不能改类型、不能换顺序、不能删除。

这条规则靠 review 守不住，要靠 CI：把每个版本的存储布局导出成一份文件提交进仓库，升级时用脚本比对，只允许新增。这是一个可以完全自动化的检查，没有理由不做。

第二，代理自己的变量放在伪随机的固定槽里，不要从 slot 0 开始声明，否则一定会和逻辑合约撞车。

第三，逻辑合约自己也是一个可以被直接调用的地址。 它的构造函数里就应该把自己标记成「已初始化」，让任何人都无法再初始化它；它里面也不能有能把自己销毁的路径。

第四，升级本身是一个需要被审计的动作，而不只是一段代码。 要回答的问题是：

- 谁能触发升级？是一个人、一个多签，还是一次治理投票？
- 有没有时间锁？多长？
- 升级会不会发出事件？外部监控能不能看见？
- 升级之后有没有一个「初始化新版本」的步骤？它有没有保护？
- 有没有办法在升级出错之后回滚？

第 24 章 说过同一句话，值得再说一遍：一个没有时间锁的可升级合约，等于把所有资金交给了持有升级权限的那把钥匙。 代码审得再干净，这一条不成立，前面的努力全部归零。

不变量：把上面所有东西收口

到这里你已经见了四类问题。它们看起来很不一样，但有一个共同点：

每一类问题，都对应一条本该永远成立、却在某个瞬间不成立的命题。

这些命题就叫不变量。它们的价值不在于「写下来看起来很专业」，而在于：

不变量是唯一能被机器反复检验的安全性表述。

「这个函数我觉得没问题」不能被检验。「合约余额永远不少于所有用户余额之和」可以——你可以让程序随机生成几百万种操作序列，每一次操作之后都检查它一遍。

这正是下一个阶段要做的事。先在这一章养成一个习惯：每写一个有状态的合约，先写出它的不变量，再写功能。 完整的写法与自动检验在 T30。

它叫什么

动手

验收 1：一份测试能证明，一个只存了小额的账户最终取回的钱超过它存入的
验收 2：把顺序修好之后，同一个测试必须从通过变成失败
验收 3：说清互斥锁和顺序修复各自挡住了什么、各自的盲区在哪

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

contract VulnerableVault {
    mapping(address => uint256) public balances;

    function deposit() external payable {
        require(msg.value > 0, "zero deposit");
        balances[msg.sender] += msg.value;
    }

    function withdraw() external {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "nothing to withdraw");

        // 这一行把执行权交给了 msg.sender
        (bool ok, ) = msg.sender.call{value: amount}("");
        require(ok, "transfer failed");

        // 等控制流回到这一行时，上面那段可能已经被重新进入过很多次
        balances[msg.sender] = 0;
    }

    function totalAssets() external view returns (uint256) {
        return address(this).balance;
    }
}

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

interface IVault {
    function deposit() external payable;
    function withdraw() external;
}

// 测试夹具：只在本地用来证明漏洞存在
contract ReentrancyProbe {
    IVault  public immutable vault;
    uint256 public unit;

    constructor(address v) {
        vault = IVault(v);
    }

    function start() external payable {
        unit = msg.value;
        vault.deposit{value: msg.value}();
        vault.withdraw();
    }

    // 金库把钱打进来时会触发这里，此时金库的账本还没清零
    receive() external payable {
        if (address(vault).balance >= unit) {
            vault.withdraw();
        }
    }
}

- 金库的 totalAssets() 掉到了 0 或接近 0
- 探针取回的总额，明显超过它当初存入的那一小笔

function withdraw() external {
    uint256 amount = balances[msg.sender];
    require(amount > 0, "nothing to withdraw");

    balances[msg.sender] = 0;                     // 先记账
    (bool ok, ) = msg.sender.call{value: amount}("");   // 再交互
    require(ok, "transfer failed");
}

AI Lab

第一步：
这是我的合约（把你在动手环节写的金库、带只读路径的份额合约、
以及一个你自己写的、带一处权限传递问题的双合约结构一起给它）。
请找出所有安全问题，每一个都要给出：
- 具体的函数和行
- 触发它需要的前置条件与调用顺序
- 造成的后果
- 修复方式
不要给出「建议做一次审计」「注意重入风险」这类没有落点的话。

第二步：
把你上面报告的每一个问题，写成一份【在当前代码上会失败】的测试。
如果你写不出这样的测试，说明这一条你并不确定，请标注出来。

第三步：
我在代码里【故意】留了至少两处问题没有告诉你。
它们分别属于「只读路径」和「跨合约权限传递」两类。
请重新审一遍，专门找这两类。

真实案例

改一个变量

带走的问题

本章自测