4、访问控制漏洞：Ownable模式缺陷、tx.origin与msg.sender区别、角色权限管理

访问控制，说白了就是「谁可以做什么」。

在智能合约里，这是最基础也最容易翻车的地方。我见过太多项目，代码写得花里胡哨，结果一个权限检查没做好，几百万美元直接归零。嗯，咱们今天就把这块彻底讲透。

4.1 Ownable模式：看似简单，坑不少

OpenZeppelin 的 Ownable 是我个人最常用的权限控制库。它提供了一个 onlyOwner 修饰器，让某些函数只有合约部署者能调用。

但问题来了——很多人以为「用了 Ownable 就安全了」。其实不然。

⚠️ 常见坑： 构造函数里忘记调用 transferOwnership，或者把 owner 写死成一个地址，导致后续无法更换 owner。

我在项目中遇到过这样一个案例：团队把 owner 设成了一个多签钱包地址，但多签钱包本身有个 bug，导致 owner 权限永远无法转移。最后整个合约只能升级，白白浪费了 gas。

来看一个典型的 Ownable 实现：

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

import "@openzeppelin/contracts/access/Ownable.sol";

contract MyContract is Ownable {
    uint256 public value;

    // 只有 owner 能调用
    function setValue(uint256 _value) external onlyOwner {
        value = _value;
    }

    // 任何人都能调用
    function getValue() external view returns (uint256) {
        return value;
    }
}

看起来没问题对吧？但如果你把 onlyOwner 用在了不该用的地方，比如 withdraw 函数，那用户存进去的钱就永远取不出来了。你想想看，这合理吗？

💡 我的建议： 尽量使用 Ownable2Step 模式，它要求新 owner 主动接受权限，避免误操作。

4.2 tx.origin vs msg.sender：一字之差，天壤之别

这两个东西，我敢说 90% 的新手都搞混过。我自己刚入行时也踩过这个坑。

msg.sender 是直接调用者，tx.origin 是交易的原始发起者。区别在哪？

  • msg.sender：当前消息的发送者。如果合约 A 调用了合约 B，那在 B 看来，msg.sender 是 A 的地址。
  • tx.origin：整个交易链的起点。不管中间经过多少合约，它始终是那个最初发起交易的 EOA 地址。

举个例子：

contract Victim {
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    // ❌ 危险！使用 tx.origin 做权限检查
    function withdraw() external {
        require(tx.origin == owner, "Not owner");
        payable(owner).transfer(address(this).balance);
    }
}

contract Attacker {
    function attack(address victim) external {
        // 诱导 Victim 的 owner 调用这个函数
        Victim(victim).withdraw();
    }
}

为什么会这样？因为 tx.origin 始终是那个 EOA 地址。如果 owner 调用了 Attacker 的 attack 函数，那 tx.origin 就是 owner 自己。攻击者就能绕过权限检查。

🔑 核心原则： 永远用 msg.sender 做权限检查，别碰 tx.origin。除非你明确知道自己在做什么。

我曾经审计过一个 DeFi 项目，他们用 tx.origin 来判断「是不是合约自己调用的」。结果呢？攻击者构造了一个中间合约，轻松绕过了所有限制。嗯，那次的审计报告写得特别长。

4.3 角色权限管理：不止是「管理员」和「用户」

Ownable 适合小项目。但一旦业务复杂起来，你就需要更细粒度的权限控制。

我个人习惯用 OpenZeppelin 的 AccessControl 库。它支持多个角色，每个角色可以有不同的权限。

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

import "@openzeppelin/contracts/access/AccessControl.sol";

contract MyToken is AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    bytes32 public constant BURNER_ROLE = keccak256("BURNER_ROLE");

    constructor() {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _grantRole(MINTER_ROLE, msg.sender);
    }

    function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {
        // 铸造逻辑
    }

    function burn(address from, uint256 amount) external onlyRole(BURNER_ROLE) {
        // 销毁逻辑
    }
}

这样做的好处很明显：

  • 你可以把铸造权限给一个合约，销毁权限给另一个合约
  • 管理员可以随时撤销某个角色的权限
  • 支持角色继承，比如 DEFAULT_ADMIN_ROLE 可以管理其他角色
⚠️ 注意： 角色权限管理也有坑。比如忘记初始化 DEFAULT_ADMIN_ROLE，或者把管理员权限给了某个 EOA 地址而不是多签钱包。

我曾经审计过一个项目，他们把 DEFAULT_ADMIN_ROLE 设成了一个普通地址。结果那个地址的私钥丢了，整个合约的管理权限就永远丢失了。你说这找谁说理去？

4.4 避坑指南：我踩过的那些坑

做安全审计这些年，我总结了几条关于访问控制的铁律：

  1. 永远不要用 tx.origin 做权限检查——除非你写的是防钓鱼合约，但那也是极少数情况。
  2. Ownable 的 owner 一定要是多签或时间锁——单点故障太可怕了。
  3. 角色权限要支持撤销和转移——别把权限写死。
  4. 构造函数里就要初始化好所有角色——别留到部署后再手动设置。
  5. 权限检查要放在函数最前面——别让攻击者有机会执行任何逻辑。
💡 小技巧： 写测试时，专门写一个「权限测试」的用例。比如用非 owner 地址调用 onlyOwner 函数，确保它 revert。

嗯，访问控制这块其实不难，但细节决定成败。你想想看，一个合约如果连「谁可以做什么」都搞不清楚，那其他安全措施再完善也是白搭。

最后说一句：权限最小化原则。每个角色只给它们完成工作所需的最小权限。别图省事，把所有权限都塞给一个角色。那样做，迟早要出事。

← 上一章 📖 返回目录 下一章 →