Full Report
OAuth is a fickle monster. This post dives into a website that was automatically redirecting to the Referer header when coming back from the OAuth flow. Likely, this was a multi-website system where they had a global OAuth page and needed to get back to the original page. Of note, the Referer header survives redirects. An arbitrary redirect in OAuth is usually an automatic game over. This is because the auth information itself is stored within the fragment or parameters in a URL. So, the goal of the attack was to trigger a redirect to steal the token information of the user. Upon trying to abuse this functionality, they learned that client-side redirects will remove the fragment but server-side will not. In the standard flow for OAuth, a client-side redirect was used. However, by changing the type to be id_token instead, this triggered a server-side redirect to keep the code around. They tried reviewing the OAuth providers used by the application: Facebook, GitHub and Google. Facebook had a confirmation step that changed the referer, and GitHub doesn't use the response_type parameter. Gmail had a selection screen if users had more than one account. By adding the parameter prompt=none, this prompt was bypassed though. The final flow of the attack tricked a victim into visiting their website and used window.open() to trigger the OAuth flow. Since they were the referrer of this interaction, it would eventually redirect to their website, where they could steal the token information. This blog post was a good example of seeing bad functionality and finding the primitives to trigger it properly. This contained numerous small tricks and required considerable perseverance. Great write-up!
Analysis Summary
The provided article summary details a security finding related to an **Open Redirect vulnerability chained with an OAuth implementation flaw**, specifically leveraging the `Referer` header persistence across OAuth redirects. However, the summary **does not contain any official CVE identifiers, CVSS scores, or specific vendor names beyond the OAuth providers tested (Facebook, GitHub, Google)** that were associated with a confirmed vulnerability in a public disclosure context. The analysis describes research findings against an unknown third-party application's OAuth implementation.
Therefore, the summary below reflects the lack of formal CVE data while accurately capturing the technical details of the described finding.
# Vulnerability: OAuth Open Redirect via Referer Header Persistence
## CVE Details
- CVE ID: N/A (No specific CVE assigned in the context provided)
- CVSS Score: N/A (Severity needs to be assessed based on the outcome, potentially High/Critical due to arbitrary redirect capability)
- CWE: CWE-601: Improper Link Resolution Before Web Navigation ('Open Redirect') (Likely primary flaw)
## Affected Systems
- Products: Custom application utilizing an OAuth flow (Facebook, Google, GitHub providers specifically tested).
- Versions: Unknown.
- Configurations: Applications where the OAuth return URL logic relied on the HTTP `Referer` header to determine the final post-authentication redirect location, especially in multi-site systems.
## Vulnerability Description
The target application implemented an OAuth return mechanism that automatically redirected the user back to the URL specified in the HTTP `Referer` header after successful token exchange/authorization, instead of strictly validating a pre-approved redirect URI. A critical aspect exploited was that the `Referer` header persists across redirects.
The attacker successfully bypassed standard client-side fragment stripping by switching the OAuth response type to `id_token`, which triggered a server-side redirect, thereby preserving the sensitive authorization parameters (token/code) within the URL that was then used as the subsequent redirect target via the `Referer` header. Furthermore, the prompt screen bypass mechanism (`prompt=none` for Google) was leveraged to automate the flow without user interaction.
## Exploitation
- Status: Successful proof-of-concept described against various providers; implies **PoC available** for the described technique. It is a description of a successful security research finding, not necessarily a known, patched CVE.
- Complexity: Medium (Required specific knowledge of OAuth flow variations like `id_token` or response behaviors of different providers).
- Attack Vector: Network (Requires victim browser visitation).
## Impact
- Confidentiality: High (Allows theft of authentication tokens/codes, leading to session hijacking or account takeover).
- Integrity: High (If tokens grant modification rights).
- Availability: Low (No direct denial of service impact).
## Remediation
### Patches
- N/A (No specific vendors/versions provided to patch against).
- **Recommended Patch:** Eliminate reliance on the `Referer` header for security-sensitive redirects post-OAuth authentication. Strictly enforce OAuth 2.0 best practices by validating the `redirect_uri` against a whitelist of approved endpoints only.
### Workarounds
- If immediate patching is impossible, ensure that any redirect logic consuming the `Referer` header strictly rejects redirects to external, non-whitelisted domains.
- For testing providers, ensure the provider-specific parameters used (like `prompt=none`) are only used when strictly necessary and validated against expected application state.
## Detection
- Indicators of Compromise: Unexpected redirect behavior following OAuth login, especially successful logins redirecting to arbitrary external domains, or logs showing server-side redirects triggered when only client-side redirects were expected during the OAuth return callback.
- Detection methods and tools: Web Application Firewalls (WAFs) or custom server-side request logging/monitoring that flag server-side redirects originating from OAuth callbacks that target user-supplied headers like `Referer`.
## References
- [Defanged URL for the article source if available]