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