Improper validation of front-end provided redirect links
What is an 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!
About this lesson
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.
A highly sophisticated phishing campaign was identified in 2020 with a very interesting use of open redirects. The attackers used over 350 unique domains to host their phishing sites, which were automatically generated using a domain-generation algorithm (DGA). The scale and effort put into this attack's infrastructure indicate that open redirect abuse can be very profitable!
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!
- STEP 1
- STEP 2
- STEP 3
- STEP 4
- STEP 5
Setting the stage
We’re going to step into the shoes of the attacker who sent Josie the email, and find out how her credit card details were compromised.
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.
Chaining Open Redirect Vulnerabilities
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:
How do you mitigate open redirect?
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.
Remove the parameter
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:
Implement an “allow list”
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.
Implement a fixed domain
Alternatively, if your application contains many potential legitimate pages to redirect to, we implement a fixed domain and simply append the redirected page.
Mobile users beware
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.
91% of all cyber attacks start with email! A lot of people are well-educated now to recognize phishing emails but are rarely taught how to spot a malicious redirect. This is why open redirects are so valuable to attackers.
You have taken your first step into learning what open redirection is, how it works, what the impacts are, and how to protect your own applications. We hope that you will apply this knowledge to make your applications safer. We'd really appreciate it if you could take a minute to rate how valuable this lesson was for you and provide feedback to help us improve! Also, make sure to check out our lessons on other common vulnerabilities.