Re: Bare CR in header fields

[Willy Tarreau <[e-mail]>]

Hi Cory,

On Wed, Jan 20, 2021 at 09:06:16PM +0000, Cory Benfield wrote:
> In particular, I'll note that Roy said, a year and a half ago, "If
> some browsers interpret CR as a line delimiter in HTTP protocol fields
> (other than payload content), they have security holes that should be
> fixed." Is that the position of this working group?

To be honest, that was my immediate thinking when I've read your scary
story about browsers taking them as field terminators! It indeed means
that it's likely possible to send them such responses and expect some
content smuggling over persistent connections:

   HTTP/1.1 200 OK
   Content-length: 10000
   X-foo: blah\rTransfer-encoding: chunked

   0\r\n
   HTTP/1.1 200 OK
   Content-length: 9900
   
   This is the content non-compliant clients will take as the response
   for the second request.

This could for example be used to inject malicious code bypassing client-side
anti-malware solutions, so it should not be taken lightly.

> Who is
> coordinating with these implementations to address that security hole?

That's unclear, as I think that all major implementations were represented
when this spec was written. However it's certain that it's not always trivial
for an implementation to spot issues that affect them in so detailed a spec.
It's also possible that some of these decided to still support that behavior
for various reasons and to apply special safety belts (e.g. no cache, no
persistent connections, no cookies etc).

Maybe the simplest would be to open a bug report in each of them's issue
tracker. Even if they decide to close it, the justfication will remain
there and accessible to anyone, should new threats pop up.

Just my two cents,
Willy