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