I am trying to get the exception details by logging it using lombok extern Slf4j. But found an issue in coverity scan as below.
This is a security audit finding. CID 227846 (#1 of 1): Log injection (LOG_INJECTION). A tainted string ex is stored in logs. This may allow for an attacker to forge log messages to confuse automated log parsing tools or humans trying to diagnose an attack or other problem. The value is used unsafely in bytecode, which cannot be displayed. Log injection vulnerabilities can be addressed by validating that the user-controllable input conforms to expectations.
log.error(Constants.EXCEPTION_OCCURRED_MSG, ex);
I rarely found options to resolve this issue. Does ESAPI or Apache log4j Audit fit here. Please suggest.
I can't speak much for Apache Log4J Audit because I have never looked at it (although, a 20 second perusal of its main web page seems to indicate it is more an attempt at structured logging messages that SIEMs would then know how to parse, rather than any sort of "safe" logging that does filtering / encoding / etc.). As for ESAPI, while ESAPI does handle "safe logging" to some degree, IIRC (didn't verify) it really doesn't do much with exceptions. Mainly ESAPI's logging trusts the exception stack and more focuses on the error message itself. Generally for secure designs, user data should never be placed in exception messages unless it is verified. But that sort of verification is not something that a general logging framework can do. To the logging framework, it has to be able to handle any Exception (or perhaps Throwable, YMMV) and any String and by the time it gets to a logging framework, the specific context is of how something should be validated is lost.
ESAPI's "safe logging" mainly consists of replacing "\r" or "\n" characters as part of the logged 'message' string (not Exception) with "_" (to prevent log injection) and optionally to do HTML entity output encoding on the message (in case one intends to peruse the log messages in a browser; the intent being to prevent XSS attacks via log messages). Although you could, with enough effort, extend it to do other things (e.g., filter out ESC sequences, etc.).
Ultimately, to prevent log injection attacks completely though, you must verify the all untrusted data before logging it. ESAPI's Validator can assist you with that, but you as a developer still need to call it with the proper validation criteria at the right moment.
Added 12/29/201: As far as using ESAPI's Validator, I did not mean to do output encoding using ESAPI's Encoder. Instead, you would create a regex to white-list your expected data and put that into your validation.properties and then call one of the Validator.getValidInput() methods. If you don't get a ValidationException thrown, the output should be "safe" according to your regex. (Note that you may need to do that in several places with many different regular expressions.) OTOH, I can't promise you that will make your Coverity scan happy as it can't possibly know whether or not the regex that you provide is an appropriate one or not. (Nor do I think it will do that deep of a data flow analysis to consider it 'safe' for use.)