OAuth misconfiguration

crypto_tokens_protocols Difficulty 1–5 30 min certifiable

Theory

Why This Matters

OAuth 2.0 misconfiguration has been responsible for a series of high-profile account takeover vulnerabilities. The 2012 "Covert Redirect" attacks demonstrated open redirect abuse in OAuth flows, and CVE-2019-11248 and similar CVEs document redirect_uri bypass vulnerabilities in major identity providers including Microsoft Azure AD, Facebook Login, and Google OAuth. The 2022 Booking.com OAuth misconfiguration allowed account takeover via redirect_uri manipulation. Because OAuth 2.0 is the foundation of "Login with Google/GitHub/Facebook" across millions of applications, a single misconfiguration can affect every user who uses social login — often millions of accounts with no password to reset.

Core Concept

OAuth 2.0 is an authorisation delegation framework defined in RFC 6749. In the authorisation code flow, the application (client) redirects the user to the authorisation server (e.g., Google, GitHub) with a redirect_uri parameter specifying where the authorisation code should be sent after the user consents. The authorisation server returns a short-lived authorisation code to the redirect_uri, and the application exchanges this code for an access token using its client secret at the token endpoint.

Open redirect via redirect_uri is the most critical misconfiguration: if the authorisation server does not strictly validate the redirect_uri against a pre-registered allowlist, an attacker can substitute their own URL. When the victim clicks the OAuth link, the authorisation code is sent to the attacker's server. The attacker exchanges the code for an access token and gains full account access. Validation bypasses include: trailing slashes (https://legitimate.com/callback/), subdomain wildcards (https://evil.legitimate.com/), path traversal (https://legitimate.com/../evil), open redirectors on the same domain (https://legitimate.com/redirect?url=https://evil.com), and fragment manipulation.

CSRF via missing state parameter is the second critical flaw. The state parameter in the OAuth request is a CSRF token: it must be a random value generated per-request, stored in the user's session, and verified when the callback is received. An application that omits the state parameter allows an attacker to craft a login-CSRF attack: the attacker initiates an OAuth flow for their own account, obtains the authorisation code, but does not complete the exchange. Instead, they embed the callback URL containing their code in an image tag or redirect on a malicious page. When the victim (already logged into the target application) visits this page, their browser completes the OAuth callback with the attacker's authorisation code, linking the victim's account to the attacker's identity.

Implicit flow token leakage occurs because the implicit flow (now deprecated in OAuth 2.1) places the access token directly in the URL fragment: https://app.com/callback#access_token=xxx. If the page at that URL loads any third-party resources, the access token may leak via the Referer header.

Technical Deep-Dive

Testing redirect_uri bypass with Burp Suite:

-- Original OAuth authorisation request
GET /oauth/authorize?
  response_type=code
  &client_id=abc123
  &redirect_uri=https://legitimate.com/callback
  &scope=openid+profile
  &state=randomvalue
HTTP/1.1
Host: authserver.example.com

-- Bypass variants to test in Burp Repeater:
redirect_uri=https://legitimate.com.evil.com/callback
redirect_uri=https://legitimate.com/callback/../evil
redirect_uri=https://legitimate.com/callback?next=https://evil.com
redirect_uri=https://legitimate.com/callback/
redirect_uri=https://legitimate.com/open-redirect?url=https://evil.com
redirect_uri=https://legitimate.com%40evil.com/callback

Missing state parameter — CSRF attack construction:

<!-- Attacker's page: forces victim's browser to complete attacker's OAuth callback -->
<!-- Step 1: Attacker initiates OAuth for their own account and gets code=ATTACKER_CODE -->
<!-- Step 2: Do not exchange the code. Instead, host this page: -->
<img src="https://app.example.com/oauth/callback?code=ATTACKER_CODE&state=">
<!-- When victim (logged into app.example.com) loads this page,
     their session is linked to the attacker's identity provider account -->

Scope escalation test:

GET /oauth/authorize?
  response_type=code
  &client_id=abc123
  &redirect_uri=https://legitimate.com/callback
  &scope=openid+profile+email+admin
  &state=randomvalue
-- Test whether the authorisation server accepts scopes beyond those registered for the client

Security Assessment Methodology

Enumerate all OAuth entry points — Identify every "Login with X" button and OAuth-based API. Capture the full authorisation request URL including all parameters.
Test redirect_uri validation — In Burp Repeater, modify the redirect_uri parameter using the bypass variants listed above. Observe whether the authorisation server accepts the modified URI (look for a 302 redirect to your modified URL in the response). An accepted URI means the authorisation code would be delivered to the attacker.
Check for state parameter — Examine the authorisation request. If state is absent or static (not a per-request random value), the flow is vulnerable to CSRF-based account linking. Document as critical if the application handles authentication (not just authorisation).
Test scope escalation — Modify the scope parameter to include additional scopes (admin, write, offline_access). Check whether the authorisation server grants them without explicit user consent or client registration.
Test the implicit flow for token exposure — If the application uses response_type=token, the access token appears in the URL fragment. Check whether any resources loaded after the callback would receive the Referer header containing the fragment.
Test token leakage via pre-auth account linking — Attempt to link a victim's account to an attacker-controlled identity provider account by initiating the linking flow from the attacker's session while forcing the victim to complete the callback.

Defensive Countermeasure — Register exact redirect_uri values (never wildcard or prefix matching) in the authorisation server and validate against the exact string using strict equality; always generate a cryptographically random state value per-request, store it in the server-side session, and reject any callback where the returned state does not match the stored value.

Common Assessment Errors

Testing only the obvious redirect_uri subdomains — The most effective bypass is often an open redirector on the legitimate domain itself. Always enumerate the target application for open redirect vulnerabilities before testing OAuth redirect_uri bypass.
Forgetting that state must also be validated on the callback — Some applications generate and send a state parameter but do not validate it when the callback is received. Test by sending a callback request with a modified or missing state and confirming the application rejects it.
Not testing account linking flows separately — "Connect your GitHub account" flows often have weaker validation than the primary "Login with GitHub" flow. Assess them independently.
Missing the PKCE requirement for public clients — Mobile and SPA clients using the authorisation code flow must use PKCE (Proof Key for Code Exchange). Absence of PKCE in a public client is a reportable finding even when redirect_uri validation is correct.
Overlooking token leakage in error responses — Some error responses include the access token or authorisation code in the response body or redirect URL for debugging purposes. Check all error cases.
Not testing token revocation — A valid finding is that access tokens are not revoked when a user revokes application access or changes their password. Test the token after performing these actions.

NICE Framework Alignment

Code	Knowledge/Skill/Task Statement	How This Card Develops It
K0007	Knowledge of authentication, authorisation, and access control methods	Covers the OAuth 2.0 authorisation flow, its security parameters, and the misconfigurations that enable account takeover
K0065	Knowledge of policy-based and role-based access controls	Explains how OAuth scope defines the access policy and how misconfigured scope validation enables privilege escalation
S0001	Skill in conducting vulnerability scans and recognising vulnerabilities in security systems	Develops redirect_uri bypass testing and state parameter CSRF assessment skills
T0028	Conduct and/or support authorised penetration testing on enterprise network assets	Provides a comprehensive OAuth 2.0 security assessment methodology covering all major attack vectors