The Panic
August 29th, 2007
If you’re a developer, you know what I’m talking about. You’re doing something seemingly trivial, when you see something, you’re not sure what it is, but it doesn’t look quite right. You squint at it. Then you realize, this is something bad, something big, something really big and bad.
You then start down a roller coaster of emotions and reactions:- Denial: “No, my code isn’t really doing that.”
- Anger: “Why is my stinking code doing this!”
- Blame: “It’s got to be something wrong with a library or a bad default setting.”
- Generalization: “I can’t be the only person this is happening to. Is this is happening on every site?”
- Acceptance: “Ok, this is wrong and it needs to be fixed.”
It happened to me yesterday, while scanning the logs of an internal app looking for bugs. I started noticing something that didn’t seem quite right. My application was logging all the details of login requests, including passwords. That’s right, passwords and their associated usernames were just sitting in my log files, clear text for the world to see.
So I started the panic…all the stages flew by in a matter of minutes. Then I did the constructive thing and hit up Google for an answer. And one was right there for the taking.
If you use Ruby on Rails, you need to add this to your ApplicationController for every application you havefilter_parameter_logging :password, :password_confirmationWhat does this do? Well as you probably guessed, it filters the given parameters from being logged in your log files. The request will still be logged, only the specified parameters will be logged as “[FILTERED]” instead of their actual values.
Now I know what you’re thinking, “Why isn’t this taken care of by default?” or “How did I miss this?” The first is valid, the second, well you can console yourself in the fact that for some reason it doesn’t seem to be common knowledge among rails people. Let’s fix that shall we…
Special thanks to Baldur Gudbjornsson’s blog for stopping the panic for me!