logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <rem...@yahoo.com>
Subject Re: Log Forgery and log4j
Date Fri, 09 Aug 2013 05:06:31 GMT

I don't believe it is the responsibility of the logging library to protect against malicious
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,

 From: kommersz <kommersz@freemail.hu>
To: log4j-dev@logging.apache.org 
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?
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?
View raw message