Cookie "expires" recent format change vs. Apache HTTP client 4.x

[Pawel Veselov <pa...@gmail.com>]

Hello.

Ran into an interesting problem yesterday. After updating Tomcat to
9.0.69 to mitigate a disclosed CVE, some of our tests started failing.

Investigation uncovered that the HTTP client stopped accepting
"set-cookie" headers because of "expires" attribute values.

There was a change to the format of the "expires" cookie attribute, to
replace dashes with spaces between date/month/year :
https://github.com/apache/tomcat/commit/d641a43b8a1a0a09862e101c304d2874b0771c6e

Interestingly, RFC-6265, section 5.1.1 allows for these delimiters
between any of the date components: %x09 / %x20-2F / %x3B-40 / %x5B-60
/ %x7B-7E
So, dash (0x2d), was a legitimate delimiter.

Apache HTTP client 4.x, however, by default, applies "default" cookie
policy, which has a JavaDoc description of:

> This policy provides a higher degree of compatibility with common cookie
> management of popular HTTP agents for non-standard (Netscape style) cookies.

However, what happens in reality, is that if the cookie has "expires"
attribute, it's always treated as a "Netspace" cookie, which has the
only supported date format of EEE, dd-MMM-yy HH:mm:ss z, see sources
of org.apache.http.impl.cookie.DefaultCookieSpec (I have a gnawing
feeling I'm missing something here, because format wants 2-digit year,
and Tomcat was sending 4 digits. But the outcome is the same - if the
date has spaces between the date components, cookies are not accepted,
with the "default" cookie policy).

It seems that cookie parsing is rather haphazard in the Apache HTTP client.

I'm sure this change is breaking things on the client sides here and
there, as a result, and I haven't seen any topics on this in the list,
so thought somebody might find this useful.

SUMMARY:
Changing something THAT old was bound to create problems for some
clients, I'm not sure how useful this change was in general. Even if
the change remains compliant to the relevant specs.

Thank you,
  Pawel.

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

Re: Cookie "expires" recent format change vs. Apache HTTP client 4.x

[Mark Thomas <ma...@apache.org>]

On 04/01/2023 13:23, Pawel Veselov wrote:
> Hello.
> 
> Ran into an interesting problem yesterday. After updating Tomcat to
> 9.0.69 to mitigate a disclosed CVE, some of our tests started failing.
> 
> Investigation uncovered that the HTTP client stopped accepting
> "set-cookie" headers because of "expires" attribute values.
> 
> There was a change to the format of the "expires" cookie attribute, to
> replace dashes with spaces between date/month/year :
> https://github.com/apache/tomcat/commit/d641a43b8a1a0a09862e101c304d2874b0771c6e
> 
> Interestingly, RFC-6265, section 5.1.1 allows for these delimiters
> between any of the date components: %x09 / %x20-2F / %x3B-40 / %x5B-60
> / %x7B-7E
> So, dash (0x2d), was a legitimate delimiter.

You are confusing client requirements with the server requirements. The 
server requirements are set out in section 4 and require that spaces are 
used.

RFC 6265 is deliberately stricter for servers than for clients. The 
idea, as I understand it, is that, over time, servers will better follow 
the specs so clients can be less lenient.

> Apache HTTP client 4.x, however, by default, applies "default" cookie
> policy, which has a JavaDoc description of:
> 
>> This policy provides a higher degree of compatibility with common cookie
>> management of popular HTTP agents for non-standard (Netscape style) cookies.
> 
> However, what happens in reality, is that if the cookie has "expires"
> attribute, it's always treated as a "Netspace" cookie, which has the
> only supported date format of EEE, dd-MMM-yy HH:mm:ss z, see sources
> of org.apache.http.impl.cookie.DefaultCookieSpec (I have a gnawing
> feeling I'm missing something here, because format wants 2-digit year,
> and Tomcat was sending 4 digits. But the outcome is the same - if the
> date has spaces between the date components, cookies are not accepted,
> with the "default" cookie policy).
> 
> It seems that cookie parsing is rather haphazard in the Apache HTTP client.

This isn't the first time I have seen a report to that effect. I'll note 
that the current home page for for the 4.5.x client states that it aims 
to support RFC 6265 so this looks like an HTTP client bug (although it 
would be worth checking the latest 4.5.x release first).

> I'm sure this change is breaking things on the client sides here and
> there, as a result, and I haven't seen any topics on this in the list,
> so thought somebody might find this useful.
> 
> SUMMARY:
> Changing something THAT old was bound to create problems for some
> clients, I'm not sure how useful this change was in general. Even if
> the change remains compliant to the relevant specs.

Changing anything cookie related frequently flags up issues. In this 
instance, Tomcat (arguably) had no choice. The default cookie processor 
in 9.0.x is Rfc6265CookieProcessor and this was a clear violation of RFC 
6265. The change should have been completely transparent (and would have 
been for any RFC 6265 compliant client).

The Servlet 4.0 spec also references RFC 6265 although there have been 
various issues with the spec and/or TCK continuing to also reference 
older cookie specs that should be fully cleaned up for Servlet 6.1 
(Tomcat 11).

Mark

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