JWT 安全性相关问题

1、jwt如何防止重放攻击？

重放攻击定义

重放攻击（英语：replay attack，或称为回放攻击）是一种恶意或欺诈的重复或延迟有效数据的网络攻击形式。 这可以由发起者或由拦截数据并重新传输数据的对手来执行，这可能是通过IP数据包替换进行的欺骗攻击的一部分。 这是“中间人攻击”的一个较低级别版本。
这种攻击的另一种描述是： “从不同上下文将消息重播到安全协议的预期（或原始和预期）上下文，从而欺骗其他参与者，致使他们误以为已经成功完成了协议运行。”

解决方案 

加时间戳

首先，常见的解决方案就是在请求报文里面加上时间戳，并参与加签。

当接收方收到报文，经过验签之后。

首先第一个事儿就是拿着请求中的时间戳字段和本地时间做个对比。

如果时间误差在指定时间，比如 60 秒内，那么认为这个请求是合理的，程序可以继续处理。

为什么要有一个时间容错范围，能理解吧？

因为报文的传输、解密、验签是需要时间，不能假设我这一秒发出去，下一秒服务端就收到了。

所以，得有时间容错范围。

但是这个容错范围又带来了另外一个问题。

不能完全避免重放攻击。

至少时间容错范围内，比如 60 秒，重发过来的请求，服务端认为是有效的。

那么怎么办呢？

加随机串

换个思路，我们在请求报文里面加个随机串，然后让它参与加签。

接受方收到报文，验签之后，把随机串拿出来，来判断一下这个随机串是否已经处理过了。比如判断一下是否存在于 Redis 里面。

当请求再次重放过来的时候，一看：嚯，好家伙，这个随机串已经被用过了呀，不处理了。

在这个情况下，随机串就得保证唯一性了，还得历史全局唯一。

因为你指不定哪天就收到一个几天前的被重放过来的请求。

确实是解决了请求重放的问题，但是弊端也很明显：历史全局唯一。</