短信漏洞 系统整改

上个月，短信我一个做运维的漏洞朋友半夜被叫起来处理故障。原因很简单：公司用的系统某云短信服务被人薅了。攻击者没用什么高级手段，整改就是短信拿着他们暴露在外的接口，批量调用发送验证码。漏洞两小时，系统发了四十多万条。整改一条按五分钱算，短信两万块没了。漏洞更麻烦的系统是，手机号列表来源不明，整改可能涉及用户信息泄露。短信

这不是漏洞孤例。短信接口被刷，系统几乎成了中小型互联网公司的"标配"事故。问题出在哪？很多团队把短信发送当成一个普通HTTP接口来写，没有频率限制，没有图形验证码前置，没有号码黑名单，甚至同一个手机号一秒能发十次。攻击者写个循环就能把余额打穿。我见过最离谱的，接口URL直接写在App的反编译代码里，连签名都不做校验。

整改得从三个层面下手，但别指望一次全做完。

第一层，接口入口。手机号+验证码的请求，必须过图形验证码或行为验证。这一步能挡掉九成以上的脚本小子。图形验证码别用简单的数字加减，那玩意儿早被OCR破了。滑动拼图或者点选文字都行，成本不高。另外，同一个手机号，一分钟内只允许发一次，一小时内不超过五条，一天不超过十条。这个阈值根据业务调，但绝不能没有。同一个IP，一分钟内超过二十次请求直接封禁十分钟。

第二层，发送逻辑。验证码别用纯数字，六位数字空间太小，暴力枚举两万次就能撞上。改成数字+字母混合，或者干脆用JWT签名，把手机号和过期时间绑进去，服务端校验签名而不是比对存储的验证码。这样连存储都省了。短信内容里别带用户可控的变量，比如"您的好友XXX给您留言"，XXX如果没过滤，能被注入换行符发多条短信。

第三层，监控和止损。给短信账户设日消费上限，比如五百块。超了自动停发，人工介入。别嫌麻烦，真出事的时候这五百块能帮你省下几万。日志里记录每次发送的手机号、IP、时间戳、请求来源。发现某个手机号连续请求不同验证码，或者某个IP的请求量突然飙升，自动触发告警。我朋友那次事故，如果有个简单的QPS监控，十分钟内就能发现异常。

还有个小细节：很多团队用同一个短信通道发营销短信和验证码。营销短信被投诉多了，通道会被运营商限流，连带验证码也发不出去。分通道，验证码走独立通道，贵一点但稳。

整改不是一次性的。攻击手段在变，今天封了脚本，明天有人上代理池。每周看一眼短信发送报表，比事后追责有用。我自己的习惯是，任何对外暴露的接口，先问三个问题：能不能被枚举？能不能被重放？出事了能不能快速关掉？短信接口这三个问题的答案，往往都不太好看。

最后说个真实案例。某电商大促前夜，测试同学用JMeter压测短信接口，忘了改配置，直接对着生产环境发了八万条。运维看到账单才发现。技术漏洞有时候不是黑客造成的，是自己人手滑。权限隔离和测试环境隔离，跟防外部攻击一样重要。