@bigbigeggs 我做安全的不是专业开发本不想跟你扯这么多，既然你回我了，那就跟你友好探讨一下，首先我认为 token 应该是服务端生成告诉客户端的，客户端怎么会知道你是用什么参数生成的呢？客户端只需要请求的时候带上即可。即攻击者获得了 url ，例如 del?id=1&token=xxx ，攻击者不知道这个用户现在有效的 token ，这个请求到服务器经过校验是无效的啊，为什么不能防止重放呢？
其次，讨论的重点是重放，什么场景会有重放？重放有可能是想针对客户的攻击，例如我把嗅探到的其他用户转账的请求包重放；也可能是针对服务端的攻击，例如我把点赞重放来刷票，甚至也可能是用户觉得页面有点卡他又刷新了一下，你总不能说我在付款页面刷新一下你又扣了一遍款吧？重放不需要考虑你是怎么生成的，我只管把数据包重新发送就行，构造恶意的请求那是另一个范畴了。你可能把重放和 csrf 两个东西搞混了？
反而我认为你还被其他人误导了，中间人和重放不是完全划等号的，逻辑应该是存在中间人攻击的话会出现在重放这个问题，因为我可以获取到你的数据包，但重放也不只在中间人攻击中存在，所以 token 防止不了 mitm ，只能用来解决重放。你想想我都能获取到你往来的请求了，你下一个 token 我也知道是什么，我完全可以构造一个请求带上服务端给你返回的有效 token 。但是我重放你请求的包是没用的，使用 https 才是可以解决 mitm 的方案，之一，https 也并不完全安全，尤其是支持一些老版本的 tls 。
所以我才说你连 token 都没搞明白，因为我从你的描述中感觉你只知道 token 应该怎么生成，但你不知道怎么用，也不知道为什么要用

"放重放生成一个 token ，这个 token 人人都知道如何生成的，比如 timestap+参数 用 md5 进行加密，攻击者也可以完全模拟这个 token 的生成规则，来绕过服务端"
我怀疑你连 token 都没搞明白

只有个$ne 不是注入漏洞吧。。我觉得你应该是存在别的漏洞
比如越权啥的

多刷几次你就发现会有验证等着你，然后你就陷入了另一个反爬的大坑
不够这个搞明白了还挺好的，可以接别人的活，很刑

@zhaohao 因为体温上升导致的 平时即使不是新冠发烧也会这样

https 就相当于是加密了。。你再加一次有什么用呢
前端对字符串加密跟明文没任何区别，如果我能从你 https 里获取到了原始的请求体内容，依旧可以用这个加密后的字符串进行重放，这个加密后的密文就等于你的明文密码，不知道你能不能想明白这个道理
除非你每次登录都重新生成一对密钥

@WilliamZuo 因为你要是不执著于本地部署的话，你没显卡都能用

扫就让他扫呗 banIP 有啥用 真想搞你买个代理池，那 IP 换的比你封的都快，成本也低
你只需要保障你的系统尽可能安全就好了，一个个人网站不会有人用 0day 打你的，只需要注意不要有弱口令 高危漏洞啥的 有新版本尽快升级这些。要是你自己写的就当作是给你免费做渗透测试了，提升一下安全编码的意识

从你这看 只是常规公网的一个扫描 你很难找到对应的人
没有造成损失的话警察应该也不会搭理你

上杠杆 涨回来就直接起飞 涨不回来也可以起飞

不会真有人站在风口上以为是自己牛逼吧。。真这么厉害这么珍贵不会几个月就培训出来一批了，自己还担心 35 连个刚毕业的都竞争不过

http 标准中 delete 方法也不是给你这样用的吧
我觉得遵循国际标准比那什么 restful api 标准理由要充分的多。。

这要求虽然看着都不要求多深，但是广度我觉得我们这专门的项目经理都没有能全部 hold 住的
我建议你们拆成两部分，一个是搞机房建设的项目经理，技术上知道怎么回事就行，再招一个是技术负责人

有没有可能 很多开直播拿个手机就开了