Skip to content

Mass assignment isn’t register_globals

So, as I’m sure you know, Github got hacked. As it turns out, the hack utilized what could easily be seen as a  vulnerability in rails: mass assignment.

As the story broke, I couldn’t help but notice that some people were quick to claim that this is a register_globals level fuckup on the part of the Rails team.

The problem, and solution.

To be clear why this isn’t Rails fault but Github’s fault, let’s look at mass assignment.

Mass assignment works like this, typically:

class User < ActiveRecord::Base

class UsersController < ApplicationController
	def update

Here we’ve said, quite plainly, that we want to find a user and update his attributes with those that we find in params[:user].

Sure, this is convenient, but if we’ve got anything in that User model that we don’t want updated by any POST to our server then we’ll have a security problem. To sort this out we can either manually filter the parameters before you tell active record to update the record or we can use the very handy attr_accessible method on your model.

Why this is not register_globals.

To my mind, this is much more like an SQL injection than register_globals. An SQL injection occurs when you pass unfiltered parameters directly into your persistence layer without any checking, filtering or sanitation. The mass assignment problem is exactly the same.

You’ll notice the code above explicitly states that we’re going to use these unfiltered parameters to update the record – ActiveRecord is doing exactly what we’ve asked of it. Register globals, however, will fuck up our php application unless steps are taken to mitigate though safe variable initialization or ensuring it’s turned off in our php config.

It’s this distinction which places the error on github’s doorstep – if the model is sensitive then this technique isn’t a good choice. The calling of potentially unsafe methods, especially when the method is as clear and obvious as update_attributes, with whatever you get from a POST is absolutely the programmer’s error – not the framework.

Bugs happen and just because popular_website uses popular_framwork does not make every problem that site faces the fault of said framework.

Categories: Uncategorized.


Comment Feed

No Responses (yet)

Some HTML is OK

or, reply to this post via trackback.