This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Category:OWASP CSRFGuard Project

Revision as of 15:18, 20 October 2007 by Esheridan (talk | contribs)

Jump to: navigation, search


Just when developers are starting to run in circles over Cross Site Scripting, the 'sleeping giant' awakes for yet another web-catastrophe. Cross-Site Request Forgery (CSRF) is an attack whereby the victim is tricked into loading information from or submitting information to a web application for which they are currently authenticated. The problem is that the web application has no means of verifying the integrity of the request.

How Does OWASP CSRFGuard Work?

The core issue with CSRF attacks is that form submission can be imitated with forged requests. The application must be able to differentiate between legal requests and forged requests. Since all headers, cookies, and credentials will be submitted with both legal and forged requests, the only method of truly verifying the integrity of the request is with a uniquely identifiable token in the form of an HTTP parameter. When the user first visits the site, the application will generate and store a session specific unique request token. This session specific unique request token is then placed in each form and link of the HTML response, ensuring that this value will be submitted with the next request. For each subsequent request, the application must verify the existence of the unique token parameter and compare its value to that of the value stored in the user's session. The security of the approach is based on the fact that this unique token value is specific to a user's session and is hard to guess. Therefore, it is imperative that this value is large and cryptographically secure.

There have been discussions suggesting that the unique request token can be compromised using JavaScript. This attack implies that the application also contains a Cross-Site Scripting vulnerability, which is frequently a more severe issue than Cross-Site Request Forgery. The first Myspace worm worked in this manner where it used a Cross Site Scripting vulnerability to forge requests to update a user's profile, where the user profile update mechanism was protected with a CSRF defense mechanism similar to what is provided by this filter. If an attacker can exploit a stored cross-site scripting vulnerability, they will be able to parse the unique request token from the HTML and forge form submissions.


CSRFGuard is offered under the LGPL. For further information on OWASP licenses, please consult the OWASP Licenses page.


[ Click here] to download the latest version of the OWASP CSRFGuard 1.x series.

[ Click here] to download the latest version of the OWASP CSRFGuard 2.x series.

Installation Instructions

[ Click here] to view the installation instructions of the OWASP CSRFGuard 1.x series.

[ Click here] to view the installation instructions of the OWASP CSRFGuard 2.x series.

Feedback and Participation

We hope you find Stinger useful. Please contribute back to the project by sending your comments, questions, and suggestions to OWASP. Thanks!


The Open Web Application Security Project is purely an open-source community driven effort. As such, all projects and research efforts are contributed and maintained with an individual's spare time. If you have found this or any other project useful, please support OWASP with a donation.

Project Sponsors

The OWASP CSRFGuard project is sponsored by Aspect_logo.gif.

Pages in category "OWASP CSRFGuard Project"

The following 4 pages are in this category, out of 4 total.