Re: p1: additional security considerations

[Mark Nottingham <[e-mail]>]

On 23/04/2013, at 4:15 PM, Willy Tarreau <[e-mail]> wrote:

> 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.

That's what I was wondering. What concerned me was that people deploy load balancers in front of proxies, and virus scanners, etc. I don't have a specific attack in mind, it just feels like there probably is one.


> 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.
> 
> Cheers,
> Willy
> 

--
Mark Nottingham   http://www.mnot.net/