[This is a guest diary submitted by Jan Kopriva. Jan is working for Alef Nula (http://www.alef.com) and you can follow him on Twitter at @jk0pr]

Open (or unvalidated) redirects[1] are a family of web application vulnerabilities caused by missing or insufficient validation of input used to specify URL to which a browser is to be redirected. Although, from a technical standpoint, their principles are quite simple and they are usually nowhere near as dangerous as XSS or SQLi vulnerabilities, under specific circumstances they can pose severe risks. This is well illustrated by the fact that “Unvalidated Redirects and Forwards” were part of the OWASP Top 10 List in its 2013 iteration.

Pages, which redirect visiting browsers to different URLs based on an input passed to them, have a legitimate use in web applications. Historically, they have often been used for marketing purposes (monitoring clickthroughs in e-mail campaigns and on websites) or for returning a browser to the same page, it was on before user logged into an application. LinkedIn, for example, makes use of this technique if you try to log in while viewing someone’s profile. In such a case, the page, to which your browser will be redirected after you log in, is specified by the value of session_redirect parameter.

As you may see, redirection mechanisms can be quite useful. A problem arises, however, when these mechanisms lack any limits on the URLs to which they may redirect a browser (i.e. the redirect is “open”). For marketing loggers, redirection to any domain passed to them might be an intentional feature. On the other hand, if an open redirect is present on the website of a bank or a similar trusted business it can be quite dangerous.

Imagine if a website of a bank used the URL https://www.bank.tld/redirect?to=https://ebanking.bank.tld to redirect users to its e-banking portal. If the redirect was “open”, a threat actor could craft a link which would point to the legitimate site of the bank, but – when accessed – would redirect the browser to a fraudulent website. (e.g. https://www.bank.tld/redirect?to=https://ebanking.fakebank.tld). A phishing campaign utilizing such a link could be quite successful. That is the main reason why a redirect mechanism should – at least in most cases – include a whitelist of permissible target domains (or another relevant filtering mechanism) and redirect only to those sites, which are considered safe.

Unfortunately, as we found out during recent research into open redirect vulnerabilities, even though they are usually easy to find and fix (and it isn’t difficult to avoid introducing them into an application in the first place), they are quite prevalent on the web. We managed to find them on more than a hundred sites in the CZ top-level domain alone – including on websites of a couple of banks and other “trusted” organizations – just by using a few well-chosen Google dorks. Breakdown of affected sites may be seen in the following chart.

It should be mentioned that although we didn’t spend much time looking outside the .cz TLD, the situation seems to be the same in other TLDs as well – open redirects are pretty common, even on high-profile sites.

A more in-depth discussion of the results of our research was part of my talk at SANS Pen Test Hackfest Summit in Berlin in July. If you didn’t have a chance to join us there but would like to learn more, you may take a look at the slides in the SANS Summit Archives at https://www.sans.org/cyber-security-summit/archives/pen-testing. The slides cover a “half-open” redirect vulnerability in Youtube (see https://untrustednetwork.net/en/2019/07/22/half-open-redirect-vulnerability-in-youtube/) and a couple of other topics as well.
If you’re not interested in the results but would like to check whether your own web applications have any obvious open redirect vulnerabilities, I can at least share with you couple of the simple Google dorks, which might be able to help you. As the targets for a redirect are usually determined by an HTTP GET parameter and as the purpose of most such parameters is identical, their names tend to be similar as well. Good Google dorks to assist you in finding open redirects in your domains might therefore be:

site:domain.tld inurl:redir
site:domain.tld inurl:redirect
site:domain.tld inurl:redirect_to
site:domain.tld inurl:newurl
site:domain.tld inurl:targeturl
site:domain.tld inurl:link
site:domain.tld inurl:url

[1] https://cwe.mitre.org/data/definitions/601.html