1

In light of the recent Twitter logging bug, I've been thinking about something with my own web-app: how much information should I log in the event of a 400 or 500? I obviously don't want to be logging sensitive info such as passwords, but I also don't want to be logging to little info. If I did, I'm afraid that users run into errors without me being able to know if it was user error or a bug in the code, whether it be the error handling code or otherwise.

How do I make that judgment call? What patterns should I be following?

2

Logging is not usually a problem: just keep sensitive data out of URLs.

  • do log URLs and selected metadata for failed requests.
    • do not log the request body for POST requests. Some frameworks offer an unified view on application/x-www-form-urlencoded parameters and URL parameters. Do not log these parameters.
    • do not indiscriminately log all request headers, especially not authorization or cookie headers.
  • do log a stack trace on internal server errors.
    • do not include function arguments in the stack trace.
  • do add application-level logging to your code for selected values.
    • do not write sensitive data to the log.
    • do not rely on masking or redacting sensitive values in your log. E.g. using a regex to filter out credit card numbers is fundamentally broken.
    • do not enable extra logging unless you currently need that information.
  • do disclose logging in your privacy policy.
    • do list the kinds of stored data.
    • do specify a retention period.

A 400 client error can indicate that:

  • the user mistyped an URL (which cannot be fixed by you),
  • there is a broken link, or
  • your front-end code is generating invalid requests.

In most such cases, logging the status code, URL, and referrer is sufficient to detect problems. If there is a recurring problem and you need more information, enable extra application-level logging. For example, is the user that made this request currently logged in? In some cases, it may be necessary to log personal data such as user IDs. After you have verified a fix, you can disable the extra logging.

It is good to think about how logging can be used safely. The general principle is to be very selective about what you store. Don't dump a complex data structure if it may contain sensitive data. This also requires that the control flow in the application is fairly clear, so that you know which data structures may contain sensitive data. In the particular case of passwords, this ought to be easy: only signup/login/password-reset functionality needs to interact with passwords, and those can be reviewed for conformance.

That some companies failed to protect passwords does not imply that they used a flawed approach to logging. Instead, it could also mean that they had grown an increasingly complex system that was no longer obviously secure. Things quickly become difficult when the responsibilities for handling sensitive data are spread across multiple services, or when code that includes logging is reused to handle sensitive data.

0

The Twitter link you provided explains:

But because of a coding bug, Agrawal explained, "passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again."

The number of employees with access to that information is limited, if they didn't have as much logging as they did (log level) the problem might have continued undiscovered for some time.

To determine the meaning of the error codes see: Status Code Definitions, 4xx is 'User Error' and 5xx is 'Server Error' - in the case of 4xx the user ought not to repeat the action, in the case of 5xx sometimes the user can retry after an interval of time passes.

I like a little too much logging instead of too little, as long as it archives (compresses) weekly/daily? and deletes after a certain period of time you won't run out of space.

Different situations require a different level of logging, rarely is the logging fine-grained enough to adjust everything just right and you will need to bump up to the next level.

You can use a test account to determine if your test password is exposed and then grep the source to find the offending logging line and hash the password out of the printf'd line.

People should know that anything they put out online (encrypted or not) is exposed to multiple people, it's no different than yelling your secrets out the window of your vehicle as you drive down the street - usually the information is of little value or interest to most people. If you don't want anyone to know then don't put it out.

People using your server will need to have a limited amount of trust in you. You know their IP, when they use your server and what they do. Keeping their passwords hashed is a respect for their privacy that you can promise but it's more of an issue of trust over proof (you don't let them visit at random times to test your equipment).

Log what you need to in order to maintain your equipment and provide a reasonable level of service. Keep your equipment locked and don't let people (friends, employees, burglars) access private information. When the log is too old to keep then delete it. Random errors sometimes occur, no level of logging will help; other times problems will be reported and you will need to increase the log level to determine if the error reoccurs.

Restrict access to logs to those that need access to perform their duties and have employees made aware of your privacy policy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.