用户界面拒绝,后端放行-记一次邮件验证bypass
用户界面拒绝，后端放行 – 记一次邮件验证bypass
希望大家一切顺利！今天，我将分享一个在 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 请求 ，你可能会发现隐藏的漏洞。
我最初将此漏洞报告为 中等严重性 ，但公司工作人员将其 升级为高危漏洞 。
