How'd I Get Here?

NOTE: The content in this post is solely for educational purposes. Do NOT attack entities that did not provide consent beforehand.

In this post, we'll cover what Open URL Redirection Vulnerabilties are, how to exploit them, and how to prevent them. I was motivated to write this, because I've lately been discovering these vulnerabilities in the wild, and I want to increase vendors', users', and researchers' awareness of them.

What is URL Redirection?

URL Redirection is a method used by web applications to manage a user's navigation throughout the app. This is often seen during authentication, where a user is registering for or logging into an application, and the application wishes to redirect the user to another page once they've been authenticated.

So, what's the problem?

What happens when we set the location to which a user will be redirected to a completely different website? If the application still redirects us to the website, its URL redirection logic could be too "open". If we can have it redirect us to any website we'd like, we might be able to use this to attack users of the website.

What does this look like?

Sometimes when you're at a login page for some website like hackus.now.sh, you might see the URL looks like hackus.now.sh/login?next=/dashboard. That URL communicates that, once you've logged in, you'll be redirected to the dashboard page, which looks like hackus.now.sh/dashboard.

We established earlier that URLs that contain the location to which we'll be redirected are potentially vulnerable to Open URL Redirection. This is because the target doesn't perform adequate verification or sanitization of the values of the next parameter. With that being said, what happens if we instead set the destination toexample.com? To see that, we can visit hackus.now.sh/login?next=https://example.com. If, after logging in, we're redirected to example.com, our target is definitely susceptible to Open URL Redirection.

How can we craft an attack?

As with many high-impact attacks, we can chain our exploitation of this vulnerability with other exploits to achieve certain effects on a target or targets. For example, we can utilize social engineering and a CVE that lets us break out of the browser sandbox and execute code on the host computer to take control of a target's device.

In theory, this could be achieved by using the social engineering to have our target visithackus.now.sh/login?next=imdangerous.com and log in. In this case, our target's visit toimdangerous.com will cause our exploitation of the aforementioned CVE to take place, allowing us to run code on the target's machine and likely take control of it.

What if there's no next parameter?

These redirect parameters vary across web applications and frameworks. In my experience, I've seennext, goto, redirect, and redirect_to. They could take so many forms that you could even use a wordlist and fuzz for valid redirection parameters to test for openness.

How creative can we get with this?

Very! If we wanna get creative with the redirection payload, we can change the form of the URL. For example, if the payload looks like ?next=/dashboard and we want to redirect to example.com, we can try the URL with protocol included (?next=https://example.com), just the host (?next=example.com / ?next=/example.com), URL without protocol (?next=//example.com), or even URL-encoded versions of any of the previous examples (?next=%2F%2Fexample.com et al.).

Another creative approach is to try different protocols in the payload! Some browsers support FTP and IPFS URLs, so we could plug those kinds of URLs in the payload and observe effects. A payload that often increases the impact of vulnerabilities of this type is using JavaScript as the payload's protocol. Using payloads of the form ?next=javascript:{some-code} can sometimes be used to perform DOM-based XSS.

The Attack in the Wild

An Open Redirect vulnerability was exploited in the United States Department of Health and Human Services' Departmental Contracts Information System during the novel coronavirus disease (COVID-19) pandemic. In short, attackers sent crafted a URL of the formhttps://dcis.hhs.gov/cas/login?service=malicioussite.com&gateway=true that redirected victims to a website that has a victim unknowingly download and execute malware. More information on this particular attack can be found here.

I also have a writeup detailing my discovery and disclosure of an Open Redirect vulnerability in Repl.it's web application.

In Conclusion

Open URL Redirection is a type of vulnerability where an application redirects users to any location provided in its URL. This type of vulnerability is typically used in a chain of exploits to achieve higher impact attacks. At times, these vulnerabilities could even lead to XSS! To mitigate the risk of an application's vulnerability to Open URL Redirection, developers and security engineers must ensure that their applications whitelist and/or sanitize the values of their redirection parameters.

I typically report these vulnerabilities with low severity, although depending on the nature of the application or range of allowed payloads I might give medium or high severity to my findings.