当注册表单成了帮凶：一场“邮件轰炸”暴露了互联网最被低估的安全漏洞

一家小公司发现：自己的欢迎邮件，正在替骗子打掩护

这类安全新闻最让人不安的地方，往往不在“系统被攻破”，而在“系统明明没坏，却还是成了武器”。

SaaS 产品 Suga 最近就碰上了这样一幕。团队先是发现一批新用户很古怪：注册后什么都不做，不创建组织、不建项目、不发部署，像是刚进门就原地消失。再仔细一看，用户名更像随机字符串，什么 PfVQXvYTXjwSbEeJBjXYy、xXzMafkbPLjOaGgDaOGZjLx，一眼就不是正常人会起的名字。奇怪的是，这些账号对应的邮箱都是真实可投递的，欢迎邮件也确实发出去了。

这不是传统意义上的撞库，也不是 DDoS。它更像一种“借刀杀人”：攻击者根本不在乎 Suga 这个网站本身，他们要的是借用网站的注册和找回密码功能，往真实受害者的邮箱里疯狂塞邮件。欢迎信、验证信、重置密码邮件，三连发，一分钟内送达。单看一封你可能只会皱皱眉，但如果几百个网站同时这么干，邮箱很快就会变成垃圾堆。

而垃圾堆里，偏偏会埋着最重要的那几封邮件：银行密码被重置、信用卡被申请、账户邮箱被修改、陌生订单确认……攻击者要的从来不是你在 SaaS 网站上的账号，而是让你错过真正的安全警报。

“订阅轰炸”不新鲜，但它越来越适合今天的互联网

这种攻击有个名字，叫 subscription bombing，直译过来就是“订阅轰炸”或“注册轰炸”。它其实不是新花样，早在多年前，安全圈就讨论过类似手法：攻击者利用海量网站、论坛、商店、邮件列表的注册入口，把同一个受害者邮箱批量提交出去，让他的收件箱在短时间内爆炸。

为什么这招在今天依然有效，甚至更危险？因为互联网的产品形态变多了，门槛却更低了。过去做一个带邮件系统的网站还需要点工程能力，现在大量初创公司直接接入现成的认证服务、营销自动化、事务邮件 API，十分钟就能上线一套注册流程。开发效率当然是好事，但很多团队也因此把“邮件应该在什么时机发给谁”这件事，处理得过于轻率。

说得直白一点，很多网站默认相信“只要有人在表单里填了邮箱，我就可以给这个邮箱发一串邮件”。这在增长团队看来很自然，在安全视角下却相当危险。因为邮箱并不是一个人随手填的昵称，它本身就是身份凭证的一部分。只要产品允许第三方替别人触发邮件，攻击者就获得了一台低成本、分布式、合法外衣包裹下的“骚扰机器”。

更麻烦的是，这种攻击几乎不会像传统攻击那样制造明显噪音。Suga 团队观察到，机器人流量并不大，每小时也就一两次注册，请求来源还分散在印度、巴西、罗马尼亚、美国、越南、土耳其等地。没有突发洪峰，没有服务器告警，没有压垮系统的并发，看上去只是“几位奇怪用户”。如果团队没有认真盯用户激活率，很多公司大概根本意识不到自己已经被黑产借走了。

最危险的地方在于：受伤的不是平台，所以平台很容易不着急

这是我觉得这件事最值得写的一点。订阅轰炸之所以顽固，不是因为它技术含量多高，而是因为它把伤害精准转移给了第三方。

对网站运营者来说，损失通常不大。邮件量不高，发件信誉未必会立刻受损；服务器压力不高，监控也未必会报警；转化漏斗里多几个僵尸账号，很多增长团队甚至未必第一时间在乎。可对受害者来说，那是另一个故事。你早上醒来，看到收件箱里躺着 200 多封你从没听过的产品欢迎信，第一反应肯定是清垃圾。偏偏就在你狂点删除的那几分钟里，真正该看的那封银行提醒、支付确认或者密码修改通知，被淹没了。

这也是为什么我一直觉得，互联网产品对“邮件发送权”的态度，应该比今天谨慎得多。发送一封邮件，在公司后台看只是一个 API 调用；落在用户身上，却可能是一次真实的骚扰、一场诈骗链条中的烟雾弹。很多团队把这类问题归进“风控优化”或“反机器人体验”，优先级靠后，但从社会影响看，它更接近平台责任问题。

