Home > Website Pentesting

Open Redirect

Open redirects occur when a web application takes a user-supplied URL and redirects the browser to that value without validating whether the destination is trusted. Attackers abuse this behavior to redirect users to malicious websites, steal credentials, deliver phishing payloads, capture OAuth tokens, or chain attacks with other vulnerabilities such as CSRF, XSS, and token theft.

Open redirects are dangerous because users trust legitimate domains. If attackers can force the legitimate site to redirect victims to their own domain, the attack becomes far more convincing.

How Open Redirects Work

A redirect endpoint commonly looks like:

/redirect?url=https://example.com

or:

next=/dashboard
returnUrl=/profile
target=https://mysite.com
redirect=...

If the application does not validate the url parameter, an attacker can inject their own site:

/redirect?url=https://evil.com

The server redirects the victim to the attacker’s domain.

Why Open Redirects Are Dangerous

Open redirects enable attackers to:

  • perform highly believable phishing attacks

  • steal credentials on fake login pages

  • capture OAuth tokens by abusing callback URLs

  • bypass email filters and security scanners

  • chain with CSRF to redirect authenticated users

  • help bypass some security controls through redirect chaining

The attack is successful because the victim first sees a trusted URL (the legitimate domain) before the redirect occurs.

Common Sources of Open Redirects

Login flows

/login?next=/dashboard

Attackers supply:

/login?next=https://evil.com

Logout flows

/logout?redirect=/home

Attackers supply:

/logout?redirect=https://phish.com

Error pages

/error?back=https://example.com

External link confirmation pages

/go?url=

OAuth and SSO flows

redirect_uri=https://mysite.com/callback

If not restricted, attackers insert:

redirect_uri=https://attacker.com

Practical Open Redirect Attack Examples

Basic Redirect Exploit

Victim visits:

https://trusted.com/redirect?url=https://attacker.com/login

Trusted site sends:

302 Found
Location: https://attacker.com/login

Victim lands on attacker’s phishing page.

Payload in Query Fragment

Some filters check only part of the URL. Attackers bypass:

/redirect?next=//evil.com

Browsers interpret //evil.com as an absolute URL.

Injecting Redirect via Path

Example:

/redirect/https://evil.com

If backend uses string concatenation → redirect occurs.

Trailing Dot Bypass

https://trusted.com.evil.com/

Backend sees domain contains trusted.com; browser treats it as attacker’s domain.

URL Encoding Bypass

%2F%2Fevil.com
%5C%5Cevil.com

Double-encoding often bypasses weak validation.

Mixed-Scheme Bypass

http://%09evil.com

Tab characters confuse naive validators.

Legit Domain Hidden in Query

?next=https://trusted.com@evil.com

Browsers follow the real domain (evil.com).

Advanced Open Redirect Exploits

Open Redirect → Phishing

Victim thinks they are logging in via trusted.com but lands on attacker.com.

Open Redirect → Token Theft (OAuth)

OAuth redirect issue:

redirect_uri=https://evil.com/callback

Attacker receives:

  • access tokens

  • authorization codes

  • ID tokens

This can lead to full account takeover.

Open Redirect → CSRF Chaining

After CSRF triggers a privileged action, a redirect hides the attack:

CSRF performs action → redirect victim away immediately

Open Redirect → XSS via Script Injection

Some frameworks reflect the redirect URL inside HTML before redirecting.
Payload:

javascript:alert(document.cookie)

If returned as-is → immediate XSS.

Open Redirect → Open Proxy Abuse

If backend fetches remote URLs:

/fetch?url=http://evil.com

Attacker chains:

/redirect?url=https://backend.internal/admin

leading to SSRF-like behavior.

Bypass Techniques

Attackers attempt multiple variations to bypass basic filters:

1. Double Slashes

/redirect?url=//evil.com

2. URL Schemes

javascript:alert(1)
data:text/html,<script>...</script>

Some browsers still execute these if filters are weak.

3. Whitelist Bypass via Subdomain Tricks

https://trusted.com.attacker.com

4. Encoded Payloads

%2F%2Fevil.com
%255C%255Cevil.com

5. Protocol Relative Bypass

redirect=//evil.com

6. Abuse of @ symbol

https://trusted.com@evil.com

Browser goes to evil.com.

7. Using Uncommon Schemes

chrome://
ftp://
file://
view-source:

Depending on browser, redirects may still occur.

Practical Open Redirect Testing Workflow

Step 1: Find Redirect Parameters

Look for:

next=
url=
redirect=
return=
dest=
continue=
target=
callback=
go=

Step 2: Insert External URL

Test:

https://evil.com

If redirected → vulnerability confirmed.

Step 3: Test Common Bypass Payloads

Try:

/redirect?next=//evil.com
/redirect?next=https://trusted.com.evil.com
/redirect?next=https://trusted.com@evil.com
/redirect?next=%2F%2Fevil.com
/redirect?next=javascript:alert(1)

Step 4: Check HTTP Response

If response contains:

302 Found
Location: https://evil.com

or:

meta refresh

or:

window.location = userInput

the redirect is exploitable.

Step 5: Test for UI Reflection

Some pages display:

You will be redirected to: https://evil.com

If reflected unsafely, XSS becomes possible.

Step 6: Attempt OAuth Redirect Exploitation

Test whether:

redirect_uri=

values are validated strictly or loosely.

If arbitrary → direct token theft.

Step 7: Combine with Social Engineering

Because victims see:

https://trusted.com/redirect?url=...

they are more likely to trust the link.

Why Open Redirects Happen

Root causes:

  • developers trusting user-controlled URLs

  • no validation of redirect targets

  • poor whitelist logic

  • regex patterns that only check for substrings

  • insecure OAuth implementations

  • convenience-driven design choices

Redirect endpoints require strict server-side validation, but developers commonly skip it.

Impact of Open Redirects

Open redirects enable:

  • phishing attacks

  • credential theft

  • account takeover via OAuth token capture

  • session stealing (if combined with XSS)

  • chain attacks with CSRF

  • escalation to SSRF in certain implementations

  • redirecting users to malware

Even though open redirect seems simple, its real impact can be severe when combined with authentication flows.

Intel Dump

  • Open redirect happens when redirect URL is user-controllable and not validated.

  • Attackers use it for phishing, OAuth token theft, and chaining with CSRF/XSS.

  • Common bypasses include double encoding, protocol-relative URLs, subdomain tricks, and URLs containing @.

  • Testing involves injecting external URLs, checking Location headers, testing encodings, and abusing OAuth redirect flows.

  • Impact includes account takeover, credential theft, session hijacking, and redirection to malicious domains.

HOME LEARN COMMUNITY DASHBOARD