众所周知，在很多海外的漏洞悬赏项目中，单纯的“邮件轰炸（Email Bombing）”往往因为影响有限而被直接标为 N/A（不接受）或者 Informative（仅提供信息）。但就在前几天的一个周末，我在某海外厂商的授权测试中，通过巧妙利用注册与登录流中的“状态机滥用（State Abuse）”，成功打出了一套无限制邮件轰炸的组合拳。
本以为这个漏洞会被无情打回，但出乎意料的是，安全团队不仅光速确认了漏洞（CVSS 评分给了 Medium），还发放了一笔相当丰厚的欧元赏金和平台积分！这让我十分兴奋。今天，我就来和各位师傅复盘一下这个藏在正常业务逻辑背后的“隐蔽杀手”。
0x01 故事背景
故事的起点是一个普通的单点登录（SSO）门户：https://auth.redacted.com/。
当时我正在对目标站点的资产进行常规梳理，发现大部分边缘资产的防御都非常严密，WAF 拦截也很严格。抱着“回归本质”的心态，我决定死磕它的核心业务逻辑——也就是用户的认证模块（Authentication）。
我习惯性地测试了常规的 SQL 注入、XSS 和简单的越权，全部石沉大海。然而，当我的目光落在“注册（Sign Up）”与“登录（Sign In）”的交互流程上时，作为攻击者的直觉告诉我：凡是涉及到多步验证的状态切换，往往容易存在逻辑断层
0x02 信息收集
我梳理了一下该网站正常的账号注册流程：
1.用户在注册页面输入邮箱（如 victim@example.com）和自定义密码。
2.提交后，页面跳转到一个【输入验证码】的界面。
接着，用户的邮箱会收到一个 6 位数的验证码，然后用户输入验证码，完成验证，账号激活。
在这个流程中，如果你想通过注册接口进行邮件轰炸，往往会遇到一个问题：同一个 IP 在短时间内频繁请求注册接口，会触发 WAF 封禁；或者系统检测到该邮箱已注册但未激活，拒绝发送新的邮件。
我在测试的时候，也的确如此
“如果我偏不按套路出牌呢？”
本以为顺着注册接口死磕是唯一的出路，然而，接下来的发现推翻了我的假设。我开始思考：系统是如何处理一个“已提交注册，但尚未完成邮件验证”的半成品账号的？
0x03 漏洞利用
这就是这篇文章的核心。我放弃了对注册接口的暴力破解，而是将目光转向了登录接口。下面是我的攻击链重构（PoC 步骤）：
Step 1：播下种子（发起注册）
在注册页面，我输入了攻击目标的邮箱地址 victim@example.com，并随意设置了一个密码（例如 Test_On_YWH_711）。点击注册。
Step 2：战略性撤退（中断状态机）
系统如期跳转到了那个需要输入 6 位验证码的页面。在这里，我直接关掉了这个页面，或者点击返回，彻底忽略它。
为什么这么做？因为在真实攻击场景中，受害者的邮箱在你手里是盲区，你根本拿不到验证码。我需要让这个账号在后端的数据库中悬停在“Unverified（未验证）”的状态，也是利用这个auth登录工作流的缺陷
Step 3：触发漏洞（逻辑滥用）
我重新回到了登录界面（Login Page）。在账号密码处，我分别输入了目标邮箱 victim@example.com 以及我刚刚自定义的密码 Test_On_YWH_711，然后点击“登录”。
Aha Moment” 出现了！
由于后端校验到我的账号密码是正确的，但状态是“未激活”，它的业务逻辑并没有提示“请前往邮箱查看验证码”，而是自作聪明地直接触发了一次新的邮件发送动作，并将我重定向到了验证页面！
更致命的是，负责处理这个重定向登录逻辑的 /login-actions/required-action 接口，没有任何频率限制（Rate Limiting），也没有 IP 限制，更没有验证码（CAPTCHA）保护！
因此，只需要不断地重复以上操作，先输入目标受害者的邮箱，密码自拟，让网站后端将该邮箱列入未验证的状态，再不断地用我们自拟的密码重复登录流程，就会一直不停的发验证码到邮箱中，没有任何速率限制，完全可以依赖自动化脚本进行，最后我也是成功验证了漏洞
0x04 漏洞影响
很多开发者觉得邮件轰炸只是“恶作剧”，但作为一个严谨的安全研究员，我们在写报告时必须将其危害场景化，这也是这份报告能被厂商认可并给予丰厚奖励的关键原因：
- 掩盖真实警报（Alert Masking）：黑客在对受害者进行核心账户盗取（如网银、主邮箱密码重置）时，可以利用此漏洞疯狂发送垃圾验证邮件。受害者在面对几百封相同的邮件时，很容易漏掉其中夹杂的那封“真实危险告警邮件”。
- 企业信誉受损（Reputation Damage）：大量的垃圾邮件会消耗企业的邮件网关资源（如 AWS SES、SendGrid），不仅会产生额外的服务费用，还可能导致该企业的发信域名被各大邮箱服务商（Google, Outlook等）标记为 Spam（垃圾邮件），严重影响正常业务。
以下是我在漏洞报告中对危害影响论证的原文：
最后厂商也是接受了报告并顺利发放了奖励
0x05 防御与反思
从攻击者回归建设者，这个漏洞的根源（Root Cause）在于：状态机设计缺陷与防御颗粒度不均。开发人员可能在注册接口做了严格的防刷机制，但却忽略了“登录流触发再次验证”这个边缘场景的限频。
针对此类业务逻辑漏洞，我给出以下加固建议：
- 统一限频策略：不仅要在注册（Sign Up）接口限制发信频率，对于所有能触发邮件发送的底层动作（如重新发送验证码、未验证用户登录重定向），都必须接入全局的 Rate Limiting 策略（例如针对单一 Email 限制每分钟最多发送 1 次，每天最多 10 次）。
- 引入人机校验：在重复触发敏感操作（如发送短信/邮件）时，必须强制要求完成 CAPTCHA 验证，阻断自动化脚本的重放攻击。
- 状态隔离：对于未激活的账号，登录时不应默认自动发送邮件，而是应当提示用户“账号未激活”，并提供一个受限流保护的“重新发送”按钮。