2

I am working with a webapp that runs in a Tomcat 6 server. With some request (that came from specific types of clients) it happens that the method getParameter of ServletRequestWrapper handles internally all CharConversionException logging to what i thing is the standard output of the server activity information about that exception. The thing is that sometimes it can be logging sensitive data (as password)... for example, it can log things like this :

INFO: Character decoding failed. Parameter [pw] with value [holaãã%20%222522%2] has been ignored. Note that the name and value quoted here may be corrupted due to the failed decoding. Use debug level logging to see the original, non-corrupted values.
java.io.CharConversionException: EOF
    at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:80)
    at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:46)
    at org.apache.tomcat.util.http.Parameters.urlDecode(Parameters.java:410)
    at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:370)
    at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:217)
    at org.apache.catalina.connector.Request.parseParameters(Request.java:2647)
    at org.apache.catalina.connector.Request.getParameter(Request.java:1106)
    at org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:355)
    at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:158)
    at myClasss (myClass.java:666)

I am not looking to resolve the problem in server, as i see is a problem from the client and the client must solve. I am looking forward to "hide" the value associated with the bad parameter that is outputted in the log. I am not an expert of tomcat logging system and how to configure it, i visited and read some material (this and this too..) but couldn't find a clue that pointed me into the right direction (if there is any..).

I've already took at look this ServletRequestWrapper or ServletResponseWrapper in production?, but there is no clue about how to modify this internal message.

Well thanks for everything!.

Greetings

Victor

Community
  • 1
  • 1
Victor
  • 3,841
  • 2
  • 37
  • 63

1 Answers1

1

First two remarks:

  1. The wrong encoding is not strictly a client problem; there are just different settings. So allow me to point to some server settings. Furthermore searching for "servlet filter character encoding" will yield some ServletFilters that set the request encoding right for getRequestParameter. (GET functions differently than POST!)

  2. "%2" at the end is a bit suspicious, isn't it.

The output looks like log output, and indeed in Parameters.java I found org.apache.juli.logging.Log.This yet another logging library of Tomcat, seems based on java.util.logging, and you may set the level to FATAL/ERROR in the WEB-INF/classes/logging.properties for org.apache.tomcat.util.http.Parameters=SEVERE.

Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
  • First at all thanks for the info and the answer!. Yes, indeed, that %2 came from a buggy client that we cannot modify at the moment. We haven't a file called logging.properties in WEB-INF/classes, but we could create one and append that line to control the logger associated with that class (Parameters). I will give it a try, and tell if it's works... it must works i guess... if's that is the correct logger :D. Thanks!! – Victor Jan 14 '13 at 21:51
  • Sorry mate, this has no effect :(. – Victor Jan 25 '13 at 19:09
  • BTW, in the file logging.properties we configure the logging level for each class.. so the instances of org.apache.tomcat.util.http.Parameters will log only at sereve level? – Victor Jan 25 '13 at 19:10
  • Is important to note that i am currently working with tomcat 6 – Victor Jan 25 '13 at 19:29
  • I see you are using a ServletRequestWrapper. Maybe you already have a conversion on the request (UTF-8?), and the wrapper does it again (in UTF-8?). If you do an encoding, try removing it or set it to something innocent like Cp1252 - to try. Show myclass. – Joop Eggen Jan 26 '13 at 10:14
  • Thanks Joop! I see your answer right now!, but i'm afraid i have no more access to the server (because the work finish, and we leave this leak in the log system unresolved). I can't try what you say, but anyway i will mark you answer as correct, like a way to express my humble gratitude for your time and concern! – Victor Apr 05 '13 at 20:29