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] > > > -- View this message in context: http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18845568.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
