Solidity智能合约安全指南：预防已知攻击的关键.

文章目录

前言

在进行Solidity智能合约开发时，确保合约的安全性是至关重要的。虽然编写一个简单的合约可能相对容易，但要确保它能够抵御各种已知和未知的攻击却是一项艰巨的任务。为了有效预防攻击，首先我们需要了解已知的一些常见攻击类型，只有了解清楚这些攻击，才能更好地保护合约的安全性

本文将为您汇总一些Solidity中已知的攻击类型，并提供一些预防这些攻击的关键措施

(以下就是个人整理的一些已知攻击)

一、攻击类型:

重入
算术溢出
意外之财
delegatecall
默认的可见性
随机错觉
外部智能合约引用
短地址/参数攻击
未检查的返回值
竞争条件/预先交易
拒绝服务
时间戳
未初始化的存储指针
浮点和数据精度
tx.origin 判定
签名伪造
合约自毁
前导零攻击
双重花费攻击
51%攻击
跨链攻击
前向预测攻击
委托投票攻击
闪电贷攻击

2.1重入攻击

简叙:

重入攻击是一种针对智能合约的安全漏洞，攻击者利用合约在执行外部调用时的顺序问题，重复执行合约的某些关键代码段，从而实现未经授权的操作或窃取资金。

重入攻击通常发生在智能合约与其他合约进行交互时，尤其是在调用外部合约的过程中。攻击者编写恶意合约，并利用以下关键步骤进行攻击：

攻击者调用受攻击合约中的某个函数。
受攻击合约执行外部调用，调用其他合约。
在外部合约执行过程中，攻击者恶意合约中的某个函数被调用。
恶意合约中的代码执行并再次调用受攻击合约。
受攻击合约再次执行关键代码段，重复执行攻击者的恶意操作。

这种攻击利用了以太坊智能合约的状态更新机制。在合约执行外部调用时，合约的状态可能被临时保存，以便在外部调用返回后继续执行。然而，如果在外部调用期间发生了状态改变，攻击者的恶意合约可以重新进入受攻击合约并执行额外的操作，包括重复转账或重复执行某些函数。

代码分析:

pragma solidity ^0.8.0;

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

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint256 amount) public {
        require(balances[msg.sender] >= amount, "Insufficient balance");

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

        balances[msg.sender] -= amount;
    }
}

在上述示例中，**

VulnerableContract

** 是一个简单的合约，允许用户存款并从合约中提取金额。然而，该合约存在重入攻击的漏洞。

攻击者可以编写一个恶意合约，并通过以下步骤进行重入攻击：

攻击者部署一个恶意合约。

pragma solidity ^0.8.0;

contract MaliciousContract {
    VulnerableContract vulnerable;

    constructor(address vulnerableContractAddress) {
        vulnerable = VulnerableContract(vulnerableContractAddress);
    }

    function attack() public payable {
        // 触发合约的提款函数并调用回调函数（即合约自身的 fallback 函数）
        vulnerable.withdraw(msg.value);
    }

    fallback() external payable {
        // 在回调函数中再次调用受攻击合约的提款函数，实现重入攻击
        vulnerable.withdraw(msg.value);
    }
}

攻击者使用恶意合约进行攻击。

// 假设合约地址为 vulnerableContractAddress
VulnerableContract vulnerableContract = VulnerableContract(vulnerableContractAddress);
MaliciousContract maliciousContract = new MaliciousContract(vulnerableContractAddress);

// 攻击者向受攻击合约存入一定数量的以太币
vulnerableContract.deposit{value: 1 ether}();

// 攻击者调用恶意合约的攻击函数
maliciousContract.attack{value: 1 ether}();

在上述攻击中，攻击者通过调用恶意合约的 **

attack()

** 函数触发重入攻击。恶意合约在调用 **

withdraw()

** 函数时再次调用了受攻击合约的 **

withdraw()

** 函数，从而导致重复执行并重复转账，最终攻击者可以多次提取合约中的资金。

(请注意，这只是一个简单的示例，实际的重入攻击可能更加复杂和隐蔽。为了防止重入攻击，开发者需要采取安全措施，如使用互斥锁来限制重复调用、在转账前更新余额、使用优先转账模式等)

预防重入攻击:

使用互斥锁（Mutex）：在执行外部调用时，使用互斥锁来阻止重入攻击。在关键代码段执行前，获取互斥锁，并在代码执行完毕后释放锁。
检查余额和状态：在转账前，确保检查用户的余额是否足够支付，并在转账后立即更新余额和状态。
使用优先转账模式：在转账操作中，先更新状态和余额，然后再进行转账操作。这样可以防止攻击者利用重入攻击在转账之前再次调用关键代码段。
将转账放在最后：在合约函数的执行过程中，将所有状态更新操作都放在转账操作之前。这样可以确保在转账之前已经更新了状态，防止攻击者重入攻击。
限制转账金额：为转账操作设置上限，防止一次转账操作中转移过多资金。这样即使攻击者发起重入攻击，其能够窃取的资金数量也会受到限制。
使用新版Solidity：Solidity 是以太坊智能合约的编程语言，新版本的 Solidity 已经对重入攻击做出了一些改进和防护机制。使用较新的 Solidity 版本可以降低受到重入攻击的风险。
限制外部调用：尽量避免合约之间的过多外部调用，减少复杂的交互逻辑，从而降低重入攻击的风险。

2.2、算术溢出攻击

简述:

算术溢出攻击指的是在计算过程中发生数值溢出或下溢的情况，导致计算结果不正确或不符合预期。在以太坊智能合约中，当进行整数运算时，如果结果超过了数据类型所能表示的范围，就会发生算术溢出。

算术溢出攻击的典型例子是整数溢出。例如，当一个无符号整数的值达到最大值时（例如 uint256 的最大值为 2^256-1），继续进行加法操作将导致溢出，重新回到 0。攻击者可以利用这种溢出行为来达到意外的结果，例如将资金转移到攻击者的地址

代码分析:

下面是一个简单的代码示例，展示了整数溢出攻击的情况：

solidityCopy code
pragma solidity ^0.8.0;

contract OverflowVulnerable {
    uint256 public balance;

    function contribute() public payable {
        balance += msg.value;
    }

    function withdraw(uint256 amount) public {
        require(amount <= balance, "Insufficient balance");

        balance -= amount;

        // 向用户转账
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
    }
}

