This post aims to provide the reader with insight and guidance about open redirect vulnerabilities. We'll focus on the different vulnerabilities that one can typically find in platforms without appropriate security and how to apply mitigation measures against them.
It's important to know that our discussion of open redirect will be concise and limited in scope. Furthermore, if you have limited experience with .NET (the development stack of choice for this article), you might want to check out Microsoft's ASP.NET documentation.
What Is Open Redirect?
To understand open redirect, it's crucial that you first understand what redirects are and why they are so prevalent on the web.
Redirects are how a platform moves a user from one URL to another to perpetuate functionality. Additionally, developers use them as a contingency against incursion from an incorrect or unauthorized address. Broadly speaking, redirects serve as a tool for developers to ensure that their users follow a proper flow.
Understanding this, one can see how they are necessary and ubiquitous on the web. Yet this also makes these redirects potential targets for bad actors trying to mislead users and direct them to malicious websites.
Open redirects occur when a web application accepts unvalidated input and ends up redirecting users to malicious websites. Now attackers have a path when using phishing scams or attempting to steal a visitor's credentials.
Sadly, open redirects are one of the most overlooked threats that users can become victims of nowadays. The logic behind the neglect from the development and security community is mainly that the impact on the platform itself is low and vulnerable code is rare.
Despite this, users can still become victims of these exploits, and sufficiently determined attackers can exploit users and, in fact, cause significant damage to the level of confidence users have in your platform.
Exploring Some Open Redirect Examples
Now that you have a basic understanding of what open redirect is, we'll illustrate the point. Let's see what an open redirect attack would look like on the web.
http://mysafesite.com/page.php?to_url=http://attackersite.comYou should be able to see from this URL that the vulnerable site 'mysafesite.com' contains a page named 'page' that includes a feature that receives user input, in this case a URL in the query string, and uses it to redirect the user.
When an unsuspecting user clicks on this link, the browser redirects them to the legitimate website. However, if the server doesn't validate the URL to redirect appropriately, it will redirect the user to a malicious site. Additionally, since the URL contains the legitimate domain, an attacker could easily fool the user about the legitimacy of the malicious site.
Once the user is on the attacker's site, the attacker can disguise the website and ask for credentials. Finally, the attacker can redirect the user back to the legitimate site after storing the credentials. Thus, the attacker succeeds at procuring the credentials, and the victim is none the wiser.
Bad News
You may already hear the security engineer on your team advocating for your dismissal for even considering such a poor implementation. And understandably, you probably think that this kind of implementation must be nonexistent in this day and age. Yet you would be surprised by the abundance of poorly implemented solutions like these.
This is not to say that this is the full extent of open redirect vulnerabilities. Far from it. Despite the low level of sophistication found in open redirect attacks, they usually exist as part of a suite of exploits with phishing and cross-site scripting. These exploits work in synergy as a more sophisticated, multi-step attack to thwart more resilient and robust platforms.
Open redirect attacks are of the following kinds:
Header-Based Open Redirect
Header-based open redirect attacks exploit vulnerable code directly by the user input. Much like the example above, these attacks heavily hinge on the logic behind the redirect in the platform and social engineering. Additionally, no JavaScript is necessary for this attack to work, so it's particularly nefarious.
JavaScript-Based Open Redirect
JavaScript-based open redirects are triggered only when executing JavaScript as part of the redirect functionality. Therefore, unvalidated redirects of this form do not work for server-side functions.
How to Prevent Open Redirect Vulnerabilities
In order to prevent open redirect vulnerabilities, you must rethink your approach to solutions dependent on redirection.
The most successful solution for open redirect is, well, to do away with redirects. This, of course, might not be a viable solution for some, and we will offer some alternatives, but we do want to emphasize that even if you think you need redirection, you actually might not. There are more modern, safe, and secure ways to provide the same functionality without opening yourself to this vulnerability.
If, however, you must have redirects, consider limiting the possible redirection destinations available to users. But, again, using fixed options in HTML elements can go a long way in mitigating these exploits.
Additionally, parsing and identifying potentially malicious inputs can weed out many of the attacks the service might receive. For example, if the user is not supposed to leave your domain and is showing an intent to do so, that is already a red flag. In .NET, we can implement such a solution with the "LocalRedirect" helper.
public IActionResult SomeAction(string redirectUrl)
{
return LocalRedirect(redirectUrl);
}Simply adding the helper to the provided input does the trick.
"LocalRedirect" will throw an exception if a non-local URL is specified. Otherwise, it behaves just like the redirect method.
Going Further
Moreover, by using the "Url.IsLocalUrl" method, we can check if a provided URL is local and change the behavior of an application if we need to handle such behavior.
private IActionResult RedirectToLocal(string returnUrl)
{
if (Url.IsLocalUrl(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction(nameof(HomeController.Index), "Home");
}
}
The "URL.IsLocalUrl" method protects users from being inadvertently redirected to a malicious site. In addition, you can log the URL details provided when a non-local URL is supplied in a situation where you expected a local URL. Logging redirect URLs may help you diagnose redirection attacks.
Beyond these strategies, you can implement platform solutions like firewalls, redirection notices, etc.
It's crucial to be aware that performing penetration tests, security audits, and keeping your libraries updated is considered good practice and the best way to ensure the security of your platform. However, doing all this work can be time-consuming and complex. That's why we encourage you to consider using StackHawk.
Conclusion
As you have seen, addressing these vulnerabilities is not complicated. It just takes time.
Doing vulnerability mitigation on all possible fronts can be demanding and sometimes not worth the time of development when considered against other potential vulnerabilities to address. This is why we encourage you to consider robust and tested solutions for your team.
We hope that this article has helped you provide better solutions for your users and clients.
This post was written by Juan Reyes. Juan is an engineer by profession and a dreamer by heart who crossed the seas to reach Japan following the promise of opportunity and challenge. While trying to find himself and build a meaningful life in the east, Juan borrows wisdom from his experiences as an entrepreneur, artist, hustler, father figure, husband, and friend to start writing about passion, meaning, self-development, leadership, relationships, and mental health. His many years of struggle and self-discovery have inspired him and drive to embark on a journey for wisdom.
