如何防止短信API接口遍历

短信API接口在web中得到越来越多的应用,如用户注册,登录,密码重置等业务模块都会使用手机验证码进行身份验证。一般情况下,我们会采用这样的安全策略,将短信发送频率限制在正常的业务流控范围内,比如,一个手机号一天最多下发10条短信,同时限制时效,验证次数。但这样的策略,攻击者通过遍历手机号,还是阻止不了短信资源被消耗的情况。

如何防止短信api接口遍历呢?

在平时浏览网站的时候,我会稍微留意一些网站是怎么做的,并记录了一些短信API接口防遍历的技术实现方式。

第一种方式:白名单

这是最简单的一种方式,但应用场景有限,比如,在一些内部应用系统(从HR系统或其他系统同步手机号过来验证),此时,只需要验证是否为内部员工手机号,如不是,直接提示非内部员工手机号;如是,再执行短信api流控策略。

第二种方式:验证码(推荐)

用户点击获取短信验证码的时候,弹出图形验证码进行验证,同时发送图形验证码和手机号码到后台验证。

当然,这种方式用户体验极差,每次都需要手动需要图片验证码才能发送手机验证码,于是,有了进一步的优化方案,从用户体验和安全角度出发,可设计为当用户输入3次错误手机验证码后自动弹出验证码。

还有另外一种方式,采用当下比较流行的滑块验证或点选验证方式,用户体验也会有所改善。

第三种方式:接口加密(不推荐)

前端与后台协商好加密方式,比如md5(timestamp+telphone+salt),前台发起请求时,同时发送 timestamp、telephone、sign参数,后台接收这些参数,按照协商好的加密方式生成一个校验值与sign进行对比,如果错误,则不处理。另外,js代码混淆+短信api业务流控限制。

风险点:虽然做了代码混淆,但js加密算法一旦泄漏,并不是一种安全的措施,但也是一种比较容易实现的技术方案。

客户端ajax代码实现:

var timestamp = (new Date).getTime();
var sign = md5(timestamp+telephone+"qwertyuiopasdfghjkl");
ajax.post({
'url': '/sms_captcha/',
'data':{
'telephone': telephone,
'timestamp': timestamp,
'sign': sign
},
...........

以上,是三种常见的预防短信api接口遍历的技术实现方案。

我创建了一个免费的知识星球,主要用于技术问题探讨。我将这个问题发表在知识星球,得到了不少星友的热情回应,以下摘录一些星友们的看法。

@超人:限制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每天只允许三个用户获取验证码。这种模式比较常用。

原文发布于微信公众号 - Bypass(Bypass--)

原文发表时间:2019-09-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券