有了QQ，微信之后短信的作用对个人好像没有什么特别的用处，平时朋友间的沟通都是通过微信(也有QQ)，渐渐淡化了短信的用处。但是作为开发我们还是会接触短信平台的。
短信现在的用处：
- 网站和app的安全验证(注册，登陆,修改密码等)
- 广告推送骚扰
- 生日祝福(来自理财，保险，银行)
- 女朋友生气拉黑微信/电话之后的道歉途径
- 还有自信卖A货的(不知道你有没有收到过)
- .......
目前阿里云，百度云，腾讯云都有自己的短信平台，而且我们的系统中也都集成了。
曾经我们正式环境系统配置的是其中一家的短信平台，已经持续运行使用2年了。
在最近使用期间出现了一次被恶意发送好几万条短信(最好在平台上开启每日最大限制，我们没开)。
我们的部分短信接口是public的(忘记密码和注册功能)，不需要授权即可直接API调用，而且我们系统中也是做了部分频控的，但是没有做IP的限制。
一个短信功能究竟该如何开发才能安全呢
一句话：互联网上没有真正的安全，安全是相对的，就是尽可能提升攻击者的代价。
新手：只考虑能不能发送，研究短信平台接口文档，写代码调试，最终可以正常发送短信。写业务相关代码，相关信息存储缓存，等待验证，一个短信功能开发完成。
老手：研究短信平台接口文档，写代码调试，可以正常发送短信。继续封装短信接口，增加频控 例如短信发送间隔时间，验证码过期时间，同一账号发送限制，次数限制的间隔时间 等。配置如下
captcha:
sms:
# 短信验证码过期时间(分)
expire: ${SMS_EXPIRE:5}
# 验证码发送间隔时间(秒)
interval: ${SMS_INTERVAL:60}
# 同一个账号发送次数限制
limit-time: ${SMS_LIMIT_TIME:10}
# 次数限制的间隔时间(时)
limit-interval: ${SMS_LIMIT_INTERVAL:12}
还有会增加接口调用IP限制(防止同一个IP频繁调用接口)，然后写业务代码，完成开发。
还可以过滤一些无效的短信发送，如：
1. 手机号校验：手机号不合格的不发送，可以使用google的组件检查，国内外手机号都可以校验。
<dependency>
<groupId>com.googlecode.libphonenumber</groupId>
<artifactId>libphonenumber</artifactId>
<version>8.12.6</version>
</dependency>
2. 注册功能：系统中已存在的不发送，在发送短信的时候校验手机号是否已注册，而不是真正注册提交数据的时候再校验。
3. 修改密码：系统中不存在的不发送，在发送验证码的时候校验下手机号是否是系统中的用户。
以上的方案只是对同一个手机号和IP做了频控，但是如果攻击者使用不断更换IP给不同的手机号发送短信，那么就无法避免短信的浪费和用户的骚扰。
要解决就要使用图形验证码或者行为式验证码
图形验证码较简单，而且不需要花钱，自己开发程序就可以实现，效果如下
这种视觉上看起来很费劲而且需要增加用户输入操作，体验不是很好，而且机器识别并解析其中的文字却比较容易。如果想要增加机器识别的难度就需要增加图片的模糊度，这样用户的错误率就更高了，体验更差。
行为式验证码 到这就不得不提逢年过节买车票让人抓狂的12306的图片验证,这是种点触式的，如下
还有目前更常用的方案是拖拽式的，如下
这种体验上就比图形要好很多，更方便美观，背景图还可以用来打广告。
行为式验证的核心思想是利用用户的“行为特征”来做验证安全判别，通过机器学习，深度学习对人的行为特征进行大量的分析。建立安全模型去区分人与机器程序。利用深度学习构建的神经网络是可以不断地自主学习的，在不断的验证过程中不断的学习新的特征分析(来源百度百科)
一般企业没有这个能力，需要花钱买
不想花钱也可以通过抠图实现简单的滑块，服务端记录滑块抠图的位置到图片边缘的距离，把原图和滑块给前端，前端在用户滑动之后把滑动的距离传给服务端，服务端通过对比用户拖动滑块的距离来验证是否正确(安全性不行)。
还有就是API增加限流
总结
- 频控，增加
短信发送间隔时间，验证码过期时间，同一账号发送限制，次数限制的间隔时间控制。 - 增加IP调用接口的频率。
- 通过校验避免一些不必要的接口调用，像
手机号格式校验，注册功能：系统中已存在的不发送,修改密码：系统中不存在的不发送 - 增加行为式验证码。
- 限流
“ 还是那句话，没有绝对的安全，安全是攻与防的较量。 ”
关注不迷路
MySQL高级相关更多内容，如事务，锁，MVCC，读写分离，分库分表等还在持续更新中，欢迎关注催更。
我是阿纪，用输出倒逼输入而持续学习，持续分享技术系列文章，以及全网值得收藏好文，欢迎关注公众号，做一个持续成长的技术人。
