网站注册页面的短信验证接口被利用了，有一个思路

• 資深大佬 : Croxx

  lz 验证码呢？

• 主 資深大佬 : ksc010

  @Croxx 有验证码的 杂色 划线 干扰字符 都有

• 資深大佬 : sunziren

  发短信之前先填写验证码，完了之后才可以输入手机号码如何？

• 資深大佬 : whitev2

  挖矿 5s ？

• 資深大佬 : wbrobot

  验证邮箱免费

• 主 資深大佬 : ksc010

  @sunziren 现在就是这样子的

• 資深大佬 : Cmdhelp

  滑块

• 資深大佬 : labulaka521

  验证码估计很简单

• 資深大佬 : kucy

  上行参数加密。https://www.sojson.com/jscodeconfusion.html

• 資深大佬 : imaning

  我用的极验

• 資深大佬 : iamverylovely

  感觉验证码没起到作用啊，必须输入验证码，验证码正确，才能发短信，一次失效，应该是不会有这种问题的吧

• 資深大佬 : wanwaneryide

  手机号不一定是随机的，有可能被拿来做短信轰炸了，基本上这类软件都是这样的。

• 資深大佬 : ychost

  挖矿吧，前端挖 0.00001 个 ETH，然后才给验证码，这样既满足了主的需求，还能浪费电

• 資深大佬 : zpfhbyx

  比如加载某个比较小的图片.. 改成后端数据流渲染,然后 js 判断是否是无头浏览器, 如果没有加载图片,就认为是机器呗,验证码不实际发送,返回发送成功,后台记录就好

• 資深大佬 : brader

  可提供如下参考思路：
  一：接口设计加一个 sign 字段，sign 不对的都为非法请求（这条只能拦截初级程序员，网页端源码较容易看到，APP 端需要反编译，能稍微提高一定的技术门槛吧）。
  二：限制每个 IP 每天发送短信的频率。
  三：增加一些技术成熟的验证码功能（如：极验）。
  四：表单请求中，附带 token，避免重复提交。
  五：APP 的话，可以要求前端传递设备唯一标识号。
  六：后端捕获到客户端频繁、严重违反上诉行为的，直接封 IP 、封设备、封账号。
  七：对于违反上诉行为的，后端不要返回具体错误原因给客户端，返回一个模糊错误即可，这样能增加客户端猜解接口报错原因的难度。

• 資深大佬 : coolcoffee

  我觉得还是加个图形验证码或者交互验证码作为前置吧，万一攻击者拿其他肉鸡作为运算机器呢。

• 主 資深大佬 : ksc010

  @iamverylovely 目前验证码相对来说挺复杂的（有混淆）但是先有的 dama 平台是可以破解的
  早就限制了 单个 ip 单个手机号的发送次数，但是对方用了代理 手机号也不重复
  @wanwaneryide 是随机的 前几位都是固定的几组 比如 1863321 这样的

• 資深大佬 : brader

  另外，还有一些巧妙的防御思路，自己可以花点心思琢磨：
  比如：接口调用顺序（一般用户去你网址注册，会先去首页，再点注册），你发现这个客户端，直接就调用注册接口的，就可归类为非法请求。前提也是不要抛出具体错误原因给客户端，让客户端猜不出什么原因造成的非法请求。

  其实，短信的攻防没有完美的解决方案，在于攻击你的人愿不愿意付出更多的成本来攻击你，也就是从你那里获得的回报要能大于他的付出，控制好这个点就 ok 了，你做了图片验证，他使用 OCR 和打码平台也是需要成本的，当成本高于收益，他自然不会干这种傻事

• 資深大佬 : shiny

  对于这条：1. 目前是有验证码 相对来说挺复杂的（有混淆）但是现有的 dama 平台是可以破解的

  破解也要花钱，如果成本和短信持平，那就没有动力来利用你的接口了。

• 主 資深大佬 : ksc010

  @brader 对 这个方法也想来
  同时加上 session 存活时间等等的判断

