I have added a howto http://wiki.apache.org/tapestry/Tapestry5CSRF
Martijn On Wed, 2008-08-06 at 00:13 -0700, 9902468 wrote: > Hi, > > CSRF solution could be the base for the solution to my problem, described > here: > > http://www.nabble.com/T5-double-click---multiple-windows-on-same-session-prevention-to18807447.html > > Could you post the code? I think that I need only to customize it so that it > changes the sid to every response and accepts only request with the latest > one. > > I'm also interested of the mixin(s) code. (Or the custom action link / form > implementation if that approach was chosen.) > > - 99 > > > Martijn Brinkers (List)-2 wrote: > > > >> Also, the internal LinkFactory service has listeners that know when an > >> action link is created; it might be possible to automatically add a > >> query parameter to every link with authentication, and then provided > >> filters in the ComponentEventRequestHandler pipeline to enforce the > >> check. > > > > I finally had time to implement the 'Cross-site request forgery' filter > > in the way suggested by Howard and it was really simple and > > straightforward (which shows me again why I think Tapestry is extremely > > well built). All action links now contain a sid (random generated for > > each user) and the sid is checked using a ComponentEventRequestFilter. > > The only possible problem (which was not a problem for me though) could > > be that the action links now contain an extra parameter > > (example: ?sid=enn50tk96) which wasn't there before the filter was > > added. This can interfere with existing code. I was wondering whether it > > would be possible to remove the sid attribute after checking the sid so > > the rest of the application has no knowlegde of the sid? > > > > Martijn > > > > > > On Mon, 2008-07-28 at 12:27 -0700, Howard Lewis Ship wrote: > >> I wonder if this could be created as a Mixin? > >> > >> Also, the internal LinkFactory service has listeners that know when an > >> action link is created; it might be possible to automatically add a > >> query parameter to every link with authentication, and then provided > >> filters in the ComponentEventRequestHandler pipeline to enforce the > >> check. > >> > >> On Mon, Jul 28, 2008 at 12:24 PM, Martijn Brinkers (List) > >> <[EMAIL PROTECTED]> wrote: > >> > Hi Christian, > >> > > >> > Do you have some example code of you Form extension? > >> > > >> > Thanks, > >> > > >> > Martijn > >> > > >> > On Mon, 2008-07-28 at 15:18 -0400, Christian Edward Gruber wrote: > >> >> A good way would be to alter the Form object to contain (via a hidden > >> >> variable) a field that's generated per the whitepaper linked from that > >> >> wikipedia article. The form would then consume the post, and if that > >> >> field is not in the expected state, generate an error state, which > >> >> could then be redirected to a security page or some such. We solved > >> >> it this way, though without changing the T5 form object - we used a > >> >> custom form object. > >> >> > >> >> A friend of mine wrote the linked whitepaper, so if someone's trying > >> >> to put the fix into the Tapestry framework infrastructure, then let me > >> >> know and I'll connect you by e-mail. It's a good read anyway, as it's > >> >> a bit of a subtle problem. > >> >> > >> >> Christian. > >> >> > >> >> On 28-Jul-08, at 14:50 , Martijn Brinkers (List) wrote: > >> >> > >> >> > Cross-site request forgeries (CSRF) is a web application > >> vulnerability > >> >> > that is often neglected by web developers. If your application is > >> >> > vulnerable to CSRF and an attacker can entice you to request some > >> URL > >> >> > (this can be done for example with an image with the src set to some > >> >> > Tapestry action) the attacker can execute random Tapestry actions > >> and > >> >> > post forms (like adding a adminitrator etc.) without the users > >> >> > consent. > >> >> > For more info on CSRF see for example: > >> >> > http://en.wikipedia.org/wiki/Cross-site_request_forgery. > >> >> > One way to protect against CSRF is to add a non-guessable code > >> >> > (saved in > >> >> > the user session) to the URLs that need to be protected against CSRF > >> >> > or > >> >> > add a hidden field to a Form with this unique code. When Tapestry > >> >> > recieved a request (for a page or action) and that page/action need > >> >> > protection a check is done to see if the code from the URL matches > >> the > >> >> > code stored in the user session. If not you know that the request > >> did > >> >> > not generated by tapestry. > >> >> > > >> >> > My question is what is the best way to implement this? Should I add > >> >> > the > >> >> > code as a context parameter and for forms as a hidden field? And use > >> a > >> >> > dispatcher to check whether the page should have been protected? > >> >> > > >> >> > Thanks, > >> >> > > >> >> > Martijn Brinkers > >> >> > > >> >> > > >> >> > > >> --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > > >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
