Cybersecurity Awareness Month is here and in celebration, the Mariner Vulnerability Assessment and Penetration Testing team are showcasing some of their favorite hacking techniques. Each week in October, they will explain a vulnerability, demonstrate how they might exploit it, describe its potential impact, and maybe even share some tips on how you can protect yourself.
Mariner penetration testing services span a wide range of domains – web and mobile applications, internal and external infrastructures, phishing simulations, wireless security assessments, and more. Testing is performed by combining real-world techniques with tried-and-true standards to provide a realistic picture of your organization’s security posture. Vulnerabilities are identified, analyzed, and broken down with prioritized remedial recommendations to help your IT teams strengthen defences where you need it most.
Open redirect vulnerabilities are often viewed as a lower severity class of vulnerability, as they typically aren’t a vector that threat actors can use to attack a web application directly. However, under the right circumstances, threat actors can leverage these seemingly benign open redirects to steal user credentials by introducing an element of social engineering to the mix.
First, what is an open redirect vulnerability? Open redirects typically occur when a web application has some feature it uses to forward users to a different web page, usually in the form of a URL parameter. If the value in the URL parameter is not properly validated by the web application, it could be used to redirect users to external, untrusted websites.
One common place we see redirects is on login pages. Whenever a user browses to a page, a check is performed to see if the user’s current session is valid. If it isn’t, it would direct users to the application’s login page, while appending a URL parameter containing the path of the page the user tried to view. Then, upon successful login, the application would check to see if the login request contained this redirect parameter and would send the user back to the page they were originally navigating to.
Painting the Picture
For example, imagine after not visiting the application in a while, a user browses directly to https://coolwebapp.com/profile. Since they have not visited the application in a while, their session has expired. Upon navigating to /profile, the application checks the user’s session token sent alongside their web request, and determines it is no longer valid. As such, the user must reauthenticate, so the application sends the user to the login page. For the sake of convenience, the application appends the redirect URL parameter with the value of /profile onto the end of the login page URL, as shown in the screenshot below.
The redirect parameter on the login page, after a user attempted to view the profile page while unauthenticated.
Note, this URL parameter does not necessarily have to take the name “redirect”. Other common names include:
- url
- page
- return
Once the user submits their username and password and a valid session is created, the application checks for the value of the redirect parameter.
The user logging into the application with the profile page as the value of the redirect parameter.
The application then knows that the user was trying to view the /profile page before being prompted to login and sends them back to this page.
The user redirected to their profile page after logging in.
However, issues arise when the application does not properly validate this redirect parameter. In this case, the intended function is to only send users to pages hosted within the confines of the web application. What if a user were to manually supply an absolute URL? If the application does not properly validate the value of the parameter, it might allow users to be redirected to external websites.
A user logging in with an external website as the value of the redirect parameter.
In this example, https://marinerinnovations.com is set as the value of the redirect parameter. As we can see, when the user logs in, they are redirected to marinerinnovations.com.
The user redirected to marinerinnovations.com after logging in.
Leveraging the Attack
A threat actor could take advantage of this lack of validation by crafting a malicious URL that would redirect users to a malicious website they own. In this example, the threat actor crafts a malicious URL with the URL of a fake version of the login page hosted at https://evilwebapp.com/login as the value of the redirect parameter.
The user logging in with an absolute URL pointing to a malicious version of the login page as the value of the redirect parameter.
Any unsuspecting user who uses this link to log in would enter their username and password into the real application. Once they form a valid session with the real application, they would then be redirected to the fake application at https://evilwebapp.com/login.
The user being redirected to the fake, attacker-controlled version of the login page after successfully logging in to the real application.
As shown in the screenshot above, the user is redirected to the nearly identical fake login page (can you spot the difference?). By prompting the users with an error message saying they entered invalid credentials, they would be led to believe they made an error while typing and simply have to re-enter their credentials.
The user logging into the fake, attacker-controlled version of the application.
Should the user fall victim, they would then submit their real credentials into the fake login page. As shown in the screenshot below, the threat actor has successfully stolen the user’s email and password.
The console of the attacker-controlled web application, showing the successfully stolen set of credentials.
After stealing the user’s credentials, the fake application would then redirect the user back to the home page of the real application. Since the initial redirect to the fake application occurred after the user formed a valid session with the real application, the user is not prompted to log in again.
The user being redirected back to the real application after having their credentials stolen by the attacker-controlled version of the application.
The user believes nothing more occurred than a simple typographical error, when in fact they were just socially engineered into giving up their email and password.
URL Obfuscation
There is a good chance you’re thinking to yourself: “There is no way anybody would fall for a URL as obviously malicious as https://coolwebapp/login?redirect=https://evilwebapp.com/login.” Well, it’s possible you could be right. However, by performing obfuscation techniques such as encoding parts of the URL and adding irrelevant parameters, you might be shocked at how easily a malicious URL could slip by the unsuspecting eye. For example, the following two URLs would achieve the same results.
Obfuscated open redirect URLs such as these can be propagated through a plethora of social engineering scenarios. These include rogue employees sending similar URLs to coworkers via messaging apps, or external threat actors sending out sophisticated phishing emails.
Ways to Mitigate
Thankfully, the fix for this class of vulnerability is as simple as the vulnerability itself. Consider some of the following options:
- If your redirect feature is only intended to redirect users to pages in your application, ensure that only URL paths in the redirect parameter are accepted as valid (e.g., /profile, /account, /home)
- If your redirect feature requires the ability to redirect users to external websites, ensure only a strict whitelist of trusted domain names are accepted as valid.
If you want to learn whether your application is vulnerable to open redirects, or any other type of vulnerability, speak with one of our penetration testing experts by getting in touch today!
—
Sam Hansen, Cybersecurity Analyst
Let’s Connect