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

Di seguito è mostrata una form per la registrazione di un utente. Riempiamola e registriamoci.

Immissione di dati sensibili in una form

Se diamo un’occhiata ai log, possiamo vedere come tutti i parametri inoltrati dalla form siano salvati su testo in chiaro.

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

I valori immessi nella form sono chiaramente visibili nel file di log e ciò solleva ovvie questioni di sicurezza. Rails 1.2 ha introdotto il comando filter_parameter_logging. Mettere questo comando nell’ApplicationController ci permette di filtrare i parametri in base al loro nome.

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

Versioni successive di Rails pongono questa linea di codice per default nell’ApplicationController, ma commentata, per cui l’unica cosa da fare per usarla è scommentarla. Creando ora un altro nuovo utente, possiamo vedere gli effetti sul log:

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

Ora possiamo vedere che la nostra action create ha messo un [FILTERED] nei log, al posto del valore della password fornito. Il logger filtrerà ogni parametro il cui nome conterrà l’argomento passatogli, per cui nel nostro caso anche il campo password_confirmation è filtrato. Tuttavia, si può notare anche che è ancora visibile la password nel log dell’ SQL. Ciò però, è un problema limitato al ambiente di sviluppo (development mode), poichè è solo in quel contesto che, per default, questo genere di log compare. Comunque, per risolvere anche quest’ ultimo problemino, se facessimo l’hash delle password prima di salvarle sul database, allora le password non viaggerebbero in chiaro verso il database e di conseguenza non si vedrebbero in chiaro nei log, nemmeno in sviluppo.