Unvalidated Redirects Vulnerability

Open Redirection

The Open Redirection vulnerability occurs when the website can allow an attacker to inject the malicious URL into the user input parameter. Sometimes, a phishing attack can be combined with a redirect. This is done to deceive users into thinking that they are entering their information on a trusted website, but in reality, their information is being sent to a harmful site.

Open Redirects Work

Many web applications intentionally redirect users to other sites by placing a destination URL as a parameter in an original URL.
Some applications utilize parameters to direct users to various destination URLs. For instance, the website www.xyz.com redirects users to www.abc.com using the following URL

<https://www.abc.com/?redirect_to=https://www.xyz.com>

Upon analyzing the URL provided, it was noticed that the ABC website receives a GET HTTP request and utilizes the redirect_to parameter to direct to the specified XYZ target website. Once the redirection is completed, the ABC web application server will display a status code indicating whether the redirection was successful. The possible status codes are 301, 303, 307, or 308.

The response from the application included a Location header, which indicates where the GET request should be redirected to.

Location: http://xyz.com

Attackers Manipulate URL

The redirect_to parameter in the above URL provided enables the Application to smoothly redirect to a designated target. It is crucial to note that the "redirect_to" parameter in the URL can be modified by the attacker to direct users to a harmful URL.

<https://www.abc.com/?redirect_to=https://www.attacker.com>

If the www.abc.com isn’t validated the input parameter “redirect_to” then it will lead to redirect the user to the given attacker.com website and the attacker can perform various attacks on the web application

Vulnerable parameters:

Most applications implement different parameters to redirect the application to specific websites. Here are some examples of the parameters.

redirect

<https://example.com/login?redirect=http://malicious-site.com>

next

<https://example.com/auth?next=http://attacker.com>

target

<https://example.com/checkout?target=http://attacker.com>

return_url

<https://example.com/reset-password?return_url=http://attacker.com>

destination

<https://example.com/redirect?destination=http://attacker.com>

url

<https://example.com/external?url=http://attacker.com>

link

<https://example.com/redirect?link=http://attacker.com>

r

<https://example.com/verify?r=http://attacker.com>

forward

<https://example.com/action?forward=http://attacker.com>

Note: You can perform a penetration test on every parameter used for redirection on the target's specific website.

Bypass for Open Redirect

The Bypass is based on the application response, sometimes applications validate the HTTP protocols. To bypass the filter protocols we can use (//) dabble slash. Also, we can try with the (\\).

<https://example.com/action?forward=//attacker.com>

Even if the domain name is verified by the application, it can still be manipulated. For example

<https://example.com/action?forward=//abc.attacker.com>

To bypass a filter that checks solely for a domain name, simply add a query or question mark "?".

<https://example.com/action?forward=//abc.com?attacker.com>

Note: You can experiment with different approaches based on how the application responds.

Vulnerability caused by an open redirect.

Phishing Attacks 

Attackers often create fraudulent URLs that imitate the appearance of popular websites or services. These URLs are designed to trick users into clicking on them, which leads to a redirection to phishing sites. These sites are specifically designed to steal sensitive information such as financial data, usernames, and passwords. It's important to be vigilant and cautious when navigating the internet to avoid falling into these traps.

Malware Distribution

Attackers may exploit open redirects to direct users to hazardous websites that can start the downloading of malware onto their devices. This malicious software can subsequently be utilized to pilfer data or carry out other malicious activities.

Cross-Site Scripting (XSS) Attacks

An attacker could insert malicious scripts into the redirect parameter, which would then be executed when the user arrived at the redirected page, allowing the attacker to steal cookies or perform actions on the user's behalf. 

The most common payload to check for Cross-site scripting (XSS) via Open redirect.

javascript:alert(1)

%09Jav%09ascript:alert(document.domain)

javascript://%250Alert(document.location=document.cookie) 

/%09/javascript:alert(1);

Note: Remember to test the application behaviour before injecting payloads. Sometimes, base64 or URL-encoded loads may work on the application, so craft the payload according to the application's understanding.

Mitigation

• The application should use relative URLs in all its redirects, and the redirection function should strictly validate that the URL received is a relative URL.
  
  
• Maintain a list of permitted redirect URLs on the server side and pass an index instead of the target URL parameter.
  
  
• The application should use a fixed redirect instead of redirecting parameters. For example, if a user clicks on a page like "profile," the application should directly show the profile page without using any redirect parameters.

     res.redirect('/profile');

Happy Hacking…