目录：
前言
漏洞挖掘
复现漏洞的步骤
小贴士
希望大家一切顺利！今天，我将分享一个在 HackerOne 公开项目 中发现的逻辑漏洞。所以，话不多说，让我们直接进入正题。
前言
这个漏洞出现在 HackerOne 的某个公开项目 中。由于它尚未修复，我们暂且将该项目称为 target.com。
该漏洞允许我 绕过邮件验证，也就是说，我可以使用任何电子邮件地址注册，而无需真正拥有该邮箱。
漏洞挖掘
我的测试方法是先注册一个账户，并探索主域及其功能——最初不使用 Burp Suite 或任何工具，而是试图彻底理解该应用的逻辑。
随后，我开始检查 登录、注册、重置密码等涉及身份验证的功能，以寻找可能的漏洞。
然而，不幸的是，这些功能都很安全，没有发现明显的安全问题。
但我注意到，该应用在注册过程中需要邮件验证。于是，我想到：是否可以绕过这个验证？
首先，我分析了发送到邮箱的验证链接，检查其生成方式是否存在配置错误。我关注的常见问题包括：
可预测的令牌 —— 如果令牌易于猜测，我可以尝试暴力破解。
-编码的邮箱值 —— 如果令牌包含我的邮箱地址，并且使用了 Base64 或 URL 编码，那么我可以尝试篡改。
可篡改的参数 —— 如果链接中包含 email 或 user_id 之类的参数，我可以修改它们以尝试绕过验证。
然而，不幸的是，这些问题都不存在 —— 该令牌强大且不可预测。
于是，我决定放弃邮件验证的思路，转而测试应用的其他功能，看看是否能找到有趣的漏洞。
我首先检查了 个人资料页面，因为这通常是 CSRF、CORS 配置错误、缓存欺骗、IDOR 以及其他漏洞的高风险区域。
但很快我发现，我无法修改敏感信息，如 邮箱 或 用户名。唯一可编辑的字段仅限于基本信息，如 性别、身高等非关键数据。
此时，我决定分析负责更改用户信息的请求。
我注意到，任何我修改的参数都会以键值对的形式出现在JSON 请求体中。
就在这时，我突然灵光一闪
还记得邮箱验证吗？
如果网站只是在用户界面上阻止了邮箱修改，但后台并没有进行相应的限制呢？
没错！ 这正是你现在想到的 😏
我立刻测试了一下，修改了请求：
我将 键从 genderIdentity 改为 email。
我将 值 设置为一个 新邮箱。
然后，你猜怎么着？
邮箱直接更新了，完全不需要任何验证！
这意味着攻击者可以使用任意受害者的邮箱注册账户，绕过邮箱验证，甚至可能冒充受害者身份在平台上活动。
复现漏洞的步骤：
1️⃣ 在 target.com 注册一个新账号，使用任意虚假邮箱完成注册并验证邮箱。
2️⃣ 进入个人资料设置，这里可以修改用户的个人信息。
3️⃣ 使用 Burp Suite 捕获更新用户信息的请求（例如性别、身高等）。
4️⃣ 修改请求的 JSON 数据：
将 键 从 "genderIdentity"（或其他可编辑字段）改为 "email"。
将 值 设置为你想更改的新邮箱.
5️⃣ 发送修改后的请求到服务器。
6️⃣ 结果： 邮箱成功更新，无需任何验证，攻击者即可使用受害者的邮箱完成注册。
小贴士：
永远不要完全依赖用户界面！许多在 UI 上看似受限或不可用的操作，可能仍然可以通过 后端 API 直接访问。 直接测试 API 请求，你可能会发现隐藏的漏洞。
我最初将此漏洞报告为中等严重性，但公司工作人员将其升级为高危漏洞。
