This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Redirects and forwards

Revision as of 01:07, 5 February 2013 by Johanna Curiel (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


When using an url as input to a request being initiated from a browser, it is important to validate the url,you must determine that it is appropriate based on the request and verify that the user is authorized to access the target. Allowing an URL as input without validation before redirecting the browser , can 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 could result in them being allowed to perform actions that are not acceptable.

Redirect Example

An application request is sent that contains an url as input,, from the example below. Where this request includes an 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.

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,it must perform the functions it provides, and it must control that 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.

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.

Applications can use ESAPI to override the

to make sure all redirect destinations are safe.

Avoiding such flaws is extremely important as they are a favorite target of phishers trying to gain the user’s trust to exploit.

  • References*


• OWASP Article on Open Redirects

• ESAPI SecurityWrapperResponse.sendRedirect() method


• CWE Entry 601 on Open Redirects

• WASC Article on URL Redirector Abuse

• Google blog article on the dangers of open redirects