Finish: 49.32 s
本来不想点进去的，看到评论实在没忍住，看起来比其他人要快

你要是在国外或者以后考虑去国外肯定考 cissp ，国内的话两个效力一样，都没什么用，只是跟别人相比有没有的事儿
最多也就是招聘要求里有这么一条：具有 cisp,cissp,hcie,ccie 等证书者优先

上面说的那些商业漏扫软件吧，不过只能说是凑合用，对于一些通用型或者已公开的各种漏洞具备一定的检测能力。。
如果是企业自己的代码，不仅仅是为了合规的话，我觉得也可以考虑同步去做代码审计，白盒比黑盒效果要好，尤其一些未知一些漏洞，像哪里有个反序列化啊，基本只能靠审计了，黑盒很难测出来，相应的，对做审计的人要求很高。

@shrugginG 那你对我说的话也没有思考，长度不一致能分配的数量也就不一样

问问题之前建议先动动脑子
IPv4 跟 MAC 地址长度又不一样，而且即使重复了又怎么样呢，只要不在同一个二层网络环境下，随便重复

为什么是调小音量而不是降到 0 呢呢

还是有点用的吧。。不然这么多设备、日志、告警 总得有个平台能统筹起来分析跟处理吧

@magzza 上半年我记得没有网规吧

CVE-2024-4577 ？

游戏的交互不会是 http 吧。。腾讯不专门有个叫 kcp 的东西，基于 UDP 的
而且现在这种数据都会加密和校验的
十几年前会有叫做封包、脱机挂这种骚操作，脱机挂就是模拟账号对某些行为直接发包来实现不登游戏就能进行对应行为，现在你还听说过么。。

@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 里获取到了原始的请求体内容，依旧可以用这个加密后的字符串进行重放，这个加密后的密文就等于你的明文密码，不知道你能不能想明白这个道理
除非你每次登录都重新生成一对密钥

div 一删就变成正常页面了。。你防了个寂寞