如图，重放攻击，这题我真的在面试的时候遇到过，两次。
印象比较深的是第一次遇到这个面试题的时候，也是第一次听到“重放攻击”这个词的时候，一脸蒙蔽，于是我就连蒙带猜的，朝着接口幂等性的方向去答了。
结果就凉了。
要回答怎么防止重放攻击，那么我们得知道啥是重放攻击。
学术上的解释是这样的：
重放攻击（英语：replay attack，或称为回放攻击）是一种恶意或欺诈的重复或延迟有效数据的网络攻击形式。 这可以由发起者或由拦截数据并重新传输数据的对手来执行，这可能是通过IP数据包替换进行的欺骗攻击的一部分。 这是“中间人攻击”的一个较低级别版本。
这种攻击的另一种描述是： “从不同上下文将消息重播到安全协议的预期（或原始和预期）上下文，从而欺骗其他参与者，致使他们误以为已经成功完成了协议运行。”
举个简单的例子：
我们程序员日夜操劳的，在按摩店里面办个卡，偶尔去洗个脚放松一下不过分吧。
有一天，我去洗脚的时候对着店员说：给我安排一个 168 价位的，要小伙子啊，按着比较带劲儿，我的卡号是 88888888。
然后我在前台签上了自己的名字，店员就安排了一个精壮的小伙子给我按摩。
没想到我们的对话被其他人听到了，于是他也给店员说：给我安排一个 168 价位的，要小伙子啊，按着比较带劲儿，我的卡号是 88888888。
还模仿了我的签名，在前台签字。
把之前的、正常的请求再次发送，这就是重放攻击。
有的朋友就会说了：我的接口是加签的，应该没问题吧？
你加签咋了？
我没有动你的报文，所以你也可以正常验签呀。
我不仅抄你报文里面的正常字段，报文里面的签名我也抄全乎了。
所以，接收方接到报文之后能正常验签。
没有任何毛病。
有的朋友还会说了：我的接口是有加密的，应该没问题吧？
看来还是不懂重放攻击的基本原理。
你加密咋了？
反正我截取到了你的报文，虽然你报文加密了，我看起来是一段乱码，但是我也不需要知道你报文的具体内容呀，直接重发就完事了。
还是前面的例子。
假设我去洗脚的时候对着店员说：天王盖地虎。
被旁边的人听到了，他根本就不知道“天王盖地虎”是啥。
但是他看到了我说了这句话之后，就被安排了一个 168 元的技术服务。
于是他也对店员说：天王盖地虎。
也能被安排。
所以，别人根本就不需要知道你报文的具体含义。
只要我再次发给你，你进行解密操作，发现能解密。
能解密说明暗号对上了。
所以，虽然报文是加密、加签传输的，对于防止请求重放，并没有什么卵用。
加密加签
来，说解决方案之前，我们先明确两个概念：加密和加签。
字面意思不解释了，大家都知道，说说目的。
加密的目的：为了保证传输信息的隐私性，不被别人看到传输的具体内容，只能让接收方看到正确的信息。
加签的目的：消息接收方验证信息是否是合法的发送方发送的，确认信息是否被其他人篡改过。
不管是加密还是加签，都涉及到公私钥。
记住了：公钥加密、私钥加签。
简单的说一下原理。
发送方有这样三样东西：自己的私钥、自己的公钥、接收方的公钥。
接收方有这样三样东西：自己的私钥、自己的公钥、发送方的公钥。
中间人有这样两样东西：接收方的公钥、发送方的公钥。
为什么是公钥加密呢？
来个反证法嘛。
假设消息发送方用自己的私钥加密。然后消息被中间人拦截到了，因为他有发送方的公钥，那么中间人就可以用公钥对消息进行解密，获取明文报文，这样达不到加密的目的。
所以，正确的操作应该是用接收方的公钥加密，这样就算消息被中间人拦截到了，他也没有接收方的私钥呀，解不了密，看不到明文。
为什么是私钥加签呢？
同样，反证法。
假设消息发送方，用接收方的公钥加签。如果消息被中间人拦截到了，巧了，我也有接收方的公钥。咔一下，直接把消息一改，然后也拿着接收方的公钥加签，发过去了。
这样的加签是没有意义的。
因此，要用自己的私钥加签，就算被拦截，中间人没有私钥，修改报文之后，搞不了签名，也就没啥卵用。
前面说了，对于重放攻击，截取到的内容是不是加密都无所谓。因为我根本不需要你们在说什么，我只需要把拦截下来的请求一遍遍的重发就行了。
所以，重要的是加签和验签。
如果你能修改报文，并且重新加签，那就不叫重放攻击了，那就叫做中间人攻击了。
其实重放攻击也是“中间人攻击”的一个较低级别版本。
啥是中间人攻击呢？
我去洗脚的时候对着店员说：给我安排一个 168 价位的，要小伙子啊，按着比较带劲儿，我的卡号是 88888888。
对话被偷听到了，中间人对店员说：给我安排一个 1999 价位的，要小姑凉啊，按摩手法好一点的，我的卡号是 88888888。
篡改报文，这是中间人攻击。
本文主要聚焦于重放攻击的解决方案。
经过前面的分析，我们知道要解决重放攻击，就是想着怎么在参与签名的字段里面搞事情。
能想到这里，就比较好回答这个问题了。
如果是从数据加密角度回答这个问题的同学，可以回去等通知了。
另外，说到加密了，大家都会想到 HTTPS 数据加密。
所以，当面试官问你：HTTPS数据加密是否可以防止重放攻击？
答：否，加密可以有效防止明文数据被监听，但是却防止不了重放攻击。
接下来，我们看看解决方案。
解决方案
加时间戳
首先，常见的解决方案就是在请求报文里面加上时间戳，并参与加签。
当接收方收到报文，经过验签之后。
首先第一个事儿就是拿着请求中的时间戳字段和本地时间做个对比。
如果时间误差在指定时间，比如 60 秒内，那么认为这个请求是合理的，程序可以继续处理。
为什么要有一个时间容错范围，能理解吧？
因为报文的传输、解密、验签是需要时间，不能假设我这一秒发出去，下一秒服务端就收到了。
所以，得有时间容错范围。
但是这个容错范围又带来了另外一个问题。
不能完全避免重放攻击。
至少时间容错范围内，比如 60 秒，重发过来的请求，服务端认为是有效的。
那么怎么办呢？
