News for hackers. Stuff that matters.
Re:My Logging Best Practices (2020) by ryandrake on Tuesday October 05, 2021 @03:30PM (#28764443)
One thing I noticed in one of the article's examples is that the log contained an example user's PII:

    INFO  | User registered for newsletter. [user="Thomas", email="[email protected]"]
Ruh-roh! You now have a potential privacy incident ready to occur, if an inadvertent log leak ever happens. I think, at least these days, one vital component of any logging API is the ability to flag particular bits of information as PII so that it can get handled differently upon output, storage, or ingestion by other tools. For example, if the users's actual E-mail address is not specifically useful for debugging, do you need to display it in the default visualization of the log?

I think in 2020, with companies' privacy practices getting more and more scrutiny, any logging best practices doc should at least mention treatment of PII.

Re:My Logging Best Practices (2020) by wpietri on Tuesday October 05, 2021 @07:11PM (#28766918)
Yuuup! I've been looking through the Epik dump [1] and there's all sorts of PII where it shouldn't be. Logs for sure. Also object dumps as text fields. [2] And the most impressive mistake is logging every failed login attempt with the login and password. There are a ton of entries where people put the password in the username field and vice versa, so it's basically a big database of passwords of frequent users.

There are also a ton of tables where they made a backup copy of the table and just left it in the database for years. Ditto switching to new coce but not cleaning up the old data. So even data that would normally be removed due to, say, expiring domains ends up being preserved.

I recommend digging through it to anybody who is sad about the systems you run at work. It's such a fractal set of fuckups that I promise you'll feel better about your legacy systems.

[1] https://ddosecrets.com/wiki/Epik

[2] in PHP serialization format: https://en.wikipedia.org/wiki/PHP_serialization_format

Re:My Logging Best Practices (2020) by jgalt212 on Tuesday October 05, 2021 @11:24PM (#28768814)
> There are a ton of entries where people put the password in the username field and vice versa, so it's basically a big database of passwords of frequent users.

Or passwords these people use for other services.

Re:My Logging Best Practices (2020) by wpietri on Tuesday October 05, 2021 @11:45PM (#28768950)
Yup! With email addresses right there. I'm glad the haveibeenpwned people sent out a notice. But I'm sure some people had real messes to clean up.
Re:My Logging Best Practices (2020) by mholt on Tuesday October 05, 2021 @05:26PM (#28765823)
Ah yeah, that's why in Caddy 2 while we do emit full details from HTTP requests in our structured JSON logs, you have the ability to traverse into each log message and replace or delete data within it: https://caddyserver.com/docs/caddyfile/directives/log#filter
Re:My Logging Best Practices (2020) by tobbebex on Tuesday October 05, 2021 @05:41PM (#28766004)
I used to work with a medical software where we turned off logging completely in production, to mitigate the risk of accidentally log patient information.

We needed to log that kind of data during development and just tagging what messages were sensitive would have been too error prone, so we couldnt reliably have any logs once we went live.

We did however have a special crash handler that logged the exception type and callstack, but not even the exception message could touch the harddrive.

Re:My Logging Best Practices (2020) by slaymaker1907 on Tuesday October 05, 2021 @06:32PM (#28766572)
What I find works best is to avoid logging raw datatypes and instead limit it to objects/structs with custom toString. Then just make sure any PII fields are not included with toString either through some sort of annotation or by writing the implementation manually. This also encourages minimizing the code that actually interacts with PII such as replacing emails with user IDs ASAP.
Re:My Logging Best Practices (2020) by mikesabbagh on Tuesday October 05, 2021 @11:56PM (#28769018)
There are cases where logging identifying info is needed. In case you have a rate limit by customer, or you have dynamic firewall rules that have to read the logs.

In this case, it is permitted to collect the log and keep them temporarily (24h or so). A workflow to keep deleting older logs or scrub the logs must be installed in this case.

Re:My Logging Best Practices (2020) by pugworthy on Tuesday October 05, 2021 @03:42PM (#28764587)
Agreed.

I found out a few years back that a large industrial device our company made was recording all users passwords due to a logging statement that was blindly just logging every piece of user input via UI.

Re:My Logging Best Practices (2020) by kordlessagain on Tuesday October 05, 2021 @04:20PM (#28765066)
This reminds me of the time a developer turned on debugging to fix some credit card thing and was sending us credit card numbers in their logs.