On 12 helmi, 14:10, Emil Stenström <[email protected]> wrote: > On Monday, 4 February 2013 15:06:18 UTC+1, Aymeric Augustin wrote: > > > Hi Luke, > > > This sounds like a good compromise between security and usability. > > I just want to add another voice of support for Option 3 to this thread. > > I'm one of the developers for a large site, with ~40 apps, that has grown > organically over time. Fixing all of them to have "fields" properly defined > will be a lot of work, but it's well worth it. Accidentally opening up your > models for writing is FAR to easy to do accidentally as things stand right > now. > > I understand why this started on the security list, this is serious.
My main gripe against this implementation is that the check against which fields are allowed is done at the wrong point. The right point is when the POST dict is passed to the form, and the fix is to have a mandatory allowed_fields argument at that point. If the "these fields are editable in this form" check is done at form class creation time, then it is still possible to use the same form in multiple places, and accidentally expose fields to unauthorized users that way. It is actually somewhat likely to happen in the cases where there could be a security issue currently. As for the seriousness of this issue: this isn't that serious. Currently every POST will set all fields not present in the HTML form to NULL. So, to have a problem you will need to have models with nullable fields not present in the HTML form. If this is the case you will usually spot the error as your data is silently overwritten to NULL on every form submission. Now, if the usual value is NULL, and setting to non-NULL value requires authorization, then and only then you will have security problem that is hard to spot. Such a case could be "published_date" for example. This is different from Rails. In Rails fields not present in the HTML POST kept their original value, and thus it was really easy to miss that the missing fields were actually editable. Still, I have to agree that there is a possible security issue, and the compromise solution forces developers to recognise this potential issue. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
