Open redirects : bug bounties

What are open redirects?

An open redirect attack occurs when an attacker tricks a user into visiting a malicious site by providing them with a URL from a legitimate site that redirects to the attacker’s site. For example, an attacker could send a victim a link like https://falkensmaze-real-website.com/login?redirect=https://malicious-hacker.com, which the victim may believe is a page on the legitimate site, but is actually a malicious page that will automatically redirect the victim after they click the link.

Another type of open redirect is referer-based open redirect, which occurs when a website redirects to the page’s referer URL after certain user actions, like login or logout. Attackers can exploit this by hosting a site that links to the victim site, setting the referer header of the request and tricking the victim into believing they are on the legitimate site.

Open redirect vulnerabilities can be used to escalate other vulnerabilities and are often used in phishing attacks. It’s important for websites to properly validate and sanitize redirect URL parameters to prevent open redirect attacks.

How to prevent?

URL validators can use either a blocklist or an allowlist to determine if a redirect URL is legitimate. A blocklist checks for indicators of a malicious redirect and blocks those requests, while an allowlist checks the hostname portion of the URL against a predetermined list of allowed hosts. If the hostname matches an allowed hostname, the redirect is allowed to go through. Otherwise, it is blocked.

However, parsing and decoding URLs can be complex and URL validators may have difficulty identifying the hostname portion of a URL. This makes open redirects a common vulnerability in modern web applications. Attackers can exploit issues with URL validation to bypass open redirect protection.

How to hunt for open redirects?

  1. Look for redirect parameters

Often used URL parameters : (in bold)

https://example.com/login?redirect=https://example.com/dashboard
https://example.com/login?redir=https://example.com/dashboard
https://example.com/login?next=https://example.com/dashboard
https://example.com/login?next=/dashboard

To find potential open redirect vulnerabilities on a website, you can use a proxy while browsing the site and then look for any parameters in the HTTP history that contain absolute or relative URLs.

An absolute URL is a complete URL that contains all the components necessary to locate a resource, such as the URL scheme, hostname, and path. A relative URL must be combined with another URL by the server to be used and typically only contains the path component of a URL. Some redirect URLs may even omit the first slash character of the relative URL.

It’s important to note that not all redirect parameters have straightforward names like “redirect” or “redir.” Some examples of redirect parameters include “RelayState,” “next,” “u,” “n,” and “forward.” Be sure to record any parameters that seem to be used for redirecting, regardless of their parameter names.

In addition, pay attention to pages that don’t have redirect parameters in their URLs but still automatically redirect users. These pages may be candidates for referer-based open redirects. To find these pages, look for 3XX response codes like 301 and 302, which indicate a redirect.

2. Use Google dorks to find more redirect parameters :

Google dork techniques are a useful way to find redirect parameters on a website. To do this, you can start by setting the site search term to the target site: site:example.com. Then, you can search for pages that contain URLs in their URL parameters by using %3D, the URL-encoded version of the equal sign (=). This will allow you to search for terms like “=http” and “=https,” which are indicators of URLs in a parameter. For example, the search term inurl:%3Dhttp site:example.com will find URL parameters that contain absolute URLs.

You can also search for relative URLs by using %2F, the URL-encoded version of the slash (/). For example, the search term inurl:%3D%2F site:example.com will find URLs that contain “=/” and therefore return URL parameters that contain relative URLs.

Alternatively, you can search for the names of common URL redirect parameters. Some examples of search terms that will likely reveal parameters used for redirecting include inurl:redir site:example.com, inurl:redirect site:example.com, inurl:redirecturi site:example.com, and inurl:return site:example.com. By using these search terms, you can find URLs such as https://example.com/login?RelayState=https://example.com/home and https://example.com/logout?forward=home.

It’s important to note any new parameters you discover, along with the ones you found in the previous step.

*Useful list of dorks*

