4. Open Redirect Vulnerabilities
Description
An open redirect vulnerability occurs when a victim visits a particular URL for a given website and that website instructs the victim’s browser to visit a completely different URL, on a separate domain. For example, suppose Google had utilized the following URL to redirect users to Gmail:
https://www.google.com?redirect_to=https://www.gmail.com
Visiting this URL, Google would receive a GET HTTP request and use the redirect_to parameter’s value to determine where the visitor’s browser should be redirected. After doing so, Google would return a 302 HTTP response, instructing the user’s browser to to make a GET request to https://www.gmail.com, the redirect_to parameter’s value. Now, suppose we changed the original URL to:
https://www.google.com?redirect_to=https://www.attacker.com
If Google wasn’t validating that the redirect_to parameter was for one of their own legitimate sites where they intended to send visitors (https://www.gmail.com in our example), this could be vulnerable to an open redirect and return a HTTP response instructing the visitor’s browser to make a GET request to https://www.attacker.com.
The Open Web Application Security Project (OWASP), which is a community dedicated to application security that curates a list of the most critical security flaws in web applications, has listed this vulnerability in their 2013 Top Ten vulnerabilities list. Open redirects exploit the trust of a given domain, https://www.google.com/ in our example, to lure victims to a malicious website. This can be used in phishing attacks to trick users into believing they are submitting information to the trusted site, when their valuable information is actually going to a malicious site. This also enables attackers to distribute malware from the malicious site or steal OAuth tokens (a topic we cover in a later chapter).
When searching for these types of vulnerabilities, you’re looking for a GET request sent to the site you’re testing, with a parameter specifying a URL to redirect to.
Examples
1. Shopify Theme Install Open Redirect
Difficulty: Low
Url: app.shopify.com/services/google/themes/preview/supply–blue?domain_name=XX
Report Link: https://hackerone.com/reports/101962
Date Reported: November 25, 2015
Bounty Paid: $500
Description:
Our first example of an open redirect was found on Shopify, an e-commerce solution that allows users to set up an on-line store to sell goods. Shopify’s platform allows administrators to customize the look and feel of their stores and one of the ways to do that is by installing a new theme. As part of that functionality, Shopify previously provided a preview for the theme through URLs that included a redirect parameter. The redirect URL was similar to the following which I’ve modified for readability:
https://app.shopify.com/themes/preview/blue?domain_name=example.com/admin
Part of the URL to preview the theme included a domain_name parameter at the end of the URL to specify another URL to redirect to. Shopify wasn’t validating the redirect URL so the parameter value could be exploited to redirect a victim to http://example.com/admin where a malicious attacker could phish the user.
2. Shopify Login Open Redirect
Difficulty: Medium
Url: http://mystore.myshopify.com/account/login
Report Link: https://hackerone.com/reports/103772
Date Reported: December 6, 2015
Bounty Paid: $500
Description:
This open redirect is similar to the first Shopify example except here, Shopify’s parameter isn’t redirecting the user to the domain specified by the URL parameter, but instead tacks the parameter’s value onto the end of a Shopify sub-domain. Normally this would have been used to redirect a user to a specific page on a given store. After the user has logged into Shopify, Shopify uses the parameter checkout_url to redirect the user. For example, if a victim visited:
http://mystore.myshopify.com/account/login?checkout_url=.attacker.com
they would have been redirected to the URL:
http://mystore.myshopify.com.attacker.com
which actually isn’t a Shopify domain anymore because it ends in .attacker.com. DNS lookups use the right-most domain label, .attacker.com in this example. So when:
http://mystore.myshopify.com.attacker.com
is submitted for DNS lookup, it will match on attacker.com, which isn’t owned by Shopify, and not myshopify.com as Shopify would have intended.
Since Shopify was combining the store URL, in this case http://mystore.myshopify.com, with the checkout_url parameter, an attacker wouldn’t be able to send a victim anywhere freely. But the attacker could send a user to another domain as long as they ensured the redirect URL had the same sub-domain.
3. HackerOne Interstitial Redirect
Difficulty: Medium
Url: N/A
Report Link: https://hackerone.com/reports/111968
Date Reported: January 20, 2016
Bounty Paid: $500
Description:
An interstitial web page is one that is shown before expected content. Using one is a common method to protect against open redirect vulnerabilities since any time you’re redirecting a user to a URL, you can show an interstitial web page with a message explaining to the user they are leaving the domain they are on. This way, if the redirect page shows a fake log in or tries to pretend to be the trusted domain, the user will know that they are being redirected. This is the approach HackerOne takes when following most URLs off their site, for example, when following links in submitted reports. Although interstitial web pages are used to avoid redirect vulnerabilities, complications in the way sites interact with one another can still lead to compromised links.
HackerOne uses Zendesk, a customer service support ticketing system, for its support sub-domain. When hackerone.com was followed by /zendesk_session users would be lead from HackerOne’s platform to HackerOne’s Zendesk platform without an interstitial page because HackerOne trusted URLs containing the hackerone.com. Additionally, Zendesk allowed users to redirect to other Zendesk accounts via the parameter /redirect_to_account?state= without an interstitial.
So, with regards to this report, Mahmoud Jamal created an account on Zendesk with the subdomain, http://compayn.zendesk.com, and added the following Javascript code to the header file with the Zendesk theme editor which allows administrators to customize their Zendesk site’s look and feel:
<script>document.location.href = "http://evil.com";</script>
Here, Mahmoud is using JavaScript to instruct the browser to visit http://evil.com. While diving into JavaScript specifics is beyond the scope of this book, the <script> tag is used to denote code in HTML and document refers to the entire HTML document being returned by Zendesk, which is the information for the web page. The dots and names following document are its properties. Properties hold information and values that either are descriptive of the object they are properties of, or can be manipulated to change the object. So the location property can be used to control the web page displayed by your browser and the href sub-property (which is a property of the location) redirects the browser to the defined website. So, visiting the following link would redirect victims to Mahmoud’s Zendesk sub-domain, which would make the victim’s browser run Mahmoud’s script and redirect them to http://evil.com (note, the URL has been edited for readability):
https://hackerone.com/zendesk_session?return_to=https://support.hackerone.com/ping/redirect?state=compayn:/
Since the link includes the domain hackerone.com, the interstitial web page isn’t displayed and the user wouldn’t know the page they are visiting is unsafe. Now, interestingly, Mahmoud originally reported this redirect issue to Zendesk, but it was disregarded and not marked as a vulnerability. So, naturally, he kept digging to see how it could be exploited.
Summary
Open redirects allow a malicious attacker to redirect people unknowingly to a malicious website. Finding them, as these examples show, often requires keen observation. Redirect parameters are sometimes easy to spot with names like redirect_to=, domain_name=, checkout_url=, and so on. Whereas other times they may have less obvious names like r=, u=, and so on.
This type of vulnerability relies on an abuse of trust, where victims are tricked into visiting an attacker’s site thinking they will be visiting a site they recognize. When you spot likely vulnerable parameters, be sure to test them out thoroughly and add special characters, like a period, if some part of the URL is hard-coded.
Additionally, the HackerOne interstitial redirect shows the importance of recognizing the tools and services websites use while you hunt for vulnerabilities and how sometimes you have to be persistent and clearly demonstrate a vulnerability before it’s recognized and accepted for a bounty.