GitHub was recently compromised by a vulnerability in Ruby on Rails know as mass assignment. This vulnerability is thought to not only affect a large number of Ruby-based websites, but also those using ASP.NET MVC and other ORM-backed web frameworks.
Mass assignment by itself is a safe and effective technique for mapping form data to objects. The equivalent in ASP.NET MVC, known as data binding, is likewise safe when used on its own. The actual vulnerability comes from the reckless mixing of mass assignment with an ORM.
Consider this scenario: a database contains a “user” table with a mixture of sensitive and non-sensitive data. Perhaps it has some columns for a user’s display name, email address, and whether or not they are an administrator. A developer wishes to build a screen that allows for editing the display name and email address. To do so they use Rails or MVC scaffolding to automatically generate the domain objects and possibly the view itself. Then they remove from the view any non-user editable fields like the “Is Administrator” checkbox.
A security hole is created if the developer forgets to also remove the IsAdministator property from the domain object. If they don’t do so, the mass assignment/data binder can be tricked into updating that property along with legitimate changes. When the record is then saved, the ORM libraries silently store the new values.
There are three tenable solutions to this problem:
- Flag the non-updatable properties so that the mass assignment/data binder will ignore them.
- Completely remove any properties on the business object that are not actually needed.
- Create models specifically for receiving update requests and manually map them to the ORM object or stored procedure call.
It should be noted that this isn’t a new vulnerability. It is easy to find warnings about mass assignment from four or five more years ago with titles such as “Hackers Love Mass Assignment” and “Use attr_protected or we will hack you”. The only difference this time around is the high-profile nature of the victim.
Community comments
Maybe this is why Enterprise don't use Rails
by Bruno Borges,
Re: Maybe this is why Enterprise don't use Rails
by Jonathan Allen,
6 Ways To Avoid Mass Assignment in ASP.NET MVC
by Jonathan Allen,
Culture more than tool
by Francois Ward,
Re: Culture more than tool
by Jonathan Allen,
Re: Culture more than tool
by Francois Ward,
Maybe this is why Enterprise don't use Rails
by Bruno Borges,
Your message is awaiting moderation. Thank you for participating in the discussion.
Rails is driven by the community. But most of the Rails team is too supercilious. This bug is in Rails for years but nobody wanted to fix it because, they say, "users should read the docs!" which goes against some other lines like "Rails is so easy to code that you don't need to read lots of docs and understand tons of design patterns. Go for production as easy as $cap deploy".
Really?
6 Ways To Avoid Mass Assignment in ASP.NET MVC
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
K. Scott Allen has a well written piece on avoiding mass assignment vulnerabilities in ASP.NET MVC. It includes the same three options outlined above, but with specific instructions for ASP.NET MVC.
odetocode.com/Blogs/scott/archive/2012/03/11/co...
Culture more than tool
by Francois Ward,
Your message is awaiting moderation. Thank you for participating in the discussion.
The vulnerability here is more in the culture than in the tool... If i bind to a LINQ to SQL model and save it in ASP.NET MVC, then I will have the exact same vulnerability (heck, its almost -worse-, because Rails has more facilities to protect yourself in that direct binding -> save scenario). But if you look at docs, samples, or talk to anyone.... people will look at you in horror if you ever mention doing that. ASP.NET devs will use viewmodels and map them case by case to the entities.
Rails can absolutely do that, but if i google up samples, thats not what comes up. THAT is the problem. No different than some languages that for a while would encourage you to escape SQL strings instead of using parameters in queries, leading to SQL injection. Or again in .NET, the <%= construct not escaping stuff by default leading to XSS. They're not vulnerabilities per say, just bad defaults, backed with a bad community culture.
Re: Maybe this is why Enterprise don't use Rails
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
The same criticism has to be applied to ASP.NET’s TryUpdateModel function and any other convenience method for automatically mapping values.
Re: Culture more than tool
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
As much as it pains me to say it, you are wrong about ASP.NET. As of MVC 3, we are seeing built-in support for automatically building CRUD-style controllers based on Entity Framework objects. The link below shows a walk-through of the feature.
www.ittreats.com/microsoft/aspnet/ef-code-first...
Re: Culture more than tool
by Francois Ward,
Your message is awaiting moderation. Thank you for participating in the discussion.
Which isn't a bad thing. The feature is useful for prototyping. As long as the -culture- doesn't change... Just like how back in the days of typed datasets (ugh...), Microsoft's own certification tests and books would tell you never to use that for a serious app (though no one listened). As long as everyone is being told not to use those features for serious work... unfortunately, they probably won't communicate it that way.