#9 Filtering Sensitive Logs

Thanks, I put it on the Rails Security Project: http://www.rorsecurity.info/

filter_parameter_logging "password"
good tip

Great stuff. Am interested to know what the prompt is for rails also [FILTERING] out the password confirmation field? Is this parameter key a regex?

It's suggested here that you need to have both :password and :password_confirmation in the filter_parameter_logging call -

http://wiki.rubyonrails.org/rails/pages/HowtoAuthenticate

I think rails filters confirmation field automatically if you filter the password field. So you don't need to explicitly say so.

Is there a way to get the exception_notifier plugin to use the filter_parameter_logging directive?

Anyone played with exception_notifier and parameter logging?

I would be nice with an explanation of how Rails know to filter password_confirmation?

Very good cast and good solution. I am sure that many developers forget about data in logs

I think it filter both because it match the start of the strings, thought I haven't tested myself.

I mean if there is filter for password and you have password_field1, password_field2, password_field3, it will [FILTER] those 3.

but these parameters are not filtered if some exception occurs.

how filter parameters from exception log as well?

Deprecated in Rails 2.3.8

See Daily Ruby Tips

This episode has been updated to Rails 5 as a blog post. Filtering Sensitive Parameters from Log Files in Rails 5

Ok guys for those using Rails 4 and up:

go to this file: filter_parameter_logging.rb in config/initializers folder:

You will notice that this is already in there: Rails.application.config.filter_parameters += [:password]

that means all parameters with the word "password" in it will be filtered out. But you are not safe yet! You also need to ensure that you are not logging the sql entries. In order to check that you need to ensure that in:

config/environments/production.rb

there is a line like this:

config.log_level = :info

make sure that the log_level is anything BUT NOT :debug.

and then you are more protected. I would suggest in the production environment to have something above :info. Info is a little too insecure in my opinion.

I hope this post helps someone!

Ben

I needed to do the same thing: transform a field in a JSON blob that was sent with an HTTP POST to a Rails 3 app. In my case I just wanted to include a hashed digest of a field, so in config/application.rb:

config.filter_parameters += [:password, lambda {|key, value|
if key.to_s == 'my_key'
value.replace(calculate_my_hash(value))
end
}]

weteng mules