Filtered parameter logging

Posted by josh August 21, 2006 @ 04:33 AM

Now that the hubbub about the recent security issues has died down, I think it's worth pointing out a little jewel that was snuck into the 1.1.6 security release of Rails that most people missed.

ActionController#filter_parameter_logging lets you filter form data that you don't want saved in the log. This is useful for preventing sensitive data like passwords and credit card numbers from being logged in the clear, for keeping huge pieces of data from clogging the log file, and so on.

If your application accepts passwords, paste this line into your ApplicationController class:

filter_parameter_logging "password"

That will prevent any field with a name matching the pattern /password/i from being logged, so both [user][password] and [user][password_confirmation] will be filtered out. If you care about preventing exposure of passwords, go do that right now.

Credit to Jeremy Evans for his patch!

Posted in Documentation | 15 comments

Comments

  1. Joe Ruby on 21 Aug 04:53:

    How can I have POST logging enabled in development mode but completely disabled in production mode?

  2. josh on 21 Aug 05:16:

    Joe, I think this should work to control filtering:

    filter_parameter_logging("password") if RAILS_ENV == "production"

    If you want to disable POST logging entirely, put this in your production.rb file:

    config.log_level = :warn
  3. evan on 21 Aug 06:53:

    Hmm, why is this in the controller, instead of the model?

  4. Steve B on 21 Aug 09:07:

    @ evan: Why should it be in the model?

    Controllers are about communication between the outside world of views and webservers and the inside world of business logic and databases.

    The filtering of http parameters from logs is an issue controller as it’s the controller that handles the http request.

  5. eyp on 21 Aug 09:23:

    evan, models must not know anything about request params.

  6. Stoffe on 21 Aug 12:36:

    Hmm, why is this in the controller, instead of the model?

    Because it is posted parameters logged by the controller, I would guess. They haven’t hit the model yet, and it is possible (although unlikely) they never will.

    That said, doesn’t Rails log SQL querys as well that could use something similar?

  7. karl on 21 Aug 12:59:

    Because the controller is responsible for logging request paramaters, and now – for filtering them as well.

  8. evan on 21 Aug 15:07:

    Oh, right. I was thinking model fields, not form fields, for some reason.

  9. Jeremy Evans on 21 Aug 15:34:

    I wrote the patch/plugin. I hope everyone else finds it useful.

  10. procreate on 21 Aug 17:48:

    Jeremy, very nice. Thanks!

  11. Brian on 21 Aug 18:09:

    Just a passing note to other noobie readers like myself, this also works:

    filter_parameter_logging :password

    In other words, symbols will work as well of course. Sorry to state the obvious but I had to stare at the example above a bit to figure out why it looked non-Railsy to me.

  12. Brian on 21 Aug 18:10:

    Oh, and very nice feature by the way! Thank you!

  13. Zachery on 21 Aug 20:09:

    @stoffe this should not be a problem as you should never be storing passwords in cleartext in the database. you should be using an md5/sha1 hash (and salting it?)

    that said the only thing your sql will see is an md5/sha1 hash.

  14. dizave on 23 Aug 17:29:

    Am I the only person wondering why someone would sneak new features into a critical security fix??

  15. Julien Jaborska on 26 Aug 15:05:

    Zachery: I think it’s for before it hits the model and SQL. The form data itself is not hashed yet (unless you do it in javascript or something), that is what you want to prevent being logged.