On 2 October 2014 00:49, Diana Hsu (ditsai) <[email protected]> wrote:
> Hi,
>
> I would like to validate a statement in "option accept-invalid-http-request"
> section:
> http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20accept-invalid-http-request
>
> By default, HAProxy complies with RFC2616 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 behaviour 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.
>
> What does it mean by "HAProxy always blocks a number of them (0..32, 127)."?
> Does it mean HAProxy will not block the request with invalid char (0..32,
> 127) in the header name all the time? Does HAProxy randomly block the bad
> request with invalid char (0..32, 127) in the header name?
I can't speak from a position of knowledge, but I would imagine that
if *unescaped* ascii chars 0,1,2,-32 and 127 are observed, HAProxy
always blocks the request.
I can quite imagine that *escaped* strings like "%20" are permitted,
either in HAProxy's permissive "accept-invalid-http-request" mode or
its default stricter mode.
> We have an application receiving "Bad Request 400" and the tcpdump shows an
> invalid char %20 (space) in some of the header names.
> However, application owner claimed sometimes these requests were not blocked
> by HAProxy and went through without "Bad Request 400" error.
I would suspect that the permitted requests have "%20", and the
dropped requests have a literal space (" ") in the header names. Those
permitted requests might then be causing the origin server / backend
to blow up, however.
Remember that only tcpdump will /definitely/ show you the truth: many
different applications will display/log/etc the unescaped string,
despite transmitting/having-received the escaped version.
That's my 2 cents, anyway :-)
Cheers,
Jonathan
PS Please send plain text email to the list, not HTML!