在上述示例中，当攻击者向 **

contribute()

** 函数贡献一定数量的以太币后，合约的 **

balance

** 增加了相应的金额。然后，攻击者可以调用 **

withdraw()

** 函数来提取资金。然而，由于没有进行足够的检查，攻击者可以提取超过合约实际余额的金额，导致整数溢出攻击。

预防益处攻击:

使用适当的数据类型：确保使用合适的数据类型来存储数值，避免数据溢出或下溢。例如，使用 SafeMath 库来进行安全的整数操作，它提供了防止溢出的加法、减法、乘法和除法函数。
边界检查：在进行数值计算之前，进行适当的边界检查以确保数值不会超过预期范围。使用 require 或 assert 来检查数值的有效性，以避免溢出。
限制转账金额：在转账操作中，进行适当的金额检查，确保转账金额不会超过合约实际余额。避免在不可信的地址之间直接转账，而是使用安全的提款模式。
安全审计和测试：对智能合约进行全面的安全审计和测试，包括静态分析工具、模拟攻击和边界情况测试等

2.3意外之财攻击

简述:

意外之财攻击（Unexpected Ether Attack）是指攻击者利用智能合约中的漏洞或意外行为，意外地获取合约中的以太币或其他数字资产的攻击方式。这种攻击可能是由于合约编写不当或合约逻辑的不完善而导致的。

意外之财攻击的一个典型示例是合约中未能正确处理接收以太币的逻辑。如果合约没有适当地处理接收以太币的函数（如**

receive()

** 或 **

fallback()

**），攻击者可以直接向合约地址发送以太币，导致合约意外地接收了以太币并无法处理。

攻击者利用这种漏洞可以通过多种方式获利，例如获取未经授权的资金、让合约陷入错误状态或利用其他合约逻辑缺陷来窃取资金。

代码分析:

pragma solidity ^0.8.0;

