java黑名单校验_短信验证码被刷怎么办？java 短信验证码防刷策略

一 事件简述

这是一件发生在前段时间的事情，当时的情况是这样的：一个新的功能模块上线之后，出现短信接口被恶意访问调用的情况，请求数量很大，而且通过查看短信服务商控制台也发现，短信发送量在飙升，看着统计曲线的增长，紧张的气氛也渐渐变得更浓，很明显，事情并不是遇到一个bug那么简单，因为牵涉到服务费用，需要立即解决。

当然，接口被恶意访问的这个问题已经解决，因此写了这篇文章，可以做一下简单的记录，并且静下心来分析一下其中的问题了，看完这个案例，大家也可以一起讨论讨论。

二 问题分析

这是当时的短信接口日志数量曲线，某一个时间点突然增长了起来并且没有降下去的意思，通过日志分析发现，***者用的不同IP、不同号码进行恶意调用，请求量较大，赶紧将事件做了记录并通知了相关人员，和同事做了沟通后，大家也都提出了自己的意见：有人说赶紧修改前端功能，发一版新的APP，有人说修改后端代码，紧急补救一下，也有人说要不要先关停一下服务......在网上技术论坛搜了一下相关问题，好像碰到这种事情的也不少，基本思路都是加验证码，做好安全验证，被***了无可奈何之类的云云。

简单对各个方案做了整理：

修改url(APP已经上线，暂时无法修改)。

添加验证码验证(APP已经上线，暂时无法通过这种方式来解决)。

停掉短信服务(不现实，其他功能模块也需要调用短信服务，不考虑实施)。

短信服务商自带防***，等一段时间，让***者自己停止***(虽然短信服务商自带防***，但是依然会出现大量的垃圾请求，而且服务商只是针对次数和时间做了限制，一段时间后依然会发送短信，因此，危害和损失还是不小的，问题依然急需处理掉，装鸵鸟是解决不了问题的)

三 应急解决方案

在用户交互界面拦截请求已经不现实了，因为移动端短时间内是无法立刻升级的，而等待***停止的方案也不可取，选择逃避和等待是解决不了问题的，因此最终的决定就是修改后端接口逻辑和代码。找到最关键的问题，虽然存在网络***，但是真正需要立刻解决的是短信服务接口的调用问题，当务之急是修改短信发送接口，尽快止损。

通过讨论和简单的分析，最终是决定先修改后端逻辑紧急打一个线上补丁，移动端也做同步修改，等待发版。

1 黑名单模式拦截

由于接口一直被调用，需要紧急处理，减少短信服务费用的损失，因此一开始的出发点放在了手机号码上，针对手机号码做验证，采用黑名单的模式，对于此接口中出现的号码，在一定次数的请求后就立刻加入到黑名单列表中，再次请求时，如