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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