contract VulnerableContract {
    uint256 public balance;

    function contribute() public payable {
        balance += msg.value;
    }

    function withdraw() public {
        require(balance > 0, "Insufficient balance");

        uint256 amount = balance;
        balance = 0;

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

在上述示例中，合约 **

VulnerableContract

** 允许用户向合约贡献以太币，并通过调用 **

withdraw()

** 函数提取合约中的资金。然而，由于在提取过程中没有考虑多用户的情况，攻击者可以通过以下方式进行攻击：

攻击者通过调用 contribute() 向合约贡献一定数量的以太币。
攻击者重复调用 withdraw() 函数，合约中的 balance 值被清空，并将所有的资金转到攻击者的地址

预防攻击:

明确处理接收以太币的逻辑：确保合约中有适当的接收以太币的函数，如 receive() 或 fallback() 函数。这些函数应该有明确的逻辑来处理接收到的以太币，包括处理多用户的情况。
使用 payable 关键字：在合约函数中使用 payable 关键字，以便合约能够接收以太币。只有标记为 payable 的函数才能接收以太币，并且需要合适的逻辑来处理接收的资金。
限制访问权限：根据合约的需求，合理.

2.4 Delegatecall攻击

简述:

delegatecall 攻击是一种合约间交互的攻击方式，其中一个合约通过使用 **

delegatecall

** 函数调用另一个合约时，可能导致意外的行为或安全漏洞。**

delegatecall

** 函数允许合约在当前合约的上下文中执行另一个合约的代码，包括存储和状态。

攻击者可以利用 **

delegatecall

** 的特性来调用受攻击合约中的代码，使其在攻击者的控制下执行，并可能导致安全漏洞，如资金窃取、未经授权的访问等。

代码分析 :

pragma solidity ^0.8.0;

contract CallerContract {
    address public vulnerableContract;

    constructor(address _vulnerableContract) {
        vulnerableContract = _vulnerableContract;
    }

    function performDelegateCall(uint256 value) public {
        // 使用 delegatecall 调用受攻击合约中的代码
        (bool success, ) = vulnerableContract.delegatecall(
            abi.encodeWithSignature("withdraw(uint256)", value)
        );
        require(success, "Delegate call failed");
    }
}

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

    function withdraw(uint256 amount) public {
        require(balances[msg.sender] >= amount, "Insufficient balance");

        balances[msg.sender] -= amount;

        // 向用户转账
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
    }
}

在上述示例中，**

CallerContract

** 合约通过使用 **

delegatecall

** 调用 **

VulnerableContract

** 合约的 **

withdraw()

** 函数。然而，由于 **

delegatecall

** 执行的代码在 **

CallerContract

** 的上下文中执行，攻击者可以构造恶意的调用，使 **

withdraw()

** 函数在攻击者的控制下执行，从而导致资金窃取等安全问题

预防方案:

避免不必要的 **delegatecall**：只有在确实需要在合约之间共享存储和状态的情况下才使用 **delegatecall**，并且需要仔细审查和验证被调用合约的代码。
对被调用合约进行审计：在使用 delegatecall 调用其他合约之前，对被调用的合约进行全面的安全审计，确保其代码和逻辑没有漏洞和安全隐患。
谨慎处理用户输入：对于使用用户输入的函数，进行适当的输入验证和边界检查，以防止攻击者利用 delegatecall 调用中的潜在漏洞。
使用接口隔离和安全模式：将合约设计为更加模块化和接口隔离，减少合

2.5默认的可见性攻击

简述:

默认的可见性攻击（Default Visibility Attack）是指在 Solidity 中，如果在函数或状态变量的声明中未显式指定可见性修饰符，默认情况下它们的可见性为 **

internal

**，这可能导致安全漏洞。攻击者可以利用这种默认可见性来访问和修改应该是私有的函数或状态变量，从而导致合约行为异常或资金被盗

代码分析 :

pragma solidity ^0.8.0;

contract VulnerableContract {
    uint256 private balance;

    function setBalance(uint256 newBalance) {
        balance = newBalance;
    }
}

contract AttackerContract {
    VulnerableContract vulnerable;

    constructor(address _vulnerableContract) {
        vulnerable = VulnerableContract(_vulnerableContract);
    }

    function attack() public {
        // 调用受攻击合约的私有函数
        vulnerable.setBalance(1000);
    }
}

在上述示例中，**

VulnerableContract

** 合约中的 **

balance

** 变量被声明为私有的，但是没有显式指定可见性修饰符，默认情况下它的可见性为 **

internal

**。攻击者通过部署一个恶意合约 **

AttackerContract

**，在其中调用 **

VulnerableContract

** 的 **

setBalance()

** 函数，成功修改了 **

balance

** 变量的值，从而绕过了私有性的限制。

预防方案:

显式指定可见性修饰符：在声明函数和状态变量时，显式指定适当的可见性修饰符（**public、private、external** 或 **internal**）。这样可以确保可见性符合预期，并防止默认可见性带来的潜在风险。
将状态变量声明为私有：对于不需要在合约外部访问的状态变量，应将其声明为私有的（**private**）。这样可以限制对变量的访问，防止意外修改或泄露。
进行安全审计：对合约进行全面的安全审计，包括检查函数和状态变量的可见性，并确保没有意外的访问或修改。
遵循最小授权原则：合约应该遵循最小授权原则，只暴露必要的接口和功能。将不需要外部访问的函数或状态变量设为私有，以降低攻击面。
使用静态分析工具：使用静态分析工具来检查合约代码中的潜在漏洞，包括检查默认可见性是否会导致安全问题。

2.6、随机错觉攻击

简述:

随机性攻击（Randomness Attack）是指攻击者利用智能合约中的随机性不可预测或不安全的特性，以获取不当利益或扰乱合约的正常运行。在智能合约中，随机性通常用于生成随机数、选择随机事件或进行加密等操作。如果随机性不正确地实现或被攻击者预测到，就可能导致随机性攻击

随机性攻击可以具体表现为以下情况：

预测随机数：攻击者可能通过分析合约中的代码、交易数据或区块链状态来预测随机数的生成算法或种子，从而获得未来的随机数结果。
重放攻击：攻击者可能利用合约中的随机数生成算法的缺陷，通过重复发送相同的交易来获取相同的随机数结果，从而影响合约的正常运行或获取不当利益。
矿工攻击：攻击者可能与恶意矿工合谋，使其选择特定的区块或交易顺序，以影响随机数生成的结果或获取利益。

预防方案:

使用可验证的随机数源：选择使用可验证的随机数源，例如基于区块链的随机数合约或外部

2.7、外部智能合约引用攻击

简述:

外部智能合约引用攻击（External Smart Contract Reference Attack）是指攻击者通过利用智能合约与其他合约之间的交互来实施攻击。当一个合约在其代码中引用了外部合约地址，并调用了外部合约的函数时，攻击者可以通过替换外部合约的地址或利用外部合约中的漏洞来达到恶意目的。

攻击者可能利用外部智能合约引用攻击来进行以下行为：

窃取资金：攻击者替换外部合约地址，将合约调用重定向到自己的合约，从而窃取资金或获取未授权的访问权限。
修改状态：攻击者可能通过替换外部合约地址，修改合约的状态或参数，导致合约执行不符合预期的操作或产生意外的结果。
拒绝服务：攻击者可能通过替换外部合约地址或利用外部合约的漏洞，导致合约无法正常运行或陷入死循环，从而拒绝服务。

预防方案:

安全审计：进行全面的安全审计，包括合约的代码和逻辑。通过静态代码分析工具、审查代码和模拟攻击等方式，发现潜在的漏洞和安全

2.8、短地址/参数攻击攻击

简述:

（Short Address/Parameter Attack）是一种利用智能合约中短地址或参数处理不当的漏洞进行的攻击。当合约接收到的地址或参数长度不足时，智能合约在处理时可能会出现错误，导致意外行为或资金损失。

短地址攻击

针对以太坊智能合约中的地址处理进行的攻击。在以太坊中，地址长度是固定的，长度不足时会自动补齐为40个字符。攻击者可以利用这一特性，在调用合约时传递短地址，导致合约在处理地址时发生错误。

参数攻击

指利用智能合约中参数处理不当的漏洞进行的攻击。当合约接收到的参数长度不足时，智能合约可能会将后续字节解析为错误的参数或无效数据，从而导致合约执行不符合预期的操作或产生意外的结果。

预防方案:

完整性检查：在智能合约中，对接收的地址和参数进行完整性检查，确保其长度符合预期，并且不假定长度自动补齐或解析。
参数验证：在智能合约中，对接收的参数进行验证，确保其格式和内容符合预期，避免解析错误或执行异常操作。
防御性编程：编写合约时，采用防御性编程的原则

2.9、未检查的返回值攻击

简述:

未检查的返回值攻击（Unchecked Return Value Attack）是指在智能合约中调用其他合约或外部函数时，没有对返回值进行适当的检查或处理，从而导致安全漏洞的一种攻击。攻击者利用这个漏洞可以执行未经授权的操作、绕过权限检查、窃取资金或导致合约状态异常等问题。

代码分析 :

contract Victim {
    mapping(address => uint) public balances;
    
    function transfer(address payable recipient, uint amount) external {
        recipient.transfer(amount);
        balances[msg.sender] -= amount;
    }
}

contract Attacker {
    Victim victim;
    
    constructor(address victimAddress) {
        victim = Victim(victimAddress);
    }
    
    function attack() external {
        victim.transfer(address(this), 10);
        // 攻击者利用未检查返回值的漏洞，合约内部没有对transfer返回的布尔值进行检查
        // 这可能导致攻击者绕过合约中的余额更新，成功将资金转移到自己的合约地址
    }
}

在上述示例中，**

Victim

合约的

transfer

函数将以太币转账给指定的地址，并在成功转账后更新发送者的余额。然而，

Attacker

合约中的

attack

函数利用未检查返回值的漏洞，在调用

victim.transfer

**后没有对返回的布尔值进行检查。这意味着如果转账失败（例如，接收者是一个恶意合约），攻击者的合约仍然会更新余额，从而导致合约状态异常。

预防方案:

检查返回值：在调用其他合约或外部函数后，始终对返回的值进行适当的检查。对于转账操作，应该检查返回的布尔值，确保转账操作成功。
使用assert或require断言：在合约中使用assert或require语句来验证关键操作的返回值。这样可以确保操作执行成功，如果返回值为false，则会中止合约执行，防止继续执行不安全的操作。
使用安全的转账模式：在进行资金转移时，建议使用安全的转账模式，如**.call.value()或.transfer()**，这些模式会返回转账操作的结果，可以对返回值进行检查。
合理的异常处理：合约应该合理处理异常情况，并在必要时回滚操作，确保合约状态的一致性和安全性。通过谨慎地编写合约代码、进行充分的测试和审查，并遵循最佳实践和安全准则，可以减少未检查的返回值攻击的风险。

2.11、竞争条件/预先交易攻击

简述:

竞争条件/预先交易（Race Condition/Front-Running）是指在多个并发操作或交易中，执行顺序的不确定性导致攻击者能够利用这个时间窗口，在合约执行前或执行过程中进行恶意操作，从而获取非法利益或破坏合约的正常运行。竞争条件指的是多个操作之间的不确定性，而预先交易则是指攻击者在合约执行前提交交易以获取优势

代码分析 :

contract Auction {
    address public highestBidder;
    uint public highestBid;
    bool public auctionEnded;
    
    function bid() public payable {
        require(!auctionEnded, "Auction has ended.");
        require(msg.value > highestBid, "There is a higher bid.");
        
        if (highestBid != 0) {
            // 返回上一位出价者的金额
            if (!highestBidder.send(highestBid)) {
                revert("Failed to send funds to the previous bidder.");
            }
        }
        
        highestBidder = msg.sender;
        highestBid = msg.value;
    }
    
    function endAuction() public {
        require(!auctionEnded, "Auction has already ended.");
        require(msg.sender == highestBidder, "Only the highest bidder can end the auction.");
        
        auctionEnded = true;
        // 结束拍卖并将资金转移到拍卖合约的拥有者
        if (!payable(owner).send(highestBid)) {
            revert("Failed to send funds to the owner.");
        }
    }
}

在上述示例中，**

Auction

合约实现了一个拍卖功能，参与者可以通过调用

bid

函数进行出价，合约会记录最高出价者和最高出价。

endAuction

**函数用于结束拍卖并将资金转移到拥有者地址。

然而，这个合约存在竞争条件和预先交易的漏洞。

攻击者可以通过以下步骤进行攻击：

攻击者通过另一个地址预先提交一笔具有更高出价的交易。
在该交易尚未被确认之前，攻击者迅速调用**bid**函数，使用较低的出价，并在竞争条件下将自己设置为最高出价者。
一旦攻击者的交易被确认，合约执行**endAuction**函数，将资金转移到攻击者的地址。

通过这种方式，攻击者可以在竞争条件中战胜其他出价者并获取拍卖的资金

预防方案:

使用原子操作：合约中的关键操作应该是原子的，确保在执行过程中不会被中断或干扰。原子操作可以使用合适的锁机

2.12、拒绝服务攻击

简述:

智能合约拒绝服务（Smart Contract Denial of Service）是指攻击者通过恶意操作智能合约的方式，导致合约无法正常执行或消耗过多的计算资源，从而阻塞其他用户的交互或使合约无法完成预期的功能。这种攻击旨在破坏合约的正常运行，使其无法提供服务或执行相关操作

代码分析 :

contract Lottery {
    mapping(address => bool) public participants;
    
    function joinLottery() public {
        require(!participants[msg.sender], "You have already joined the lottery.");
        participants[msg.sender] = true;
        
        // 消耗大量计算资源的操作
        for (uint i = 0; i < 2**256; i++) {
            // 执行复杂的计算操作
        }
    }
}

在上述示例中，**

Lottery

合约实现了一个简单的抽奖功能，参与者可以通过调用

joinLottery

**函数加入抽奖。然而，在该函数中存在一个耗时很长的计算操作，使用了一个循环进行复杂的计算。如果攻击者调用该函数，并且该计算操作需要很长时间才能完成，那么合约将无法继续执行其他操作，导致其他用户无法加入抽奖或执行其他交互.

预防方案:

限制计算资源：在设计合约时，避免使用过多的计算资源或耗时很长的计算操作。确保合约中的计算逻辑能够在合理的时间范围内完成，以免被攻击者滥用。
使用Gas限制：在Solidity合约中，可以使用Gas来限制合约的计算资源消耗。通过设置合适的Gas限制和Gas价格，确保合约执行过程中消耗的资源是可控的。这可以防止攻击者通过执行耗时的计算操作来拒绝服务。
避免复杂的循环：尽量避免在合约中使用复杂、耗时的循环操作。如果必须使用循环，确保循环的迭代次数是可控的，并且不会导致合约无法继续执行其他操作。
安全审计和代码评估：对智能合约进行安全审计和代码评估，确保合约没有明显的安全漏洞或资源耗尽的风险。请专业的审计人员或安全专家进行合约审计，以发现并修复潜在的

2.13、时间戳攻击

简述:

时间戳攻击（Timestamp Attack）是一种利用智能合约中的时间戳信息不可信的攻击方式。智能合约中的时间戳通常由矿工在区块链上创建新区块时提供，攻击者可以通过操纵或利用时间戳信息来获得不当利益或破坏合约的预期行为

代码分析 :

contract Auction {
    uint public auctionEndTime;
    address public highestBidder;
    uint public highestBid;

    constructor(uint _biddingTime) {
        auctionEndTime = block.timestamp + _biddingTime;
    }

    function bid() public payable {
        require(block.timestamp < auctionEndTime, "Auction has ended.");

        if (msg.value > highestBid) {
            if (highestBid != 0) {
                // 返回上一位出价者的金额
                payable(highestBidder).transfer(highestBid);
            }
            highestBidder = msg.sender;
            highestBid = msg.value;
        }
    }

    function endAuction() public {
        require(block.timestamp >= auctionEndTime, "Auction has not ended yet.");
        require(msg.sender == highestBidder, "Only the highest bidder can end the auction.");

        // 结束拍卖并将资金转移到拍卖合约的拥有者
        payable(owner()).transfer(highestBid);
    }
}

在上述示例中，**

Auction

合约实现了一个简单的拍卖功能。合约的构造函数设置了拍卖结束的时间戳

auctionEndTime

，而

bid

函数允许参与者进行出价。

endAuction

**函数用于结束拍卖。

然而，攻击者可以通过以下方式进行时间戳攻击：

攻击者可以修改本地计算机的时间，以在其交易时提供早于实际时间的时间戳，从而延长拍卖时间。
攻击者可以利用矿工的时间戳操纵能力，使区块中的时间戳早于实际时间，以延长拍卖时间。

这些攻击方式可能导致拍卖在预期时间之后结束或被延长，给攻击者提供额外的出价机会。

预防方案:

校验时间戳的合理范围：在合约中对时间戳进行校验，确保其在合理的范围内。例如，检查时间戳是否在当前时间之前或之后的一定范围内，以防止过早或过晚的交易被接受。
避免仅依赖时间戳进行重要决策：在合约设计中，尽量避免仅仅依赖时间戳来进行重要的决策。考虑使用其他可信的数据源或合约状态来进行验证和决策。
安全审计和代码评估：对智能合约进行安全审计和代码评估，以发现潜在的安全漏洞或时间戳攻击的风险。请专业的审计人员或安全专家对合约进行审计，并根据其建议来增强合约的安全性。
外部调用的安全性：当与外部合约或预言机进行交互时，要确保这些合约或服务本身没有受到时间戳攻击的风险，并进行适当的安全检查和验证。

2.14、未初始化的存储指针攻击

简述:

未初始化的存储指针攻击（Uninitialized Storage Pointer Attack）是一种利用智能合约中未正确初始化存储指针的漏洞来实施攻击的方式。当合约中的存储指针被使用之前没有被初始化，攻击者可以利用这个未初始化的指针来读取或篡改合约存储中的数据，从而获得非法利益或破坏合约的预期行为

代码分析 :

contract Storage {
    address[] public data;

    function addToData(address _item) public {
        data.push(_item);
    }

    function removeData() public {
        delete data;
    }

    function getDataLength() public view returns (uint) {
        return data.length;
    }
}

在上述示例中，**

Storage

合约包含一个动态数组

data

，用于存储地址数据。合约提供了

addToData

函数用于向数组中添加元素，

removeData

函数用于删除数组中的所有数据，以及

getDataLength

**函数用于返回数组长度。

然而，如果在调用**

removeData

函数之后再次调用

addToData

函数，而没有重新初始化存储指针

data

，那么原来存储在

data

**数组中的数据可能仍然存在，且可以被攻击者利用。攻击者可以利用这个漏洞来读取或修改数组中的数据，即使在逻辑上已经被删除。

预防方案:

显式初始化存储指针：确保在使用存储指针之前，对其进行显式初始化。在使用动态数组、映射或其他复杂的数据结构时，务必在使用之前初始化存储指针。
规避重用存储指针：避免在删除或清空数据后，继续使用同一个存储指针来存储新的数据。在删除或清空数据后，应当重新初始化存储指针，确保新的数据不会受到未初始化指针的影响。
安全审计和代码评估：对智能合约进行安全审计和代码评估，以发现潜在的未初始化存储指针漏洞或其他安全风险。请专业的审计人员或安全专家对合约进行审计，并根据其建议来增强合约的安全性。
严格的代码测试：进行全面的代码测试，包括对存储指针的初始化和使用进行验证。确保在不同情况下合约的行为符合预期，并没有未初始化指针的问题

2.15、浮点和数据精度攻击

简述:

浮点和数据精度攻击（Floating-Point and Data Precision Attack）是一种利用智能合约中浮点数和数据精度处理不当而导致的漏洞攻击。在智能合约中，浮点数和数据精度的计算可能受限于计算机硬件和编程语言的特性，这可能导致计算结果的精度损失或不一致性。攻击者可以利用这些精度问题来获得不当利益或干扰合约的正常运行。

代码分析 :

contract Calculation {
    function divide(uint _numerator, uint _denominator) public pure returns (uint) {
        return _numerator / _denominator;
    }
}

在上述示例中，**

Calculation

合约包含一个

divide

**函数，用于执行两个无符号整数相除的操作。然而，在Solidity中，整数除法是向下取整的，即舍弃小数部分。这可能导致结果的精度损失，特别是当期望获得精确小数结果时。

攻击者可以利用这个精度问题来进行攻击，例如，通过使用一个极大的分母来导致整数除法的结果为零，从而获得不当利益

预防方案:

使用整数运算：尽量使用整数运算而不是浮点数运算来处理数值计算。整数运算可以提供更精确的结果，并减少由于浮点数精度问题引起的漏洞风险。
手动处理精度：对于需要使用浮点数或小数计算的情况，可以手动处理精度，例如使用整数表示小数，并在计算过程中保持精度。这可以通过将小数数值乘以某个倍数来转换为整数，并在需要时再进行逆转换。
使用安全库和算法：使用经过安全审计的数值计算库或算法来处理浮点数和数据精度。这些库和算法经过测试和优化，可以提供更可靠的数值计算结果，并减少精度问题的风险。
安全审计和代码评估：对智能合约进行安全审计和代码评估，特别关注数值计算的精度处理部分。请专业的审计人员或安全专家对合约进行审计，并根据其建议来增强合约的安全性

2.16、tx.origin 判定攻击

简述:

tx.origin 判定攻击是一种利用 Solidity 中的 **

tx.origin

** 属性进行攻击的漏洞。**

tx.origin

** 用于获取发送当前交易的原始地址，但它容易受到攻击，因为它不会考虑合约间的交互，只会返回交易的发起者地址，而不是当前调用合约的地址。攻击者可以利用这个属性来伪装为合约的原始调用者，以获得未授权的访问或执行某些操作

代码分析 :

contract Bank {
    address owner;

    constructor() {
        owner = msg.sender;
    }

    function withdraw() public {
        require(tx.origin == owner, "Only owner can withdraw funds");
        // 执行提款操作
    }
}

contract MaliciousContract {
    address attacker;

    constructor(address _attacker) {
        attacker = _attacker;
    }

    function callBankWithdraw(address _bank) public {
        Bank(_bank).withdraw();
    }

    function maliciousWithdraw(address _bank) public {
        // 伪装为合约的原始调用者进行提款操作
        Bank(_bank).withdraw();
    }
}

在上述示例中，**

Bank

** 合约允许只有合约的初始拥有者才能提款。它通过比较 **

tx.origin

** 和 **

owner

** 来验证调用者是否为合约的原始拥有者。然而，**

MaliciousContract

** 合约可以通过调用 **

callBankWithdraw

** 函数来正常执行提款操作，因为 **

tx.origin

** 仍然是 **

MaliciousContract

** 合约的原始调用者。然而，**

MaliciousContract

** 合约可以通过调用 **

maliciousWithdraw

** 函数伪装为合约的原始调用者进行提款操作，绕过了原始调用者的验证。

预防方案:

使用 msg.sender 进行身份验证：在合约中进行身份验证和权限控制时，始终使用 msg.sender 进行比较和验证，而不是使用 **tx.origin**。
限制对合约的调用权限：确保只有授权的合约可以调用敏感函数。可以通过在函数中添加 require(msg.sender == allowedContract) 来限制对函数的调用。
安全审计和代码评估：对智能合约进行安全审计和代码评估

2.17、签名伪造攻击（Signature Forgery Attack)

