VSRC业务安全 | Check Your User Name
前言：Chaos is not a pit. Chaos is a ladder.
在电商业务安全里，从用户最基本的注册、登录到浏览商品，添加购物车，再到最后成单收货，每一个环节都是环环相扣相互关联的。
每一个细小的安全问题都足以让我们混乱，使我们遭受沉重的打击。
但是 “Chaos is not a pit. Chaos is a ladder.（混乱不是深渊。混乱是阶梯。）”。只有解决了这些基础问题，我们才能向更高的方向攀爬前进。
我们一直在总结在安全风控工作中踩过的坑，淌过的水。希望这些经验能够帮助到我们自己和大家，促进我们多思考，而不是永远做个救火队长，也希望大家能够多多交流分享。
本文以检查一个手机号是否在平台注册（黑话：“查存”）为例阐述：即便是非常简单的基础接口，一旦被恶意利用，同样会产生大问题。
案例一：注册环节“查存”
众所周知，现代互联网公司为了增强用户体验，前端界面通常都提供非常用好的交互UI。
以注册为例，当用户在某输入框中输入用户名或手机号后，只要释放鼠标焦点，网页代码会后台异步请求一个检查用户名是否注册的接口。
该接口会立即告诉用户，刚刚填写的用户名或手机号能否使用，用户无需等到发起注册行为或页面跳转是才发现手机号已被注册不可用。
作为一个提升用户体验判断用户名是否被注册的异步检查接口，一旦被恶意利用并无限放大，将产生灾难性的后果。
黑产可以不断向该接口发起请求遍历全国手机号，以此确认特定的手机号是否在目标网站注册过，也能为后续的精准撞库攻击行为做准备。
下图是我所在团队曾经遇到的一次挑战，在黑产不断的请求下，系统收到大量的4XX日志报警，团队频繁地被监控中心请（sao）教(rao)，不胜其扰。
本次事件中，IP地址极度的分散，源源不断，不可能一网打尽，而且封杀效率低下。有时候等封禁策略执行完毕，黑产的IP已经更换废弃。
另外，我们还发现风控系统的拦截率并不高。在如此大量的IP请求下，为什么风控的拦截率会这么低呢？
带着问题，在持续的对抗中，我们也根据黑产的动作做出了分析和调整：
首先，我们上线了Nginx上的Lua拦截模块，实时地封禁IP，拦截效率得到了大幅度的提升。
其次，经过排查发现黑产有伪造IP的行为，这对我们风控策略造成了影响，使拦截效果大打折扣。
于是我们优化了获取IP的逻辑，减少伪造IP的可能，并调整了风控策略，提升风控的拦截效果。
通过我们一系列的措施，目前网站请求用户名是否注册的接口已经趋于正常，未来我们还会考虑加入图片验证码等方式。
案例二：密码找回环节“查存”
某商城密码找回页面在用户提交手机号后会发送重置密码的短信验证码。
由于未对接口调用进行限制，导致被黑产大量利用，一夜之间发出30w条发送找回密码短信。
黑产之所以大量利用这个接口，其目的仍是检查用户名是否存在。系统提示：“短信已发送”则说明手机号在目标网站存在，相反不存在。
结果引起了用户恐慌，造成了大量的投诉。更严重的情况，甚至可能导致短信通道被关闭，平台无法发送短信，影响到正常业务。
试想，如果发生在注册或者结算时，短信通道被关闭……
在短暂的懵B后，团队迅速开展排查，发现问题出在接口调用这里。此接口没有任何安全措施，导致了大量恶意请求。
于是我们采取了应急措施：
- 1、 联系运维暂时短时间封禁此接口。
- 2、 修改前端文案，模糊提示，返回一致性信息，使黑产无法利用。
- 3、 封禁IP。
- 4、 客服发送安抚短信。
事件的后续处理和反思：
- 1、 该短信接口接入风控，设置短信防刷
- 2、 增加图片验证码防刷
- 3、 排查筛选其他接口是否存在类似情况，并通过此次事件推动加强安全措施。
- 4、 我们需要经常评审、回顾我们的风控规则，由于业务的发展和变动，我们也需要评估现有规则的合理性和有效性。
当遇到问题时要么屈服要么反抗你只要开始，进行分析 解决一个个的问题
等解决了足够多的问题，你就能早点回家了。那么，下一个问题是？