- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 23 Apr 2013 16:17:22 +1000
- To: Willy Tarreau <w@1wt.eu>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 23/04/2013, at 4:15 PM, Willy Tarreau <w@1wt.eu> 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/
Received on Tuesday, 23 April 2013 06:17:48 UTC