ASCIIcasts

9: Filtering Sensitive Logs 

(view original Railscast)

Other translations:

Below is a user registration form. Let’s fill it in and register.

If we look in the development log, we can see that all of the parameters we submitted in the form are stored in plain text.

Processing UsersController#create (for 127.0.0.1 at 2009-01-02 10:13:13) [POST]
Parameters: {"user"=>{"name"=>"eifion", "password_confirmation"=>"secret", "password"=>"secret"}, "commit"=>"Register", "authenticity_token"=>"9efc03bcc37191d8a6dc3676e2e7890ecdfda0b5"}
User Create (0.5ms)   INSERT INTO "users" ("name", "updated_at", "password_confirmation", "password", "created_at") VALUES('eifion', '2009-01-02 10:13:13', 'secret', 'secret', '2009-01-02 10:13:13')

The values we entered in the form are clearly visible in the log file and this obviously raises security issues. Rails 1.2 introduced the filter_parameter_logging command. Putting this command in to the ApplicationController allows us to filter parameters based on their name

class ApplicationController < ActionController::Base
  filter_parameter_logging "password" 
end

Later versions of Rails have this line in the application controller by default, but commented out, so we only have to uncomment it to use it. We’ll create another new user and see what’s in the logs.

Processing UsersController#create (for 127.0.0.1 at 2009-01-02 11:02:33) [POST]
  Parameters: {"user"=>{"name"=>"susan", "password_confirmation"=>"[FILTERED]", "password"=>"[FILTERED]"}, "commit"=>"Register", "action"=>"create", "authenticity_token"=>"9efc03bcc37191d8a6dc3676e2e7890ecdfda0b5", "controller"=>"users"}
  User Create (0.4ms)   INSERT INTO "users" ("name", "updated_at", "password_confirmation", "password", "created_at") VALUES('susan', '2009-01-02 11:02:33', 'verysecret', 'verysecret', '2009-01-02 11:02:33')

Now we see that our create action has put [FILTERED] in the log, rather than the password supplied. The parameter logging will filter any parameter whose name contains the argument passed to it, so in our case the password_confirmation field is filtered too. We can still see the password in the SQL statement in the log, however. This will only be a problem in development mode as by default this data isn’t stored to the log in production mode. Also, if we are hashing our passwords before storing them in the database then the passwords won’t be sent to the database as clear text and won’t be seen in the log.