Introduction

When using an URL as input to a request being initiated from a browser, it
is important the validate the URL, it is essential to determine that the redirect
or forward is appropriate based on the request and the user is authorized to access the target. Allowing a
URL as input without validation before redirecting the browser , could
result in sending the user to a malicious link without their knowledge.
Forwarding a user to a page without first determining if it is appropriate
and they are authorized can result in them being allowed to perform actions
that are not acceptable.

Redirect Example

An application request is sent that contains a url as input,
malicious.example.com, from the example below. Where this request includes
a url as input that is not validated by the server, the browser can be
redirected to a malicious url to perform any number of undesirable actions.

Example 1:
The following PHP code obtains a URL from the query string and then redirects the user to that 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

Example 2

ASP.NET MVC 1 & 2 websites are particularly vulnerable to open redirection attacks. In order to avoid this vulnerability, you need to apply MVC 3 .
The code for the LogOn action in an ASP.NET MVC 2 application is shown below. Note that upon a successful login, the controller returns a redirect to the returnUrl. You can see that no validation is being performed against the returnUrl parameter.

Forward Example

When applications allow user input to forward requests between different
parts of the site, the application must check that the user is authorized
to access the url, perform the functions it provides, and it is an
appropriate url request. If the application fails to perform these checks,
an attacker crafted URL may pass the application’s access control check and
then forward the attacker to an administrative function that is not
normally permitted.

The following code is a Java servlet that will receive a GET request with a url parameter in the request to redirect the browser to the address specified in the url parameter. The servlet will retrieve the url parameter value from the request and send a response to redirect the browser to the url address.

Attack Vectors and Risk

When considering the risk, think about the implications of anyone who can
trick your users into clicking on a malicious link. This can be used to
direct users to malicious sites when they think they are actually going to
your site or another legitimate site or one of its pages. Any website or
other HTML feed that your users use could do this.

Attacker changes the url to an unvalidated redirect and the unsuspecting
victim clicks on it because they are unaware of the deception.

Attacker targets unsafe forward to bypass security checks to perform
actions that they are not authorized to perform.

Security Weakness

Applications frequently redirect users to other pages, or use internal
forwards in a similar manner. Sometimes the target page is specified in
unvalidated input, allowing attackers to choose the destination page or
function they wish to perform.

Technical impacts

Such redirects may attempt to install malware or trick victims into
disclosing passwords or other sensitive information. Unsafe forwards may
allow access control bypass.

Business impacts

Consider the business value of retaining your users’ trust.

What if they get owned by malware?

What if attackers can access internal only functions?

Am I Vulnerable To Unvalidated Redirects and Forwards?

The best way to find out if an application has any unvalidated redirects or
forwards is to:

Review the code for all uses of redirect or forward (called a transfer in
.NET). For each use, identify if the target URL is included in any
parameter values. If so, verify the parameter(s) are validated to contain
only an allowed destination, or element of a destination.

Also, spider the site to see if it generates any redirects (HTTP response
codes 300-307, typically 302). Look at the parameters supplied prior to the
redirect to see if they appear to be a target URL or a piece of such a URL.
If so, change the URL target and observe whether the site redirects to the
new target.

If code is unavailable, check all parameters to see if they look like part
of a redirect or forward URL destination and test those that do.

How Do I Prevent Unvalidated Redirects and Forwards?

Safe use of redirects and forwards can be done in a number of ways:

Simply avoid using redirects and forwards.

If used, don’t allow the url as user input for the destination. This can

usually be done.

If user input can’t be avoided, ensure that the supplied *value* is valid,

appropriate for the application, and *authorized* for the user.

It is recommended that any such destination input be mapped to a value,

rather than the actual URL or portion of the URL, and that server side code
translate this value to the target URL.