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.
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.
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.
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
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.
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 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.
These redirect parameters vary across web applications and frameworks. In my experience, I've seen
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.
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), URL without protocol (
?next=//example.com), or even URL-encoded versions of any of the previous examples (
?next=%2F%2Fexample.com et al.).
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 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.
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.