OAuth to Account takeover
最后更新于
最后更新于
OAuth 提供各种版本，可在OAuth 2.0 文档中找到基础见解。本讨论主要集中在广泛使用的OAuth 2.0 授权码授权类型上，提供了一种授权框架，使应用程序能够访问或执行另一个应用程序中用户帐户上的操作（授权服务器）。
考虑一个假设的网站 https://example.com，旨在展示您的所有社交媒体帖子，包括私人帖子。为实现此目的，采用了 OAuth 2.0。https://example.com 将请求您的许可以访问您的社交媒体帖子。因此，在 https://socialmedia.com 上将出现一个同意屏幕，概述了正在请求的权限和发出请求的开发人员。在您授权后，https://example.com 将能够代表您访问您的帖子。
在 OAuth 2.0 框架中理解以下组件至关重要：
资源所有者：您作为用户/实体，授权访问您的资源，如您的社交媒体帐户帖子。
资源服务器：在应用程序代表资源所有者获得访问令牌后，管理经过身份验证的请求的服务器，例如https://socialmedia.com。
客户端应用程序：从资源所有者那里寻求授权的应用程序，例如https://example.com。
授权服务器：在资源所有者成功验证并获得授权后，向客户端应用程序发放访问令牌的服务器，例如https://socialmedia.com。
client_id：应用程序的公共唯一标识符。
client_secret：应用程序和授权服务器独有的机密密钥，用于生成访问令牌。
response_type：指定请求的令牌类型的值，如code。
scope：客户端应用程序从资源所有者请求的访问级别。
redirect_uri：授权后用户被重定向到的 URL。通常必须与预注册的重定向 URL 保持一致。
state：一个参数，用于在用户重定向到授权服务器和从授权服务器返回时保持数据。其唯一性对于作为CSRF 保护机制至关重要。
grant_type：指示授权类型和要返回的令牌类型的参数。
code：从授权服务器获取的授权码，由客户端应用程序与client_id和client_secret一起使用以获取访问令牌。
access_token：客户端应用程序用于代表资源所有者进行 API 请求的令牌。
refresh_token：使应用程序能够获取新的访问令牌而无需重新提示用户。
实际的 OAuth 流程如下进行：
您访问 https://example.com 并选择“与社交媒体集成”按钮。
网站随后向 https://socialmedia.com 发送请求，请求您授权让 https://example.com 的应用程序访问您的帖子。请求结构如下：
然后会显示一个同意页面。
在您同意后，社交媒体会向 redirect_uri 发送带有 code 和 state 参数的响应：
https://example.com 利用这个 code，连同其 client_id 和 client_secret，向服务器发出请求，以获取代表您的 access_token，从而使您能够访问您同意的权限：
最后，过程以 https://example.com 使用您的 access_token 发起 API 调用到社交媒体以访问
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。这些细节有助于识别注册端点和服务器的其他配置细节。
正如在这份漏洞赏金报告中所述 https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html，可能会出现重定向 URL 在用户认证后服务器响应中被反射，存在 XSS 漏洞。测试的可能有效载荷：
在OAuth实现中，state参数的错误使用或省略会显著增加**跨站请求伪造（CSRF）**攻击的风险。当state参数未被使用、被用作静态值或未经适当验证时，就会出现这种漏洞，使攻击者能够绕过CSRF保护。
攻击者可以通过拦截授权过程来利用这一点，将他们的账户与受害者的账户关联起来，从而导致潜在的账户接管。这在OAuth用于身份验证目的的应用程序中尤为关键。
这种漏洞的实际案例已在各种CTF挑战和黑客平台中有所记录，突显了其实际影响。这个问题还延伸到与第三方服务（如Slack、Stripe和PayPal）的集成，攻击者可以将通知或付款重定向到他们的账户。
妥善处理和验证**state参数**对于防范CSRF攻击并保护OAuth流程至关重要。
在账户创建时未进行电子邮件验证：攻击者可以预先使用受害者的电子邮件创建一个账户。如果受害者后来使用第三方服务进行登录，应用程序可能会无意中将这个第三方账户与攻击者预先创建的账户关联起来，导致未经授权的访问。
利用宽松的OAuth电子邮件验证：攻击者可能会利用不验证电子邮件的OAuth服务，通过注册其服务然后将账户电子邮件更改为受害者的电子邮件。这种方法类似于第一种情况，但通过不同的攻击向量，同样存在未经授权的账户访问风险。
识别和保护秘密的OAuth参数至关重要。虽然**client_id可以安全地公开，但揭示client_secret会带来重大风险。如果client_secret泄露，攻击者可以利用应用程序的身份和信任来窃取用户的access_tokens**和私人信息。
当应用程序错误地在客户端而不是服务器端处理授权code以获取access_token时，就会出现常见的漏洞。这个错误导致client_secret的暴露，使攻击者能够在应用程序的名义下生成access_tokens。此外，通过社会工程学，攻击者可以通过向OAuth授权添加额外的范围来提升权限，进一步利用应用程序的受信任状态。
您可以尝试使用身份提供者暴力破解服务提供商的client_secret，以尝试窃取账户。 BF请求可能类似于：
一旦客户端获得了code和state，如果在他浏览到不同页面时在Referer标头中反映出来，那么就存在漏洞。
前往浏览器历史记录，检查访问令牌是否保存在其中。
授权码应该只存在一段时间，以限制攻击者可以窃取并使用它的时间窗口。
如果你可以获得授权码并将其与不同的客户端一起使用，那么你可以接管其他账户。
在这份赏金猎人报告中：https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/，你可以看到AWS Cognito返回给用户的令牌可能具有足够的权限来覆盖用户数据。因此，如果你可以更改用户电子邮件为不同的用户电子邮件，你可能能够接管其他账户。
正如在这篇文章中提到的，期望接收令牌（而不是代码）的OAuth流程可能存在漏洞，如果它们不检查令牌是否属于该应用程序。
这是因为攻击者可以创建一个支持OAuth并使用Facebook登录（例如）的应用程序。然后，一旦受害者在攻击者的应用程序中使用Facebook登录，攻击者可以获取用户授予其应用程序的OAuth令牌，并使用该令牌登录受害者OAuth应用程序中的受害者用户。
因此，如果攻击者成功让用户访问自己的OAuth应用程序，他将能够接管期望令牌的应用程序中的受害者帐户，并且不检查令牌是否授予其应用程序ID。
根据这篇文章，可以让受害者打开一个带有指向攻击者主机的returnUrl的页面。这些信息将被存储在一个cookie（RU）中，在后续步骤中，提示将询问用户是否要授予对该攻击者主机的访问权限。
为了绕过此提示，可以打开一个选项卡来启动Oauth流程，该流程将使用returnUrl设置此RU cookie，然后在显示提示之前关闭该选项卡，并打开一个不包含该值的新选项卡。然后，提示不会提及攻击者主机，但cookie将被设置为该主机，因此令牌将被发送到攻击者主机进行重定向。
查看此研究以获取有关此技术的更多详细信息。
OAuth中的动态客户端注册作为安全漏洞的一个不太明显但关键的向量，特别是用于**服务器端请求伪造（SSRF）**攻击。此端点允许OAuth服务器接收有关客户端应用程序的详细信息，包括可能被利用的敏感URL。
关键点：
动态客户端注册通常映射到/register，通过POST请求接受诸如client_name、client_secret、redirect_uris和用于logo或JSON Web Key Sets（JWKs）的URL等详细信息。
此功能遵循RFC7591和OpenID Connect Registration 1.0中规定的规范，其中包括可能容易受到SSRF攻击的参数。
注册过程可能会以几种方式无意中使服务器暴露于SSRF：
logo_uri：客户端应用程序logo的URL，服务器可能会获取该URL，触发SSRF或如果URL处理不当可能导致XSS。
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。
