What is the Open Redirect vulnerability, find it, and protect against it

9 min readMar 5, 2023

للإطلاع علي النسخة العربية

https://www.cyberelliot.com/2023/03/open-redirect.html

What are Open Redirect vulnerabilities?

Open Redirect is a type of web application vulnerability that allows an attacker to redirect a user from a legitimate website to a malicious website, without the user’s knowledge or consent.

In open redirect attacks, the attacker designs a specially crafted URL that takes advantage of a weakness in the target website's redirect functionality. The attacker then tricks the user into clicking on the URL, which redirects the user to a malicious website. The user may not realize that they have been redirected, as the attacker may use a URL that looks like the legitimate website URL.

Some types of Open Redirect vulnerabilities with examples:

Parameter-based Open Redirect: This occurs when the website allows the user to specify a URL parameter that specifies where the user is redirected to. Attackers can manipulate these parameters by entering a malicious URL that redirects the user to a phishing or malware-infected website.

Example: A website has a login page with a "return to previous page" function that redirects the user to the page they were on before logging in. The URL parameter for this function is “return_to”. An attacker can create a malicious URL that uses the “return_to” parameter to redirect the user to a malicious website. For example:

https://www.example.com/login?return_to=http://malicious-site.com

Header-based Open Redirect: This occurs when a website uses a header to redirect users to a different URL. Attackers can modify the header to redirect the user to a malicious website.

Example: A website uses a header to redirect users to a different page. The attacker modifies the header to redirect the user to a phishing website instead. For example, a website might contain a link like:

<a href="/logout">Logout</a>

An attacker can modify the link to redirect the user to a malicious website:

<a href="https://malicious-site.com/logout">Logout</a>

JavaScript-based Open Redirect: This type of Open Redirect occurs when a website allows the use of an untrusted input in a JavaScript function that redirects users to a different page.

Example: A website uses a JavaScript function to redirect users to a different page. The function takes an argument specifying the URL to redirect to. An attacker can insert a malicious URL into the function, causing the user to be redirected to a phishing website. For example:

<script>
  function redirect(url) {
    window.location = url;
  }

  var returnUrl = "http://malicious-site.com";
  redirect(returnUrl);
</script>

Search for Open Redirects

1- Search for Redirect Parameters

redirect: Many websites use this Parameter to redirect the user to a different page after a successful login or registration. For example, the URL might look like this: https://example.com/login.php?redirect=/dashboard.php

return: Some of these websites use Parameter to redirect the user to the previous page after completing an action. For example, the URL might look like this: https://example.com/add_comment.php?return=/blog/post1234

next: Some of these websites use Parameter to redirect the user to the next page in a series of steps or steps. For example, the URL might look like this: https://example.com/checkout.php?next=/checkout/step2

continue: Some of these websites use Parameter to redirect the user to the next page in the process. For example, the URL might look like this: https://example.com/signup.php?continue=/dashboard.php

target: Some of these websites use Parameter to redirect the user to a specific page after completing an action. For example, the URL might look like this: https://example.com/subscribe.php?target=/premium-content

go: Some of these websites use Parameter to redirect the user to a specific page or URL. For example, the URL might look like this: https://example.com/landing.php?go=https://malicious-site.com

2- Use Google Dorks to find Redirect Parameters

"inurl" is Google Dorks to search for a specific keyword or phrase within a web page URL. By using "inurl:" followed by the keyword or phrase, you can instruct Google to return only results that contain that specific word or phrase in their URL.

For example, if you wanted to search for webpages that have the word "security" in their URL, you could use the following Google Dork:

site:example.com inurl: security

This will return a list of web pages that have the word "security" in their URL, eg https://www.example.com/security-tips.html
Using "inurl" with other search dorks can help you narrow your search results and find specific types of websites and vulnerabilities.

inurl:redirect= site:example.com
inurl:return= site:example.com
inurl:returnTo= site:example.com
inurl:redirect_to= site:example.com
inurl:redirect_uri= site:example.com
inurl:redirect_url= site:example.com
inurl:redirect_page= site:example.com
inurl:target= site:example.com
inurl:out= site:example.com
inurl:go= site:example.com
inurl:to= site:example.com
inurl:link= site:example.com
inurl:next= site:example.com
inurl:file= site:example.com
inurl:uri= site:example.com
inurl:url= site:example.com
inurl:location= site:example.com
inurl:ref= site:example.com
inurl:navigateTo= site:example.com
inurl:transfer= site:example.com
inurl:path= site:example.com
inurl:domain= site:example.com
inurl:dest= site:example.com
inurl:away= site:example.com
inurl:forward= site:example.com

