// SPDX-License-Identifier: MITpragma solidity ^0.8.13;
contract Attack {    KingOfEther kingOfEther;
    constructor(KingOfEther _kingOfEther) {        kingOfEther = KingOfEther(_kingOfEther);    }
    function attack() public payable {        kingOfEther.claimThrone{value: msg.value}();    }}

首先我们先来分析攻击流程：

1. Alice 部署 KingOfEther 合约。

2. Alice 调用 KingOfEther.claimThrone() 发送 1 个以太到 KingOfEther 合约中成为“以太之王”。

3. 高富帅 Bob 调用 KingOfEther.claimThrone() 发送 2 个以太到 KingOfEther 合约中成为新王。

4. Alice 收到 1 个以太币的退款。

5. Eve 使用 KingOfEther 的地址部署攻击合约 Attack。

6. Eve 调用 Attack.attack() 向 KingOfEther 合约中发送 3 个以太。

7. Attack 合约成为新王。

8. 高富帅 Bob 觉得不服，再次调用 KingOfEther.claimThrone() 向 KingOfEther 合约中发送了 20 个以太展现自己的“钞能力”。

9. Bob 发现自己的交易一直被 revert，无法成为新王。至此，Eve 的攻击使 KingOfEther 合约永久失效，Attack 合约成为了永远的“以太之王”。

高富帅 Bob 觉得不可思议，为啥自己这么有钱还不能称王呢？我们来看看到底是为什么。

修复建议

作为开发者

1. 在智能合约开发中应当注意处理连续失败的情况，例如将可能出现失败的外部调用逻辑异步处理。

2. 在使用 call 进行外部调用以及使用循环和遍历时应当注意 Gas 消耗。

3. 避免对单个角色过度授权的情况，处理合约权限时应做到合理的权限划分，对拥有权限的角色使用多签钱包管理，防止由于私钥泄漏导致权限丢失。

下面是针对上面漏洞合约的修复示例：

// SPDX-License-Identifier: MITpragma solidity ^0.8.13;
contract KingOfEther {    address public king;    uint public KingValue;    mapping(address => uint) public balances;
    function claimThrone() external payable {        balances[msg.sender] += msg.value;
        require(balances[msg.sender] > balance, "Need to pay more to become the king");                KingValue = balances[msg.sender];        king = msg.sender;    }
    function withdraw() public {        require(msg.sender != king, "Current king cannot withdraw");
        uint amount = balances[msg.sender];        balances[msg.sender] = 0;
        (bool sent, ) = msg.sender.call{value: amount}("");        require(sent, "Failed to send Ether");    }}

可以看到修复合约中添加了 balances 映射，它记录了每个人向合约中打入以太的总数量相较于之前合约的优势是玩家失去王位后可以追加以太重新获得王位。修复版本的关键点是将退款逻辑作异步处理，需要玩家手动调用 withdraw() 来自助退款，就算遇到恶意玩家拒收以太也只能影响到自己，不会再造成之前的拒绝服务了。

作为审计者

• 内部合约进行分析：

1. 注意合约中是否存在逻辑上的错误导致影响了可用性。

2. 注意是否存在由于虚拟机调用深度过大导致的 DoS（深度最大 1024）。

3. 重点关注在代码逻辑中是否存在大量消耗 Gas 的逻辑。

• 外部合约进行分析：

1. 关注与外部合约进行交互的时候没有考虑好兼容性的问题，如：未处理 TRC20-USDT 的返回值的兼容性，导致代币被锁定。

2. 重点检查有没有判断外部合约调用的返回值是否符合预期的效果。

• 对权限管理进行分析：

在审计中需要检查和确认所有函数方法的可见性及调用权限，需要结合项目方提供设计文档在审计中根据设计文档中的描述一一确认权限。如果发现过度授权或权限划分不清晰的需要与项目方交流改进方法，并且与项目方沟通运营操作的流程，确保流程上能够避免合约在运营的时候管理员操作失误或配置错误的情况。

注：本文参考于《Solidity by Example》

往期回顾

Unicode 视觉欺骗攻击深度解析

揭秘以太坊 Vanity 生成器 Profanity 私钥破解漏洞

慢雾解读 | 区块链分叉带来的安全挑战

共迎中秋 | 一份讲究的慢雾定制礼品（文末有惊喜）

暗夜小偷：Redline Stealer 木马盗币分析