Is it a security flaw to log the class and method name when an exception occurs?

Question

I have the following :

public class doCheck(){

    public void performCheck(){
        try {
            perform all checks......
        }
        catch(Exception e){
            logger.error("Exception occured in class doCheck in method performCheck");
            thrown new MyNewException(e.getMessage());
        }
    }
}

Is it safe to log the class and method name?

Answer 1

That depends on whether your code base is hidden or not. If you ship the product to the client then he can inspect the Java byte code trivially anyway, so logging class names doesn’t reveal any information the user cannot get anyway.

For a server-side application, this is still true. However, it may be a security hole to display such logs to the client. That’s why most web application frameworks distinguish between a development and production configuration: during development, debug information is displayed to the user in the case of an error. In production, this information is logged on the server, but no longer displayed in the web browser / to the client.

Answer 2

@Konrad answered the direct question, however your exception handling has one minor and two serious problems. Since you originally posted to codereview.SE, here they are:

1. Logging an exception before throwing is pointless. Log it where you handle it, and don't bother catching it if you don't plan to handle ti.
2. If you're going to log an exception, log the exception; don't simply say "an exception happened" and expect people to guess what the exception is. All common logging frameworks provide a two-argument method: the first is the message, the second is the throwable.
3. Rethrowing an exception with just a message is the same problem but a worse instance. I can understand (barely) why you might not want an exception stack trace to show up in your logs. But once you throw the new exception, you have absolutely no way to tell what the real problem is. Especially if you keep up the habit of catching and rethrowing.

OK, I'm going to add a fourth issue: you log where the exception happened, but you don't say what you were doing when it happened, or give any contextual information. If you log the actual exception (point #1), you'll know where it happened. More important is saying something like "unable to open file foo.txt".

Answer 3

It's not particularly unsafe, so unless there's anything critical that you'd want to hide in this class or if the class is part of a critical path (like a secure handshake or "hidden" feature), I wouldn't consider this an issue at all.

Furthermore, we're talking about Java here. So if we're talking about a client-side app running Java on the client, they can always modify their JRE to use add their own debugging routines and/or use a custom classloader and access your classes pretty much any way they want to. Making it harder for them (by way of hiding stuff deeper, or even obfuscating code) is always a possibility, but it usually isn't cost-effective when you consider the time and effort needed to achieve this against the loss caused by statistically improbable malicious users.

If we're talking about a server-side piece of software that may output logs to clients (say, to the user's browser), then it probably isn't too big a deal, but it's already more straightforward to fix: configure your container accordingly, and use a logging framework or multiplexer to output to appropriate files on the server for debugging purposes instead. This way you retain useful records for debugging but don't compromise potentially useful information.

But in general, this probably wouldn't be a problem. it's more what you put in the debug message that could be an issue, as we often tend as developers to output things we work on (you don't want to leave these debug outputs for usernames, passwords, salts and security tokens in clear view).