How slf4j-jboss works ?

[yunshi]

Hi,

I have a very wired question : How slf4j-jboss works ? I spent one whole day trying to figure it out ...

I have projects using the libs like

• application -> log4j-over-slf4j -> slf4j-api -> slf4j-jboss-logmanager -> jboss-logmanager
• application -> jcl-over-slf4j     -> slf4j-api -> slf4j-jboss-logmanager -> jboss-logmanager
• application -> slf4j-api -> slf4j-jboss-logmanager -> jboss-logmanager

Here comes the problem:

I simplely want to add one line in Slf4jLogger.java of slf4j-jboss-logmanager to filter out '\n' chars in the logging message, but I cannot get what I want because the functions like logger.isInfoEnable(), logger.info(), logger.trace() etc are never called !

However, I add some trace in the construction of Slf4jLogger.java to make sure that getLogger construct an Slf4jLogger. Then I emtpy all the logger.info, logger.trace, logger.debug functions in Slf4jLogger.java. When I restart jboss, logs are print out as usual while the trace in the construction of Slf4jLogger.java! tells me that I am using slf4j.

As I understand, Slf4jLogger.java of slf4j-jboss-logmanager implements slf4j-api to delegate the logging job to jboss-logmanager. But this does not happen in my jboss7...

Does anyone have some ideas about this plz ?

PS. I use jboss 7.1.1.final.

[jamezp]

You should just need to use sfl4j in your application and not include any dependencies. The server should have all the required dependencies to make it work.

If you could explain a little about why you want to strip \n out of the log messages that might help a bit to find a solution. If it's as simple as only wanting \r then you can just change the pattern. If there's more to it, it's probably more appropriate to create a custom handler for it.

--

James R. Perkins

[yunshi]

Thanks James.

I want to strip \n and \r in order to avoid the log forging problem (http://www.jtmelton.com/2010/09/21/preventing-log-forging-in-java/).

Is it possible to strip out these chars in the pattern ?

[sfcoy]

This is the same problem as SQL injection and should be treated the same way.

ie. always validate all input from a web client.

[yunshi]

Hi Stephen,

For the log foring, yes we could validate all input from a web client. But it seems more sure to also have a piece of code to make sure that the log cannot be forging.

[sfcoy]

SQL injection is a way more important problem, and if you deal with that properly you will not have any log forging issues.

Refer: http://xkcd.com/327/

[sfcoy]

And while we're on the subject *ALL* web developers should be thoroughly familiar with the OWASP Top Ten.

You will see that log forging does not rate an explicit mention, because it's well covered by other broader issues.

[jamezp]

No a pattern wouldn't fix that. You would need to use a custom handler, but at that point I would question why not just sanitize the parameters instead of attempting to do it in a logging framework? A filter might work as well, but to be honest the filter support in AS 7.1.x isn't the greatest. Just tested too and the replace filter is broken in 7.1.1.Final .

A side question have you ever seen an attack like this happen? How would the attacker know the format your logs are written out like?

--

James R. Perkins