The problem is that newlines in log messages cannot be disallowed because they may be desired. So trying to filter them out to prevent forgery results in loss of desired functionality. Formatting of stack traces is a prime example, but I can imagine cases where statistics might be printed in a single log event but formatted on multiple lines.
In general, Appenders do not do any formatting so adding options for this there wouldn't be correct. It would make far more sense to create a Layout that wraps other Layouts to do this. Ralph On Aug 9, 2013, at 1:29 PM, kommersz wrote: > > Hi Gary, > > Even this could work theoretically, but it does in reality not: in > PatterLayout.format the Converter (by default the > LineSeparatorPatternConverter) is called _before_ the replace is called (in > PatterLayout.toSerializable), resulting in following: the "\r\n" added by > LineSeparatorPatternConverter.format is simply replaced, resulting in a log > file containing no line feeds. > > Besides this tiny bug, I still wonder: if we want proper secure file based > logging, should we address Log Forgery all times by introducing a custom > replacement pattern? > > I do recall Remko saying "I worry about the performance impact" and "The > application knows which points are vulnerable and it knows what form the > input takes so it is best positioned to protect itself" - all this lets me > think that the main reason for concerns about updating Log4J for protection > is performance. So far I had 3 recommendations on how to fix: > Remko was suggesting to dig out linefeeds on the caller side, as then it can > be selectively applied - no doubt it would be the most performant - I just > wonder if in a complex real-life application (as for example in our case) it > is really easy and straightforward to track, where a string is coming from > (was maybe mixed up with other user input, might come indirectly via > database, from a call via an untrusted source etc etc) > As with the two other proposals, it would introduce an additional layouting, > either custom (which would be maybe redundant to be implemented every time > someone uses Log4J) or by configuring PatternLayout (which is done with regex > - what I would consider more questionable from a performance perspective than > a simple hand-coded replace)... > > I am still somewhat insistent on that maybe a configuration option for any > affected appenders (e.g. FileAppender) would be handy - so if people want to > go for so much performance, they can turn off linefeed elimination, and risk > that their logs will be tampered with. > > I know I am not in a good position with my plea, as I have not been an active > developer of Log4J so far - but as I am a user of this, I am somewhat > enthusiastic about making it superior, so I would give it a last try on > promoting this idea :) > > Cheers, > Gabor > > > > > > ---------------------------------------------------------------------- >> Can you do what you want with the PatternLayout's replace feature? >> >> Gary >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
