#9 Filtering Sensitive Logs

Mar 23, 2007 | 2 minutes | Security

Are you accepting sensitive user data? Passwords, credit card numbers, etc. By default, Rails stores all submitted parameters in plain text in the logs. This episode will show you how to filter this sensitive input so it doesn't show up in the log file.

Click to Play Video ▶

Download:
mp4Full Size H.264 Video (4.71 MB)
m4vSmaller H.264 Video (3.38 MB)
webmFull Size VP8 Video (8.27 MB)
ogvFull Size Theora Video (7.96 MB)

Debajo vemos un formulario de registración de usuario. Vamos a llenarlo y a registrarnos.

Si observamos en el log de desarrollo, podremos ver que los parámetros que pasamos en el formulario son almacenados en texto plano.

          terminal
        
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')

Los valores que ingresamos en el formulario son claramente visibles en el archivo de log y esto, obviamente, genera problemas de seguridad. Rails 1.2 agregó el comando filter_parameter_logging. Colocando este comando en ApplicationController nos permitirá filtrar parámetros basado en sus nombres.

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

Versiones mas recientes de Rails, tienen esta línea de manera predeterminada en ApplicationController, pero comentada, por lo que solo tendremos que descomentarla. Nuevamente, vamos a crear otro usuario nuevo y veremos que encontramos en los logs.

          terminal
        
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')

Ahora vemos que nuestra acción create ha puesto la palabra [FILTERED] en el log, en reemplazo de la palabra clave escrita. El seguimiento de parámetros que configuramos va a filtrar cualquier parámetro cuyo nombre contenga el argumento que se le pasa, por lo que en nuestro caso el campo password_confirmation va a ser filtrado también. Sin embargo, aun podemos ver la clave que pasamos en la instrucción SQL en el log. Esto sera solamente un problema mientras trabajemos en modo desarrollo, ya que de manera predeterminada estos datos no son almacenados en el log en modo producción. También, si estamos hasheando nuestras claves antes de almacenarlas en la base de datos esto generara que las claves no sean enviadas a la base de datos como texto y no apareceran en el log.