What is
Open Redirect?

Open redirect attacks are a growing issue in web applications nowadays, as there are many serious vulnerabilities open redirects can lead to. As applications increasingly use external data sources, there's an increasing need to secure URL redirection.

In this post, we'll go over what exactly open redirect is, how this attack works, how you can detect it, and how you can prevent it.

What Is Open Redirect?

Before understanding what open redirect is, let's learn what redirect exactly means. 

A redirect is an HTTP response code that sends a user agent to a different URL from the one requested. Hackers use redirects for many reasons, including to implement a change in the structure of a website, to pass a user agent to a different website, or to serve the same content under multiple URLs. Still, if they're not implemented correctly, redirects may lead to open redirects.

Open redirect is a vulnerability that can be used to manipulate the application to redirect users to a different URL other than the one that's intended. This can be done by manipulating the URL to include the parameters that redirect the user to a different URL. This is one of the most common vulnerabilities found in most applications.

Open redirect vulnerabilities may result from insecure input validation on a website or a service that allows for parameter tampering. By performing a redirect, attackers can steal users' credentials, redirect users to phishing sites, and do more malicious things.

Types of Open Redirect

Open redirection (open redirect) is classified as one of two types: header- and JavaScript-based, also known as type I and type II open redirect. 

1. Header-Based Open Redirect Vulnerability

For example, the location header redirects the user to another location or resource. Still, an attacker can also use it to redirect the user to a malicious URL. Then, the attacker can use the location header to send the user to a phishing website by manipulating the URL to redirect the user after the authentication process.

2. JavaScript-Based Open Redirect Vulnerability

Industries use JavaScript to develop applications (both front end and back end). A web application's failure to validate the request URI before redirecting to an unintended destination can lead to this type of open redirect. Based on the scenario, this kind of issue can occur on either the front or back end.

Vulnerabilities That Arise Due to Open Redirect

A lot of people ignore the importance of addressing open redirection vulnerabilities. They think it's just a vulnerability that allows someone to redirect users to a different website. But hackers can use this vulnerability for much more.

Once a hacker finds and exploits this vulnerability, it's no longer just a matter of redirection. He can perform phishing attacks, cross-site scripting attacks, and even server-side request forgery attacks. Let's try to understand each of them one by one.

1. Phishing Attacks

Phishing attacks are the most common way for cybercriminals to steal users' credentials, and one of the most common attack vectors is the open redirect vulnerability.

2. Cross-Site Scripting Attacks

Hackers can use open redirect to execute XSS payloads by redirecting the parameter to JavaScript. The two most common payloads to convert open redirect to XSS are

• javascript:alert(1), and

• javascript://%250Aalert(1).

3. Server-Side Request Forgery

If the application sends HTTP requests to the redirect URL, open redirect can lead to server-side request forgery attacks.

How Hackers Exploit Open Redirect Vulnerability

Hackers carry out phishing attacks to steal your personal information like credit card details, username, password, etc. 

When the user accesses a website with a vulnerable parameter, the attacker crafts a URL to redirect the user to a malicious website. The URL can look like the URL below with the vulnerable redirectURL  parameter. Once the user opens the URL, he'll be redirected to https://example.phishing.com .

https://www.example.com/login?username=test&password=test&success=false&redirectURL=https://example.phishing.com

How Did the URL Redirect Happen?

In the URL provided above, example.com is a trusted domain, and redirectURL is the parameter that contains the URL where the user will be redirected after authentication. Two pointers make this URL perfect for phishing attacks:

1. The length of the URL is quite significant, which decreases the probability of the user reading the end part.

2. Users trust a URL after reading the trusted domain in the first part of it.

Once the user opens this URL, the application will redirect the user to the URL present in the redirectURL parameter. 

The malicious website will ask for sensitive information like a username and password, just like the original website. Once the user has provided the credentials, the attacker will have access to the user's account.

In many cases, the user doesn't realize they've been redirected to a malicious website until it's too late.

Understanding Open Redirect With Example (Code)

Suppose you have a website that has an email verification endpoint component made in ReactJS.

