Tapestry is a component oriented framework for creating dynamic, robust, highly scalable web applications in Java[1] that lacks a built-in mechanism to protect web applications against cross-site request forgery. 
The goal of this project is to create a Tapestry built-in protection mechanism that secures Tapestry applications against CSRF attacks.
Cross-site request forgery(CSRF)[2] exploits a target website by transmitting unauthorized HTTP requests through the client's browser. Malicious links are placed on a different site and if the user can be tricked to click on such link the browser executes the link and submits cookie data for that web page. In this way a malicious link can be executed within a valid user session if the session identifier is stored in the cookie.

Example:
Target site: http://mybank.com

Malicious link: mybank.com/withdraw?from=markus&to=attacker&value=999998 placed on http://untrustworhty.com

If the user can be tricked to go on http://untrustworthy.com and execute the link the request is issued within a possible valid sessoin of the user at the site http://mybank.com

There are several ways how to protect against such an attack. The Open Web Application security Project outlines the attack in detail and provide some possible protection mechanisms (2).

One solution is to create a random token that is passed to the client within a cookie and also attached as parameter to every input form or link that issues a HTTP request. At the server side the token of the cookie and the request parameter can be compared. If they are identical the request was issued by the user on the original side. If the request parameter differs from the value stored in the cookie a cross site request forgery attack happened and the request execution has to be stopped.

[1] http://tapestry.apache.org
[2] The Open Web Application security Project - http://www.owasp.org/images/4/42/RequestRodeo-MartinJohns.pdf

Detailed Description:

The Tapestry framework allows uses components to build powerful web applications. Tapestry allows building complex applications by using pages and components to simplify development. An example for a component is e.g. the BeanEditForm that contains the logic to render a Java bean and to modify the content. So called Mixins allows adding behaviour to components. 

The goal of this project is to create a Tapestry built-in protection mechanism that secures Tapestry applications against CSRF attacks.

Work packages

WP1 - Example Project that shows the CSRF vulnerability 

First a simple example Tapestry project is created that is vulnerable to CSRF.

WP2 - Discussion of different implementation mechanisms with the development community in detail.

In this work package I would like to propose different solutions in detail that could be included in the Tapestry core.

Alternatives:

-) integration of the LinkFactory mechanism described in the Tapestry wiki. 

-) a component or mixin based approach

-) a page level or project scoped approach

WP3 - Test Case Project

The example project from WP1 is extended with a configuration or code that demonstrates the final solution and works as a test case 

for the CSRF protection.

WP4 - Implementation of the CSRF protection

This work package depends on the solution agreed in WP2. A possible solution is a Component or a Mixin that creates a 

token based on for example UUID.randomUUID(). This random token is passed as cookie and as hidden parameter in HTML form elements to the client.

The generation of such token is triggered either in general for all input forms and action links or only specific for some Components or Pages 

marked with an Java annotation, e.g. @CSRFProtection or as Mixin, e.g. @Mixin({"CSRFProtected"}). 

The event handler methods e.g. onAction or onSubmit can be annoted with for example @CheckCSRFProtection, in this case

the token value of the cookie and the sent token parameter value are compared to each other. In the case of an error an exception is thrown or

a HTTP error response is returned.

Provide also a API to create an check an token in order to provide a generic way to use the CSRF protection functionality.

If a page or project scope protection mechanism is allowed an annotation has to be implemented that allows to mark event handler methods to be 

exceptions for CSRF protection, e.g. @NoCSRFProtection.

WP5 - Implementation Verification

Test the implemented Tapestry extension against the test case project created in WP3. CSRF attacks should not be

possible any more. Further test if there are any side effects on session replication, book marking, user authentication.

WP6 - Wiki documentation & API documentation

Create a documentation page in the Wiki that describes the CSRF protection mechanism and demonstrates how to use it. 

The vulnerable test project and the fixed test project are part of the documentation. Javadoc is also provided as API documentation.

Time Plan:

27. April – 24. Mai 2011

Learning the internals of Tapestry. Check out the source code, make custom builds and expirement with components, mixins and internal framework classes.

Work on WP1 and make a showcase of the CSRF vulnerability. Discuss WP2 and find a protection mechanism that should be implemented.

25. Mail - 12. July 2011

Work on WP3 and create a project that uses the discussed solution and works as a use-case for the CSRF protection and as a testcase for the upcoming implementation.

Implementation of the CSRF protection WP4.

15. July 2011 - Mid term evalution deadline

17. July 2011 - 16. August 2011

Evalute the implementation based on WP5. If any problems are found the solution has to be reworked. Finally a documentation based on a

wiki page, API description and Javadoc is done.

16. August 2011 - suggested pencils down date

26. August 2011 - Final evaluation