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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > -- Andreas Andreou - [email protected] - http://blog.andyhot.gr Apache Tapestry PMC / http://chesstu.be owner Open Source / JEE Consulting --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
