@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 下吗

@isblock 老婆是律师，可以帮你免费出个律师函，需要联系我 MTgyMTc3MzI2NTE= 这种人太气人了

@kisshere 很早以前的笔记,请参考
XSS 的防御需要在特定的场景下使用特定的方法:
1. 变量在 html 代码中输出，这时的应对方法应该是使用 htmlencode
所谓 htmlencode 就是让浏览器不把这部分信息当做 html 代码处理而是当做纯文本。这样就避免了对原有页面信息的污染。一般需要转义的字符包括以下：<、>、&、"、‘、/这六个。
2. 变量在 html 标签的属性中输出 例如 <div id="abc" name=""><script>alert(1)</script ><""></div>
防御方法也是采用 html 编码
3. 在 script 内输出变量：
(1) 保证变量处在""内 "$test" 这样如果发起攻击的话，首先就要绕过双引号的封锁
(2)对变量进行 javascript 编码，对 script 内的特殊字符前加上\
4. 在事件内输出： <a href="#" onclick="funA('$var')"></a>可以通过如下方式绕过
<a href="#" onclick="funA('');alert('1');"></a>
也需要进行 javascript 编码
5. 在 css 内输出：首先要尽力控制这种情况，不要允许用户自定义 css 的 style 等内容，如果必须这样做需要用到 owasp 的 encodeForcss()函数
6. 输出到 URL，使用 urlencode 就可以避免了，但注意 http://这部分不要被转义否则不能完成功能
7. 处理富文本，由于富文本必须当做 html 解析，所以比较复杂：
(1)首先过滤掉比较危险的标签<form><iframe><base><script>，尽量使用白名单
(2) 尽量禁止用户自定义 css 样式 style 属性
(3)使用比较好的 xssFiter
8. Dom 型的 XSS：一般先进行一次 javascriptencode 再进行一次 htmlencode 才可以完全过滤

关键词匹配敢加单个字真是够猛的

@127000 你说的应该是对的，绝不可能是某个小白黑客做的，不然不可能涉及到这么多家运营商，倾向怀疑是某个内部小白做的操作

低频操作我理解用 Redis 做一把全局锁就可以了
Lock.lock();
doSomeThing();
Lock.unlock();

动手搞一下 套一层 CDN 就好了