第4章访问控制漏洞

4、访问控制漏洞：tx.origin与msg.sender的区别、权限管理不当、Ownable模式与RBAC

访问控制，说白了就是「谁有资格干这件事」。在智能合约里，这个「谁」一旦搞错了，轻则数据泄露，重则合约里的钱被人一把掏空。我见过太多项目因为访问控制没写好，最后被黑客当提款机用的案例了。今天咱们就把这块掰开揉碎了讲清楚。

4.1 tx.origin 与 msg.sender：一个天一个地

这两个东西，很多新手容易搞混。我刚开始写合约的时候也踩过这个坑。先看定义：

msg.sender：直接调用当前合约的地址。说白了就是「谁喊的我」。
tx.origin：整条交易链的发起者。也就是「最初那个掏钱签交易的人」。

你想想看，如果合约A调用了合约B，合约B里用tx.origin做权限校验，那结果会怎样？

核心区别：

msg.sender 是直接调用者，可能是EOA，也可能是另一个合约
tx.origin 永远是EOA（外部账户），是交易的原始发起者

来看个反面教材：

// ❌ 危险写法：用 tx.origin 做权限校验
function withdraw() public {
    require(tx.origin == owner, "Not owner");
    payable(msg.sender).transfer(address(this).balance);
}

为什么会出问题？假设有个钓鱼合约，诱导用户去调用它，然后它再回调你的合约。这时候tx.origin还是用户地址，但msg.sender已经变成了钓鱼合约。嗯，这里要注意——永远不要用tx.origin做身份校验。

避坑指南：我曾经审计过一个DeFi项目，他们用tx.origin来限制只有合约部署者才能调用紧急暂停功能。结果黑客部署了一个中间合约，诱导部署者调用，成功绕过了权限检查。那次教训让我养成了一个习惯：但凡看到tx.origin出现在require里，直接标红。

正确的做法很简单：

// ✅ 正确写法：用 msg.sender
function withdraw() public {
    require(msg.sender == owner, "Not owner");
    payable(msg.sender).transfer(address(this).balance);
}

4.2 权限管理不当：最常见的漏洞之一

权限管理不当，说白了就是「该管的人没管住，不该管的人反而能操作」。我总结了几种常见情况：

漏洞类型	具体表现	后果
初始化函数未加锁	`initialize()` 可以被任何人重复调用	攻击者可以重新初始化合约，篡改owner
关键函数缺少权限校验	`mint()`、`withdraw()` 没有require	任何人都可以铸币或提款
权限检查顺序错误	先执行逻辑，后检查权限	状态被修改后才发现权限不足，但回滚成本高
硬编码地址	owner地址写死在代码里	owner私钥丢失后，合约彻底失控

我个人习惯的做法是：权限检查永远放在函数体的第一行。这样即使函数中途revert，也不会浪费gas去执行前面的逻辑。

小技巧：写合约的时候，可以先用modifier把权限逻辑抽出来。这样既清晰又不容易漏掉。比如：

modifier onlyOwner() {
    require(msg.sender == owner, "Caller is not owner");
    _;
}

function sensitiveAction() public onlyOwner {
    // 核心逻辑
}

4.3 Ownable模式：最经典的权限方案

Ownable模式，说白了就是「一个合约只有一个老大」。OpenZeppelin提供了标准实现，我建议直接用，别自己造轮子。

标准Ownable的核心逻辑：

部署时，部署者自动成为owner
onlyOwner modifier 限制关键函数
transferOwnership() 转移所有权
renounceOwnership() 放弃所有权（慎用！）

这里有个坑我要特别说一下：renounceOwnership() 一旦调用，合约就变成「无主状态」了。我见过一个项目，团队为了展示「去中心化」，上线第一天就调用了这个方法。结果后来发现合约有个bug需要升级，但owner已经没了，只能眼睁睁看着合约被攻击。

避坑指南：我曾经参与过一个NFT项目的审计，他们用了Ownable模式，但transferOwnership()没有做两阶段确认。结果团队不小心把owner转到了一个无效地址，整个合约的管理权限彻底丢失。后来我们建议他们改用Ownable2Step模式——先提议，再确认，多一步操作，安全系数翻倍。

Ownable的局限性也很明显：它只支持一个管理员。如果项目需要多个角色（比如管理员、操作员、审计员），那就得用RBAC了。

4.4 RBAC：角色权限控制

RBAC（Role-Based Access Control），说白了就是「给不同的人分配不同的权限」。OpenZeppelin的AccessControl实现得相当成熟，我直接推荐大家用它。

核心概念：

角色：用bytes32标识，比如keccak256("ADMIN_ROLE")
授予：grantRole() 给地址分配角色
撤销：revokeRole() 收回角色
校验：onlyRole(role) modifier

来看个实际例子：

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

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

contract MyContract is AccessControl {
    bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");
    bytes32 public constant OPERATOR_ROLE = keccak256("OPERATOR_ROLE");

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

    function operatorAction() public onlyRole(OPERATOR_ROLE) {
        // 只有操作员才能调用
    }

    function adminAction() public onlyRole(ADMIN_ROLE) {
        // 只有管理员才能调用
    }
}

你想想看，这种设计的好处是什么？权限可以灵活分配，而且可以随时回收。比如项目上线后，发现某个操作员行为异常，直接revokeRole()就行，不用重新部署合约。

最佳实践总结：

能用OpenZeppelin就别自己写，标准库经过大量审计，比自己写的靠谱
权限检查放在函数最前面，用modifier实现
永远不要用tx.origin做身份校验
Ownable适合简单场景，RBAC适合多角色场景
转移所有权时，用两阶段确认（Ownable2Step）
保留一个「超级管理员」角色，用于紧急情况下的权限回收