#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)

Ci-dessous, nous avons un formulaire d'enregistrement utilisateur. Remplissons le et enregistrons.

Si on regarde les logs de développement, on peut voir que tous les paramètres que nous transmettons grâce au formulaire sont stocké en texte plein.

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

Les valeurs que nous avons saisi dans le formulaire sont clairement visible dans le fichier de log et ceci augmente évidemment les problèmes de sécurité. Rails 1.2 a introduit la commande filter_parameter_logging. En mettant cette commande dans le contrôleur ApplicationController nous permet de filtrer les paramètres basé sur leurs noms :

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

Les versions supérieures de Rails ont cette ligne dans le contrôleur de l'application par défaut mais elle est commentée donc il faut la décommenter pour l'utiliser. Nous allons créer un autre utilisateur et voir ce qu'il y a dans les 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')

Maintenant, on peut voir que notre action create a mis [FILTERED] dans le log plutôt que le mot de passe soumis. Le paramètre logging filtrera n'importe quel paramètre dont le nom contient l'argument passé, ainsi dans notre cas, le champ password_confirmation est aussi filtré. Toutefois, on peut toujours voir le mot de passe dans la requête SQL dans le log. Ce n'est un problème que dans le mode développement puisque par défaut cette donnée n'est pas stockée adns les logs en mode production. Aussi, si nous hashons nos mots de passe avant de les stocker dans la base de données alors les mots de passe ne seront pas envoyé à la base de données en texte clair et ne seront pas consultables dans les logs.