https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Esheridan 2026-05-09T03:08:39Z User contributions MediaWiki 1.27.2 https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=161563 2013-10-25T13:50:34Z

<p>Esheridan: </p> <hr /> <div>&lt;!---==== Main ====---&gt;<br /> == Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> THE PROJECT IS IN NEED OF LEADERSHIP! Contact Samantha Groves (samantha.groves@owasp.org) if you are interested!<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> Download and build the latest source code from GitHub - https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> &lt;!---==== Project About ====<br /> {{:Projects/OWASP CSRFGuard Project| Project About}}<br /> <br /> __NOTOC__ &lt;headertabs /&gt;----&gt;<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=161562 2013-10-25T13:50:12Z

<p>Esheridan: /* Project Lead */</p> <hr /> <div>&lt;!---==== Main ====---&gt;<br /> == Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> THE PROJECT IS IN NEED OF LEADERSHIP! Contact Samantha Groves (samantha.groves@owasp.org) if you are interested!<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> Download and build the latest source code from GitHub - https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [[File:Infrared-logo-small.png | link=http://www.infraredsecurity.com]]<br /> <br /> &lt;!---==== Project About ====<br /> {{:Projects/OWASP CSRFGuard Project| Project About}}<br /> <br /> __NOTOC__ &lt;headertabs /&gt;----&gt;<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_User_Manual&diff=154359 2013-06-24T12:41:09Z

<p>Esheridan: /* Download */</p> <hr /> <div>= Overview =<br /> <br /> Welcome to the OWASP CSRFGuard 3 User Manual! The purpose of this article is to provide the user with guidance on obtaining, installing, deploying, and developing with the OWASP CSRFGuard library. The author's goal was to keep the User Manual informative, use to understand, and concise. If you find that one or more aspects of this document does not adhere to these goals, please me know at eric dot sheridan at owasp dot org.<br /> <br /> = Download =<br /> <br /> Users can download the latest release of OWASP CSRFGuard using one of the following links:<br /> <br /> Download and build the source at - https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> = Installation =<br /> <br /> Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps:<br /> <br /> :# Copy the Owasp.CsrfGuard.jar file to your application's classpath<br /> :# Declare CsrfGuard in your application's deployment descriptor (web.xml)<br /> :# Configure the Owasp.CsrfGuard.properties file as you see fit<br /> <br /> [[CSRFGuard_3_Installation | Click here]] for more detailed information regarding the installation of OWASP CSRFGuard.<br /> <br /> = Configuration =<br /> <br /> The minimum configuration settings that users should review include:<br /> <br /> :* Default new token landing page (org.owasp.csrfguard.NewTokenLandingPage)<br /> :* Support for Ajax and XMLHttpRequest (org.owasp.csrfguard.Ajax)<br /> :* URI resources that should not be protected (org.owasp.csrfguard.unprotected.*)<br /> :* Actions executed when an attack is detected (org.owasp.csrfguard.action.*)<br /> <br /> [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> = Token Injection =<br /> <br /> Users of OWASP CSRFGuard can inject prevention tokens into HTML using two strategies:<br /> <br /> :* JavaScript DOM Manipulation - largely automated process requiring minimal effort and is ideal for most web applications<br /> :* JSP Tag Library - provides fine grained strategy ideal for situations where automated DOM manipulation is insufficient.<br /> <br /> [[CSRFGuard_3_Token_Injection | Click here]] for more information regarding the injection of CSRF prevention tokens within your application.<br /> <br /> = Known Issues =<br /> <br /> The following is a quick bulleted list of known issues within the current release:<br /> <br /> :* No known way to inject CSRF prevention tokens into setters of document.location (ex: document.location=&quot;http://www.owasp.org&quot;;)<br /> <br /> [[Category:OWASP_CSRFGuard_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=154358 2013-06-24T12:40:45Z

<p>Esheridan: /* Downloads */</p> <hr /> <div>&lt;!---==== Main ====---&gt;<br /> == Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> [mailto:eric@infraredsecurity.com Eric Sheridan] is the lead and primary developer of the OWASP CSRFGuard project and a Managing Partner at [http://www.infraredsecurity.com Infrared Security]. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including CSRF Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). As Managing Partner at Infrared Security, Eric Sheridan specializes in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> Download and build the latest source code from GitHub - https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [[File:Infrared-logo-small.png | link=http://www.infraredsecurity.com]]<br /> <br /> &lt;!---==== Project About ====<br /> {{:Projects/OWASP CSRFGuard Project| Project About}}<br /> <br /> __NOTOC__ &lt;headertabs /&gt;----&gt;<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=136936 2012-10-02T17:50:53Z

<p>Esheridan: </p> <hr /> <div>= Introduction =<br /> <br /> 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 for which the user is currently authenticated. The impact of a successful cross-site request forgery attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context. In affect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the target's browser without knowledge of the target user, at least until the unauthorized function has been committed.<br /> <br /> Impacts of successful CSRF exploits vary greatly based on the role of the victim. When targeting a normal user, a successful CSRF attack can compromise end-user data and their associated functions. 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). 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 user's knowledge, either directly or by utilizing a Cross-site Scripting flaw (ex: Samy MySpace Worm).<br /> <br /> For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.<br /> <br /> = Prevention Measures That Do NOT Work =<br /> <br /> '''Using a Secret Cookie'''<br /> <br /> 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. <br /> <br /> '''Only Accepting POST Requests'''<br /> <br /> 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 an attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.<br /> <br /> '''Multi-Step Transactions'''<br /> <br /> Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.<br /> <br /> '''URL Rewriting'''<br /> <br /> 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.<br /> <br /> = General Recommendation: Synchronizer Token Pattern =<br /> <br /> In order to facilitate a &quot;transparent but visible&quot; CSRF solution, developers are encouraged to adopt the Synchronizer Token Pattern (http://www.corej2eepatterns.com/Design/PresoDesign.htm). The synchronizer token pattern requires the generating of random &quot;challenge&quot; tokens that are associated with the user's current session. These challenge tokens are the inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token. It is then the responsibility of the server application to verify the existence and correctness of this token. By including a challenge token with each request, the developer has a strong control to verify that the user actually intended to submit the desired requests. Inclusion of a required security token in HTTP requests associated with sensitive business functions helps mitigate CSRF attacks as successful exploitation assumes the attacker knows the randomly generated token for the target victim's session. This is analogous to the attacker being able to guess the target victim's session identifier. The following synopsis describes a general approach to incorporate challenge tokens within the request.<br /> <br /> 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 a hidden input parameter with a common name such as &quot;CSRFToken&quot;. The value of this token must be randomly generated such that it cannot be guessed by an attacker. Consider leveraging the java.security.SecureRandom class for Java applications to generate a sufficiently long random token. Alternative generation algorithms include the use of 256-bit BASE64 encoded hashes. Developers that choose this generation algorithm must make sure that there is randomness and uniqueness utilized in the data that is hashed to generate the random token.<br /> <br /> &lt;form action=&quot;/transfer.do&quot; method=&quot;post&quot;&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;CSRFToken&quot; value=&quot;OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi<br /> MGYwMGEwOA==&quot;&gt;<br /> …<br /> &lt;/form&gt;<br /> <br /> In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted, token should be reset and the event logged as a potential CSRF attack in progress.<br /> <br /> To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and or value for each request. Implementing this approach results in the generation of per-request tokens as opposed to per-session tokens. Note, however, that this may result in usability concerns. For example, the &quot;Back&quot; button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event at the server. Regardless of the approach taken, developers are encouraged to protect the CSRF token the same way they protect authenticated session identifiers, such as the use of SSLv3/TLS.<br /> <br /> === Disclosure of Token in URL ===<br /> <br /> Many implementations of this control include the challenge token in GET (URL) requests as well as POST requests. This often implemented as a result of sensitive server-side operations being invoked as a result of embedded links in the page or other general design patterns. These patterns are often implemented without knowledge of CSRF and an understanding of CSRF prevention design strategies. While this control does help mitigate the risk of CSRF attacks, the unique per-session token is being exposed for GET requests. CSRF tokens in GET requests are potentially leaked at several locations: browser history, HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referrer headers if the protected site links to an external site.<br /> <br /> In the latter case (leaked CSRF token due to the Referer header being parsed by a linked site), it is trivially easy for the linked site to launch a CSRF attack on the protected site, and they will be able to target this attack very effectively, since the Referer header tells them the site as well as the CSRF token. The attack could be run entirely from javascript, so that a simple addition of a script tag to the HTML of a site can launch an attack (whether on an originally malicious site or on a hacked site). Timeouts on CSRF tokens are very unlikely to help this attack scenario.<br /> <br /> The ideal solution is to only include the CSRF token in POST requests and modify server-side actions that have state changing affect to only respond to POST requests. This is in fact what the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 RFC 2616] requires for GET requests. If sensitive server-side actions are guaranteed to only ever respond to POST requests, then there is no need to include the token in GET requests.<br /> <br /> In most JavaEE web applications, however, HTTP method scoping is rarely ever utilized when retrieving HTTP parameters from a request. Calls to &quot;HttpServletRequest.getParameter&quot; will return a parameter value regardless if it was a GET or POST. This is not to say HTTP method scoping cannot be enforced. It can be achieved if a developer explicitly overrides doPost() in the HttpServlet class or leverages framework specific capabilities such as the AbstractFormController class in Spring.<br /> <br /> For these cases, attempting to retrofit this pattern in existing applications requires significant development time and cost, and as a temporary measure it may be better to pass CSRF tokens in the URL. Once the application has been fixed to respond to HTTP GET and POST verbs correctly, CSRF tokens for GET requests should be turned off.<br /> <br /> === Viewstate (ASP.NET) ===<br /> <br /> ASP.NET has an option to maintain your ViewState. The ViewState indicates the status of a page when submitted to the server. The status is defined through a hidden field placed on each page with a &lt;form runat=&quot;server&quot;&gt; control. Viewstate can be used as a CSRF defense, as it is difficult for an attacker to forge a valid Viewstate. It is not impossible to forge a valid Viewstate since it is feasible that parameter values could be obtained or guessed by the attacker. However, if the current session ID is added to the ViewState, it then makes each Viewstate unique, and thus immune to CSRF. <br /> <br /> To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (This property must be set in the Page.Init event)<br /> <br /> protected override OnInit(EventArgs e) {<br /> base.OnInit(e); <br /> if (User.Identity.IsAuthenticated)<br /> ViewStateUserKey = Session.SessionID; }<br /> <br /> The following keys the Viewstate to an individual using a unique value of your choice.<br /> <br /> (Page.ViewStateUserKey)<br /> <br /> This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.<br /> <br /> However, there are [http://keepitlocked.net/archive/2008/05/29/viewstateuserkey-doesn-t-prevent-cross-site-request-forgery.aspx limitations] on this mechanism. Such as, ViewState MACs are only checked on POSTback, so any other application requests not using postbacks will happily allow CSRF.<br /> <br /> === Double Submit Cookies ===<br /> <br /> Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value. When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.<br /> <br /> While this approach is effective in mitigating the risk of cross-site request forgery, including authenticated session identifiers in HTTP parameters may increase the overall risk of session hijacking. Architects and developers must ensure that no network appliances or custom application code or modules explicitly log or otherwise disclose HTTP POST parameters. An attacker that is able to obtain access to repositories or channels that leak HTTP POST parameters will be able to replay the tokens and perform session hijacking attacks. Note, however, that transparently logging all HTTP POST parameters is a rare occurrence across network systems and web applications as doing so will expose significant sensitive data aside from session identifiers including passwords, credit card numbers, and or social security numbers. Inclusion of the session identifier within HTML can also be leveraged by cross-site scripting attacks to bypass HTTPOnly protections. Most modern browsers prevent client-side script from accessing HTTPOnly cookies. However, this protection is lost if HTTPOnly session identifiers are placed within HTML as client-side script can easily traverse and extract the identifier from the DOM. Developers are still encouraged to implement the synchronizer token pattern as described in this article.<br /> <br /> [http://directwebremoting.org Direct Web Remoting (DWR)] Java library version 2.0 has CSRF protection built in as it implements the double cookie submission transparently.<br /> <br /> === Prevention Frameworks ===<br /> <br /> There are CSRF prevention modules available for J2EE, .Net, and PHP.<br /> <br /> [[:Category:OWASP_CSRFGuard_Project | OWASP CSRF Guard (For Java)]]<br /> <br /> 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. <br /> <br /> '''Similar Projects'''<br /> <br /> CSRFGuard has been implemented in other languages besides Java. They are: <br /> <br /> *[[PHP CSRF Guard]]<br /> *[[.Net CSRF Guard]]<br /> <br /> == Challenge-Response ==<br /> <br /> Challenge-Response is another defense option for CSRF. The following are some examples of challenge-response options.<br /> <br /> *CAPTCHA<br /> *Re-Authentication (password)<br /> *One-time Token<br /> <br /> While challenge-response is a very strong defense to CSRF (assuming proper implementation), it does impact user experience. For applications in need of high security, tokens (transparent) and challenge-response should be used on high risk functions.<br /> <br /> = Checking The Referer Header =<br /> Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce.<br /> <br /> However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check. It should be noted that GET requests should never incur a state change as this is a violation of the HTTP specification. <br /> <br /> There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is &quot;site.com&quot; then an attacker have the CSRF exploit originate from &quot;site.com.attacker.com&quot; which may fool a broken referer check implementation. XSS can be used to bypass a referer check. <br /> <br /> = Checking The Origin Header =<br /> The [https://wiki.mozilla.org/Security/Origin Origin HTTP Header] was introduced as a method of defending against CSRF and other Cross-Domain attacks. Unlike the referer, the origin will be present in HTTP request that originates from an HTTPS url.<br /> <br /> If the origin header is present, then it should be checked for consistency.<br /> <br /> = Client/User Prevention =<br /> <br /> Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating include: <br /> <br /> * Logoff immediately after using a Web application <br /> * Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login <br /> * Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing). <br /> * The use of plugins such as No-Script makes POST based CSRF vulnerabilities difficult to exploit. This is because JavaScript is used to automatically submit the form when the exploit is loaded. Without JavaScript the attacker would have to trick the user into submitting the form manually. <br /> <br /> Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack. <br /> <br /> = No Cross-Site Scripting (XSS) Vulnerabilities =<br /> <br /> Cross-Site Scripting is not necessary for CSRF to work. However, all stored cross-site scripting attacks can be used to defeat token, referer and origin based CSRF defenses, This is because an XSS payload can simply read any page on the site using a XMLHttpRequest and obtain the generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) MySpace (Samy) worm] defeated MySpace's anti CSRF defenses in 2005, which enabled the worm to propagate. XSS cannot defeat challenge-response defenses such as Captcha, re-authentication or one-time passwords. It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented. Please see the OWASP [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheat Sheet]] for detailed guidance on how to prevent XSS flaws.<br /> <br /> = Related Articles =<br /> <br /> '''Cross-Site Request Forgery (CSRF)'''<br /> <br /> For more information on CSRF please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.<br /> <br /> '''How to Review Code for CSRF Vulnerabilities'''<br /> <br /> See the [[:Category:OWASP_Code_Review_Project | OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues]]. <br /> <br /> '''How to Test for CSRF Vulnerabilities'''<br /> <br /> See the [[:Category:OWASP_Testing_Project | OWASP Testing Guide]] article on how to [[Testing_for_CSRF_(OWASP-SM-005) | Test for CSRF Vulnerabilities]]. <br /> <br /> '''CSRF Testing Tool'''<br /> <br /> Check out the [[:Category:OWASP_CSRFTester_Project | OWASP CSRF Tester]] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java. <br /> <br /> = References =<br /> <br /> [http://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery: An introduction to a common web application weakness]<br /> <br /> [http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Cross-Site Request Forgeries: Exploitation and Prevention]<br /> <br /> = Authors and Primary Editors =<br /> <br /> Paul Petefish - paulpetefish[at]solutionary.com&lt;br/&gt;<br /> Eric Sheridan - eric[at]infraredsecurity.com&lt;br/&gt;<br /> Dave Wichers - dave.wichers[at]aspectsecurity.com <br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> [[Category:Cheatsheets]]</div>

Esheridan https://wiki.owasp.org/index.php?title=OWASP_Appsec_Tutorial_Series&diff=125014 2012-02-24T18:50:45Z

<p>Esheridan: /* Overview */</p> <hr /> <div>= Overview =<br /> <br /> Welcome to the home of the OWASP AppSec Tutorial Series project! The OWASP AppSec Tutorial Series project provides a video based means of conveying complex application security concepts in an easily accessible and understandable way. Each video is approximately 5-10 minutes long and highlights one or more specific application security concepts, tools, or methodologies. The goal of the project is quite simple and yet quite audacious - provide top notch application security video based training... for free!<br /> <br /> = Project Goals =<br /> <br /> While there are a significant number of objectives we hope to achieve, the OWASP AppSec Tutorial Series is focused on the following goals:<br /> <br /> * Create top notch application security video based training materials<br /> * Convey complex application security topics in a fun and informative way<br /> * MAKE APPSEC MORE VISIBLE!<br /> <br /> = Episode List =<br /> <br /> *[http://www.youtube.com/watch?v=CDbWvEwBBxo Episode 1 - Introduction]<br /> *[http://www.youtube.com/watch?v=pypTYPaU7mM Episode 2 - Injection Attacks]<br /> *[http://www.youtube.com/watch?v=_Z9RQSnf8-g Episode 3 - Cross Site Scripting]<br /> <br /> = Project Lead =<br /> <br /> [mailto:jerry@owasp.org Jerry Hoff] is the lead of the OWASP AppSec Tutorial Series project, is VP of the Static Code Analysis division at WhiteHat Security and is a Managing Partner at Infrared Security. Having performed code reviews and penetration tests of hundreds of applications for Fortune 500 companies, Jerry Hoff is an experienced application security practitioner. He also has over a decade of professional training experience at an advanced degree level. His application security experience coupled with his training experience helps ensure the OWASP AppSec Tutorial Series project continues to deliver exceptional episodes free for the community!<br /> <br /> = License = <br /> <br /> The OWASP Appsec Tutorial Series is released under the [http://creativecommons.org/licenses/by-nc/3.0/ Attribution-NonCommercial license].<br /> <br /> = Project Sponsor =<br /> <br /> The OWASP Appsec Tutorial Series is sponsored by [http://www.infraredsecurity.com Infrared Security].<br /> <br /> [[File:Infrared-logo-small.png | link=http://www.infraredsecurity.com]]<br /> <br /> [[Category:OWASP Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=OWASP_Appsec_Tutorial_Series&diff=120004 2011-11-11T13:53:46Z

<p>Esheridan: </p> <hr /> <div>= Overview =<br /> <br /> Welcome to the home of the OWASP AppSec Tutorial Series project! The OWASP AppSec Tutorial Series project provides a video based means of conveying complex application security concepts in an easily accessible and understandable way. Each video is approximately 5-10 minutes long and highlights one or more specific application security concepts, tools, or methodologies. The goal of the project is quite simple and yet quite audacious - provide top notch application security video based training... for free! It is our hope that the community<br /> <br /> = Project Goals =<br /> <br /> While there are a significant number of objectives we hope to achieve, the OWASP AppSec Tutorial Series is focused on the following audacious goals:<br /> <br /> * Create top notch application security video based training materials<br /> * Convey complex application security topics in a fun and informative way<br /> * Be able to deliver the material for free!<br /> <br /> = Episode List =<br /> <br /> *[http://www.youtube.com/watch?v=CDbWvEwBBxo Episode 1 - Introduction]<br /> *[http://www.youtube.com/watch?v=pypTYPaU7mM Episode 2 - Injection Attacks]<br /> *[http://www.youtube.com/watch?v=_Z9RQSnf8-g Episode 3 - Cross Site Scripting]<br /> <br /> = Project Lead =<br /> <br /> [mailto:jerry@owasp.org Jerry Hoff] is the lead of the OWASP AppSec Tutorial Series project and is a Managing Partner at [http://www.infraredsecurity.com Infrared Security]. Having performed code reviews and penetration tests of hundreds of applications for Fortune 500 companies, Jerry Hoff is an experienced application security practitioner. He also has over a decade of professional training experience at an advanced degree level. His application security experience coupled with his training experience helps ensure the OWASP AppSec Tutorial Series project continues to deliver exceptional episodes free for the community!<br /> <br /> = License = <br /> <br /> The OWASP Appsec Tutorial Series is released under the [http://creativecommons.org/licenses/by-nc/3.0/ Attribution-NonCommercial license].<br /> <br /> =Project Sponsor=<br /> <br /> [[File:Infrared-logo-small.png | link=http://www.infraredsecurity.com]]<br /> <br /> [[Category:OWASP Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=OWASP_Appsec_Tutorial_Series&diff=120003 2011-11-11T13:53:17Z

<p>Esheridan: </p> <hr /> <div>= Overview =<br /> <br /> Welcome to the home of the OWASP AppSec Tutorial Series project! The OWASP AppSec Tutorial Series project provides a video based means of conveying complex application security concepts in an easily accessible and understandable way. Each video is approximately 5-10 minutes long and highlights one or more specific application security concepts, tools, or methodologies. The goal of the project is quite simple and yet quite audacious - provide top notch application security video based training... for free! It is our hope that the community<br /> <br /> = Project Goals =<br /> <br /> While there are a significant number of objectives we hope to achieve, the OWASP AppSec Tutorial Series is focused on the following audacious goals:<br /> <br /> * Create top notch application security video based training materials<br /> * Convey complex application security topics in a fun and informative way<br /> * Be able to deliver the material for free!<br /> <br /> = Episode List =<br /> <br /> *[http://www.youtube.com/watch?v=CDbWvEwBBxo Episode 1 - Introduction]<br /> *[http://www.youtube.com/watch?v=pypTYPaU7mM Episode 2 - Injection Attacks]<br /> *[http://www.youtube.com/watch?v=_Z9RQSnf8-g Episode 3 - Cross Site Scripting]<br /> <br /> = Project Lead =<br /> <br /> [mailto:jerry@owasp.org Jerry Hoff] is the lead of the OWASP AppSec Tutorial Series project and is a Managing Partner at [http://www.infraredsecurity.com Infrared Security]. Having performed code reviews and penetration tests of hundreds of applications for Fortune 500 companies, Jerry Hoff is an experienced application security practitioner. He also has over a decade of professional training experience at an advanced degree level. His application security experience coupled with his training experience helps ensure the OWASP AppSec Tutorial Series project continues to deliver exceptional episodes free for the community!<br /> <br /> = License = <br /> <br /> The OWASP Appsec Tutorial Series is released under the [http://creativecommons.org/licenses/by-nc/3.0/ Attribution-NonCommercial license].<br /> <br /> =Project Sponsor=<br /> <br /> [[File:Infrared-logo-small.png | link=http://www.infraredsecurity.com]]</div>

Esheridan https://wiki.owasp.org/index.php?title=OWASP_Appsec_Tutorial_Series&diff=120002 2011-11-11T13:34:52Z

<p>Esheridan: </p> <hr /> <div>==== Main ====<br /> <br /> = Overview =<br /> <br /> The OWASP Appsec Tutorial Series breaks down security concepts in a easily accessible, friendly way. Each video is 5-10 minutes long and highlights a different security concept, tool or methodology. <br /> <br /> <br /> = Project Goals =<br /> <br /> The goal is to cover each major OWASP project in a fun, informative way. <br /> <br /> = Episode List =<br /> <br /> *[http://www.youtube.com/watch?v=CDbWvEwBBxo Episode 1 - Introduction]<br /> *[http://www.youtube.com/watch?v=pypTYPaU7mM Episode 2 - Injection Attacks]<br /> *[http://www.youtube.com/watch?v=_Z9RQSnf8-g Episode 3 - Cross Site Scripting]<br /> <br /> = Participants List =<br /> * Project Lead:<br /> ** Jerry Hoff - jerry@owasp.org<br /> <br /> =Project Sponsor=<br /> <br /> [[File:Infrared-logo-small.png | link=http://www.infraredsecurity.com]]<br /> <br /> = License = <br /> The OWASP Appsec Tutorial Series is released under the Attribution-NonCommercial license.<br /> <br /> http://creativecommons.org/licenses/by-nc/3.0/</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=120001 2011-11-11T13:34:09Z

<p>Esheridan: /* Project Lead */</p> <hr /> <div>&lt;!---==== Main ====---&gt;<br /> == Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> [mailto:eric@infraredsecurity.com Eric Sheridan] is the lead and primary developer of the OWASP CSRFGuard project and a Managing Partner at [http://www.infraredsecurity.com Infrared Security]. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including CSRF Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). As Managing Partner at Infrared Security, Eric Sheridan specializes in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/Owasp-CsrfGuard-3.0.0.503.tar.gz OWASP CSRFGuard 3.0.0.503 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [[File:Infrared-logo-small.png | link=http://www.infraredsecurity.com]]<br /> <br /> &lt;!---==== Project About ====<br /> {{:Projects/OWASP CSRFGuard Project| Project About}}<br /> <br /> __NOTOC__ &lt;headertabs /&gt;----&gt;<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=120000 2011-11-11T13:33:20Z

<p>Esheridan: /* Project Lead */</p> <hr /> <div>&lt;!---==== Main ====---&gt;<br /> == Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> Eric Sheridan (mailto:eric@infraredsecurity.com) is the lead and primary developer of the OWASP CSRFGuard project and a Managing Partner at Infrared Security (http://www.infraredsecurity.com). Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including CSRF Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). As Managing Partner at Infrared Security, Eric Sheridan specializes in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/Owasp-CsrfGuard-3.0.0.503.tar.gz OWASP CSRFGuard 3.0.0.503 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [[File:Infrared-logo-small.png | link=http://www.infraredsecurity.com]]<br /> <br /> &lt;!---==== Project About ====<br /> {{:Projects/OWASP CSRFGuard Project| Project About}}<br /> <br /> __NOTOC__ &lt;headertabs /&gt;----&gt;<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=119999 2011-11-11T13:33:01Z

<p>Esheridan: /* Project Lead */</p> <hr /> <div>&lt;!---==== Main ====---&gt;<br /> == Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> Eric Sheridan [(eric@infraredsecurity.com)](mailto:eric@infraredsecurity.com) is the lead and primary developer of the OWASP CSRFGuard project and a Managing Partner at Infrared Security (http://www.infraredsecurity.com). Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including CSRF Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). As Managing Partner at Infrared Security, Eric Sheridan specializes in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/Owasp-CsrfGuard-3.0.0.503.tar.gz OWASP CSRFGuard 3.0.0.503 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [[File:Infrared-logo-small.png | link=http://www.infraredsecurity.com]]<br /> <br /> &lt;!---==== Project About ====<br /> {{:Projects/OWASP CSRFGuard Project| Project About}}<br /> <br /> __NOTOC__ &lt;headertabs /&gt;----&gt;<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_User_Manual&diff=119998 2011-11-11T13:30:36Z

<p>Esheridan: </p> <hr /> <div>= Overview =<br /> <br /> Welcome to the OWASP CSRFGuard 3 User Manual! The purpose of this article is to provide the user with guidance on obtaining, installing, deploying, and developing with the OWASP CSRFGuard library. The author's goal was to keep the User Manual informative, use to understand, and concise. If you find that one or more aspects of this document does not adhere to these goals, please me know at eric dot sheridan at owasp dot org.<br /> <br /> = Download =<br /> <br /> Users can download the latest release of OWASP CSRFGuard using one of the following links:<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/Owasp-CsrfGuard-3.0.0.503.tar.gz OWASP CSRFGuard 3.0.0.503 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> = Installation =<br /> <br /> Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps:<br /> <br /> :# Copy the Owasp.CsrfGuard.jar file to your application's classpath<br /> :# Declare CsrfGuard in your application's deployment descriptor (web.xml)<br /> :# Configure the Owasp.CsrfGuard.properties file as you see fit<br /> <br /> [[CSRFGuard_3_Installation | Click here]] for more detailed information regarding the installation of OWASP CSRFGuard.<br /> <br /> = Configuration =<br /> <br /> The minimum configuration settings that users should review include:<br /> <br /> :* Default new token landing page (org.owasp.csrfguard.NewTokenLandingPage)<br /> :* Support for Ajax and XMLHttpRequest (org.owasp.csrfguard.Ajax)<br /> :* URI resources that should not be protected (org.owasp.csrfguard.unprotected.*)<br /> :* Actions executed when an attack is detected (org.owasp.csrfguard.action.*)<br /> <br /> [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> = Token Injection =<br /> <br /> Users of OWASP CSRFGuard can inject prevention tokens into HTML using two strategies:<br /> <br /> :* JavaScript DOM Manipulation - largely automated process requiring minimal effort and is ideal for most web applications<br /> :* JSP Tag Library - provides fine grained strategy ideal for situations where automated DOM manipulation is insufficient.<br /> <br /> [[CSRFGuard_3_Token_Injection | Click here]] for more information regarding the injection of CSRF prevention tokens within your application.<br /> <br /> = Known Issues =<br /> <br /> The following is a quick bulleted list of known issues within the current release:<br /> <br /> :* No known way to inject CSRF prevention tokens into setters of document.location (ex: document.location=&quot;http://www.owasp.org&quot;;)<br /> <br /> [[Category:OWASP_CSRFGuard_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=119864 2011-11-07T21:42:28Z

<p>Esheridan: /* Project Sponsors */</p> <hr /> <div>&lt;!---==== Main ====---&gt;<br /> == Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> [http://ericsheridan.blogspot.com/ Eric Sheridan] (eric dot sheridan at owasp dot org) is the lead and primary developer of the OWASP CSRFGuard project. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). He is an Independent Application Security Consultant specializing in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/Owasp-CsrfGuard-3.0.0.503.tar.gz OWASP CSRFGuard 3.0.0.503 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [[File:Infrared-logo-small.png | link=http://www.infraredsecurity.com]]<br /> <br /> &lt;!---==== Project About ====<br /> {{:Projects/OWASP CSRFGuard Project| Project About}}<br /> <br /> __NOTOC__ &lt;headertabs /&gt;----&gt;<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=119863 2011-11-07T21:40:37Z

<p>Esheridan: /* Project Sponsors */</p> <hr /> <div>&lt;!---==== Main ====---&gt;<br /> == Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> [http://ericsheridan.blogspot.com/ Eric Sheridan] (eric dot sheridan at owasp dot org) is the lead and primary developer of the OWASP CSRFGuard project. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). He is an Independent Application Security Consultant specializing in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/Owasp-CsrfGuard-3.0.0.503.tar.gz OWASP CSRFGuard 3.0.0.503 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [[File:Infrared-logo-small.png | http://www.infraredsecurity.com]]<br /> <br /> &lt;!---==== Project About ====<br /> {{:Projects/OWASP CSRFGuard Project| Project About}}<br /> <br /> __NOTOC__ &lt;headertabs /&gt;----&gt;<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=File:Infrared-logo-small.png&diff=119862 2011-11-07T21:39:09Z

<p>Esheridan: </p> <hr /> <div></div>

Esheridan https://wiki.owasp.org/index.php?title=Category:Synapse&diff=111213 2011-05-30T22:14:44Z

<p>Esheridan: </p> <hr /> <div>&lt;!---==== Main ====---&gt;<br /> == Overview ==<br /> <br /> Welcome to the home of the Synapse project! Synapse is a code analysis tool inspired by other static analysis tools such as OWASP LAPSE, OWASP Orizon, and FlawFinder. The project &quot;compiles&quot; source code into an intermediate format called Common Abstract Syntax Tree (CAST) which is then analyzed for security problems. <br /> <br /> == Technologies ==<br /> <br /> It is developed almost entirely using C# (.NET 3.5 or greater) with minimal Java for the aforementioned &quot;compilation&quot; support. The project is currently in development form with hopes of achieving release status in the near future. A more formal project roadmap is under construction.<br /> <br /> == Project Lead ==<br /> <br /> [http://ericsheridan.blogspot.com/ Eric Sheridan] (eric dot sheridan at owasp dot org) is the owner, chief architect, and lead developer of the Synapse project. Aside from leading up Synapse, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI).<br /> <br /> == License ==<br /> <br /> Synapse is offered under the [http://www.gnu.org/licenses/gpl-3.0.html GPLv3] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Source Code ==<br /> <br /> The source code is currently hosted on Sourceforge in a single zip archive. Synapse will leverage the SVN capabilities of Sourceforge once the project layout and structure becomes more stable. The following links can be used to access the source code.<br /> <br /> [https://sourceforge.net/projects/synapsesca/ Synapse 0.1 (ALPHA)]<br /> <br /> == References ==<br /> <br /> :* [https://www.owasp.org/index.php/Category:OWASP_Orizon_Project OWASP Orizon]<br /> :* [https://www.owasp.org/index.php/OWASP_LAPSE_Project OWASP LAPSE]<br /> :* [http://www.dwheeler.com/flawfinder/ Flaw Finder]<br /> <br /> == Project Sponsors == <br /> <br /> Looking for Sponsors...</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:Synapse&diff=111212 2011-05-30T22:07:19Z

<p>Esheridan: Created page with &quot;&lt;!---==== Main ====---&gt; == Overview == Welcome to the home of the Synapse project! Synapse is a Source Code Analysis (SCA) tool inspired by other static analysis tools such as ...&quot;</p> <hr /> <div>&lt;!---==== Main ====---&gt;<br /> == Overview ==<br /> <br /> Welcome to the home of the Synapse project! Synapse is a Source Code Analysis (SCA) tool inspired by other static analysis tools such as OWASP LAPSE, OWASP Orizon, and FlawFinder. The project &quot;compiles&quot; source code into an intermediate format called Common Abstract Syntax Tree (CAST) which is then analyzed for security problems. It is developed almost entirely using C# (.NET 3.5 or greater) with minimal Java for the aforementioned &quot;compilation&quot; support. The project is currently in development form with hopes of achieving release status in the near future. A more formal project roadmap is under construction.<br /> <br /> == Project Lead ==<br /> <br /> [http://ericsheridan.blogspot.com/ Eric Sheridan] (eric dot sheridan at owasp dot org) is the owner, chief architect, and lead developer of the Synapse project. Aside from leading up Synapse, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI).<br /> <br /> == License ==<br /> <br /> Synapse is offered under the [http://www.gnu.org/licenses/gpl-3.0.html GPLv3] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Source Code ==<br /> <br /> The source code is currently hosted on Sourceforge in a single zip archive. Synapse will leverage the SVN capabilities of Sourceforge once the project layout and structure becomes more stable.<br /> <br /> [https://sourceforge.net/projects/synapsesca/ Click here] to download the Synapse source code!<br /> <br /> == References ==<br /> <br /> :* [https://www.owasp.org/index.php/Category:OWASP_Orizon_Project OWASP Orizon]<br /> :* [https://www.owasp.org/index.php/OWASP_LAPSE_Project OWASP LAPSE]<br /> :* [http://www.dwheeler.com/flawfinder/ Flaw Finder]<br /> <br /> == Project Sponsors == <br /> <br /> Looking for Sponsors...</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=111055 2011-05-25T02:11:19Z

<p>Esheridan: </p> <hr /> <div>&lt;!---==== Main ====---&gt;<br /> == Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> [http://ericsheridan.blogspot.com/ Eric Sheridan] (eric dot sheridan at owasp dot org) is the lead and primary developer of the OWASP CSRFGuard project. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). He is an Independent Application Security Consultant specializing in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/Owasp-CsrfGuard-3.0.0.503.tar.gz OWASP CSRFGuard 3.0.0.503 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> Looking for Sponsors...<br /> <br /> &lt;!---==== Project About ====<br /> {{:Projects/OWASP CSRFGuard Project| Project About}}<br /> <br /> __NOTOC__ &lt;headertabs /&gt;----&gt;<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=OWASP_Connections_Committee_-_Application_6&diff=107793 2011-03-28T23:38:17Z

<p>Esheridan: </p> <hr /> <div>[[How to Join a Committee|Click here to return to 'How to Join a Committee' page]]<br /> <br /> ----<br /> {| style=&quot;width:100%&quot; border=&quot;0&quot; align=&quot;center&quot;<br /> ! colspan=&quot;2&quot; align=&quot;center&quot; style=&quot;background:#4058A0; color:white&quot;|&lt;font color=&quot;white&quot;&gt;'''COMMITTEE APPLICATION FORM''' <br /> |-<br /> | style=&quot;width:25%; background:#7B8ABD&quot; align=&quot;center&quot;|'''Applicant's Name'''<br /> | colspan=&quot;1&quot; style=&quot;width:85%; background:#cccccc&quot; align=&quot;left&quot;|&lt;font color=&quot;black&quot;&gt;Doug Wilson<br /> |-<br /> | style=&quot;width:25%; background:#7B8ABD&quot; align=&quot;center&quot;| '''Current and past OWASP Roles''' <br /> | colspan=&quot;1&quot; style=&quot;width:85%; background:#cccccc&quot; align=&quot;left&quot;|OWASP DC co-chair, Organizer of AppSecDC, representative of OWASP at various US Government organizations<br /> |-<br /> | style=&quot;width:25%; background:#7B8ABD&quot; align=&quot;center&quot;| '''Committee Applying for''' <br /> | colspan=&quot;1&quot; style=&quot;width:85%; background:#cccccc&quot; align=&quot;left&quot;|OWASP Connection Committee<br /> |}<br /> ----<br /> <br /> <br /> ----<br /> Please be aware that for an application to be considered by the board, '''you MUST have 5 recommendations'''. <br /> An incomplete application will not be considered for vote.<br /> ----<br /> <br /> <br /> ----<br /> {| style=&quot;width:100%&quot; border=&quot;0&quot; align=&quot;center&quot;<br /> ! colspan=&quot;8&quot; align=&quot;center&quot; style=&quot;background:#4058A0; color:white&quot;|&lt;font color=&quot;white&quot;&gt;'''COMMITTEE RECOMMENDATIONS''' <br /> |- <br /> ! align=&quot;center&quot; style=&quot;background:white; color:white&quot;|&lt;font color=&quot;black&quot;&gt;<br /> ! align=&quot;center&quot; style=&quot;background:#7B8ABD; color:white&quot;|&lt;font color=&quot;black&quot;&gt;'''Who Recommends/Name''' <br /> ! align=&quot;center&quot; style=&quot;background:#7B8ABD; color:white&quot;|&lt;font color=&quot;black&quot;&gt;'''Role in OWASP'''<br /> ! align=&quot;center&quot; style=&quot;background:#7B8ABD; color:white&quot;|&lt;font color=&quot;black&quot;&gt;'''Recommendation Content''' <br /> |-<br /> | style=&quot;width:3%; background:#cccccc&quot; align=&quot;center&quot;|'''1'''<br /> | style=&quot;width:20%; background:#cccccc&quot; align=&quot;center&quot;| Mark Bristow<br /> | style=&quot;width:20%; background:#cccccc&quot; align=&quot;center&quot;| Global Conferences Committee Chair, DC Chapter Lead, AppSec DC Organizer<br /> | style=&quot;width:57%; background:#cccccc&quot; align=&quot;center&quot;| I can't think of a better person to join the Connections Committee. Doug is already spearheading government outreach, OWASP social media, and other actions to promote the organization. Would buy again A+++++++<br /> |-<br /> | style=&quot;width:3%; background:#cccccc&quot; align=&quot;center&quot;|'''2'''<br /> | style=&quot;width:20%; background:#cccccc&quot; align=&quot;center&quot;| Lorna Alamri<br /> | style=&quot;width:20%; background:#cccccc&quot; align=&quot;center&quot;| Global Industry Committee, AppSec USA 2011 Organizer<br /> | style=&quot;width:57%; background:#cccccc&quot; align=&quot;center&quot;| Doug would be a great addition to the Connections Committee. He's shown that he will jump in and make things happen and promote OWASP as an Organization.<br /> |-<br /> | style=&quot;width:3%; background:#cccccc&quot; align=&quot;center&quot;|'''3'''<br /> | style=&quot;width:20%; background:#cccccc&quot; align=&quot;center&quot;| Jim Manico<br /> | style=&quot;width:20%; background:#cccccc&quot; align=&quot;center&quot;| Connection Committee Chair, <br /> | style=&quot;width:57%; background:#cccccc&quot; align=&quot;center&quot;| We need Dougs help!<br /> |-<br /> | style=&quot;width:3%; background:#cccccc&quot; align=&quot;center&quot;|'''4'''<br /> | style=&quot;width:20%; background:#cccccc&quot; align=&quot;center&quot;| Eric Sheridan<br /> | style=&quot;width:20%; background:#cccccc&quot; align=&quot;center&quot;| Various Projects (CSRFGuard, CSRFTester, CSRF CheatSheet, etc.)<br /> | style=&quot;width:57%; background:#cccccc&quot; align=&quot;center&quot;| Doug has the ability to get things done right!<br /> |-<br /> | style=&quot;width:3%; background:#cccccc&quot; align=&quot;center&quot;|'''5'''<br /> | style=&quot;width:20%; background:#cccccc&quot; align=&quot;center&quot;|<br /> | style=&quot;width:20%; background:#cccccc&quot; align=&quot;center&quot;|<br /> | style=&quot;width:57%; background:#cccccc&quot; align=&quot;center&quot;|<br /> |}<br /> ----</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_User_Manual&diff=105349 2011-02-17T17:43:53Z

<p>Esheridan: /* Download */</p> <hr /> <div>= Overview =<br /> <br /> Welcome to the OWASP CSRFGuard 3 User Manual! The purpose of this article is to provide the user with guidance on obtaining, installing, deploying, and developing with the OWASP CSRFGuard library. The author's goal was to keep the User Manual informative, use to understand, and concise. If you find that one or more aspects of this document does not adhere to these goals, please me know at eric dot sheridan at owasp dot org.<br /> <br /> = Download =<br /> <br /> Users can download the latest release of OWASP CSRFGuard using one of the following links:<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/Owasp-CsrfGuard-3.0.0.503.tar.gz OWASP CSRFGuard 3.0.0.503 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> = Installation =<br /> <br /> Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps:<br /> <br /> :# Copy the Owasp.CsrfGuard.jar file to your application's classpath<br /> :# Declare CsrfGuard in your application's deployment descriptor (web.xml)<br /> :# Configure the Owasp.CsrfGuard.properties file as you see fit<br /> <br /> [[CSRFGuard_3_Installation | Click here]] for more detailed information regarding the installation of OWASP CSRFGuard.<br /> <br /> = Configuration =<br /> <br /> The minimum configuration settings that users should review include:<br /> <br /> :* Default new token landing page (org.owasp.csrfguard.NewTokenLandingPage)<br /> :* Support for Ajax and XMLHttpRequest (org.owasp.csrfguard.Ajax)<br /> :* URI resources that should not be protected (org.owasp.csrfguard.unprotected.*)<br /> :* Actions executed when an attack is detected (org.owasp.csrfguard.action.*)<br /> <br /> [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> = Token Injection =<br /> <br /> Users of OWASP CSRFGuard can inject prevention tokens into HTML using two strategies:<br /> <br /> :* JavaScript DOM Manipulation - largely automated process requiring minimal effort and is ideal for most web applications<br /> :* JSP Tag Library - provides fine grained strategy ideal for situations where automated DOM manipulation is insufficient.<br /> <br /> [[CSRFGuard_3_Token_Injection | Click here]] for more information regarding the injection of CSRF prevention tokens within your application.<br /> <br /> = Known Issues =<br /> <br /> The following is a quick bulleted list of known issues within the current release:<br /> <br /> :* No known way to inject CSRF prevention tokens into setters of document.location (ex: document.location=&quot;http://www.owasp.org&quot;;)<br /> :* Tokens are not injected into HTML elements dynamically generated using JavaScript &quot;createElement&quot; and &quot;setAttribute&quot;<br /> <br /> [[Category:OWASP_CSRFGuard_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=105347 2011-02-17T17:43:30Z

<p>Esheridan: /* Downloads */</p> <hr /> <div>== Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> [http://ericsheridan.blogspot.com/ Eric Sheridan] (eric dot sheridan at owasp dot org) is the lead and primary developer of the OWASP CSRFGuard project. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). He is an Independent Application Security Consultant specializing in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/Owasp-CsrfGuard-3.0.0.503.tar.gz OWASP CSRFGuard 3.0.0.503 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_Configuration&diff=104953 2011-02-12T17:47:59Z

<p>Esheridan: /* New Token Landing Page */</p> <hr /> <div>= Overview =<br /> <br /> The most important aspect of deploying OWASP CSRFGuard is configuration of the Owasp.CsrfGuard.properties file. There are a minimum number of configuration settings that users should review and specify before running an instance of OWASP CSRFGuard. Such configurations include specifying the new token landing page, enabling Ajax support for applications making use of XMLHttpRequest, capturing pages that should not be protected, as well as configuring one or more actions that should be invoked when a CSRF attack is identified. The purpose of this article is to provide an overview of key OWASP CSRFGuard configuration settings.<br /> <br /> = Logger =<br /> <br /> The logger property (org.owasp.csrfguard.Logger) defines the qualified class name of the object responsible for processing all log messages produced by CSRFGuard. The default CSRFGuard logger is org.owasp.csrfguard.log.ConsoleLogger. This class logs all messages to System.out which JavaEE application servers redirect to a vendor specific log file. Developers can customize the logging behavior of CSRFGuard by implementing the org.owasp.csrfguard.log.ILogger interface and setting the logger property to the new logger's qualified class name. The following configuration snippet instructs OWASP CSRFGuard to capture all log messages to the console:<br /> <br /> org.owasp.csrfguard.Logger=org.owasp.csrfguard.log.ConsoleLogger<br /> <br /> = New Token Landing Page =<br /> <br /> The new token landing page property (org.owasp.csrfguard.NewTokenLandingPage) defines where to send a user if the token is being generated for the first time. This request is generated using auto-posting forms and will only contain the CSRF prevention token parameter, if applicable. All query-string or form parameters sent with the original request will be discarded. If this property is not defined, CSRFGuard will instead auto-post the user to the original context and servlet path. The following configuration snippet instructs OWASP CSRFGuard to redirect the user to /Owasp.CsrfGuard.Test/index.html when the user visits a protected resource without having a corresponding CSRF token present in the HttpSession object:<br /> <br /> org.owasp.csrfguard.NewTokenLandingPage=/Owasp.CsrfGuard.Test/index.html<br /> <br /> = Unique Token Per Page =<br /> <br /> The unique token per-page property (org.owasp.csrfguard.TokenPerPage) is a boolean value that determines if CSRFGuard should make use of unique per-page (i.e. URI) prevention tokens as opposed to unique per-session prevention tokens. When a user requests a protected resource, CSRFGuard will determine if a page specific token has been previously generated. If a page specific token has not yet been previously generated, CSRFGuard will verify the request was submitted with the per-session token intact. After verifying the presence of the per-session token, CSRFGuard will create a page specific token that is required for all subsequent requests to the associated resource. The per-session CSRF token can only be used when requesting a resource for the first time. All subsequent requests must have the per-page token intact or the request will be treated as a CSRF attack. Use of the unique token per page property is currently experimental but provides a significant amount of improved security. Consider the exposure of a CSRF token using the legacy unique per-session model. Exposure of this token facilitates the attacker's ability to carry out a CSRF attack against the victim's active session for any resource exposed by the web application. Now consider the exposure of a CSRF token using the experimental unique token per-page model. Exposure of this token would only allow the attacker to carry out a CSRF attack against the victim's active session for a small subset of resources exposed by the web application. Use of the unique token per-page property is a strong defense in depth strategy significantly reducing the impact of exposed CSRF prevention tokens. The following configuration snippet instructs OWASP CSRFGuard to utilize the unique token per-page model:<br /> <br /> org.owasp.csrfguard.TokenPerPage=true<br /> <br /> = Token Rotation =<br /> <br /> The rotate token property (org.owasp.csrfguard.Rotate) is a boolean value that determines if CSRFGuard should generate and utilize a new token after verifying the previous token. Rotation helps minimize the window of opportunity an attacker has to leverage the victim's stolen token in a targeted CSRF attack. However, this functionality generally causes navigation problems in most applications. Specifically, the 'Back' button in the browser will often cease to function properly. When a user hits the 'Back' button and interacts with the HTML, the browser may submit an old token causing CSRFGuard to incorrectly believe this request is a CSRF attack in progress (i.e. a 'false positive'). Users can prevent this scenario by preventing the caching of HTML pages containing FORM submissions using the cache-control header. However, this may also introduce performance problems as the browser will have to request HTML on a more frequent basis. The following configuration snippet disables token rotation:<br /> org.owasp.csrfguard.Rotate=false<br /> <br /> = Ajax and XMLHttpRequest Support =<br /> <br /> The Ajax property (org.owasp.csrfguard.Ajax) is a boolean value that indicates whether or not OWASP CSRFGuard should support the injection and verification of unique per-session prevention tokens for XMLHttpRequests. To leverage Ajax support, the user must not only set this property to true but must also reference the [[CSRFGuard_3_Token_Injection#JavaScript_DOM_Manipulation | JavaScript DOM Manipulation]] code using a script element. This dynamic script will override the send method of the XMLHttpRequest object to ensure the submission of an X-Requested-With header name value pair coupled with the submission of a custom header name value pair for each request. The name of the custom header is the value of the token name property and the value of the header is always the unique per-session token value. This custom header is analogous to the HTTP parameter name value pairs submitted via traditional GET and POST requests. If the X-Requested-With header was sent in the HTTP request, then CSRFGuard will look for the presence and ensure the validity of the unique per-session token in the custom header name value pair. Note that verification of these headers takes precedence over verification of the CSRF token supplied as an HTTP parameter. More specifically, CSRFGuard does not verify the presence of the CSRF token if the Ajax support property is enabled and the corresponding X-Requested-With and custom headers are embedded within the request. The following configuration snippet instructs OWASP CSRFGuard to support Ajax requests by verifying the presence and correctness of the X-Requested-With and custom headers:<br /> <br /> org.owasp.csrfguard.Ajax=true<br /> <br /> = Unprotected Pages =<br /> <br /> The unprotected pages property (org.owasp.csrfguard.unprotected.*) defines a series of pages that should not be protected by CSRFGuard. Such configurations are useful when the CsrfGuardFilter is aggressively mapped (ex: /*). The syntax of the property name is org.owasp.csrfguard.unprotected.[PageName], where PageName is some arbitrary identifier that can be used to reference a resource. The syntax of defining the uri of unprotected pages is the same as the syntax used by the JavaEE container for uri mapping. Specifically, CSRFGuard will identify the first match (if any) between the requested uri and an unprotected page in order of declaration. Match criteria is as follows:<br /> <br /> :Case 1: exact match between request uri and unprotected page<br /> :Case 2: longest path prefix match, beginning / and ending /*<br /> :Case 3: extension match, beginning *.<br /> :Default: requested resource must be validated by CSRFGuard<br /> <br /> The following code snippet illustrates the three use cases over four examples. The first two examples (Tag and JavaScriptServlet) look for direct URI matches. The third example (Html) looks for all resources ending in a .html extension. The last example (Public) looks for all resources prefixed with the URI path /MySite/Public/*.<br /> <br /> org.owasp.csrfguard.unprotected.Tag=/Owasp.CsrfGuard.Test/tag.jsp<br /> org.owasp.csrfguard.unprotected.JavaScriptServlet=/Owasp.CsrfGuard.Test/JavaScriptServlet<br /> org.owasp.csrfguard.unprotected.Html=*.html<br /> org.owasp.csrfguard.unprotected.Public=/MySite/Public/*<br /> <br /> = Actions: Responding to Attacks =<br /> <br /> The actions directive (org.owasp.csrfguard.action.*) gives the user the ability to specify one or more actions that should be invoked when a CSRF attack is detected. Every action must implement the org.owasp.csrfguard.action.IAction interface either directly or indirectly through the org.owasp.csrfguard.action.AbstractAction helper class. Many actions accept parameters that can be specified along with the action class declaration. These parameters are consumed at runtime and impact the behavior of the associated action.<br /> <br /> The syntax for defining and configuring CSRFGuard actions is relatively straight forward. Let us assume we wish to redirect the user to a default page when a CSRF attack is detected. A redirect action already exists within the CSRFGuard bundle and is available via the class name org.owasp.csrfguard.actions.Redirect. In order to enable this action, we capture the following declaration in the Owasp.CsrfGuard.properties file:<br /> <br /> '''syntax:''' org.owasp.csrfguard.action.[actionName]=[className]<br /> '''example:''' org.owasp.csrfguard.action.class.Redirect=org.owasp.csrfguard.actions.Redirect<br /> <br /> The aforementioned directive declares an action called &quot;Redirect&quot; (i.e. [actionName]) referencing the Java class &quot;org.owasp.csrfguard.actions.Redirect&quot; (i.e. [className]). Anytime a CSRF attack is detected, the Redirect action will be executed. You may be asking yourself, &quot;but how do I specify where the user is redirected?&quot;; this is where action parameters come into play. In order to specify the redirect location, we capture the following declaration in the Owasp.CsrfGuard.properties file:<br /> <br /> '''syntax:''' org.owasp.csrfguard.action.[actionName].[parameterName]=[parameterValue]<br /> '''example:''' org.owasp.csrfguard.action.Redirect.ErrorPage=/Owasp.CsrfGuard.Test/error.html<br /> <br /> The aforementioned directive declares an action parameter called &quot;ErrorPage&quot; (i.e. [parameterName]) with the value of &quot;/Owasp.CsrfGuard.Test/error.html&quot; (i.e. [parameterValue]) for the action &quot;Redirect&quot; (i.e. [actionName]). The Redirect action expects the &quot;ErrorPage&quot; parameter to be defined and will redirect the user to this location when an attack is detected.<br /> <br /> There are several &quot;out of the box&quot; actions made available with the OWASP CSRFGuard distributable. <br /> <br /> == org.owasp.csrfguard.action.Log ==<br /> <br /> Creates a customized log message whenever a CSRF attack is detected by OWASP CSRFGuard. The log message is captured using the logger mechanism defined by the ''org.owasp.csrfguard.Logger'' directive in the Owasp.CsrfGuard.properties file. Log accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.Log.Message'''<br /> <br /> Allows the user to define the format of the log message to be recorded. The Message parameter supports several formatting options to aide in the customization of the message to the particular attack. The following formatting options are supported:<br /> <br /> '''%exception%''' - String representation of the CsrfGuardException thrown by the CsrfGuard class.<br /> '''%exception_message%''' - Localized exception message of the class CsrfGuardException thrown by the CsrfGuard class.<br /> '''%remote_ip%''' - Remote IP address of the client that sent the CSRF attack to the server.<br /> '''%remote_host%''' - Remote host name of the client that sent the CSRF attack to the server.<br /> '''%remote_port%''' - Remote port of the client that sent the CSRF attack to the server.<br /> '''%local_ip%''' - Local IP address of the server that detected the CSRF attack.<br /> '''%local_host%''' - Local host name of the server that detected the CSRF attack.<br /> '''%local_port%''' - Local port of the server that detected the CSRF attack.<br /> '''%request_uri%''' - Request URI for which the CSRF attack was targeting.<br /> '''%request_url%''' - Request URL for which the CSRF attack was targeting.<br /> '''%user%''' - User information as made available by the javax.servlet.http.HttpServletRequest.getRemoteUser() method invocation.<br /> <br /> == org.owasp.csrfguard.action.Invalidate ==<br /> <br /> Invalidate any existing HttpSession associated with the current HttpServletRequest. Note that this is the session of the victim for which the CSRF attack was targeting. Invalidating the JavaEE container's session generally results in the user having to re-authenticate. There are no parameters associated with this action.<br /> <br /> == org.owasp.csrfguard.action.Redirect ==<br /> <br /> Redirects the user to the URI specified in the Page action parameter. Attempting to utilize this action in combination with Forward will generally result in the JavaEE container throwing IllegalStateException. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.Redirect.Page'''<br /> <br /> Defines the URI for which the user is redirected when a CSRF attack is detected.<br /> <br /> == org.owasp.csrfguard.action.Forward ==<br /> <br /> Forwards the user to the URI specified in the Page action parameter. Attempting to utilize this action in combination with Redirect will generally result in the JavaEE container throwing IllegalStateException. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.Forward.Page'''<br /> <br /> Defines the URI for which the user is forwarded when a CSRF attack is detected.<br /> <br /> == org.owasp.csrfguard.action.RequestAttribute ==<br /> <br /> Makes the CsrfGuardException thrown by the CsrfGuard class when an attack is detected programmatically available as an attribute in the HttpServletRequest object. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.RequestAttribute.AttributeName'''<br /> <br /> Defines the attribute name that should be used when placing the CsrfGuardException in the HttpServletRequest attributes collection.<br /> <br /> == org.owasp.csrfguard.action.SessionAttribute ==<br /> <br /> Makes the CsrfGuardException thrown by the CsrfGuard class when an attack is detected programmatically available as an attribute in the HttpSession object. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.SessionAttribute.AttributeName'''<br /> <br /> Defines the attribute name that should be used when placing the CsrfGuardException in the HttpSession attributes collection.<br /> <br /> == org.owasp.csrfguard.action.Rotate ==<br /> <br /> Invalidates and re-generates any existing CSRF prevention tokens associated with the current HttpSession. This action helps minimize the risk of a malicious user attempting to brute force a user's prevention tokens through timing based side channel attacks. Note that this action has no effect when used in conjunction with the Invalidate action. There are no parameters associated with this action.<br /> <br /> = Miscellaneous Configurations =<br /> <br /> == Token Name ==<br /> <br /> The token name property (org.owasp.csrfguard.TokenName) defines the name of the HTTP parameter to contain the value of the OWASP CSRFGuard token for each request. The following configuration snippet sets the CSRFGuard token parameter name to the value OWASP_CSRFTOKEN:<br /> org.owasp.csrfguard.TokenName=OWASP_CSRFTOKEN<br /> <br /> == Session Key ==<br /> <br /> The session key property (org.owasp.csrfguard.SessionKey) defines the string literal used to save and lookup the CSRFGuard token from the session. This value is used by the filter and the tag libraries to retrieve and set the token value in the session. Developers can use this key to programmatically lookup the token within their own code. The following configuration snippet sets the session key to the value OWASP_CSRFTOKEN:<br /> org.owasp.csrfguard.SessionKey=OWASP_CSRFTOKEN<br /> <br /> == Token Length ==<br /> <br /> The token length property (org.owasp.csrfguard.TokenLength) defines the number of characters that should be found within the CSRFGuard token. Note that characters are delimited by dashes (-) in groups of four. For cosmetic reasons, users are encourage to ensure the token length is divisible by four. The following configuration snippet sets the token length property to 32 characters:<br /> org.owasp.csrfguard.TokenLength=32<br /> <br /> == Pseudo-Random Number Generator ==<br /> <br /> The pseudo-random number generator property (org.owasp.csrfguard.PRNG) defines what PRNG should be used to generate the OWASP CSRFGuard token. Always ensure this value references a cryptographically strong pseudo-random number generator algorithm. The following configuration snippet sets the pseudo-random number generator to SHA1PRNG:<br /> org.owasp.csrfguard.PRNG=SHA1PRNG<br /> <br /> [[Category:OWASP CSRFGuard Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_Token_Injection&diff=104952 2011-02-12T17:45:47Z

<p>Esheridan: </p> <hr /> <div>= Overview =<br /> <br /> OWASP CSRFGuard implements a variant of the synchronizer token pattern to mitigate the risk of CSRF attacks. In order to implement this pattern, CSRFGuard must offer the capability to place the CSRF prevention token within the HTML produced by the protected web application. CSRFGuard 3 provides developers more fine grain control over the injection of the token. Developers can inject the token in their HTML using either dynamic JavaScript DOM manipulation or a JSP tag library. CSRFGuard no longer intercepts and modifies the HttpServletResponse object as was done in previous releases. The currently available token injection strategies are designed to make the integration of CSRFGuard more feasible and scalable within current enterprise web applications. Developers are encouraged to make use of both the JavaScript DOM Manipulation and the JSP tag library strategies for a complete token injection strategy. The JavaScript DOM Manipulation strategy is ideal as it is automated and requires minimal effort on behalf of the developer. In the event the JavaScript solution is insufficient within a particular application context, developers should leverage the JSP tag library. The purpose of this article is to describe the token injection strategies offered by OWASP CSRFGuard 3.<br /> <br /> = JavaScript DOM Manipulation =<br /> <br /> OWASP CSRFGuard 3 supports the ability to dynamically inject CSRF prevention tokens throughout the DOM currently loaded in the user's browser. This strategy is extremely valuable with regards to server-side performance as it simply requires the serving of a dynamic JavaScript file. There is little to no performance hit when the fetched dynamic JavaScript updates the browser's DOM. Making use of the JavaScript token injection solution requires the developer map a Servlet and place a JavaScript HTML tag within all pages sending requests to protected application resources. Developers are strongly encouraged to leverage the JavaScript token injection strategy by default. This strategy requires minimal effort on behalf of the developer as most of the token injection logic is automated. In the event that the JavaScript automated solution may be insufficient for a specific application context, developers should leverage the OWASP CSRFGuard JSP tag library.<br /> <br /> '''Note:''' Use of JavaScript DOM Manipulation is required for Ajax support.<br /> <br /> == Declare and Configure JavaScriptServlet ==<br /> <br /> The JavaScript file used for token injection is dynamically generated by the JavaScriptServlet class using a template file. Ensure that the Owasp.CsrfGuard.jar file is found within the target application's classpath. Copy the Owasp.CsrfGuard.js template file from the OWASP CSRFGuard distribution folder to a non-publicly accessible directory within the target application. For the remainder of this section, we assume the Owasp.CsrfGuard.js template file was placed in the application's WEB-INF folder. Edit the deployment descriptor (web.xml) to declare the JavaScriptServlet class along with any associated initialization parameters. Consider the following configuration snippet taken from the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;servlet-class&gt;org.owasp.csrfguard.servlet.JavaScriptServlet&lt;/servlet-class&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;source-file&lt;/param-name&gt;<br /> &lt;param-value&gt;WEB-INF/Owasp.CsrfGuard.js&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-forms&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-attributes&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;domain-strict&lt;/param-name&gt;<br /> &lt;param-value&gt;false&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;referer-pattern&lt;/param-name&gt;<br /> &lt;param-value&gt;.*localhost.*&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;/servlet&gt;<br /> <br /> The aforementioned configuration snippet declares the JavaScriptServlet class using the name &quot;JavaScriptServlet&quot;. JavaScriptServlet accepts various initialization parameters augmenting the behavior of the class at runtime. The provided configuration snippet instructs JavaScriptServlet to...<br /> <br /> #Leverage the template JavaScript file at WEB-INF/Owasp.CsrfGuard.js<br /> #Inject the token into all HTML forms<br /> #Inject the token into all src and href attributes<br /> #Leverage loose same origin matching criteria when placing the token in URL resources<br /> <br /> Consider the following for a more detailed listing of the initialization parameters supported by JavaScriptServlet:<br /> <br /> source-file<br /> <br /> Denotes the location of the JavaScript template file that should be consumed and dynamically augmented by the JavaScriptServlet class. The default value is WEB-INF/Owasp.CsrfGuard.js. Use of this property and the existence of the specified template file is required. <br /> <br /> domain-strict<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should be strict with regards to what links it should inject the CSRF prevention token. With a value of true, the JavaScript code will only place the token in links that point to the same exact domain from which the HTML originated. With a value of false, the JavaScript code will place the token in links that not only point to the same exact domain from which the HTML originated, but sub-domains as well.<br /> <br /> referer-pattern<br /> <br /> Allows the developer to specify a regular expression describing the required value of the Referer header. Any attempts to access the servlet with a Referer header that does not match the captured expression is discarded. Inclusion of referer header checking is to help minimize the risk of JavaScript Hijacking attacks that attempt to steal tokens from the dynamically generated JavaScript. While the primary defenses against JavaScript Hijacking attacks are implemented within the dynamic JavaScript itself, referer header checking is implemented to achieve defense in depth.<br /> <br /> cache-control<br /> <br /> Allows the developer to specify the value of the Cache-Control header in the HTTP response when serving the dynamic JavaScript file. The default value is private, maxage=28800. Caching of the dynamic JavaScript file is intended to minimize traffic and improve performance. Note that the Cache-Control header is always set to &quot;no-store&quot; when either the &quot;Rotate&quot; &quot;TokenPerPage&quot; options is set to true in Owasp.CsrfGuard.properties.<br /> <br /> inject-into-forms<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token as a hidden field into HTML forms. The default value is true. Developers are strongly discouraged from disabling this property as most server-side state changing actions are triggered via a POST request.<br /> <br /> inject-into-attributes<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token in the query string of src and href attributes. Injecting the CSRF prevention token in a URL resource increases its general risk of exposure to unauthorized parties. However, most JavaEE web applications respond in the exact same manner to HTTP requests and their associated parameters regardless of the HTTP method. The risk associated with not protecting GET requests in this situation is perceived greater than the risk of exposing the token in protected GET requests. As a result, the default value of this attribute is set to true. Developers that are confident their server-side state changing controllers will only respond to POST requests (i.e. discarding GET requests) are strongly encouraged to disable this property.<br /> <br /> == Map JavaScriptServlet ==<br /> <br /> Developers must map the JavaScriptServlet to a URI space such that the Servlet class can be remotely accessed by the dynamic JavaScript code. Consider the following configuration snippet taken directly from the [hhttps://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet-mapping&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;url-pattern&gt;/JavaScriptServlet&lt;/url-pattern&gt;<br /> &lt;/servlet-mapping&gt;<br /> <br /> The aforementioned configuration snippet maps the Servlet referenced by the name &quot;JavaScriptServlet&quot; to the URI space &quot;/JavaScriptServlet&quot;. Any request sent to the /JavaScriptServlet URI will produce a dynamically generated CSRFGuard JavaScript file specific to the user's current session.<br /> <br /> == Inject Dynamic JavaScript ==<br /> <br /> Developers are required to place an HTML script tag within all pages that are known to send requests to CSRF protected resources. All requests within the current HTML page are augmented to ensure they submit the correct CSRF token for the user's current session. Note that inclusion of the dynamic JavaScript does not protect the current page. Rather, the script ensures the CSRF token is transmitted within all requests generated by the current page. Consider the following code snippet taken directly from the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;!-- OWASP CSRFGuard Support --&gt;<br /> &lt;script src=&quot;/Owasp.CsrfGuard.Test/JavaScriptServlet&quot;&gt;&lt;/script&gt;<br /> <br /> The script tag retrieves and executes the dynamically generated JavaScript from the Servlet mapped at /Owasp.CsrfGuard.Test/JavaScriptServlet. This JavaScript code will register an event handler with window.onload. Once triggered, the code will iterate over every HTML element within the DOM looking for either form tags and or tags containing href or src attributes as configured by the JavaScriptServlet initialization parameters. Forms are dynamically updated to include the CSRFGuard token via a hidden field and tags using src and href attributes are updated to include the CSRFGuard token via a query string parameter.<br /> <br /> = JSP Tag Library =<br /> <br /> OWASP CSRFGuard 3 exposes a JSP tag library providing developers more fine grain control over token injection. The library exposes JSP tags that allow access to the token name, the token value, and the token name value pair delimited by an equals (=) sign. In order to make use of the tag library, ensure the Owasp.CsrfGuard.jar file is found within the target application's classpath. For example, the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application places the OWASP CSRFGuard jar file within the WebContent/WEB-INF/lib directory. After placing the library in the classpath, developers can reference the tags in JSP pages using predefined URI reference. The following JSP code snippet imports the tag library and makes it available using the prefix &quot;csrf&quot;:<br /> <br /> &lt;%@ taglib uri=&quot;http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project/Owasp.CsrfGuard.tld&quot; prefix=&quot;csrf&quot; %&gt;<br /> <br /> The benefit of using the JSP tag library to inject the CSRF prevention token is the fine grain level of control. Developers can place the token in all the correct locations within the context of their applications. This strategy is useful in application contexts where the JavaScript DOM Manipulation strategy is insufficient.<br /> <br /> == Display Token Name ==<br /> <br /> The OWASP CSRFGuard token name can be obtained through the token-name tag. The token-name tag is useful when injecting the CSRFGuard token name in a non-query string context. Consider the following code snippet taken from the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-name tag to reference the token name in the name attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;'''&lt;csrf:token-name/&gt;'''&quot; value=&quot;&lt;csrf:token-value/&gt;&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Value ==<br /> <br /> The OWASP CSRFGuard token value can be obtained through the token-value tag. The token-value tag is useful when injecting the CSRFGuard token value in a non-query string context. Consider the following code snippet taken from the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-value tag to reference the token value in the value attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;&lt;csrf:token-name/&gt;&quot; value=&quot;'''&lt;csrf:token-value/&gt;'''&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> The token value tag must be used in conjunction with the URI attribute when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The value of the uri attribute is the URI for which the token value will be posted. Consider the following example which sets the URI to the destination of the form, &quot;protect.html&quot;:<br /> <br /> &lt;form id=&quot;formTest1&quot; name=&quot;formTest1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;&lt;csrf:token-name/&gt;&quot; value=&quot;&lt;csrf:token-value uri=&quot;protect.html&quot;/&gt;&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Name Value Pair ==<br /> <br /> The OWASP CSRFGuard token name value pair, delimited by an equals sign (=), can be obtained though the token tag. The token tag is useful when injecting the CSRFGuard token value in a query string context. Consider the following code snippet taken from the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token tag to reference the token name value pair in the href attribute of an anchor tag:<br /> <br /> &lt;a href=&quot;protect.html?&lt;csrf:token/&gt;&quot;&gt;protect.html&lt;/a&gt;<br /> <br /> The token name value pair tag must be used in conjunction with the URI attribute when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The value of the uri attribute is the URI for which the token value will be posted. Consider the following example which sets the URI to the destination of the link, &quot;protect.html&quot;:<br /> <br /> &lt;a href=&quot;protect.html?&lt;csrf:token uri=&quot;protect.html&quot;/&gt;&quot;&gt;protect.html&lt;/a&gt;<br /> <br /> == Generate Form with Prevention Token ==<br /> <br /> The OWASP CSRFGuard JSP library implements a tag library designed specifically to generate HTML forms with the CSRF prevention token automatically embedded as a hidden field. This strategy simplifies the integration of the CSRF token, especially when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The tag accepts dynamic attribute name value pairs and simply outputs them to the page. As a result, you are free to use the same attribute values made available in a standard HTML form. There is no special output encoding performed on these dynamic attributes. Take care to perform the appropriate validation and output encoding for all dynamic attributes used in conjunction with untrusted data. Consider the following code snippet which will produce a HTML form with an embedded CSRF token. No special care must be taken when using this flag in conjunction with the unique token per uri model:<br /> <br /> &lt;csrf:form id=&quot;formTest2&quot; name=&quot;formTest2&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;/csrf:form&gt;<br /> <br /> == Generate Link with Prevention Token ==<br /> <br /> The OWASP CSRFGuard JSP library implements a tag library designed specifically to generate HTML anchor tags with the CSRF prevention token automatically embedded as a query string parameter. This strategy simplifies the integration of the CSRF token, especially when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The tag accepts dynamic attribute name value pairs and simply outputs them to the page. As a result, you are free to use the same attribute values made available in a standard HTML anchor. There is no special output encoding performed on these dynamic attributes. Take care to perform the appropriate validation and output encoding for all dynamic attributes used in conjunction with untrusted data. Consider the following code snippet which will produce a HTML anchor tag with an embedded CSRF token. No special care must be taken when using this flag in conjunction with the unique token per uri model:<br /> <br /> &lt;csrf:a href=&quot;protect.html&quot;&gt;protect.html&lt;/csrf:a&gt;</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_User_Manual&diff=104951 2011-02-12T17:43:52Z

<p>Esheridan: /* Installation */</p> <hr /> <div>= Overview =<br /> <br /> Welcome to the OWASP CSRFGuard 3 User Manual! The purpose of this article is to provide the user with guidance on obtaining, installing, deploying, and developing with the OWASP CSRFGuard library. The author's goal was to keep the User Manual informative, use to understand, and concise. If you find that one or more aspects of this document does not adhere to these goals, please me know at eric dot sheridan at owasp dot org.<br /> <br /> = Download =<br /> <br /> Users can download the latest release of OWASP CSRFGuard using one of the following links:<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/OWASP-CSRFGuard-3.0.0.499.tar.gz OWASP CSRFGuard 3.0.0.499 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> = Installation =<br /> <br /> Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps:<br /> <br /> :# Copy the Owasp.CsrfGuard.jar file to your application's classpath<br /> :# Declare CsrfGuard in your application's deployment descriptor (web.xml)<br /> :# Configure the Owasp.CsrfGuard.properties file as you see fit<br /> <br /> [[CSRFGuard_3_Installation | Click here]] for more detailed information regarding the installation of OWASP CSRFGuard.<br /> <br /> = Configuration =<br /> <br /> The minimum configuration settings that users should review include:<br /> <br /> :* Default new token landing page (org.owasp.csrfguard.NewTokenLandingPage)<br /> :* Support for Ajax and XMLHttpRequest (org.owasp.csrfguard.Ajax)<br /> :* URI resources that should not be protected (org.owasp.csrfguard.unprotected.*)<br /> :* Actions executed when an attack is detected (org.owasp.csrfguard.action.*)<br /> <br /> [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> = Token Injection =<br /> <br /> Users of OWASP CSRFGuard can inject prevention tokens into HTML using two strategies:<br /> <br /> :* JavaScript DOM Manipulation - largely automated process requiring minimal effort and is ideal for most web applications<br /> :* JSP Tag Library - provides fine grained strategy ideal for situations where automated DOM manipulation is insufficient.<br /> <br /> [[CSRFGuard_3_Token_Injection | Click here]] for more information regarding the injection of CSRF prevention tokens within your application.<br /> <br /> = Known Issues =<br /> <br /> The following is a quick bulleted list of known issues within the current release:<br /> <br /> :* No known way to inject CSRF prevention tokens into setters of document.location (ex: document.location=&quot;http://www.owasp.org&quot;;)<br /> :* Tokens are not injected into HTML elements dynamically generated using JavaScript &quot;createElement&quot; and &quot;setAttribute&quot;<br /> <br /> [[Category:OWASP_CSRFGuard_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_Installation&diff=104950 2011-02-12T17:41:49Z

<p>Esheridan: /* Declare CsrfGuard in Deployment Descriptor */</p> <hr /> <div>= Overview =<br /> <br /> The purpose of this article is to provide guidance around the installation of OWASP CSRFGuard within a JavaEE web application. Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps. First, you must copy the Owasp.CsrfGuard.jar file to your application's classpath. After copying over the OWASP CSRFGuard library, declare and map the CsrfGuardFilter in your application's web.xml deployment descriptor. This instructs the application server to initialize the OWASP CSRFGuard Filter protecting those resources that match the Filter mapping. Finally, customize the Owasp.CsrfGuard.properties file as you see fit. You'll need to make sure you tell CsrfGuardFilter the location of your CSRFGuard properties file via a JavaEE Filter init-param directive. Please refer to the following sub-sections for more detailed information on each of the aforementioned installation steps.<br /> <br /> = Copy Owasp.CsrfGuard.jar to Classpath =<br /> <br /> The first thing you need to do is copy the Owasp.CsrfGuard.jar library into your classpath. The most common classpath location to place Owasp.CsrfGuard.jar is within the lib directory of the web application's WEB-INF folder. OWASP CSRFGuard 3 has no additional dependencies outside of the traditional JavaEE runtime environment.<br /> <br /> = Declare CsrfGuard in Deployment Descriptor =<br /> <br /> After placing Owasp.CsrfGuard.jar in your application's classpath, you'll need to declare CsrfGuard context parameters along with a HttpSessionListener and a Filter. The following web.xml snippet was extracted from the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] web application:<br /> <br /> &lt;context-param&gt;<br /> &lt;param-name&gt;Owasp.CsrfGuard.Config&lt;/param-name&gt;<br /> &lt;param-value&gt;WEB-INF/Owasp.CsrfGuard.properties&lt;/param-value&gt;<br /> &lt;/context-param&gt;<br /> <br /> &lt;context-param&gt;<br /> &lt;param-name&gt;Owasp.CsrfGuard.Config.Print&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/context-param&gt;<br /> <br /> &lt;listener&gt;<br /> &lt;listener-class&gt;org.owasp.csrfguard.CsrfGuardListener&lt;/listener-class&gt;<br /> &lt;/listener&gt;<br /> <br /> The code snippet defines two context parameters: Owasp.CsrfGuard.Config and Owasp.CsrfGuard.Config.Print. The Owasp.CsrfGuard.Config parameter is required and specifies the location of the CSRFGuard properties file. CSRFGuard will search for the properties file specified by searching the following locations in order of appearance: the application's classpath, a directory accessible by the container, or an arbitrary absolute path. The Owasp.CsrfGuard.Config.Print parameter is optional and simply instructs CSRFGuard to display the parsed properties to the application server log file. Finally, we declare and enable the CSRFGuard HttpSessionListener with a class name of org.owasp.csrfguard.CsrfGuardListener. The CsrfGuardListener class is responsible for consuming context parameters and initializing CsrfGuard context for all newly created HttpSessions.<br /> <br /> Now that we have the CsrfGuard context initialization facilities in place, we'll need to declare and map the enforcement mechanism: CsrfGuardFilter. CsrfGuardFilter is responsible for facilitating the integration of the CsrfGuard object and associated token verification logic within the JavaEE web application. The following web.xml snippet was extracted from the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] web application:<br /> <br /> &lt;filter&gt;<br /> &lt;filter-name&gt;CSRFGuard&lt;/filter-name&gt;<br /> &lt;filter-class&gt;org.owasp.csrfguard.CsrfGuardFilter&lt;/filter-class&gt;<br /> &lt;/filter&gt;<br /> &lt;filter-mapping&gt;<br /> &lt;filter-name&gt;CSRFGuard&lt;/filter-name&gt; <br /> &lt;url-pattern&gt;/*&lt;/url-pattern&gt;<br /> &lt;/filter-mapping&gt;<br /> <br /> We create a filter with the name of CSRFGuard and specify a classname of org.owasp.csrfguard.CsrfGuardFilter. At this point, we need to mapp the CSRFGuard Filter to all resources that we want to protect from attack. The following web.xml snippet was extracted from the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] web application:<br /> <br /> &lt;filter-mapping&gt;<br /> &lt;filter-name&gt;CSRFGuard&lt;/filter-name&gt;<br /> &lt;url-pattern&gt;/*&lt;/url-pattern&gt;<br /> &lt;/filter-mapping&gt;<br /> <br /> The aforementioned code snippet maps CSRFGuard to every resource served by the application server. You can more specifically map the filter through the use of the &quot;servlet-name&quot; and &quot;url-pattern&quot; directives.<br /> <br /> = Configure Owasp.CsrfGuard.properties =<br /> <br /> The Owasp.CsrfGuard.properties file controls how OWASP CSRFGuard behaves at runtime. CSRFGuard looks for the file in the following locations in order: application's classpath, servlet context directory, and current directory. You are encouraged to make use of the sample Owasp.CsrfGuard.properties file bundled with CSRFGuard to help kick-start your deployment efforts. There are various properties supported by CSRFGuard. At a minimum, you'll want to configure the new token landing page and the action properties. [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> [[Category:OWASP CSRFGuard Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_Installation&diff=104949 2011-02-12T17:41:02Z

<p>Esheridan: </p> <hr /> <div>= Overview =<br /> <br /> The purpose of this article is to provide guidance around the installation of OWASP CSRFGuard within a JavaEE web application. Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps. First, you must copy the Owasp.CsrfGuard.jar file to your application's classpath. After copying over the OWASP CSRFGuard library, declare and map the CsrfGuardFilter in your application's web.xml deployment descriptor. This instructs the application server to initialize the OWASP CSRFGuard Filter protecting those resources that match the Filter mapping. Finally, customize the Owasp.CsrfGuard.properties file as you see fit. You'll need to make sure you tell CsrfGuardFilter the location of your CSRFGuard properties file via a JavaEE Filter init-param directive. Please refer to the following sub-sections for more detailed information on each of the aforementioned installation steps.<br /> <br /> = Copy Owasp.CsrfGuard.jar to Classpath =<br /> <br /> The first thing you need to do is copy the Owasp.CsrfGuard.jar library into your classpath. The most common classpath location to place Owasp.CsrfGuard.jar is within the lib directory of the web application's WEB-INF folder. OWASP CSRFGuard 3 has no additional dependencies outside of the traditional JavaEE runtime environment.<br /> <br /> = Declare CsrfGuard in Deployment Descriptor =<br /> <br /> After placing Owasp.CsrfGuard.jar in your application's classpath, you'll need to declare CsrfGuard context parameters along with a HttpSessionListener and a Filter. The following web.xml snippet was extracted from the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] web application:<br /> <br /> &lt;context-param&gt;<br /> &lt;param-name&gt;Owasp.CsrfGuard.Config&lt;/param-name&gt;<br /> &lt;param-value&gt;WEB-INF/Owasp.CsrfGuard.properties&lt;/param-value&gt;<br /> &lt;/context-param&gt;<br /> <br /> &lt;context-param&gt;<br /> &lt;param-name&gt;Owasp.CsrfGuard.Config.Print&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/context-param&gt;<br /> <br /> &lt;listener&gt;<br /> &lt;listener-class&gt;org.owasp.csrfguard.CsrfGuardListener&lt;/listener-class&gt;<br /> &lt;/listener&gt;<br /> <br /> The code snippet defines two context parameters: Owasp.CsrfGuard.Config and Owasp.CsrfGuard.Config.Print. The Owasp.CsrfGuard.Config parameter is required and specifies the location of the CSRFGuard properties file. CSRFGuard will search for the properties file specified by searching the following locations in order of appearance: the application's classpath, a directory accessible by the container, or an arbitrary absolute path. The Owasp.CsrfGuard.Config.Print parameter is optional and simply instructs CSRFGuard to display the parsed properties to the application server log file. Finally, we declare and enable the CSRFGuard HttpSessionListener with a class name of org.owasp.csrfguard.CsrfGuardListener. The CsrfGuardListener class is responsible for consuming context parameters and initializing CsrfGuard context for all newly created HttpSessions.<br /> <br /> Now that we have the CsrfGuard context initialization facilities in place, we'll need to declare and map the enforcement mechanism: CsrfGuardFilter. CsrfGuardFilter is responsible for facilitating the integration of the CsrfGuard object and associated token verification logic within the JavaEE web application. The following web.xml snippet was extracted from the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] web application:<br /> <br /> &lt;filter&gt;<br /> &lt;filter-name&gt;CSRFGuard&lt;/filter-name&gt;<br /> &lt;filter-class&gt;org.owasp.csrfguard.CsrfGuardFilter&lt;/filter-class&gt;<br /> &lt;/filter&gt;<br /> &lt;filter-mapping&gt;<br /> &lt;filter-name&gt;CSRFGuard&lt;/filter-name&gt;<br /> &lt;url-pattern&gt;/*&lt;/url-pattern&gt;<br /> &lt;/filter-mapping&gt;<br /> <br /> We create a filter with the name of CSRFGuard and specify a classname of org.owasp.csrfguard.CsrfGuardFilter. At this point, we need to mapp the CSRFGuard Filter to all resources that we want to protect from attack. The following web.xml snippet was extracted from the [https://github.com/esheri3/OWASP-CSRFGuard/tree/master/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] web application:<br /> <br /> &lt;filter-mapping&gt;<br /> &lt;filter-name&gt;CSRFGuard&lt;/filter-name&gt;<br /> &lt;url-pattern&gt;/*&lt;/url-pattern&gt;<br /> &lt;/filter-mapping&gt;<br /> <br /> The aforementioned code snippet maps CSRFGuard to every resource served by the application server. You can more specifically map the filter through the use of the &quot;servlet-name&quot; and &quot;url-pattern&quot; directives.<br /> <br /> = Configure Owasp.CsrfGuard.properties =<br /> <br /> The Owasp.CsrfGuard.properties file controls how OWASP CSRFGuard behaves at runtime. CSRFGuard looks for the file in the following locations in order: application's classpath, servlet context directory, and current directory. You are encouraged to make use of the sample Owasp.CsrfGuard.properties file bundled with CSRFGuard to help kick-start your deployment efforts. There are various properties supported by CSRFGuard. At a minimum, you'll want to configure the new token landing page and the action properties. [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> [[Category:OWASP CSRFGuard Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_User_Manual&diff=104948 2011-02-12T17:25:49Z

<p>Esheridan: /* Download */</p> <hr /> <div>= Overview =<br /> <br /> Welcome to the OWASP CSRFGuard 3 User Manual! The purpose of this article is to provide the user with guidance on obtaining, installing, deploying, and developing with the OWASP CSRFGuard library. The author's goal was to keep the User Manual informative, use to understand, and concise. If you find that one or more aspects of this document does not adhere to these goals, please me know at eric dot sheridan at owasp dot org.<br /> <br /> = Download =<br /> <br /> Users can download the latest release of OWASP CSRFGuard using one of the following links:<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/OWASP-CSRFGuard-3.0.0.499.tar.gz OWASP CSRFGuard 3.0.0.499 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> = Installation =<br /> <br /> Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps:<br /> <br /> :# Copy the Owasp.CsrfGuard.jar file to your application's classpath<br /> :# Map the CsrfGuardFilter in your application's deployment descriptor (web.xml)<br /> :# Configure the Owasp.CsrfGuard.properties file as you see fit<br /> <br /> [[CSRFGuard_3_Installation | Click here]] for more detailed information regarding the installation of OWASP CSRFGuard.<br /> <br /> = Configuration =<br /> <br /> The minimum configuration settings that users should review include:<br /> <br /> :* Default new token landing page (org.owasp.csrfguard.NewTokenLandingPage)<br /> :* Support for Ajax and XMLHttpRequest (org.owasp.csrfguard.Ajax)<br /> :* URI resources that should not be protected (org.owasp.csrfguard.unprotected.*)<br /> :* Actions executed when an attack is detected (org.owasp.csrfguard.action.*)<br /> <br /> [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> = Token Injection =<br /> <br /> Users of OWASP CSRFGuard can inject prevention tokens into HTML using two strategies:<br /> <br /> :* JavaScript DOM Manipulation - largely automated process requiring minimal effort and is ideal for most web applications<br /> :* JSP Tag Library - provides fine grained strategy ideal for situations where automated DOM manipulation is insufficient.<br /> <br /> [[CSRFGuard_3_Token_Injection | Click here]] for more information regarding the injection of CSRF prevention tokens within your application.<br /> <br /> = Known Issues =<br /> <br /> The following is a quick bulleted list of known issues within the current release:<br /> <br /> :* No known way to inject CSRF prevention tokens into setters of document.location (ex: document.location=&quot;http://www.owasp.org&quot;;)<br /> :* Tokens are not injected into HTML elements dynamically generated using JavaScript &quot;createElement&quot; and &quot;setAttribute&quot;<br /> <br /> [[Category:OWASP_CSRFGuard_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=104947 2011-02-12T17:24:07Z

<p>Esheridan: /* Downloads */</p> <hr /> <div>== Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> [http://ericsheridan.blogspot.com/ Eric Sheridan] (eric dot sheridan at owasp dot org) is the lead and primary developer of the OWASP CSRFGuard project. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). He is an Independent Application Security Consultant specializing in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/OWASP-CSRFGuard-3.0.0.499.tar.gz OWASP CSRFGuard 3.0.0.499 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Summit_2011_Working_Sessions/Session029&diff=104052 2011-02-07T13:51:27Z

<p>Esheridan: </p> <hr /> <div>{{Template:&lt;includeonly&gt;{{{1}}}&lt;/includeonly&gt;&lt;noinclude&gt;Summit 2011 Working Sessions test tab&lt;/noinclude&gt;<br /> |-<br /> <br /> | summit_session_attendee_name1 = Chris Schmidt<br /> | summit_session_attendee_email1 = chris.schmidt@owasp.org<br /> | summit_session_attendee_username1 = <br /> | summit_session_attendee_company1=Aspect Security<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=<br /> <br /> | summit_session_attendee_name2 = Achim Hoffmann<br /> | summit_session_attendee_email2 = achim@owasp.org<br /> | summit_session_attendee_username2 = Achim<br /> | summit_session_attendee_company2= sic[!]sec<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=capabilities of WAFs to protect against CSRF<br /> <br /> | summit_session_attendee_name3 = Ryan Barnett<br /> | summit_session_attendee_email3 = Ryan.Barnett@owasp.org<br /> | summit_session_attendee_username3 = <br /> | summit_session_attendee_company3=Trustwave's SpiderLabs<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=discuss how WAFs (ModSecurity) can help mitigate CSRF. Also want to discuss/test new CSRFGuard v3 JS code<br /> <br /> | summit_session_attendee_name4 = <br /> | summit_session_attendee_email4 = <br /> | summit_session_attendee_username4 = <br /> | summit_session_attendee_company4=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=<br /> <br /> | summit_session_attendee_name5 = Vishal Garg<br /> | summit_session_attendee_email5 = vishalgrg@gmail.com<br /> | summit_session_attendee_username5 = <br /> | summit_session_attendee_company5= AppSecure Labs<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5= WAFs vs. Frameworks to protect against CSRF<br /> <br /> | summit_session_attendee_name6 = <br /> | summit_session_attendee_email6 = <br /> | summit_session_attendee_username6 = <br /> | summit_session_attendee_company6=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=<br /> <br /> | summit_session_attendee_name7 = <br /> | summit_session_attendee_email7 = <br /> | summit_session_attendee_username7 = <br /> | summit_session_attendee_company7=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=<br /> <br /> | summit_session_attendee_name8 = <br /> | summit_session_attendee_email8 = <br /> | summit_session_attendee_username8 = <br /> | summit_session_attendee_company8=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=<br /> <br /> | summit_session_attendee_name9 = <br /> | summit_session_attendee_email9 = <br /> | summit_session_attendee_username9 = <br /> | summit_session_attendee_company9=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=<br /> <br /> | summit_session_attendee_name10 = <br /> | summit_session_attendee_email10 = <br /> | summit_session_attendee_username10 = <br /> | summit_session_attendee_company10=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=<br /> <br /> | summit_session_attendee_name11 = <br /> | summit_session_attendee_email11 = <br /> | summit_session_attendee_username11 = <br /> | summit_session_attendee_company11=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=<br /> <br /> | summit_session_attendee_name12 = <br /> | summit_session_attendee_email12 = <br /> | summit_session_attendee_username12 = <br /> | summit_session_attendee_company12=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=<br /> <br /> | summit_session_attendee_name13 = <br /> | summit_session_attendee_email13 = <br /> | summit_session_attendee_username13 = <br /> | summit_session_attendee_company13=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=<br /> <br /> | summit_session_attendee_name14 = <br /> | summit_session_attendee_email14 = <br /> | summit_session_attendee_username14 = <br /> | summit_session_attendee_company14=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14= <br /> <br /> | summit_session_attendee_name15 = <br /> | summit_session_attendee_email15 = <br /> | summit_session_attendee_username15 = <br /> | summit_session_attendee_company15=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=<br /> <br /> | summit_session_attendee_name16 = <br /> | summit_session_attendee_email16 = <br /> | summit_session_attendee_username16 = <br /> | summit_session_attendee_company16=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=<br /> <br /> | summit_session_attendee_name17 = <br /> | summit_session_attendee_email17 = <br /> | summit_session_attendee_username17 = <br /> | summit_session_attendee_company17=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=<br /> <br /> | summit_session_attendee_name18 = <br /> | summit_session_attendee_email18 = <br /> | summit_session_attendee_username18 = <br /> | summit_session_attendee_company18=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=<br /> <br /> | summit_session_attendee_name19 = <br /> | summit_session_attendee_email19 = <br /> | summit_session_attendee_username19 = <br /> | summit_session_attendee_company19=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=<br /> <br /> | summit_session_attendee_name20 = <br /> | summit_session_attendee_email20 = <br /> | summit_session_attendee_username20 = <br /> | summit_session_attendee_company20=<br /> | summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=<br /> <br /> |-<br /> | summit_track_logo = [[Image:T._secure_coding.jpg]]<br /> | summit_ws_logo = [[Image:WS._secure_coding.jpg]]<br /> | summit_session_name = Protecting Against CSRF<br /> | summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session029<br /> | mailing_list =<br /> |-<br /> <br /> | short_working_session_description = Examining different ways to build CSRF protection into web applications and web frameworks.<br /> <br /> |-<br /> <br /> | related_project_name1 = ESAPI Java CSRF protection in DefaultHTTPUtilities.java<br /> | related_project_url_1 = https://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/reference/DefaultHTTPUtilities.java<br /> <br /> | related_project_name2 = CSRFGuard<br /> | related_project_url_2 = http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project<br /> <br /> | related_project_name3 = Preventing CSRF with mod_security<br /> | related_project_url_3 = http://knol.google.com/k/preventing-cross-site-request-forgeries-csrf-using-modsecurity#<br /> <br /> | related_project_name4 = Prevent CSRF with ModSecurity v2 (Request Validation Tokens via Content Injection)<br /> | related_project_url_4 = http://blog.spiderlabs.com/2011/01/detecting-malice-with-modsecurity-csrf-attacks.html<br /> <br /> | related_project_name5 = <br /> | related_project_url_5 = <br /> <br /> |-<br /> <br /> | summit_session_objective_name1= <br /> <br /> | summit_session_objective_name2 = <br /> <br /> | summit_session_objective_name3 = <br /> <br /> | summit_session_objective_name4 = <br /> <br /> | summit_session_objective_name5 = <br /> <br /> |-<br /> <br /> | working_session_date_and_time = <br /> <br /> |-<br /> <br /> | discussion_model = participants and attendees<br /> <br /> |-<br /> <br /> | operational_resources = Projector, whiteboards, markers, Internet connectivity, power<br /> <br /> |-<br /> <br /> | working_session_additional_details = <br /> <br /> |-<br /> <br /> |summit_session_deliverable_name1 = A practical guideline for protecting against CSRF in the real world.<br /> <br /> |summit_session_deliverable_name2 = A concise, clear standard for determining whether an application is vulnerable to CSRF.<br /> <br /> |summit_session_deliverable_name3 = <br /> <br /> |summit_session_deliverable_name4 = <br /> <br /> |summit_session_deliverable_name5 = <br /> <br /> |summit_session_deliverable_name6 = <br /> <br /> |summit_session_deliverable_name7 = <br /> <br /> |summit_session_deliverable_name8 = <br /> <br /> |-<br /> <br /> | summit_session_leader_name1 = <br /> | summit_session_leader_email1 = <br /> <br /> | summit_session_leader_name2 = <br /> | summit_session_leader_email2 = <br /> | summit_session_leader_username2 = <br /> <br /> | summit_session_leader_name3 = <br /> | summit_session_leader_email3 = <br /> | summit_session_leader_username3 = <br /> <br /> |-<br /> <br /> | operational_leader_name1 =<br /> | operational_leader_email1 =<br /> | operational_leader_username1 = <br /> <br /> |-<br /> <br /> | meeting_notes = <br /> <br /> |-<br /> | session_name_mask = &lt;!--Please replace DO NOT EDIT this string --&gt; Session029<br /> | session_home_page = &lt;!--Please replace DO NOT EDIT this string --&gt; Summit_2011_Working_Sessions/Session029<br /> }}</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=102721 2011-01-31T16:33:29Z

<p>Esheridan: </p> <hr /> <div>== Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> [http://ericsheridan.blogspot.com/ Eric Sheridan] (eric dot sheridan at owasp dot org) is the lead and primary developer of the OWASP CSRFGuard project. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). He is an Independent Application Security Consultant specializing in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/OWASP-CSRFGuard-3.0.0.479.tar.gz OWASP CSRFGuard 3.0.0.479 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_User_Manual&diff=102362 2011-01-28T02:40:46Z

<p>Esheridan: /* Download */</p> <hr /> <div>= Overview =<br /> <br /> Welcome to the OWASP CSRFGuard 3 User Manual! The purpose of this article is to provide the user with guidance on obtaining, installing, deploying, and developing with the OWASP CSRFGuard library. The author's goal was to keep the User Manual informative, use to understand, and concise. If you find that one or more aspects of this document does not adhere to these goals, please me know at eric dot sheridan at owasp dot org.<br /> <br /> = Download =<br /> <br /> Users can download the latest release of OWASP CSRFGuard using one of the following links:<br /> <br /> :[https://github.com/downloads/esheri3/OWASP-CSRFGuard/OWASP-CSRFGuard-3.0.0.479.tar.gz<br /> OWASP CSRFGuard 3.0.0.479 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> = Installation =<br /> <br /> Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps:<br /> <br /> :# Copy the Owasp.CsrfGuard.jar file to your application's classpath<br /> :# Map the CsrfGuardFilter in your application's deployment descriptor (web.xml)<br /> :# Configure the Owasp.CsrfGuard.properties file as you see fit<br /> <br /> [[CSRFGuard_3_Installation | Click here]] for more detailed information regarding the installation of OWASP CSRFGuard.<br /> <br /> = Configuration =<br /> <br /> The minimum configuration settings that users should review include:<br /> <br /> :* Default new token landing page (org.owasp.csrfguard.NewTokenLandingPage)<br /> :* Support for Ajax and XMLHttpRequest (org.owasp.csrfguard.Ajax)<br /> :* URI resources that should not be protected (org.owasp.csrfguard.unprotected.*)<br /> :* Actions executed when an attack is detected (org.owasp.csrfguard.action.*)<br /> <br /> [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> = Token Injection =<br /> <br /> Users of OWASP CSRFGuard can inject prevention tokens into HTML using two strategies:<br /> <br /> :* JavaScript DOM Manipulation - largely automated process requiring minimal effort and is ideal for most web applications<br /> :* JSP Tag Library - provides fine grained strategy ideal for situations where automated DOM manipulation is insufficient.<br /> <br /> [[CSRFGuard_3_Token_Injection | Click here]] for more information regarding the injection of CSRF prevention tokens within your application.<br /> <br /> = Known Issues =<br /> <br /> The following is a quick bulleted list of known issues within the current release:<br /> <br /> :* No known way to inject CSRF prevention tokens into setters of document.location (ex: document.location=&quot;http://www.owasp.org&quot;;)<br /> :* Tokens are not injected into HTML elements dynamically generated using JavaScript &quot;createElement&quot; and &quot;setAttribute&quot;<br /> <br /> [[Category:OWASP_CSRFGuard_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_User_Manual&diff=102361 2011-01-28T02:39:56Z

<p>Esheridan: /* Known Issues */</p> <hr /> <div>= Overview =<br /> <br /> Welcome to the OWASP CSRFGuard 3 User Manual! The purpose of this article is to provide the user with guidance on obtaining, installing, deploying, and developing with the OWASP CSRFGuard library. The author's goal was to keep the User Manual informative, use to understand, and concise. If you find that one or more aspects of this document does not adhere to these goals, please me know at eric dot sheridan at owasp dot org.<br /> <br /> = Download =<br /> <br /> Users can download the latest release of OWASP CSRFGuard using one of the following links:<br /> <br /> :[http://code.google.com/p/owaspcsrfguard/downloads/detail?name=OWASP%20CSRFGuard%20%283.0.0.245%20-%20ALPHA%29.zip&amp;can=2&amp;q= OWASP CSRFGuard 3.0.0.245 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> = Installation =<br /> <br /> Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps:<br /> <br /> :# Copy the Owasp.CsrfGuard.jar file to your application's classpath<br /> :# Map the CsrfGuardFilter in your application's deployment descriptor (web.xml)<br /> :# Configure the Owasp.CsrfGuard.properties file as you see fit<br /> <br /> [[CSRFGuard_3_Installation | Click here]] for more detailed information regarding the installation of OWASP CSRFGuard.<br /> <br /> = Configuration =<br /> <br /> The minimum configuration settings that users should review include:<br /> <br /> :* Default new token landing page (org.owasp.csrfguard.NewTokenLandingPage)<br /> :* Support for Ajax and XMLHttpRequest (org.owasp.csrfguard.Ajax)<br /> :* URI resources that should not be protected (org.owasp.csrfguard.unprotected.*)<br /> :* Actions executed when an attack is detected (org.owasp.csrfguard.action.*)<br /> <br /> [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> = Token Injection =<br /> <br /> Users of OWASP CSRFGuard can inject prevention tokens into HTML using two strategies:<br /> <br /> :* JavaScript DOM Manipulation - largely automated process requiring minimal effort and is ideal for most web applications<br /> :* JSP Tag Library - provides fine grained strategy ideal for situations where automated DOM manipulation is insufficient.<br /> <br /> [[CSRFGuard_3_Token_Injection | Click here]] for more information regarding the injection of CSRF prevention tokens within your application.<br /> <br /> = Known Issues =<br /> <br /> The following is a quick bulleted list of known issues within the current release:<br /> <br /> :* No known way to inject CSRF prevention tokens into setters of document.location (ex: document.location=&quot;http://www.owasp.org&quot;;)<br /> :* Tokens are not injected into HTML elements dynamically generated using JavaScript &quot;createElement&quot; and &quot;setAttribute&quot;<br /> <br /> [[Category:OWASP_CSRFGuard_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=102360 2011-01-28T02:25:26Z

<p>Esheridan: /* Downloads */</p> <hr /> <div>== Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> [http://ericsheridan.blogspot.com/ Eric Sheridan] (eric dot sheridan at owasp dot org) is the lead and primary developer of the OWASP CSRFGuard project. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). He is a Principal Consultant at Aspect Security specializing in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> [https://github.com/downloads/esheri3/OWASP-CSRFGuard/OWASP-CSRFGuard-3.0.0.479.tar.gz OWASP CSRFGuard 3.0.0.479 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=102359 2011-01-28T01:43:53Z

<p>Esheridan: /* Source Code */</p> <hr /> <div>== Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> [http://ericsheridan.blogspot.com/ Eric Sheridan] (eric dot sheridan at owasp dot org) is the lead and primary developer of the OWASP CSRFGuard project. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). He is a Principal Consultant at Aspect Security specializing in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the Git repository online at https://github.com/esheri3/OWASP-CSRFGuard<br /> <br /> == Downloads ==<br /> <br /> [http://code.google.com/p/owaspcsrfguard/downloads/detail?name=OWASP%20CSRFGuard%20%283.0.0.336%20-%20ALPHA%29.zip&amp;can=2&amp;q= OWASP CSRFGuard 3.0.0.336 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_Token_Injection&diff=98328 2011-01-04T21:18:57Z

<p>Esheridan: /* Declare and Configure JavaScriptServlet */</p> <hr /> <div>= Overview =<br /> <br /> OWASP CSRFGuard implements a variant of the synchronizer token pattern to mitigate the risk of CSRF attacks. In order to implement this pattern, CSRFGuard must offer the capability to place the CSRF prevention token within the HTML produced by the protected web application. CSRFGuard 3 provides developers more fine grain control over the injection of the token. Developers can inject the token in their HTML using either dynamic JavaScript DOM manipulation or a JSP tag library. CSRFGuard no longer intercepts and modifies the HttpServletResponse object as was done in previous releases. The currently available token injection strategies are designed to make the integration of CSRFGuard more feasible and scalable within current enterprise web applications. Developers are encouraged to make use of both the JavaScript DOM Manipulation and the JSP tag library strategies for a complete token injection strategy. The JavaScript DOM Manipulation strategy is ideal as it is automated and requires minimal effort on behalf of the developer. In the event the JavaScript solution is insufficient within a particular application context, developers should leverage the JSP tag library. The purpose of this article is to describe the token injection strategies offered by OWASP CSRFGuard 3.<br /> <br /> = JavaScript DOM Manipulation =<br /> <br /> OWASP CSRFGuard 3 supports the ability to dynamically inject CSRF prevention tokens throughout the DOM currently loaded in the user's browser. This strategy is extremely valuable with regards to server-side performance as it simply requires the serving of a dynamic JavaScript file. There is little to no performance hit when the fetched dynamic JavaScript updates the browser's DOM. Making use of the JavaScript token injection solution requires the developer map a Servlet and place a JavaScript HTML tag within all pages sending requests to protected application resources. Developers are strongly encouraged to leverage the JavaScript token injection strategy by default. This strategy requires minimal effort on behalf of the developer as most of the token injection logic is automated. In the event that the JavaScript automated solution may be insufficient for a specific application context, developers should leverage the OWASP CSRFGuard JSP tag library.<br /> <br /> '''Note:''' Use of JavaScript DOM Manipulation is required for Ajax support.<br /> <br /> == Declare and Configure JavaScriptServlet ==<br /> <br /> The JavaScript file used for token injection is dynamically generated by the JavaScriptServlet class using a template file. Ensure that the Owasp.CsrfGuard.jar file is found within the target application's classpath. Copy the Owasp.CsrfGuard.js template file from the OWASP CSRFGuard distribution folder to a non-publicly accessible directory within the target application. For the remainder of this section, we assume the Owasp.CsrfGuard.js template file was placed in the application's WEB-INF folder. Edit the deployment descriptor (web.xml) to declare the JavaScriptServlet class along with any associated initialization parameters. Consider the following configuration snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;servlet-class&gt;org.owasp.csrfguard.servlet.JavaScriptServlet&lt;/servlet-class&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;source-file&lt;/param-name&gt;<br /> &lt;param-value&gt;WEB-INF/Owasp.CsrfGuard.js&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-forms&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-attributes&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;domain-strict&lt;/param-name&gt;<br /> &lt;param-value&gt;false&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;referer-pattern&lt;/param-name&gt;<br /> &lt;param-value&gt;.*localhost.*&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;/servlet&gt;<br /> <br /> The aforementioned configuration snippet declares the JavaScriptServlet class using the name &quot;JavaScriptServlet&quot;. JavaScriptServlet accepts various initialization parameters augmenting the behavior of the class at runtime. The provided configuration snippet instructs JavaScriptServlet to...<br /> <br /> #Leverage the template JavaScript file at WEB-INF/Owasp.CsrfGuard.js<br /> #Inject the token into all HTML forms<br /> #Inject the token into all src and href attributes<br /> #Leverage loose same origin matching criteria when placing the token in URL resources<br /> <br /> Consider the following for a more detailed listing of the initialization parameters supported by JavaScriptServlet:<br /> <br /> source-file<br /> <br /> Denotes the location of the JavaScript template file that should be consumed and dynamically augmented by the JavaScriptServlet class. The default value is WEB-INF/Owasp.CsrfGuard.js. Use of this property and the existence of the specified template file is required. <br /> <br /> domain-strict<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should be strict with regards to what links it should inject the CSRF prevention token. With a value of true, the JavaScript code will only place the token in links that point to the same exact domain from which the HTML originated. With a value of false, the JavaScript code will place the token in links that not only point to the same exact domain from which the HTML originated, but sub-domains as well.<br /> <br /> referer-pattern<br /> <br /> Allows the developer to specify a regular expression describing the required value of the Referer header. Any attempts to access the servlet with a Referer header that does not match the captured expression is discarded. Inclusion of referer header checking is to help minimize the risk of JavaScript Hijacking attacks that attempt to steal tokens from the dynamically generated JavaScript. While the primary defenses against JavaScript Hijacking attacks are implemented within the dynamic JavaScript itself, referer header checking is implemented to achieve defense in depth.<br /> <br /> cache-control<br /> <br /> Allows the developer to specify the value of the Cache-Control header in the HTTP response when serving the dynamic JavaScript file. The default value is private, maxage=28800. Caching of the dynamic JavaScript file is intended to minimize traffic and improve performance. Note that the Cache-Control header is always set to &quot;no-store&quot; when either the &quot;Rotate&quot; &quot;TokenPerPage&quot; options is set to true in Owasp.CsrfGuard.properties.<br /> <br /> inject-into-forms<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token as a hidden field into HTML forms. The default value is true. Developers are strongly discouraged from disabling this property as most server-side state changing actions are triggered via a POST request.<br /> <br /> inject-into-attributes<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token in the query string of src and href attributes. Injecting the CSRF prevention token in a URL resource increases its general risk of exposure to unauthorized parties. However, most JavaEE web applications respond in the exact same manner to HTTP requests and their associated parameters regardless of the HTTP method. The risk associated with not protecting GET requests in this situation is perceived greater than the risk of exposing the token in protected GET requests. As a result, the default value of this attribute is set to true. Developers that are confident their server-side state changing controllers will only respond to POST requests (i.e. discarding GET requests) are strongly encouraged to disable this property.<br /> <br /> == Map JavaScriptServlet ==<br /> <br /> Developers must map the JavaScriptServlet to a URI space such that the Servlet class can be remotely accessed by the dynamic JavaScript code. Consider the following configuration snippet taken directly from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet-mapping&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;url-pattern&gt;/JavaScriptServlet&lt;/url-pattern&gt;<br /> &lt;/servlet-mapping&gt;<br /> <br /> The aforementioned configuration snippet maps the Servlet referenced by the name &quot;JavaScriptServlet&quot; to the URI space &quot;/JavaScriptServlet&quot;. Any request sent to the /JavaScriptServlet URI will produce a dynamically generated CSRFGuard JavaScript file specific to the user's current session.<br /> <br /> == Inject Dynamic JavaScript ==<br /> <br /> Developers are required to place an HTML script tag within all pages that are known to send requests to CSRF protected resources. All requests within the current HTML page are augmented to ensure they submit the correct CSRF token for the user's current session. Note that inclusion of the dynamic JavaScript does not protect the current page. Rather, the script ensures the CSRF token is transmitted within all requests generated by the current page. Consider the following code snippet taken directly from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;!-- OWASP CSRFGuard Support --&gt;<br /> &lt;script src=&quot;/Owasp.CsrfGuard.Test/JavaScriptServlet&quot;&gt;&lt;/script&gt;<br /> <br /> The script tag retrieves and executes the dynamically generated JavaScript from the Servlet mapped at /Owasp.CsrfGuard.Test/JavaScriptServlet. This JavaScript code will register an event handler with window.onload. Once triggered, the code will iterate over every HTML element within the DOM looking for either form tags and or tags containing href or src attributes as configured by the JavaScriptServlet initialization parameters. Forms are dynamically updated to include the CSRFGuard token via a hidden field and tags using src and href attributes are updated to include the CSRFGuard token via a query string parameter.<br /> <br /> = JSP Tag Library =<br /> <br /> OWASP CSRFGuard 3 exposes a JSP tag library providing developers more fine grain control over token injection. The library exposes JSP tags that allow access to the token name, the token value, and the token name value pair delimited by an equals (=) sign. In order to make use of the tag library, ensure the Owasp.CsrfGuard.jar file is found within the target application's classpath. For example, the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application places the OWASP CSRFGuard jar file within the WebContent/WEB-INF/lib directory. After placing the library in the classpath, developers can reference the tags in JSP pages using predefined URI reference. The following JSP code snippet imports the tag library and makes it available using the prefix &quot;csrf&quot;:<br /> <br /> &lt;%@ taglib uri=&quot;http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project/Owasp.CsrfGuard.tld&quot; prefix=&quot;csrf&quot; %&gt;<br /> <br /> The benefit of using the JSP tag library to inject the CSRF prevention token is the fine grain level of control. Developers can place the token in all the correct locations within the context of their applications. This strategy is useful in application contexts where the JavaScript DOM Manipulation strategy is insufficient.<br /> <br /> == Display Token Name ==<br /> <br /> The OWASP CSRFGuard token name can be obtained through the token-name tag. The token-name tag is useful when injecting the CSRFGuard token name in a non-query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-name tag to reference the token name in the name attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;'''&lt;csrf:token-name/&gt;'''&quot; value=&quot;&lt;csrf:token-value/&gt;&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Value ==<br /> <br /> The OWASP CSRFGuard token value can be obtained through the token-value tag. The token-value tag is useful when injecting the CSRFGuard token value in a non-query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-value tag to reference the token value in the value attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;&lt;csrf:token-name/&gt;&quot; value=&quot;'''&lt;csrf:token-value/&gt;'''&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> The token value tag must be used in conjunction with the URI attribute when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The value of the uri attribute is the URI for which the token value will be posted. Consider the following example which sets the URI to the destination of the form, &quot;protect.html&quot;:<br /> <br /> &lt;form id=&quot;formTest1&quot; name=&quot;formTest1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;&lt;csrf:token-name/&gt;&quot; value=&quot;&lt;csrf:token-value uri=&quot;protect.html&quot;/&gt;&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Name Value Pair ==<br /> <br /> The OWASP CSRFGuard token name value pair, delimited by an equals sign (=), can be obtained though the token tag. The token tag is useful when injecting the CSRFGuard token value in a query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token tag to reference the token name value pair in the href attribute of an anchor tag:<br /> <br /> &lt;a href=&quot;protect.html?&lt;csrf:token/&gt;&quot;&gt;protect.html&lt;/a&gt;<br /> <br /> The token name value pair tag must be used in conjunction with the URI attribute when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The value of the uri attribute is the URI for which the token value will be posted. Consider the following example which sets the URI to the destination of the link, &quot;protect.html&quot;:<br /> <br /> &lt;a href=&quot;protect.html?&lt;csrf:token uri=&quot;protect.html&quot;/&gt;&quot;&gt;protect.html&lt;/a&gt;<br /> <br /> == Generate Form with Prevention Token ==<br /> <br /> The OWASP CSRFGuard JSP library implements a tag library designed specifically to generate HTML forms with the CSRF prevention token automatically embedded as a hidden field. This strategy simplifies the integration of the CSRF token, especially when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The tag accepts dynamic attribute name value pairs and simply outputs them to the page. As a result, you are free to use the same attribute values made available in a standard HTML form. There is no special output encoding performed on these dynamic attributes. Take care to perform the appropriate validation and output encoding for all dynamic attributes used in conjunction with untrusted data. Consider the following code snippet which will produce a HTML form with an embedded CSRF token. No special care must be taken when using this flag in conjunction with the unique token per uri model:<br /> <br /> &lt;csrf:form id=&quot;formTest2&quot; name=&quot;formTest2&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;/csrf:form&gt;<br /> <br /> == Generate Link with Prevention Token ==<br /> <br /> The OWASP CSRFGuard JSP library implements a tag library designed specifically to generate HTML anchor tags with the CSRF prevention token automatically embedded as a query string parameter. This strategy simplifies the integration of the CSRF token, especially when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The tag accepts dynamic attribute name value pairs and simply outputs them to the page. As a result, you are free to use the same attribute values made available in a standard HTML anchor. There is no special output encoding performed on these dynamic attributes. Take care to perform the appropriate validation and output encoding for all dynamic attributes used in conjunction with untrusted data. Consider the following code snippet which will produce a HTML anchor tag with an embedded CSRF token. No special care must be taken when using this flag in conjunction with the unique token per uri model:<br /> <br /> &lt;csrf:a href=&quot;protect.html&quot;&gt;protect.html&lt;/csrf:a&gt;</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_Configuration&diff=97612 2010-12-22T22:32:00Z

<p>Esheridan: /* New Token Landing Page */</p> <hr /> <div>= Overview =<br /> <br /> The most important aspect of deploying OWASP CSRFGuard is configuration of the Owasp.CsrfGuard.properties file. There are a minimum number of configuration settings that users should review and specify before running an instance of OWASP CSRFGuard. Such configurations include specifying the new token landing page, enabling Ajax support for applications making use of XMLHttpRequest, capturing pages that should not be protected, as well as configuring one or more actions that should be invoked when a CSRF attack is identified. The purpose of this article is to provide an overview of key OWASP CSRFGuard configuration settings.<br /> <br /> = Logger =<br /> <br /> The logger property (org.owasp.csrfguard.Logger) defines the qualified class name of the object responsible for processing all log messages produced by CSRFGuard. The default CSRFGuard logger is org.owasp.csrfguard.log.ConsoleLogger. This class logs all messages to System.out which JavaEE application servers redirect to a vendor specific log file. Developers can customize the logging behavior of CSRFGuard by implementing the org.owasp.csrfguard.log.ILogger interface and setting the logger property to the new logger's qualified class name. The following configuration snippet instructs OWASP CSRFGuard to capture all log messages to the console:<br /> <br /> org.owasp.csrfguard.Logger=org.owasp.csrfguard.log.ConsoleLogger<br /> <br /> = New Token Landing Page =<br /> <br /> The new token landing page property (org.owasp.csrfguard.NewTokenLandingPage) defines where to send a user if the token is being generated for the first time. This request is generated using auto-posting forms and will only contain the CSRF prevention token parameter, if applicable. All query-string or form parameters sent with the original request will be discarded. If this property is not defined, CSRFGuard will instead auto-post the user to the originally requested URI. The following configuration snippet instructs OWASP CSRFGuard to redirect the user to /Owasp.CsrfGuard.Test/index.html when the user visits a protected resource without having a corresponding CSRF token present in the HttpSession object:<br /> <br /> org.owasp.csrfguard.NewTokenLandingPage=/Owasp.CsrfGuard.Test/index.html<br /> <br /> = Unique Token Per Page =<br /> <br /> The unique token per-page property (org.owasp.csrfguard.TokenPerPage) is a boolean value that determines if CSRFGuard should make use of unique per-page (i.e. URI) prevention tokens as opposed to unique per-session prevention tokens. When a user requests a protected resource, CSRFGuard will determine if a page specific token has been previously generated. If a page specific token has not yet been previously generated, CSRFGuard will verify the request was submitted with the per-session token intact. After verifying the presence of the per-session token, CSRFGuard will create a page specific token that is required for all subsequent requests to the associated resource. The per-session CSRF token can only be used when requesting a resource for the first time. All subsequent requests must have the per-page token intact or the request will be treated as a CSRF attack. Use of the unique token per page property is currently experimental but provides a significant amount of improved security. Consider the exposure of a CSRF token using the legacy unique per-session model. Exposure of this token facilitates the attacker's ability to carry out a CSRF attack against the victim's active session for any resource exposed by the web application. Now consider the exposure of a CSRF token using the experimental unique token per-page model. Exposure of this token would only allow the attacker to carry out a CSRF attack against the victim's active session for a small subset of resources exposed by the web application. Use of the unique token per-page property is a strong defense in depth strategy significantly reducing the impact of exposed CSRF prevention tokens. The following configuration snippet instructs OWASP CSRFGuard to utilize the unique token per-page model:<br /> <br /> org.owasp.csrfguard.TokenPerPage=true<br /> <br /> = Token Rotation =<br /> <br /> The rotate token property (org.owasp.csrfguard.Rotate) is a boolean value that determines if CSRFGuard should generate and utilize a new token after verifying the previous token. Rotation helps minimize the window of opportunity an attacker has to leverage the victim's stolen token in a targeted CSRF attack. However, this functionality generally causes navigation problems in most applications. Specifically, the 'Back' button in the browser will often cease to function properly. When a user hits the 'Back' button and interacts with the HTML, the browser may submit an old token causing CSRFGuard to incorrectly believe this request is a CSRF attack in progress (i.e. a 'false positive'). Users can prevent this scenario by preventing the caching of HTML pages containing FORM submissions using the cache-control header. However, this may also introduce performance problems as the browser will have to request HTML on a more frequent basis. The following configuration snippet disables token rotation:<br /> org.owasp.csrfguard.Rotate=false<br /> <br /> = Ajax and XMLHttpRequest Support =<br /> <br /> The Ajax property (org.owasp.csrfguard.Ajax) is a boolean value that indicates whether or not OWASP CSRFGuard should support the injection and verification of unique per-session prevention tokens for XMLHttpRequests. To leverage Ajax support, the user must not only set this property to true but must also reference the [[CSRFGuard_3_Token_Injection#JavaScript_DOM_Manipulation | JavaScript DOM Manipulation]] code using a script element. This dynamic script will override the send method of the XMLHttpRequest object to ensure the submission of an X-Requested-With header name value pair coupled with the submission of a custom header name value pair for each request. The name of the custom header is the value of the token name property and the value of the header is always the unique per-session token value. This custom header is analogous to the HTTP parameter name value pairs submitted via traditional GET and POST requests. If the X-Requested-With header was sent in the HTTP request, then CSRFGuard will look for the presence and ensure the validity of the unique per-session token in the custom header name value pair. Note that verification of these headers takes precedence over verification of the CSRF token supplied as an HTTP parameter. More specifically, CSRFGuard does not verify the presence of the CSRF token if the Ajax support property is enabled and the corresponding X-Requested-With and custom headers are embedded within the request. The following configuration snippet instructs OWASP CSRFGuard to support Ajax requests by verifying the presence and correctness of the X-Requested-With and custom headers:<br /> <br /> org.owasp.csrfguard.Ajax=true<br /> <br /> = Unprotected Pages =<br /> <br /> The unprotected pages property (org.owasp.csrfguard.unprotected.*) defines a series of pages that should not be protected by CSRFGuard. Such configurations are useful when the CsrfGuardFilter is aggressively mapped (ex: /*). The syntax of the property name is org.owasp.csrfguard.unprotected.[PageName], where PageName is some arbitrary identifier that can be used to reference a resource. The syntax of defining the uri of unprotected pages is the same as the syntax used by the JavaEE container for uri mapping. Specifically, CSRFGuard will identify the first match (if any) between the requested uri and an unprotected page in order of declaration. Match criteria is as follows:<br /> <br /> :Case 1: exact match between request uri and unprotected page<br /> :Case 2: longest path prefix match, beginning / and ending /*<br /> :Case 3: extension match, beginning *.<br /> :Default: requested resource must be validated by CSRFGuard<br /> <br /> The following code snippet illustrates the three use cases over four examples. The first two examples (Tag and JavaScriptServlet) look for direct URI matches. The third example (Html) looks for all resources ending in a .html extension. The last example (Public) looks for all resources prefixed with the URI path /MySite/Public/*.<br /> <br /> org.owasp.csrfguard.unprotected.Tag=/Owasp.CsrfGuard.Test/tag.jsp<br /> org.owasp.csrfguard.unprotected.JavaScriptServlet=/Owasp.CsrfGuard.Test/JavaScriptServlet<br /> org.owasp.csrfguard.unprotected.Html=*.html<br /> org.owasp.csrfguard.unprotected.Public=/MySite/Public/*<br /> <br /> = Actions: Responding to Attacks =<br /> <br /> The actions directive (org.owasp.csrfguard.action.*) gives the user the ability to specify one or more actions that should be invoked when a CSRF attack is detected. Every action must implement the org.owasp.csrfguard.action.IAction interface either directly or indirectly through the org.owasp.csrfguard.action.AbstractAction helper class. Many actions accept parameters that can be specified along with the action class declaration. These parameters are consumed at runtime and impact the behavior of the associated action.<br /> <br /> The syntax for defining and configuring CSRFGuard actions is relatively straight forward. Let us assume we wish to redirect the user to a default page when a CSRF attack is detected. A redirect action already exists within the CSRFGuard bundle and is available via the class name org.owasp.csrfguard.actions.Redirect. In order to enable this action, we capture the following declaration in the Owasp.CsrfGuard.properties file:<br /> <br /> '''syntax:''' org.owasp.csrfguard.action.[actionName]=[className]<br /> '''example:''' org.owasp.csrfguard.action.class.Redirect=org.owasp.csrfguard.actions.Redirect<br /> <br /> The aforementioned directive declares an action called &quot;Redirect&quot; (i.e. [actionName]) referencing the Java class &quot;org.owasp.csrfguard.actions.Redirect&quot; (i.e. [className]). Anytime a CSRF attack is detected, the Redirect action will be executed. You may be asking yourself, &quot;but how do I specify where the user is redirected?&quot;; this is where action parameters come into play. In order to specify the redirect location, we capture the following declaration in the Owasp.CsrfGuard.properties file:<br /> <br /> '''syntax:''' org.owasp.csrfguard.action.[actionName].[parameterName]=[parameterValue]<br /> '''example:''' org.owasp.csrfguard.action.Redirect.ErrorPage=/Owasp.CsrfGuard.Test/error.html<br /> <br /> The aforementioned directive declares an action parameter called &quot;ErrorPage&quot; (i.e. [parameterName]) with the value of &quot;/Owasp.CsrfGuard.Test/error.html&quot; (i.e. [parameterValue]) for the action &quot;Redirect&quot; (i.e. [actionName]). The Redirect action expects the &quot;ErrorPage&quot; parameter to be defined and will redirect the user to this location when an attack is detected.<br /> <br /> There are several &quot;out of the box&quot; actions made available with the OWASP CSRFGuard distributable. <br /> <br /> == org.owasp.csrfguard.action.Log ==<br /> <br /> Creates a customized log message whenever a CSRF attack is detected by OWASP CSRFGuard. The log message is captured using the logger mechanism defined by the ''org.owasp.csrfguard.Logger'' directive in the Owasp.CsrfGuard.properties file. Log accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.Log.Message'''<br /> <br /> Allows the user to define the format of the log message to be recorded. The Message parameter supports several formatting options to aide in the customization of the message to the particular attack. The following formatting options are supported:<br /> <br /> '''%exception%''' - String representation of the CsrfGuardException thrown by the CsrfGuard class.<br /> '''%exception_message%''' - Localized exception message of the class CsrfGuardException thrown by the CsrfGuard class.<br /> '''%remote_ip%''' - Remote IP address of the client that sent the CSRF attack to the server.<br /> '''%remote_host%''' - Remote host name of the client that sent the CSRF attack to the server.<br /> '''%remote_port%''' - Remote port of the client that sent the CSRF attack to the server.<br /> '''%local_ip%''' - Local IP address of the server that detected the CSRF attack.<br /> '''%local_host%''' - Local host name of the server that detected the CSRF attack.<br /> '''%local_port%''' - Local port of the server that detected the CSRF attack.<br /> '''%request_uri%''' - Request URI for which the CSRF attack was targeting.<br /> '''%request_url%''' - Request URL for which the CSRF attack was targeting.<br /> '''%user%''' - User information as made available by the javax.servlet.http.HttpServletRequest.getRemoteUser() method invocation.<br /> <br /> == org.owasp.csrfguard.action.Invalidate ==<br /> <br /> Invalidate any existing HttpSession associated with the current HttpServletRequest. Note that this is the session of the victim for which the CSRF attack was targeting. Invalidating the JavaEE container's session generally results in the user having to re-authenticate. There are no parameters associated with this action.<br /> <br /> == org.owasp.csrfguard.action.Redirect ==<br /> <br /> Redirects the user to the URI specified in the Page action parameter. Attempting to utilize this action in combination with Forward will generally result in the JavaEE container throwing IllegalStateException. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.Redirect.Page'''<br /> <br /> Defines the URI for which the user is redirected when a CSRF attack is detected.<br /> <br /> == org.owasp.csrfguard.action.Forward ==<br /> <br /> Forwards the user to the URI specified in the Page action parameter. Attempting to utilize this action in combination with Redirect will generally result in the JavaEE container throwing IllegalStateException. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.Forward.Page'''<br /> <br /> Defines the URI for which the user is forwarded when a CSRF attack is detected.<br /> <br /> == org.owasp.csrfguard.action.RequestAttribute ==<br /> <br /> Makes the CsrfGuardException thrown by the CsrfGuard class when an attack is detected programmatically available as an attribute in the HttpServletRequest object. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.RequestAttribute.AttributeName'''<br /> <br /> Defines the attribute name that should be used when placing the CsrfGuardException in the HttpServletRequest attributes collection.<br /> <br /> == org.owasp.csrfguard.action.SessionAttribute ==<br /> <br /> Makes the CsrfGuardException thrown by the CsrfGuard class when an attack is detected programmatically available as an attribute in the HttpSession object. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.SessionAttribute.AttributeName'''<br /> <br /> Defines the attribute name that should be used when placing the CsrfGuardException in the HttpSession attributes collection.<br /> <br /> == org.owasp.csrfguard.action.Rotate ==<br /> <br /> Invalidates and re-generates any existing CSRF prevention tokens associated with the current HttpSession. This action helps minimize the risk of a malicious user attempting to brute force a user's prevention tokens through timing based side channel attacks. Note that this action has no effect when used in conjunction with the Invalidate action. There are no parameters associated with this action.<br /> <br /> = Miscellaneous Configurations =<br /> <br /> == Token Name ==<br /> <br /> The token name property (org.owasp.csrfguard.TokenName) defines the name of the HTTP parameter to contain the value of the OWASP CSRFGuard token for each request. The following configuration snippet sets the CSRFGuard token parameter name to the value OWASP_CSRFTOKEN:<br /> org.owasp.csrfguard.TokenName=OWASP_CSRFTOKEN<br /> <br /> == Session Key ==<br /> <br /> The session key property (org.owasp.csrfguard.SessionKey) defines the string literal used to save and lookup the CSRFGuard token from the session. This value is used by the filter and the tag libraries to retrieve and set the token value in the session. Developers can use this key to programmatically lookup the token within their own code. The following configuration snippet sets the session key to the value OWASP_CSRFTOKEN:<br /> org.owasp.csrfguard.SessionKey=OWASP_CSRFTOKEN<br /> <br /> == Token Length ==<br /> <br /> The token length property (org.owasp.csrfguard.TokenLength) defines the number of characters that should be found within the CSRFGuard token. Note that characters are delimited by dashes (-) in groups of four. For cosmetic reasons, users are encourage to ensure the token length is divisible by four. The following configuration snippet sets the token length property to 32 characters:<br /> org.owasp.csrfguard.TokenLength=32<br /> <br /> == Pseudo-Random Number Generator ==<br /> <br /> The pseudo-random number generator property (org.owasp.csrfguard.PRNG) defines what PRNG should be used to generate the OWASP CSRFGuard token. Always ensure this value references a cryptographically strong pseudo-random number generator algorithm. The following configuration snippet sets the pseudo-random number generator to SHA1PRNG:<br /> org.owasp.csrfguard.PRNG=SHA1PRNG<br /> <br /> [[Category:OWASP CSRFGuard Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_Configuration&diff=97514 2010-12-22T15:22:21Z

<p>Esheridan: /* org.owasp.csrfguard.action.Log */</p> <hr /> <div>= Overview =<br /> <br /> The most important aspect of deploying OWASP CSRFGuard is configuration of the Owasp.CsrfGuard.properties file. There are a minimum number of configuration settings that users should review and specify before running an instance of OWASP CSRFGuard. Such configurations include specifying the new token landing page, enabling Ajax support for applications making use of XMLHttpRequest, capturing pages that should not be protected, as well as configuring one or more actions that should be invoked when a CSRF attack is identified. The purpose of this article is to provide an overview of key OWASP CSRFGuard configuration settings.<br /> <br /> = Logger =<br /> <br /> The logger property (org.owasp.csrfguard.Logger) defines the qualified class name of the object responsible for processing all log messages produced by CSRFGuard. The default CSRFGuard logger is org.owasp.csrfguard.log.ConsoleLogger. This class logs all messages to System.out which JavaEE application servers redirect to a vendor specific log file. Developers can customize the logging behavior of CSRFGuard by implementing the org.owasp.csrfguard.log.ILogger interface and setting the logger property to the new logger's qualified class name. The following configuration snippet instructs OWASP CSRFGuard to capture all log messages to the console:<br /> <br /> org.owasp.csrfguard.Logger=org.owasp.csrfguard.log.ConsoleLogger<br /> <br /> = New Token Landing Page =<br /> <br /> The new token landing page property (org.owasp.csrfguard.NewTokenLandingPage) defines where to send a user if the token is being generated for the first time. CSRFGuard will redirect the user to the current page without any parameters if the property is not specified. Preventing the protected application from consuming a request whose session does not yet have a CSRF token through the use of a redirect prevents the execution of a one-time CSRF attack. The following configuration snippet instructs OWASP CSRFGuard to redirect the user to /Owasp.CsrfGuard.Test/index.html when they visit a protected resource without having a corresponding CSRF token present in the HttpSession object:<br /> <br /> org.owasp.csrfguard.NewTokenLandingPage=/Owasp.CsrfGuard.Test/index.html<br /> <br /> = Unique Token Per Page =<br /> <br /> The unique token per-page property (org.owasp.csrfguard.TokenPerPage) is a boolean value that determines if CSRFGuard should make use of unique per-page (i.e. URI) prevention tokens as opposed to unique per-session prevention tokens. When a user requests a protected resource, CSRFGuard will determine if a page specific token has been previously generated. If a page specific token has not yet been previously generated, CSRFGuard will verify the request was submitted with the per-session token intact. After verifying the presence of the per-session token, CSRFGuard will create a page specific token that is required for all subsequent requests to the associated resource. The per-session CSRF token can only be used when requesting a resource for the first time. All subsequent requests must have the per-page token intact or the request will be treated as a CSRF attack. Use of the unique token per page property is currently experimental but provides a significant amount of improved security. Consider the exposure of a CSRF token using the legacy unique per-session model. Exposure of this token facilitates the attacker's ability to carry out a CSRF attack against the victim's active session for any resource exposed by the web application. Now consider the exposure of a CSRF token using the experimental unique token per-page model. Exposure of this token would only allow the attacker to carry out a CSRF attack against the victim's active session for a small subset of resources exposed by the web application. Use of the unique token per-page property is a strong defense in depth strategy significantly reducing the impact of exposed CSRF prevention tokens. The following configuration snippet instructs OWASP CSRFGuard to utilize the unique token per-page model:<br /> <br /> org.owasp.csrfguard.TokenPerPage=true<br /> <br /> = Token Rotation =<br /> <br /> The rotate token property (org.owasp.csrfguard.Rotate) is a boolean value that determines if CSRFGuard should generate and utilize a new token after verifying the previous token. Rotation helps minimize the window of opportunity an attacker has to leverage the victim's stolen token in a targeted CSRF attack. However, this functionality generally causes navigation problems in most applications. Specifically, the 'Back' button in the browser will often cease to function properly. When a user hits the 'Back' button and interacts with the HTML, the browser may submit an old token causing CSRFGuard to incorrectly believe this request is a CSRF attack in progress (i.e. a 'false positive'). Users can prevent this scenario by preventing the caching of HTML pages containing FORM submissions using the cache-control header. However, this may also introduce performance problems as the browser will have to request HTML on a more frequent basis. The following configuration snippet disables token rotation:<br /> org.owasp.csrfguard.Rotate=false<br /> <br /> = Ajax and XMLHttpRequest Support =<br /> <br /> The Ajax property (org.owasp.csrfguard.Ajax) is a boolean value that indicates whether or not OWASP CSRFGuard should support the injection and verification of unique per-session prevention tokens for XMLHttpRequests. To leverage Ajax support, the user must not only set this property to true but must also reference the [[CSRFGuard_3_Token_Injection#JavaScript_DOM_Manipulation | JavaScript DOM Manipulation]] code using a script element. This dynamic script will override the send method of the XMLHttpRequest object to ensure the submission of an X-Requested-With header name value pair coupled with the submission of a custom header name value pair for each request. The name of the custom header is the value of the token name property and the value of the header is always the unique per-session token value. This custom header is analogous to the HTTP parameter name value pairs submitted via traditional GET and POST requests. If the X-Requested-With header was sent in the HTTP request, then CSRFGuard will look for the presence and ensure the validity of the unique per-session token in the custom header name value pair. Note that verification of these headers takes precedence over verification of the CSRF token supplied as an HTTP parameter. More specifically, CSRFGuard does not verify the presence of the CSRF token if the Ajax support property is enabled and the corresponding X-Requested-With and custom headers are embedded within the request. The following configuration snippet instructs OWASP CSRFGuard to support Ajax requests by verifying the presence and correctness of the X-Requested-With and custom headers:<br /> <br /> org.owasp.csrfguard.Ajax=true<br /> <br /> = Unprotected Pages =<br /> <br /> The unprotected pages property (org.owasp.csrfguard.unprotected.*) defines a series of pages that should not be protected by CSRFGuard. Such configurations are useful when the CsrfGuardFilter is aggressively mapped (ex: /*). The syntax of the property name is org.owasp.csrfguard.unprotected.[PageName], where PageName is some arbitrary identifier that can be used to reference a resource. The syntax of defining the uri of unprotected pages is the same as the syntax used by the JavaEE container for uri mapping. Specifically, CSRFGuard will identify the first match (if any) between the requested uri and an unprotected page in order of declaration. Match criteria is as follows:<br /> <br /> :Case 1: exact match between request uri and unprotected page<br /> :Case 2: longest path prefix match, beginning / and ending /*<br /> :Case 3: extension match, beginning *.<br /> :Default: requested resource must be validated by CSRFGuard<br /> <br /> The following code snippet illustrates the three use cases over four examples. The first two examples (Tag and JavaScriptServlet) look for direct URI matches. The third example (Html) looks for all resources ending in a .html extension. The last example (Public) looks for all resources prefixed with the URI path /MySite/Public/*.<br /> <br /> org.owasp.csrfguard.unprotected.Tag=/Owasp.CsrfGuard.Test/tag.jsp<br /> org.owasp.csrfguard.unprotected.JavaScriptServlet=/Owasp.CsrfGuard.Test/JavaScriptServlet<br /> org.owasp.csrfguard.unprotected.Html=*.html<br /> org.owasp.csrfguard.unprotected.Public=/MySite/Public/*<br /> <br /> = Actions: Responding to Attacks =<br /> <br /> The actions directive (org.owasp.csrfguard.action.*) gives the user the ability to specify one or more actions that should be invoked when a CSRF attack is detected. Every action must implement the org.owasp.csrfguard.action.IAction interface either directly or indirectly through the org.owasp.csrfguard.action.AbstractAction helper class. Many actions accept parameters that can be specified along with the action class declaration. These parameters are consumed at runtime and impact the behavior of the associated action.<br /> <br /> The syntax for defining and configuring CSRFGuard actions is relatively straight forward. Let us assume we wish to redirect the user to a default page when a CSRF attack is detected. A redirect action already exists within the CSRFGuard bundle and is available via the class name org.owasp.csrfguard.actions.Redirect. In order to enable this action, we capture the following declaration in the Owasp.CsrfGuard.properties file:<br /> <br /> '''syntax:''' org.owasp.csrfguard.action.[actionName]=[className]<br /> '''example:''' org.owasp.csrfguard.action.class.Redirect=org.owasp.csrfguard.actions.Redirect<br /> <br /> The aforementioned directive declares an action called &quot;Redirect&quot; (i.e. [actionName]) referencing the Java class &quot;org.owasp.csrfguard.actions.Redirect&quot; (i.e. [className]). Anytime a CSRF attack is detected, the Redirect action will be executed. You may be asking yourself, &quot;but how do I specify where the user is redirected?&quot;; this is where action parameters come into play. In order to specify the redirect location, we capture the following declaration in the Owasp.CsrfGuard.properties file:<br /> <br /> '''syntax:''' org.owasp.csrfguard.action.[actionName].[parameterName]=[parameterValue]<br /> '''example:''' org.owasp.csrfguard.action.Redirect.ErrorPage=/Owasp.CsrfGuard.Test/error.html<br /> <br /> The aforementioned directive declares an action parameter called &quot;ErrorPage&quot; (i.e. [parameterName]) with the value of &quot;/Owasp.CsrfGuard.Test/error.html&quot; (i.e. [parameterValue]) for the action &quot;Redirect&quot; (i.e. [actionName]). The Redirect action expects the &quot;ErrorPage&quot; parameter to be defined and will redirect the user to this location when an attack is detected.<br /> <br /> There are several &quot;out of the box&quot; actions made available with the OWASP CSRFGuard distributable. <br /> <br /> == org.owasp.csrfguard.action.Log ==<br /> <br /> Creates a customized log message whenever a CSRF attack is detected by OWASP CSRFGuard. The log message is captured using the logger mechanism defined by the ''org.owasp.csrfguard.Logger'' directive in the Owasp.CsrfGuard.properties file. Log accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.Log.Message'''<br /> <br /> Allows the user to define the format of the log message to be recorded. The Message parameter supports several formatting options to aide in the customization of the message to the particular attack. The following formatting options are supported:<br /> <br /> '''%exception%''' - String representation of the CsrfGuardException thrown by the CsrfGuard class.<br /> '''%exception_message%''' - Localized exception message of the class CsrfGuardException thrown by the CsrfGuard class.<br /> '''%remote_ip%''' - Remote IP address of the client that sent the CSRF attack to the server.<br /> '''%remote_host%''' - Remote host name of the client that sent the CSRF attack to the server.<br /> '''%remote_port%''' - Remote port of the client that sent the CSRF attack to the server.<br /> '''%local_ip%''' - Local IP address of the server that detected the CSRF attack.<br /> '''%local_host%''' - Local host name of the server that detected the CSRF attack.<br /> '''%local_port%''' - Local port of the server that detected the CSRF attack.<br /> '''%request_uri%''' - Request URI for which the CSRF attack was targeting.<br /> '''%request_url%''' - Request URL for which the CSRF attack was targeting.<br /> '''%user%''' - User information as made available by the javax.servlet.http.HttpServletRequest.getRemoteUser() method invocation.<br /> <br /> == org.owasp.csrfguard.action.Invalidate ==<br /> <br /> Invalidate any existing HttpSession associated with the current HttpServletRequest. Note that this is the session of the victim for which the CSRF attack was targeting. Invalidating the JavaEE container's session generally results in the user having to re-authenticate. There are no parameters associated with this action.<br /> <br /> == org.owasp.csrfguard.action.Redirect ==<br /> <br /> Redirects the user to the URI specified in the Page action parameter. Attempting to utilize this action in combination with Forward will generally result in the JavaEE container throwing IllegalStateException. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.Redirect.Page'''<br /> <br /> Defines the URI for which the user is redirected when a CSRF attack is detected.<br /> <br /> == org.owasp.csrfguard.action.Forward ==<br /> <br /> Forwards the user to the URI specified in the Page action parameter. Attempting to utilize this action in combination with Redirect will generally result in the JavaEE container throwing IllegalStateException. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.Forward.Page'''<br /> <br /> Defines the URI for which the user is forwarded when a CSRF attack is detected.<br /> <br /> == org.owasp.csrfguard.action.RequestAttribute ==<br /> <br /> Makes the CsrfGuardException thrown by the CsrfGuard class when an attack is detected programmatically available as an attribute in the HttpServletRequest object. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.RequestAttribute.AttributeName'''<br /> <br /> Defines the attribute name that should be used when placing the CsrfGuardException in the HttpServletRequest attributes collection.<br /> <br /> == org.owasp.csrfguard.action.SessionAttribute ==<br /> <br /> Makes the CsrfGuardException thrown by the CsrfGuard class when an attack is detected programmatically available as an attribute in the HttpSession object. The action accepts the following action parameters:<br /> <br /> '''org.owasp.csrfguard.action.SessionAttribute.AttributeName'''<br /> <br /> Defines the attribute name that should be used when placing the CsrfGuardException in the HttpSession attributes collection.<br /> <br /> == org.owasp.csrfguard.action.Rotate ==<br /> <br /> Invalidates and re-generates any existing CSRF prevention tokens associated with the current HttpSession. This action helps minimize the risk of a malicious user attempting to brute force a user's prevention tokens through timing based side channel attacks. Note that this action has no effect when used in conjunction with the Invalidate action. There are no parameters associated with this action.<br /> <br /> = Miscellaneous Configurations =<br /> <br /> == Token Name ==<br /> <br /> The token name property (org.owasp.csrfguard.TokenName) defines the name of the HTTP parameter to contain the value of the OWASP CSRFGuard token for each request. The following configuration snippet sets the CSRFGuard token parameter name to the value OWASP_CSRFTOKEN:<br /> org.owasp.csrfguard.TokenName=OWASP_CSRFTOKEN<br /> <br /> == Session Key ==<br /> <br /> The session key property (org.owasp.csrfguard.SessionKey) defines the string literal used to save and lookup the CSRFGuard token from the session. This value is used by the filter and the tag libraries to retrieve and set the token value in the session. Developers can use this key to programmatically lookup the token within their own code. The following configuration snippet sets the session key to the value OWASP_CSRFTOKEN:<br /> org.owasp.csrfguard.SessionKey=OWASP_CSRFTOKEN<br /> <br /> == Token Length ==<br /> <br /> The token length property (org.owasp.csrfguard.TokenLength) defines the number of characters that should be found within the CSRFGuard token. Note that characters are delimited by dashes (-) in groups of four. For cosmetic reasons, users are encourage to ensure the token length is divisible by four. The following configuration snippet sets the token length property to 32 characters:<br /> org.owasp.csrfguard.TokenLength=32<br /> <br /> == Pseudo-Random Number Generator ==<br /> <br /> The pseudo-random number generator property (org.owasp.csrfguard.PRNG) defines what PRNG should be used to generate the OWASP CSRFGuard token. Always ensure this value references a cryptographically strong pseudo-random number generator algorithm. The following configuration snippet sets the pseudo-random number generator to SHA1PRNG:<br /> org.owasp.csrfguard.PRNG=SHA1PRNG<br /> <br /> [[Category:OWASP CSRFGuard Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_Token_Injection&diff=96889 2010-12-18T18:30:59Z

<p>Esheridan: /* Declare and Configure JavaScriptServlet */</p> <hr /> <div>= Overview =<br /> <br /> OWASP CSRFGuard implements a variant of the synchronizer token pattern to mitigate the risk of CSRF attacks. In order to implement this pattern, CSRFGuard must offer the capability to place the CSRF prevention token within the HTML produced by the protected web application. CSRFGuard 3 provides developers more fine grain control over the injection of the token. Developers can inject the token in their HTML using either dynamic JavaScript DOM manipulation or a JSP tag library. CSRFGuard no longer intercepts and modifies the HttpServletResponse object as was done in previous releases. The currently available token injection strategies are designed to make the integration of CSRFGuard more feasible and scalable within current enterprise web applications. Developers are encouraged to make use of both the JavaScript DOM Manipulation and the JSP tag library strategies for a complete token injection strategy. The JavaScript DOM Manipulation strategy is ideal as it is automated and requires minimal effort on behalf of the developer. In the event the JavaScript solution is insufficient within a particular application context, developers should leverage the JSP tag library. The purpose of this article is to describe the token injection strategies offered by OWASP CSRFGuard 3.<br /> <br /> = JavaScript DOM Manipulation =<br /> <br /> OWASP CSRFGuard 3 supports the ability to dynamically inject CSRF prevention tokens throughout the DOM currently loaded in the user's browser. This strategy is extremely valuable with regards to server-side performance as it simply requires the serving of a dynamic JavaScript file. There is little to no performance hit when the fetched dynamic JavaScript updates the browser's DOM. Making use of the JavaScript token injection solution requires the developer map a Servlet and place a JavaScript HTML tag within all pages sending requests to protected application resources. Developers are strongly encouraged to leverage the JavaScript token injection strategy by default. This strategy requires minimal effort on behalf of the developer as most of the token injection logic is automated. In the event that the JavaScript automated solution may be insufficient for a specific application context, developers should leverage the OWASP CSRFGuard JSP tag library.<br /> <br /> '''Note:''' Use of JavaScript DOM Manipulation is required for Ajax support.<br /> <br /> == Declare and Configure JavaScriptServlet ==<br /> <br /> The JavaScript file used for token injection is dynamically generated by the JavaScriptServlet class using a template file. Ensure that the Owasp.CsrfGuard.jar file is found within the target application's classpath. Copy the Owasp.CsrfGuard.js template file from the OWASP CSRFGuard distribution folder to a non-publicly accessible directory within the target application. For the remainder of this section, we assume the Owasp.CsrfGuard.js template file was placed in the application's WEB-INF folder. Edit the deployment descriptor (web.xml) to declare the JavaScriptServlet class along with any associated initialization parameters. Consider the following configuration snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;servlet-class&gt;org.owasp.csrfguard.servlet.JavaScriptServlet&lt;/servlet-class&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;source-file&lt;/param-name&gt;<br /> &lt;param-value&gt;WEB-INF/Owasp.CsrfGuard.js&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-forms&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-attributes&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;domain-strict&lt;/param-name&gt;<br /> &lt;param-value&gt;false&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;/servlet&gt;<br /> <br /> The aforementioned configuration snippet declares the JavaScriptServlet class using the name &quot;JavaScriptServlet&quot;. JavaScriptServlet accepts various initialization parameters augmenting the behavior of the class at runtime. The provided configuration snippet instructs JavaScriptServlet to...<br /> <br /> #Leverage the template JavaScript file at WEB-INF/Owasp.CsrfGuard.js<br /> #Inject the token into all HTML forms<br /> #Inject the token into all src and href attributes<br /> #Leverage loose same origin matching criteria when placing the token in URL resources<br /> <br /> Consider the following for a more detailed listing of the initialization parameters supported by JavaScriptServlet:<br /> <br /> source-file<br /> <br /> Denotes the location of the JavaScript template file that should be consumed and dynamically augmented by the JavaScriptServlet class. The default value is WEB-INF/Owasp.CsrfGuard.js. Use of this property and the existence of the specified template file is required. <br /> <br /> domain-strict<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should be strict with regards to what links it should inject the CSRF prevention token. With a value of true, the JavaScript code will only place the token in links that point to the same exact domain from which the HTML originated. With a value of false, the JavaScript code will place the token in links that not only point to the same exact domain from which the HTML originated, but sub-domains as well.<br /> <br /> referer-pattern<br /> <br /> Allows the developer to specify a regular expression describing the required value of the Referer header. Any attempts to access the servlet with a Referer header that does not match the captured expression is discarded. Inclusion of referer header checking is to help minimize the risk of JavaScript Hijacking attacks that attempt to steal tokens from the dynamically generated JavaScript. While the primary defenses against JavaScript Hijacking attacks are implemented within the dynamic JavaScript itself, referer header checking is implemented to achieve defense in depth.<br /> <br /> cache-control<br /> <br /> Allows the developer to specify the value of the Cache-Control header in the HTTP response when serving the dynamic JavaScript file. The default value is private, maxage=28800. Caching of the dynamic JavaScript file is intended to minimize traffic and improve performance. Note that the Cache-Control header is always set to &quot;no-store&quot; when either the &quot;Rotate&quot; &quot;TokenPerPage&quot; options is set to true in Owasp.CsrfGuard.properties.<br /> <br /> inject-into-forms<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token as a hidden field into HTML forms. The default value is true. Developers are strongly discouraged from disabling this property as most server-side state changing actions are triggered via a POST request.<br /> <br /> inject-into-attributes<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token in the query string of src and href attributes. Injecting the CSRF prevention token in a URL resource increases its general risk of exposure to unauthorized parties. However, most JavaEE web applications respond in the exact same manner to HTTP requests and their associated parameters regardless of the HTTP method. The risk associated with not protecting GET requests in this situation is perceived greater than the risk of exposing the token in protected GET requests. As a result, the default value of this attribute is set to true. Developers that are confident their server-side state changing controllers will only respond to POST requests (i.e. discarding GET requests) are strongly encouraged to disable this property.<br /> <br /> == Map JavaScriptServlet ==<br /> <br /> Developers must map the JavaScriptServlet to a URI space such that the Servlet class can be remotely accessed by the dynamic JavaScript code. Consider the following configuration snippet taken directly from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet-mapping&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;url-pattern&gt;/JavaScriptServlet&lt;/url-pattern&gt;<br /> &lt;/servlet-mapping&gt;<br /> <br /> The aforementioned configuration snippet maps the Servlet referenced by the name &quot;JavaScriptServlet&quot; to the URI space &quot;/JavaScriptServlet&quot;. Any request sent to the /JavaScriptServlet URI will produce a dynamically generated CSRFGuard JavaScript file specific to the user's current session.<br /> <br /> == Inject Dynamic JavaScript ==<br /> <br /> Developers are required to place an HTML script tag within all pages that are known to send requests to CSRF protected resources. All requests within the current HTML page are augmented to ensure they submit the correct CSRF token for the user's current session. Note that inclusion of the dynamic JavaScript does not protect the current page. Rather, the script ensures the CSRF token is transmitted within all requests generated by the current page. Consider the following code snippet taken directly from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;!-- OWASP CSRFGuard Support --&gt;<br /> &lt;script src=&quot;/Owasp.CsrfGuard.Test/JavaScriptServlet&quot;&gt;&lt;/script&gt;<br /> <br /> The script tag retrieves and executes the dynamically generated JavaScript from the Servlet mapped at /Owasp.CsrfGuard.Test/JavaScriptServlet. This JavaScript code will register an event handler with window.onload. Once triggered, the code will iterate over every HTML element within the DOM looking for either form tags and or tags containing href or src attributes as configured by the JavaScriptServlet initialization parameters. Forms are dynamically updated to include the CSRFGuard token via a hidden field and tags using src and href attributes are updated to include the CSRFGuard token via a query string parameter.<br /> <br /> = JSP Tag Library =<br /> <br /> OWASP CSRFGuard 3 exposes a JSP tag library providing developers more fine grain control over token injection. The library exposes JSP tags that allow access to the token name, the token value, and the token name value pair delimited by an equals (=) sign. In order to make use of the tag library, ensure the Owasp.CsrfGuard.jar file is found within the target application's classpath. For example, the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application places the OWASP CSRFGuard jar file within the WebContent/WEB-INF/lib directory. After placing the library in the classpath, developers can reference the tags in JSP pages using predefined URI reference. The following JSP code snippet imports the tag library and makes it available using the prefix &quot;csrf&quot;:<br /> <br /> &lt;%@ taglib uri=&quot;http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project/Owasp.CsrfGuard.tld&quot; prefix=&quot;csrf&quot; %&gt;<br /> <br /> The benefit of using the JSP tag library to inject the CSRF prevention token is the fine grain level of control. Developers can place the token in all the correct locations within the context of their applications. This strategy is useful in application contexts where the JavaScript DOM Manipulation strategy is insufficient.<br /> <br /> == Display Token Name ==<br /> <br /> The OWASP CSRFGuard token name can be obtained through the token-name tag. The token-name tag is useful when injecting the CSRFGuard token name in a non-query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-name tag to reference the token name in the name attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;'''&lt;csrf:token-name/&gt;'''&quot; value=&quot;&lt;csrf:token-value/&gt;&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Value ==<br /> <br /> The OWASP CSRFGuard token value can be obtained through the token-value tag. The token-value tag is useful when injecting the CSRFGuard token value in a non-query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-value tag to reference the token value in the value attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;&lt;csrf:token-name/&gt;&quot; value=&quot;'''&lt;csrf:token-value/&gt;'''&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> The token value tag must be used in conjunction with the URI attribute when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The value of the uri attribute is the URI for which the token value will be posted. Consider the following example which sets the URI to the destination of the form, &quot;protect.html&quot;:<br /> <br /> &lt;form id=&quot;formTest1&quot; name=&quot;formTest1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;&lt;csrf:token-name/&gt;&quot; value=&quot;&lt;csrf:token-value uri=&quot;protect.html&quot;/&gt;&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Name Value Pair ==<br /> <br /> The OWASP CSRFGuard token name value pair, delimited by an equals sign (=), can be obtained though the token tag. The token tag is useful when injecting the CSRFGuard token value in a query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token tag to reference the token name value pair in the href attribute of an anchor tag:<br /> <br /> &lt;a href=&quot;protect.html?&lt;csrf:token/&gt;&quot;&gt;protect.html&lt;/a&gt;<br /> <br /> The token name value pair tag must be used in conjunction with the URI attribute when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The value of the uri attribute is the URI for which the token value will be posted. Consider the following example which sets the URI to the destination of the link, &quot;protect.html&quot;:<br /> <br /> &lt;a href=&quot;protect.html?&lt;csrf:token uri=&quot;protect.html&quot;/&gt;&quot;&gt;protect.html&lt;/a&gt;<br /> <br /> == Generate Form with Prevention Token ==<br /> <br /> The OWASP CSRFGuard JSP library implements a tag library designed specifically to generate HTML forms with the CSRF prevention token automatically embedded as a hidden field. This strategy simplifies the integration of the CSRF token, especially when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The tag accepts dynamic attribute name value pairs and simply outputs them to the page. As a result, you are free to use the same attribute values made available in a standard HTML form. There is no special output encoding performed on these dynamic attributes. Take care to perform the appropriate validation and output encoding for all dynamic attributes used in conjunction with untrusted data. Consider the following code snippet which will produce a HTML form with an embedded CSRF token. No special care must be taken when using this flag in conjunction with the unique token per uri model:<br /> <br /> &lt;csrf:form id=&quot;formTest2&quot; name=&quot;formTest2&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;/csrf:form&gt;<br /> <br /> == Generate Link with Prevention Token ==<br /> <br /> The OWASP CSRFGuard JSP library implements a tag library designed specifically to generate HTML anchor tags with the CSRF prevention token automatically embedded as a query string parameter. This strategy simplifies the integration of the CSRF token, especially when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The tag accepts dynamic attribute name value pairs and simply outputs them to the page. As a result, you are free to use the same attribute values made available in a standard HTML anchor. There is no special output encoding performed on these dynamic attributes. Take care to perform the appropriate validation and output encoding for all dynamic attributes used in conjunction with untrusted data. Consider the following code snippet which will produce a HTML anchor tag with an embedded CSRF token. No special care must be taken when using this flag in conjunction with the unique token per uri model:<br /> <br /> &lt;csrf:a href=&quot;protect.html&quot;&gt;protect.html&lt;/csrf:a&gt;</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_User_Manual&diff=96692 2010-12-16T16:06:17Z

<p>Esheridan: </p> <hr /> <div>= Overview =<br /> <br /> Welcome to the OWASP CSRFGuard 3 User Manual! The purpose of this article is to provide the user with guidance on obtaining, installing, deploying, and developing with the OWASP CSRFGuard library. The author's goal was to keep the User Manual informative, use to understand, and concise. If you find that one or more aspects of this document does not adhere to these goals, please me know at eric dot sheridan at owasp dot org.<br /> <br /> = Download =<br /> <br /> Users can download the latest release of OWASP CSRFGuard using one of the following links:<br /> <br /> :[http://code.google.com/p/owaspcsrfguard/downloads/detail?name=OWASP%20CSRFGuard%20%283.0.0.245%20-%20ALPHA%29.zip&amp;can=2&amp;q= OWASP CSRFGuard 3.0.0.245 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> = Installation =<br /> <br /> Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps:<br /> <br /> :# Copy the Owasp.CsrfGuard.jar file to your application's classpath<br /> :# Map the CsrfGuardFilter in your application's deployment descriptor (web.xml)<br /> :# Configure the Owasp.CsrfGuard.properties file as you see fit<br /> <br /> [[CSRFGuard_3_Installation | Click here]] for more detailed information regarding the installation of OWASP CSRFGuard.<br /> <br /> = Configuration =<br /> <br /> The minimum configuration settings that users should review include:<br /> <br /> :* Default new token landing page (org.owasp.csrfguard.NewTokenLandingPage)<br /> :* Support for Ajax and XMLHttpRequest (org.owasp.csrfguard.Ajax)<br /> :* URI resources that should not be protected (org.owasp.csrfguard.unprotected.*)<br /> :* Actions executed when an attack is detected (org.owasp.csrfguard.action.*)<br /> <br /> [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> = Token Injection =<br /> <br /> Users of OWASP CSRFGuard can inject prevention tokens into HTML using two strategies:<br /> <br /> :* JavaScript DOM Manipulation - largely automated process requiring minimal effort and is ideal for most web applications<br /> :* JSP Tag Library - provides fine grained strategy ideal for situations where automated DOM manipulation is insufficient.<br /> <br /> [[CSRFGuard_3_Token_Injection | Click here]] for more information regarding the injection of CSRF prevention tokens within your application.<br /> <br /> = Known Issues =<br /> <br /> The following is a quick bulleted list of known issues within the current release:<br /> <br /> :* Ajax support does not yet work in Internet Explorer<br /> :* Ajax support coupled with the TokenPerPage option only works as expected in Google Chrome. The Ajax request is not being triggered correctly in other browsers.<br /> <br /> [[Category:OWASP_CSRFGuard_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=96630 2010-12-16T02:30:32Z

<p>Esheridan: </p> <hr /> <div>== Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> [http://ericsheridan.blogspot.com/ Eric Sheridan] (eric dot sheridan at owasp dot org) is the lead and primary developer of the OWASP CSRFGuard project. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). He is a Principal Consultant at Aspect Security specializing in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the SVN repository online at http://owaspcsrfguard.googlecode.com<br /> <br /> == Downloads ==<br /> <br /> [http://code.google.com/p/owaspcsrfguard/downloads/detail?name=OWASP%20CSRFGuard%20%283.0.0.336%20-%20ALPHA%29.zip&amp;can=2&amp;q= OWASP CSRFGuard 3.0.0.336 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=Category:OWASP_CSRFGuard_Project&diff=96629 2010-12-16T01:59:51Z

<p>Esheridan: /* Downloads */</p> <hr /> <div>== Overview ==<br /> <br /> Welcome to the home of the OWASP CSRFGuard Project! OWASP CSRFGuard is a library that implements a variant of the [http://www.corej2eepatterns.com/Design/PresoDesign.htm synchronizer token pattern] to mitigate the risk of [[Cross-Site Request Forgery]] (CSRF) attacks. The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated and manual ways to integrate per-session or pseudo-per-request tokens into HTML. When a user interacts with this HTML, CSRF prevention tokens (i.e. cryptographically random synchronizer tokens) are submitted with the corresponding HTTP request. It is the responsibility of OWASP CSRFGuard to ensure the token is present and is valid for the current HTTP request. Any attempt to submit a request to a protected resource without the correct corresponding token is viewed as a CSRF attack in progress and is discarded. Prior to discarding the request, CSRFGuard can be configured to take one or more actions such as logging aspects of the request and redirecting the user to a landing page. The latest release enhances this strategy to support the optional verification of HTTP requests submitted using Ajax as well as the optional verification of referrer headers.<br /> <br /> == Project Lead ==<br /> <br /> Eric Sheridan (eric dot sheridan at owasp dot org) is the lead and primary developer of the OWASP CSRFGuard project. Aside from leading up CSRFGuard, Eric has contributed to or provided guidance on numerous other OWASP projects including the Cross-Site Request Forgery Prevention Cheat Sheet, WebGoat, Stinger, CSRFTester, and Enterprise Security API (ESAPI). He is a Principal Consultant at Aspect Security specializing in a wide variety of application security activities including static analysis, penetration tests, code reviews, and threat modeling. In his personal time... wait, what is that?<br /> <br /> == License ==<br /> <br /> OWASP CSRFGuard is offered under the [http://www.opensource.org/licenses/bsd-license.php BSD] license. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.<br /> <br /> == Email List ==<br /> <br /> You can sign up for the OWASP CSRFGuard email list at [https://lists.owasp.org/mailman/listinfo/owasp-csrfguard https://lists.owasp.org/mailman/listinfo/owasp-csrfguard]<br /> <br /> == Source Code ==<br /> <br /> You can access the SVN repository online at http://owaspcsrfguard.googlecode.com<br /> <br /> == Downloads ==<br /> <br /> [http://code.google.com/p/owaspcsrfguard/downloads/detail?name=OWASP%20CSRFGuard%20%283.0.0.336%20-%20ALPHA%29.zip&amp;can=2&amp;q= OWASP CSRFGuard 3.0.0.336 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> [[CSRFGuard_Deprecated_Releases | Deprecated Releases]] - article containing several download references to deprecated and officially unsupported releases<br /> <br /> == User Manual(s) ==<br /> <br /> [[CSRFGuard_3_User_Manual | OWASP CSRFGuard v3 ]] - series of articles describing the installation, configuration, and deployment of OWASP CSRFGuard v3.<br /> <br /> == References ==<br /> <br /> :*[http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester ] - utility to assist in the testing and generating PoC for CSRF attacks.<br /> :*[[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet | OWASP CSRF Prevention Cheat Sheet]] - provides a more holistic overview of CSRF prevention strategies and associated frameworks.<br /> :*http://www.owasp.org/index.php/PHP_CSRF_Guard - project implementing CSRFGuard style solution for PHP.<br /> :*http://www.thespanner.co.uk/2007/10/19/jsck/ - project implementing CSRFGuard style solution for PHP and JavaScript.<br /> :*http://www.owasp.org/index.php/.Net_CSRF_Guard - project implementing CSRFGuard style solution for ASP.NET.<br /> <br /> == Project Sponsors == <br /> <br /> [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> <br /> [[Category:OWASP_Validation_Project]]<br /> [[Category:Java]]<br /> [[Category:OWASP_Project|CSRFGuard Project]]<br /> [[Category:OWASP_Java_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_Token_Injection&diff=96628 2010-12-16T01:35:35Z

<p>Esheridan: /* JSP Tag Library */</p> <hr /> <div>= Overview =<br /> <br /> OWASP CSRFGuard implements a variant of the synchronizer token pattern to mitigate the risk of CSRF attacks. In order to implement this pattern, CSRFGuard must offer the capability to place the CSRF prevention token within the HTML produced by the protected web application. CSRFGuard 3 provides developers more fine grain control over the injection of the token. Developers can inject the token in their HTML using either dynamic JavaScript DOM manipulation or a JSP tag library. CSRFGuard no longer intercepts and modifies the HttpServletResponse object as was done in previous releases. The currently available token injection strategies are designed to make the integration of CSRFGuard more feasible and scalable within current enterprise web applications. Developers are encouraged to make use of both the JavaScript DOM Manipulation and the JSP tag library strategies for a complete token injection strategy. The JavaScript DOM Manipulation strategy is ideal as it is automated and requires minimal effort on behalf of the developer. In the event the JavaScript solution is insufficient within a particular application context, developers should leverage the JSP tag library. The purpose of this article is to describe the token injection strategies offered by OWASP CSRFGuard 3.<br /> <br /> = JavaScript DOM Manipulation =<br /> <br /> OWASP CSRFGuard 3 supports the ability to dynamically inject CSRF prevention tokens throughout the DOM currently loaded in the user's browser. This strategy is extremely valuable with regards to server-side performance as it simply requires the serving of a dynamic JavaScript file. There is little to no performance hit when the fetched dynamic JavaScript updates the browser's DOM. Making use of the JavaScript token injection solution requires the developer map a Servlet and place a JavaScript HTML tag within all pages sending requests to protected application resources. Developers are strongly encouraged to leverage the JavaScript token injection strategy by default. This strategy requires minimal effort on behalf of the developer as most of the token injection logic is automated. In the event that the JavaScript automated solution may be insufficient for a specific application context, developers should leverage the OWASP CSRFGuard JSP tag library.<br /> <br /> '''Note:''' Use of JavaScript DOM Manipulation is required for Ajax support.<br /> <br /> == Declare and Configure JavaScriptServlet ==<br /> <br /> The JavaScript file used for token injection is dynamically generated by the JavaScriptServlet class using a template file. Ensure that the Owasp.CsrfGuard.jar file is found within the target application's classpath. Copy the Owasp.CsrfGuard.js template file from the OWASP CSRFGuard distribution folder to a non-publicly accessible directory within the target application. For the remainder of this section, we assume the Owasp.CsrfGuard.js template file was placed in the application's WEB-INF folder. Edit the deployment descriptor (web.xml) to declare the JavaScriptServlet class along with any associated initialization parameters. Consider the following configuration snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;servlet-class&gt;org.owasp.csrfguard.servlet.JavaScriptServlet&lt;/servlet-class&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;source-file&lt;/param-name&gt;<br /> &lt;param-value&gt;WEB-INF/Owasp.CsrfGuard.js&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-forms&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-attributes&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;domain-strict&lt;/param-name&gt;<br /> &lt;param-value&gt;false&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;/servlet&gt;<br /> <br /> The aforementioned configuration snippet declares the JavaScriptServlet class using the name &quot;JavaScriptServlet&quot;. JavaScriptServlet accepts various initialization parameters augmenting the behavior of the class at runtime. The provided configuration snippet instructs JavaScriptServlet to...<br /> <br /> #Leverage the template JavaScript file at WEB-INF/Owasp.CsrfGuard.js<br /> #Inject the token into all HTML forms<br /> #Inject the token into all src and href attributes<br /> #Leverage loose same origin matching criteria when placing the token in URL resources<br /> <br /> Consider the following for a more detailed listing of the initialization parameters supported by JavaScriptServlet:<br /> <br /> source-file<br /> <br /> Denotes the location of the JavaScript template file that should be consumed and dynamically augmented by the JavaScriptServlet class. The default value is WEB-INF/Owasp.CsrfGuard.js. Use of this property and the existence of the specified template file is required. <br /> <br /> domain-strict<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should be strict with regards to what links it should inject the CSRF prevention token. With a value of true, the JavaScript code will only place the token in links that point to the same exact origin from which the HTML originated. With a value of false, the JavaScript code will place the token in links that contain, but may not exactly match, the originating domain.<br /> <br /> referer-pattern<br /> <br /> Allows the developer to specify a regular expression describing the required value of the Referer header. Any attempts to access the servlet with a Referer header that does not match the captured expression is discarded. Inclusion of referer header checking is to help minimize the risk of JavaScript Hijacking attacks that attempt to steal tokens from the dynamically generated JavaScript. While the primary defenses against JavaScript Hijacking attacks are implemented within the dynamic JavaScript itself, referer header checking is implemented to achieve defense in depth.<br /> <br /> cache-control<br /> <br /> Allows the developer to specify the value of the Cache-Control header in the HTTP response when serving the dynamic JavaScript file. The default value is private, maxage=28800. Caching of the dynamic JavaScript file is intended to minimize traffic and improve performance. Note that the Cache-Control header is always set to &quot;no-store&quot; when either the &quot;Rotate&quot; &quot;TokenPerPage&quot; options is set to true in Owasp.CsrfGuard.properties.<br /> <br /> inject-into-forms<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token as a hidden field into HTML forms. The default value is true. Developers are strongly discouraged from disabling this property as most server-side state changing actions are triggered via a POST request.<br /> <br /> inject-into-attributes<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token in the query string of src and href attributes. Injecting the CSRF prevention token in a URL resource increases its general risk of exposure to unauthorized parties. However, most JavaEE web applications respond in the exact same manner to HTTP requests and their associated parameters regardless of the HTTP method. The risk associated with not protecting GET requests in this situation is perceived greater than the risk of exposing the token in protected GET requests. As a result, the default value of this attribute is set to true. Developers that are confident their server-side state changing controllers will only respond to POST requests (i.e. discarding GET requests) are strongly encouraged to disable this property.<br /> <br /> == Map JavaScriptServlet ==<br /> <br /> Developers must map the JavaScriptServlet to a URI space such that the Servlet class can be remotely accessed by the dynamic JavaScript code. Consider the following configuration snippet taken directly from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet-mapping&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;url-pattern&gt;/JavaScriptServlet&lt;/url-pattern&gt;<br /> &lt;/servlet-mapping&gt;<br /> <br /> The aforementioned configuration snippet maps the Servlet referenced by the name &quot;JavaScriptServlet&quot; to the URI space &quot;/JavaScriptServlet&quot;. Any request sent to the /JavaScriptServlet URI will produce a dynamically generated CSRFGuard JavaScript file specific to the user's current session.<br /> <br /> == Inject Dynamic JavaScript ==<br /> <br /> Developers are required to place an HTML script tag within all pages that are known to send requests to CSRF protected resources. All requests within the current HTML page are augmented to ensure they submit the correct CSRF token for the user's current session. Note that inclusion of the dynamic JavaScript does not protect the current page. Rather, the script ensures the CSRF token is transmitted within all requests generated by the current page. Consider the following code snippet taken directly from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;!-- OWASP CSRFGuard Support --&gt;<br /> &lt;script src=&quot;/Owasp.CsrfGuard.Test/JavaScriptServlet&quot;&gt;&lt;/script&gt;<br /> <br /> The script tag retrieves and executes the dynamically generated JavaScript from the Servlet mapped at /Owasp.CsrfGuard.Test/JavaScriptServlet. This JavaScript code will register an event handler with window.onload. Once triggered, the code will iterate over every HTML element within the DOM looking for either form tags and or tags containing href or src attributes as configured by the JavaScriptServlet initialization parameters. Forms are dynamically updated to include the CSRFGuard token via a hidden field and tags using src and href attributes are updated to include the CSRFGuard token via a query string parameter.<br /> <br /> = JSP Tag Library =<br /> <br /> OWASP CSRFGuard 3 exposes a JSP tag library providing developers more fine grain control over token injection. The library exposes JSP tags that allow access to the token name, the token value, and the token name value pair delimited by an equals (=) sign. In order to make use of the tag library, ensure the Owasp.CsrfGuard.jar file is found within the target application's classpath. For example, the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application places the OWASP CSRFGuard jar file within the WebContent/WEB-INF/lib directory. After placing the library in the classpath, developers can reference the tags in JSP pages using predefined URI reference. The following JSP code snippet imports the tag library and makes it available using the prefix &quot;csrf&quot;:<br /> <br /> &lt;%@ taglib uri=&quot;http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project/Owasp.CsrfGuard.tld&quot; prefix=&quot;csrf&quot; %&gt;<br /> <br /> The benefit of using the JSP tag library to inject the CSRF prevention token is the fine grain level of control. Developers can place the token in all the correct locations within the context of their applications. This strategy is useful in application contexts where the JavaScript DOM Manipulation strategy is insufficient.<br /> <br /> == Display Token Name ==<br /> <br /> The OWASP CSRFGuard token name can be obtained through the token-name tag. The token-name tag is useful when injecting the CSRFGuard token name in a non-query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-name tag to reference the token name in the name attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;'''&lt;csrf:token-name/&gt;'''&quot; value=&quot;&lt;csrf:token-value/&gt;&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Value ==<br /> <br /> The OWASP CSRFGuard token value can be obtained through the token-value tag. The token-value tag is useful when injecting the CSRFGuard token value in a non-query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-value tag to reference the token value in the value attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;&lt;csrf:token-name/&gt;&quot; value=&quot;'''&lt;csrf:token-value/&gt;'''&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> The token value tag must be used in conjunction with the URI attribute when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The value of the uri attribute is the URI for which the token value will be posted. Consider the following example which sets the URI to the destination of the form, &quot;protect.html&quot;:<br /> <br /> &lt;form id=&quot;formTest1&quot; name=&quot;formTest1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;&lt;csrf:token-name/&gt;&quot; value=&quot;&lt;csrf:token-value uri=&quot;protect.html&quot;/&gt;&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Name Value Pair ==<br /> <br /> The OWASP CSRFGuard token name value pair, delimited by an equals sign (=), can be obtained though the token tag. The token tag is useful when injecting the CSRFGuard token value in a query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token tag to reference the token name value pair in the href attribute of an anchor tag:<br /> <br /> &lt;a href=&quot;protect.html?&lt;csrf:token/&gt;&quot;&gt;protect.html&lt;/a&gt;<br /> <br /> The token name value pair tag must be used in conjunction with the URI attribute when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The value of the uri attribute is the URI for which the token value will be posted. Consider the following example which sets the URI to the destination of the link, &quot;protect.html&quot;:<br /> <br /> &lt;a href=&quot;protect.html?&lt;csrf:token uri=&quot;protect.html&quot;/&gt;&quot;&gt;protect.html&lt;/a&gt;<br /> <br /> == Generate Form with Prevention Token ==<br /> <br /> The OWASP CSRFGuard JSP library implements a tag library designed specifically to generate HTML forms with the CSRF prevention token automatically embedded as a hidden field. This strategy simplifies the integration of the CSRF token, especially when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The tag accepts dynamic attribute name value pairs and simply outputs them to the page. As a result, you are free to use the same attribute values made available in a standard HTML form. There is no special output encoding performed on these dynamic attributes. Take care to perform the appropriate validation and output encoding for all dynamic attributes used in conjunction with untrusted data. Consider the following code snippet which will produce a HTML form with an embedded CSRF token. No special care must be taken when using this flag in conjunction with the unique token per uri model:<br /> <br /> &lt;csrf:form id=&quot;formTest2&quot; name=&quot;formTest2&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;/csrf:form&gt;<br /> <br /> == Generate Link with Prevention Token ==<br /> <br /> The OWASP CSRFGuard JSP library implements a tag library designed specifically to generate HTML anchor tags with the CSRF prevention token automatically embedded as a query string parameter. This strategy simplifies the integration of the CSRF token, especially when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The tag accepts dynamic attribute name value pairs and simply outputs them to the page. As a result, you are free to use the same attribute values made available in a standard HTML anchor. There is no special output encoding performed on these dynamic attributes. Take care to perform the appropriate validation and output encoding for all dynamic attributes used in conjunction with untrusted data. Consider the following code snippet which will produce a HTML anchor tag with an embedded CSRF token. No special care must be taken when using this flag in conjunction with the unique token per uri model:<br /> <br /> &lt;csrf:a href=&quot;protect.html&quot;&gt;protect.html&lt;/csrf:a&gt;</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_Token_Injection&diff=96627 2010-12-16T01:32:12Z

<p>Esheridan: /* JSP Tag Library */</p> <hr /> <div>= Overview =<br /> <br /> OWASP CSRFGuard implements a variant of the synchronizer token pattern to mitigate the risk of CSRF attacks. In order to implement this pattern, CSRFGuard must offer the capability to place the CSRF prevention token within the HTML produced by the protected web application. CSRFGuard 3 provides developers more fine grain control over the injection of the token. Developers can inject the token in their HTML using either dynamic JavaScript DOM manipulation or a JSP tag library. CSRFGuard no longer intercepts and modifies the HttpServletResponse object as was done in previous releases. The currently available token injection strategies are designed to make the integration of CSRFGuard more feasible and scalable within current enterprise web applications. Developers are encouraged to make use of both the JavaScript DOM Manipulation and the JSP tag library strategies for a complete token injection strategy. The JavaScript DOM Manipulation strategy is ideal as it is automated and requires minimal effort on behalf of the developer. In the event the JavaScript solution is insufficient within a particular application context, developers should leverage the JSP tag library. The purpose of this article is to describe the token injection strategies offered by OWASP CSRFGuard 3.<br /> <br /> = JavaScript DOM Manipulation =<br /> <br /> OWASP CSRFGuard 3 supports the ability to dynamically inject CSRF prevention tokens throughout the DOM currently loaded in the user's browser. This strategy is extremely valuable with regards to server-side performance as it simply requires the serving of a dynamic JavaScript file. There is little to no performance hit when the fetched dynamic JavaScript updates the browser's DOM. Making use of the JavaScript token injection solution requires the developer map a Servlet and place a JavaScript HTML tag within all pages sending requests to protected application resources. Developers are strongly encouraged to leverage the JavaScript token injection strategy by default. This strategy requires minimal effort on behalf of the developer as most of the token injection logic is automated. In the event that the JavaScript automated solution may be insufficient for a specific application context, developers should leverage the OWASP CSRFGuard JSP tag library.<br /> <br /> '''Note:''' Use of JavaScript DOM Manipulation is required for Ajax support.<br /> <br /> == Declare and Configure JavaScriptServlet ==<br /> <br /> The JavaScript file used for token injection is dynamically generated by the JavaScriptServlet class using a template file. Ensure that the Owasp.CsrfGuard.jar file is found within the target application's classpath. Copy the Owasp.CsrfGuard.js template file from the OWASP CSRFGuard distribution folder to a non-publicly accessible directory within the target application. For the remainder of this section, we assume the Owasp.CsrfGuard.js template file was placed in the application's WEB-INF folder. Edit the deployment descriptor (web.xml) to declare the JavaScriptServlet class along with any associated initialization parameters. Consider the following configuration snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;servlet-class&gt;org.owasp.csrfguard.servlet.JavaScriptServlet&lt;/servlet-class&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;source-file&lt;/param-name&gt;<br /> &lt;param-value&gt;WEB-INF/Owasp.CsrfGuard.js&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-forms&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-attributes&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;domain-strict&lt;/param-name&gt;<br /> &lt;param-value&gt;false&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;/servlet&gt;<br /> <br /> The aforementioned configuration snippet declares the JavaScriptServlet class using the name &quot;JavaScriptServlet&quot;. JavaScriptServlet accepts various initialization parameters augmenting the behavior of the class at runtime. The provided configuration snippet instructs JavaScriptServlet to...<br /> <br /> #Leverage the template JavaScript file at WEB-INF/Owasp.CsrfGuard.js<br /> #Inject the token into all HTML forms<br /> #Inject the token into all src and href attributes<br /> #Leverage loose same origin matching criteria when placing the token in URL resources<br /> <br /> Consider the following for a more detailed listing of the initialization parameters supported by JavaScriptServlet:<br /> <br /> source-file<br /> <br /> Denotes the location of the JavaScript template file that should be consumed and dynamically augmented by the JavaScriptServlet class. The default value is WEB-INF/Owasp.CsrfGuard.js. Use of this property and the existence of the specified template file is required. <br /> <br /> domain-strict<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should be strict with regards to what links it should inject the CSRF prevention token. With a value of true, the JavaScript code will only place the token in links that point to the same exact origin from which the HTML originated. With a value of false, the JavaScript code will place the token in links that contain, but may not exactly match, the originating domain.<br /> <br /> referer-pattern<br /> <br /> Allows the developer to specify a regular expression describing the required value of the Referer header. Any attempts to access the servlet with a Referer header that does not match the captured expression is discarded. Inclusion of referer header checking is to help minimize the risk of JavaScript Hijacking attacks that attempt to steal tokens from the dynamically generated JavaScript. While the primary defenses against JavaScript Hijacking attacks are implemented within the dynamic JavaScript itself, referer header checking is implemented to achieve defense in depth.<br /> <br /> cache-control<br /> <br /> Allows the developer to specify the value of the Cache-Control header in the HTTP response when serving the dynamic JavaScript file. The default value is private, maxage=28800. Caching of the dynamic JavaScript file is intended to minimize traffic and improve performance. Note that the Cache-Control header is always set to &quot;no-store&quot; when either the &quot;Rotate&quot; &quot;TokenPerPage&quot; options is set to true in Owasp.CsrfGuard.properties.<br /> <br /> inject-into-forms<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token as a hidden field into HTML forms. The default value is true. Developers are strongly discouraged from disabling this property as most server-side state changing actions are triggered via a POST request.<br /> <br /> inject-into-attributes<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token in the query string of src and href attributes. Injecting the CSRF prevention token in a URL resource increases its general risk of exposure to unauthorized parties. However, most JavaEE web applications respond in the exact same manner to HTTP requests and their associated parameters regardless of the HTTP method. The risk associated with not protecting GET requests in this situation is perceived greater than the risk of exposing the token in protected GET requests. As a result, the default value of this attribute is set to true. Developers that are confident their server-side state changing controllers will only respond to POST requests (i.e. discarding GET requests) are strongly encouraged to disable this property.<br /> <br /> == Map JavaScriptServlet ==<br /> <br /> Developers must map the JavaScriptServlet to a URI space such that the Servlet class can be remotely accessed by the dynamic JavaScript code. Consider the following configuration snippet taken directly from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet-mapping&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;url-pattern&gt;/JavaScriptServlet&lt;/url-pattern&gt;<br /> &lt;/servlet-mapping&gt;<br /> <br /> The aforementioned configuration snippet maps the Servlet referenced by the name &quot;JavaScriptServlet&quot; to the URI space &quot;/JavaScriptServlet&quot;. Any request sent to the /JavaScriptServlet URI will produce a dynamically generated CSRFGuard JavaScript file specific to the user's current session.<br /> <br /> == Inject Dynamic JavaScript ==<br /> <br /> Developers are required to place an HTML script tag within all pages that are known to send requests to CSRF protected resources. All requests within the current HTML page are augmented to ensure they submit the correct CSRF token for the user's current session. Note that inclusion of the dynamic JavaScript does not protect the current page. Rather, the script ensures the CSRF token is transmitted within all requests generated by the current page. Consider the following code snippet taken directly from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;!-- OWASP CSRFGuard Support --&gt;<br /> &lt;script src=&quot;/Owasp.CsrfGuard.Test/JavaScriptServlet&quot;&gt;&lt;/script&gt;<br /> <br /> The script tag retrieves and executes the dynamically generated JavaScript from the Servlet mapped at /Owasp.CsrfGuard.Test/JavaScriptServlet. This JavaScript code will register an event handler with window.onload. Once triggered, the code will iterate over every HTML element within the DOM looking for either form tags and or tags containing href or src attributes as configured by the JavaScriptServlet initialization parameters. Forms are dynamically updated to include the CSRFGuard token via a hidden field and tags using src and href attributes are updated to include the CSRFGuard token via a query string parameter.<br /> <br /> = JSP Tag Library =<br /> <br /> OWASP CSRFGuard 3 exposes a JSP tag library providing developers more fine grain control over token injection. The library exposes JSP tags that allow access to the token name, the token value, and the token name value pair delimited by an equals (=) sign. In order to make use of the tag library, ensure the Owasp.CsrfGuard.jar file is found within the target application's classpath. For example, the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application places the OWASP CSRFGuard jar file within the WebContent/WEB-INF/lib directory. After placing the library in the classpath, developers can reference the tags in JSP pages using predefined URI reference. The following JSP code snippet imports the tag library and makes it available using the prefix &quot;csrf&quot;:<br /> <br /> &lt;%@ taglib uri=&quot;http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project/Owasp.CsrfGuard.tld&quot; prefix=&quot;csrf&quot; %&gt;<br /> <br /> The benefit of using the JSP tag library to inject the CSRF prevention token is the fine grain level of control. Developers can place the token in all the correct locations within the context of their applications. This strategy is useful in application contexts where the JavaScript DOM Manipulation strategy is insufficient.<br /> <br /> == Display Token Name ==<br /> <br /> The OWASP CSRFGuard token name can be obtained through the token-name tag. The token-name tag is useful when injecting the CSRFGuard token name in a non-query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-name tag to reference the token name in the name attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;'''&lt;csrf:token-name/&gt;'''&quot; value=&quot;&lt;csrf:token-value/&gt;&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Value ==<br /> <br /> The OWASP CSRFGuard token value can be obtained through the token-value tag. The token-value tag is useful when injecting the CSRFGuard token value in a non-query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-value tag to reference the token value in the value attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;&lt;csrf:token-name/&gt;&quot; value=&quot;'''&lt;csrf:token-value/&gt;'''&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> The token value tag must be used in conjunction with the URI attribute when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The value of the uri attribute is the URI for which the token value will be posted. Consider the following example which sets the URI to the destination of the form, &quot;protect.html&quot;:<br /> <br /> &lt;form id=&quot;formTest1&quot; name=&quot;formTest1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;&lt;csrf:token-name/&gt;&quot; value=&quot;&lt;csrf:token-value uri=&quot;protect.html&quot;/&gt;&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Name Value Pair ==<br /> <br /> The OWASP CSRFGuard token name value pair, delimited by an equals sign (=), can be obtained though the token tag. The token tag is useful when injecting the CSRFGuard token value in a query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token tag to reference the token name value pair in the href attribute of an anchor tag:<br /> <br /> &lt;a href=&quot;protect.html?&lt;csrf:token/&gt;&quot;&gt;protect.html&lt;/a&gt;<br /> <br /> The token name value pair tag must be used in conjunction with the URI attribute when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). The value of the uri attribute is the URI for which the token value will be posted. Consider the following example which sets the URI to the destination of the link, &quot;protect.html&quot;:<br /> <br /> &lt;a href=&quot;protect.html?&lt;csrf:token uri=&quot;protect.html&quot;/&gt;&quot;&gt;protect.html&lt;/a&gt;<br /> <br /> == Generate Form with Prevention Token ==<br /> <br /> The OWASP CSRFGuard JSP library implements a tag library designed specifically to generate HTML forms with the CSRF prevention token automatically embedded as a hidden field. This strategy simplifies the integration of the CSRF token, especially when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). Consider the following code snippet which will produce a HTML form with an embedded CSRF token. No special care must be taken when using this flag in conjunction with the unique token per uri model:<br /> <br /> &lt;csrf:form id=&quot;formTest2&quot; name=&quot;formTest2&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;/csrf:form&gt;<br /> <br /> == Generate Link with Prevention Token ==<br /> <br /> The OWASP CSRFGuard JSP library implements a tag library designed specifically to generate HTML anchor tags with the CSRF prevention token automatically embedded as a query string parameter. This strategy simplifies the integration of the CSRF token, especially when using the unique token per page model (org.owasp.csrfguard.TokenPerPage). Consider the following code snippet which will produce a HTML anchor tag with an embedded CSRF token. No special care must be taken when using this flag in conjunction with the unique token per uri model:<br /> <br /> &lt;csrf:a href=&quot;protect.html&quot;&gt;protect.html&lt;/csrf:a&gt;</div>

Esheridan https://wiki.owasp.org/index.php?title=Summit_2011_Attendee/Attendee076&diff=96314 2010-12-14T16:00:35Z

<p>Esheridan: </p> <hr /> <div>{{Template:&lt;includeonly&gt;{{{1}}}&lt;/includeonly&gt;&lt;noinclude&gt;OWASP 2011 Global Summit Attendee Tab&lt;/noinclude&gt;<br /> |-<br /> | summit_attendee_name1 = Eric Sheridan<br /> | summit_attendee_email1 = eric.sheridan@owasp.org<br /> | summit_attendee_wiki_username1 = esheridan<br /> |-<br /> | summit_attendee_company = Aspect Security<br /> |-<br /> | summit_attendee_current_owasp_involvement_name1 = CSRFGuard<br /> | summit_attendee_current_owasp_involvement_url_1 = http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project<br /> | summit_attendee_current_owasp_involvement_name2 = <br /> | summit_attendee_current_owasp_involvement_url_2 = <br /> | summit_attendee_current_owasp_involvement_name3 = <br /> | summit_attendee_current_owasp_involvement_url_3 = <br /> | summit_attendee_current_owasp_involvement_name4 = <br /> | summit_attendee_current_owasp_involvement_url_4 = <br /> | summit_attendee_current_owasp_involvement_name5 = <br /> | summit_attendee_current_owasp_involvement_url_5 = <br /> |-<br /> | summit_attendee_reason_for_summit_participation_name1 = Protecting Against CSRF<br /> | summit_attendee_reason_for_summit_participation_url_1 = http://www.owasp.org/index.php/Summit_2011/OWASP_Secure_Coding_Workshop<br /> | notes_reason_for_participating_issues_to_be_discussed_1 = <br /> | summit_attendee_reason_for_summit_participation_name2 = <br /> | summit_attendee_reason_for_summit_participation_url_2 = <br /> | notes_reason_for_participating_issues_to_be_discussed_2 = <br /> | summit_attendee_reason_for_summit_participation_name3 = <br /> | summit_attendee_reason_for_summit_participation_url_3 = <br /> | notes_reason_for_participating_issues_to_be_discussed_3 = <br /> | summit_attendee_reason_for_summit_participation_name4 = <br /> | summit_attendee_reason_for_summit_participation_url_4 = <br /> | notes_reason_for_participating_issues_to_be_discussed_4 = <br /> | summit_attendee_reason_for_summit_participation_name5 = <br /> | summit_attendee_reason_for_summit_participation_url_5 = <br /> | notes_reason_for_participating_issues_to_be_discussed_5 = <br /> |-<br /> | summit_attendee_owasp_sponsor = <br /> |-<br /> | summit_attendee_summit_time_paid_by_name1 =<br /> | summit_attendee_summit_time_paid_by_url_1 =<br /> | summit_attendee_summit_time_paid_by_name2 =<br /> | summit_attendee_summit_time_paid_by_url_2 =<br /> |-<br /> | summit_attendee_summit_expenses_paid_by_name1 = <br /> | summit_attendee_summit_expenses_paid_by_url_1 = <br /> | summit_attendee_summit_expenses_paid_by_name2 = <br /> | summit_attendee_summit_expenses_paid_by_url_2 = <br /> |-<br /> | reason_for_sponsorship = OWASP CSRFGuard Project Lead<br /> |-<br /> | status = Confirmed, Seeking Funds<br /> |-<br /> | letter sent to sponsor = <br /> |-<br /> | notes for Kate =<br /> |-<br /> | attendee_name_mask = &lt;!--Please replace DO NOT EDIT this string --&gt; Attendee076<br /> | attendee_home_page = &lt;!--Please replace DO NOT EDIT this string --&gt; Summit_2011_Attendee/Attendee076 <br /> }}</div>

Esheridan https://wiki.owasp.org/index.php?title=Summit_2011_Attendee/Attendee076&diff=96313 2010-12-14T15:58:42Z

<p>Esheridan: </p> <hr /> <div>{{Template:&lt;includeonly&gt;{{{1}}}&lt;/includeonly&gt;&lt;noinclude&gt;OWASP 2011 Global Summit Attendee Tab&lt;/noinclude&gt;<br /> |-<br /> | summit_attendee_name1 = Eric Sheridan<br /> | summit_attendee_email1 = eric.sheridan@owasp.org<br /> | summit_attendee_wiki_username1 = esheridan<br /> |-<br /> | summit_attendee_company = Aspect Security<br /> |-<br /> | summit_attendee_current_owasp_involvement_name1 = CSRFGuard<br /> | summit_attendee_current_owasp_involvement_url_1 = http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project<br /> | summit_attendee_current_owasp_involvement_name2 = <br /> | summit_attendee_current_owasp_involvement_url_2 = <br /> | summit_attendee_current_owasp_involvement_name3 = <br /> | summit_attendee_current_owasp_involvement_url_3 = <br /> | summit_attendee_current_owasp_involvement_name4 = <br /> | summit_attendee_current_owasp_involvement_url_4 = <br /> | summit_attendee_current_owasp_involvement_name5 = <br /> | summit_attendee_current_owasp_involvement_url_5 = <br /> |-<br /> | summit_attendee_reason_for_summit_participation_name1 = Protecting Against CSRF<br /> | summit_attendee_reason_for_summit_participation_url_1 = http://www.owasp.org/index.php/Summit_2011/OWASP_Secure_Coding_Workshop<br /> | notes_reason_for_participating_issues_to_be_discussed_1 = <br /> | summit_attendee_reason_for_summit_participation_name2 = <br /> | summit_attendee_reason_for_summit_participation_url_2 = <br /> | notes_reason_for_participating_issues_to_be_discussed_2 = <br /> | summit_attendee_reason_for_summit_participation_name3 = <br /> | summit_attendee_reason_for_summit_participation_url_3 = <br /> | notes_reason_for_participating_issues_to_be_discussed_3 = <br /> | summit_attendee_reason_for_summit_participation_name4 = <br /> | summit_attendee_reason_for_summit_participation_url_4 = <br /> | notes_reason_for_participating_issues_to_be_discussed_4 = <br /> | summit_attendee_reason_for_summit_participation_name5 = <br /> | summit_attendee_reason_for_summit_participation_url_5 = <br /> | notes_reason_for_participating_issues_to_be_discussed_5 = <br /> |-<br /> | summit_attendee_owasp_sponsor = <br /> |-<br /> | summit_attendee_summit_time_paid_by_name1 =<br /> | summit_attendee_summit_time_paid_by_url_1 =<br /> | summit_attendee_summit_time_paid_by_name2 =<br /> | summit_attendee_summit_time_paid_by_url_2 =<br /> |-<br /> | summit_attendee_summit_expenses_paid_by_name1 = <br /> | summit_attendee_summit_expenses_paid_by_url_1 = <br /> | summit_attendee_summit_expenses_paid_by_name2 = <br /> | summit_attendee_summit_expenses_paid_by_url_2 = <br /> |-<br /> | reason_for_sponsorship = <br /> |-<br /> | status = <br /> |-<br /> | letter sent to sponsor = <br /> |-<br /> | notes for Kate =<br /> |-<br /> | attendee_name_mask = &lt;!--Please replace DO NOT EDIT this string --&gt; Attendee076<br /> | attendee_home_page = &lt;!--Please replace DO NOT EDIT this string --&gt; Summit_2011_Attendee/Attendee076 <br /> }}</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_Token_Injection&diff=96180 2010-12-13T23:15:04Z

<p>Esheridan: </p> <hr /> <div>= Overview =<br /> <br /> OWASP CSRFGuard implements a variant of the synchronizer token pattern to mitigate the risk of CSRF attacks. In order to implement this pattern, CSRFGuard must offer the capability to place the CSRF prevention token within the HTML produced by the protected web application. CSRFGuard 3 provides developers more fine grain control over the injection of the token. Developers can inject the token in their HTML using either dynamic JavaScript DOM manipulation or a JSP tag library. CSRFGuard no longer intercepts and modifies the HttpServletResponse object as was done in previous releases. The currently available token injection strategies are designed to make the integration of CSRFGuard more feasible and scalable within current enterprise web applications. Developers are encouraged to make use of both the JavaScript DOM Manipulation and the JSP tag library strategies for a complete token injection strategy. The JavaScript DOM Manipulation strategy is ideal as it is automated and requires minimal effort on behalf of the developer. In the event the JavaScript solution is insufficient within a particular application context, developers should leverage the JSP tag library. The purpose of this article is to describe the token injection strategies offered by OWASP CSRFGuard 3.<br /> <br /> = JavaScript DOM Manipulation =<br /> <br /> OWASP CSRFGuard 3 supports the ability to dynamically inject CSRF prevention tokens throughout the DOM currently loaded in the user's browser. This strategy is extremely valuable with regards to server-side performance as it simply requires the serving of a dynamic JavaScript file. There is little to no performance hit when the fetched dynamic JavaScript updates the browser's DOM. Making use of the JavaScript token injection solution requires the developer map a Servlet and place a JavaScript HTML tag within all pages sending requests to protected application resources. Developers are strongly encouraged to leverage the JavaScript token injection strategy by default. This strategy requires minimal effort on behalf of the developer as most of the token injection logic is automated. In the event that the JavaScript automated solution may be insufficient for a specific application context, developers should leverage the OWASP CSRFGuard JSP tag library.<br /> <br /> '''Note:''' Use of JavaScript DOM Manipulation is required for Ajax support.<br /> <br /> == Declare and Configure JavaScriptServlet ==<br /> <br /> The JavaScript file used for token injection is dynamically generated by the JavaScriptServlet class using a template file. Ensure that the Owasp.CsrfGuard.jar file is found within the target application's classpath. Copy the Owasp.CsrfGuard.js template file from the OWASP CSRFGuard distribution folder to a non-publicly accessible directory within the target application. For the remainder of this section, we assume the Owasp.CsrfGuard.js template file was placed in the application's WEB-INF folder. Edit the deployment descriptor (web.xml) to declare the JavaScriptServlet class along with any associated initialization parameters. Consider the following configuration snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;servlet-class&gt;org.owasp.csrfguard.servlet.JavaScriptServlet&lt;/servlet-class&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;source-file&lt;/param-name&gt;<br /> &lt;param-value&gt;WEB-INF/Owasp.CsrfGuard.js&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-forms&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;inject-into-attributes&lt;/param-name&gt;<br /> &lt;param-value&gt;true&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;init-param&gt;<br /> &lt;param-name&gt;domain-strict&lt;/param-name&gt;<br /> &lt;param-value&gt;false&lt;/param-value&gt;<br /> &lt;/init-param&gt;<br /> &lt;/servlet&gt;<br /> <br /> The aforementioned configuration snippet declares the JavaScriptServlet class using the name &quot;JavaScriptServlet&quot;. JavaScriptServlet accepts various initialization parameters augmenting the behavior of the class at runtime. The provided configuration snippet instructs JavaScriptServlet to...<br /> <br /> #Leverage the template JavaScript file at WEB-INF/Owasp.CsrfGuard.js<br /> #Inject the token into all HTML forms<br /> #Inject the token into all src and href attributes<br /> #Leverage loose same origin matching criteria when placing the token in URL resources<br /> <br /> Consider the following for a more detailed listing of the initialization parameters supported by JavaScriptServlet:<br /> <br /> source-file<br /> <br /> Denotes the location of the JavaScript template file that should be consumed and dynamically augmented by the JavaScriptServlet class. The default value is WEB-INF/Owasp.CsrfGuard.js. Use of this property and the existence of the specified template file is required. <br /> <br /> domain-strict<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should be strict with regards to what links it should inject the CSRF prevention token. With a value of true, the JavaScript code will only place the token in links that point to the same exact origin from which the HTML originated. With a value of false, the JavaScript code will place the token in links that contain, but may not exactly match, the originating domain.<br /> <br /> referer-pattern<br /> <br /> Allows the developer to specify a regular expression describing the required value of the Referer header. Any attempts to access the servlet with a Referer header that does not match the captured expression is discarded. Inclusion of referer header checking is to help minimize the risk of JavaScript Hijacking attacks that attempt to steal tokens from the dynamically generated JavaScript. While the primary defenses against JavaScript Hijacking attacks are implemented within the dynamic JavaScript itself, referer header checking is implemented to achieve defense in depth.<br /> <br /> cache-control<br /> <br /> Allows the developer to specify the value of the Cache-Control header in the HTTP response when serving the dynamic JavaScript file. The default value is private, maxage=28800. Caching of the dynamic JavaScript file is intended to minimize traffic and improve performance. Note that the Cache-Control header is always set to &quot;no-store&quot; when either the &quot;Rotate&quot; &quot;TokenPerPage&quot; options is set to true in Owasp.CsrfGuard.properties.<br /> <br /> inject-into-forms<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token as a hidden field into HTML forms. The default value is true. Developers are strongly discouraged from disabling this property as most server-side state changing actions are triggered via a POST request.<br /> <br /> inject-into-attributes<br /> <br /> Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token in the query string of src and href attributes. Injecting the CSRF prevention token in a URL resource increases its general risk of exposure to unauthorized parties. However, most JavaEE web applications respond in the exact same manner to HTTP requests and their associated parameters regardless of the HTTP method. The risk associated with not protecting GET requests in this situation is perceived greater than the risk of exposing the token in protected GET requests. As a result, the default value of this attribute is set to true. Developers that are confident their server-side state changing controllers will only respond to POST requests (i.e. discarding GET requests) are strongly encouraged to disable this property.<br /> <br /> == Map JavaScriptServlet ==<br /> <br /> Developers must map the JavaScriptServlet to a URI space such that the Servlet class can be remotely accessed by the dynamic JavaScript code. Consider the following configuration snippet taken directly from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;servlet-mapping&gt;<br /> &lt;servlet-name&gt;JavaScriptServlet&lt;/servlet-name&gt;<br /> &lt;url-pattern&gt;/JavaScriptServlet&lt;/url-pattern&gt;<br /> &lt;/servlet-mapping&gt;<br /> <br /> The aforementioned configuration snippet maps the Servlet referenced by the name &quot;JavaScriptServlet&quot; to the URI space &quot;/JavaScriptServlet&quot;. Any request sent to the /JavaScriptServlet URI will produce a dynamically generated CSRFGuard JavaScript file specific to the user's current session.<br /> <br /> == Inject Dynamic JavaScript ==<br /> <br /> Developers are required to place an HTML script tag within all pages that are known to send requests to CSRF protected resources. All requests within the current HTML page are augmented to ensure they submit the correct CSRF token for the user's current session. Note that inclusion of the dynamic JavaScript does not protect the current page. Rather, the script ensures the CSRF token is transmitted within all requests generated by the current page. Consider the following code snippet taken directly from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application:<br /> <br /> &lt;!-- OWASP CSRFGuard Support --&gt;<br /> &lt;script src=&quot;/Owasp.CsrfGuard.Test/JavaScriptServlet&quot;&gt;&lt;/script&gt;<br /> <br /> The script tag retrieves and executes the dynamically generated JavaScript from the Servlet mapped at /Owasp.CsrfGuard.Test/JavaScriptServlet. This JavaScript code will register an event handler with window.onload. Once triggered, the code will iterate over every HTML element within the DOM looking for either form tags and or tags containing href or src attributes as configured by the JavaScriptServlet initialization parameters. Forms are dynamically updated to include the CSRFGuard token via a hidden field and tags using src and href attributes are updated to include the CSRFGuard token via a query string parameter.<br /> <br /> = JSP Tag Library =<br /> <br /> OWASP CSRFGuard 3 exposes a JSP tag library providing developers more fine grain control over token injection. The library exposes JSP tags that allow access to the token name, the token value, and the token name value pair delimited by an equals (=) sign. In order to make use of the tag library, ensure the Owasp.CsrfGuard.jar file is found within the target application's classpath. For example, the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application places the OWASP CSRFGuard jar file within the WebContent/WEB-INF/lib directory. After placing the library in the classpath, developers can reference the tags in JSP pages using predefined URI reference. The following JSP code snippet imports the tag library and makes it available using the prefix &quot;csrf&quot;:<br /> <br /> &lt;%@ taglib uri=&quot;http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project/Owasp.CsrfGuard.tld&quot; prefix=&quot;csrf&quot; %&gt;<br /> <br /> The benefit of using the JSP tag library to inject the CSRF prevention token is the fine grain level of control. Developers can place the token in all the correct locations within the context of their applications. This strategy is useful in application contexts where the JavaScript DOM Manipulation strategy is insufficient.<br /> <br /> == Display Token Name ==<br /> <br /> The OWASP CSRFGuard token name can be obtained through the token-name tag. The token-name tag is useful when injecting the CSRFGuard token name in a non-query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-name tag to reference the token name in the name attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;'''&lt;csrf:token-name/&gt;'''&quot; value=&quot;&lt;csrf:token-value/&gt;&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Value ==<br /> <br /> The OWASP CSRFGuard token value can be obtained through the token-value tag. The token-value tag is useful when injecting the CSRFGuard token value in a non-query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token-value tag to reference the token value in the value attribute of a hidden input field:<br /> <br /> &lt;form name=&quot;test1&quot; action=&quot;protect.html&quot;&gt;<br /> &lt;input type=&quot;text&quot; name=&quot;text&quot; value=&quot;text&quot;/&gt;<br /> &lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;submit&quot;/&gt;<br /> &lt;input type=&quot;hidden&quot; name=&quot;&lt;csrf:token-name/&gt;&quot; value=&quot;'''&lt;csrf:token-value/&gt;'''&quot;/&gt;<br /> &lt;/form&gt;<br /> <br /> == Display Token Name Value Pair ==<br /> <br /> The OWASP CSRFGuard token name value pair, delimited by an equals sign (=), can be obtained though the token tag. The token tag is useful when injecting the CSRFGuard token value in a query string context. Consider the following code snippet taken from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] application. This code makes use of the token tag to reference the token name value pair in the href attribute of an anchor tag:<br /> <br /> &lt;a href=&quot;protect.html?&lt;csrf:token/&gt;&quot;&gt;protect.html&lt;/a&gt;</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_User_Manual&diff=96175 2010-12-13T22:55:42Z

<p>Esheridan: /* Token Injection */</p> <hr /> <div>= Overview =<br /> <br /> Welcome to the OWASP CSRFGuard 3 User Manual! The purpose of this article is to provide the user with guidance on obtaining, installing, deploying, and developing with the OWASP CSRFGuard library. The author's goal was to keep the User Manual informative, use to understand, and concise. If you find that one or more aspects of this document does not adhere to these goals, please me know at eric dot sheridan at owasp dot org.<br /> <br /> = Download =<br /> <br /> Users can download the latest release of OWASP CSRFGuard using one of the following links:<br /> <br /> :[http://code.google.com/p/owaspcsrfguard/downloads/detail?name=OWASP%20CSRFGuard%20%283.0.0.245%20-%20ALPHA%29.zip&amp;can=2&amp;q= OWASP CSRFGuard 3.0.0.245 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> = Installation =<br /> <br /> Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps:<br /> <br /> :# Copy the Owasp.CsrfGuard.jar file to your application's classpath<br /> :# Map the CsrfGuardFilter in your application's deployment descriptor (web.xml)<br /> :# Configure the Owasp.CsrfGuard.properties file as you see fit<br /> <br /> [[CSRFGuard_3_Installation | Click here]] for more detailed information regarding the installation of OWASP CSRFGuard.<br /> <br /> = Configuration =<br /> <br /> The minimum configuration settings that users should review include:<br /> <br /> :* Default new token landing page (org.owasp.csrfguard.NewTokenLandingPage)<br /> :* Support for Ajax and XMLHttpRequest (org.owasp.csrfguard.Ajax)<br /> :* URI resources that should not be protected (org.owasp.csrfguard.unprotected.*)<br /> :* Actions executed when an attack is detected (org.owasp.csrfguard.action.*)<br /> <br /> [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> = Token Injection =<br /> <br /> Users of OWASP CSRFGuard can inject prevention tokens into HTML using two strategies:<br /> <br /> :* JavaScript DOM Manipulation - largely automated process requiring minimal effort and is ideal for most web applications<br /> :* JSP Tag Library - provides fine grained strategy ideal for situations where automated DOM manipulation is insufficient.<br /> <br /> [[CSRFGuard_3_Token_Injection | Click here]] for more information regarding the injection of CSRF prevention tokens within your application.<br /> <br /> [[Category:OWASP_CSRFGuard_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_User_Manual&diff=96173 2010-12-13T22:54:04Z

<p>Esheridan: /* Token Injection */</p> <hr /> <div>= Overview =<br /> <br /> Welcome to the OWASP CSRFGuard 3 User Manual! The purpose of this article is to provide the user with guidance on obtaining, installing, deploying, and developing with the OWASP CSRFGuard library. The author's goal was to keep the User Manual informative, use to understand, and concise. If you find that one or more aspects of this document does not adhere to these goals, please me know at eric dot sheridan at owasp dot org.<br /> <br /> = Download =<br /> <br /> Users can download the latest release of OWASP CSRFGuard using one of the following links:<br /> <br /> :[http://code.google.com/p/owaspcsrfguard/downloads/detail?name=OWASP%20CSRFGuard%20%283.0.0.245%20-%20ALPHA%29.zip&amp;can=2&amp;q= OWASP CSRFGuard 3.0.0.245 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> = Installation =<br /> <br /> Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps:<br /> <br /> :# Copy the Owasp.CsrfGuard.jar file to your application's classpath<br /> :# Map the CsrfGuardFilter in your application's deployment descriptor (web.xml)<br /> :# Configure the Owasp.CsrfGuard.properties file as you see fit<br /> <br /> [[CSRFGuard_3_Installation | Click here]] for more detailed information regarding the installation of OWASP CSRFGuard.<br /> <br /> = Configuration =<br /> <br /> The minimum configuration settings that users should review include:<br /> <br /> :* Default new token landing page (org.owasp.csrfguard.NewTokenLandingPage)<br /> :* Support for Ajax and XMLHttpRequest (org.owasp.csrfguard.Ajax)<br /> :* URI resources that should not be protected (org.owasp.csrfguard.unprotected.*)<br /> :* Actions executed when an attack is detected (org.owasp.csrfguard.action.*)<br /> <br /> [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> = Token Injection =<br /> <br /> Users of OWASP CSRFGuard can inject prevention tokens into HTML using two strategies:<br /> <br /> :* JavaScript DOM Manipulation<br /> :* JSP Tag Library<br /> <br /> [[CSRFGuard_3_Token_Injection | Click here]] for more information regarding the injection of CSRF prevention tokens within your application.<br /> <br /> [[Category:OWASP_CSRFGuard_Project]]</div>

Esheridan https://wiki.owasp.org/index.php?title=CSRFGuard_3_User_Manual&diff=96172 2010-12-13T22:53:21Z

<p>Esheridan: /* Token Injection */</p> <hr /> <div>= Overview =<br /> <br /> Welcome to the OWASP CSRFGuard 3 User Manual! The purpose of this article is to provide the user with guidance on obtaining, installing, deploying, and developing with the OWASP CSRFGuard library. The author's goal was to keep the User Manual informative, use to understand, and concise. If you find that one or more aspects of this document does not adhere to these goals, please me know at eric dot sheridan at owasp dot org.<br /> <br /> = Download =<br /> <br /> Users can download the latest release of OWASP CSRFGuard using one of the following links:<br /> <br /> :[http://code.google.com/p/owaspcsrfguard/downloads/detail?name=OWASP%20CSRFGuard%20%283.0.0.245%20-%20ALPHA%29.zip&amp;can=2&amp;q= OWASP CSRFGuard 3.0.0.245 (ALPHA)] - download the latest development release with binary and associated configuration files '''(recommended)'''.<br /> <br /> = Installation =<br /> <br /> Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps:<br /> <br /> :# Copy the Owasp.CsrfGuard.jar file to your application's classpath<br /> :# Map the CsrfGuardFilter in your application's deployment descriptor (web.xml)<br /> :# Configure the Owasp.CsrfGuard.properties file as you see fit<br /> <br /> [[CSRFGuard_3_Installation | Click here]] for more detailed information regarding the installation of OWASP CSRFGuard.<br /> <br /> = Configuration =<br /> <br /> The minimum configuration settings that users should review include:<br /> <br /> :* Default new token landing page (org.owasp.csrfguard.NewTokenLandingPage)<br /> :* Support for Ajax and XMLHttpRequest (org.owasp.csrfguard.Ajax)<br /> :* URI resources that should not be protected (org.owasp.csrfguard.unprotected.*)<br /> :* Actions executed when an attack is detected (org.owasp.csrfguard.action.*)<br /> <br /> [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.<br /> <br /> = Token Injection =<br /> <br /> Users of OWASP CSRFGuard can inject prevention tokens into HTML using JavaScript DOM Manipulation and or the JSP Tag Library. JavaScript DOM Manipulation requires minimal effort on behalf of the developer and is ideal for most web based applications. The JSP tag library should be utilized in situations where the JavaScript DOM Manipulation token injection strategy is found to be technically insufficient. Together, the JavaScript DOM Manipulation and the JSP tag library provide strong and fine grain means of integrating CSRF prevention tokens within application presentation logic.<br /> <br /> [[CSRFGuard_3_Token_Injection | Click here]] for more information regarding the injection of CSRF prevention tokens within your application.<br /> <br /> [[Category:OWASP_CSRFGuard_Project]]</div>

Esheridan