简述:

签名伪造攻击（Signature Forgery Attack）是一种利用数字签名系统中的漏洞，通过伪造签名来进行欺骗或执行未经授权的操作的攻击方式。数字签名是用于验证数据完整性和身份认证的重要机制，但在某些情况下，攻击者可能能够通过篡改或伪造签名来绕过验证，从而执行恶意操作。

代码分析 :

contract Auction {
    address public highestBidder;
    uint public highestBid;

    function bid(uint _bidAmount, bytes memory _signature) public {
        bytes32 message = keccak256(abi.encodePacked(_bidAmount));
        address signer = recoverSigner(message, _signature);

        require(_bidAmount > highestBid, "Bid amount is not higher than the current highest bid");
        require(signer == highestBidder, "Invalid signature");

        highestBidder = signer;
        highestBid = _bidAmount;
    }

    function recoverSigner(bytes32 _message, bytes memory _signature) internal pure returns (address) {
        require(_signature.length == 65, "Invalid signature length");

        bytes32 r;
        bytes32 s;
        uint8 v;

        assembly {
            r := mload(add(_signature, 32))
            s := mload(add(_signature, 64))
            v := byte(0, mload(add(_signature, 96)))
        }

        if (v < 27) {
            v += 27;
        }

        return ecrecover(_message, v, r, s);
    }
}

