Difference between revisions of "Forward and Redirect Cheat Sheet"

From OWASP
Jump to: navigation, search
 
(39 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Introduction==
+
Moved to the [[Unvalidated Redirects and Forwards Cheat Sheet]].
 
+
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 code obtains a URL from the query string and then redirects the user to that URL.
+
(Bad Code)
+
 
+
$redirect_url = $_GET['url'];
+
header("Location: " . $redirect_url);
+
|}
+
| border="1" bordercolor="#000000" style="border-collapse:collapse;"
+
|+Example Language: PHP
+
!bgcolor="#aabccc"|Service
+
|----
+
|[[Pakistan Army|Army]]
+
|align="center"|550,000
+
|align="center"|500,000
+
|---- bgcolor=#FFFFFF
+
|[[Pakistan Navy|Navy]]
+
|align="center"|22,000
+
|align="center"|5,000
+
|}
+
 
+
 
+
 
+
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
+
 
+
===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
+
 
+
===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
+
*sendRedirect()*<http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/filters/SecurityWrapperResponse.html>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
+
 
+
• OWASP Article on Open Redirects
+
https://www.owasp.org/index.php/Open_redirect
+
 
+
• ESAPI SecurityWrapperResponse.sendRedirect() method
+
 
+
External
+
 
+
• 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
+

Latest revision as of 09:48, 13 March 2013

Moved to the Unvalidated Redirects and Forwards Cheat Sheet.