文章总结： 信用机构门户网站存在IDOR漏洞，攻击者通过未验证的邮箱更新端点修改受害者备用邮箱，结合密码重置实现账户接管。根本原因是端点使用请求参数而非令牌识别用户且邮箱变更未验证。补救建议包括从令牌获取用户ID、实施邮箱验证和通知用户。CVSS9.1，影响包括数据泄露和身份盗窃。 综合评分： 89 文章分类： 漏洞分析,威胁情报,安全建设

0182.IDOR 导致通过电子邮件重新分配进行账户接管

原创

Gambacorta Gambacorta

Rsec

2026年7月7日 15:34 贵州

在小说阅读器读本章

去阅读

本文章仅用网络安全研究学习，请勿使用相关技术进行违法犯罪活动。

声明：本文搬运自互联网，如你是原作者，请联系我们！

类型：账户接管

信用机构面向消费者的门户网站存在一个用户个人资料更新端点，该端点无法验证所有权。攻击者可以修改请求，将其他用户的注册邮箱地址更改为自己控制的地址，然后利用标准的密码恢复流程接管该账户。一个简单的身份识别漏洞（IDOR）与平台自身的密码重置机制相结合，使得原本的个人资料更新漏洞演变成完整的账户接管链。

目标

此次攻击的目标是一家大型信用机构运营的面向消费者的门户网站。该平台允许消费者查看信用报告、管理个人数据并使用与信用相关的服务。鉴于其业务性质（信用数据、个人财务信息、身份验证），该平台上用户账户的敏感性极高。

该门户网站提供了一个 REST API，用于处理所有用户操作，包括个人资料更新、数据检索和身份验证流程。用户通过持有者令牌进行身份验证，并可以通过控制面板管理其帐户详细信息。

发现：个人资料更新端点蕴藏着巨大价值

个人资料更新端点是访问控制测试的宝库。它们通常接受多个用户可控字段（姓名、电子邮件、电话号码、地址），并直接修改用户记录。安全问题始终如一：服务器是根据身份验证令牌确定要更新哪个用户，还是根据客户端提供的参数确定？

我们首先在平台上创建了一个测试账号，然后进入个人资料管理页面。“更新我的数据”操作会触发一个 POST 请求，发送到 /api/v1/user/update ，请求体为 JSON 格式，其中包含用户的个人资料字段。

我们首先测试的是将自己的邮箱地址更改为其他用户的邮箱地址是否会被接受。结果是可以的。无需验证邮件，也无需任何确认步骤。服务器只是简单地更新了我们账户中的邮箱地址。这很有意思，但还不足以构成账户盗用。

然后我们反过来测试：能否更改他人的电子邮件地址？我们修改了请求正文中的 email 地址字段，使其指向另一个用户的帐户，并将辅助电子邮件地址字段设置为我们控制的地址。我们使用自己的 bearer token 发送了该请求。

成功了。

#

服务器并未验证被修改的电子邮件地址是否属于已认证用户。相反，它似乎将请求正文中的 email 地址字段用作查找键来识别目标用户记录，然后将更新（包括辅助电子邮件地址）应用到该记录。

在得出这个结论之前，我们尝试了一些方法，但都失败了。我们尝试在请求中注入额外的字段，看看是否可以修改角色或权限属性，但服务器忽略了未知字段。我们还测试了持有者令牌是否与特定的用户 ID 绑定，以防止跨账户修改。结果表明并非如此。

#

利用漏洞：两起账户接管请求

漏洞利用链很清晰，只需要两个步骤：

第一步：修改受害者的备用邮箱

POST /api/v1/user/update HTTP/1.1Host: [REDACTED]Authorization: Bearer [ATTACKER_TOKEN]Content-Type: application/json

{  "firstName": "unchanged",  "email": "[email protected]",  "secondEmail": "[email protected]",  "address": "unchanged",  "primaryPhone": null,  "mobilePhone": null}

服务器返回了成功响应。此时，受害者的账户记录中已将攻击者的电子邮件地址注册为辅助联系邮箱。

第二步：触发密码恢复

攻击者访问了平台的密码恢复页面，并重置了受害者的账户密码。平台将恢复凭证发送到了账户上所有注册的邮箱地址，包括攻击者刚刚设置的备用邮箱。

攻击者在其控制的邮箱地址收到了恢复邮件，重置了受害者的密码，并获得了对该账户的完全访问权限。

整个链条需要：

• 一个经过身份验证的请求（使用攻击者自己的有效令牌）
• 知晓受害者的电子邮件地址
• 受害者没有做出任何回应。

