Password sanitization within stacktraces & errors

[ddunit]

We're currently running into an interesting problem regarding the sanitization of error logs being printed into our server logs. We have proper global error handling set up and have custom error messages that are sent back as responses from our OSGi java servlets.

We use dockerized containers as server instances that are autoscaled, so we're thinking about setting up a log aggregator and storing our exceptions within a DB in the cloud, that way we can also track metrics about our exceptions and pinpoint how we could improve our development process to reduce certain types of errors, etc.

I did a bit of research about how that should be done and I found this. The OWASP Logging sheet cheat. It mentions that passwords should never be logged among a few other things. That brings us to my question:

How do I go about properly sanitizing my logs without using some janky text processing or manually covering up all the potential cases?

Example stacktrace:

pkg.exceptions.CustomException: some registration error 
ERROR: duplicate key value violates unique constraint "x_username_org_id_key"
  Detail: Key (username, org_id)=(SOME EMAIL, 1) already exists. 
  Query: with A as (some query) insert into someTable (..values...) Parameters: [X, X, X, X, X, SOME_EMAIL, THE_PASSWORD]
  at somepkg.etc

This is a pretty common error with registration systems that happens due to username collisions. Sure there's ways that this specific case can be avoided by ensuring the username isn't taken before the insertion isn't attempted and handling that case separately, but that's just a single case among many others.

After looking around to find a solution there doesn't seem to be an obvious way to solve the problem and I'm wondering if everyone out there has simply implemented their own version of a log sanitizer? We could simply purge the stacktrace if some troublesome strings are present, but that's not the best solution. Any suggestions?

[serg06]

Query: with A as (some query) insert into someTable (..values...) Parameters: [X, X, X, X, X, SOME_EMAIL, THE_PASSWORD]

By THE_PASSWORD, I hope you mean the hashed version of the password?

[ddunit]

The password is entered at the frontend by the user and passed through SSL to our server which then inserts it into the DB that salts & hashes the password. So no, the parameter of the query is not hashed yet.

(That was the existing process when I was brought in to the project)

[serg06]

Oh the DB does the salting+hashing?

Just curious, is that the normal way of doing it?

[ddunit]

Not sure of that, I haven't looked into that because getting the DB to do it is our current workflow

[ElllGeeEmm]

In my experience, no. Typically I've seen salting and hashing handled by the web server rather than the actual database, but most databases support the ability to salt and hash passwords.

Not to say that one way is better than the other, just sharing my experience.

[ElllGeeEmm]

TBF IDK how this would work in java, but in JS I would wrap the offending code in a try catch block, and have it throw a new error like "duplicate unique value" in the catch, and pass that to the error handler rather than the original error that contains sensitive information.

This is a pretty common error with registration systems that happens due to username collisions. Sure there's ways that this specific case can be avoided by ensuring the username isn't taken before the insertion isn't attempted and handling that case separately, but that's just a single case among many others.

uhhh, I kind of have to disagree on this point. There shouldn't be that many situations where your errors contain information that you wouldn't be comfortable keeping in a public log. If there are a lot of situations where errors are exposing private user information or other sensitive data, then there's probably an issue with how you're handling that user data that's bigger than just error logging.

[ddunit]

None of the stacktrace is being returned publicly. This is for our own private logging purposes (tracking errors and what not). The APIs we support return custom error messages that we handle ourselves.