W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: p1: additional security considerations

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 23 Apr 2013 08:15:06 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <20130423061506.GB8496@1wt.eu>
On Tue, Apr 23, 2013 at 04:02:22PM +1000, Mark Nottingham wrote:
> Just wondering if we need to explicitly point out the security considerations
> around the following:
> * Message routing -- it's somewhat common AIUI for intermediaries to only
> route on the Host header, for performance reasons; i.e., they do not
> reconstruct the effective request URI (as required by p1 5.5). I know there's
> a theoretical risk here, but is there a real-world risk that we should point
> out?

I see no particular risk since the Host header field is mandatory. Also in
practice, intermediaries which "route" requests tend to be very close to
the servers, at places where the security considerations are very specific
to the environment and explicitly covered in this intermediary's configuration.

Maybe we should point one thing though, which is not related to intermediaries
but all recipients in general : recipients of a request message which consider
the Host header field to decide about what content to serve must ensure of its
unicity before serving the request. Otherwise the risk is that an intermediary
could use a first instance to route the request and that a server would use the
last one for example.

> * Message delimitation - the consequences for getting message delimitation
> wrong (whether it's regarding multiple content-length headers, processing 1xx
> responses correctly, etc.) are now well-understood. Should we point it out
> explicitly in SC?

Yes I think that's important to add something about this, especially since
I discovered a few weeks ago a "security" product which was able to "fix"
badly chunked data ! It was quite scary to imagine that an improperly chunked
content which could possibly contain whatever is needed to embed different
contents could be converted to whatever this component considered valid by
skipping undesired data before chunk lengths and recomposing new valid ones!
It looks like some developers don't understand the security implications of
their choices.

Received on Tuesday, 23 April 2013 06:15:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC