@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 就好了

@lkl641818 有一句话叫可怜之人必有可恨之处 不是没有道理的

@SlipStupig 以下是我做过的 UGC 内容的风控工作的一些经验，你看下是否有帮助：
1. 无论是正则 match 敏感词或者分词+native bayes 甚至神经网络，如果想绕过一定能绕过，想想异形字、拼音混合、火星文等等，如果支持图片那就更是噩梦，OCR 就是一个非常大的问题。
2. 业界的基本操作基本上都是模型打分，分数不仅仅是依赖内容自身可能还有用户的一些历史行为维度，超出阈值部分人工审核，再审核通过前，仅作者可见（那些自以为沙发的评价）
3. 换个维度解决问题，针对违规用户一定要处罚，禁言、封号，不然永远都是对抗
4. 提高用户门槛，包括注册门槛，发言门槛，总之要提升成本
5. 风控策略防止及其行为和团伙作案，IP、设备维度等维度的限制等
6. 完善的应急制度，针对极度敏感内容要有预案能快速删除，以防封站

分母+1

@JustinJie 你的服务如果在迁移期间可以停止服务，那同步数据用脚本还是 sql 都可以。但是你确定迁移期间没有数据修改的问题吗？

我能想到的步骤如下：
1. 新老表双写，读老表
2. 数据迁移，400W 条数据迁移应该很快
3. 抽样对比数据，看下是否 OK
4. 灰度读数据到新表
5. 老表下线

flink

@onice 毕业后一直从事安全行业，如果需要可以聊一下 YTU3NDAwODc0MQ==