Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4C5538DB.1070305@apache.org>
Date: Sun, 01 Aug 2010 10:05:31 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB;
 rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: UTF-8 encoding in Tomcat 6.0
References: <180882.95892.qm@web62101.mail.re1.yahoo.com>
In-Reply-To: <180882.95892.qm@web62101.mail.re1.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 <markt@apache.org> wrote:
> 
>> From: Mark Thomas <markt@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 <ebu@memecry.net>
>> wrote:
>>>
>>>> From: Erik Bunn <ebu@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>        
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
> 
> 
>       
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org