URL Redirection to Untrusted Site ('Open Redirect')
Weakness ID: 601 (Weakness Variant)Status: Draft
+ Description

Description Summary

A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.

Extended Description

An http parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance.

+ Alternate Terms
Open Redirect
Cross-site Redirect
Cross-domain Redirect
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms



Architectural Paradigms


+ Common Consequences

The user may be redirected to an untrusted page that contains malware which may then compromise the user's machine. This will expose the user to extensive risk and the user's interaction with the web server may also be compromised if the malware conducts keylogging or other attacks that steal credentials, personally identifiable information (PII), or other important data.


The user may be subjected to phishing attacks by being redirected to an untrusted page. The phishing attack may point to an attacker controlled web page that appears to be a trusted web site. The phishers may then steal the users credentials and then use these credentials to access the legitimate web site.

+ Likelihood of Exploit

Low to Medium

+ Detection Methods

Manual Static Analysis

Since this weakness does not typically appear frequently within a single software package, manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all potentially-vulnerable operations can be assessed within limited time constraints.

Effectiveness: High

Automated Dynamic Analysis

Automated black box tools that supply URLs to every input may be able to spot Location header modifications, but test case coverage is a factor, and custom redirects may not be detected.

Automated Static Analysis

Automated static analysis tools may not be able to determine whether input influences the beginning of a URL, which is important for reducing false positives.


Whether this issue poses a vulnerability will be subject to the intended behavior of the application. For example, a search engine might intentionally provide redirects to arbitrary URLs.

+ Demonstrative Examples

Example 1

The following code obtains a URL from the query string and then redirects the user to that URL.

(Bad Code)
Example Language: PHP 
$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);

The problem with the above code is that an attacker could use this page as part of a phishing scam by redirecting users to a malicious site. For example, assume the above code is in the file example.php. An attacker could supply a user with the following link:


The user sees the link pointing to the original trusted site (example.com) and does not realize the redirection that could take place.

+ Observed Examples
CVE-2005-4206URL parameter loads the URL into a frame and causes it to appear to be part of a valid page.
CVE-2008-2951An open redirect vulnerability in the search script in the software allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL as a parameter to the proper function.
CVE-2008-2052Open redirect vulnerability in the software allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the proper parameter.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Use a whitelist of approved URLs or domains to be used for redirection.

Phase: Architecture and Design

Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving your site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.

Phase: Architecture and Design

When the set of URLs to be redirected is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual URLs, and reject all other inputs. For example, ID 1 could map to "/login.asp" and ID 2 could map to "http://www.example.com/". Features such as the ESAPI AccessReferenceMap provide this capability.

Phases: Architecture and Design; Implementation

Strategy: Identify and Reduce Attack Surface

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.

Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.

+ Background Details

Phishing is a general term for deceptive attempts to coerce private information from users that will be used for identity theft.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Development Concepts (primary)699
ChildOfCategoryCategory442Web Problems
Development Concepts699
ChildOfWeakness ClassWeakness Class610Externally Controlled Reference to a Resource in Another Sphere
Research Concepts (primary)1000
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory8012010 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Anonymous Tool Vendor (under NDA)
WASC38URl Redirector Abuse
+ Related Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.4)
194Fake the Source of Data
+ References
Craig A. Shue, Andrew J. Kalafut and Minaxi Gupta. "Exploitable Redirects on the Web: Identification, Prevalence, and Defense". <http://www.cs.indiana.edu/cgi-pub/cshue/research/woot08.pdf>.
Russ McRee. "Open redirect vulnerabilities: definition and prevention". Page 43. Issue 17. (IN)SECURE. July 2008. <http://www.net-security.org/dl/insecure/INSECURE-Mag-17.pdf>.
+ Content History
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)Externally Mined
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential Mitigations, Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Alternate Terms, Background Details, Description, Detection Factors, Likelihood of Exploit, Name, Relationships, Observed Example, Taxonomy Mappings
2008-10-03CWE Content TeamMITREInternal
updated References and Observed Examples
2008-10-14CWE Content TeamMITREInternal
updated Alternate Terms, Observed Examples, References
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Name
2009-12-28CWE Content TeamMITREInternal
updated Demonstrative Examples, Detection Factors, Likelihood of Exploit, Potential Mitigations
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unsafe URL Redirection
2008-09-09URL Redirection to Untrusted Site
2009-05-27URL Redirection to Untrusted Site (aka 'Open Redirect')