kozorizki/haproxy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

DOC: config: Explicitly list relaxing rules for accept-invalid-http-* options

Browse Source 
Time to time, new exceptions are added in the HTTP parsing (most of time H1)
to not reject some invalid messages sent by legacy applications. But the
documentation of accept-invalid-http-request and
accept-invalid-http-response options is not pretty clear. So, now, there is
an explicit list of relaxing rules for both options.

(cherry picked from commit 0f4fad5291027a7dfc8109fbbe2acd0bac8affd0)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This commit is contained in:
Christopher Faulet 2024-09-12 09:15:37 +02:00
parent 9a923de45d
commit 228f104668
1 changed files with 64 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

99
doc/configuration.txt
View File

@ -8697,35 +8697,53 @@ no option accept-invalid-http-request
Arguments : none
By default, HAProxy complies with RFC7230 in terms of message parsing. This
means that invalid characters in header names are not permitted and cause an
error to be returned to the client. This is the desired behavior as such
forbidden characters are essentially used to build attacks exploiting server
weaknesses, and bypass security filtering. Sometimes, a buggy browser or
server will emit invalid header names for whatever reason (configuration,
implementation) and the issue will not be immediately fixed. In such a case,
it is possible to relax HAProxy's header name parser to accept any character
even if that does not make sense, by specifying this option. Similarly, the
list of characters allowed to appear in a URI is well defined by RFC3986, and
chars 0-31, 32 (space), 34 ('"'), 60 ('<'), 62 ('>'), 92 ('\'), 94 ('^'), 96
('`'), 123 ('{'), 124 ('|'), 125 ('}'), 127 (delete) and anything above are
not allowed at all. HAProxy always blocks a number of them (0..32, 127). The
remaining ones are blocked by default unless this option is enabled. This
option also relaxes the test on the HTTP version, it allows HTTP/0.9 requests
to pass through (no version specified), as well as different protocol names
(e.g. RTSP), and multiple digits for both the major and the minor version.
Finally, this option also allows incoming URLs to contain fragment references
('#' after the path).
By default, HAProxy complies with the different HTTP RFCs in terms of message
parsing. This means the message parsing is quite strict and causes an error
to be returned to the client for malformed messages. This is the desired
behavior as such malformed messages are essentially used to build attacks
exploiting server weaknesses, and bypass security filtering. Sometimes, a
buggy browser will not respect these RCFs for whatever reason (configuration,
implementation...) and the issue will not be immediately fixed. In such case,
it is possible to relax HAProxy's parser to accept some invalid requests by
specifying this option. Most of rules concern the H1 parsing for historical
reason. Newer HTTP versions tends to be cleaner and applications follow more
stickly these protocols.
When this option is set, the following rules are observed:
* In H1 only, invalid characters, including NULL character, in header name
will be accepted;
* In H1 only, NULL character in header value will be accepted;
* The list of characters allowed to appear in a URI is well defined by
RFC3986, and chars 0-31, 32 (space), 34 ('"'), 60 ('<'), 62 ('>'), 92
('\'), 94 ('^'), 96 ('`'), 123 ('{'), 124 ('|'), 125 ('}'), 127 (delete)
and anything above are normally not allowed. But here, in H1 only,
HAProxy will only block a number of them (0..32, 127);
* In H1 and H2, URLs containing fragment references ('#' after the path)
will be accepted;
* In H1 only, no check will be performed on the authority for CONNECT
requests;
* In H1 only, no check will be performed against the authority and the Host
header value.
* In H1 only, tests on the HTTP version will be relaxed. It will allow
HTTP/0.9 GET requests to pass through (no version specified), as well as
different protocol names (e.g. RTSP), and multiple digits for both the
major and the minor version.
This option should never be enabled by default as it hides application bugs
and open security breaches. It should only be deployed after a problem has
been confirmed.
When this option is enabled, erroneous header names will still be accepted in
requests, but the complete request will be captured in order to permit later
analysis using the "show errors" request on the UNIX stats socket. Similarly,
requests containing invalid chars in the URI part will be logged. Doing this
also helps confirming that the issue has been solved.
When this option is enabled, invalid but accepted H1 requests will be
captured in order to permit later analysis using the "show errors" request on
the UNIX stats socket.Doing this also helps confirming that the issue has
been solved.
If this option has been enabled in a "defaults" section, it can be disabled
in a specific instance by prepending the "no" keyword before it.
@ -8745,17 +8763,28 @@ no option accept-invalid-http-response
Arguments : none
By default, HAProxy complies with RFC7230 in terms of message parsing. This
means that invalid characters in header names are not permitted and cause an
error to be returned to the client. This is the desired behavior as such
forbidden characters are essentially used to build attacks exploiting server
weaknesses, and bypass security filtering. Sometimes, a buggy browser or
server will emit invalid header names for whatever reason (configuration,
implementation) and the issue will not be immediately fixed. In such a case,
it is possible to relax HAProxy's header name parser to accept any character
even if that does not make sense, by specifying this option. This option also
relaxes the test on the HTTP version format, it allows multiple digits for
both the major and the minor version.
Similarly to "option accept-invalid-http-request", this option may be used to
relax parsing rules of HTTP responses. It should only be enabled for trusted
legacy servers to accept some invalid responses. Most of rules concern the H1
parsing for historical reason. Newer HTTP versions tends to be cleaner and
applications follow more stickly these protocols.
When this option is set, the following rules are observed:
* In H1 only, invalid characters, including NULL character, in header name
will be accepted;
* In H1 only, NULL character in header value will be accepted;
* In H1 only, empty values or several "chunked" value occurrences for
Transfer-Encoding header will be accepted;
* In H1 only, no check will be performed against the authority and the Host
header value.
* In H1 only, tests on the HTTP version will be relaxed. It will allow
different protocol names (e.g. RTSP), and multiple digits for both the
major and the minor version.
This option should never be enabled by default as it hides application bugs
and open security breaches. It should only be deployed after a problem has