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