Redirection is the technique in web development to automatically send the user from one web page to another URL. It is widely used and is a common practice implemented on various websites. There are reasons why the website owner and the developer might want to do this, from maintaining the website, updating and improving the website structure and the performance, or letting the users to use the different language version based on their location.

While there are numerous ways to do this, not doing it correctly may leave a great security hole on a website. Many factors may contribute to this, from the developer being unaware regarding this issue or a limited deadline, forcing the developers to deliver their tasks at hand without proper testing.

What is open redirection vulnerability?

Known as an open URL redirection vulnerability, this is a web application security flaw that allows an attacker to redirect a user from a legitimate website to another one by their choice. The URL redirection occurs when a web application takes a parameter from the user and uses it for the redirect.

Without proper filtering and validation, the users may deliberately change the destination URL to any web page by choice. In this way, the attackers can exploit this and redirect users to malicious sites owned or created by attackers.

Why is it important?

One of the most common reasons the attackers do this is to steal the user credentials and personal information.

Let’s take a look at the URL below.

https://example.com/login?redirect_to=https://auth.google.com/

So what’s wrong with the URL? If we take a closer look, the website will redirect the user to let the user login using a third-party website. Without proper validation or restrictions, anyone can change the destination URL address above. From the attacker’s point of view, this vulnerability will be very easy to find and manipulate.

How does open redirection vulnerability work?

Look again at the sample website above. The value of the “redirect_to” parameter can be replaced with the attacker’s phishing site such as https://evil.com/. Attackers can send the modified link to the potential victims so they would see something like this.

https://example.com/login?redirect_to=https://evil.com/

By using social engineering techniques, the attacker will try to convince the victim to open the website above by disguising it as a legitimate website. The attacker will take full control of the destination website so that it can do anything that the attacker wants it to, from distributing malware or stealing user credentials.

Although the method above may be enough to trick some people, others may be aware of this and wonder, isn’t that obvious? Well, how about this one

https://examples.com/login%3Fredirect_to%3Dhttps%3A%2F%2Fexamples.com%2F

Here, the attacker tries to replace the domain name with a name that is very similar to the target domain, namely https://examples.com which is also owned by the attacker. Additionally, the URL is encoded in order to obfuscate the real URL.

Only by changing and encoding the domain name, the victim will be made unaware of this. Even further, if the redirected website is designed in a similar fashion as the original website does, it is more likely that almost everyone would fall for it.

Chaining with SSRF vulnerability

Fundamentally, the open redirection vulnerability is exploiting the URL parameters, which is also common in the SSRF (Server Side Request Forgery) type of attack. With this kind of attack, the attacker targets the back-end server (resources server) and modifies the requests that are originally made by the website to the resources server via the API. Many modern websites, especially those based on microservices architecture, automate these processes using webhooks.

Sometimes, it may require users input for functions or methods in order to be executed. Such websites will heavily rely on webhooks to make HTTP requests to different resources in accordance to specific business domains (or any other factors the company wants it to). In this way, a website may have tons of separate servers.

A redirection URL shown above is only an example of a user entering the input to make a request to the server. In fact, SSRF can also be done by exploiting other parameters such as login request form and product search feature. Thus, the attacker will make requests to the server by intercepting and modifying the request before the request is sent from the target website to the back-end server.

How does SSRF work?

Things can go wrong real fast if the attacker can access another backend system that is supposedly inaccessible by the users. Let’s take a look at the example below.

https://example.com/login?redirect_to=https://example.com:8080/authorized/

As opposed to the previous example above that depends on a third-party website, this example redirects the user to its own backend server. By simply modifying the request, the attacker may have gained access to the back-end system.

https://example.com/login?redirect_to=http://localhost/admin/

In this case, if the attacker is trying to use the URL normally by simply copy-pasting this destination URL to the attacker’s browser, it will return nothing as it is only running on the server local machine. But, if the attackers do this, the access control is likely to be bypassed.

Though some applications may also block input to access 127.0.0.1 or localhost due to some implemented filters, access may still be possible by changing this to a specific IP address in order to bypass the URL filter. The attacker may have access to another backend server within the same network by changing this to a particular host within the same network like this.

https://example.com/login?redirect_to=http://192.168.0.23/admin/

To modify the request, the attacker may simply use the browser, and modify the parameter right from the developer tools to extract the information from the server database. The web browser like Firefox is powerful enough to do this manually as it supports request modification as one of its features.

Preventing open redirection vulnerabilities

As a user, we can’t really do much about it. But, as an owner and website developer, applying validation and sanitizing to any user input is critical to address and mitigate the issue. Alternatively, some other approaches may also be taken, such as

1. Simply not using redirects and forward.
2. Ensure that the user cannot enter the destination URL address.
3. Using server side validation and handling the redirection from server-side.
4. If unavoidable, validate the user input value and let only the authorized user to do so.
5. Whitelist only the intended redirection target and block the rest.
6. Display the location of the redirection target to the body of the website, so the users can see it and let them decide to continue or not.

Conclusion

The consequence of an open redirection vulnerability can be severe and can be used to carry out any fraudulent activities from identity theft to unauthorized transactions. To prevent this, some action needs to be done, from input sanitization and validation, server-side redirection, and vulnerabilities testing. In addition, staying up-to-date to the latest best practices and regular monitoring of the website can also be helpful in order to mitigate the risk of attack.