通过IDOR漏洞实现账户接管：从用户ID到完全控制

在发现同一应用程序中存在泄露敏感用户数据的未授权端点后（参见我之前的报告），我预感还有更多漏洞等待发掘。该应用程序行为异常，我仍在通过匿名会话进行探索。

浏览个人资料设置页面时，我注意到输入字段都是空白的。这可能是因为会话没有关联真实用户。尽管如此，我决定填写这些字段并观察后台发生的情况。

当我提交表单并捕获请求时，请求结构中的某些内容引起了我的注意。虽然很细微，但足够有趣，值得深入研究。

1. 一切的起点：PII泄露

在同一应用程序的早期测试中，我发现了一个未授权端点，该端点暴露了详细的用户信息。通过操纵factoryId参数，我能够枚举不同租户的用户并获取敏感字段，如姓名、邮箱地址、电话号码和管理员标志，所有这些都不需要身份验证：

该漏洞已经引起了担忧，但我在那里发现的用户数据最终在这个第二次发现中发挥了关键作用。

重新审视之前发现的数据后，我决定回到应用程序中，尽可能多地与各种功能交互。我点击了所有可见选项，试图了解在匿名会话中可用的功能类型。

就在这时，我找到了个人资料设置页面。

起初，页面看起来是空的。所有输入字段都是空白的，没有填充任何用户数据。但我很好奇。我用虚拟值填写了每个字段，并在拦截请求的同时提交了表单。Burp中捕获的内容引起了我的注意。

注意：此截图是在复制原始应用程序行为的本地测试环境中捕获的。此处演示的漏洞行为与实际目标中的行为相同。

在Burp Suite中提交表单并拦截请求后，我仔细查看了请求：

我将查询参数（id）和请求体（User.Id）中的默认用户ID替换为我之前在PII枚举期间识别的真实用户ID。

我保持其他所有内容不变，只更改了一个字段：邮箱地址。

当我转发请求时，服务器返回了302 Found状态，并将我重定向到/users/u001：

该路径本身再次重定向回空白个人资料设置页面，就像之前一样。用户界面没有任何迹象表明更新是否成功。

提交修改后的请求后，我想确认除了用户界面之外，更改是否产生了实际影响。具体来说，我想看看应用程序是否在账户相关工作流程中使用了更新后的邮箱地址。

我在登录页面上找到了密码重置功能，并输入了测试期间使用的新邮箱地址：pwned@example.com。不久之后，我收到了一封包含有效重置链接的密码重置邮件。

这证实了应用程序已成功更新用户的邮箱，并依赖该字段进行账户恢复。在真实场景中，这将允许恶意行为者通过触发密码重置来完全控制其他用户的账户。

为避免造成干扰，我立即使用相同的请求格式将邮箱地址恢复为原始值。没有采取进一步行动。

这足以完全确认漏洞并证明其严重性，而不会造成任何持久影响。

在验证影响并恢复受影响的数据后，我向项目提交了详细报告。我包含了完整的重现步骤、修改后的请求以及通过密码重置流程进行的确认。

响应迅速且专业。问题在提交后不久得到确认、重现和分类。

由于该漏洞可能允许在无需身份验证的情况下完全接管账户，因此被评估为严重漏洞。

只需一个被遗忘的检查，就能完全打开大门。