Incorrect responses for invalid or multiple content-length

[vladtcvs]

According to RFC7230 3.3.3.4, if we have 2 or more different content-length, for response we must respond 400 to client, and for backend response we must response 502.

Now we have 403 and 500

[vladtcvs]

[vladtcvs]

Tests for this case created as part of #619

[krizhanovsky]

This is also subject for #541, protection against HTTP Request Splitting attack, so please update the Wiki page when the issue is finished. We don't need Frang rules since this is prohibited by the RFC, so the parser must be adjusted instead.

[vladtcvs]

https://tools.ietf.org/html/rfc7230#section-3.3.3

In requests like

Content-Length: 123
Content-Length: 124

,

Content-Length: invalid

,

Content-Length: 123, 124

we must reply 400

In same cases for responses we must reply 502

In cases of equal content length in request

Content-Length: 123
Content-Length: 123

,

Content-Length: 123, 123

we must reject OR merge into 1 header

Content-Length: 123

[vladtcvs]

I think, in case of multiple equal content-length in response, we should also merge them or reject.
I haven't found this in rfc, but it looks like good idea

[vladtcvs]

also i think we should remove content-length header in case of chunked body

[vankoven]

we should also merge them or reject. I haven't found this in rfc, but it looks like good idea

You're absolutely right:
RFC 7230 3.3.2

If a message is received that has multiple Content-Length header
fields with field-values consisting of the same decimal value, or a
single Content-Length header field with a field value containing a
list of identical decimal values (e.g., "Content-Length: 42, 42"),
indicating that duplicate Content-Length header fields have been
generated or combined by an upstream message processor, then the
recipient MUST either reject the message as invalid or replace the
duplicated field-values with a single valid Content-Length field
containing that decimal value prior to determining the message body
length or forwarding the message.

[vladtcvs]

I've misunderstood "If a message is received" as request message. It looks that case of response is also related here

[vankoven]

also i think we should remove content-length header in case of chunked body

Yes, we must do that. RFC 7230 3.3.3 point 3:

If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to
perform request smuggling (Section 9.5) or response splitting
(Section 9.4) and ought to be handled as an error. A sender MUST
remove the received Content-Length field prior to forwarding such
a message downstream.

[aleksostapenko]

All specified above cases are already handled in Tempesta FW code, according the most strict scenario described in RFC: all HTTP messages with misused Content-Length headers (multiple headers, multiple values, usage with Transfer-Encoding header) are rejected.