Open redirect

An open redirect vulnerability occurs when an application allows a user to control a redirect or forward to another URL. If the app does not validate untrusted user input, an attacker could supply a URL that redirects an unsuspecting victim from a legitimate domain to an attacker’s phishing site.

Attackers exploit open redirects to add credibility to their phishing attacks. Most users see the legitimate, trusted domain, but do not notice the redirection to the phishing site.

Although this vulnerability doesn’t always directly impact the legitimate application, the company's reputation can be negatively impacted. In addition, open redirects may not seem like a high impact on the organization itself, it’s important to avoid damaging the trust users have in the business. It’s worth noting, an open redirect in your own site may very well be used against your own employees!

During this lesson, we will learn how open redirects work, why they work, and how to prevent them in your application. We’ll look at how a vulnerable application can be abused to collect some credit card details. After that, we’ll look under the hood at the code that made this possible. We will then update the code to fix the vulnerability.

Music fanatic and struggling DJ, Josie has woken up in the morning and is checking her emails. She finds an amazing offer in her inbox, her favorite music streaming service is on sale! Normally, MusiqueAimer is a $60 per month subscription but for a very limited time is only $10 a month.

Josie clicks the link in the email and is directed to the MusiqueAimer login page. She logs in and is then asked to enter her credit card details to process the new subscription. She enters all her details but is disappointed as a banner displays, “Sorry, you are not eligible for this deal” and is redirected to the homepage.

Later that week, Josie checks her credit card balance and finds numerous transactions she hadn’t made!

When we edited the redirect_url parameter and sent it to Josie, the legitimate application redirected her to our phishing page after she signed in. Since there is no validation of the URL, anyone can arbitrarily provide whatever URL they like.

Josie didn’t even notice the redirect to our phishing page because it looks exactly like the legitimate MusiqueAimeers website. Even if she checked the URL, it probably wouldn’t have raised concern since they are very similar. So, without any worries raised, Josie entered her credentials into our site where we were able to capture them. After presenting her with a seemingly legitimate reason as to why we couldn’t provide a discount, she was redirected to her home page. I’m sure she would be upset about not getting a discount, but she didn’t expect that she’d actually just lost her money!

Using open redirects for phishing is so effective because we are providing a link to a known legitimate site. Even if the victim is tech-savvy and checked the URL’s domain and maybe even the SSL certificate, the redirection will still lead to an unwanted location.

The code on the backend might look something like this vulnerable code snippet from the official C# documentation:

Along with phishing and social engineering implications, open redirect vulnerabilities may also be chained with other vulnerabilities to increase their impact. For example, an open redirect may allow an attacker to:

• Bypass a domain-based server-side request whitelist to achieve full-blown server-side request forgery
• Redirect to a URL with the javascript: schema, resulting in XSS
• Steal secret tokens via the referrer header

There are several ways to fix this code so that the open redirect is no longer possible. We can find a way to validate the input in the parameter so that only legitimate locations are accepted, or we could remove the parameter altogether.

This is the safest way to fix the open redirect but depending on how your application is set up, it could disrupt the flow of the application and impact the user’s experience. If the user was trying to access a different page, such as the contact details, the user would have to navigate from their profile to the contact details instead of the app redirecting them straight to the contact details. To remove the parameter completely and implement a fixed redirect, we’d edit our code to look like this:

This is the safest way to fix the open redirect but depending on how your application is set up, it could disrupt the flow of the application and impact the user’s experience. If the user was trying to access a different page, such as the contact details, the user would have to navigate from their profile to the contact details instead of the app redirecting them straight to the contact details.

If removing the parameter doesn’t work for your application flow, then we could alter the code to only allow redirects to pages from an “allow list”. All redirect_url parameters that are not equal to either the profile or contact details page will simply redirect the user to the home page after login.

Alternatively, if your application contains many potential legitimate pages to redirect to, we implement a fixed domain and simply append the redirected page.

The best way to do this is by implementing IsLocalUrl() from the System.Web.Mvc.Url helper class.

Most mobile devices will only show the domain of the site you’re visiting and will exclude any parameters, including redirections. This makes it very tricky for mobile users to spot a malicious redirect.

There's more to learn! Check out these links:

• Take a look at OWASP's unvalidated redirects and forwards cheat sheet
• Learn more about open redirection reflected