OAuth 到账户接管

Reading time: 25 minutes

基本信息

OAuth 提供了多种版本，基础信息可在 OAuth 2.0 documentation 中获取。本讨论主要集中在广泛使用的 OAuth 2.0 授权码授权类型，提供一个 授权框架，使应用程序能够访问或在另一个应用程序中执行用户账户上的操作（授权服务器）。

考虑一个假设的网站 https://example.com，旨在 展示您所有的社交媒体帖子，包括私人帖子。为此，采用 OAuth 2.0。https://example.com 将请求您允许 访问您的社交媒体帖子。因此，https://socialmedia.com 上会出现一个同意屏幕，概述 请求的权限和发起请求的开发者。在您授权后，https://example.com 获得 代表您访问您的帖子 的能力。

理解 OAuth 2.0 框架中的以下组件至关重要：

• 资源拥有者：您，作为 用户/实体，授权访问您的资源，例如您的社交媒体账户帖子。
• 资源服务器：在应用程序为 资源拥有者 获取 access token 后，管理经过身份验证请求的服务器，例如 https://socialmedia.com。
• 客户端应用程序：向 资源拥有者 请求授权的 应用程序，例如 https://example.com。
• 授权服务器：在成功验证 资源拥有者 并获得授权后，向 客户端应用程序 发放 access tokens 的服务器，例如 https://socialmedia.com。
• client_id：应用程序的公共唯一标识符。
• client_secret：仅为应用程序和授权服务器所知的机密密钥，用于生成 access_tokens。
• response_type：指定 请求的令牌类型 的值，例如 code。
• scope：客户端应用程序 请求的 资源拥有者 的 访问级别。
• redirect_uri：用户在授权后被重定向的 URL。这通常必须与预注册的重定向 URL 对齐。
• state：一个参数，用于 在用户重定向到授权服务器及返回时维护数据。其唯一性对于作为 CSRF 保护机制 至关重要。
• grant_type：指示 授权类型和要返回的令牌类型 的参数。
• code：来自 授权服务器 的授权码，客户端应用程序与 client_id 和 client_secret 一起使用以获取 access_token。
• access_token：客户端应用程序代表 资源拥有者 用于 API 请求的 令牌。
• refresh_token：使应用程序能够 在不重新提示用户的情况下获取新的 access_token。

流程

实际的 OAuth 流程如下：

1. 您导航到 https://example.com 并选择“与社交媒体集成”按钮。
2. 然后该网站向 https://socialmedia.com 发送请求，请求您的授权以让 https://example.com 的应用程序访问您的帖子。请求的结构为：

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. 然后您会看到一个同意页面。
4. 在您批准后，社交媒体会向 redirect_uri 发送包含 code 和 state 参数的响应：

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com 利用这个 code，连同它的 client_id 和 client_secret，发起服务器端请求以代表您获取 access_token，从而访问您同意的权限：

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. 最后，过程结束时 https://example.com 使用您的 access_token 进行 API 调用以访问

漏洞

开放的 redirect_uri

redirect_uri 对于 OAuth 和 OpenID 实现的安全性至关重要，因为它指示在授权后敏感数据（如授权代码）发送到何处。如果配置错误，可能会允许攻击者将这些请求重定向到恶意服务器，从而实现账户接管。

利用技术根据授权服务器的验证逻辑而异。它们可以从严格的路径匹配到接受指定域或子目录内的任何 URL。常见的利用方法包括开放重定向、路径遍历、利用弱正则表达式和 HTML 注入进行令牌窃取。

除了 redirect_uri，其他 OAuth 和 OpenID 参数如 client_uri、policy_uri、tos_uri 和 initiate_login_uri 也容易受到重定向攻击。这些参数是可选的，其支持在不同服务器之间有所不同。

对于那些针对 OpenID 服务器的攻击者，发现端点（**.well-known/openid-configuration**）通常列出有价值的配置细节，如 registration_endpoint、request_uri_parameter_supported 和 "require_request_uri_registration。这些细节可以帮助识别注册端点和服务器的其他配置细节。

重定向实现中的 XSS

正如在这个漏洞赏金报告中提到的 https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html，重定向 URL 可能在用户认证后被反射在服务器的响应中，因此 容易受到 XSS 攻击。可以测试的有效载荷：

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Improper handling of state parameter

在OAuth实现中，state参数的误用或遗漏会显著增加跨站请求伪造（CSRF）攻击的风险。当state参数未使用、作为静态值使用，或未正确验证或与用户会话关联时，就会出现此漏洞，从而允许攻击者绕过CSRF保护。

攻击者可以通过拦截授权过程，将他们的账户与受害者的账户关联，从而利用这一点，导致潜在的账户接管，使用户登录几乎完成的属于攻击者的oauth流程。这在使用OAuth进行身份验证的应用程序中尤其关键。

此漏洞的现实世界示例已在各种CTF挑战和黑客平台中记录，突显了其实际影响。该问题还扩展到与第三方服务的集成，如Slack、Stripe和PayPal，攻击者可以将通知或付款重定向到他们的账户。