3- Test for Parameter-Based Open Redirects

Enter a random host, in redirect parameters ; Then check if the site automatically redirects to the site you specified: https://example.com/login?p=http://google.com https://example.com/login?p=http://malicious-site.com

Some sites will redirect to the intended site immediately after visiting the URL, without any user interaction. But on many pages, the redirect will only occur after a user action, such as registration, login, or logout.. In these cases, be sure to perform the required user interactions before checking for a redirect.

4- Test for Referer-Based Open Redirects

Test referer-based open redirects on any page or pages you found in step 1 that redirected the user even though they didn't have the redirect URL parameter. To test this, create a page on a host you own and host this HTML page:

<html>
 <a href="https://example.com/login">Click on this link!</a>
</html>

Replace the linked URL with the target page. Then reload and visit your HTML page. Click on the link and see if you will be redirected to your site automatically or after required user interactions.

Bypassing Open-Redirect Protection

Modern browsers often correct URLs that do not contain the correct components to correct garbled URLs caused by user misspellings.
For example, Chrome will interpret all such URLs as pointing to http://example.com /

https:example.com
https;example.com
https:\/\/example.com
https:/\/\example.com

These changes can help you bypass URL validation for blacklist.

If the validator rejects any redirect URL containing the words HTTPS:// or HTTP:// , you can use an alternative, such as HTTPS;// to achieve the same results.

Most modern browsers also automatically correct forward slashes (\) backslashes (/), which means they will treat these URLs as follows:

https:\\example.com
https://example.com

If the validator does not recognize this behavior, it may cause errors. For example, the following URL could be problematic:

https://example.com%5C%5C@google.com/

But if the browser autocorrects backslashes to forward slashes, the user will be redirected to example.com and treat google.com as part of the URL, forming the following valid URL:

https://example.com/@google.com

Exploiting Flawed Validator Logic

Exploiting Flawed Validator Logic is a common technique for bypassing open redirect protection. In some cases, web applications use client-side validation to validate user input, such as checking for valid URL format. However, this client-side check can be bypassed by simply modifying the URL parameter to include a redirect to an external website.

For example, suppose a website uses the following client-side check to ensure that the parameter "redirect_url" is a valid URL:

function isValidURL(url) {
  var pattern = new RegExp('^(https?:\\/\\/)?'+ // protocol
    '((([a-z\\d]([a-z\\d-]*[a-z\\d])*)\\.)+[a-z]{2,}|'+ // domain name
    '((\\d{1,3}\\.){3}\\d{1,3}))'+ // IP address
    '(\\:\\d+)?(\\/[-a-z\\d%_.~+]*)*'+ // port and path
    '(\\?[;&a-z\\d%_.~+=-]*)?'+ // query string
    '(\\#[-a-z\\d_]*)?$','i'); // fragment locator
  return pattern.test(url);
}

if(!isValidURL(redirect_url)) {
  alert('Invalid redirect URL');
  return false;
}

It does not check if the URL redirects to a different domain or path. Therefore, an attacker can bypass this verification by using a URL that redirects to an external website.

For example, the following URL might pass client-side verification, but could be used to redirect users to a phishing website:

https://example.com/?redirect_url=https://attacker.com/redirect?url=https://phishing.com

In this case, the attacker can use the URL parameter with the value https://attacker.com/redirect?url=https://phishing.com

To redirect the user to a phishing site.

Using Data URLs

Data URLs are a type of URI (Uniform Resource Identifier) that allows developers to include data as part of a URL. They are most commonly used to include images or other resources directly in HTML or CSS files.

For Open-Redirect attacks, data URLs can be used to bypass external URL validations. This is because data URLs do not require a separate HTTP request to retrieve the resource, and therefore do not run the same validation checks that external URLs do.

To understand how this works, consider the following example:

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

In this case, the "redirect.php" script might check that the url "parameter" starts with https://example.com/ to make sure it’s a trusted domain. However, an attacker can bypass this check using the data url:

https://example.com/redirect.php?url=data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==

