OWASP TOP 10 2013: Unvalidated Redirects and Forwards – 10 minute mail

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 Disposable mail can help

We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Disposable mail 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:

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

Disposable mail
Open Redirect Remediation Tips

 

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Newly Added Security Tests, February 15, 2017: MongoDB – 10 minute mail

Security never stands still, which is why we update our service on a regular basis to help you keep up with the latest vulnerabilities. We are constantly working on updating and improving our modules, but you can find some highlights from this week’s update below:

  • MongoDB operation injection module
  • WordPress github-btn XSS
  • HelpJuice XSS
  • Express (serve static) open redirect

Happy scanning!
The Disposable mail Team

 

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

The real impact of an Open Redirect vulnerability – 10 minute mail

The simplest explanation is that the page takes a value and then creates a redirect to it. If /red.php?url=https://example.com created a redirect to https://example.com that would be a typical Open Redirect-vulnerability.

This is called Unvalidated Redirects and Forwards by OWASP and could of course occur by less obvious reasons as well. Maybe you are only supposed to be able to redirect to a specific domain but is there a bypass of the filter? Maybe the value is not coming from a URL-parameter at all, but something totally different.

We have described this vulnerability type before, while this article will go into how an Open Redirect vulnerability can be exploited.

Header based

Header-based being a location-header sent from the server. The benefit with this, for an attacker’s perspective, is that the redirect always works even if Javascript is not interpreted. A server side function that gets a URL as input will follow the redirect and end up somewhere else.

Javascript based

When the redirect instead happens in Javascript it only works in scenarios where Javascript is actually executed. It might not work for server-side functions, but it will work in the victim’s web browser.

If the redirect happens in Javascript it might also be possible to cause a redirect to javascript:something(), which would be an XSS in itself.

When explaining the impact of an open redirect it is common to default to phishing or similar attacks. The question whether it actually is a problem or not to use open redirect for phishing is a debatable question. If receive a link which then redirects you to a sketchy site, how much more trustworthy is that compared to receiving a link to the sketchy site directly?

While some companies do consider this a legitimate risk, others do not.

Some members of the security community argue that the redirectors aid phishing, because users may be inclined to trust the mouse hover tooltip on a link and then fail to examine the address bar once the navigation takes place.

Our take on this is that tooltips are not a reliable security indicator, and can be tampered with in many ways; so, we invest in technologies to detect and alert users about phishing and abuse, but we generally hold that a small number of properly monitored redirectors offers fairly clear benefits and poses very little practical risk.https://sites.google.com/site/bughunteruniversity/nonvuln/open-redirect

However, phishing is not really all an open redirect can be good for. Open Redirect is often quickly dismissed because phishing is the first thing you come to think about, without considering what it could actually be combined with.

Instead, an open redirect often allows other vulnerabilities to be exploited, or chained to increase the impact. A list of a few of the things an open redirect vulnerability can be used for follows below. It is far from a comprehensive list, but could act as an example of what is possible:

Oauth

When you want to allow users to sign-up with external services, such as putting up a “Login with Facebook” or “Sign up with Google”-button you may choose to implement an Oauth-flow.

The basic principle is a link going to facebook.com/oauth.php?clientid=123&state=abc&redirect_uri=https://yourdomain.com/oauth. When the user clicks this link they are going to Facebook where they login and accept the permissions your app requires, and then redirected back to https://yourdomain.com/oauth?code=xyz.

Now your application can take the value of code and by using that getting partial access to the user’s Facebook account, all according to what permissions it has been given you on the login screen. The attacker can also re-use the value of the code parameter to login to the application with the victim’s Facebook account.

If an attacker would change the redirect_uri to https://attacker.com/oauth the request would be denied directly, as it is an external domain. However, if the attacker would find an open redirect on the accepted domain, it might be possible to combine those.

facebook.com/oauth.php?clientid=123&state=abc&redirect_url=https://yourdomain.com/red.php?url%3dhttps://attacker.com/

which causes a redirect to

https://yourdomain.com/red.php?url=https://attacker.com/?code=xyz

which in turn causes a redirect to

https://attacker.com/?code=xyz

and now the attacker are able to access the Facebook account on the application’s behalf.

(If it is not possible to keep the code-parameter in the URL when redirecting, it might be leaked in the referrer header in the last request)

Facebook prevents this attack by requiring the redirect_uri to match a pre-configured URL. However, many other services do not, where this is still a potential issue.

Sometimes this gets a bit complicated, such as Github’s oauth flow accepts any subdomain, so if x.com/auth is accepted, so is y.x.com/auth, even though this behaviour is not mentioned anywhere in the documentation. This means that an open redirect on any of your subdomains would lead to an account takeover.

SSRF

We have written about SSRF here before: https://blog.detectify.com/2019/01/10/what-is-server-side-request-forgery-ssrf/

Open redirect is something that is often used to bypass filters used here. Imagine that you have a service that are allowed to access content from a specific domain, but that domain could redirect anywhere. Then an attacker can enter the allowed server, and from there go anywhere.

XSS-Auditor bypass

Google Chrome has a built-in XSS-auditor which sometimes prevents a XSS-attack from working. However, it does not prevent an inclusion of scripts hosted at the same domain, so together with an open redirect you can bypass the XSS-auditor like this:

There are some limitations though, such as that the URL cannot contain an equal sign.

Referrer check bypass

One way of protecting against CSRF is to check the referrer header to confirm that the request originated from the website itself.

However, with an open redirect it might be possible to trick this by running the CSRF-attack against the open redirect that in turn redirects to the correct page. It will look like the CSRF originated from the open redirect-page, which are hosted on the same domain and is allowed to do such requests.

 

So in conclusion, when you report or create a finding for an open redirect, it is generally not for the impact of the open redirect in itself, but rather for what it can be combined with. Thus, fixing an open redirect prevents the vulnerability from being exploited at an earlier stage.

How Disposable mail can help

Disposable mail has an ability to test web applications for open redirect vulnerabilities and 1000+ known web vulnerabilities including the OWASP Top 10 and more. Check your web applications using Disposable mail by starting your 14-day free trial today.

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.