正确处理和验证**state参数**对于防范CSRF和保护OAuth流程至关重要。

Pre Account Takeover

1. 在账户创建时未进行电子邮件验证：攻击者可以预先使用受害者的电子邮件创建账户。如果受害者稍后使用第三方服务登录，应用程序可能会不经意地将此第三方账户链接到攻击者预先创建的账户，从而导致未经授权的访问。
2. 利用宽松的OAuth电子邮件验证：攻击者可能会利用不验证电子邮件的OAuth服务，通过注册其服务并将账户电子邮件更改为受害者的电子邮件来进行攻击。这种方法同样存在未经授权的账户访问风险，类似于第一种情况，但通过不同的攻击向量。

Disclosure of Secrets

识别和保护秘密的OAuth参数至关重要。虽然**client_id可以安全披露，但泄露client_secret会带来重大风险。如果client_secret被泄露，攻击者可以利用应用程序的身份和信任来窃取用户的access_tokens**和私人信息。

一个常见的漏洞出现在应用程序错误地在客户端而不是服务器端处理授权code与access_token的交换。这一错误导致client_secret的暴露，使攻击者能够以应用程序的名义生成access_tokens。此外，通过社会工程学，攻击者可以通过向OAuth授权添加额外的范围来提升权限，进一步利用应用程序的信任状态。

Client Secret Bruteforce

您可以尝试暴力破解服务提供商的client_secret与身份提供者，以试图窃取账户。
暴力破解的请求可能类似于：

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header leaking Code + State

一旦客户端拥有了 code 和 state，如果它们在用户浏览到不同页面时 反映在 Referer 头中，那么就存在漏洞。

Access Token Stored in Browser History

前往 浏览器历史记录并检查访问令牌是否保存在其中。

Everlasting Authorization Code

授权代码应该只存在一段时间，以限制攻击者可以窃取和使用它的时间窗口。

Authorization/Refresh Token not bound to client

如果你可以获取 授权代码并在不同的客户端上使用它，那么你可以接管其他账户。

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

查看此帖子

AWS Cognito

在这个漏洞赏金报告中：https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ 你可以看到 AWS Cognito 返回给用户的 令牌 可能具有 足够的权限来覆盖用户数据。因此，如果你可以 将用户电子邮件更改为其他用户的电子邮件，你可能能够 接管 其他账户。

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

对于如何滥用 AWS cognito 的更详细信息，请查看：

AWS - Cognito Unauthenticated Enum - HackTricks Cloud

滥用其他应用程序令牌

正如 在这篇文章中提到的，期望接收 token（而不是代码）的 OAuth 流程可能会受到攻击，如果它们没有检查该 token 是否属于该应用程序。

这是因为 攻击者 可以创建一个 支持 OAuth 的应用程序并使用 Facebook 登录（例如）在自己的应用程序中。然后，一旦受害者在 攻击者的应用程序 中使用 Facebook 登录，攻击者就可以获取 分配给其应用程序的用户的 OAuth token，并使用它在受害者的 OAuth 应用程序中登录，使用受害者的用户 token。

两个链接和 cookie

根据 这篇文章，可以让受害者打开一个 returnUrl 指向攻击者主机的页面。此信息将 存储在 cookie (RU) 中，在 后续步骤 中，提示 将 询问 用户 是否希望授予对该攻击者主机的访问权限。

为了绕过此提示，可以打开一个选项卡以启动 Oauth 流程，该流程将使用 returnUrl 设置此 RU cookie，在提示显示之前关闭选项卡，然后打开一个没有该值的新选项卡。然后，提示不会通知攻击者的主机，但 cookie 将被设置为它，因此 token 将在重定向中发送到攻击者的主机。

提示交互绕过

正如 在这段视频中解释的，某些 OAuth 实现允许将 prompt GET 参数指示为 None (&prompt=none) 以 防止用户在已登录平台时被要求确认 在网页上授予的访问权限。

response_mode

正如 在这段视频中解释的，可能可以指示参数 response_mode 来指示您希望在最终 URL 中提供代码的位置：

