Wednesday, November 29, 2006

Rails Security Checklist

Security is a dull topic, but will become exciting if you screw it up. To avoid such excitement, here is a checklist for reviewing security in models, controllers, and views. If you see holes, add a comment and I'll update the list.

Security checklist for models:
  • Use attr_accessible (or attr_protected if you must) to explicitly identify attributes that are accessible by .create and .update_attributes. Just because you don't expose an attribute on an edit form doesn't mean that someone won't try to post a value to it. I prefer attr_accessible over attr_protected as it fails on the side of safety when new fields are added to a model - you have to explicitly expose new fields.
  • Make sure queries are using the Rails bind variable facility for parameters, not string concatenation or the handy Ruby's #{...} syntax.
  • Use validations to prevent bad input.
Security checklist for controllers:
  • Make non-action controller methods private (if possible).
  • If non-action controller methods must be public, identify them with hide_action to prevent unwanted execution.
  • Make sure before_filters are in place if necessary for your authorization infrastructure.
  • Move queries from your controller to your model, and see the model checklist above.
  • Check for params[:id] usage - are you sure you can trust it? Check for proper ownership of the record.
  • Check for usage of hidden fields - a user can send anything to you through them, so treat them with suspicious just as params[:id] should be suspect.
  • Use filter_parameter_logging to prevent entry of sensitive unencrypted data (passwords, SSN's, credit card numbers, etc.) in your server logs.
  • Forget about your view code for a minute, and think about how to protect your controller from posts a malicious user could make to any of your exposed methods. All parameters (whether or not exposed on a form, and whether or not invisible) are suspect to length overruns, bypassing of any browser based validation, attacks with malformed data, etc.
Security checklist for views:
  • Make sure all data displayed is escaped with the helper method h(string).
  • Eliminate comments in your views that you don't wish the entire world to see.
What else? (In particular, considerations for REST web services and AJAX need to be added).

5 comments:

Fref said...
This comment has been removed by the author.
Anonymous said...

I recently found a very interesting website:
http://alreadylinked.com/
There you can purchase ad space for your Blog etc.

James H. said...

I liked your point about considering the controller without the view in place. I can't quite recollect the article at the moment, but I was once shown how to interact with a controller via script/console. If you're vulnerable there, you're vulnerable online too.

Buben Razuma said...

Aren't Object#taint, Object#untaint and Object#tainted? methods used for the security purposes?

H. Webers said...

Thanks for the list. I'm doing Ruby On Rails Security here: http://www.rorsecurity.info/