在上述示例中，**

Auction

** 合约是一个拍卖合约，允许用户进行出价操作。在 **

bid

** 函数中，用户需要传入出价金额和对出价金额的数字签名 **

_signature

**。合约会使用 **

_signature

** 进行验证，以确保签名来自当前的最高出价者。然而，如果攻击者能够伪造一个有效的签名，他们就可以通过伪造签名来执行出价操作，并将自己设为最高出价者。

预防方案:

使用安全的签名机制：确保使用安全的签名算法和机制进行数字签名，如使用标准的公钥/私钥对进行签名和验证。
强化签名验证逻辑：在验证签名时，进行严格的逻辑检查和验证，包括验证签名的长度、签名的有效性和正确性等。
使用合适的哈希算法：在生成消息哈希时，使用安全可靠的哈希算法，如 SHA-256，以增加签名的安全性。
限制对敏感操作的访问：对于需要进行签名验证的敏感操作，限制访问权限，确保只有授权的地址或角色才能执行操作

2.18、合约自毁攻击

简述:

合约自毁攻击（Contract Self-Destruct Attack）是一种利用 Solidity 中的 **

selfdestruct

** 函数来攻击合约的技术。攻击者通过滥用合约的自毁功能，将合约自身销毁并将合约余额发送到指定地址，从而导致合约的意外销毁和资金丢失。这种攻击通常发生在合约没有适当的权限验证和控制的情况下

