Open redirects are a great way to get started and understand how parameters work, and they can sometimes be the key to unlocking much more severe vulnerabilities.

openredirect.md

A Practical Walkthrough: Finding an Open Redirect

Let's imagine our target is https://example.com.

Step 1: Search for Redirect URL Parameters

You're browsing example.com and notice that when you click the "Login" button, it takes you to a URL like: https://example.com/login?redirect=/dashboard

• Analysis: The redirect parameter is a classic candidate. It tells the application where to send the user after a successful login. Other common parameter names include:
  • url
  • return
  • returnTo
  • next
  • goto
  • target
  • rurl
  • destination

You also check the site's robots.txt file and find a link to the logout page: https://example.com/logout?redirect=https://example.com/

Another redirect parameter.

---

Step 2: Search for Referer-based Redirects

Referer-based redirects are less common but powerful. These are pages that automatically send you back to the page you came from.

A common example is a "Exit" page or a "Leave Site" warning. You might find a link like: https://example.com/exit?url=https://externalsite.com

Even more subtle, a page might have a "Back to Safety" button that uses the Referer header from your HTTP request to determine where to send you. You'd need a tool like Burp Suite to intercept and modify this request to test it.

---

Step 3: Test for Open Redirects

Let's test the /logout endpoint we found.

1. The Basic Test: Change the redirect parameter to a domain you control.

   • URL: https://example.com/logout?redirect=https://attacker-website.com
   • Result: You click the link and are immediately redirected to https://attacker-website.com. Success! You've found a basic open redirect.

2. A More Stealthy Test: Often, applications have some basic checks. Let's see if it only allows relative paths.

   • URL: https://example.com/logout?redirect=//attacker-website.com
   • Why this works: Starting with // is a protocol-relative URL. The browser will interpret this as https://attacker-website.com when on the https://example.com page.

---

Step 4: Bypass Protections

What if the application tries to block external domains? Let's try some bypass techniques on our hypothetical /login?redirect= parameter.

• Scenario 1: The app checks for example.com in the URL.

  • Payload: https://[email protected]
  • How it works: The @ symbol in a URL is used for credentials. The browser might ignore the example.com. part and redirect to what comes after the @.

• Scenario 2: The app only allows paths starting with /.

  • Payload: /\/attacker-website.com
  • How it works: The backslashes might be stripped by the application, leaving a forward slash that passes the initial check, but the browser interprets the final URL as https://attacker-website.com.

• Scenario 3: The app appends the value to https://example.com.

  • Input: @attacker-website.com
  • Final URL built by app: https://example.com/@attacker-website.com
  • Bypass: Use a ? to start a new query string for the attacker site.
    • Input: [email protected]
    • Final URL: https://example.com/[email protected]
  • Bypass: Use a # (fragment) to trick the app.
    • Input: #@attacker-website.com
    • Final URL: https://example.com/#@attacker-website.com
  • In both these cases, the browser will navigate to https://attacker-website.com because the @ symbol is interpreted in the context of the final, full URL.

• Other Common Bypasses:

  • Double URL Encoding: Encode the https:// part (%68%74%74%70%73%3a%2f%2f) to evade string filters.
  • Using alternate domains: attacker-website.com.evil.com (if the check is just "does it contain example.com?").
  • Using subdomains: example.com.attacker-website.com

---

Step 5: Brainstorm Ways of Using the Open Redirect

An open redirect by itself is often considered a low-severity issue. Its real power is as a component in a more severe attack chain.

1. Phishing & Social Engineering:

   • The Problem: A savvy user might not click evil.com/login, but they will trust example.com/logout?redirect=https://evil.com/login.
   • The Attack: An attacker sends a phishing email: "Your account has suspicious activity. Please re-authenticate at example.com/logout?redirect=https://evil-phishing-site.com." The victim sees the legitimate example.com domain in their address bar for a split second before being redirected to a perfect fake login page, making the scam much more convincing.

2. Bypassing SSO/Allow-lists:

   • Some applications trust URLs from a specific domain (e.g., trusted-partner.com). If that trusted partner has an open redirect, an attacker can use it as a trampoline to access the target application.
   • Attack Chain: Victim -> trusted-partner.com/redirect?url=evil.com -> evil.com

3. Chaining with Other Vulnerabilities:

   • With XSS: If a site has a reflected XSS but the payload is blocked, you can sometimes host the payload on your server and use an open redirect to deliver it: vulnerable-site.com/redirect?url=attacker.com/xss-payload.html.
   • With OAuth Flows: OAuth and SAML authentication often use redirect_uri parameters. An open redirect on the client's domain can sometimes be exploited to steal authorization codes.