The URL encodes a simple HTML page as a base64-encoded string, and includes it as a parameter “url”. When the victim clicks the link, script redirect.php will interpret the data URL as a valid URL parameter and redirect the victim’s browser to the data URL. The browser will then decode the base64-encoded string and display the HTML page directly, bypassing any external URL validations.

Exploiting URL decoding

The URL decoding exploit is a technique used to bypass external URL validations in Open-Redirect vulnerabilities. Some web applications decode the URL parameter before performing validation checks, which attackers can exploit to generate malicious URLs that bypass validation checks.

To understand how this works, consider the following example:

https://example.com/redirect.php?url=https%3A%2F%2Fexample.com%2Fhome

In this case, the parameter for "url" is URL-encoded, which means that certain characters are replaced with their corresponding ASCII hex codes. The encoded value %3A%2F%2F represents the characters // , which are part of the https:// protocol in the URL. The redirect.php script might check that the url parameter starts with /https://example.com to ensure that it is a trusted domain.

Double Encoding

However, an attacker can bypass this check by encoding the URL parameter twice:

https://example.com/redirect.php?url=https%253A%252F%252Fexample.com%252Fhome

Combining exploit techniques

Combining exploits is a common approach used by attackers to bypass multiple layers of validations and achieve a successful Open-Redirect exploit. By combining different techniques, attackers can create more sophisticated attacks that are difficult to detect and mitigate.

For example, an attacker might combine URL encoding and data URLs to bypass validation checks and achieve a successful exploit. Consider the following example:

https://example.com/redirect.php?url=data:text/html,<script>alert('Vulnerable')</script>

In this case, parameter url contains a data URL that will execute JavaScript code “alert(’Vulnerable’)” when the victim’s browser is redirected to the URL. This attack works because ":data" is a valid protocol that can be used for URL redirects.

However, some web applications may block "data:" to prevent this type of attack. To bypass this protection, an attacker can encrypt the data URL parameter:

https://example.com/redirect.php?url=data%3Atext%2Fhtml%2C%253Cscript%253Ealert%2528%2527Vulnerable%2527%2529%253C%252Fscript%253E

In this case, the attacker did the URL-encoded data URL parameter twice to bypass the validations blocking the "data:" protocol. The parameter will be decoded by script redirect.php and executed by the victim’s browser.

Escalating the attack

One common technique for escalating an Open-Redirect attack is using it in combination with phishing attacks. In this scenario, the attacker sends a phishing email or message to the victim, containing a link that appears to lead to a legitimate website. However, the link actually redirects the user to a fake website that looks identical to the legitimate one, but is controlled by the attacker. The victim can then enter their login credentials or other sensitive information, which is then obtained by the attacker.

Another method of attack escalation is to use the Open-Redirect vulnerability to launch cross-site scripting (XSS) attacks against the web application or its users. In this scenario, the attacker injects malicious code into the redirected URL, which is then executed by the victim's browser when it visits the URL. The code can be used to steal sensitive data, such as session cookies, or to perform actions on behalf of the victim.

Find the first Open Redirect

You are ready to find your first open redirect. Follow the steps in this lesson to test the target applications:

1. Find redirect URL parameters. This may be subject to parameter-based open redirect.

2. Find pages that perform referer-based redirects. These are referer-based open redirect candidates.

3. Test the pages and parameters you found for open redirects.

4. If the server blocks open redirects, try the protection bypass techniques mentioned in this lesson.

5. Consider ways to use open redirect on other bugs.

Prevention

Here are some best practices for avoiding vulnerabilities from Open-Redirect attacks:

Use a whitelist: Instead of blacklisting specific domains or URLs, use a whitelist approach that only allows trusted domains or URLs. This can prevent attackers from exploiting Open-Redirect vulnerabilities.

Validate input: Validate all input fields on your website, including URLs, to ensure they conform to expected patterns and do not contain any malicious symbols or characters.

Use HTTP-only cookies: Set the HttpOnly flag on cookies to prevent them from being accessed by malicious scripts.

Implement strict validation on redirect parameters: Only allow redirects to trusted domain or URLs.

Use safe redirection methods: Use safe redirection methods like "301 Moved Permanently" or "302 Found" instead of "meta-refresh" or "location.replace()".

Monitor website logs: Monitor website logs for suspicious activity or unauthorized attempts to exploit Open-Redirect vulnerabilities.

By applying these best practices, you can reduce the risk of Open-Redirect vulnerabilities and improve the overall security of your website.