Hi guys,
On Thu, Oct 02, 2014 at 01:52:41PM +0100, JCM wrote:
> 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.
Yes you're right, that's it. These are control chars (0..31, 127) or
spaces being delimiters to the protocol itself (32) so there's no way
to cleanly recover from these chars, except by opening wide gaping holes.
> 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.
Yes, since "%" is 0x25 (37), it can be accepted by the option above,
so if you have it, "%20" written like this will pass through (at your
own risk, of course).
> > 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.
That's my guess as well.
> 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.
By the way, haproxy tries to display the original version in its logs,
unless the request contains non-printable chars or chars which will
corrupt the log format, in which case it prefixes them with "#" (which
is uncommon enough in requests that it's not a problem to have it here).
Best regards,
Willy
