短信验证码一夜薅光了

事情是这样的，周五临近下班，本想着可以过一个美好的平安夜。结果收到一条短信通知，大致内容是：验证码短信帐号余额不足，请及时充值。

心想，这是诈骗短信吧？因为就在大约一个月前在平台充了几万条短信，按我们系统目前的用户规模，支撑一年是没有问题的。

半信半疑登录到短信平台一看究竟，结果就如短信通知的一样余额没了。此刻好慌。。。

看后台日志，短信接口还在不停的被调用，我赶紧把短信通道先关闭。攻击者用的手段也很简单，就是拿到token后挂上代理IP，模拟客户端不停的并发请求。不到一天时间，短信接口被恶意调用了几万次。

连夜开始对系统进行修复升级，增加核心接口的调用频次，同一个用户或同一个IP或同一个手机号在限定时间范围内限制获取短信条数。同时对相关接口做必要的签名校验。同时，在特定条件下给短信接口加上图形验证码校验，比如连续触发3次短信接口，就要求输入图形验证码才能正常发送短信。

道高一尺魔高一丈，要从客户端完全杜绝恶意用户是不现实的，你有1000种防御方法，他就有1001种破解方法来搞你，只能是增加复杂度提高被破解的门槛。

搞我们的人大概有这么几种可能，一种可能是利益无关人，他们或许是刚学网络完全技术不久的脚本小子，刚入行，随便抓到一台机器就攻击，也不考虑系统的承载能力以及后果。 第二种可能就是有利益相关的竞争对手，如果你们的业务发展越来越快，会引起更多的同行关注，竞争对手正面干不过你，可能就在背后捅你刀子。还有一种概率虽然很小也不是不可能，就是和平台有利害关系的人。不管那种，都祝你早日吃上牢饭

万幸这次事故损失不大，但也足够引起重视，最后来复盘这个事故，总结几点

再小的业务，只要是面向公网的服务（也包括内网服务），安全问题从第一天就要开始重视。比如各种帐号、第三方服务密钥配置信息妥善处理，做到配置和代码分离，常见的Web安全问题比如SQL注入、CSRF攻击、XSS等等开发都需要有所了解，接口的请求频次限制，权限校验都不能忽略，业务ID不要把自增的ID暴露。关闭服务器没必要开放的端口等等。

系统安全不出事就没事，一出事就是大事。这种例子屡见不鲜，还记得有一年，CSDN被脱裤，所有用户的密码被暴露在网上，其中就包含我自己的帐号，讽刺的是，密码竟然还是文明保存的。。。

选择第三方服务的时候，尽量选择靠谱大厂，他们的费用可能会高些，但至少有信用背书，毕竟经过市场验证，提供的服务相对也更完善。比如我们使用的短信服务，因为之前一直用的是某小厂的，平台对这种异常流量的监控就做的很垃圾。平时的用量一天大概就一两百，结果这次一天消耗了几万条，作为平台方，肯定是有能力去做这些异常行为风控管理并提醒开发者的，但他们并没有这块服务。直到最后全部薅光了才来短信通知你要充值了。而大平台这些方面就要完善些，比如某云就有各种阈值告警配置，遇到异常可以做到及时通知开发者。至少可以把损失降到最低。