代码分析 :

contract VulnerableContract {
    address owner;

    constructor() {
        owner = msg.sender;
    }

    function destroyContract(address payable _target) public {
        require(msg.sender == owner, "Only owner can destroy the contract");
        selfdestruct(_target);
    }
}

在上述示例中，**

VulnerableContract

** 合约具有一个 **

destroyContract

** 函数，只有合约的拥有者才能调用该函数。当合约的拥有者调用 **

destroyContract

** 函数时，合约会调用 **

selfdestruct

** 函数，并将合约的余额发送到指定的目标地址 **

_target

**，同时销毁合约本身。

预防方案:

限制自毁权限：在合约中进行自毁操作时，确保只有授权的地址或角色才能执行自毁操作。可以在自毁函数中添加权限检查逻辑，限制只有合适的账户或角色才能调用自毁函数。
尽量避免使用自毁功能：除非有明确的业务需求，尽量避免在合约中使用自毁功能。如果没有必要，可以删除自毁函数，以防止滥用。
审慎设计合约：在设计合约时，考虑合约的权限验证和访问控制机制。确保只有授权的地址或角色才能执行敏感操作，包括自毁操作。
多重签名机制：引入多重签名机制，需要多个授权的地址或角色才能执行自毁操作。这样可以增加攻击者获取足够权限的难度。
安全审计和代码评估：对智能合约进行安全审计和代码评估，发现潜在的漏洞和弱点，并修复它们。确保合约的安全性和可靠性

2.19、前导零攻击

简述:

前导零攻击（Front-Running Attack）是一种在区块链交易中利用信息不对称性的攻击方式。攻击者通过在交易中插入具有更高矿工费的交易，以获取交易的优先确认，并在其确认前将交易的信息用于自己的利益。这种攻击通常发生在交易信息公开之前，攻击者能够提前观察到交易信息，并利用这些信息执行有利于自己的操作，例如提前购买或卖出资产。

代码分析 :

contract VulnerableContract {
    address public owner;
    uint public price;

    constructor() {
        owner = msg.sender;
    }

    function setPrice(uint _newPrice) public {
        require(msg.sender == owner, "Only owner can set price");
        price = _newPrice;
    }

    function buy() public payable {
        require(msg.value >= price, "Not enough funds");

        // 执行购买逻辑
        // ...
    }
}

在上述示例中，**

VulnerableContract

** 合约有一个 **

setPrice

** 函数用于设置商品价格，并有一个 **

buy

** 函数用于购买商品。攻击者可以观察到调用 **

setPrice

** 的交易，并在其确认前提交一笔具有更高矿工费的交易来购买商品。这样攻击者就可以在其交易被确认之前，以较低价格购买商品

预防方案:

加密和隐私保护：使用加密技术和隐私保护措施来保护交易信息的机密性，减少信息泄露的可能性。
随机化操作：在敏感操作中引入随机因素，使攻击者无法预测操作结果。例如，在交易执行时引入随机延迟或价格微调，使攻击者无法准确预测执行结果。
使用合适的交易顺序：合约开发者可以使用适当的交易顺序来减少前导零攻击的风险。例如，可以使用交易队列或批处理机制来处理交易，以减少攻击者的机会。
使用可信任的中介方：如果存在可信任的中介方，可以考虑使用其服务来确保交易的公正性和安全性。中介方可以进行交易的协调和验证，减少前导零攻击的风险。
审慎设计合约：在设计合约时，要考虑安全性和防范前导零攻击的措施。避免过于依赖交易信息的可见性

