Bots flooded my anti-bot startup with 55,000 fake signups：一次反制机器人的初创公司的“自爆”实录

背景

在网络安全领域，尤其是反机器人（Anti-bot）产品领域，信任是产品的基石。然而，一家名为 useHUMA 的初创公司最近经历了一场极具讽刺意味的危机：他们向用户出售机器人检测服务，自己却未能守住自家注册页面的防线。

据创始人披露，他们在周二晚上检查数据库时，发现注册表中出现了令人震惊的异常。原本用于展示增长曲线的图表看似强劲，但仔细查看数据后发现，这背后是整整 555 页的虚假注册记录。这些注册并非来自真实用户，而是来自精心构造的自动化脚本。这一事件不仅暴露了产品在实际应用中的漏洞，也揭示了初创公司在基础设施防护上的常见盲区。

核心内容

发现：深夜的“繁荣”假象

周二晚上 11 点，创始人打开 Supabase 数据库编辑器检查一些无关事项时，发现 developers 表的数据量异常沉重。滚动查看后，他发现每一行的名字都惊人地一致：“🎁 Dene Hemen! 5K Lira Bonusunu Yakala”（土耳其语，意为“试试！领取 5,000 里拉奖金”）。这是典型的赌场垃圾邮件内容。

随着滚动继续，页面从第 2 页一直延伸到第 555 页。这意味着有超过 55,000 个虚假账号涌入。讽刺的是，作为一家销售机器人检测产品的公司，他们的注册表单被机器人淹没。如果只看增长曲线而不看用户名，这看起来像是一次爆炸式的成功增长。

根因分析：为什么防线崩溃？

创始人将这次攻击归咎于三个主要漏洞：

1. 注册接口缺乏速率限制（Rate Limiting） 公司的公共 API 端点从第一天起就实施了基于套餐的速率限制，但营销网站的注册页面却仅依赖一个“蜜罐字段”（Honeypot field）和美好的愿望。蜜罐字段只能捕获那些会渲染表单的“礼貌”机器人。而这次攻击的脚本直接向端点发送 POST 请求，数千次地绕过前端，甚至从未加载过隐藏字段，因此完全无视了蜜罐陷阱。

2. 错误地“吃狗粮”（Dogfooding） 这是最尴尬的一点。注册流程确实调用了公司自己的机器人检测 API。但为什么没有拦截这 55,000 个机器人？ 因为调用时只传入了 userId，没有任何行为信号。useHUMA 的核心评分机制依赖于行为数据：鼠标移动、按键节奏、滚动韵律、触摸模式等。由于没有提供这些信号，引擎返回了中性分数。中性分数通过了公司的阈值设置，导致所有机器人都被放行。

3. 每个虚假注册都触发了真实邮件 每次注册都会触发一封验证邮件。55,000 次注册意味着向虚假地址发送了 55,000 封邮件。这种退信风暴（Bounce Storm）通常会导致发送域名被列入黑名单。 幸免原因：邮件提供商的免费层级每日发送上限充当了“意外断路器”。此前让人略感烦恼的发送限制，在关键时刻阻止了洪水般的发送，从而保护了域名的信誉。

修复：一夜之间的四步行动

创始人在当晚睡觉前部署了四项更改：

1. 注册接口的 IP 级速率限制：限制为每分钟 5 次。复用了 API 已有的原子计数器，仅约 12 行代码。
2. 生命周期邮件过滤： drip 邮件和试用提醒现在仅发送给 email_verified = true 的用户。垃圾行不再接收邮件。
3. 清理垃圾数据：通过安全匹配模式删除了 113,000 行垃圾数据。
4. 建立监控习惯：每周执行一次 SQL 计数查询。创始人强调：“你不看的监控，等于没有监控。”

后续更新：真正的“吃狗粮”

本周稍后，公司发布了更彻底的修复：注册表单现在在客户端收集完整的行为信号，并在每次注册时进行评分。任何不带信号提交的请求都会被直接拒绝。创始人的注册表单终于像他们告诉客户那样使用了 useHUMA。正如他所言：“相机终于对准了门口。”

关键要点

• 速率限制是基础中的基础：它不是后期的加固任务，而是前门的锁。必须在每个公共 POST 端点实施基于 IP 的低上限速率限制。
• 蜜罐字段无法阻挡直接 POST 攻击：蜜罐只能过滤掉懒惰的机器人。必须为那些根本不加载 HTML 的脚本做好准备。
• 正确“吃狗粮”，否则不如不做：没有行为数据的反机器人 API 调用，就像穿着一件实验服掷硬币，结果纯属随机。
• 免费层级的限制可能是意外的断路器：在升级限制之前，要知道哪些限制正在保护你。
• 垃圾邮件看起来像增长，直到你阅读内容：55,388 个“注册”和 12 个真实客户。虚荣指标（Vanity metrics）可能是由机器人编写的。
• 攻击即内容：这篇文章的存在本身就源于一次攻击。火灾过后，最有用的东西就是关于火灾如何开始的故事。
• 透明是核心卖点：useHUMA 的 pitch 是机器人检测应该是透明的——没有黑盒、没有个人身份信息（PII）、没有表演。这包括在自家产品出现漏洞时保持透明。
• 通过行为验证人类：没有 CAPTCHA，没有谜题，零 PII。只需一次 API 调用——现在已正确实施速率限制，问问我们是怎么知道的。

意义与影响

这次事件对 SaaS 和网络安全行业具有多重启示：

1. 信任与透明度的辩证关系： 对于像 useHUMA 这样以“透明”和“无黑盒”为核心卖点的公司，公开承认自己的失败反而增强了品牌可信度。这种“修鞋匠的孩子赤脚”（cobbler's children go barefoot）式的坦诚，向市场展示了他们敢于直面问题并迅速修复的决心，从而将危机转化为营销素材。

2. 基础设施安全的“最后一公里”问题： 许多初创公司专注于核心 API 的安全防护，却忽视了面向公众的营销页面（如注册表单）。这次事件表明，即使是核心产品内部，如果配置不当（如未传递行为信号），同样会失效。安全是一个整体，不能存在盲区。

3. 监控的重要性： “你不看的监控，等于没有监控。”定期的人工检查（如每周 SQL 查询）比自动化的告警有时更为有效，特别是在自动化系统可能因逻辑漏洞而被绕过时。

4. 对“虚荣指标”的警示： 在增长黑客文化盛行的今天，数据造假（尤其是机器人刷量）是一个普遍问题。企业必须建立数据清洗和验证机制，区分真实用户增长与机器噪音，避免被虚假的繁荣误导战略决策。

5. 防御策略的层次性： 单一的安全措施（如蜜罐）往往不足以应对有预谋的攻击。必须采用纵深防御策略：前端行为分析 + 后端 API 速率限制 + 邮件发送限制 + 人工监控。任何一环的缺失都可能导致防线崩溃。