A Guide to Open Redirection

Hey everyone! My name is Tuhin Bose, currently working as a Security Engineer at BugBase. In this blog, we are going to explore Open Redirection vulnerability - understanding what Open Redirection is, why Open Redirection exists, types of Open Redirection, possible ways to identify the vulnerability, popular ways to bypass existing filters and escalating Open Redirection to increase the impact.

What is Open Redirection?#

Open Redirection vulnerability occurs when a web application allows a user to be redirected to an external website without proper validation. Imagine you got a text message that says, "Get a chance to win an iPhone 15 Pro - Register here: https://facebook.com/endpoint?redirect=https%3A%2F%2Fevil.com%2F".
Now since you trust the domain facebook.com, you might click on the link, thinking it is a legitimate giveaway from Facebook. However, upon clicking the URL, you get redirected to another domain evil.com. Now most people won't notice the domain since they know that they have opened Facebook. So if you are asked now to enter your personal details, you will end up giving those as you trust Facebook. However, these details will be sent to a malicious domain, not Facebook.

So what happened here? Basically, facebook.com didn't validate the URL properly before redirecting. The attacker took advantage of this behaviour to conduct a phishing attack on the victim by exploiting the trust relationship between the user and Facebook.

Why Open Redirection Exists?#

Many developers want the user to be redirected after certain actions. Let's say, you want to view all the vulnerability reports submitted by you at bugbase.in. So you simply open your browser and directly navigate to https://bugbase.in/dashboard/reports. But what if you're not logged in or your cookies are expired? In such cases, the developer may configure the application in such a way that it'll redirect you to the login page and once you enter the correct credentials, you'll be redirected to the destined page (in this case, your reports section). To implement this, once you try to access the reports section without logging in, the application will redirect you to a URL like this: https://bugbase.in/login?redirect=https%3A%2F%2Fbugbase.in%2Fdashboard%2Freports&expired=true and if you enter correct credentials, the application will redirect you to the value of redirect parameter which is https://bugbase.in/dashboard/reports.

Now imagine the developer forgets to implement any filter (or protection) on the redirect parameter. So as an attacker, I can simply construct a URL like this: https://bugbase.in/login?redirect=https%3A%2F%2Fevil.com%2F&expired=true and send it to the victim and perform the above attack.

Types of Open Redirection#

Open Redirection can be classified into two types based on the request type - GET based open redirection and POST based open redirection.

• GET Based Open Redirection: In case of a GET based open redirection, a GET parameter is responsible for the redirection, just like the previous case.

• POST Based Open Redirection: Here, a POST parameter is responsible for the redirection. For example,

This is usually considered an informational (P5) vulnerability.

Identifying Open Redirection Vulnerability#

While looking for open redirection vulnerability, the main task is to find the right parameter that can control the flow of redirection. Some of the common parameters are:

Here is my methodology to find Open Redirection vulnerability in a target:

• Google Dorks: Although this might not be effective for most small or medium-scale businesses, still I want to include it as sometimes it might be really helpful to find some hidden parameters. We can construct a Google dork to search for popular parameters along with the target name. For example, searching "next=" site:bugbase.in or inurl:"next=" site:bugbase.in might result in giving some URLs with next parameter which are indexed by Google.

• Keyword Search: According to me, this is one of the easiest and most effective methods. All you need to do is search for some specific keywords. Before knowing the keywords, let's see how you can identify a parameter suspectable to open redirection vulnerability. Generally, the parameter can hold any of the 4 values:

1. https://bugbase.in/login?redirect=https%3A%2F%2Fbugbase.in%2Fdashboard%2Freports
2. https://bugbase.in/login?redirect=%2Fdashboard%2Freports
3. https://bugbase.in/login?redirect=/dashboard/reports
   In some cases, the application encodes the value into base64:
4. https://bugbase.in/login?redirect=aHR0cHM6Ly9idWdiYXNlLmluL2Rhc2hib2FyZC9yZXBvcnRz

So from these, we can get 4 keywords =http, =%2F, =/, =aHR. Now the question arises where to search these keywords?
My recommendation will be,

1. Crawl the website in burpsuite, click on every button you encounter and then search these 4 keywords using Burp search.
2. Get all the URLs from public archives (Wayback Machine, AlienVault's Open Threat Exchange, Common Crawl, etc) and use grep to extract these keywords.

After this, you can simply replace the value with any other URL to test the vulnerability.

Here are some bonus tips to find Open Redirection:

• Perform a parameter discovery on forms (signup, login, contact us, etc) that you encounter. Sometimes, you'll find some hidden parameters that might control the flow of redirection after the form is submitted.
• Try to access any authenticated page (profile, dashboard, etc) in a browser where you're not logged in to the application. In such cases, the application may redirect you to the login page which has some parameters pointing to the destined page like https://bugbase.in/login?redirect=/dashboard
• Run a nuclei scan on the target. Sometimes you'll end up finding open redirection via path fragments or some open redirection based CVEs.

Bypassing Existing Protection#

Now you already know how to find open redirection vulnerability. But what if the application has already some protection mechanism in place against it? Well, there are some ways that can help you to bypass the protection (if it's poorly implemented).

For example, sometimes the application simply checks if the value of the redirection parameter starts with https://target.com. This is to ensure that the redirection doesn't send the user to some random domains. However, this can be bypassed using the payload: https://target.com@evil.com (this will attempt you to log in to the site evil.com with the username target.com; a way of sending credentials in Basic Authentication) or https://target.com.evil.com. Some more techniques to bypass can be,

You can find a list of cool bypasses here.

Escalating Open Redirection#

Now since you already learnt about finding open redirection and bypassing filters, let's see how you can escalate an open redirection to some higher severity vulnerabilities such as XSS or Account Takeovers.

• Achieving Cross-site Scripting: This is one of the most popular way. An attacker can simply construct a URL with the javascript: pseudo-protocol to execute arbitrary code when the URL is processed by the browser. For example, take a look at the following payload:

• Stealing OAuth Token: An attacker can simply change the redirect_uri parameter value with the open redirection URL.

• SSRF Whitelist Bypass: If you have found an SSRF on the application but are unable to exploit this further because of whitelisting (only target.com or its subdomains are allowed), you can use open redirection to bypass the whitelist and try exploiting the SSRF further.

References#

[1] PayloadsAllTheThings: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect
[2] HackTricks: https://book.hacktricks.xyz/pentesting-web/open-redirect