• response_mode=query -> 代码在 GET 参数中提供： ?code=2397rf3gu93f
• response_mode=fragment -> 代码在 URL 片段参数中提供 #code=2397rf3gu93f
• response_mode=form_post -> 代码在一个名为 code 的 POST 表单中提供，并带有值
• response_mode=web_message -> 代码通过 post 消息发送： window.opener.postMessage({"code": "asdasdasd...

OAuth ROPC 流程 - 2 FA 绕过

根据 这篇博客文章，这是一个允许通过 用户名 和 密码 登录 OAuth 的 OAuth 流程。如果在这个简单流程中返回一个具有用户可以执行的所有操作的访问权限的 token，那么就可以使用该 token 绕过 2FA。

基于开放重定向的网页重定向 ATO

这篇 博客文章 评论了如何利用 开放重定向 从 referrer 的值滥用 OAuth 进行 ATO。攻击过程如下：

1. 受害者访问攻击者的网页
2. 受害者打开恶意链接，打开者使用 response_type=id_token,code&prompt=none 作为附加参数启动 Google OAuth 流程，referrer 为攻击者网站。
3. 在打开者中，提供者在授权受害者后，将他们发送回 redirect_uri 参数的值（受害者网站），并带有 30X 代码，这仍然保持攻击者网站在 referer 中。
4. 受害者 网站根据 referrer 触发开放重定向，将受害者用户重定向到攻击者网站，因为 respose_type 是 id_token,code，代码将通过 URL 的 fragment 返回给攻击者，从而使他能够通过 Google 在受害者网站上接管用户的帐户。

SSRFs 参数

查看这项研究 以获取此技术的更多详细信息。

OAuth 中的动态客户端注册作为一个不太明显但关键的安全漏洞向量，特别是针对 服务器端请求伪造 (SSRF) 攻击。此端点允许 OAuth 服务器接收有关客户端应用程序的详细信息，包括可能被利用的敏感 URL。

关键点：

• 动态客户端注册 通常映射到 /register，并接受诸如 client_name、client_secret、redirect_uris 和用于徽标或 JSON Web 密钥集 (JWKs) 的 URL 的 POST 请求。
• 此功能遵循 RFC7591 和 OpenID Connect Registration 1.0 中列出的规范，其中包括可能对 SSRF 易受攻击的参数。
• 注册过程可能会以多种方式无意中使服务器暴露于 SSRF：
• logo_uri：客户端应用程序徽标的 URL，服务器可能会获取该 URL，从而触发 SSRF 或导致 XSS（如果 URL 处理不当）。
• jwks_uri：客户端的 JWK 文档的 URL，如果恶意构造，可能导致服务器向攻击者控制的服务器发出外部请求。
• sector_identifier_uri：引用 redirect_uris 的 JSON 数组，服务器可能会获取，从而创建 SSRF 机会。
• request_uris：列出客户端允许的请求 URI，如果服务器在授权过程开始时获取这些 URI，则可能被利用。

利用策略：

• 通过在参数如 logo_uri、jwks_uri 或 sector_identifier_uri 中注册带有恶意 URL 的新客户端，可以触发 SSRF。
• 尽管通过白名单控制可能会减轻直接通过 request_uris 的利用，但提供一个预注册的、攻击者控制的 request_uri 可以在授权阶段促进 SSRF。

OAuth 提供者竞争条件

如果您正在测试的平台是 OAuth 提供者 请阅读此内容以测试可能的竞争条件。

可变声明攻击

在 OAuth 中，sub 字段唯一标识用户，但其格式因授权服务器而异。为了标准化用户识别，一些客户端使用电子邮件或用户句柄。然而，这很危险，因为：

• 一些授权服务器并不确保这些属性（如电子邮件）保持不变。
• 在某些实现中——例如 “使用 Microsoft 登录”——客户端依赖于电子邮件字段，该字段由 Entra ID 中的用户控制，并未经过验证。
• 攻击者可以通过创建自己的 Azure AD 组织（例如，doyensectestorg）并使用它执行 Microsoft 登录来利用这一点。
• 尽管存储在 sub 中的对象 ID 是不可变且安全的，但对可变电子邮件字段的依赖可能会导致帐户接管（例如，劫持像 victim@gmail.com 这样的帐户）。

客户端混淆攻击

在 客户端混淆攻击 中，使用 OAuth 隐式流的应用程序未能验证最终访问 token 是否专门为其自己的客户端 ID 生成。攻击者设置一个公共网站，使用 Google 的 OAuth 隐式流，欺骗成千上万的用户登录，从而收集意图用于攻击者网站的访问 token。如果这些用户在另一个不验证 token 的客户端 ID 的易受攻击网站上也有帐户，攻击者可以重用收集到的 token 来冒充受害者并接管他们的帐户。

范围升级攻击

授权代码授权 类型涉及安全的服务器到服务器通信以传输用户数据。然而，如果 授权服务器 隐式信任访问令牌请求中的范围参数（RFC 中未定义的参数），恶意应用程序可以通过请求更高的范围来升级授权代码的权限。在生成 访问令牌 后，资源服务器 必须验证它：对于 JWT 令牌，这涉及检查 JWT 签名并提取数据，如 client_id 和 scope，而对于随机字符串令牌，服务器必须查询授权服务器以检索令牌的详细信息。

重定向方案劫持

在移动 OAuth 实现中，应用程序使用 自定义 URI 方案 来接收带有授权代码的重定向。然而，由于多个应用程序可以在设备上注册相同的方案，因此假设只有合法客户端控制重定向 URI 的假设被违反。例如，在 Android 上，像 com.example.app:// 的 Intent URI 是根据方案和应用程序的 intent-filter 中定义的可选过滤器捕获的。由于 Android 的意图解析可能很广泛——尤其是如果仅指定方案——攻击者可以注册一个带有精心设计的意图过滤器的恶意应用程序，以劫持授权代码。这可以 启用帐户接管，无论是通过用户交互（当多个应用程序有资格处理意图时）还是通过利用过于特定的过滤器的绕过技术，如 Ostorlab 的评估流程图所详细说明的那样。

参考文献

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors
• https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html