不安全的刷新令牌使用导致账户接管(IDOR)

引言

在这篇文章中，我将详细说明一个存在于认证域而非主应用域的IDOR漏洞。通过滥用OAuth2刷新令牌流程，我能够获取任意用户的JWT访问令牌。利用该令牌，我可以完全冒充平台上的任何用户，最终导致完整的账户接管(ATO)。

问题发现过程

在浏览网站时，我经常将有趣的请求转发到Burp Repeater进行进一步测试。某天，当我把一个请求留在Repeater中约10分钟后再次发送时，收到了401未授权响应。

这很不寻常 - 因为当我在浏览器中执行相同操作时，它正常工作且没有要求重新登录。这引起了我的好奇。

我决定被动监控从浏览器到服务器的网络请求，而不手动与页面交互。

发现步骤

我注意到一个POST请求被发送到认证域：

1

POST https://auth.target.com/oauth/token

该请求返回了用户的新JWT令牌(access_token)。发送的唯一参数是：

1
2
3

grant_type=refresh_token
refresh_token=<token>
client_id=<client_id>

参数测试

我观察到使用相同接口的不同账户的client_id是相同的。 例如：

• 通过www.target.com登录 → client_id=xxxx
• 通过community.target.com登录 → client_id=yyyy

这里重要的参数是refresh_token。为了进一步测试，我：

1. 创建第二个账户
2. 获取第二个账户的refresh_token
3. 在第一个账户的会话中使用该refresh_token发送相同的POST请求

服务器返回了第二个账户的JWT令牌。这意味着我可以：

• 访问第二个用户的账户
• 查看和编辑他们的个人资料
• 以他们的身份执行任何操作

错误配置

此漏洞源于认证流程中的两个关键缺陷：

1. 缺乏绑定：服务器不验证正在使用的刷新令牌是否确实属于当前认证的用户/会话
2. 静态刷新令牌：refresh_token数月保持不变，意味着被盗/泄露的令牌可以无限期重复使用

建议

• 始终观察令牌交换，特别是前端和认证服务之间的交换
• 小的异常行为(如不一致的错误或缺少重新认证)可能导致严重漏洞

不幸的是，由于refresh_token使用的是不可猜测的UUID，且无法通过受害者个人资料交互获取，他们将其评定为P5级别漏洞。