Confusion between “Logging and Debug”
I was talking with one of my consultants the other day about a common confusion Developers sometimes have regarding a pretty mundane piece of security guidance. Specifically, “What does it mean I have to turn off logging/debug in production?”
In my mind, these two separate issues exist here, intertwined.
Almost every logging framework has an in-place configuration option for increasing/decreasing log-level; most allow you to reconfigure on a running system without restart. The point here being that an application developer, with use of such a package, get to 1) keep a single code base, 2) turn a high level of logging off by default in a production environment, and 3) ratchet up log-level in circumstances requiring it (incident response or in-place debugging).
Often, people mix the above guidance with “don’t roll debug code out to production.” Code Analysis tools, for instance, give this advice. Two things principally concern me here. First, you don’t want a bunch of “main” or other “debug-only” entry points to the code. Attackers capable of compromising host systems could shoe-horn their way into an application this way. The situation becomes worse when said debug interfaces are web-based. Second, especially for thick clients or code running in less trusted environments, debug code tends to ‘express’ things about the design (or leak critical data) in an undisciplined manner. Removing such code from deployments to untrusted zones CAN be advisable, but one must balance complete removal with the need to ‘turn on’ nascent debug code in times of need as described by the previous paragraph. Only protection of the most sensitive information, and most invasive code qualifies for the extreme guidance “remove before deploying” that this paragraph describes.
The best thing one can do is give the developer guidance as to what types of test/debug code might qualify for wholesale removal. I’ll start you a list:
- Client ‘harness’ code allowed to connect to server interfaces w/o
authentication - Client code allowed to edit/manipulate local data repositories/stores
directly - Command ‘harnesses’, allowed to (re)set or manipulate server state
- Client code that dumps secret keys, tokens, or stored-but-otherwise-protected credentials
- Backdoors
- Code allowing for ‘insecure failure’ or back off, say to an older protocol
- ‘Re-implementation’ outside a sandbox (native equivalents of a managed binary)
Just a small tidbit, away from the glib towards concrete guidance.
-jOHN
