BUG/MAJOR: h3: reject header values containing invalid chars
authorWilly Tarreau <w@1wt.eu>
Tue, 8 Aug 2023 15:18:27 +0000 (17:18 +0200)
committerSalvatore Bonaccorso <carnil@debian.org>
Sat, 16 Dec 2023 16:41:30 +0000 (17:41 +0100)
commiteef6a592054249bcb2c0b355dd32bf62e5dfef5b
treef4a59fbb7d27f654c0194e5ee2346fce7473a361
parent7483776e5f464e5dfaebf99e8c40b79a5f09057d
BUG/MAJOR: h3: reject header values containing invalid chars

Origin: https://git.haproxy.org/?p=haproxy-2.6.git;a=commit;h=20a35c4d505475215122d37405ce173075338032

In practice it's exactly the same for h3 as 54f53ef7c ("BUG/MAJOR: h2:
reject header values containing invalid chars") was for h2: we must
make sure never to accept NUL/CR/LF in any header value because this
may be used to construct splitted headers on the backend. Hence we
apply the same solution. Here pseudo-headers, headers and trailers are
checked separately, which explains why we have 3 locations instead of
2 for h2 (+1 for response which we don't have here).

This is marked major for consistency and due to the impact if abused,
but the reality is that at the time of writing, this problem is limited
by the scarcity of the tools which would permit to build such a request
in the first place. But this may change over time.

This must be backported to 2.6. This depends on the following commit
that exposes the filtering function:

    REORG: http: move has_forbidden_char() from h2.c to http.h

(cherry picked from commit d13a80abb7c1badaa42045c37cfff79f24f05726)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 0404bf14c900d6ac879ec432a198435e0741d835)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit f58b63af68f239464c29e698a34f08ff3eef862f)
 [ad: no http/3 trailer support in 2.6]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
Gbp-Pq: Name BUG-MAJOR-h3-reject-header-values-containing-invalid.patch
src/h3.c