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