HELLO HACKERS,

希望大家一切顺利！今天，我将分享一个在 HackerOne 公开项目 中发现的逻辑漏洞。所以，话不多说，让我们直接进入正题。

前言

这个漏洞出现在 HackerOne 的某个公开项目 中。由于它尚未修复，我们暂且将该项目称为 target.com。

该漏洞允许我 绕过邮件验证，也就是说，我可以使用任何电子邮件地址注册，而无需真正拥有该邮箱。

漏洞挖掘

我的测试方法是先注册一个账户，并探索主域及其功能——最初不使用 Burp Suite 或任何工具，而是试图彻底理解该应用的逻辑。

随后，我开始检查 登录、注册、重置密码等涉及身份验证的功能，以寻找可能的漏洞。

然而，不幸的是，这些功能都很安全，没有发现明显的安全问题。

但我注意到，该应用在注册过程中需要邮件验证。于是，我想到：是否可以绕过这个验证？

首先，我分析了发送到邮箱的验证链接，检查其生成方式是否存在配置错误。我关注的常见问题包括：

可预测的令牌 —— 如果令牌易于猜测，我可以尝试暴力破解。

-编码的邮箱值 —— 如果令牌包含我的邮箱地址，并且使用了 Base64 或 URL 编码，那么我可以尝试篡改。

可篡改的参数 —— 如果链接中包含 email 或 user_id 之类的参数，我可以修改它们以尝试绕过验证。

然而，不幸的是，这些问题都不存在 —— 该令牌强大且不可预测。

于是，我决定放弃邮件验证的思路，转而测试应用的其他功能，看看是否能找到有趣的漏洞。

我首先检查了 个人资料页面，因为这通常是 CSRF、CORS 配置错误、缓存欺骗、IDOR 以及其他漏洞的高风险区域。

但很快我发现，我无法修改敏感信息，如 邮箱 或 用户名。唯一可编辑的字段仅限于基本信息，如 性别、身高等非关键数据。

img

此时，我决定分析负责更改用户信息的请求。

我注意到，任何我修改的参数都会以键值对的形式出现在JSON 请求体中。

就在这时，我突然灵光一闪

img

还记得邮箱验证吗？

如果网站只是在用户界面上阻止了邮箱修改，但后台并没有进行相应的限制呢？

没错！ 这正是你现在想到的 😏

我立刻测试了一下，修改了请求：

img

然后，你猜怎么着？

邮箱直接更新了，完全不需要任何验证！

img

这意味着攻击者可以使用任意受害者的邮箱注册账户，绕过邮箱验证，甚至可能冒充受害者身份在平台上活动。

复现漏洞的步骤：

1️⃣ 在 target.com 注册一个新账号，使用任意虚假邮箱完成注册并验证邮箱。

2️⃣ 进入个人资料设置，这里可以修改用户的个人信息。

3️⃣ 使用 Burp Suite 捕获更新用户信息的请求（例如性别、身高等）。

4️⃣ 修改请求的 JSON 数据：

5️⃣ 发送修改后的请求到服务器。

6️⃣ 结果： 邮箱成功更新，无需任何验证，攻击者即可使用受害者的邮箱完成注册。

小贴士：

永远不要完全依赖用户界面！许多在 UI 上看似受限或不可用的操作，可能仍然可以通过 后端 API 直接访问。 直接测试 API 请求，你可能会发现隐藏的漏洞。

我最初将此漏洞报告为中等严重性，但公司工作人员将其升级为高危漏洞。

img

原文始发于微信公众号（白帽子左一）：用户界面拒绝，后端放行 -- 记一次邮件验证bypass