On Tue, Feb 9, 2010 at 10:24 AM, Haron Media <[email protected]> wrote: > If anyone is using unprotected form is directly open to a CSRF attack. > How serious/significant this is to them, that depends.
I see how it can be important for certain sensitive forms, but applying it across the board violates a basic principle of HTTP that it should be stateless as much as possible and not discriminate between user agents. A form is supposed to be a tool to help users prepare a correct request, not a requirement that they must view the form before submitting it. The most destructive thing somebody could do in my applications is delete a major group of records. So the delete action has a confirmation form that forces them to type "delete" in a text box if they really want to do it. That could be spoofed, but somebody would have to study the individual site to know how to spoof it, and have a login account to to even see the site, and have sufficient motivation to craft such a spoof. If they spoof the search form to do an extra search, well whoop-de-do. > 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. > 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. If you want to prepare a patch for WebHelpers, it will be considered. One issue with cookie-only tokens is they'll still depend on Pylons/WebOb, because there's no framework-neutral way to access cookies or the HTTP headers. (The helpers aren't in the WSGI call chain, so they don't have access to the environ except by that trick in url_for which I'm trying to eradicate.) So it would still have to go under webhelpers.pylonslib, unless perhaps it had callback args in the constructor to get and set a cookie. If you can think of a framework-neutral way to do it, that would be most welcome. -- Mike Orr <[email protected]> -- 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.
