短信API接口在web中得到越来越多的应用，如用户注册，登录，密码重置等业务模块都会使用手机验证码进行身份验证。一般情况下，我们会采用这样的安全策略，将短信发送频率限制在正常的业务流控范围内，比如，一个手机号一天最多下发10条短信，同时限制时效，验证次数。但这样的策略，攻击者通过遍历手机号，还是阻止不了短信资源被消耗的情况。
如何防止短信api接口遍历呢？
在平时浏览网站的时候，我会稍微留意一些网站是怎么做的，并记录了一些短信API接口防遍历的技术实现方式。
第一种方式：白名单
这是最简单的一种方式，但应用场景有限，比如，在一些内部应用系统（从HR系统或其他系统同步手机号过来验证），此时，只需要验证是否为内部员工手机号，如不是，直接提示非内部员工手机号；如是，再执行短信api流控策略。
第二种方式：验证码（推荐）
用户点击获取短信验证码的时候，弹出图形验证码进行验证，同时发送图形验证码和手机号码到后台验证。
当然，这种方式用户体验极差，每次都需要手动需要图片验证码才能发送手机验证码，于是，有了进一步的优化方案，从用户体验和安全角度出发，可设计为当用户输入3次错误手机验证码后自动弹出验证码。
还有另外一种方式，采用当下比较流行的滑块验证或点选验证方式，用户体验也会有所改善。
第三种方式：接口加密(不推荐)
前端与后台协商好加密方式，比如md5(timestamp telphone salt)，前台发起请求时，同时发送 timestamp、telephone、sign参数，后台接收这些参数，按照协商好的加密方式生成一个校验值与sign进行对比，如果错误，则不处理。另外，js代码混淆 短信api业务流控限制。
风险点：虽然做了代码混淆，但js加密算法一旦泄漏，并不是一种安全的措施，但也是一种比较容易实现的技术方案。
客户端ajax代码实现：
代码语言：javascript复制var timestamp = (new Date).getTime();
var sign = md5(timestamp telephone "qwertyuiopasdfghjkl");
ajax.post({
'url': '/sms_captcha/',
'data':{
'telephone': telephone,
'timestamp': timestamp,
'sign': sign
},
...........以上，是三种常见的预防短信api接口遍历的技术实现方案。
我创建了一个免费的知识星球，主要用于技术问题探讨。我将这个问题发表在知识星球，得到了不少星友的热情回应，以下摘录一些星友们的看法。
代码语言：javascript复制@超人：限制ip有可能误伤同一局域网下的用户，最好是登陆后允许发送，限制用户的发送次数
@密因：同一手机号，60秒内不能重复发送，24小时内总共发送不超过5次；2个及以上手机号，通过识别客户端特征，出口ip，随机字符串，判定是否为同一用户，对同一用户使用限制措施。或者设定略高于平常请求数的基线，如日常1分钟100个短信请求，基线设置为150，1分钟内超过150次之外的请求丢弃。
@Antares：限制每个IP、帐号每天的请求频率和数量，对请求参数做签名校验，防止请求重放
@Adler：在获取验证码前加验证，然后黑名单屏蔽虚拟号，限制每个IP一定时间内的请求数和限制每个手机号请求的总次数。
@yd：一般都是限制ip在时间段内请求次数，限制同一手机号发送次数，加图形或滑动等验证码。
@Mr.周：设置请求上线 屏蔽虚拟号码段。
@ch4ce：我们限制了IP地址，虽然这样不是最好的解决方案。
@Loki⚡：我个人感觉，首先确保发送短信验证码的逻辑是正确的，然后可以根据业务的重要程度决定是用安全产品，还是自己开发人机识别功能。
1024：人机验证，设备号，帆布指纹， ip。
corp0ra1：如果可以的话，匹配用户名?
掉到鱼缸里的猫：限制同IP请求次数。
zxt：每个用户一天或者一个小时只允许三个验证码，同ip每天只允许三个用户获取验证码。这种模式比较常用。