inurl:redir site:example.com
inurl:redirect site:example.com
inurl:redirecturi site:example.com
inurl:redirect_uri site:example.com
inurl:redirecturl site:example.com
inurl:redirect_uri site:example.com
inurl:return site:example.com
inurl:returnurl site:example.com
inurl:relaystate site:example.com
inurl:forward site:example.com
inurl:forwardurl site:example.com
inurl:forward_url site:example.com
inurl:url site:example.com
inurl:uri site:example.com
inurl:dest site:example.com
inurl:destination site:example.com
inurl:next site:example.com

3. Test for parameter-based open redirects:

This is the time when you need to pay attention to the functionality of each redirect parameter you have found and test each one for open redirects.

# examples

https://example.com/redir?n=http://attacker.com
https://example.com/login?n=https://google.com

Some websites will automatically redirect to the destination site when you visit the URL, without requiring any user interaction. However, for many pages, the redirect will not occur until after a user action like registration, login, or logout. In these cases, it’s important to perform the required user interactions before checking for the redirect. This will help you confirm that the redirect is occurring as expected.

4. Test for referer-based open redirects:

Test for referer-based open redirects on any pages you found in step 1) that redirected users, despite the fact that the URL does not contain a parameter. To test for these, set up a page on a domain that you own, and host the following HTML page.

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

Just replace the linked URL with your target page. Reload the HTML page, click on the link, and notice if you get redirected to your site automatically or after the user actions have taken place.

How to bypass open-redirect protection

Browser Autocorrect

https;google.com

https:google.com

https:/\/\google.com

https:\/\/google.com

This feature can help you bypass URL validation based on a blocklist. For example, if the validator rejects any redirect URL that contains the strings https:// or http://, you can use something like : https; , and you will get the same results.

Also, you can use backslashes (\) instead of forwards slashes, they both get interpreted the same by modern web browsers.

Flawed validator logic

http://legitcompany.com/login?redir=http://hacker.com/legitcompany.com/malicious-login.php

http://legitcompany.com/login?redir=http://legitcompany.com.hacker.com/login.php

In order for the validator to prevent attacks such as this, it might accept only URLs that both start and end with a domain listed on the allowlist. However, it’s possible to construct a URL that satisfies both of these rulse. E.G.

http://legitcompany.com/login?redir=http://legitcompany.com.hacker.com/legitcompany.com

This URL will redirect to hacker.com . The browser will interpret the first legitcompany.com as the subdomain name and the second one as the filepath.

Alternatively , you can use this symboll “@”, to make the first legitcompany.com the username portion of the URL:

https://legitcompany.com/login?redir=https://legitcompany.com@hacker.com/legitcompany.com

Using DATA URLS

data:MEDIA_TYPE[;base64],DATA

For example, you can send an image like this:

data:img;base64

We can use the data: scheme to construct a base64 encoded redirect URL that evades the validator completely. For example , this URL will redirect to legitcompany.com :

data:text/html;base64,PHNjcmlwdD5sb2NhdGlvbj0iaHR0cHM6Ly9sZWdpdGNvbXBhbnkuY29tIjwvc2NyaXB0Pg==

The data encoded in this url, PHNjcmlwdD5sb2NhdGlvbj0iaHR0cHM6Ly9sZWdpdGNvbXBhbnkuY29tIjwvc2NyaXB0Pg== , is the base64 encoded version of this script:

<script>location="https://legitcompany.com"</script>

Exploit URL decoding

Here is the original url:

https://company.com/@hacker.com

And here is the URL , URL-encoded once:

https://company.com%2f@hacker.com

Here it is double-encoded:

https://company.com%252f@hacker.com

What is left to do now, is try to combine all of the exploitation techniques, and you will find that you will be able to find and exploit more open redirects than you have ever had.

Thank you so much for reading through, if you’ve enjoyed this piece of contact, make sure to clap for the story and follow me , here on Medium, as it helps me build a community, and encourages me to continue to publish content like this.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store