Hi Simon, > CSRF[1] is one of the most common web application vulnerabilities, but > continues to have very poor awareness in the developer community. > Django ships with CSRF protection in the form of middleware, but it's > off by default. I'm willing to bet most people don't turn it on. > > I don't believe middleware is the right way to approach this. It's too > "magic" - it involves code that parses and re-writes your HTML as the > response is being returned. It also means CSRF failures can't be > gracefully handled - the middleware can throw up a big ugly error > page, but ideally a CSRF failure would be treated the same way as a > regular form validation error. > > I propose django.forms should include a SafeForm class, which is a > subclass of Form that includes built-in protection against CSRF. I > imagine the interface looking something like this:
I carefully prepared a reply to this, only to forget to transfer it to my memory stick for sending (I have just moved house and I'm without internet connection to my own computer...). Anyway, here is a shortened version, hope it makes some kind of sense as it was written hurriedly. I'm unlikely to be able to reply to any responses to this, for reasons mentioned above. I agree that the CsrfMiddleware is ugly, but before replacing it, here are the things about it that I do like: - It Just Works (after you turn it on). - The only ugly bit (which is also the 'fragile' bit) is the post processing HTML munging, and if this fails, you are secure by default. - You don't have to remember to do *anything* for it to work, you just turn it on once. This is a big deal -- this is why we have SQL escaping in the ORM, and auto-escaping in the templates. If you leave something to human error, humans will make an error. - You don't have security related boilerplate code messing up every view function. This means all the ugliness of having to deal with the real world of CSRF etc has been confined to one ugly middleware. - It works for non-Django forms, which I do have sometimes e.g. forms with a dynamic number of controls, like tables with a checkbox in each row for manipulating large numbers of objects. I have several instances of this in my code already, I'm glad I don't have to re-implement CSRF protection for these. It also Just Works for AJAX (you may have to do extra work to get hold of the token client side, and of course you need to use POST appropriately in your AJAX). - If we moved to a SafeForm, at least the SafeForm code thus far proposed, it would be more work to be CSRF safe than non-safe, and all the example code for Django froms on tutorials acrosss the internet would therefore be non-safe, just like all the example PHP code across the web is vulnerable to all kind of hacks. - There are ways of making the existing implementation nicer (e.g. redirect to a view which handles the error more gracefully, with a link (via REFERER header or something) to the original page, or something like that), and we could turn it on by default in default settings - SafeForm probably couldn't do that. I'm not saying don't replace it, but let's make sure the cure is better than the illness. Regards, Luke --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
