reCaptcha v3无法拦截支付注册机器人的原因及低成本解决方案

• 部署覆盖范围不足：reCaptcha v3的评分依赖用户全访问路径的行为采集，你目前仅在2个高流量页面部署代码，机器人可以直接跳过这些页面，构造请求直连注册、支付接口，甚至盗用其他站点生成的有效高评分token提交，完全不触发你站点的验证码采集逻辑。
• 冷启动阶段模型精度不足：reCaptcha v3上线后需要3-7天的站点特征学习周期，需要积累足够的正常用户行为、异常流量特征才能建立准确的评分基线，你上线仅半天就要求0.9阈值的拦截精度，本身就不符合产品的运行逻辑，这段时间的评分普遍存在虚高问题。
• 后端校验逻辑存在明显漏洞：从你贴的校验代码来看，存在三个可被直接利用的缺陷：

  //captcha verification
  if(!request.v) return error(401, "Error");
  console.log("Captcha tracking, ", "start")
  var captchaResp = await fetch(
      "https://www.google.com/recaptcha/api/siteverify?secret=SECRETKEY&response=" + request.v + "&remoteip=" + event.requestContext.identity.sourceIp);
  const captchaRespJson = await captchaResp.json();
  console.log("Captcha tracking, ", captchaRespJson)
  if (!(captchaRespJson.success==true && captchaRespJson.score >= 0.9)) {
      console.log("Captcha tracking, ", "error")
      firebase.auth().deleteUser(decodedToken.uid);
      return error(401, "Error");
  }
  console.log("Captcha tracking, ", "all done")
  //end captcha verification
  

  1. 没有校验token有效期：reCaptcha生成的token有效期仅为2分钟，你没有校验返回结果中的challenge_ts字段，机器人可以从打码平台批量购买真人验证过的高评分token反复复用。
  2. 没有校验token归属：没有校验返回结果中的hostname字段，无法确认token是不是你自己的站点生成的，其他站点的高评分token也能通过你的校验。
  3. 没有校验操作场景：reCaptcha v3生成token时会绑定对应操作的action标识（比如注册、提交支付），你没有做action匹配校验，拿其他页面生成的高评分token也能通过支付接口的校验。
• 高级自动化工具的行为模拟：目前成熟的卡测机器人已经可以模拟真人鼠标轨迹、页面停留、滚动行为，搭配住宅代理、真实浏览器指纹，完全可以拿到0.9以上的评分，单靠0.9的分数阈值不可能拦住所有这类攻击。
• 蜜罐规则被识别：如果你的蜜罐字段用了website、hp_input这类常见蜜罐命名，或者直接用display:none、visibility:hidden做隐藏，很容易被机器人的规则库识别，自动跳过填充后根本触发不了拦截。

• 先修正reCaptcha的配置和校验逻辑
  • 全站所有页面加载reCaptcha v3脚本，不要只部署在2个高流量页面，让模型可以采集用户从进入站点到提交支付的全链路行为，等上线满7天模型稳定后，再根据实际的正常用户、异常用户的分数分布调整阈值，不要刚上线就死卡0.9。
  • 补全后端校验规则：除了校验success和score字段，必须同时校验三个字段：challenge_ts确认token生成时间在2分钟有效期内，hostname确认token是本站点生成，action确认token对应的操作和当前请求匹配，彻底杜绝token复用、跨站盗用的问题。
  • 优化蜜罐逻辑：不要用常见的蜜罐字段名，不要直接用CSS隐藏属性做蜜罐，可以用绝对定位把蜜罐输入框移到屏幕可视区域外，或者设置极低的z-index放在正常页面元素下方，保证真人看不到、填不了，只要蜜罐字段有内容直接拦截请求。
• 注册环节前置拦截
  • 加一次性邮箱黑名单：从开源渠道获取公开的一次性邮箱域名列表，注册时校验邮箱后缀，命中黑名单直接禁止注册，不需要调用付费API就能拦住80%以上的批量注册机器人，定期更新黑名单即可。
  • 加频率限制：按IP、IP段做限流，比如单个IP1小时内最多允许注册3个账号，24小时内最多发起5次支付请求，超出阈值直接临时封禁，卡测机器人都是短时间批量发起请求，这个规则的拦截效率极高。
  • 加基础环境校验：注册、支付提交时，在前端校验是否存在真实浏览器特征，比如window.navigator对象是否正常、屏幕分辨率是否在常规范围、页面加载后是否有鼠标/键盘交互记录，无头浏览器、自动化工具默认会缺失很多真人特征，直接拦截这类异常请求即可。
• 支付环节针对性拦截
  • 用好Stripe自带的免费反欺诈能力：Stripe免费版的Radar反欺诈系统支持自定义规则，可以直接配置规则拦截：注册后10分钟内发起的支付请求、同一张卡短时间内绑定多个账号的请求、CVC/邮编校验失败超过2次的IP发起的请求，Stripe本身掌握全球卡测攻击的黑名单数据，拦截准确率远高于通用验证码。
  • 给新用户加短冷却期：新账号注册成功后15分钟内不允许发起支付，正常用户几乎不会受这个规则影响，但卡测机器人都是批量注册后立刻打支付接口，不会等待冷却时间，能拦住绝大多数自动化攻击。
• 兜底二次校验：如果某个IP/账号触发2次支付失败，再弹出reCaptcha v2复选框做二次验证，平时不弹出不影响正常用户体验，只对异常流量做校验，不需要额外成本。

reCaptcha v3刚上线确实需要数据积累周期，一般为3-7天，这段时间模型没有建立你站点的正常用户行为基线，评分参考价值很低，刚上线半天出现漏拦是正常现象。但你当前的部署方式和校验逻辑本身存在明确的可利用漏洞，就算等模型完成冷启动，依然会有大量机器人绕过，必须先把上述配置缺陷修复。

内容的提问来源于stack exchange，提问作者Mathias Paicheler