Difference between revisions of "Forward and Redirect Cheat Sheet"

From OWASP
Jump to: navigation, search
 
(23 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Introduction =
+
Moved to the [[Unvalidated Redirects and Forwards Cheat Sheet]].
Forward and redirect attacks are possible when a web page accepts a redirection parameter in the 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 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.
+
 
+
Forwarding a user to a page without first determining if it is appropriate
+
and they are authorized, could also result in them being allowed to perform actions
+
that are not intended.
+
 
+
 
+
== Redirect Example ==
+
 
+
An application request is sent that 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);
+
 
+
 
+
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:
+
 
+
(Attack)
+
+
http://example.com/example.php?url=http://malicious.example.com
+
 
+
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. 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.
+
 
+
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
+
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
+

Latest revision as of 09:48, 13 March 2013

Moved to the Unvalidated Redirects and Forwards Cheat Sheet.