OWASP TOP 10: Unvalidated Redirects and Forwards (#10)

OWASP is a non-profit organization with the goal of improving the security of software and the internet. They have put together a list of the ten most common vulnerabilities, which we will cover one by one in this blog series. This is the tenthpost and the rest can be found by clickinghere.

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 redirect wasranked as uncommon both in 2010 and 2013 when OWASP graded vulnerabilities in their top ten list.

However, even if the prevalenceof 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 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, Open Redirect is very easy to exploit, which increases the likelihood of someone finding the vulnerability 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 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. 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 a / . An attacker could easily bypass that by just using // instead of https://.

Read more OWASP

Top 10 2013: Unvalidated Redirects and Forwards

Unvalidated Redirects and Forwards Cheat Sheet

Detectify

Open Redirect Remediation Tips