How'd I Get Here? Exploiting Redirection
Tags: security, webdev, hacking, pentest
Published: 2020-04-04 02:15:36

This post was first featured on [my blog](https://blog.aunyks.com/2020/2/howd-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 developers', users', and security 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 to `example.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](https://www.cvedetails.com/cve/CVE-2019-11708) to take control of a target's device.

In theory, this could be achieved by using the social engineering to have our target visit `hackus.now.sh/login?next=imdangerous.com` and log in. In this case, our target's visit to `imdangerous.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 seen `next`, `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](https://owasp.org/www-community/attacks/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](https://dcis.hhs.gov/) during the novel coronavirus disease (COVID-19) pandemic. In short, attackers sent crafted a URL of the form `https://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.

# 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.

---
Thanks for reading. If you have any questions for me about this post or anything else, please feel free to message me on [Twitter](https://twitter.com/aunyks)!