CVE-2023-45539: Ambiguity about how to deal with received fragments in URI from Willy Tarreau on 2023-07-27 ([email protected] from July to September 2023)

Hello,

An haproxy user rightfully reported that we don’t ignore the fragments in the URIs we receive. While that’s historically true and comes back from the old days where any byte from one side would be passed to the other side, I’m facing a dilemma about how to best deal with it.

Indeed, RFC9110 is pretty clear about the fact that URIs do not contain the fragment component, and even refers to RFC3986 that omits it for scheme-based absolute URIs. But as often, this only concerns senders and does not suggest much about how to proceed on the receiver when that rule is violated. I could be tempted to say that if a fragment is present, the the rule is violated and I should just reject the request as bad with a

400. I tried various web servers (among which Apache and NGINX) and all silently trim any received fragment, which leaves me with even more doubt about the suitability of the 400 here…

We could also consider that we continue to accept it and just trim it from the functions that extract it for internal processing, but that would mean we’d continue to pass it to the server, which is contrary to the rules imposed to a client (even though we’re a gateway here, but still we try hard to comply as much as possible and sometimes to repair damaged protocol elements if needed and permitted).

We could also completely trim this one when receiving the request, and probably match more closely what the few servers I’ve tested seem to do, but given that we’re not supposed to receive them, I’m wondering if we’re not hiding the dust under the carpet. It will also mean that they wouldn’t appear in logs anymore, preventing from observing them.

Thus I’d like to collect some opinions here from other implementers. Are there any who reject requests containing fragments in the URI ? If not, are there any good reasons for not doing so (e.g. clients caught sending them from time to time in the past and situation nor re-evaluated since; lack of clarity in older versions of the spec, etc) ?

Without strong support for rejecting these as invalid, I’m probably going to silently fix these requests by trimming the fragment like others seem to do, but I really do not like doing such things that hide interoperability issues without a good reason first. We already have normalization rules in place to either reject or trim, but they’re currently opt-in so we can’t count on that to collect more feedback.

Thanks in advance, Willy

Received on Thursday, 27 July 2023 09:05:14 UTC