智能合约漏洞攻击事件_智能合约百科全书攻击漏洞

智能合约漏洞攻击事件

Applications on Ethereum manage financial value, making security absolutely crucial. As a nascent, experimental technology, smart contracts have certainly had their fair share of attacks.

以太坊上的应用程序管理财务价值，因此安全性绝对至关重要。 作为一种新兴的实验性技术，智能合约当然具有应有的攻击份额。

To help prevent further attacks, I’ve constructed a list of nearly all known attacks and vulnerabilities. Though this list may cover known attacks, new exploits are still being discovered regularly, and, as such, this should only be the beginning of your research into smart contract security as an engineer.

为了帮助防止进一步的攻击，我构建了几乎所有已知攻击和漏洞的列表。 尽管此列表可能涵盖已知的攻击，但仍会定期发现新的攻击，因此，这仅是您以工程师身份开始研究智能合约安全的开始。

This list can also be found on GitHub.

该列表也可以在GitHub上找到 。

进攻 (Attacks)

In this section, we’ll look at known attacks that can be used to exploit smart contract vulnerabilities.

在本节中，我们将研究可用于利用智能合约漏洞的已知攻击。

前端运行又称为事务排序依赖性 (Front-running aka transaction-ordering dependence)

The University of Concordia considers front-running to be “a course of action where an entity benefits from prior access to privileged market information about upcoming transactions and trades.” This knowledge of future events in a market can lead to exploitation.

康科迪亚大学认为，“领先是一种行动，实体可以从事先获得的有关即将发生的交易和交易的特权市场信息中受益”。 对市场中未来事件的了解可以导致剥削。

For example, knowing a very large purchase of a specific token is going to occur, a bad actor can purchase that token in advance and sell the token for a profit when the oversized buy order increases the price.

例如，如果知道将要大量购买特定代币，那么坏演员可以提前购买该代币并在超大买单增加价格时出售该代币以获利。

Front-running attacks have long been an issue in financial markets, and due to blockchain’s transparent nature, the problem is coming up again in cryptocurrency markets.

长期以来，前端攻击一直是金融市场中的一个问题，由于区块链的透明性，该问题在加密货币市场中再次出现。

Since the solution to this problem varies on a per-contract basis, it can be hard to protect against. Possible solutions include batching transactions and using a precommit scheme (i.e., allowing users to submit details at a later time).

由于此问题的解决方案因合同而异，因此很难避免。 可能的解决方案包括批处理事务并使用预提交方案(即，允许用户稍后提交详细信息)。

限制气体的DoS (DoS with block gas limit)

In the Ethereum blockchain, the blocks all have a gas limit. One of the benefits of a block gas limit is it prevents attackers from creating an infinite transaction loop, but if the gas usage of a transaction exceeds this limit, the transaction will fail. This can lead to a DoS attack in a couple different ways.

在以太坊区块链中，所有区块都有瓦斯限制。 限制气体限制的好处之一是，它可以防止攻击者创建无限的事务循环，但是，如果事务的气体使用量超过此限制，则事务将失败。 这可能以几种不同的方式导致DoS攻击 。

Unbounded operations

无限运营

A situation in which the block gas limit can be an issue is in sending funds to an array of addresses. Even without any malicious intent, this can easily go wrong. Just by having too large an array of users to pay can max out the gas limit and prevent the transaction from ever succeeding.

限制气体限制可能是一个问题，就是将资金发送到一系列地址。 即使没有恶意，这也很容易出错。 只是因为有太多的用户来支付，才可以最大限度地提高用气限额，并阻止交易成功。

This situation can also lead to an attack. Say a bad actor decides to create a significant amount of addresses, with each address being paid a small amount of funds from the smart contract. If done effectively, the transaction can be blocked indefinitely, possibly even preventing further transactions from going through.

这种情况也可能导致攻击。 假设一个坏演员决定创建大量地址，每个地址都从智能合约中获得少量资金。 如果有效完成，则可以无限期地阻止交易，甚至可能阻止进一步的交易进行。

An effective solution to this problem would be to use a pull-payment system over the current push-payment system. To do this, separate each payment into its own transaction and have the recipient call the function.

解决此问题的有效方法是在当前的推付式支付系统上使用预付式支付系统。 为此，请将每笔付款分成自己的交易，然后让收款人调用该功能。

If, for some reason, you really need to loop through an array of unspecified length, at least expect it to potentially take multiple blocks, and allow it to be performed in multiple transactions — as seen in this example:

如果出于某种原因，如果您确实确实需要遍历一个未指定长度的数组，则至少希望它可能占用多个块，并允许它在多个事务中执行-如以下示例所示：

Consensys Consensys的示例

