|
|
(38 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);
| |
− | | |
− | | |
− | 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
| |