Open Redirect [CWE-601]

Open Redirect weakness describes improper sanitization of input that is used to redirect users to external websites.

Created: September 11, 2012
Latest Update: December 28, 2020

Table of Content

1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Exploitation Examples
6. Severity and CVSS Scoring
7. Mitigations
8. Common Fix Errors and Bypasses
9. References
10. Related Security Advisories

Want to have an in-depth understanding of all modern aspects of
Open Redirect [CWE-601]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

This weakness occurs where software uses an untrusted input to redirect visitors to an external website. The vulnerability can be introduced into application by a simple redirector script used by many content management systems for SEO purposes. If an attacker can influence the address of the website that user is redirected to and there are no additional checks or warnings within the application, it is possible to conduct phishing attacks.

The following example in PHP demonstrates the weakness:

The script accepts the "url" parameter and uses it to redirect users to another page. An attacker can replace the original value of the "url" parameter and redirect users, who follow this link, to an arbitrary webpage:
http://website.com/index.php?url=http://malicious.site.com

2. Potential impact

Open redirect weaknesses are used to make user believe that the supplied link leads to a trusted website. They can lend credibility to phishing attacks, by using the vulnerable legitimate site as a trusted URL, in order to fool the victim. The victim may receive a phishing email that contains a link (disguised URL, such as using a URL shortening service) to a malicious page, but with the trusted domain preceding it. An example of potential techniques and impacts are listed below:

• Credential theft
  The redirection may lead the victim to a fake page that has been designed to steal credentials. A victim will follow the phishing link from the attacker (be it via email or otherwise), and the resulting attacker crafted page will often look legitimate. The victim will enter their credentials, which will be sent to the attacker. An example scenario is notifying a user that there may have been a possible security breach, and the victim must reset their credentials.
• Malware Delivery
  The disguised link in the phishing email may lead to a malicious website that either directly attempts to deliver malware or initiates a series of events that will ultimately lead to the malware being delivered. JavaScript staging malware is growing in popularity, and has been frequently used in similar circumstances.
  The phishing email may notify the user that they must download a specific file, due to some severe event. The link to the supposed file will again be disguised and will instead resolve to an attacker-controlled domain and downloads a stager (e.g. incident_177884.js) that will automatically execute in the victim's browser. The JavaScript may be obfuscated in order to evade detection and will again contact an attacker-controlled domain to download a further file that will contain a binary, which will attempt to run as a process on the victim's machine, leading to full compromise.

3. Attack patterns

There is one CAPEC pattern that corresponds to this weakness:

• CAPEC-194: Fake the Source of Data

According to WASC classification this attack type is described as URL Redirector Abuse under WASC-38.

4. Affected software

A web application that uses redirector script is potentially vulnerable to this weakness.

5. Exploitation Examples

Vulnerability described in HTB23029 security advisory (Open Redirect Weakness in MBoard) demonstrates this weakness. An attacker can create a malicious page and trick a user into following a link, which appears to be leading to a trusted website. The link can be disguised so that the user does not see the real address in browser's address bar:
http://mboard.local/go.php?param1=AAAAAAAAA[ Lots of A ]AAA&param2=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&url=http://attacker-site.com

The script however will redirect a user to a website that might be under control of an attacker. This vulnerability can be used to perform phishing attacks. An attacker can also try to compromise user's system by exploiting vulnerabilities in browser or its components.

6. Severity and CVSS Scoring

This weakness has no significant impact on security for major applications but giving the CVSS limitations it should be scored as XSS, e.g,
3.4 [CVSS:3.0/AV:N/.AC:H/.PR:N/.UI:R/.S:C/.C:N/.I:L/.A:N] - Low severity.

7. Mitigations

The best way to eliminate the vulnerability is not to use redirector scripts on the website. However, this is not always possible, especially when it comes to redirecting visitors to external websites. There are number of solutions one can use to solve the redirection issue:

1. Do not grant visitors control over the destination URL. This can be done by using internal links such as "/redirect/123" where 123 corresponds to a valid external URL, stored in your database. Such redirects are easy to implement when developing the web application.
2. You can allow external redirects to certain websites only. This way an attacker will not be able to redirect users to arbitrary website. The redirector script will have to compare untrusted input with the list of allowed domains/addresses or you can use a regular expression for that purpose.
3. Use proxy pages when redirecting users to external websites. This will allow to warn users that they are leaving the trusted website.
4. Disable redirects to external websites on the server side.

Proxy Page Example

PHP

As an example, we will create a simple proxy page that uses the "goto" parameter to redirect users to external websites. External links on the website should look like this:

/redirect.php?goto=http://google.com

The proxy page redirect.php warns users that they are being redirected to an external website:

VB

Here is an example of a proxy page for ASP website. The redirection URL looks as follows:

/redirect.aspx?goto=http://google.com

Webserver configuration

This vulnerability can be temporarily closed using webserver configuration.

Apache

You can create a simple rewrite rule to redirect all requests with "goto=http" string to a bogus page, for example "/403.php". The rewrite rule will look as follows:

RewriteEngine On
RewriteCond %{QUERY_STRING} ^(?:.*\&)?goto=http
rewriterule (.*) /403.php [R=permanent,L]

Microsoft IIS

For Internet Information Services you can use a custom filtering rule as a temporary measure. We can disable requests that contain "goto=http://" or "goto=https://" strings, or just disable "://" string in case of multiple redirectors.

Here is an example of Web.config file that disables "goto=http://" and "goto=https://" strings but allows internal redirects, such as "goto=/default.aspx":

8. Common Fix Errors and Bypasses

There are many bypasses for poorly implemented blacklist/whitelist filters, some basic examples of common mistakes and their corresponding bypasses are listed below:

Bypasses for simple blacklist entries. Such as 'http' , '//' , '.' , keywords, and others.

//attacker.com
https://attacker.com
\/\/attacker.com/
////attacker.com/
/\attacker.com
@attacker.com
////\;@attacker.com
attacker%252ecom
<>//attacker.com
%2f%2f192.175.111.230
//attacker.com%00.com
www.allowed.com.attacker.com -> attacker.com


Alternate IP Address Encoding:

http://3232722918
http://[::192.175.111.230]
http:[::192.175.111.230]
http://0300.0257.0157.0346
http://030053667746
http://0xC0.0xAF.0x6F.0xE6


9. References

1. Open redirect [www.owasp.org]
2. CWE-601: URL Redirection to Untrusted Site ('Open Redirect') [cwe.mitre.org]
3. Preventing Open Redirection Attacks in ASP.NET MVC [weblogs.asp.net]

10. Open Redirect Vulnerabilities, Exploits and Examples

• HTB23259: Arbitrary File Disclosure and Open Redirect in Bonita BPM
• HTB23029: Open Redirect Weakness in MBoard

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.

↑ Back to Top