Quantcast

Tomcat 8.5.4 and LegacyCookieProcessor

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Tomcat 8.5.4 and LegacyCookieProcessor

Jared Walker
Hello,

We are migrating to the version of tomcat identified in the subject
and during our testing we ran into an issue with an external automated
client used to submit specialized requests to your web application.
It was failing to connect because it was submitting cookies with
version set to 0.

I have read through the documentation and found that configuring the
legacy processor does resolve this issue.

Now, I know this is only a work around as the "spec" being used by
this client is ancient.  We are considering using the legacy parser as
a stop-gap measure until we can update the external clients with a new
version.

My groups concern however is two fold:

1. What are the security and compatibility concerns when using the
legacy processor
2. The header for LegacyCookieProcesor.java explicitly states: "This
class is not thread-safe."

Can someone here with background knowledge explain exactly whats not
thread-safe about the processor?  Does this mean you cannot use it for
multiple simultaneous requests (pretty hindering for a server) or does
this mean that you cannot have multiple threads parse the cookie
contents of a request in parallel (which isn't a very normal thing to
do)?

Any advice would be appreciated.

Thanks,
-Jared

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Tomcat 8.5.4 and LegacyCookieProcessor

Caldarale, Charles R
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Jared Walker
> Subject: Tomcat 8.5.4 and LegacyCookieProcessor

> We are migrating to the version of tomcat identified in the subject

Before exposing an almost year-old version to the nasty real world, you might want to look at this:
        http://tomcat.apache.org/security-8.html
and then pick a newer level (hint: 8.5.15 would be good).

> 1. What are the security and compatibility concerns when using the
> legacy processor

Sorry, can't answer that one.

> 2. The header for LegacyCookieProcesor.java explicitly states: "This
> class is not thread-safe."

> Can someone here with background knowledge explain exactly whats not
> thread-safe about the processor?  Does this mean you cannot use it for
> multiple simultaneous requests (pretty hindering for a server) or does
> this mean that you cannot have multiple threads parse the cookie
> contents of a request in parallel (which isn't a very normal thing to
> do)?

It's neither, really; there is one instance of CookieProcessor per <Context>, and the fields within LegacyCookieProcessor that make it not thread-safe are only set (in Tomcat) when the <Context> is initialized.  Were you to dynamically reset the fields while requests were in progress, you could get in trouble.  The fields are described here:

http://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 8.5.4 and LegacyCookieProcessor

markt
On 18/05/2017 19:12, Caldarale, Charles R wrote:
>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Jared Walker
>> Subject: Tomcat 8.5.4 and LegacyCookieProcessor
>
>> We are migrating to the version of tomcat identified in the subject
>
> Before exposing an almost year-old version to the nasty real world, you might want to look at this:
>          http://tomcat.apache.org/security-8.html
> and then pick a newer level (hint: 8.5.15 would be good).

Plus that version includes a fix for the problem the OP is seeing:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60627


>> 1. What are the security and compatibility concerns when using the
>> legacy processor
>
> Sorry, can't answer that one.

Security concerns - none known (if there were we'd have fixed them)

Compatibility - tends to play better with older browsers. Lots of config
options to handle various edge cases.

Mark

>
>> 2. The header for LegacyCookieProcesor.java explicitly states: "This
>> class is not thread-safe."
>
>> Can someone here with background knowledge explain exactly whats not
>> thread-safe about the processor?  Does this mean you cannot use it for
>> multiple simultaneous requests (pretty hindering for a server) or does
>> this mean that you cannot have multiple threads parse the cookie
>> contents of a request in parallel (which isn't a very normal thing to
>> do)?
>
> It's neither, really; there is one instance of CookieProcessor per <Context>, and the fields within LegacyCookieProcessor that make it not thread-safe are only set (in Tomcat) when the <Context> is initialized.  Were you to dynamically reset the fields while requests were in progress, you could get in trouble.  The fields are described here:
>
> http://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html
>
>   - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tomcat 8.5.4 and LegacyCookieProcessor

Christopher Schultz-2
In reply to this post by Jared Walker
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jared,

On 5/18/17 1:24 PM, Jared Walker wrote:
> Now, I know this is only a work around as the "spec" being used by
> this client is ancient.  We are considering using the legacy parser
> as a stop-gap measure until we can update the external clients with
> a new version.

Others have answered your core question, but I have another point to
add: you can fix these clients by changing your application slightly.

Modify your application to re-write your cookie values with a value
that does not require any spec-ambiguous decoding. Specifically, use
something like base64 encoding so your cookie value is always clean.

If a client sends you a cookie value that is not in the "new" format,
re-issue the cookie value to them with the new format. Issue all new
cookies in the new format (of course).

They it doesn't matter whether or not the clients are properly
spec-compliant.

> 2. The header for LegacyCookieProcesor.java explicitly states:
> "This class is not thread-safe."

That is a note to direct consumers of the class. Tomcat's use of this
class is safe (it would be a pretty bad bug if it were not used in a
safe way).

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkfBVkACgkQHPApP6U8
pFhLmw/9Eh04el3+EiDtpaO1gMwpfdo8E0FJ8eA0A0Jz03rgfQpCNRtvFJOAVcaw
8sg1g+WFYgi5fASv48fVk3p6Bccm7GRNTfXayYh/n9KCaW4nJdhnB9qVDSRubhps
K/sLG7Jc4+x6tHmBa4V2c6/70whb89nWnmKBxXZ27pO6Bbn1Vd3bj2uVJCRyzS2/
MGlimUpyeXCYHcZMly7VoKJSEdyh8FWevuBZq2L16LvWs6ncVQxkfgNUm4TmxE5o
ZvSxy0ThlBtJxYPi0evozVmaqBhzEE9mX/ARqR/qSU0jnka8M1MH2VjtFCLjCQ1A
kj5NKqiNIVoyJypDpdk3DSoHZT29wpSULbem0pna/VsFZE9qEwT7FkPt30MpWAls
qCcFAI+o+g3tV5Hv1dPGxnHmvH/iXmxC5HkYSlI4igaQ56eSOeFd4NKd3p7UPC1q
mR+N+DqjJDDjSXTufebB33bdKbBOVjpq+fc67BQgqXP1fJFuK355lPUpNvmTCUY2
2xiC9cUSuqKx1h1RM3KwOmfDw/g4hUnyLYjabyhoLSr5tIPCIKeVwTTuMd6SvGaY
SqDjsex397u5UxdXWj3aIbCPmQXHCB9tFPAk6eHLZpj9y7pDQoeLWhkzRG+slhzE
M5vTS9xYM+xXB3Nvh2cswQQVs7F5KV+yiAVEhvJNnmTpLroiuhY=
=EA0s
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...