之前遇到客户得罪人，被人恶意攻击，批量刷项目的短信接口，导致一天内被刷了上千条短信。

当时项目已有的防刷机制只大概包括：

1. 验证手机号格式
2. 检测该手机号请求频率，最高一分钟一次，一天最多发送三次
3. 检测IP的请求频率，一小时内最多请求五次

但是这种情况下还是被一天刷了上千条。后台看了下请求记录，发现攻击者使用了高匿代理轮询请求服务器，就是相当于模拟不同用户的手机号和不同IP发送请求，这让我们很难判断来请求的究竟是真实用户还是机器人。

但是我从记录发现了一点：对方是直接攻击的API接口

这样一来就有了个初步的解决办法：

让程序在请求短信接口前 先从服务器获取一个特征码，然后在请求短信接口的时候把这个特征码和手机号一起发送到接口，服务器再根据这个特征码验证是否成功。

最直接的方法就是生成一个随机码存到Session中，然后前端请求短信接口时服务器判断Session中的随机码和前端请求时发送过来的随机码是否相同，为空或者不同则验证不通过

但是这样一来也有个问题，当攻击者不了解请求流程还好，如果攻击者理解了参数含义，还是能直接拿到特征码再提交过来，同样防止不了刷短信的问题。

于是又衍生出了另一种解决方案：

图形验证码
像网易等大厂注册时也是采用了这种方法

服务器先生成图形验证码返回到前端，在请求短信接口前先验证图形验证码，然后再决定是否发送短信

这种方法生成的图形验证码一般机器人识别起来有一定难度，虽然同样有被破解的可能（AI训练和打码平台），但是也无形中增加了攻击者的攻击成本，能大大减少被攻击的概率。

只不过这种方式在手机端相对于用户体验可能不是很好，不过安全至上，也无伤大雅吧