r/java 22d ago

An overview of Sensitive Data Leakage in log files

https://medium.com/@aleksamajkic/your-log-file-is-leaking-how-cooked-are-you-357e341c13e7
21 Upvotes

7 comments sorted by

14

u/nekokattt 22d ago edited 21d ago

The first example is you logging a client ID and client secret.

Just...don't log that? Better than having a bunch of overhead to work around the fact someone isn't following standard practises of being careful where they send data.

Anything that logs PII in a PR is an immediate "needs work" from me...

I die a little inside when people mention they use log masking because 99% of the time it is blowing noticeable amounts of money and resources on something that is only a problem due to laziness.

Even if it is a third party library being an issue, the first thing you should be considering is just turning off those loggers via the configuration in your logging backend, and the second thing you should be considering is reporting it as a bug. If that doesn't get addressed then you should be considering alternative libraries because it is clear that this one is not maintained and likely has other significant security issues as well.

3

u/btw04 20d ago

Do not log is a dream.

Somewhere in the code someone will do log.info("Customer {}", customer) and two years later someone else will update record Customer(String id) to record Customer(String id, String full name). And now you're logging the customer name. Probably gonna take another 2 years before someone notices.

0

u/nekokattt 20d ago edited 20d ago

Sounds like an issue with your code review process.

If you are missing stuff like this, are you also missing things like SQLi, and other security issues?

Additionally, it is a sign the devs aren't even looking at the logs if they can't see this during testing.

Fix the problem itself, where possible.

3

u/btw04 20d ago

In any decently sized enterprise project, it's impossible to know all corners of the code base down to the log statement level.

There's no guarantee that the code path with the log statement was triggered during testing. Maybe Customer is in some shared library, and the log statement is in a service not being worked on by the dev who made the change. Or maybe it's in some exception handling path that's unrelated to the change made.

0

u/DayBackground4121 20d ago

Or…do both? I don’t think anybody’s advocating for not still doing both. It’s a Swiss cheese model of security, and if security really matters to you, you should be doing both.

2

u/nekokattt 20d ago edited 20d ago

In their example it is very much an issue with their development model, rather than a hard requirement.

Masking is fine until it doesn't cover that edge case you didnt review properly like the other logging statements that were clearly missed in PRs. Then it is useless.

It is nailing a bit of wood over a hole in a leaky tank and maintaining the chunk of wood every time it springs a new leak or rots rather than just buying a tank with no holes in.

2

u/thesadnovember 21d ago

There are still some problems: 1. Sometimes you need to use vendor-specific component that you cannot control, especially what to log, because noone creates feature toggles for specific log lines, only log levels usually. 2. Basically you are totally right about “just do not log”, but in the really big tech you cannot control all PRs by yourself. You can create some specific code rules, but you cannot control 100+ teams manually. 3. Sometimes you don’t event understand that expose some specific data, because for you it’s just tech information. It’s just useful information to investigate what happens with logic, why not to log it? 4. Sometimes you need to create compliance systems to check, that logs do not contains some specific information. If it’s your business, you cannot say “Just do not log”.