On 31/07/2010 17:34, arun kumar wrote: > > I ran my example webapp on a standalone tomcat and the behavior was the same: > When the param is being sent using GET, I need to send the param as %25xx for > it to be read correctly > When the method is PUT, %xx works fine.
Then something in your setup is badly broken, evidenced by the fact you have to encode the % as %25 to get things to work. > I believe this is a known issue with Tomcat: I remember reading this on many > forums. I believe this is the same behavior that Erik reports. This is absolutely *not* a Tomcat problem. Tomcat does not behave the way you describe. A clean Tomcat install with no other components (reverse proxy etc) using the test encoding JSP from the wiki [1] works correctly with POST and GET (if URIEncoding="UTF-8" is used). > Sorry Mark - i did not get what you said. Could you please elaborate? Decoding is happening twice. i.e.: %25xx -> %xx %xx -> whatever character Tomcat absolutely, 100% does not do this. Either your test application is doing it or there is another component - such as a reverse proxy - in the mix that is doing a second decoding. This represents a significant security risks. Issues caused by double decoding in the past include: - XSS - source code disclosure - authentication bypass - directory traversal It does not mean that these issues will be present, but double decoding has been the cause of all of these - and probably more - at various points in the past. The details will depend on system configuration but seeing an issue like this is certainly indicative that there may well be a problem. Mark [1] http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q4 > Regards > Arun > > --- On Sat, 7/31/10, Mark Thomas <ma...@apache.org> wrote: > >> From: Mark Thomas <ma...@apache.org> >> Subject: Re: UTF-8 encoding in Tomcat 6.0 >> To: "Tomcat Users List" <users@tomcat.apache.org> >> Date: Saturday, July 31, 2010, 12:18 PM >> On 31/07/2010 15:40, arun kumar >> wrote: >>> Hi Erik >>> Thanks very much for your responses. >>> I can assure that i'm interested in this topic even >> now :). >>> >>> My scenario is this: >>> >>> 1. I use a web application that runs in JBOSS. >>> >>> 2. JBOSS uses a tomcat web container from what i can >> see. >>> >>> 3. To my application if i pass a UTF-8 encoded value >> in hex e.g: >>> >> http://<server>:<port>/<servlet>/param=%xx... >>> >>> Then %xx is not decoded properly. I initially used to >> send the request with a mozilla browser but later started >> sending it with a java program as well with the same >> results. >>> >>> I tried setting the URI Encoding parameters in the >> tomcat server.xml - with no success. >>> I then set a filter to specifically set the encoding >> to utf-8 - again with no luck - behavior was exactly the >> same. >>> >>> But when i sent the param as %25xx ( %25= hex value of >> the % character), it worked fine but i suspect that the >> string gets stored in ISO 8859 format - like you say: it >> gets mangled... >> >> That smells of double-decoding which as well as breaking >> your app is >> also a security risk. I have seen this when a reverse proxy >> is in the mix. >> >> Tomcat will *not* do this on its own. >> >> Mark >> >> >> >>> I wrote a standalone web application that showed the >> same behavior. >>> I haven't tried with a standalone tomcat. >>> >>> I know that we need to take care of the encodings at >> various points but how can i rule out a problem with >> my web container configuration settings? Or can it be a >> problem coming from the web container itself? >>> >>> Thanks and regards >>> Arun >>> >>> >>> --- On Fri, 7/30/10, Erik Bunn <e...@memecry.net> >> wrote: >>> >>>> From: Erik Bunn <e...@memecry.net> >>>> Subject: Re: UTF-8 encoding in Tomcat 6.0 >>>> To: "Tomcat Users List" <users@tomcat.apache.org> >>>> Date: Friday, July 30, 2010, 1:55 PM >>>> On 7/30/10 6:33 PM, Christopher >>>> Schultz wrote: >>>> >>>>> If all you want to do is set the character >> encoding, >>>> you can easily call >>>>> setCharacterEncoding and be done with it: >> subclassing >>>> and overriding >>>>> should not be necessary at all, otherwise >> nobody would >>>> have written one >>>>> of these: >>>> >>>> No, I have other reasons to mess there. >> Nevertheless, >>>> adding a filter is >>>> probably less iffy, thanks for pointing that out. >> TC7 >>>> provides a suitable >>>> example: >>>> >> .../webapps/examples/WEB-INF/classes/filters/SetCharacterEncodingFilter.java >>>> >>>>> Tomcat versions before 7.x had an option in >>>> the<Connector> which could >>>>> be used to set the request URI encoding to >> that of the >>>> Content-Type of >>>>> the request (useBodyEncodingForURI) and >> another option >>>> for explicitly >>>>> and unconditionally setting the encoding to be >> used >>>> for URI decoding >>>>> (URIEncoding). I haven't read-up on Tomcat 7 >>>> behavior. >>>> >>>> 7.x Connector has the exact same options. I'll >> restate, >>>> though, that setting >>>> the Connector URIEncoding in TC7.x won't currently >> help >>>> when decoding GET >>>> parameters in a no-content-type case - without the >> filter, >>>> they will be >>>> mangled as ISO-8859-1. If this is different from >> previous >>>> behaviour, maybe I >>>> should report a bug. >>>> >>>> Thanks, >>>> //e >>>> >>>> >>>> >> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> >>> >>> >> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
