One of the most common and yet overlooked vulnerabilities by web developers is Open Redirect (also known as “Unverified redirects and forwards”). A website is considered vulnerable to Open Redirect if the parameter values (the portion of the URL after the “?”) In the HTTP GET request redirects the user to a new site without validating the target site. Depending on the architecture of the vulnerable site, redirection can occur after certain actions, such as logging in, and sometimes it can happen instantly on page load.
An example of a vulnerable link looks something like this: www.example.com/login.html?RelayState=http%3A%2F%2Fexample.com%2Fnext
In this example, the parameter “RelayState” indicates where to redirect the user after a successful login (in our example, this is example.com/next). If the site does not check the parameter value “RelayState” for legitimacy and security, then the attacker can use this parameter to redirect the victim to a fake page created by the attacker himself: www.example.com/login.html?RelayState=http%3A%2F%2FEvilWebsite.com
Vulnerabilities such as Open Redirect have been neglected by developers, since they do not directly damage the site and do not give an attacker the ability to directly steal company data. However, this does not mean that Open Redirect is not a threat. One of the main uses of this type of attack is to conduct effective and reliable phishing attacks.
When a phishing attack uses Open Redirect, a victim may receive a plausible-looking email with a link that points to a correct and familiar domain to the victim. What the victim might not notice is that there are parameters in the middle of the URL that change the redirect endpoint. To complicate the detection of Open Redirect, a redirect can occur after the victim enters a username and password on a genuine site. The attackers discovered that an effective way to trick the victim is to redirect them to a fake site after entering their username and password on the real site. The fake site will look similar to the real site and will ask the victim to re-enter the password. After the victim has done this, the password will be written down by the attacker, and the victim will be redirected back to the real site. If everything is done correctly, the victim will think that they made a mistake with the password the first time and will not notice that their username and password were stolen.
Phishing is used in most successful targeted hacks as well as regularly in opportunistic attacks. Considering how common phishing is in everyday life, vulnerabilities like Open Redirect shouldn’t be dismissed either.
It would be unfair to single out a particular site or company as vulnerable to Open Redirect, because this vulnerability is common. Instead, it would be helpful to show how many such sites there are and how easy it is to find them.
Doing a web search is one of the best ways to find Open Redirect on your own site and elsewhere on the internet in general.
Google’s search engine gives you the flexibility to write search queries, including queries that specifically search for page URLs.
The following operators and special characters will allow any user to create tagged queries that can help detect Open Redirect:
allinurlIs the operator who tells Google to search the URL for all specified keywords. For example:
allinurl:ReturnUrlwill search for all web pages that have a ReturnUrl part in their URL.
site– an operator who says to return only those results that are on a specific domain or website. Example:
site:example.comwhich searches web pages by
""– double quotes are special characters that are used to indicate to search for an exact combination of words and characters within quotes.
*– an asterisk is a wildcard character that represents one or more words.
Using them allows you to find signs of a potential Open Redirect:
We can search simultaneously for the presence of tokens “Http” and “Https” in the parameters of the GET request. For example:
allinurl:%3Dhttps* allinurl:%253Dhttps* allinurl:%3Dhttp* allinurl:%253Dhttp*
We can also search for specific general words related to redirection in the GET request parameters area. For example:
=https" allinurl:" =http" allinurl: =https allinurl: =http allinurl: %3Dhttps allinurl: %3Dhttps* allinurl: %253Dhttps allinurl: %253Dhttps* allinurl: %3Dhttp allinurl: %3Dhttp* allinurl: %253Dhttp allinurl: %253Dhttp* allinurl:
, we will use one of the following redirect-specific words: RelayState, ReturnUrl, RedirectUri, Return, Return_url, Redirect, Redirect_uri, Redirect_url, RedirectUrl, Forward, Forward_url, SuccessUrl, Redir, Exit_url, Destination... This is not a complete list of keywords. You can find more by analyzing the results of the more general URL lookup queries in the GET Request Parameters section.
For targeted searches, you can add
at the end of your Google searches. This method can help you find Open Redirect vulnerabilities on your own site.
With such a simple search, you can find dozens of Open Redirect vulnerabilities within minutes. The list of vulnerable sites includes sites of banks, international corporations, trusted companies, favorite projects, and numerous sites of small organizations. As an added bonus, every time a Google crawler stumbles upon sites from Open Redirect, we will receive updated results using queries.
The best way to avoid the Open Redirect vulnerability is to avoid user-specific or GET-request redirection. If a redirect is unavoidable, it can be dealt with by validating the target site and clearing its reputation with a whitelist of validated URLs.
I would encourage you to tell your web developer friends about Open Redirect. You can forward this article to them, or even discover vulnerabilities using the method mentioned above and report it to the company with a detailed description of the problem. Let's make it harder for phishing attacks together!
If you'd like to share your Google searches that work for Open Redirect detection, you can do so in the comments.