Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <47AF2B25.9080904@hanik.com>
Date: Sun, 10 Feb 2008 09:49:41 -0700
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Cookies are broken in 6.0.16?
References: <5245102a0802082243u1c75eb0fl77dee2f5e5d45ad7@mail.gmail.com>
	 <47ADA4AC.2080302@apache.org>
	 <1202596086.4884.3.camel@localhost.localdomain>
	 <47AE33D5.3000301@hanik.com>
 <1202604089.4884.13.camel@localhost.localdomain> <47AE55D5.70608@hanik.com>
 <47AE5DF4.2070704@manico.net> <47AE6F96.6010400@hanik.com>
 <47AED113.3080907@apache.org> <47AEE263.8000704@apache.org>
In-Reply-To: <47AEE263.8000704@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Mark Thomas wrote:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>>> Jim Manico wrote:
>>>> > I guess we could throw a run time exception if the value 
>>>> contained any of those. other than that, I'm not sure how to behave
>>>>
>>>> I think this is the best case scenario for v0 cookies. Perhaps, if 
>>>> you really want to get fancy, you can add a flag to let legacy 
>>>> solutions roll back to the old/non-standard cookie handling 
>>>> methodology?
>>> no, we wont do that. we fixed the cookie behavior in this release 
>>> due to security issues filed against the old parsing.
>>
>> The security issue only exists because of a fundamentally broken 
>> servlet in the examples, and assumes the user will click on a URL. 
>> That's not what I call a security problem.
>
> The root cause of the issue wasn't the servlet in the examples. If it 
> were, that servlet would have been fixed.
>
> The issue was a number of bugs/inconsistencies in the handling of 
> cookie headers, particularly around quoting and unquoting which 
> enabled XSS attacks in some instances. That said the issues were all 
> hard to exploit and required the application to use user provided data 
> directly as the cookie value. This was why these issues were rated as 
> low severity.
>
> An enhancement request to log when Tomcat ignores/truncates a value or 
> identifies some other issue when parsing cookies seems reasonable to me.
I just thought some more on this, the easiest suggestion I would come up 
with would be to have a flag that defaults all cookies to v1.
turning on this flag, will make all values work correctly.

Filip

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