你可以把它类比成开放中继邮件服务器在早年垃圾邮件泛滥中的角色：不是每一台服务器的管理员都有恶意，但只要系统设计允许被滥用，它就会在更大的黑产生态里变成基础设施。今天的注册表单、找回密码页面，在某种意义上也正在扮演这样的角色。

这家公司怎么止血：不是靠更狠的限流，而是改掉默认逻辑

Suga 的处理方式很有代表性，也很值得其他团队抄作业。

他们一开始尝试从防火墙入手，加强前端托管平台上的机器人检测。结果只成功拦住了一部分，6 个小时里仍有漏网之鱼。这不难理解，因为订阅轰炸本来就不是靠暴力请求取胜。你对每秒几千次请求的机器人做限流很有效，但对“每小时来一两个、动作还故意装得像真人”的机器人，传统限流几乎无能为力。

团队后来启用了 Cloudflare Turnstile，这是一种比传统 CAPTCHA 更轻量的挑战机制。它不会总让用户去点红绿灯、认自行车，而是更多在后台判断浏览器信号，发现可疑时再触发额外校验。配合 Better Auth 的现成插件，Suga 很快把注册、登录和找回密码几个入口都接上了验证。部署后，机器人注册基本停了。

但真正更关键的一步，不是上验证码，而是修改邮件发送策略：在用户点击验证链接、证明自己确实拥有该邮箱之前，系统只发送一封验证邮件，不再发欢迎信、产品通知，也不继续触发其他自动化流程。这个改动看起来很小，意义却很大。它相当于把“任何人都能替你触发三四封邮件”，改成了“最多只会收到一封验证信”。如果你没点，那事情就到此为止。

这其实暴露了很多产品设计里一个常见误区：大家把“注册成功”视为营销旅程的起点，于是欢迎邮件、引导邮件、功能推荐邮件一股脑自动接上；但在安全视角里，真正的起点应该是“邮箱所有权已经被证明”。在此之前，所有热情洋溢的欢迎，都可能欢迎错了人。

订阅轰炸会越来越常见吗？恐怕会，而且 AI 还会帮它“更像人”

Suga 团队提到一个很有意思的细节：这些机器人在输入框里逐字符慢慢打字，间隔还带随机延迟，显然在模仿真人。但它模仿得太机械了，像一个认真研究过“人类会停顿”，却没有真正观察过人类怎么打字的脚本。

这让我想到一个更现实的问题：今天的机器人还会因为“随机得不自然”而露馅，明天呢？随着自动化工具、浏览器指纹伪装、AI 驱动的交互脚本越来越成熟，这种低频、低噪音、跨站点的攻击只会更难发现。它不需要攻破你的网站，不需要高超权限利用，只需要互联网还保留着大量“先发邮件、后验身份”的老习惯。

这也是为什么我不太认同一种常见看法：认为这只是“小网站的小麻烦”。恰恰相反，正因为门槛低、收益高、风险分散，它才适合大规模复制。一个攻击者不需要控制一万个肉鸡，也不需要打穿一万家公司的防线，他只需要写好自动化脚本，批量调用一万个“设计松散”的注册入口，就能给受害者制造几乎同等规模的混乱。

更值得行业思考的是，验证码会不会伤害用户体验？答案当然是会，尤其在移动端和弱网环境下，再“无感”的校验也不是零摩擦。但如果把体验与责任放在天平两端，我的判断是：在注册、密码重置这类高风险入口，适度摩擦比无条件顺滑更值得。互联网过去几年太迷恋“丝滑转化”，以至于我们常常忘了，某些看似流畅的设计，代价是把外部用户暴露给滥用风险。

从更大的行业背景看，随着各类身份服务、邮件 API、无代码表单和营销自动化工具越来越普及，这不是某一家产品该补的漏洞，而是一整套默认范式该升级的信号。邮箱验证前只发一封确认邮件，重置密码流程加上更聪明的机器人拦截，对异常地理分布与时区行为做关联分析——这些措施今天看已经不算“高级安全能力”，而应该是现代互联网产品的基本礼貌。

说到底，注册表单从来不只是增长入口，它也是公共互联网的一部分。你以为你在做转化漏斗，黑产看到的却可能是一门现成的生意。