Privacy settings
We use cookies and similar technologies that are necessary to run the website. Additional cookies are only used with your consent. You can consent to our use of cookies by clicking on Agree. For more information on which data is collected and how it is shared with our partners please read our privacy and cookie policy: Cookie policy, Privacy policy
We use cookies to access, analyse and store information such as the characteristics of your device as well as certain personal data (IP addresses, navigation usage, geolocation data or unique identifiers). The processing of your data serves various purposes: Analytics cookies allow us to analyse our performance to offer you a better online experience and evaluate the efficiency of our campaigns. Personalisation cookies give you access to a customised experience of our website with usage-based offers and support. Finally, Advertising cookies are placed by third-party companies processing your data to create audiences lists to deliver targeted ads on social media and the internet. You may freely give, refuse or withdraw your consent at any time using the link provided at the bottom of each page.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Attacks, Vulnerabilities

Open Redirect Vulnerability

 Open Redirect Vulnerability

Introduction

In cyberspace, vulnerabilities exist in multiple types and forms and this is what makes them hard to track, test, and fix. For through-and-through API security, it’s crucial to have awareness of all the famous and unfamiliar threats. 

One such threat/vulnerability is Open redirect. Responsible for the execution of XSS payloads and phishing, this security loophole category of extensive web application vulnerability needs the undivided attention of AppSec security experts.

Learning Objectives

Definition of a Redirect

Redirect is the process that websites or web apps adopt to modify the URLs accessed by end-users through the site’s back-end. Forwarding clients' particular HTTP headers or using JavaScript are a few ways to attain it.

If unattended and unprotected, redirects are prone to redirect attacks. Knowledged malicious actors or attackers can exploit them and use them as a means to misguide the user/client/visitor. 

What is an Open Redirection

It is a redirect, generated by the client, which isn’t valid or filtered properly. Such redirects are unsafe and leave scope for attackers.

There are certain traits defining safe and unsafe redirect usage. For instance, encrypted websites redirecting clients only to a fixed URL is considered a safe practice while websites allowing clients to define or specific redirect destination is not considered safe. Such redirects are known as open redirects.

In addition, if a redirection uses user-defined parameters, it can also be called safe. But if the same redirect doesn’t feature filtered or validated inputs then it becomes unsafe as there is a possibility of an attacker inserting malicious content into the input.

Open redirection scheme
Open redirection scheme

To sum up, developers using dynamic redirects must consider them untrusted by default and enforce strong security measures. If that’s not happening, the threat attacker will have a chance to divert the redirect to a corrupted/risky site.

Speaking of its classification, Open Redirect OWASP Top 10 2013 list position was A10. Netsparker calls this threat of medium danger. 

Let’s understand the concept using an open redirect vulnerability example.

Say, you own a domain name test.com. To exploit users of your domain, a skilled threat actor can create a URL as mentioned below.

https://test.com/redirect.php?url=http://attacker.com 

This URL will be used for carrying out a phishing attack to give users an impression of authenticating the URL, as test.com is added in the beginning. 

If the website has open redirection issues, attackers will have no hassles in implementing this URL. 

Here is an example code depicting the same: 

$redirect = $_GET['url']; header("Location: " . $redirect);

The Types

  1. Header-Based

It can take place even if including JavaScript isn’t inferred. The threat actor uses HTTP Location Header, causing the problems, such as:

  • Redirection on visiting a link
  • being a response header, it may leak the location-related details of the newly generated resources.

As you can conclude from the above, if the user fails to spot any malicious content present in the URL, the results could be severe.

  1. JavaScript-Based

Adding the JS-based checks/validations instead of server-side restrictions to your pages makes your web pages more prone to redirect attacks because the attacker can always disable them from the client-side.

If a threat actor succeeds in carrying out the JS-based redirect, exploitation possibilities are endless. This is the cause why attackers utilizing open redirect phishing explore JavaScript and attack through it most of the time.

open redirects process
Open redirections process

Ways Open Redirections Coule be Taken in Use by Threat Actors

There could be multiple methods of exploitation through it, such as:

  • Sending the Victim to Risky/Malicious sites

It's a very common practice. What happened during the phishing scam is a part of this attack. The threat actorr generally uses an exploited browser or a CSRF attack prone page as its aid in this case.

When such content seems to be offered by a trusted resource, people fall into the trap. The most common example of an attack happening this way is a corrupted bank/financial service site redirecting visitors to a page featuring CSRF exploit.

Making use of an open redirect to XSS attack execution requires utilizing non-HTTP protocols. As their direct usage will get caught and blocked, threat actors use Javascript and DOM objects to carry out such an attack.

Verified/considerably-reliable websites featuring open redirect endpoints act as a platform for attackers to carry out phishing attacks. Using them, attackers will introduce malicious links on a trustworthy site or can forward phishing emails featuring a corrupt URL. Matching a lot with the original one, these e-mails will redirect the end-user to the wrong/risky URL.

As the attackers work heavily to disguise the authentic site and use encoded parameters that are extremely lengthy, recognising them could be tough many times. This is why phishing attacks succeed most of the time. It’s so strong that even the sites with well-established authentication flow are likely to be its victims.

It is used against internal entities and is only achievable when redirection takes place on the internal host. SSRF often gets paired with path traversal and when this happens, threat actors can gain internal access.

  • Token Theft Scenario

One not-to-forget use case of open directs is stealing user tokens. This possibility occurs in an SSO-based application featuring open redirection. Token theft attack lets attackers enter a system like verified users and use them to carry out session hijacking and many other attacks. 

Measures to prevent open redirects

Unverified user input processing is the main cause why open directs become available for exploitation. Here, the concerned input is URL query strings. To reduce the incidences and impact of this vulnerability, the below-mentioned preventive techniques work best.

  • Make sure user-driven or defined data is used in the least possible quantity within a URL. Whenever such data is used, proper sanitization should be done. For more details, we recommend referring to this Cheat Sheet by OWASP
  • Creating a whitelist of all the allowed redirect locations and redirecting other to a default URL is a good open redirect prevention methodology. 
  • One viable approach to deal with the vulnerability is creating a distinct ID for every redirect target. Doing so makes URLs free from user-controllable names.
  • API security experts also suggest choosing an appropriate referrer-policy header so that referrer URL exposure is limited and token leak risks are less than before. 
  • One must keep the use of forwards/redirects limited and completely secured. 
  • When accepting user-created URLs is crucial, it’s wise to ask for a short URL name or token. This attribute should be completely mapped out on the server-side.
  • Try Wallarm's cybersecurity products: API Security Platform, GoTestAPI
FAQ

Subscribe for the latest news