2.20、双重花费攻击

简述:

双重花费攻击（Double Spending Attack）是指在区块链网络中，攻击者使用同一份数字资产或加密货币进行多次交易的攻击行为。攻击者试图通过快速发送两个或多个相互矛盾的交易，在网络中引入不一致的交易历史，从而欺骗系统确认多个交易并花费同一份资产。
双重花费攻击通常不是通过代码实现，而是在交易广播和区块链网络中进行的。攻击者会创建两个或多个相互冲突的交易，并尽可能快地将这些交易广播到网络中。攻击者希望能够引导网络的多个节点确认不同的交易，并使不一致的交易历史出现。

预防方案:

区块链确认：等待足够的区块链确认，以确保交易被确认并写入不可逆转的区块中。通常，等待多个区块的确认可以大大降低双重花费攻击的风险。
高级交易验证：在接受交易时，进行更多的验证步骤，例如检查输入交易是否已经被确认，或者检查交易的输入是否与之前的交易匹配。这样可以降低接受冲突交易的风险。
交易广播策略：选择合适的交易广播策略，例如将交易广播到具有良好连接和高可靠性的节点，以减少攻击者的影响力。
双花检测机制：实施双花检测机制，监测和分析交易历史，以发现任何可能的双重花费行为，并采取适当的措施，例如标记交易为无效或封锁相关地址。
防御性编程：在编写智能合约时，采用防御性编程的原则，确保合约逻辑对于双重花费攻击是安全的。这可能包括使用状态标记、锁定机制和适当的权限控制等。
参考其他区块链解决方案：一些特定的区块链技术提供了内置的双花检测和防御机制。在选择使用特定区块链平台或协议时，应考虑其安全性功能和双花攻击的防范措施。

二十、跨链攻击（Cross-Chain Attack）

简述:

跨链攻击（Cross-Chain Attack）是指在不同区块链之间进行的攻击行为。它涉及利用区块链之间的互操作性或脆弱性，以执行未经授权的操作、操纵交易或窃取资产。跨链攻击的目标是利用不同区块链之间的互联特性，从而获得非法利益。

跨链攻击通常不是通过单一的代码描述来实现的，因为它牵涉到多个区块链之间的互操作性。攻击者可能会利用多个智能合约或多个链上操作，以执行跨链攻击。具体的代码描述将取决于攻击者的目标和所涉及的区块链技术。

预防方案:

审慎选择跨链桥接协议：如果涉及使用跨链桥接协议来实现不同区块链之间的互操作性，确保选择经过审计和被广泛使用的可靠桥接协议。避免使用未经验证或存在安全问题的跨链桥接协议。
强化安全审计：对涉及跨链操作的智能合约进行安全审计，确保没有存在漏洞或安全隐患。这涉及对智能合约的逻辑、权限控制、输入验证等进行仔细检查和评估。
加强身份验证和授权机制：在跨链操作中，确保身份验证和授权机制的安全性和可靠性。使用多重签名、身份验证证书或其他身份验证方法来确保参与者的身份和权限。
安全通信和加密：在跨链通信中使用安全的通信协议和加密算法，以保护数据的机密性和完整性。确保通信通道的安全性，防止中间人攻击或数据篡改。
深入了解跨链技术：了解所使用的跨链技术的工作原理和安全机制，并遵循最佳实践。跨链技术的安全性高度依赖于实施的协议、算法和安全设计。
定期更新和维护：跨链技术和相关智能合约可能会不断发展和演进，要及时更新和维护系统，以纠正已知漏洞和提高系统的安全性。
安全性意识和教育：加强参与者的安全性意识和教育，提供关于跨链攻击的培训和信息，使他们能够识别和防范潜在的威胁

2.21、前向预测攻击

简述:

前向预测攻击（Front-Running Attack）是一种利用区块链交易顺序的信息不对称性进行的攻击方式。攻击者通过在知道其他用户的交易之前，故意在交易中插入具有更高矿工费的交易，以获得优先确认，并在其确认之前执行有利于自己的操作，从中获取利益。这种攻击利用了区块链的透明性和不可更改性。

代码分析 :

contract VulnerableContract {
    address public owner;
    uint public price;

    constructor() {
        owner = msg.sender;
    }

    function setPrice(uint _newPrice) public {
        require(msg.sender == owner, "Only owner can set price");
        price = _newPrice;
    }

    function buy() public payable {
        require(msg.value >= price, "Not enough funds");

        // 执行购买逻辑
        // ...
    }
}

在上述示例中，**

VulnerableContract

** 合约有一个 **

setPrice

** 函数用于设置商品价格，并有一个 **

buy

** 函数用于购买商品。攻击者可以观察到调用 **

setPrice

** 的交易，并在其确认之前提交一笔具有更高矿工费的交易来购买商品。这样攻击者就可以在其交易被确认之前，以较低价格购买商品，然后在确认之后将商品以更高的价格转售，从中获取利益

预防方案:

交易加密和隐私保护：使用加密技术和隐私保护措施来保护交易信息的机密性，减少信息泄露的可能性。
随机化操作：在敏感操作中引入随机因素，使攻击者无法预测操作结果。例如，在交易执行时引入随机延迟或价格微调，使攻击者无法准确预测执行结果。
使用交易队列或批处理：将交易放入队列或批处理中进行处理，以减少攻击者通过观察交易顺序来进行攻击的机会。
使用隐名交易：使用隐名交易技术，如使用隐名地址或混币服务，以降低攻击者识别和追踪交易的能力。
提高网络确认时间：等待足够的区块链确认，以增加交易的安全性。等待更多的确认时间可以减少前向预测攻击的风险。
使用零知识证明（Zero-Knowledge Proofs）：使用零知识证明技术来证明交易的有效性，而不需要透露具体交易细节，从而减少攻击者的信息获取能力。
分散化交易执行：采用去中心化交易执行机制，如使用智能合约或分布式交易协议，以减少中心化交易所等集中化交易平台的操纵和干扰

2.22、委托投票攻击（Delegated Voting Attack）

简述:

