Ruby on Rails Security Checklist
Contact me at LinkedIn  RailsZilla at Facebook  RailsZilla at twitter   google +1  Contact me at Xing  connect me at github

Ruby on Rails Security Checklist

Posted in Rails

When ever we create a project, the same issue is our pain in the ass …
I talk about Security which is somehow dull and seems to be boring. I have done a simple checklist for a quick review of your code, which is divided in three simple steps: model, view and of course controller.

Our quick security checklist for your models

Use the helper method

1
attr_accessible

or

1
attr_protected

if you have to explicitly identify attributes that are accessible by the actions “create” and “update_attributes”. Don’t ever think that someone won’t try to post a value to your form.

Another thing to be aware is, when we use

1
attr_accessible

instead of

1
attr_protected

in this case we have the the advantage that it fails if new fields are added to a model. In this case you have to expose new fields explicitly. The method attr_accessible specifies a white list of model attributes that can be set via mass-assignment.

The next step is to analyse our queries and make sure, we are using the Rails bind variable facility for parameters. We do NOT use string concatenation or the convenient Ruby’s #{…} syntax. Generally we use the handy validations which are offered from ActiveRecord to prevent bad input.

Our security checklist for controllers

  • We make sure that before_filters are in place if necessary for your authorization infrastructure.
  • If we have non-action controller methods which must be public, we identify them with hide_action to prevent unwanted execution.
  • We move all queries from our controller to our model. For mdel security please have a look above …
  • The really bad thing (and often ends up in a disaster) are params[:id]. You neve can be sure that you can trust it. We allways check for proper ownership of the record.
  • Hidden fields are a thing to observe … 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 like passwords, SSN’s, credit card numbers etc. in your server logs.
  • We make non-action controller methods generally private if this is possible.
  • Protect your controller and exposed methods from posts of an evil user. All parameters are suspect to length overruns, bypassing of any browser based validation, attacks with malformed data and so on …

Security checklist for views:

In older Rails Projects we generally escape the displayed data with the helper method h(string). In the current version of Rails we do not need it anymore. When making comments in your views, take care to not use html comment tag

1
<!-- information about security things in comments are a bad thing -->

We better use the comments inside a ruby comment tag like

1
<%# this information will be invisible for browser/client %>

This post will be updated when having the next cup of tea …

Tags: , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

Please enter a secure code to see if you are a spammer ;-)

 

Copyright © 2011-2017  - RailsZilla – Ruby on Rails tutorials, tips and tricks All rights reserved. | Imprint | Privacy