On 2012-03-07, at 07:53 , Peter Murphy wrote: > > > On Mar 7, 10:13 am, Donald Stufft <[email protected]> wrote: >> >> For what it's worth in the context of the Homakov exploit, this has been a >> well known vulnerability by the rails core for years >> that they've basically said "not our problem, configure your app better" the >> entire time. I think that situation is the one that >> Joey was referring too. > > I hope that Django has no vulnerabilities of the "WTFitude" that Ruby > on Rails has with "mass assignment" vulnerabilities. I got this link > from Homakov's github complaint[1]. > > http://enlightsolutions.com/articles/whats-new-in-edge-scoped-mass-assignment-in-rails-3-1 > > "If you’re using Rails and you want to be secure, you should be > protecting against mass assignment. Basically, without declaring > attr_accessible or attr_protected, malicious users can set any column > value in your database, including foreign keys and secure data." > > Huh? (With a side helping of jaw dropping.) Why would you allow your > users to get anywhere near the DB code?
You do that any time you create an object using POSTdata (which you should not do). That's how "near the DB code" this comes, the code essentially does the same thing as `Model(**request.POST)… except it can also work for updates. And that's a normal rails idiom apparently. > Why should it be even > possible? Why would "magic" attributes make a difference? "Mass assignment" works through a dedicated method (ActiveRecord::Base#update_attributes). ``attr_accessible`` and ``attr_protected`` control the behavior of this method by respectively whitelisting and blacklisting fields the method can touch. That's why these attributes make a difference: by using ``attr_accessible`` (the other one should not be used) you define any attribute which is "safe" to update. > In Django, you abstract the models code (which reads and writes DB > records) from the views (where all the monkey business could occur) > from the urls. At least that's what I thought you should do. You also > make the views in charge of checking whether your requests are POSTs > or GETs. It's the same in Rails (modulo a few things), the issue here is at the point where you move data from the view to the model, and Rails's "ethos" of doing data validation in the model rather than the view when possible. Django tends to have much lower a hangup on implicit behavior (so between a potentially dangerous implicit behavior and a safer explicit one, Django will not implement the implicit and require explicitness) and modelforms act as fields whitelists (even more so because they're easy to compose). -- You received this message because you are subscribed to the Google Groups "Django users" 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/django-users?hl=en.
