Which of the following are the best ways to prevent unvalidated redirect and forwards vulnerabilities?

Unvalidated redirects and forwards, also referred to as Open Redirect, is featured on OWASP‘s list of the ten most common vulnerabilities. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their Top 10 list one by one in our OWASP Top 10 blog series. 

Description

Unvalidated redirect vulnerabilities occur when an attacker is able to redirect a user to an untrusted site when the user visits a link located on a trusted website. This vulnerability is also often called Open Redirect.

Prevalence

Unvalidated redirects and forwards were ranked as uncommon both in 2010 and 2013 when OWASP graded vulnerabilities in their top ten list.

However, even if the prevalence of this vulnerability is considered low in general over the internet, one could not look at the resources or popularity a site has to determine if it is likely to be vulnerable. One of the companies that do not classify this as a vulnerability is Google, while Facebook, for example, does. It would therefore not be strange to find an unvalidated redirect on Google’s domain, while Facebook would pay a bug bounty for the same thing on their domain.

Potential impact

The potential danger of Unvalidated Redirects and Forwards is not to be considered as that serious. The most common use case are phishing attacks or others that also involve Social Engineering, which lowers the potential impact of the vulnerability.

It also happens that this is part of an chained attack, where it is only one in a chain of multiple vulnerabilities used. This type of attack is more advanced and therefore not as common.

Exploitability

In most cases, this vulnerability is very easy to exploit, which increases the likelihood of someone finding and abusing it.

There have, of course, been cases where it has been much harder to exploit, but as the impact is not that great, the time used to look for the vulnerability is limited. This means it is mainly the easier cases of Unvalidated Redirects and Forwards that are discovered and exploited.

Well-known events

There have not been any public attacks where this vulnerability has played a great part. It is possible that something like that has happened in the past, but as most serious uses of this vulnerability involve social engineering, companies are rarely that generous with reporting attacks.

How to discover Unvalidated Redirects and Forwards

  • Look at the code for every place that utilizes a redirect. If there is no kind of whitelist for the URL being redirected, the site is probably vulnerable.
  • Crawl the site and save all pages that generate a redirect. If a parameter is changed, is the URL redirected to that as well? Again, if no whitelist seems to be implemented here the site is most likely vulnerable.
  • Manually looking around and investigating all parameters that can be suspected to have something to do with redirects may feel like a waste of time, but can actually generate better results than one might expect.

How Detectify can help

We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Detectify is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 700 vulnerabilities, including OWASP Top 10, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable » 

Code example of vulnerable application

Let us assume there is a file (router.php) on the website responsible for internal redirects. A normal request would look something like this:

https://example.com/router.php?url=forum.php

The code for that script is the following:

<?php header(“Location: “.$_GET[“url”); die(); ?>

However, as there are no checks whether the URL really is internal or external an attacker would be able to conduct a URL like this as well:

https://example.com/router.php?url=https://phishing.com

Remediation

There are a few possible ways to remediate this issue.

  • Try to avoid redirects altogether. In most cases, they are not needed.
  • If a redirect is necessary, do not trust user input for its destination.
  • Map the destination input to a value that the server then translates to the original value before doing the redirect. This prevents the attacker from changing it.
  • Have a whitelist of URLs – this can be done with regex if necessary. Be careful with this as it is easy to make mistakes without realizing.

If none of the above is possible, force all redirects to a page where the user will have to click a button to confirm they are leaving the trusted site.

One common, but insufficient, remediation method is ensuring that the URL starts with:

/

An attacker could easily bypass that by just using

//

instead of:

https://

Watch the video:

Read more

OWASP
Top 10 2013: Unvalidated Redirects and Forwards
Unvalidated Redirects and Forwards Cheat Sheet

Detectify
Open Redirect Remediation Tips

Which of the following strategy is appropriate for mitigating an unvalidated redirect vulnerability?

Simply avoid using redirects and forwards. If used, do not allow the URL as user input for the destination. Where possible, have the user provide short name, ID or token which is mapped server-side to a full target URL. This provides the highest degree of protection against the attack tampering with the URL.

Which vulnerability is classified as unvalidated forward?

Unvalidated Redirects and Forward Vulnerability, also sometimes referred to as URL Redirection Vulnerability, is a type of bug found in the Web Application. In this type of vulnerability, the attacker uses to manipulate the URL and sends it to the victim.

Which is most likely to result from invalidated redirects and forwards?

If you allow unvalidated redirects and forwards, your website or web application will most probably be used in phishing scams.

Which of the following are the best ways to prevent malicious input exploiting your application?

Other Measures.
Updates are crucial; never ignore them..
Never allow unsanitized, unvalidated user inputs or inputs from untrusted sources..
Use parameterized queries to prevent SQLi attacks..
Secure coding practices and application development..
Leverage CDN so that users do not have direct access to the server..