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 article will go into how Open Redirect can be exploited.
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:
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.
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 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.
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.
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 Detectify can help
Detectify 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 Detectify by starting your 14-day free trial today.