委托投票攻击（Delegated Voting Attack）是指在一个委托投票系统中，攻击者通过控制或欺骗其他参与者的投票权来操纵选举结果。委托投票系统允许参与者将自己的投票权委托给其他人来代表自己进行投票，攻击者可以利用这一特性来获取更多的投票权或操纵选举结果。

代码分析 :

contract VotingSystem {
    mapping(address => uint) public votes;

    function delegateVote(address _delegate) public {
        require(_delegate != msg.sender, "Cannot delegate to yourself");

        // 委托投票
        votes[_delegate] += votes[msg.sender];
        votes[msg.sender] = 0;
    }

    function vote(uint _amount) public {
        require(_amount > 0, "Invalid vote amount");

        // 进行投票
        votes[msg.sender] += _amount;
    }
}

在上述示例中，**

VotingSystem

** 合约实现了一个简单的委托投票系统。参与者可以通过调用 **

delegateVote

** 函数来委托自己的投票权给其他地址。攻击者可以利用这一特性来获取更多的投票权，例如通过诱导其他参与者将投票权委托给自己

预防方案:

限制委托投票权：限制委托投票的范围和次数，确保参与者不能过度委托或将投票权委托给不可信任的地址。设定委托投票的规则和限制，以确保系统的公正性和安全性。
透明的投票机制：确保投票过程的透明度，使所有参与者能够查看和验证投票结果。提供公开的投票记录和投票结果，以便进行审计和验证。
身份验证和授权：采用身份验证和授权机制，确保只有合法的参与者能够参与投票。使用加密技术和数字身份验证来确保投票者的身份和投票权的真实性。
投票权分配的公平性：确保投票权的分配是公平和合理的，避免投票权过度集中在少数人手中。采用分权机制和投票权平衡的策略，以减少操纵选举结果的可能性。
安全审计和代码评估：对委托投票系统进行安全审计和代码评估，发现潜在的漏洞和弱点，并修复它们。确保系统的安全性和可靠性。
教育和意识提高：提供有关委托投票攻击的教育和意识提高，使参与者了解攻击的风险和防范措施。提供投票指南和安全建议，以帮助参与者做出明智的投票决策。

2.23、闪电贷攻击（Flash Loan Attack）

简述:

闪电贷攻击（Flash Loan Attack）是一种利用闪电贷机制进行的攻击方式。闪电贷是一种特殊类型的智能合约贷款，允许用户在同一交易中借款和还款，而无需提供任何抵押品。攻击者利用这一特性，在同一区块内执行多个操作，并在没有足够的资金支持的情况下进行操纵或攻击。

闪电贷攻击通常不是通过单一的代码描述来实现的，而是通过多个交易和合约操作组合而成。攻击者可能会借用闪电贷来进行以下操作：

借入大量资金并在同一交易中进行多个操作，如操纵价格、攻击合约或执行其他有利于自己的操作。
利用价格操纵或交易撮合机制，在闪电贷期间利用价格差异来获取利润。
在借款和还款之间进行操纵或恶意行为，如更改交易状态或利用合约漏洞。

预防方案:

强化智能合约安全性：审计和评估智能合约代码，确保没有潜在的漏洞和安全隐患。遵循最佳实践，包括输入验证、安全的资金管理和权限控制等，以减少攻击风险。 - 限制闪电贷条件：引入合适的限制和条件，以确保闪电贷只能用于合法和合理的操作。例如，要求借款者在借款和还款之间经过一定时间的间隔，或者限制闪电贷的数量和频率。- 价格操纵监测：实施监测和检测机制，以监控市场价格和交易活动。及时发现和干预异常或潜在的价格操纵行为，以减少攻击者利用价格差异进行攻击的机会。- 多签名机制：在闪电贷和相关交易中使用多签名机制，要求多个授权的地址或角色批准交易的执行。这样可以增加攻击者获取足够权限的难度。- 加密和隐私保护：使用加密技术和隐私保护措施来保护交易和借贷的机密性和隐私性。减少敏感信息的泄露和攻击者的信息获取能力。- 智能合约审核和平台选择：选择经过审计和有良好声誉的智能合约平台和借贷平台，以减少潜在的攻击风险。选择经过安全审计的智能合约和合规的借贷平台。- 教育和意识提高：提供有关闪电贷攻击的教育和意识提高，使用户和平台参与者了解攻击的风险和防范措施。提供安全建议和最佳实践，以帮助用户做出明智的决策

总结

要预防这些攻击，需要采取一系列安全措施。包括但不限于：

审计智能合约代码，确保没有漏洞和安全隐患。
限制合约权限和访问控制，确保只有授权的用户可以执行关键操作。
进行输入验证和边界检查，确保输入数据的有效性和安全性。
使用适当的加密和安全协议，保护数据和通信的机密性。
遵循最佳实践和安全编码准则，如避免使用过时的函数、避免硬编码密码等。
定期更新和维护合约，修复已知漏洞和安全问题。

通过深入了解这些攻击类型，并采取适当的预防措施，你可以提高Solidity智能合约的安全性，并更好地保护用户资产和系统的安全性

如有其他补充或者交流,欢迎大家评论,或者私我luo425116243.

标签：智能合约安全

本文转载自: https://blog.csdn.net/qq_33842966/article/details/131610182
版权归原作者 Zeke Luo 所有，如有侵权，请联系我们删除。

Solidity智能合约安全指南：预防已知攻击的关键.

文章目录

前言

一、攻击类型:

2.1重入攻击

2.2、算术溢出攻击

2.3意外之财攻击

2.4 Delegatecall攻击

2.5默认的可见性攻击

2.6、随机错觉攻击

2.7、外部智能合约引用攻击

2.8、短地址/参数攻击攻击

2.9、未检查的返回值攻击

2.11、竞争条件/预先交易攻击

2.12、拒绝服务攻击

2.13、时间戳攻击

2.14、未初始化的存储指针攻击

2.15、浮点和数据精度攻击

2.16、tx.origin 判定攻击

2.17、签名伪造攻击（Signature Forgery Attack)

2.18、合约自毁攻击

2.19、前导零攻击

2.20、双重花费攻击

二十、跨链攻击（Cross-Chain Attack）

2.21、前向预测攻击

2.22、委托投票攻击（Delegated Voting Attack）

2.23、闪电贷攻击（Flash Loan Attack）

总结

发表评论

“Solidity智能合约安全指南：预防已知攻击的关键.”的评论:

关于作者

overfit同步小助手

相关阅读

文章导航