CWE-601: URL Redirection to Untrusted Site

The weakness occurs when an application places user-controlled data into a redirect destination without tightly restricting the permitted URL or domain. An attacker can alter the redirect value so that a link originating from a trusted application leads to an attacker-controlled page. That page may imitate a trusted site to collect credentials, or may expose the user to malware and an automatic download. The same risk applies to indirectly obtained input, not only to visibly supplied URL parameters.

The defining characteristic is a redirect whose destination is influenced by untrusted user input and is not constrained to approved destinations. Because the redirect starts from a trusted application, the resulting link can appear more credible than a directly supplied malicious link. The weakness commonly reflects an omitted architecture or design security tactic, or incorrect assumptions that sources such as cookies and hidden form fields cannot be modified. It is not specific to a programming language.

This weakness can undermine access-control protections by sending users to untrusted pages that host malware or trigger an automatic download. Malware may compromise the user's system or steal credentials, personally identifiable information, and other data through activities such as keylogging. Attackers can also use the trusted-looking redirect to conduct phishing, collect credentials, and then use those credentials against the legitimate site. The affected security scopes include access control, confidentiality, and other security properties; impacts include bypassing protection mechanisms and gaining privileges or assuming an identity.

Validate redirects against an allowlist. Treat every input as potentially malicious and use accept-known-good validation covering the expected type, length, syntax, complete value range, missing or extra data, consistency, and business rules. Approve only specifically allowed URLs or domains, rather than relying exclusively on a denylist.

Replace user-supplied URLs with fixed mappings. When the permitted destinations are limited or known, accept fixed identifiers and map them to the corresponding URLs, rejecting all other values.

Use an intermediate warning page. Clearly warn users that they are leaving the current site, require an explicit click, or apply a long delay before redirecting. Avoid introducing cross-site scripting when generating that page.

Require an unpredictable application nonce. Require every externally supplied redirect request to include a unique nonce generated by the application, and ensure that the nonce is not predictable. This measure can be bypassed through cross-site scripting.

Reduce the attack surface. Identify every possible source of untrusted data, including parameters, cookies, hidden fields, network data, environment variables, reverse DNS results, query results, request headers, URL components, files, databases, email, APIs, and external systems. Do not assume that cookies or hidden fields cannot be modified.

Use an application firewall as defense in depth. This can provide emergency protection when the code cannot immediately be fixed, but it may miss input vectors, be bypassed by malformed inputs, or reject or alter legitimate requests. Customization may also be necessary.

Several detection approaches are applicable. Manual static analysis and source-code review can provide good coverage and reduce false positives when potentially vulnerable redirect operations can be assessed within the available time. Automated static analysis, including source, binary, and bytecode analysis, can model data and control flow to find paths from input sources to redirect sinks, but tools may have difficulty determining whether input controls the beginning of a URL. Automated dynamic analysis can submit URLs through inputs and look for changes to the Location header, but coverage affects results and custom redirects may be missed. Web application, web services, and database scanners, fuzz testers, and framework-based fuzzers can supplement these checks. Architecture and design review, including formal methods, correct-by-construction approaches, and IEEE 1028 inspection, can also be used, with coverage depending on the review method.

The official record lists the following representative examples, not an exhaustive set:

• CVE-2005-4206: A URL parameter loads a URL into a frame, making it appear to be part of a valid page.
• CVE-2008-2951: A search script permits remote attackers to redirect users to arbitrary sites and conduct phishing through a URL supplied as a parameter.
• CVE-2008-2052: A URL in the relevant parameter permits remote attackers to redirect users to arbitrary sites and conduct phishing attacks.
• CVE-2020-11053: A Go-based OAuth2 reverse proxy can send an authenticated user to another site after authentication; an HTML-encoded whitespace character in the redirect URL can bypass validation and enable redirection to a malicious site.