Why is this an issue?
Open redirection occurs when an application uses user-controllable data to build URLs used during redirects.
An attacker with malicious intent could manipulate a user to browse into a specially crafted URL, such as
https://trusted.example.com/redirect?url=evil.com, to redirect the victim to their evil domain.
Open redirection is most often used to trick users into browsing to a malicious domain that they believe is safe. As such, attackers commonly use
open redirect exploits in mass phishing campaigns.
What is the potential impact?
An attacker can use this vulnerability to redirect a user from a trusted domain to a malicious domain controlled by the attacker. At that point,
the attacker can perform various attacks, such as phishing.
Below are some scenarios that illustrate some impacts of an attacker exploiting the vulnerability.
Phishing
Suppose the attacker creates a malicious website that mirrors the interface of the trusted website. In that case, they can use the open redirect
vulnerability to lead the user to this malicious site.
Due to the similarity in the application appearance and the supposedly trustable hyperlink, the user fails to identify that they are browsing on a
malicious domain. From here, an attacker can capture the user’s credentials, bypass Multi-Factor Authentication (MFA), and take over the user’s
account on the trusted website.
Malware distribution
By leveraging the domain mirroring technique explained above, the attacker could also create a website that hosts malware. A user who is unaware of
the redirection from a trusted website to this malicious website might then download and execute the attacker’s malware. In the worst case, this can
lead to a complete system compromise for the user.
JavaScript injection (XSS)
In certain circumstances, an attacker can use DOM-based open redirection to execute JavaScript code. This can lead to further exploitation in the
trusted domain and has consequences such as the compromise of the user’s account.
How to fix it in DOM API
Code examples
The following noncompliant code example is vulnerable to open redirection as it constructs a URL with user-controllable data. This URL is then used
to redirect the user without being first validated. An attacker can leverage this to manipulate users into performing unwanted redirects.
Noncompliant code example
The following example is vulnerable to open redirection through the following URL:
https://example.com/redirect?url=https://evil.com;
const queryParams = new URLSearchParams(document.location.search);
const redirectUrl = queryParams.get("url");
document.location = redirectUrl; // Noncompliant
Compliant solution
const queryParams = new URLSearchParams(document.location.search);
const redirectUrl = queryParams.get("url");
if (redirectUrl.startsWith("https://www.example.com/")) {
document.location = redirectUrl;
}
How does this work?
Most client-side frameworks, such as Vue.js or React.js, provide built-in redirection methods. Those should be preferred
as they often provide additional security mechanisms. However, these built-in methods are usually engineered for internal page redirections. Thus,
they might not solve the reader’s use case.
In case the application strictly requires external redirections based on user-controllable data, the following should be done instead:
- Validating the
authority part of the URL against a statically defined value (see Pitfalls.)
- Using an allowlist approach in case the destination URLs are multiple but limited.
- Adding a dynamic confirmation dialog, warning about the imminent action and requiring manual authorization to proceed to the actual
redirection.
Pitfalls
The trap of String.startsWith and equivalents
When validating untrusted URLs by checking if they start with a trusted scheme and authority pair scheme://authority, ensure
that the validation string contains a path separator character (i.e., a /) as the last character.
When this character is not present, attackers may be able to register a specific domain name that both passes validation and is controlled by
them.
For example, when validating the https://example.com domain, suppose an attacker owns the https://example.evil domain. If
the prefix-based validation is implemented incorrectly, they could create a https://example.com.example.evil subdomain to abuse the
broken validation.
The practice of taking over domains that maliciously look like existing domains is widespread and is called cybersquatting.
Resources
Standards
