短信轰炸与接口滥用

为什么这个漏洞如此普遍

短信发送接口的防护难点在于它本身面向匿名用户——注册流程需要在用户提供手机号但尚未登录时发送验证码，此时没有可信的身份信息用于限速。开发团队往往在功能上线后才意识到缺少防护，而补救措施如果影响正常用户体验又容易被产品拒绝。

攻击者通常枚举所有含「发送验证码」功能的接口（注册、登录、绑定手机、修改密码、找回账号），批量脚本化调用。不同接口的频率限制往往是各自独立配置的，有时甚至互相冲突——注册接口有限制，但「修改绑定手机」接口没有，同样可以对目标号码轰炸。[1]

防御需要多层组合：

同一手机号频率限制：每个号码每分钟不超过 1 次，每天不超过 5-10 次，并在 Redis 或数据库中存储计数，不依赖客户端传参。
同一 IP 频率限制：对同一 IP 的短信请求总量限速，配合 Nginx limit_req 或应用层中间件实现。注意 NAT 环境下同 IP 可能对应大量合法用户，阈值不宜过低。
图形验证码前置：在触发短信接口前要求用户完成一次图形验证码，增加自动化成本。
号码归属地与格式校验：拒绝非本国号码格式，减少境外号码骚扰。
短信内容加时效签名：验证码与发送时间戳签名绑定，防止重放已收到的验证码。

从业务角度，建议接入短信运营商的「短信防刷」服务，部分服务商提供接口层的异常检测。此外，定期审计所有含短信发送逻辑的接口，包括管理后台、第三方回调接口，确保无死角。