权限控制问题

权限管理不当的严重性

智能合约中的权限管理问题本质上源于对关键功能访问控制的不严谨设计或实现错误。这类漏洞可能允许未经授权的用户执行本应受限的操作，如无限制铸造代币、转移用户资产或修改合约核心逻辑。

典型案例包括管理员账户被过度赋权，例如一个简单的代币合约中，管理员可以无限制地铸造新代币并将其转移到任意账户。如果管理员私钥泄露或初始设置错误，攻击者便可利用这一点无限增发代币，导致严重的通胀和经济系统崩溃。

更危险的是，某些合约中存在"后门"函数，允许特权账户（如 owner 或 admin）直接销毁或转移任意用户的资产。安全研究人员在对大量合约审计中发现，这类问题相当普遍，包括burn()、burnFrom()、destroyTokens()等函数都可能被滥用。例如，某些合约中的burnFrom()函数允许合约所有者销毁任意地址的代币，而melt()函数则允许 CFO（首席财务官角色）执行类似操作。

常见权限漏洞模式

1. 过度集中的权限控制

许多合约采用单一管理员模式，将所有特权集中在一个地址上。如下面这个漏洞合约示例：

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

    constructor() {
        admin = msg.sender;
    }

    function mint(address to, uint256 amount) public {
        require(msg.sender == admin, "Only admin can mint");
        balances[to] += amount;
    }
}

这个合约中，admin可以无限制地调用mint函数创建新代币。一旦这个账户被攻破，整个经济系统将面临灾难性后果。

2. 条件判断逻辑错误

某些权限漏洞源于简单的编码错误，如应该使用==的地方误用了!=。在一个实际案例中，韩国区块链项目 ICON(ICX)的智能合约就曾因此类错误导致严重后果：

modifier onlyFromWallet {
    require(msg.sender != walletAddress); // 错误地使用了!=
    _;
}

本意是限制只有钱包地址能调用特定函数，但由于条件判断写反，实际上除了钱包地址，其他所有地址都能调用该函数。

3. 缺乏权限分层与限制

即使实施了权限控制，很多合约也缺乏对特权操作的合理限制。例如，管理员可能被赋予无限的铸造权限，而没有每日限额、总量上限或时间锁等安全机制。

4. 后门函数与过度特权

许多合约包含允许特权账户直接操作用户资产的函数，如：

burn(address from, uint amount)：允许 owner 销毁任意用户的代币
sweep(address from, address to, uint amount)：允许 owner 转移任意用户的资金
zero_fee_transaction(address from, address to, uint amount)：允许特殊账户无需授权即可转账

这些函数本意可能是用于紧急情况或特殊业务需求，但一旦被滥用或泄露，将严重破坏用户信任。

权限管理最佳实践

1. 最小权限原则

每个角色只应拥有完成其职责所需的最小权限。例如，铸造功能可以设置每日上限：

contract SafePermissions {
    uint256 public dailyMintLimit;
    uint256 public dailyMinted;

    function mint(address to, uint256 amount) public onlyAdmin {
        require(dailyMinted + amount <= dailyMintLimit, "Daily limit exceeded");
        balances[to] += amount;
        dailyMinted += amount;
    }
}

这种方式即使管理员账户被攻破，攻击者也无法无限制地铸造代币。

2. 多签与多重验证

对于关键操作，应引入多签机制，要求多个独立方批准才能执行。OpenZeppelin 的 AccessControl 库提供了角色管理的标准实现：

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

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

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

    function criticalOperation() public onlyRole(ADMIN_ROLE) {
        // 需要ADMIN_ROLE才能执行
    }
}

这种方式可以避免单点故障。

3. 基于角色的访问控制(RBAC:Role-Based Access Control)

更复杂的系统可以采用基于角色的访问控制模型，定义不同角色并分配相应权限。中国银行的一项专利就展示了如何将 RBAC 应用于金融业务合约，实现细粒度的权限管理。

4. 权限审计与时效性

所有权限操作应记录在事件日志中供审计，同时权限应设置有效期，过期后需要重新授权。例如：

mapping(address => uint256) public adminExpiry;

function addAdmin(address newAdmin, uint256 expiryTime) public onlyAdmin {
    admins[newAdmin] = true;
    adminExpiry[newAdmin] = expiryTime;
}

modifier onlyAdmin() {
    require(admins[msg.sender] && adminExpiry[msg.sender] > block.timestamp, "Not admin or expired");
    _;
}

漏洞类型：重入攻击（访问控制不足）
影响：攻击者利用递归调用漏洞，从 The DAO 合约中盗取了 360 万枚 ETH（当时价值约 5000 万美元），最终导致以太坊硬分叉，分裂为 ETH 和 ETC。
原因：合约在转账时未采用“检查-生效-交互”（Checks-Effects-Interactions, CEI）模式，允许攻击者在余额清零前多次提取资金。

2. Parity 多重签名钱包漏洞（2017 年）

漏洞类型：函数可见性错误（未限制关键函数调用权限）
影响：攻击者利用未正确设置访问控制的initWallet函数，将 Parity 钱包合约变为“自杀”状态，导致约 15.3 万枚 ETH（当时价值 3000 万美元）被永久锁定。
原因：关键初始化函数未设置为internal或private，允许任意用户调用并接管合约。