Gabor,
I don't believe it is the responsibility of the logging library to protect
against malicious input.
Not only do I worry about the performance impact, I also don't think it is
possible to protect against everything.
A much better place to do this would be the application logic. Take the example
given in the first link you provided:
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException) {
log.info("Failed to parse val = " + val); // original example
log.info("Failed to parse val = " + URLEncoder.encode(val, "UTF-8")); //
protected correctly
}
In the above example, an easy way to protect against malicious input was to use
URLEncoder.encode(), because the application is a web application and the input
is coming from an HTTP request. But that is not the only input method. What
about cut-and-paste in a Swing application? Apps reading from the command line?
Log4j cannot and should not try to protect against all.
The application knows which points are vulnerable and it knows what form the
input takes so it is best positioned to protect itself.
Best regards,
Remko
________________________________
From: kommersz <[email protected]>
To: [email protected]
Sent: Thursday, August 8, 2013 5:12 PM
Subject: Log Forgery and log4j
Ladies and Gentleman,
Recently I came across an issue with Log Forgery
(http://cwe.mitre.org/data/definitions/117.html) - a problem where line feed
characters passed over to logging results in extra log entries created when
simple file-based logging is used.
Checked briefly with log4j appenders, also the mailing list, but found no
methods of protection against it.
So now if a "\r\n" is added, it can result in two log entries, e.g. with
FileAppender. Not being black belt in log4j, however, it might happen that I
overlooked something. So any hints?
Cheers,
Gabor
P.s.: Googling "log4j log forgery" brings
http://www.jtmelton.com/2010/09/21/preventing-log-forging-in-java/ as a result,
which suggests a wrapper, utilizing ESAPI functions to sanitize... - this also
raises the question, if it is really the supported way of fixing this issue by
always wrapping log4j into another API before using?
