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

Difference between revisions of "Forward and Redirect Cheat Sheet"

From OWASP
Jump to: navigation, search
 
(16 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Introduction =
+
Moved to the [[Unvalidated Redirects and Forwards Cheat Sheet]].
 
 
The Forward and Redirect Cheat Sheet is a technical guide that explains how URL Forward and Redirects attacks works  . Forward and redirect attacks are possible when a web page accepts a redirection parameter (a url ) in a query-string. When using an URL as input string to a request being initiated from a browser, it is important to 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.
 
The biggest risk of allowing a URL as input without validating it, may result in Phishing scams where users are redirected to malicious websites , which collects the users authentication session or steals the username and password.
 
 
 
== Programming URL redirects ==
 
When we want to redirect a user automatically to another page(without an action of the visitor such as clicking on a hyperlink) you might implement a code such as the following:
 
PHP
 
  <?php
 
  /* Redirect browser */
 
  header("Location: http://www.mysite.com/");
 
  ?>
 
 
 
ASP.NET
 
  Response.Redirect("~/folder/Login.aspx")
 
 
 
In these above examples , the URL is being explicitly declared in the code. Suppose you want to use this URL as a query string to allow a more dynamic way of programming, such building a URL list or saving these URL's in the database. In that case, the URL string instead of being hard coded, it's changed by a variable . The variable is a data type string which is later used in the code.
 
 
 
 
 
== Redirect Example ==
 
 
 
An application request is sent which contains a url as input,
 
malicious.example.com, from the example below. If 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.
 
 
 
  $redirect_url = $_GET['url'];
 
  header("Location: " . $redirect_url);
 
 
 
A similar example of C# .NET Vulnerable Code:
 
 
  string url = request.QueryString["url"];
 
  Response.Redirect(url);
 
 
 
 
 
The above code is vulnerable to an attack if no validation or extra method controls are applied to verify the certainty of the url. This vulnerability could be used as part of a phishing scam by redirecting users to a malicious site.
 
 
 
 
 
You should have a method to validate this URL. The following example uses a behind code (C-Sharp) to validate the URL after the user has click a certain submit button:
 
 
 
'''Example validation in .NET: '''
 
 
 
  protected btRedirect_Click( object sender, EventArgs e )
 
  {
 
  if ( this.IsValid )
 
    Response.Redirect( ... );
 
  }
 
 
 
If no validation is applied, a malicious user could create a hyperlink to redirect your users to an unvalidated malicious website, for example:
 
 
 
http://example.com/example.php?url=http://malicious.example.com
 
 
 
The user sees the link directing 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. After a successful login, the controller returns a redirect to the returnUrl. You can see that no validation is being performed against the returnUrl parameter.
 
 
 
Listing 1 – ASP.NET MVC 2 LogOn action in AccountController.cs
 
 
 
  [HttpPost]
 
  public ActionResult LogOn(LogOnModel model, string returnUrl)
 
  {
 
    if (ModelState.IsValid)
 
    {
 
        if (MembershipService.ValidateUser(model.UserName, model.Password))
 
        {
 
            FormsService.SignIn(model.UserName, model.RememberMe);
 
            if (!String.IsNullOrEmpty(returnUrl))
 
            {
 
                return Redirect(returnUrl);
 
            }
 
            else
 
            {
 
                return RedirectToAction("Index", "Home");
 
            }
 
        }
 
        else
 
        {
 
            ModelState.AddModelError("", "The user name or password provided is incorrect.");
 
        }
 
    }
 
 
    // If we got this far, something failed, redisplay form
 
    return View(model);
 
    }
 
 
 
== 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.
 
 
 
http://www.example.com/function.jsp?fwd=admin.jsp
 
 
 
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.
 
 
 
  public class RedirectServlet extends HttpServlet {
 
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
 
      String query = request.getQueryString();
 
      if (query.contains("url")) {
 
      String url = request.getParameter("url");
 
      response.sendRedirect(url);
 
        }
 
      }
 
    }
 
 
 
== 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.
 
 
 
*Sanitize input by creating a list of trusted URL's.
 
 
 
*Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.
 
 
 
 
 
Applications can use ESAPI to override the
 
*sendRedirect()*<ref><http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/filters/SecurityWrapperResponse.html></ref> method
 
to make sure all redirect destinations are safe.
 
 
 
 
 
== References ==
 
 
 
• OWASP Article on Open Redirects
 
https://www.owasp.org/index.php/Open_redirect
 
 
 
• ESAPI SecurityWrapperResponse.sendRedirect() method
 
 
 
== External Links ==
 
 
 
• CWE Entry 601 on Open Redirects
 
http://cwe.mitre.org/data/definitions/601.html
 
 
 
• WASC Article on URL Redirector Abuse
 
http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse
 
 
 
• Google blog article on the dangers of open redirects
 
http://googlewebmastercentral.blogspot.com/2009/01/open-redirect-urls-is-your-site-being.html
 
 
 
• Preventing Open Redirection Attacks (C#)
 
http://www.asp.net/mvc/tutorials/security/preventing-open-redirection-attacks
 
 
 
= Other Cheatsheets =
 
{{Cheatsheet_Navigation}}
 
 
 
[[Category:Cheatsheets]]
 

Latest revision as of 14:48, 13 March 2013

Moved to the Unvalidated Redirects and Forwards Cheat Sheet.