以太坊智能合约安全之重放攻击

什么是重放攻击？

1.顾名思义，重复的会话请求就是重放攻击。

2.可能是因为用户重复发起请求，也可能是因为请求被攻击者获取，然后重新发给服务器。

重放攻击的危害

请求被攻击者获取，并重新发送给认证服务器，从而达到认证通过的目的。

我们可以通过加密，签名的方式防止信息泄露，会话被劫持修改。但这种方式防止不了重放攻击。

为什么会出现重放攻击？

在比特币的某次硬分叉后，出现了一条新链，其代币为 BCH。比特币硬分叉后，新链与原链是拥有相同的交易数据、地址、私钥、交易方式。你在硬分叉之前的一种币，会因为分叉而变成两种，即原有的 BTC 和等额的 BCH。您只需要下载 BCH 对应的钱包，并且把原 BTC 的钱包私钥导入，即可得到等额的 BCH 。

同时，如果你在没有解决重放攻击问题之前，在自己钱包里把分叉前的一个 BTC 转到一个地址A上，有趣的事就发生了，你在 BCH 钱包内对应的一个 BCH 也会被转入到地址 A 里面去。因为你在分叉前的币，会自动被分叉后的两条链都承认是合法的。只要你发起一笔交易，另一笔会被同步到比特币网络中去，然后被矿工打包处理，该交易生效，这就是重放攻击！

智能合约中比较特殊的委托概念：

在资产管理体系中，常有委托管理的情况，委托人将资产给受托人管理，委托人支付一定的费用给受托人。这个业务场景在智能合约中也比较普遍。

这里举例子为transferProxy函数，该函数用于当user1转token给user3，但没有eth来支付gasprice，所以委托user2代理支付，通过调用transferProxy来完成。

上述代码nonce值可以被预测，而其他变量不变的情况下，可以通过重放攻击来多次转账。

影响范围

截止2018年9月5日，发现了18个存在重放攻击隐患问题的合约代码，其中16个仍处于交易状态，其中交易量最高的10个合约情况如下：

修复方式

合约中如果涉及委托管理的需求，应注意验证的不可复用性，避免重放攻击。其中主要的两点在于：

1.避免使用transferProxy函数。采用更靠谱的签名方式签名。

2.nonce机制其自增可预测与这种签名方式违背，导致可以被预测。尽量避免nonce自增。

重放攻击的防御

1）时间戳验证

请求时加上客户端当前时间戳，同时签名（签名是为了防止会话被劫持，时间戳被修改），服务端对请求时间戳进行判断，如超过5分钟，认定为重放攻击，请求无效。

时间戳无法完全防止重放攻击。

2)序号

顾名思义，在客户端和服务端通讯时，先定义一个初始序号，每次递增。这样，服务端就可以知道是否是重复发送的请求。

3)挑战与应答的方式

我们一般采用这种方式来防御重放攻击。

客户端请求服务器时，服务器会首先生成一个随机数，然后返回给客户端，客户端带上这个随机数，访问服务器，服务器比对客户端的这个参数，若相同，说明正确，不是重放攻击。

这种方式下，客户端每次请求时，服务端都会先生成一个挑战码，客户端带上应答码访问，服务端进行比对，若挑战码和应答码不对应，视为重放攻击。

4)Https防重放攻击

对于https，每个socket连接都会验证证书，交换密钥。攻击者截获请求，重新发送，因为socket不同，密钥也不同，后台解密后是一堆乱码，所以https本身就是防止重放攻击的，除非能复制socket，或者进行中间人攻击。

总结：

由于智能合约代码公开透明的特性，加上这类问题比较容易检查出，一旦出现就会导致对合约的毁灭性打击，所以大部分合约开发人员都会注意到这类问题。但在不容易被人们发现的未公开合约中，或许还有大批潜在的问题存在。建议所有的开发者重新审视自己的合约代码，检查是否存在编码安全问题，避免不必要的麻烦或严重的安全问题。

（编译：区块链安全档案，内容来自链得得内容开放平台“得得号”；本文仅代表作者观点，不代表链得得官方立场）