注入教做人

你把 mybatis 的 XML 文件里参数前#变成$，就是一个注入

@zero47 目前工作中绝大部分使用的都是集群部署，部分使用哨兵是需要 mget

在快照读读情况下，mysql 通过 mvcc 来避免幻读。
在当前读读情况下，mysql 通过 next-key 来避免幻读。
select * from t where a=1;属于快照读
select * from t where a=1 lock in share mode;属于当前读

不能把快照读和当前读得到的结果不一样这种情况认为是幻读，这是两种不同的使用。所以我认为 mysql 的 rr 级别是解决了幻读的。
https://github.com/Yhzhtk/note/issues/42

@shoreywong 不好意思 @错人了，我自己是搞网络安全的，老婆是律师，也经常给 v2er 免费咨询，如果需要你可以加下她的 VX:MTgyMTc3MzI1NDA=

@shoreywon 兄弟你这一波的确有点伤，我自己是搞网络安全的，老婆是律师，也经常给 v2er 免费咨询，如果需要你可以加下 VX:MTgyMTc3MzI1NDA=

@plusDiscuss 找个律师花点钱出个律师函，说明不付款后的动作，这样比较合法，而且还能震慑下

@TIMIYANG 直接 ASRC 提交个漏洞，提漏洞的时候别说客服投诉的问题。从一个安全从业人员的角度看，这是一个挺严重的问题。如果没有忽略你的漏洞，再拿着漏洞详情去找他们客服就行了。

哈哈 作为一个风控开发工程师我能联想到咸鱼风控的无数技术细节。其实文字识别这个东西真的难做，这个锅要他们运营团队背的。

@tocherrygo 或许这个白帽子或者相关漏洞平台存在一定问题，但是你的说辞真的恶心。这个人既然提交了漏洞说明他并没有太多获利的想法。你可以联系相关平台问一下为什么没通知情况下直接公布 POC，而不是试图解决这个找到问题的人。

@chengkai 如果不是 IP 分布不是很广泛的话，写个流计算程序+nginx LUA 自动封禁就可以了

说个真实的例子，用户注册登录的接口，产品经理打着用户体验的大旗，不让加验证码甚至拒绝接入风控+验证码的方案，上线一个周被刷了几 W 块，后面半夜给我们打电话声音都是抖的

@oldManPushCar666 你们的产品怕不是没被锤过，这个情况最合理的方式是针对 99%的正常用户不谈验证码，剩下的高频访问 IP 怎么恶心怎么来，验证码+返回裁剪+投毒

@ksc010 看你的描述 已经做了基本防御但还是被刷了，一般来说短信轰炸接口不会使用带有验证码的接口，是否是批量注册呢？可以关注下这批用户的后续行为。

@mrzx 现在的 IP 地址供应商基本上都是会在 N 个地区用不同用户办理 N 很大的宽带，提供给客服的基本上是 VPS 或者是一个 VPN 账号，实际上就是把他的网络资源云化了，客户甚至可以通过接口指定出口 IP 的区域,类似这种 https://www.kuaidaili.com/

@mrzx 问题的点不在于池子有多大，而是这种 IP 可能会被重新分配给正常用户，如果你的应用体量很大，这样引发的客诉是不可控的

@mrzx @zhuwd 常年从事安全风控工作，说一下几点建议：
1. 不要做 IP 维度的对抗，黑灰产的 IP 资源早已不是来源于代理 IP，细节请搜索秒拨机
2. 增加黑灰产获取新用户的难度，注册环境各种图灵测试，针对虚拟号段的打击等手段，解决了用户问题，就解决了一半问题
3. 针对存量垃圾用户可以返回结果投毒，裁剪，不建议直接拉黑
4. 风控策略要尽量后置多变，不要被摸清楚规律
5. 最后如果数据敏感 可以收集证据走法律途径

@sunzhenyucn 简历模板不错，可以 share 下吗