记一次反垃圾注册应急

前期回顾

某天晚上运维老哥反映，公司某业务系统接到大量的注册请求，最高频率可达到4w/分钟。

前期猜测有两种可能：1.因为优惠券来薅羊毛的；2.某短信提供商在刷费用。

前期思路：

对注册接口进行限速以及禁止机制,API网关限速

应急流程

• Splunk,nginx access log
• web服务架构: Front ->cdn-> nginx reverse proxy ->waf-> WebServer

踩过的坑

封禁IP

**思路：**在waf上配置封禁策略，当请求次数达到30次/minute，将其封禁一小时。

坑点1：

waf上配置封禁策略，因为waf是在nginx的后面，所以流量在转发到waf时，已经被nginx解析了一次，所以应该考虑nginx转发的包到waf的样子。

坑点2：

因为网络架构的原因(waf在nginx的后面），所以当流量到达nginx时，nginx将其转发给waf,请求频率达到阈值之后，waf会触发规则将其封禁，然后返回502给nginx。当流量再次到达nginx时，nginx依旧会把它转发给waf,但此时waf已将该IP封禁，会返回502。此时的nginx再收到502之后，它会以为后端服务器出问题了，然后就会输出大量错误日志。这傻逼的网络架构，我也是无力吐槽。

短信验证码

坑点1：限制 60s 发送一次短信 ，但是未对短信发送的最大条数进行限制。

坑点2：客户端和服务器为设置同步，导致客户端限制了短信发送的次数，但在服务端未生效。

解决办法

1. 实行注册用户打分机制(基于 IP 信誉值，手机号)，当用户注册 时，分数越低，获得的奖励越低，并增加其注册成本
2. 限制每个账户每天发送短信的最大条数
3. 增加验证码（在请求次数大于等于3次时，弹出滑块验证码）
4. 对注册接口进行限速已经禁止机制，API网关限速

代码层面解决思路

从JavaScript AntiDebug 开始

一般来讲是有以下几种技术:

• 异常环境检测（我们只想自己的代码运行在浏览器中）
• 调试工具检测
• 代码完整性检测
• 数据流完整性检测
• 反模拟

当然前提是前端也要做好反调试和加密。

前后端接入之后，但依旧不能完全的阻止攻击，在攻击者花费一定时间之后还是有可能被攻破的。那么如何在后面的阶段检测到脚本作弊，则需要对用户行为进行分析。

用户行为分析

对用户行为进行分析，将非正常用户进行标记，为降低误杀率， 增加被标记用户的操作成本(例如：短信验证码改为语音验证码)

简单的鼠标行为记录，加上事件记录，单击，输入focus input，等等，将其序列化，做分类即可。这个方法目前正在测试环境收集用户行为日志，将其导入到s3,然后后期分析。

字段记录:

• 鼠标轨迹
• 单击事件
• 输入事件:时长
• 登录后行为

一下为简单的记录坐标轨迹：

document.onmousemove = function(e){
  var pageCoords = "( " + e.pageX + ", " + e.pageY + " )";
  console.log(pageCoords);
};

更骚的操作是:

monitorEvents(document.body); // logs all events on the body
monitorEvents(document.body, 'mouse'); // logs mouse events on the body
monitorEvents(document.body.querySelectorAll('input')); // lo

其他

• 行为日志收集之后用于分析
• Javascript 加密混淆深入了解

总结

SDL的推进真的十分必要，研发那帮人真的是啥方便干啥，总是遇到问题才会着急，平时真特么拽得不行。实在荒谬，然而现在给我的感觉是技术好管，人难管。真是让人一言难尽。还应该学习一些管理学的知识才行。

参考文献

• https://telegra.ph/Javascirpt-Anti-Debugging-08-02
• https://stackoverflow.com/questions/7439570/how-do-you-log-all-events-fired-by-an-element-in-jquery