On 02/09/2010 08:35 PM, Mike Orr wrote: > 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. >
In an ideal world, yeah. But it is the very nature of stateless HTTP that is the reason attacks such CSRF exist. However, tokenizing form is far more than just requiring users to view it before submitting. Viewing before submitting is the result of how browsers handle HTML. For instance, take the steps required to ensure a form is submitted only once. A POST is not supposed to be idempotent. Therefore preparing the means to POST data cannot be decoupled from actually POSTing the data. And this is not just the philosophy of a "pure" RESTful application. Take for instance Joe Gregorio's example of a RESTifying the Day Trader benchmark app. In there he deals with tickets to ensure a an order has been submitted only once. That obtaining the ticket (or permission to post it once if you will) is not unlike tokenizing forms. Does it violate "pure" REST or the stateless nature of HTTP (devised many decades ago)? Yes. But what's the alternative? > The most destructive thing somebody could do in my applications is > delete a major group of records. That's what I meant by the significance depending on the application. In my apps a CSRF could effectively change admin password because I deal with multiuser apps where exists an interface for users to update their passwords and other data. True, there are other ways to ensure admin account is not as easily modified, but still other user accounts could be hijacked. And it's not just that. I also deal with webshops, orders processing and payments, so in my case it is crucial. > 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. > Indeed there are situations where security by obscurity is one of the (effective) layers in the security onion. But we're talking about a generic framework to build web apps in Python. I believe it can be improved by removing sessions/beaker as dependency for secure forms, regardless if people use them or not. Speaking of sessions though, what is the status on the rewrite mentioned in the docs that should optimize session handling that is not quite optimally compatible with Beaker caching containers? > If you want to prepare a patch for WebHelpers, it will be considered. > Unless someone beats me to it, I most certainly will (look into it). Currently I am finishing a rather big PHP app for a client and this will be the last that PHP will ever see of me, then I'm jumping full time into Python and Pylons. And as I mentioned when I first subscribed, I have a set of components and practices that I'd like to port to Pylons, and I believe some of them could be used to better the framework. > 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 I will have to dig deeper in order to answer that, but I understand the concern. Unlike with sessions (beaker) -- which is in the wsgi chain -- there is nothing to import in the secure form modules in order to have access to cookies, correct? OTOH, that means several options: a) make environ globally available (thread-local?), b) make cookie management a module/object in itself (like beaker), c) make only subsets of environ responsible for request and response headers globally available like (a), or d) forget it, too complicated, if you're using secure forms you're most likely using sessions to begin with. 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.
