Soildity安全之交易顺序依赖问题

Soildity作为编写智能合约的语言，已经被广泛的应用。但同时，开发者和用户也得到了惨痛的教训，智能合约的安全问题层出不穷。因此，我们总结了一些常见的Solidity安全问题。前车之鉴，后车之师，希望后来者能有所警惕。

交易顺序依赖

一笔交易被传播出去并被矿工认同包含在一个区块内需要一定的时间，如果一个攻击者在监听到网络中对应合约的交易，然后发出他自己的交易来改变当前的合约状态，例如对于悬赏合约，减少合约回报，则有一定几率使这两笔交易包含在同一个区块下面，并且排在另一个交易之前，完成攻击。这意味着，如果某个用户正在揭示拼图或其他有价值的秘密的解决方案，恶意用户可以窃取解决方案并以较高的费用复制其交易，以抢占原始解决方案。

攻击模型：

1.攻击者提交一个有奖竞猜合约，让用户找出这个问题的解，并允诺给予丰厚的奖励。
2.攻击者提交完合约后就持续监听网络，观察是否有人提交了答案的解。
3.有人提交答案，此时提交答案的交易还未确认，攻击者就马上发起一个交易降低奖金的数额使之无限接近0。
4.攻击者提供较高的Gas,是的自己的交易先被矿工处理。
5.矿工先处理提交答案的交易时，答案提交者所获得的奖励将变得极低，攻击者就能几乎免费的获得正确答案。

相关事件

ERC20

ERC20标准是相当知名的关于Ethereum建设令牌。这个标准有一个潜在的超前漏洞，这个漏洞是由于这个approve()功能而产生的。

​该标准规定的approve()功能如下：

攻击情景如下：

1.Alice允许Bob通过调用approve方法传输N个Alice的令牌（N> 0）在Token智能合约上传递Bob的地址和N作为方法参数；

2.过了一段时间，Alice决定从N改为M（M> 0）的数量Alice的令牌Bob被允许转移，所以她再次呼叫批准方法，这个时间传递Bob的地址和M作为方法参数；

3. Bob在开采并快速发送之前注意到Alice的第二笔交易调用transferFrom方法转移N 个Alice的令牌的事件；

4.如果Bob的交易将在Alice交易之前执行，那么Bob将会执行成功转移N个 Alice的代币并获得转移另一次M个代币的能力；

5.在Alice注意到出现问题之前，Bob调用了transferFrom方法，这次转移M个爱丽丝的代币。

总结：

对于交易顺序依赖这个问题，如果智能合约的开发者不小心，这种情况会导致实际的和毁灭性的前端攻击。因此开发者要综合运用gas限制以及披露方案，从而保障交易信息在合理的环节以合理的形式呈现。

（作者：曲速未来安全区，本文仅代表作者观点，不代表链得得官方立场）