百木园一、序言
在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限流。
喜欢本文就【♥️推荐♥️】一下，激励我持续创作。这个Github同样精彩，收到您的star我会很激动。本文归档在专题博客，视频讲解在B站。
来源：https://www.cnblogs.com/javazhishitupu/p/16134378.html
本站部分图文来源于网络，如有侵权请联系删除。