On 02/07/2010 04:04 AM, Mike Orr wrote: > I don't know about the best way to implement SecureForm, but I > discovered when I was documenting it that it depends on > pylons.session, so it's now under webhelpers.pylonslib in WebHelpers > 1.0b4 and later. So you may have to change your import. I don't know > whether a sessionless SecureForm is feasable, but if it is we can put > it in the old place. But Ben just changed the @secure_form decorator > in Pylons, so I doubt it's worth changing again. I did wonder how > many people use SecureForm anyway because I don't hear it mentioned > that often. >
Well, secure forms should be used to prevent CSRF. Even forms that only allow POST are vulnerable to CSRF, because any user currently logged into a system (thus having the session cookie) can be tricked into visiting a site/page that submits a hidden form, so POST is not safer than GET, just trickier to exploit. GET can be exploited without tricking the user to visit another site while being logged into the site attacked. If anyone is using unprotected form is directly open to a CSRF attack. How serious/significant this is to them, that depends. So the only way to ensure that a form is posted from the page it was loaded into is to include a one-time token in it, and validate the token server side. This can be done, and afaik is currently done by storing the token into session and comparing the value with the one coming from the form. My suggestion is that it does not need to be stored in the session. Since sessions are anyways tracked by a cookie, all that can be done is place another cookie containing only the token, and the SecureForm compares value from teh cookie with the value from the form itself. The cookie can be cleared, token invalidated, upon submission of the form. So even if the user is tricked to visit a malicious site which does a hidden POST (and thus automatically submits the cookie by the browser itself), there is still no known way to read the token value from the form in another window or tab. The way I see it, the benefits of having sessionless secure form (storing the token in a separate cookie) are in that the application that otherwise does not need sessions would not need to use them. Once you use sessions, EACH request results with at least one read and at least one write per session container, be it on disc or memcached. I am also not sure how exactly sessions work in Pylons, but vast majority of PHP apps that do use sessions start one (read/write cycle) even for guest users that otherwise do not need to be tracked. May be irrelevant for a number of small sites, but is significant on larger sites with large traffic, or even for small sites that get slashdotted or similar. I also believe the change required is internal to teh forms and does not invalidate any form api, decorators included. Just get/set from cookie instead of get/set from session. Vlad -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
