Search Go hack yourself with Detectify

An EASM blog from Detectify

The real impact of an Open Redirect vulnerability

detectify / May 16, 2019

Detectify is building web app security solutions that are automated and crowd-based. By collaborating with ethical hackers, business critical security research is put into the hands of those who need it most. This includes actual hacker payloads that are normally used to exploit vulnerabilities like open redirect, into something more. Let’s go into how open redirect can be escalated into something more:

What an open redirect vulnerability is

The simplest explanation is that the page takes a value and then creates a redirect to it. If /red.php?url= created a redirect to 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.

image: Detectify Deep Scan web application security scanner detects open redirects using request/response testing. 

Different kinds of Open Redirects

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 Open Redirect becomes an issue

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.

Detectify Research team:
“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.”

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:


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

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

which causes a redirect to

which in turn causes a redirect to

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 is accepted, so is, 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.


We have written about SSRF here before:

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.

details on open redirect in detectify UIimage: If an open redirect is detected, you’ll get to see the request sent by the Detectify scanning engines.

How Detectify can help

Detectify has an ability to test web applications for open redirect vulnerabilities and other wildly exploited known web vulnerabilities including the OWASP Top 10 and more. Check your web applications using Detectify by starting your 14-day free trial today.

Check your website for the latest vulnerabilities with Detectify Run a scan now