在绝大部分网站中，都提供短信来进行用户验证，如注册、登陆、修改密码、转账等功能。通过短信可以简单便捷地进行用户验证，但是，如果验证逻辑存在缺陷，导致用户可以无限制请求短信接口，就会造成短信轰炸漏洞，也属于防护功能滥用类漏洞。
该漏洞的利用过程也比较简单，即伪装成正常用户，向短信接口发起大量的请求，即可完成攻击过程。短信轰炸漏洞也能造成不小的危害，如会造成短信通道阻塞、短信资源被恶意消耗，如果被灰黑产利用，制作成短信轰炸机，还会造成企业形象受损，若被用户投诉还可能造成接口封禁等威胁。
短信轰炸漏洞造成的原因大概可以总结为两个，一是没有验证用户是否为正常用户，二是没有限制短信下发的频率，而防御思路也可以根据这两个方面来展开。
针对于用户校验方面，可以通过在发送短信验证之前，增加图形验证码或者是滑块验证码。而短信下发频率方面，可以限制单个IP请求频率、限制单个手机号请求频率等等。
2.1 图形验证码
造成短信轰炸漏洞的主要原因是攻击者可以编写成自动利用脚本工具，对短信接口进行大量的调用。如果再获取短信验证码前，增加一个图形验证码，只有校验成功才能进行后续操作，也能有效的防御漏洞。
如果图形验证码功能增加的逻辑不当，仍然会造成短信轰炸漏洞：
2. 验证码复用：验证码必须单次有效，有合理的失效机制
3. 图形过于简单：可以使用OCR进行图形识别，验证作用也就不复存在了，可以使用需要逻辑判断的图形验证码，如简单的算式等等，都可以增加攻击者自动化攻击的成本。
2.2 滑动验证
相对于简单的图片验证码，滑动验证的方式不仅用户体验会更好，安全性也会更高，因为滑动验证的本质逻辑是用户的拖放轨迹是否符合真实用户的行为特征。
但是，滑动验证也并不是完全不可绕过， 在Github 上有不少利用深度学习进行滑动验证项目。其工作原理是，通过对大量的样本数据进行数据标注，即将滑块的位置标注，用目标识别的模型，预测出滑块位置，最后通过轨迹方程，完成滑块验证。
同时，滑动验证也需要规范使用的逻辑，如有效性控制，包括了有效时间和有效次数等等。
2.3 限制单个IP请求频率
通过限制IP在单位时间内的请求次数，可以有效阻止某个IP在短时间内对大量用户进行轰炸攻击。一旦用户请求次数超出设定的阈值，则暂停对该 IP 一段时间内的请求进行响应；若造成大量的恶意请求，也可以将 IP 加入黑名单，禁止该 IP 的访问请求。
然而，通过IP限制的方式，仅仅是增加了攻击成本而已。单一的IP限制很难达到比较好的防御效果，攻击者可以使用代理池等对IP限制进行绕过。
2.4 限制单个手机号请求频率
可以根据业务需求，对手机号在单位时间内的请求次数进行限制，如一天不超过十次等。同时，还需要对两次请求之间的时长做合理限制，时长应该要超过验证码有效期。
通过这样的限制，可以有效的解决单个用户遭受短信轰炸的困扰。但是，仅仅通过限制单个手机号的请求频率，依然无法解决所有问题。这样的防御方案仅仅防止了短信轰炸问题，但是攻击者依然可以通过生成随机手机号，对随机用户发送短信，虽然这样的攻击并不会造成轰炸的效果，但是依然会损耗短信资源，造成一定的损失。
2.5 总结
上文叙述了常见的几种防御方式，显然，单独使用其中某种方式，是无法很好的防御短信轰炸漏洞。此外，还需要严格控制功能逻辑，才能达到很好的效果。在请求短信接口的过程中，每一步都需要进行严格的验证，必须以上一步的结果作为依据，如在验证过程中加入随机数，随机数仅支持一次验证，并且验证需要贯穿整个过程。
在具体的实现过程中，客户端的请求频率相关数据存储实现，可以使用 session、redis数据库等等。
最近在实战过程遇到的一个站，感觉他的功能逻辑相对来说比较严谨，所以想分享下。
原文始发于微信公众号（山石网科安全技术研究院）：手机短信轰炸与群发漏洞防御总结
评论