You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Markus Jung <ma...@gmail.com> on 2011/04/01 10:46:48 UTC
GSoC - CSRF Protection
Hi,
I would like to participate as student in GSoC. Unfortunately I'm a little
bit late to propose own ideas therefore I would like to work on the task
https://issues.apache.org/jira/browse/TAP5-1474
[GSoC] add out-of-the-box protection against cross-site request forgery
(CSRF).
I have implemented once a concept against CSRF in Grails in an industry
project and think that I can contribute ideas here and I would also like to
discuss such a mechanism with the developer community to make a useful
solution.
The concept there was based on action tokens stored in cookies implemented
with aspect oriented filters and taglibs that provided enhanced logics for
basic tags.
The CSRF protection works in the following way:
-) A http request handler at the server side creates a unique one time token
(UUID) and stores it in the session
-) This token is passed to the client as cookie
-) All tags that are rendered as or HTML tags are enhanced with a
javascript logic that reads the cookie value and sends the cookie value back
to the server as parameter- this has to be done for all GET and POST calls
-) The http request handler checks the passed parameter value with the
stored session value - here the passed parameter value is checked - not the
cookie value sent by the client!
-) If the token check succeeds the usual http request processing is done
-) If the token check fails a HTTP error is sent back to the client
Why is this solution secure (at least I think so):
-) The cookie value can only be evaluted by the javascript running on the
page. Javascript in the context of a different page cannot access the
cookies of another page
-) A plain link without any cookie value is useless, since it is not
possible to generate a proper token parameter
Challenges:
-) Making the whole mechanism as transparent as possible - in my Grails
solution a CSRF secured controller just had to extend a base class to use
that mechanism
-) Providing taglib elements for every type of UI component that sends a
HTTP requeset to use the javascript logic. Also to provide a easy way to
extend this logic to any other custom UI component.
-) Javascript is required for that concept, maybe there are concepts that
don't require javascript
I have to admit that I don't have much experience with Tapestry but I think
with my experience from other Java frameworks and my java development
background I can contribute useful code.
I would appreciate some feedback on this concept and some info on the
further application process.
Should I already submit an application at the GSoC page or is it better to
refine the ideas first?
Thanks in advance,best regards
Markus
--
View this message in context: http://tapestry.1045711.n5.nabble.com/GSoC-CSRF-Protection-tp4274965p4274965.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: GSoC - CSRF Protection
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 02 May 2011 18:24:07 -0300, Markus Jung <ma...@gmail.com>
wrote:
> Hi,
Hi!
> As described in my proposal I will dig into documentation for the next
> time
> and expirment with the tapestry source code. In parallel I will prepare a
> project that demonstrates the CSRF vulnerability. I think I'll use/extend
> the jumpstart tutorial for that. I will discuss minor questions directly
> with my mentor Ulrich Stärk. As soon it comes to some bigger decisions
> I'll start a thread in the mailing list.
Don't forget that interacting with the project community is a very
important objective in GSoC, so don't hesitate in posting in the mailing
lists (user and dev). ;)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: GSoC - CSRF Protection
Posted by Markus Jung <ma...@gmail.com>.
Hi,
I'm really happy that I've got accepted with my proposal :)
As described in my proposal I will dig into documentation for the next time
and expirment with the tapestry source code. In parallel I will prepare a
project that demonstrates the CSRF vulnerability. I think I'll use/extend
the jumpstart tutorial for that. I will discuss minor questions directly
with my mentor Ulrich Stärk. As soon it comes to some bigger decisions I'll
start a thread in the mailing list.
Kind regards,
Markus
--
View this message in context: http://tapestry.1045711.n5.nabble.com/GSoC-CSRF-Protection-tp4274965p4365781.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: GSoC - CSRF Protection
Posted by Markus Jung <ma...@gmail.com>.
Hi,
here is my project proposal that I would like to submit:
Proposal Title: Cross-site request forgery protection for Tapestry
Student Name: Markus Jung
Student E-mail: markus.jung85@gmail.com
Organization/Project: Apache Software Foundation / Tapestry
Assigned Mentor: Ulrich Stärk
Proposal Abstract:
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. 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
Deliverables:
D1 - Tapestry Example Project demonstrating CSRF vulnerability
D2 - How it should be use case project - used to specify the solution and
later used to verify the implementation
D3 - CSRF Protection implementation
D4 - Show case project that demonstrates the CSRF protection
D5 - Documentation
--
View this message in context: http://tapestry.1045711.n5.nabble.com/GSoC-CSRF-Protection-tp4274965p4286394.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: GSoC - CSRF Protection
Posted by Ulrich Stärk <ul...@spielviel.de>.
Hey Markus,
we don't know who will mentor you but we'll find someone ;). Please don't discuss just with your
possible mentor but with the whole development community. So go ahead, write that proposal and show
it to us.
Cheers,
Uli
On 03.04.2011 22:44, Markus Jung wrote:
> Thanks for your input.
>
> Regarding the javascript in my proposed concept, for protection of input
> actions that are rendered through a HTML form a hidden input is the best
> solution to protect the action behind against CSRF. Javascript is not
> necessary in that case.
>
> The solution in the wiki by Martijn Brinkers has some drawbacks as stated in
> the end of article, that can be avoided if a hidden input is used, but the
> solution works also for action links that issue a HTTP GET request.
>
> What is not clear for me is that this solution works for all form and bean
> based components. This solution seems only to work for actionLink, right -
> or am I missing something?
>
> I'm currently digging into the details of Tapestry and different protection
> mechanisms against CSRF. As far the most reasonable solution for me is like
> Andreas Andreou suggested to provide a component mixin, that could be added
> to all components that are rendered as a HTML form, e.g. Form Components and
> Bean related components. In the template an additional element has to be
> explicetely added, that holds the secure token and is rendered as HTML
> hidden input field.
>
> This solution could maybe extended to provide a more general usage pattern,
> e.g. a site configuration parameter that enables CSRF protection for all
> form based components without further coding required, or a page scope
> enabling of this mechanism maybe useful.
>
> In a further step it might be useful to protect HTML anchor rendered
> components also.
>
> I will prepare a project proposal with a rough timeline. Who would like to
> mentor this project - is it Ulrich Stärk? I would like to double check the
> project proposal with the mentor before I submit it.
>
> Best Regards,
> Markus
>
>
>
>
>
>
>
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/GSoC-CSRF-Protection-tp4274965p4279297.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: GSoC - CSRF Protection
Posted by françois facon <fr...@gmail.com>.
2011/4/3 Markus Jung <ma...@gmail.com>:
> What is not clear for me is that this solution works for all form and bean
> based components. This solution seems only to work for actionLink, right -
> or am I missing something?
The form component render hidden input for parameters added by
LinkCreationListener2.
(new name for LinkFactoryListener)
> I'm currently digging into the details of Tapestry and different protection
> mechanisms against CSRF. As far the most reasonable solution for me is like
> Andreas Andreou suggested to provide a component mixin, that could be added
> to all components that are rendered as a HTML form, e.g. Form Components and
> Bean related components. In the template an additional element has to be
> explicetely added, that holds the secure token and is rendered as HTML
> hidden input field.
If I were you I would first try to implement the wiki solution with
LinkCreationListener2.
> This solution could maybe extended to provide a more general usage pattern,
> e.g. a site configuration parameter that enables CSRF protection for all
> form based components without further coding required, or a page scope
> enabling of this mechanism maybe useful.
>
Keep in mind the draw back effect on
- bookmarking / url re-rewriting.
- entry point to user auth and user right management
- session replication and so one
etc...
> In a further step it might be useful to protect HTML anchor rendered
> components also.
>
> I will prepare a project proposal with a rough timeline. Who would like to
> mentor this project - is it Ulrich Stärk? I would like to double check the
> project proposal with the mentor before I submit it.
Would be nice to have a page about Tapestry better than
http://www.owasp.org/index.php/Java_Server_Faces
François
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: GSoC - CSRF Protection
Posted by Markus Jung <ma...@gmail.com>.
Thanks for your input.
Regarding the javascript in my proposed concept, for protection of input
actions that are rendered through a HTML form a hidden input is the best
solution to protect the action behind against CSRF. Javascript is not
necessary in that case.
The solution in the wiki by Martijn Brinkers has some drawbacks as stated in
the end of article, that can be avoided if a hidden input is used, but the
solution works also for action links that issue a HTTP GET request.
What is not clear for me is that this solution works for all form and bean
based components. This solution seems only to work for actionLink, right -
or am I missing something?
I'm currently digging into the details of Tapestry and different protection
mechanisms against CSRF. As far the most reasonable solution for me is like
Andreas Andreou suggested to provide a component mixin, that could be added
to all components that are rendered as a HTML form, e.g. Form Components and
Bean related components. In the template an additional element has to be
explicetely added, that holds the secure token and is rendered as HTML
hidden input field.
This solution could maybe extended to provide a more general usage pattern,
e.g. a site configuration parameter that enables CSRF protection for all
form based components without further coding required, or a page scope
enabling of this mechanism maybe useful.
In a further step it might be useful to protect HTML anchor rendered
components also.
I will prepare a project proposal with a rough timeline. Who would like to
mentor this project - is it Ulrich Stärk? I would like to double check the
project proposal with the mentor before I submit it.
Best Regards,
Markus
--
View this message in context: http://tapestry.1045711.n5.nabble.com/GSoC-CSRF-Protection-tp4274965p4279297.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: GSoC - CSRF Protection
Posted by based2 <ba...@free.fr>.
http://wiki.apache.org/tapestry/Tapestry5CSRF
--
View this message in context: http://tapestry.1045711.n5.nabble.com/GSoC-CSRF-Protection-tp4274965p4278913.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: GSoC - CSRF Protection
Posted by Andreas Andreou <an...@gmail.com>.
I don't like that this depends on javascript. Perhaps this is so that
you can protect GET requests but i don't like that either :P
I believe the base solution should just protext POSTs and be functional even
without javascript.
I quite enjoy the asp.mvc aproach which contains 2 parts...
First, in the template one uses @Html.AntiForgeryToken() and this outputs
a hidden input tag (and creates the related cookie)
And secondly, in the controller that handles the submit one adds the
ValidateAntiForgeryToken annotation
For Tapestry, the first step could be either a component or (probably
better) a mixin
to be used with forms. The second step could be the same but i'd also
provide an api
call for manual validation of the token
Finally, in case of wrong or missing token an exception is thrown
On Fri, Apr 1, 2011 at 11:46, Markus Jung <ma...@gmail.com> wrote:
> Hi,
>
> I would like to participate as student in GSoC. Unfortunately I'm a little
> bit late to propose own ideas therefore I would like to work on the task
> https://issues.apache.org/jira/browse/TAP5-1474
> [GSoC] add out-of-the-box protection against cross-site request forgery
> (CSRF).
>
> I have implemented once a concept against CSRF in Grails in an industry
> project and think that I can contribute ideas here and I would also like to
> discuss such a mechanism with the developer community to make a useful
> solution.
>
> The concept there was based on action tokens stored in cookies implemented
> with aspect oriented filters and taglibs that provided enhanced logics for
> basic tags.
>
> The CSRF protection works in the following way:
>
> -) A http request handler at the server side creates a unique one time token
> (UUID) and stores it in the session
> -) This token is passed to the client as cookie
> -) All tags that are rendered as or HTML tags are enhanced with a
> javascript logic that reads the cookie value and sends the cookie value back
> to the server as parameter- this has to be done for all GET and POST calls
> -) The http request handler checks the passed parameter value with the
> stored session value - here the passed parameter value is checked - not the
> cookie value sent by the client!
> -) If the token check succeeds the usual http request processing is done
> -) If the token check fails a HTTP error is sent back to the client
>
> Why is this solution secure (at least I think so):
> -) The cookie value can only be evaluted by the javascript running on the
> page. Javascript in the context of a different page cannot access the
> cookies of another page
> -) A plain link without any cookie value is useless, since it is not
> possible to generate a proper token parameter
>
> Challenges:
> -) Making the whole mechanism as transparent as possible - in my Grails
> solution a CSRF secured controller just had to extend a base class to use
> that mechanism
> -) Providing taglib elements for every type of UI component that sends a
> HTTP requeset to use the javascript logic. Also to provide a easy way to
> extend this logic to any other custom UI component.
> -) Javascript is required for that concept, maybe there are concepts that
> don't require javascript
>
> I have to admit that I don't have much experience with Tapestry but I think
> with my experience from other Java frameworks and my java development
> background I can contribute useful code.
>
> I would appreciate some feedback on this concept and some info on the
> further application process.
> Should I already submit an application at the GSoC page or is it better to
> refine the ideas first?
>
> Thanks in advance,best regards
>
> Markus
>
>
>
>
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/GSoC-CSRF-Protection-tp4274965p4274965.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Apache Tapestry PMC / http://chesstu.be owner
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org