CWE-532, Insertion of Sensitive Information into Log File, is simple to state: the product writes sensitive information to a log file. It is also one of the easiest weaknesses to introduce by accident, because logging feels harmless and everyone does it. It applies to any language.
How it happens
Developers add logging to understand what the code did. Under pressure, they log whole requests, whole objects, or whole command lines. Somewhere in that blob sit a password, a token, a session ID or a private key passphrase.
Debug mode makes it worse. Verbose logging gets switched on to chase a bug and never switched off.
MITRE lists two observed cases. CVE-2017-9615 describes verbose logging that stores admin credentials in a world-readable log file (Gold entry). CVE-2018-1999036 describes an SSH password for a private key stored in a build log (Gold entry). Two different products, one habit.
Here is the pattern in Python:
# Vulnerable: the password ends up in the log
logger.info("Login attempt: %s", request.form)
# Better: log only what you need
logger.info("Login attempt for user %s", request.form["username"])
What an attacker gains
MITRE lists a confidentiality impact: reading application data. Logging sensitive user data, full path names or system information often gives attackers an additional, less protected path to the same information.
That last phrase matters. Your database may be locked down and your logs may sit in a shared folder, a log aggregator with broad access, or a CI system that many people can open. The secret is only as safe as the weakest place it was copied to.
How to find it
- Search code for log statements that print entire request bodies, headers, environment variables or exception objects that wrap credentials.
- Grep existing log files for strings that look like passwords, bearer tokens and keys.
- Review CI and build logs, not just application logs. The second CVE above came from a build log.
- Run static analysis. MITRE notes that static analysis can find some instances of this weakness.
- Check file permissions on log directories. A world-readable log turns a small mistake into a large one.
How to fix it
MITRE's mitigations, in plain steps:
- Decide up front how sensitive each piece of data is. Do not write secrets into log files.
- Remove debug log files before deploying the application into production.
- Protect log files against unauthorized read and write access.
- Adjust configuration when software moves from a debug state to production, so verbose logging is off.
Practical additions that follow from those: redact known field names such as password, token and authorization in one shared logging helper, and mask secrets in CI output.
Try it yourself
The demo below walks through how a secrets scanner flags credentials in code and output.
Click through it at your own pace, or open it full screen.
Quick check
A log file is only readable by staff. Is logging a password still a problem?
Yes. Logs get copied to aggregators, backups and tickets. Secrets should not be written at all, as MITRE advises.
Where else besides application logs should you look?
Build and CI logs. One of MITRE's observed examples is an SSH password stored in a build log.
