最近发现公司账户注册量连续几天暴涨，因为业务上并没有做特别的运营活动，可以肯定是有人在刷账户注册接口了。

通过elk日志监控，查看请求注册接口的客户端来源IP，没有发现有过多请求的IP地址。但是我们的注册接口有多个版本，可以查到有一个接口的请求量很大，其他接口还是正常的平均水平。不过虽然这个接口请求量很大，但是客户端来源IP基本没有重复的，找了一些IP，查了一下IP归属地，五花八门，哪里都有，猜测可能是使用了代理IP。但是连续几天都是这种情况，怎么会有这么多的代理IP，即便是购买的代理IP库，也不至于这么多IP吧，所以猜测可能是web后台获取并传递到后台接口的客户端IP是错误的。于是联系运维，查看WAF信息，可以看到这些请求的真实客户端IP，以及HTTP头信息，发现web后台获取的客户端IP是HTTP头里的 X-Forwarded-For 字段值，而这个字段是访问者可以任意填写，可以伪造的，问题原因算是找到了。

webserver 日志

WAF信息

解决办法：web后台Nginx中将WAF传递的真实客户端IP追加写入到X-Forwarded-For字段，web后台读取X-Forwarded-For字段的最后一个IP作为真实客户端IP。有了真实客户端IP，后台的IP防刷限制就可以起到作用。

客服反馈，有用户反映有人用别人账号就能直接查到该账号绑定的手机号，怀疑有接口漏洞。

客服提供了几个被查到手机号的账号，通过elk日志查看这些账号近期接口调用情况，没有发现什么异常。想到最近上线的一款应用有用到查询用户信息的协议，怀疑是不是有bug，打开应用主页，debug模式查看用户信息相关请求，发现返回信息都是做过脱敏的，比如手机号中间四位用*号替换等。复制请求链接，浏览器新页面打开，修改请求链接的用户ID字段，发现竟然可以查到任意用户的个人信息，包括手机号、身份证，虽然都已脱敏，但也是不应该这样的。如果有人利用这个接口查询到任意一个账号绑定的手机号，只有中间四位未知，只需要有一个接口能用来验证手机号，很容易验证出正确的值。再次到elk日志查看用来验证手机号是否绑定的接口，果然近期有大量请求。因为这个协议中没有涉及账号信息，所以之前用账号查询接口请求情况时没有发现异常。继续查看协议的请求来源IP，发现同样是来自这个新上线的应用。打开应用首页，发现在手机注册账号之前会先调用接口查看手机号是否存在。问题基本确定。

解决办法：应用开发人员修改bug，只允许用户查看自己的个人信息；脱敏数据进一步脱敏，只显示前两位及最后一位，中间数据全部*号代替；优化注册流程，可以在注册提交之后再提示是否存在，因为手机注册时需要验证手机验证码，可以起到一定的防刷作用。