Open redirects : bug bounties
What are open redirects?
Open redirect vulnerabilities occur when websites use HTTP or URL parameters to redirect users to a specified URL without user action. This behavior is often used for convenience, but it can also be exploited by attackers.
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?
To protect against open redirect attacks, servers need to ensure that they are not redirecting users to malicious locations. One way that websites can do this is by implementing URL validators.
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?
Today, we’ll talk about hunting for a simple open redirect. You can find simple redirects by using recon tricks.
- 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.com3. 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.comSome 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
The first method we are going to discuss is the usage of browser autocorrect. We can use this feature to construct alternative URLs that redirect offsite. Modern browsers often autocorrect URLs that don’t have the correct components, in order to correct gibberish URLs , caused by typos. For instance, Google Chrome will interpret all of these URLs as https://google.com :
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
In case you have tried the previous bypassing procedure and it failed, you can try this one which attempts to do the same thing. Here , we are directly exploiting the application’s logic. For example, as common defense against open redirect vulnerabilities, URL validators check if the redirct url starts with , contains or ends with the site’s domain name. You can bypass this type of protection by creating a subdomain or directory with the target’s domain name.
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 URLs use the data: scheme to embed small files in a url. They are constructed in this format:
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
Double Encoding:
Here is the original url:
And here is the URL , URL-encoded once:
Here it is double-encoded:
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.
