GitHub Compromised by Mass Assignment Vulnerability

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.

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".

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.

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.

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.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.