一、序言

在Web开发中，总有一些接口需要暴露在用户认证前访问，短信发送接口特别是短信验证码注册接口便是其中典型的一类，这类接口具有如下特点：

• 流量在用户认证之前

流量在用户认证之前，意味着无法获取用户ID等唯一标识符信息对流量限流

• 手机号未知

手机号未知意味着无法对待发送短信的手机号做精准检测，判断是否是合法的手机号。通过正则表达式判断手机号连号过多，容易滋生短信盗刷。

本文将重点聚焦接口的防盗刷实践。

二、盗刷流量

在解决防盗刷之前先认识盗刷流量的特点和防盗刷的目标。

（一）防盗刷的目标

1、减少盗刷的总量

如果能将盗刷的频率控制在60秒之外，那么单日盗刷的最大数量为24*60=1440。假如系统入侵者发现请求频率间隔在60秒以上，那么可自动劝退入侵者，原因是投入与产出不匹配。

实际上盗刷流量以秒级甚至毫秒级刷新，对系统造成明显的损害。

2、回避周期性盗刷

周期性盗刷隐匿性更高，对系统有持续破坏能力，积少成多，不易察觉，相比于单次爆破性盗刷，周期性盗刷的危害可能会更大。

对于重要的接口，可考虑动态URL或者给参数增加时间戳签名，避免静态接口被暴露出去。

3、减小对正常用户的影响

防盗刷的重要目标是避免因提高安全等级而误伤正常用户，即使对正常用户有影响，也要减少相应的比率。

（二）盗刷流量的特点

盗刷与正常用户流量有明显区别，尽管盗刷可以模拟正常用户，但是还是通用性区别。

正常用户访问是随机的，失败重试的次数有限并且也是随机的。盗刷流量是周期性的，并且间隔很小。

正常用户是通过浏览器或者APP间接的产生请求流量，盗刷通过代码直接发送HTTP请求。

三、可行性方案

下面通过逐步探究的方式，寻找合适的防盗刷方案。

（一）无安全防护

如果说重要的接口无安全防护措施，那么过于粗心大意。仅靠短信运营商提供的限流和预警方案不能满足短信防盗刷的需求，本质原因是手机号可以合法的模拟，短信运营商不管是正常手机号、停机号、注销号还是尚未投入使用手机号，均会响应发送短信的指令，哪怕是空号发送不成功也会计数。实际上盗刷使用的空号正是接口盗刷的典型特征。

仅靠短信运营商提供的限流和预警方案不能满足短信防盗刷的需求，尽管可以针对单个手机号定制发送短信限额，按小时、按天可定制发送总额，依然不满足短信防盗刷的目标。当触发限流时，正常用户流量同样被限流，对于短信注册来说新增正常用户受影响。如果恶意破坏者连多日耗尽限额短信资源，对正常用户的使用影响很大。

（二）图片验证码

在无防护措施的基础上增加图片验证码，有验证码的保护，短信接口相对安全许多。

短信验证码尽管能够有效保护短信接口防盗刷，但是不能够保护自己被盗刷。盗刷流量恶意刷新图片验证码接口，给服务器CPU造成极大的负载：图片验证码服务与业务耦合，则业务可能响应缓慢；图片验证码服务独立部署，隔离了对业务的影响，但是图片验证码服务器CPU依旧可能过载，正常用户依然收到影响。

Web系统使用图片验证码正逐渐减少，原因是引入了图片验证码保护了短信接口，却无法保护自己。

（三）基于IP限流

上述两种方法存在明显的缺陷，实施落地时几乎不使用，通过基于IP限流对无安全防护方案进行升级改造。基于IP地址，每60秒允许发送一条短信（不关联手机号），通过后端强制限流，能够大幅减少短信接口被盗刷的数量。

基于IP限流回避了盗刷模拟手机号的影响，使用IP地址一刀切，稳妥的保证了短信接口的安全。

IP限流有个潜在隐患是如果恶意攻击者与正常用户复用同一个公网IP出口，那么正常用户可能会收到影响，不过这种情况影响范围有限且可控。

恶意盗刷通过代理IP地址仍然能够破解IP限流，只不过增加了破坏者的成本。

UCode CMS内置分布式IP限流的实现，可快速集成到项目中，请访问开源项目中说明文档获取更多内容。

（四）动态请求

通过上述三种方案并没有找到令人满意的防盗刷方案，下面在IP限流的基础上继续打补丁，升级到动态请求。

动态请求的核心思想是将短信验证码接口动态化，既可以接口URL动态化，也可以是参数动态化。下面介绍一种基于时间戳签名参数的方式，实现动态请求。

1、签名参数生成

前后端约定签名参数生成算法，此算法应当保密。

比如：手机号=18612345678，则key=MD5(手机号 + 当前时间/分钟），这里使用60秒的缓冲时间，也可以约定3分钟或者5分钟。

前后端都用这种方式生成key，前端页面通过js脚本生成“签名”，服务端“验签”。

需要注意的是：时间校验要留buffer，客户机时间与服务器时间并不完全相同。

同一个签名参数超过缓冲时间在后端无法实现验签，因此盗刷在不知道签名算法的前提下，盗刷流量有时间维度限制，解决了周期性盗刷的问题。

2、签名算法安全性

签名算法在后端是安全的，出开发人员外，几乎无泄漏的可能。下面着重讨论签名算法在前端的安全性，以Web端和APP端讨论。

（1）Web端

Web端通过JS实现签名算法，由于可通过浏览器直接查看JS，有泄露算法的可能。不过目前大多数JS都是通过压缩处理的，无法直接查看JS的详细内容，如果前端做一些伪装，破坏者找到签名算法有一定难度。

（2）APP端

相比于Web端，APP端的安全性略高，签名拳法封装在APP应用程序中，除非通过反编译手段，无法得知签名算法的详情。

对于非HTTPS流量，可通过抓包程序获取短信接口的URL和参数，在不知道签名算法的前提下，仍不能周期性的盗刷。

四、小结

上述可行性方案逐步升级，能够实现重要接口的防盗刷需求。

（一）防盗刷建议

对于重要接口的防盗刷，除了使用上述方案外，建议遵循如下要点：

1、使用POST请求

尽量使用POST请求方式，增加盗刷者的尝试成本。

2、使用HTTPS

HTTPS在Web端形同虚设，在APP端有较为很好的保护作用，盗刷者通过抓包工具无法直接获取接口的详情信息，有效的保护了接口。

3、周期性修改接口

随着项目的迭代升级，周期性的随机变更重点接口的请求地址，前后端同步更新。

（二）补充说明

上述可行性讨论方案适用于与短信注册类似的接口。

1、短信登录接口

短信登录在IP限流的基础上增加手机号BitMap检验，如果当前客户端访问IP限流正常，并且当前请求手机号已经注册，则发送短信。

短信登录接口无必要使用复杂的动态请求的方式，原因是已经默认了当前请求手机号存在数据库中，如果不存在那么便是错误请求，快速响应即可。

UCode CMS内置分布式BitMap的实现，可快速集成到项目中，请访问开源项目中说明文档获取更多内容。

2、已认证接口

对于已经经过登录认证的接口，可使用用户ID限流，直接在无安全防护的基础上使用用户ID限流。

出处：https://www.cnblogs.com/javazhishitupu/p/16134378.html