This post originated from an RSS feed registered with Ruby Buzz by Robby Russell. Original Post: Rails Code Audit Tips - Filtered Parameter Logging Feed Title: Robby on Rails Feed URL: http://feeds.feedburner.com/RobbyOnRails Feed Description: Ruby on Rails development, consulting, and hosting from the trenches... Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Robby Russell Latest Posts From Robby on Rails

It’s been a month since I posted, Audit Your Rails Development Team and now I find myself sitting in a hotel room in Mankato, Minnesota with Graeme after a long day of walking through the documents that we delivered to our client after conducting a Rails Code Audit and Review. Our client felt that it would be a great idea to have us visit with six of their employees and walk through the various topics that we brought up in our process. We’ve been doing several of these audits recently and are thought that it would be a good idea to begin sharing some problems that we’ve discovered across projects.

As much as we like to find lots things that we’d recommend improving in Rails applications, we also want to make sure that as many projects as possible avoid some of these common oversights. So, expect to see more posts related to things that we find through our Code Audit and Review process.

Today, I’d like to point out a potential security problem that is often overlooked by developers and system administrators.

Log files.

Does your application request any of the following information from your users?

• Social security number
• Credit card date (number, expiration date, etc..)
• Passwords

BY DEFAULT, all of this data is being written to your production log file. Even if you’re encrypting this data in your database, request parameters (get/post) are all written to your production logs without any encryption. Log files are also notorious for having insecure file permissions, so if you’re on a shared host, other accounts on the server might be able to view them. Regardless of how secure you think your server is, this isn’t data that you want sitting around.

Lucky for you, Ruby on Rails has an easy solution to this problem! All that you need to do is use the filter_parameter_logging method in your controller(s). We generally add something like the following to our application controller.

  filter_parameter_logging :social_security_number, :password, :credit_card_number, 'some-other-param' 

This will replace the value from the parameters with [FILTERED], which solves this problem rather nicely.

So, it would be our recommendation, that if your application is storing any sensitive data, that you take advantage of this simple solution. Be sure to read more about filter_parameter_logging before you implement this for various usage examples.

Stay tuned for more tips and tricks. If you’re interested in contracting us for our Rails Code Audit and Review service, give us a call.

Tomorrow, Graeme and I will be meeting for another day with our clients and then we fly home to Portland, Oregon in the evening. We survived our first tornado warnings, which was exciting as we don’t get those on the west coast. ;-)