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.
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.
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.
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,
1POST /login HTTP/1.1 2Host: bugbase.in 3Content-Type: application/x-www-form-urlencoded 4Content-Length: 70 5 6username=tuhin1729&password=BugB4$3_$3cur!7y&redirect=https://evil.com 7
This is usually considered an informational (P5) 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:
1?redirect_url= 2?next= 3?continue= 4?goto= 5?return_Url= 6?destination= 7?fromURI= 8?redirect= 9?go= 10?from= 11?return= 12?rurl= 13?checkout_url= 14
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:
https://bugbase.in/login?redirect=https%3A%2F%2Fbugbase.in%2Fdashboard%2Freports
https://bugbase.in/login?redirect=%2Fdashboard%2Freports
https://bugbase.in/login?redirect=/dashboard/reports
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,
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:
https://bugbase.in/login?redirect=/dashboard
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://[email protected]
(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,
1//evil.com 2http://ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ 3/\/evil.com/ 4\/\/evil.com/ 5
You can find a list of cool bypasses here.
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.
javascript:
pseudo-protocol to execute arbitrary code when the URL is processed by the browser. For example, take a look at the following payload:1https://bugbase.in/login?redirect=javascript:alert(document.cookie) 2
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.
[1] PayloadsAllTheThings: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect
[2] HackTricks: https://book.hacktricks.xyz/pentesting-web/open-redirect
A Guide to Open Redirection