Introduction

Unvalidated Redirects and Forwards might no longer occupy a place in the OWASP Top 10 basket of most common vulnerabilities, as it did in 2013 and 2017, it is however known to harm your reputation. To know what it is and how it can affect your reputation, let’s understand Redirects and Forwards. You might want to learn about a 302 Response Status code, which refers to Temporary Redirect.

What is a Redirect and Forward?

For the sake of this argument, let’s consider Bob, the admin of the site bob.com. He wants to temporarily fix his site but, at the same time, doesn’t want the users to suffer because of the downtime. An idea strikes his mind. He thinks of redirecting his traffic to his friend Alice’s site, called alice.com.

So, what he does is, opens his admin panel and set up a 302 redirect to alice.com for any incoming request to bob.com.

What this will do is, if I, as a user will type in bob.com in my web browser, it’ll take me to bob.com, but the bob’s server, instead of returning me the webpage, will return me a 302 Status code, and a location header of alice.com. This will instruct my browser to visit alice.com. This, in brief is called a Redirect.

A forward, on the other hand, can refer to 2 scenarios. The first is when bob makes a link on the home page to the /login page. When a user clicks on it, he’ll be taken to bob.com/login. In this scenario, the user is being forwarded or taken to a page of the same website. In the second scenario, bob makes an external link that points to www.google.com. When a user clicks on it, he’s taken to google.com.

In the second scenario, Bob can also make use of a 302 redirect, as per his preference.

The difference is slight, and many do not even consider a redirect and forward to be different and often use them interchangeably.

What are unvalidated redirects and forwards?

Unvalidated Redirects and Forwards, also called URL Redirects, is a web application vulnerability when the application doesn’t validate or verify whether it should be redirecting the user to the provided domain, this is just like the input validation vulnerability in which the website trusts the inputs provided by the website and directly redirect the users on the provided website. This, unlike other vulnerabilities, doesn’t affect your website in any way. However, it can be used against the hacker to compromise his account(s), download malware onto his computer, and use it for phishing purposes.

Let’s consider Bob’s website bob.com. It has a redirect parameter that redirects/forwards a user to the URL provided after the user has successfully logged in.

https://www.bob.com/login?redirect=bob.com/dashboard

As you can figure out, after the user successfully logs in, he’ll be taken to bob.com/dashboard.

This, from a developer’s viewpoint, is safe and should work as expected. But Chris is a security researcher. He knows that the redirect parameter is vulnerable. So, what he does is tries to change bob.com/dashboard to chiristhehaceker.com. The result is https://www.bob.com/login?redirect=christhehacker.com

He logs in, and he finds himself redirecting to christthehacker.com.

How they are exploited?

From an attacker’s perspective, he’s hit the jackpot. He can achieve unimaginable things with URL redirects.

He no longer has to entice you to click on christhehacker.com. He can exploit your trust for bob.com, and with simple social engineering techniques, you will be redirected to his malicious website. Since a trusted website redirected you to christhehacker.com, you will easily believe that the second website is trusted, and you might provide sensitive information such as credit cards, login credentials, etc.

He can make the site similar to Bob’s, sell you fake news, download malware, and even disclose sensitive information.

URL Redirect, which appeared harmless a while back, can be exploited by hackers to achieve unimaginable things.

URL redirection can also be used to bypass CSP. Now, what is CSP? CSP stands for Content Security Policy and can be thought of as a policy that helps your browser decide from which source it can fetch resources and execute them. It is a good technique to prevent XSS Attacks. If one of the domains listed in CSP has a URL redirect issue, it can be used by the attacker to bypass CSP altogether.

An open redirect in OAuth can be equally exploited, but here it can lead to an account takeover. You can check out our blog on OAuth here (provide link).

Remediation

Now that we’ve discussed some of the exploitation methods, URL redirects, and their impacts, let’s go through some of the steps or measures that can be taken to prevent them.

1. If possible, try to avoid forwards and redirects. It might look like functionality but it can be full of opportunities for a hacker.
2. If, for some reason, you can let go of it, whitelist the URLs to which the website can redirect.
3. You can store a token ID mapped to each URL and stored in the database. You can stop URL redirection if the token ID doesn’t match the URL.
4. If the list of URLs is quite huge and then keeping them stored in a database and then checking each at a time would add to the latency, then what you can do is not store them at all. Instead, what you can do is display a message to the user every time he’s being redirected to a domain that doesn’t match your domain name.