Vue Open Redirect
Guide: Examples
and Prevention

Building fast and reliable websites that satisfy the needs of your clients while providing a safe and reliable service is a must. Users expect a twenty-first-century business to not only have a website and a full-fledged platform but also a mobile app and excellent customer support. Websites and apps ought to be attractive and performant at all times.  

What's more, these solutions need to provide state-of-the-art security for their users. Additionally, you must constantly keep them updated to protect against new threats that arise daily. Gone are the days of patience and leniency from customers. It's either astoundingly good or garbage. 

This means that developers' standards are constantly rising. We're in a never-ending chase for the top. If you're in the field, you know there's no stopping the tug of war between threats and mitigation. Unfortunately, attackers favor popular, susceptible platforms, and it's our responsibility to protect them. 

This article will serve as an introduction to open redirect vulnerabilities. It will focus on the various vulnerabilities commonly found in platforms without proper security. Additionally, we'll discuss how to apply mitigation measure against them, specifically in Vue.

Additionally, if you have limited or no experience with Vue.js or Node.js, you might find these resources handy: 

• Introduction to Node.js

• Introduction to Vue.js

Now let's dive in.

Explaining Open Redirect

To fully understand open redirect, you first need to understand what a redirect is. A redirect works by moving a user from one URL to another, usually to perpetuate functionality or as a contingency against an incursion to an incorrect or unauthorized address. Essentially, redirects ensure that the users follow the proper flow of a predefined user case.  

They're both necessary and ubiquitous on the web. This also makes them targets for bad actors trying to guide users to malicious websites. 

Open redirects, on the other hand, occur when a web application accepts unvalidated input and ends up redirecting users to malicious websites. This then becomes a path for attackers to engage in phishing scams or to steal a visitor's credentials. 

Unfortunately, open redirects are one of the most overlooked threats that users can become victims of nowadays. They tend to be neglected by the development and security communities because their impact on the platform itself is low and vulnerable code is rare. But users are vulnerable. And sufficiently determined attackers can cause significant damage.

Open Redirect Examples

To illustrate the point, let's see how an open redirect attack would look like in the real world. 

Wow, that seems so simple, right? We can glean from this URL that the vulnerable site 'mysafesite.com' includes a 'page' with 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 does not validate the URL to redirect appropriately, the user will be redirected to a malicious site controlled by the attacker. Additionally, since the URL contains the legitimate domain, an attacker could easily fool the user about the legitimacy of the malicious site.  

Trouble on the Way

Once the user is on the attacker's site, the attacker can disguise the site to match the legitimate site and ask for credentials, which the victim will likely provide. Finally, the attacker will 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.

You can probably imagine the security engineer in your team advocating for your dismissal for even considering such a poor implementation. And you might understandably think that this kind of implementation must be nonexistent in this day and age. But you might be surprised by the abundance of poorly implemented solutions like these. 

This is not 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 along with phishing and cross-site scripting. These exploits work in synergy as a more sophisticated, multistep attack to thwart more resilient and robust platforms. 

Open redirect attacks include 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 hinge on the logic behind the redirect in the platform. Additionally, no JavaScript is necessary for this 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 don't work for server-side functions.

Mitigating Open Redirect Vulnerabilities

To mitigate open redirect vulnerabilities, you must rethink your approach to solutions that are 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'll 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. 

If, however, you must have redirects, consider limiting the possible redirection destinations available to users. Using fixed options in HTML elements can go a long way toward 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. 

Implementation

You can implement such a solution both on the back end (Node.js) or in Vue itself if you provide a JavaScript-based redirection with an approach like the following: 

const safelist = ['/user', '/photos', '/settings'];

if (safelist.indexOf(req.query.to_url) > -1) {
  res.redirect(req.query.to_url);
  //this.$router.push(req.query.to_url);
} else {
  res.redirect('/');
}

This confirms that the provided user input is on the safelist with a simple match. However, you can implement a more robust and complex matching solution with a RegEx. 

Moreover, you can add an extra layer of security by explicitly indicating the URL's domain in the redirect. This way, if the attacker manages to exploit the safelist, the attack will not be able to take the user away from your domain.

const safelist = ['/user', '/photos', '/settings'];

if (safelist.indexOf(req.query.redirect_url) > -1) {
  res.redirect('http://mysafesite.com/' + req.query.to_url);
  //this.$router.push('http://mysafesite.com/' + req.query.to_url);
} else {
  res.redirect('/');
}

We need to mention that there's an open vulnerability in Vue.js that might allow attackers to bypass all mitigation strategies. Learn more about it here. 

Beyond these strategies, you can implement platform solutions like firewalls, redirection notices, etc. 

It's essential to note that performing penetration tests and security audits and keeping your libraries updated is considered good practice and a must. However, doing all this work can be time-consuming and complex. That's why we encourage you to consider StackHawk. StackHawk tests your running applications, services, and APIs for security vulnerabilities that your team has introduced as well as exploitable open source security bugs. 

With StackHawk, application security can keep up with the pace of today’s engineering teams. Find vulnerabilities at the pull request and quickly push out fixes, all while yesterday’s security tools are waiting for someone to kick off a manual scan. 

The Takeaway

Open redirect attacks may be a lesser threat to platforms and apps, but the potential for damage to users is high. So you need to ensure that your efforts are comprehensive and that all possible threats are considered. 

Mitigating every conceivable vulnerability can be demanding, and it may sometimes feel like it's not worth the time and effort when considered against other potential vulnerabilities. But you're responsible for bringing safe solutions to your clients and not betraying their trust. 

Addressing these vulnerabilities isn't complicated. It just takes time.  

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.