受害者不会收到任何关于其备用邮箱已被更改的通知。他们可能会注意到一封他们并未请求的密码重置邮件，但那时攻击者已经获得了访问权限。

根本原因分析

导致此漏洞的原因有两个截然不同的故障：

故障 一：更新端点缺少所有权验证。 服务器使用请求正文中的 email 字段来识别要修改的用户记录，而不是从身份验证令牌中获取目标用户。这意味着任何已验证的用户都可以通过提供电子邮件地址来修改任何其他用户的个人资料。这是一个典型的不安全直接对象引用：服务器信任用户提供的标识符（电子邮件），而没有验证已验证用户是否拥有修改该记录的权限。

故障二：辅助邮箱变更未进行验证。 当添加或更改辅助邮箱时，服务器不会发送验证邮件来确认新邮箱地址是否属于账户持有人。这意味着攻击者可以悄无声息地将自己的邮箱地址附加到其他用户的账户，而无需任何通知或确认流程。

单独来看，这两项故障都足以构成重大发现。而它们结合起来，则构成了一个极易被利用的账户接管链。IDOR 允许修改其他用户的记录，而缺乏电子邮件验证机制则确保了这种修改不会被察觉，并可被利用来恢复密码。

该 API 似乎采用了一种模式，即电子邮件字段同时充当用户数据和记录标识符。这是一种危险的设计模式：可变的用户数据绝不应用作授权决策的主键。已认证用户的身份应完全来自会话或令牌，绝不能来自请求体参数。

补救指南

1. 从身份验证令牌中获取目标用户。

   更新端点必须仅基于已验证的会话来确定要修改的用户记录，而不能使用客户端提供的参数。持有者令牌应在服务器端映射到用户 ID，并且该 ID 应是更新操作中唯一使用的 ID。

2. 联系人变更需进行电子邮件验证。

   任何对主要或辅助电子邮件地址的更改都必须触发验证流程。新电子邮件地址只有在收件人点击验证链接确认所有权后才能在帐户中生效。

3. 通知用户个人资料变更。

   当任何个人资料字段被修改时，向用户已验证的电子邮件地址发送通知。这样，如果攻击者设法修改了帐户，就能及早发出预警。

4. 将数据字段与标识符分开。

   不要在 API 操作中使用可变的用户数据（例如电子邮件、电话号码）作为记录标识符。使用用户不可控制的不可变内部 ID。

5. 在更新端点上实施速率限制和异常检测。

   使用单个令牌在多个帐户间快速更改配置文件应触发警报。

6. 审核密码恢复流程。

   恢复流程应仅向已验证的主邮箱发送重置链接，而不应向最近添加或未经验证的备用邮箱发送链接。

影响

CVSS 评分：9.1（危急）

该漏洞允许攻击者完全接管平台上任何用户的账户。鉴于攻击目标是信用机构的消费者门户网站，其影响十分严重：

• 获取信用数据。

  攻击者可以查看受害者的完整信用报告，包括财务历史记录、未偿债务和信用评分。

• 身份盗窃的温床。

  信用局档案包含身份盗窃所需的全部个人信息：全名、身份证号码、地址、电话号码和财务关系。

• 大规模利用的可能性。

  该攻击仅需受害者的电子邮件地址，因此具有可扩展性。攻击者可以自动化该过程，批量接管账户。

• 横向影响。

  该 API 为该地区的多个面向消费者的服务提供支持。在此平台上发生的账户盗用事件可能会波及到任何共享同一身份后端的服务。

• 监管风险。

  信用机构在严格的数据保护法规下运作。大规模未经授权访问信用数据将构成重大监管事件。

此次攻击手段简单易用（只需两次 HTTP 请求和一次密码重置），再加上数据的极度敏感性，使其成为本次行动中最具影响力的发现之一。

要点总结

IDOR 漏洞通常被轻描淡写地视为“仅仅”篡改参数，但当它们发生在修改账户所有权属性（例如电子邮件、电话号码、恢复机制）的端点时，就会演变成账户接管的直接手段。由此可见，我们不仅需要在更新端点上验证所有权，更要深入思考每个可修改字段的作用。电子邮件字段不仅仅是一条数据，它是账户恢复流程的关键。保护电子邮件字段需要像保护密码本身一样严谨。

这类漏洞的修复方法很简单。难点在于找到它，而这正是手动、攻击者驱动的测试发挥作用的地方。

该发现已通过组织授权的安全程序负责任地披露，并已得到全面补救。

赏金：4000美元

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Rsec Gambacorta Gambacorta《0182.IDOR 导致通过电子邮件重新分配进行账户接管》