Block stuffing

块馅

In some situations, your contract can be attacked with a block gas limit even if you don’t loop through an array of unspecified length. An attacker can fill several blocks before a transaction can be processed by using a sufficiently high gas price.

在某些情况下，即使您未遍历未指定长度的数组，您的合同也可能受到限制气体的攻击。 攻击者可以通过使用足够高的汽油价格来填充交易之前的几个区块。

This attack is done by issuing several transactions at a very high gas price. If the gas price is high enough and the transactions consume enough gas, they can fill entire blocks and prevent other transactions from being processed.

这种攻击是通过以很高的汽油价格发行几笔交易来完成的。 如果天然气价格足够高，并且交易消耗了足够的天然气，它们会填满整个区块并阻止其他交易被处理。

Ethereum transactions require the sender to pay gas to disincentivize spam attacks, but in some situations, there can be enough incentive to go through with such an attack. For example, a block stuffing attack was used on a gambling Dapp, Fomo3D. The app had a countdown timer, and users could win a jackpot by being the last to purchase a key — except every time a user bought a key, the timer would be extended. An attacker bought a key then stuffed the next 13 blocks in a row so they could win the jackpot.

以太坊交易需要发件人付费以抑制垃圾邮件攻击，但在某些情况下，可以有足够的动机来进行此类攻击。 例如，在赌博Dapp Fomo3D上使用了块填充攻击。 该应用程序具有倒数计时器，通过最后一次购买钥匙，用户可以赢得大奖-除非用户每次购买钥匙，否则计时器都会延长。 攻击者购买了一把钥匙，然后连续塞满了接下来的13个区块，这样他们才能赢得大奖。

To prevent such attacks from occurring, it’s important to carefully consider whether it’s safe to incorporate time-based actions in your application.

为了防止发生此类攻击，请务必仔细考虑将基于时间的操作合并到应用程序中是否安全。

带有(意外)还原的DoS (DoS with (unexpected) revert)

DoS (denial-of-service) attacks can occur in functions when you try to send funds to a user and the functionality relies on that fund transfer being successful.

当您尝试向用户发送资金并且功能依赖于成功进行资金转移时，DoS(拒绝服务)攻击可能会在功能中发生。

This can be problematic in the case that the funds are sent to a smart contract created by a bad actor, since they can simply create a fallback function that reverts all payments.

在将资金发送到由不良参与者创建的智能合约的情况下，这可能会出现问题，因为它们可以简单地创建一个可退回所有付款的后备功能。

For example:

例如：

Consensys Consensys的示例

As you can see in this example, if an attacker bids from a smart contract with a fallback function reverting all payments, they can never be refunded, and, thus, no one can ever make a higher bid.

如本例所示，如果攻击者通过具有回退功能的智能合约出价来还原所有付款，则它们将永远无法退款，因此，没有人可以提出更高的出价。

This can also be problematic without an attacker present. For example, you may want to pay an array of users by iterating through the array, and, of course, you’d want to make sure each user is properly paid. The problem here is if one payment fails, the function is reverted and no one is paid.

如果没有攻击者在场，这也可能会带来问题。 例如，您可能希望通过遍历数组来向用户支付费用，当然，您要确保每个用户都得到了适当的支付。 这里的问题是，如果一次付款失败，该功能将被还原并且没有人付款。

Consensys Consensys的示例

An effective solution to this problem would be to use a pull-payment system over the current push-payment system. To do this, separate each payment into its own transaction, and have the recipient call the function.

解决此问题的有效方法是在当前的推付式支付系统上使用预付式支付系统。 为此，请将每笔付款分成自己的交易，然后让收款人调用该功能。

Consensys Consensys的示例

强制将以太币发送给合同 (Forcibly sending Ether to a contract)

Occasionally, it’s unwanted for users to be able to send Ether to a smart contract. Unfortunately for these circumstances, it’s possible to bypass a contract fallback function and forcibly send Ether.

有时候，用户不需要将Ether发送到智能合约。 不幸的是，在这些情况下，可以绕过合同后备功能并强制发送以太坊。

Consensys Consensys的示例

Though it seems like any transaction to the Vulnerable contract should be reverted, there are actually a couple ways to forcibly send Ether.

虽然似乎应该撤销与弱势合同的任何交易，但实际上有两种方法可以强制发送以太坊。

The first method is to call the selfdestruct method on a contract with the Vulnerable contract address set as the beneficiary. This works because selfdestruct will not trigger the fallback function.

第一种方法是在以“易受攻击的合同”地址设置为受益人的合同上调用“ selfdestruct方法。 这是selfdestruct因为selfdestruct不会触发后备功能。

Another method is to precompute a contra