Subject: HTTP/2: Another reason to find a safer encoding

From: Willy Tarreau <[email-masked]>
Date: Tue, 31 Jul 2012 19:36:55 +0200

Hi,

Ivan Ristic recently presented a wide collection of methods to bypass
web application firewalls using implementation differences in HTTP
stacks :

   https://community.qualys.com/blogs/securitylabs/2012/07/25/protocol-level-evasion-of-web-application-firewalls

While some of them have already been discussed to great extents, including
here, I think it's worth a read and reminds us that we really need to
address the ambiguities of request encoding if we want to make the web
safer.

Regards,
Willy

---

From: James M Snell <[email-masked]>
Date: Tue, 31 Jul 2012 14:56:01 -0700

Definitely a fascinating read and I can certainly relate to many of the
issues discussed. Reliable parsing within existing HTTP headers and the
request URI can be a significant source of pain. Encoding issues and
inconsistency between header definitions just makes matters that much
worse. Unfortunately, despite the significant security concern that such
issues represent (issues that I would argue are as significant, or in some
cases more significant than the question of mandatory TLS support) it would
be next to impossible to fix (or at least improve-upon) these various
issues without making significant modifications to existing HTTP/1.1
semantics. I'd very much like to see such changes made within 2.0, but I'm
afraid that I may be in the minority.

- James

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 31 Jul 2012 15:08:35 -0700

See http://xkcd.com/327/

In the Omnibroker spec I created a new type 'Label' as a subclass of
string that is designed to help avoid this type of issue.

A Label can contain any UNICODE character except for ASCII characters
other than 0-9, a-z, A-Z, -, _.

The reason for this particular choice is that it excludes all the
control characters used in pretty much every widely used scripting
language.

This does not provide a complete protection against injection attacks,
but the data types most commonly subject to injection attacks are
things like usernames, indexes, labels and such.

On Tue, Jul 31, 2012 at 2:56 PM, James M Snell <[email-masked]> wrote:
> inconsistency between header definitions just makes matters that much worse.
> Unfortunately, despite the significant security concern that such issues
> represent (issues that I would argue are as significant, or in some cases
> more significant than the question of mandatory TLS support) it would be
> next to impossible to fix (or at least improve-upon) these various issues
> without making significant modifications to existing HTTP/1.1 semantics. I'd
> very much like to see such changes made within 2.0, but I'm afraid that I
> may be in the minority.
>
> - James
>

-- 
Website: http://hallambaker.com/

---

From: Zhong Yu <[email-masked]>
Date: Tue, 31 Jul 2012 19:24:12 -0500

> address the ambiguities of request encoding if we want to make the web

What do you have in mind?

The problem is that implementations tend to be liberal in accepting
inputs. That is mostly due to laziness - being strict is harder. As
long as an input can be mapped to an acceptable value, no harm is done
to the internal state, therefore there's no incentive for
implementations to reject illegal inputs. This is the reality, no
matter how sternly the spec emphasizes the MUST NOTs.

Zhong Yu

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Aug 2012 07:43:22 +0200

> matter how sternly the spec emphasizes the MUST NOTs.

This is not the only issue, it's very hard to be strict on things that
are not well defined. For instance, we had a hard time trying to find
what to do with multiple content-lengths. Some implementers had to
perform some tests to see how much breakage they would cause by becoming
stricter. Header field folding is a big issue too. I suspect that many
implementation do not consider that a request might contain two Host
header fields, simply because this is not supposed to be possible nor to
make sense at all. Similarly, "Connection: content-length" or equivalent
border-line things are not the problem of the implementation, but of the
spec. The spec has grown to a huge size because we tried to address that
many issues. But still you cannot document all corner cases because they
are invented every day and implementations cannot guess them all because
it's not their job.

So my point precisely is to try to enforce a stronger typing of exchanged
data to avoid a number of these issues as much as possible. For instance,
by using an integer to represent a date, you cannot send "29 Feb 2013",
and you don't need implementations to verify that this date makes any sense.

Regards,
Willy