重放攻击的一点想法

http请求是短连接 每次有请求接入  服务器都要重新核实一遍 请求里面用户的身份信息，而这个往往是通过浏览器的cookie来实现的  目前好像这个是 各种五花八门 登录，实现b/s会话的基础  什么单点登录  ，oauth2.0都是围绕这个在做事 只是组件数量和 过滤器多少 过滤条件 多少的问题。

重发攻击 说的简单点 就是把你这个请求的数据包 给抓下来 然后 在次提交一遍 （当然 这里面 肯定还会做手脚）这个比什么crsf以及xss攻击要厉害的多，另外还有一点 因为在浏览器里可以看到 前段所有的东西 所以 不管你怎么 加时间戳 加头什么的  只要可以拿到你的前端提交请求的代码 （这部分一般是会做加密的）任你怎么玩 别人 都可以看的一清二楚，这就是很多数据验证 要放在s端的原因。

因此要解决这个重放攻击 重点 应该放在后端 而不是在前端

s端 每次有请求进来 都会接受  当然重放攻击的请求 也会接受，要解决重放攻击 需要解决两件事：

       1. s端需要知道 这个浏览器是由用户发出的

       2. 再次发送这个请求 s端可以识别 并且丢弃（这个上面 不应该有时间限制 什么60秒什么的 其实并不好）

这里学过struts2.0的 都会想到一个表单令牌环的解决方法 这个可以防止重复提交 当然也可以阻止重放攻击 但这个需要使用struts的标签 以及服务 不过 现在貌似是springboot的天下了 这东西用的怕是少了 不是一种普遍的解决方案

但是他的机制 我们可以借鉴

每次提交数据携带这个令牌 作为s端识别的标志 如果令牌是相同的 就将这个令牌销毁 并处理数据 同时生成一个新的令牌 放在上下文中 在调用 表单插件的时候 解析struts标签 将其放入

不过现在前后端分离  后端代码 现在一般都不会再去解析jsp或者ftl了 用的什么node vue 后端只负责返回数据所以 解决方案还要调整

以下是我想到的一种：

    后端需要有一个拦截器 或者过滤器 对每个请求进行处理 如果是 get直接放行  如果是post 需要判断某个token，这个token如果和s端 如果不一致 直接拒绝  如果一致 那么放行 并重新生成一个新的token 覆盖掉当前值，并做返回值 一起返回个前端 之后提交的时候 在把这个值带上。

第一次这个值 当然是登录成功才返回的 因此那个过滤器 对这个登录的请求要放行

这个值只有在使用post方式的时候 或者你认为有改写数据的可能的时候才拿出来验证 其他的不用 切每个只用一次 用了就更新

至于这个token的存储问题 感觉直接塞进 内存就好了  或者用个缓存 redis什么的  只存键值对 而且都是字符串 应该占不了多少内存

这个里面 只能传图 不能画图 实在是烦  图之后再补上