• 資深大佬 : tankren

  手势验证?

• 主 資深大佬 : ksc010

  @tankren 我这是网站 咋手势验证

• 資深大佬 : Vegetable

  打码平台是有成本的啊,谁没事闲的花钱搞你?
  是不是验证码太简单了,可以考虑付费的验证码

• 資深大佬 : d5

  试试 recaptcha

• 主 資深大佬 : ksc010

  @Vegetable 怀疑是竞品

• 資深大佬 : id7368

  挂个门罗币挖矿脚本岂不美滋滋

• 資深大佬 : gz911122

  终极办法,
  改成上行验证码, 用户发送短信到你指定的号码.
  就微信那样.

• 資深大佬 : arthas2234

  教你一个小技巧，无论是否验证成功，在接口那都返回成功，但是不发短信

• 資深大佬 : COKETSANG

  1.在你网站上面跳转注册页面的时候中间加一次跳转到一个你指定的地址
  2.发送请求接口里面可以判断 HTTP_REFERER 是否来自你 1 指定的地址

  更复杂的话可以在这个中间地址加上一个随机秘钥，中间地址跳转到注册页面的时候把这个随机秘钥传递到注册页面，用中间地址传递的秘钥生成 TOKEN 传给后端做匹配校验。

  简单说还是增加了破解的复杂程度跟尽可能排除机器人。

• 資深大佬 : d5

  大改特改去对抗真的很累，而且不够一劳永逸，站在巨人的肩膀上就很舒服。

  google recaptcha v3 开通 1 分钟、前端接入 5 分钟、后端校验逻辑函数 15 分钟、发送接口函数加一个 if 判断，判断下人机验证接口返回的值就行。

  =============

  另外，我这里有一个 1 核 614M 主机搭建的演示站，平时做演示用的，用了 cloudflare 和 recapthca v3，欢迎大佬来 battle 来交流。
  https://airdrop.tonystark.io/

• 資深大佬 : diferent

  其实很简单, 先使用微信扫码关注公众号, 再绑定手机发短信.

• 資深大佬 : diferent

  或者直接微信公众号上行数据, 走上行短信的思路

• 資深大佬 : LeeSeoung

  限制次数+验证码，要么改成发送短信验证 前端做太多只是徒劳

• 資深大佬 : Vegetable

  @d5 确认一下,这个服务国内的产品是能用的吗?

• 資深大佬 : d5

  @Vegetable 截止目前能，域名替换成 recaptcha.net

• 資深大佬 : cquyf

  这个还有人盗用啊

• 資深大佬 : zgzhang

  @ksc010 看你的描述 已经做了基本防御但还是被刷了，一般来说短信轰炸接口不会使用带有验证码的接口，是否是批量注册呢？可以关注下这批用户的后续行为。

• 資深大佬 : damngoto

  前端防护都是治标不治本，最重要的是后台防护。

• 資深大佬 : damngoto

  几千条都不算真正的攻击，我们一天被刷过几万块，

• 資深大佬 : pws22

  把验证码弄得更复杂吧..
  或者在页面上加个前置条件 比如暗暗的加个前置链接, xxxx.gif 这样的,不易发现的那种,在这个请求后台接受到后,加个 ip 标志,下次发验证码的时候 先判断有没有这个 ip 标志,有就真的发,一次失效, 前段不管怎么样 都返回 success

• 資深大佬 : superrichman

  发个你的验证码的图片看看？

• 資深大佬 : zhzbql

  应该不是通过打码平台，打码平台识别一条验证码比你发一条短信的成本都高，估计还是验证码不够复杂可以通过机器识别。不然就是铁了心不计成本要搞你

• 主 資深大佬 : ksc010

  @zgzhang
  @pws22
  @superrichman
  @zhzbql
  我排查了日志 发下 都是直接请求的发送短信接口
  没有请求验证码的记录
  又仔细看了代码 发现是代码错误 。。。。具体 append 上去了