import React, { useState, useEffect } from 'react';
import { useLocation } from "react-router-dom"
 
 
export default function Email(){
 
const { search } = useLocation();
const queryParams = search.split('?').join().split('&');
 
const [loginData, setLoginData]=useState({
    token:'',
    validated:false,
});
 
const getRedirectURL =()=>{
    if(queryParams.length>0){
        const redirectTo=queryParams[1]?.split('=')[1];
        console.log(redirectTo);
        return redirectTo;
    }
}
 
const validateUserEmail =()=>{
    let response= "" // Send API request to validate user email
	let redirectURL = “”
    if (response.success){
    setLoginData({...loginData, validated:true});
        redirectURL = getRedirectURL();
    } else {
	redirectURL = “/login”;
    }
    if(redirectURL){
        window.location.href=redirectURL;
    }
}
 
useEffect(()=>{
    validateUserEmail()
},[]) 
return(
    <div className="login-form">
        {
            !loginData.validated? <h1>Email Not Verified</h1>: <h1>Redirecting to /dashboard</h1>
        }
    </div>
)}

In the example above, we have a functional component for email verification on /email route. The URL for email verification will look like this:

http://www.example.com/email?token=xyz&redirectTo=/dashboard

Once the user opens the email verification link, the component will validate the email verification token from the URL and redirect the user to the redirectURL parameter if the email is verified; otherwise, a redirect will occur to the /login route.

The code mentioned above is vulnerable to open redirect. If the attacker crafts a URL with a malicious redirectURL  parameter, he can redirect a user without hassle.

http://localhost:3000/email?token=helloIamaToken&rediectTo=https://www.evil.com

To prevent open redirect in the code provided above, rather than using window.location.href, it's recommended you use the useHistory hook. The sample code looks like this:

import React, {useState, useEffect} from 'react';
import {useHistory, useLocation} from "react-router-dom"

export default function Email(){
const { search } = useLocation();
const history = useHistory();

const queryParams = search.split('?').join().split('&');

const [loginData, setLoginData]=useState({
    token:'',
    validated:false,
});
 
const getRedirectURL =()=>{
    if(queryParams.length>0){
        const redirectTo=queryParams[1]?.split('=')[1];
        return redirectTo;
    }
    return;
}
 
const validateUserEmail =()=>{
    let response= "" // Send API request to validate user email
    setLoginData({...loginData, validated:true});
    let redirectURL = getRedirectURL();
    if(redirectURL){
        // Redirect User to the URL using history.push
        history.push(redirectURL);
    }
}

In the code above, the user will be redirected to http://localhost:3000/https://www.evil.com even if the attacker tries to manipulate the parameter.

Furthermore, to add an extra layer of security, developers can create a helper function to check if a URL is a relative URL or not.

Now that we understand how open redirect happens, let's focus on a few things you should keep in mind to avoid open redirects.

3 Things to Avoid With Open Redirects

Open redirect is a fairly common issue on the web, so it's essential to keep these points in mind to avoid such risks.

1. Avoid redirect parameters in URLs, store them in localstorage, or use custom paths using code instead.

2. If you use redirect parameters, validate the supplied input (query strings).

3. Use whitelisting and validate if the URL is relative or not while implementing redirects.

Best Practices to Avoid Security Vulnerabilities

Security is one of the most important factors to consider while building a web application or website. It's the gateway to your customer's information or data. You must take every possible step to avoid security risks. Below is a list of best practices to prevent security vulnerabilities in your web application.

1. Always Validate User Input

User input is one of the biggest causes of security vulnerabilities. When an application takes user input and then blindly acts on that input, it opens itself up to a whole new set of vulnerabilities.

2. Keep Sensitive Data Out of Logs

Data in your logs should be the bare minimum. This means you should never log essential data like username, password, credit card information, etc. You can add data that helps with debugging and analytics. If you see data or information that can compromise security, then you shouldn't include it in your logs.

3. Use Always Deny Rule

The simplest way to think about this is that all access controls are denied if you don't explicitly allow something. If you can identify potential issues early on in the design of a system, you can prevent those issues from taking effect. It's easy to deny access to everything by default and then determine what access you need to allow. 

4. Automate Testing for Security Vulnerabilities in the Build Pipeline

In the ever-changing web application development landscape, companies need to take extra steps to ensure that there are no security vulnerabilities in their web applications. Developers' primary focus is on the end product and not on the security vulnerabilities that may exist on the platform. This is where a security scanner like StackHawk comes into play. 

StackHawk offers a DAST scanner that is integrated into a development pipeline.

It helps developers identify and fix security issues early on in the development cycle, ultimately saving development time, saving money, and ensuring a more secure end product.

Conclusion

Now that you've read our post about open redirect vulnerability, you should be aware of the potential dangers an open redirect vulnerability can cause and know how to protect yourself against such hazards.

If you have any questions about protecting yourself from such threats, our team can help you identify the issue and find the right solution.