|
|
| (172 intermediate revisions by 22 users not shown) |
| Line 1: |
Line 1: |
| − | = Introduction = | + | __NOTOC__ |
| | + | <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div> |
| | | | |
| − | Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site, email, blog, instant message, or program causes a user’s Web browser to perform an unwanted action on a trusted site that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the users’ context.
| + | The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]! |
| | | | |
| − | A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).
| + | Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet] to see the latest version of the cheat sheet. |
| − | | |
| − | Utilizing social engineering, an attacker will embed malicious HTML or JavaScript code into an email or Website to request a specific 'task url'. The task then executes with or without the users knowledge, either directly or by utilizing a Cross-site Scripting Flaw.
| |
| − | | |
| − | In effect, CSRF attacks are used by an attacker to make a target system perform a function (Funds Transfer, Form submission etc..) via the targets browser without knowledge of the target user, at least until the unauthorized function has been committed.
| |
| − | | |
| − | = Prevention =
| |
| − | | |
| − | == Token Based ==
| |
| − | | |
| − | The most common defense of CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens.
| |
| − | | |
| − | When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user) the application should include as a query parameter as an “Input” tag of type “hidden” with a name like: CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as they may be leaked. The CSRFToken should have a value that is a randomly generated such as a 128-bit hash that has been base 64 encoded. For each request this token need only be generated randomly once, after that the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has its value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly then the Request Formulator is not the application, the request should be aborted and the event can be logged as a potential security incident.
| |
| − | | |
| − | The request name should be different for each request. The CSRFToken must be strictly protected, for example an application that does not use SSL or passes the token through a URL parameter, will result in the CSRFToken being leaked.
| |
| − | | |
| − | == .NET Viewstate ==
| |
| − | | |
| − | == Prevention Frameworks ==
| |
| − | | |
| − | There are CSRF prevention modules available for J2EE, .Net, and PHP.
| |
| − | | |
| − | [http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project OWASP CSRF Guard] | |
| − | | |
| − | The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.
| |
| − | | |
| − | CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.
| |
| − | | |
| − | Similar Projects
| |
| − | There are a small number of other projects that implement the unique random request token concept similar to that of CSRFGuard. They are as follows:
| |
| − | | |
| − | [http://www.owasp.org/index.php/PHP_CSRF_Guard http://www.owasp.org/index.php/PHP_CSRF_Guard]
| |
| − | | |
| − | [http://www.owasp.org/index.php/.Net_CSRF_Guard http://www.owasp.org/index.php/.Net_CSRF_Guard]
| |
| − | | |
| − | = Challenge-Response =
| |
| − | | |
| − | = Double Submit Cookies =
| |
| − | | |
| − | = Prevention Measures That Do NOT Work =
| |
| − | | |
| − | '''Using a Secret Cookie'''
| |
| − | | |
| − | Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.
| |
| − | | |
| − | '''Only Accepting POST Requests'''
| |
| − | | |
| − | Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.
| |
| − | | |
| − | '''Checking Referer Header'''
| |
| − | | |
| − | An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear the this header is optional. Browsers also omit the referer header when they are being used over SSL.
| |
| − | | |
| − | '''Multi-Step Transactions'''
| |
| − | | |
| − | Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacked can predict or deduce each step of the completed transaction, then CSRF is possible.
| |
| − | | |
| − | '''URL Rewriting'''
| |
| − | | |
| − | This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.
| |
| − | | |
| − | | |
| − | | |
| − | = References =
| |
| − | | |
| − | [https://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery]
| |
| − | | |
| − | An introduction to a common web application weakness
| |
| − | | |
| − | | |
| − | [[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]
| |
