Open Redirect Vulnerability

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.

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.

2. 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.

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.

• Cross-site Scripting (XSS)

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.

• Phishing 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.

• Server-Side Request Forgery

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