What is an open redirect vulnerability and how to prevent it?

01 december 2021 om 10:00 by ParTech Media - Post a comment

We are living in a world where attacks are getting more and more sophisticated. Hackers are able to steal sensitive data at the drop of a hat. We, on the other hand, are unaware of what is really going on.

One such super-sophisticated attack is the open redirect vulnerability attack. In this, the user is neither aware when the attack was initiated nor when their data was completely stolen.

In this post, we will understand more about open redirect vulnerability, including its types and examples.

Table of Contents

  1. What is an open redirect vulnerability?
  2. Example of open redirect vulnerability
  3. Types of open redirect vulnerability
  4. Prevention of open redirect vulnerability
  5. Wrapping Up

What is an open redirect vulnerability?

Simply put, open redirect vulnerability is a website security issue that allows attackers to take advantage of the vulnerabilities in your official business websites. When an open redirect vulnerability is not resolved in your website, the attacker can send the victim a phishing mail with your business domain name and redirect the user to another malicious URL.

Here, the user fails to notice that the parameters of the malicious URL have been manipulated by the attacker with the intention of redirecting the user to a new website that looks the same as the original. Now the fake website may prompt the user to enter the credentials like the real one. Once the user enters their credentials and submits, they will be redirected to the previous genuine website, as though nothing happened.

Here are the consequences of an open redirect vulnerability -

  1. Phishing attacks: Such attacks will be carried out by steering the user from the vulnerable site to the phishing site.
  2. Cross-site scripting attacks: This type of attack will be carried out if your website lacks iframe content security policies. Also, if the client supports such protocols when redirecting, the attacker can leverage it to perform an XSS attack.
  3. Server-Side Request Forgery: Open redirects allow attackers to perform SSRF and send well-crafted messages from the backend server so that the users won't question the authenticity of the message.
  4. CSP: If your website is using CSP to protect from XSS attacks and even if one whitelisted domain has an open redirect, attackers use it to instantiate a phishing attack.

Example of open redirect vulnerability

https://yourbusinessurl.com/redirect.php?redirecturl=http://attacker.com/phish/

Observe the above URL, especially the parameters sandwiched between the official genuine URL address. It has been smartly changed to redirect the user to the website framed by the attacker.

The probability of clicking the above link is high since the URL ‘yourbusinessurl.com’ creates an air of genuineness to your users and makes them take action.

Another URL scheme that is handy to the attackers is data: attribute in URLs. Although it cannot be manipulated in Webkit-based browsers such as Chrome and Opera, browsers like Mozilla Firefox allow the manipulation of this data: attributes. Attackers can easily get hold of this open redirect vulnerability to create phishing websites without needing web servers to host them.

Types of open redirect vulnerabilities

There are two types of open redirect vulnerabilities -

Header-based open redirect vulnerability

An HTTP location header is a very important component of a website as it asks a browser to redirect to the specified URL and provides the location of the resource that was created recently. However, it is JavaScript independent and attackers use this header to redirect users to a malicious website. The issue is - unless the user examines the URL they won't see any strange additions to the URL which may cost them their precious data.

Javascript-based open redirect vulnerability

In this, server-side code takes care of sending requests and displaying the right information to the user. Attackers exploit this JavaScript-based open redirect vulnerability hijacking cookie sessions and initiate their phishing attacks to get hold of the user’s credentials.

Prevention of open redirect vulnerability

There are a handful of methods to avoid open redirects -

  1. Force redirects to go to a page notifying the users that it is redirecting out of the website. It should clearly display a message and a button that needs to be clicked by users to confirm that they are okay to be redirected to another location.
  2. Do not allow URL as user input value in your website. If it is absolutely necessary to use URL as an input value, accept the short name, token, or ID that will be mapped to the target URL. This method is much more effective in avoiding attacks that tamper with the URLs.
  3. Disallow offsite redirects. A classic example of an offsite redirect is when the payment page redirects the customer to a third-party payment service provider website for the checkout process. This may allow attackers to interfere with the URL and modify them.
  4. Use a black box security solution that tests your web application, API, and web socket to find any open redirect vulnerabilities.
  5. It is important to check the referrer value while managing redirects. Redirects to URL passed in query parameters must be triggered by pages in your site. Any other suspicious sites triggering a redirect should be taken care of.
  6. Also, make sure that all the redirected URLs are relative paths, starting with a single / character. Also, it is important to note that redirect URLs starting with // characters are considered protocol-agnostic by the browser and the use of such characters should be avoided.

Wrapping Up

In this post, you have seen how harmful an open redirect vulnerability can be and why it is so important to prevent it. The easiest and the most effective way to prevent it is by not letting your user have control of where the page redirects them to. It is only necessary to provide users the authority to enter short keywords and map them to the target URL or simply allow them to confirm before being redirected to the destination.

Nieuwste