Joscha,
On 1/11/22 09:50, Joscha Cepok wrote:
But there is maybe another approach, during my research I encountered
most time one of two cases:
timestamp; key1=value1; key2=value2;... OR key1=value1;
key2=value2;...;timestamp
I didn't take a deeper look, why browsers add the timestamp to the
cookie header
I've never seen this before. Perhaps you have a plugin that's adding that?
so ignoring the timestamp and log it once seems fine for
me. But in case of multiple broken cookies, maybe all malformed content
of the header should be logged on INFO and not just once?
-1
This makes it trivial for an attacker to fill your disk with INFO logs
by repeatedly providing malformed headers.
I usually
don't like approaches, which distinguish between expected malformed
content and unexpected malformed content, but on the other hand, if
malformed content appears way too often it might be worth to have that
information.
Malformed content is always malformed. The only reason it's being logged
in this situation is because Cookie headers are used for authentication
and if they are broken they can cause applications (or servers) to
appear to be broken when it's really the cookie. It's really a way for
Tomcat to prove to admins that Tomcat isn't at fault.
Regarding my reported possible CVE, that behavior wouldn't have any
impact, since the key-value pair of the cookies was always valid. The
most common and probably only issue was a stand-alone timestamp in the
cookie header, lead the parser to print the entire header.
Note that a user would have to attack themselves. It's not really
feasible to convince another user to break their own HTTP headers.
Or if there is an insider who has access to the logs but not the
application, they can maybe steal cookies and use them to masquerade as
the affected user.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
