- From: Adrien de Croy <adrien@qbik.com>
- Date: Tue, 07 Apr 2009 09:45:13 +1200
- To: Adam Barth <w3c@adambarth.com>
- CC: Lisa Dusseault <lisa.dusseault@messagingarchitects.com>, HTTP Working Group <ietf-http-wg@w3.org>
Is it safe for all browsers to use the same algorithm here? From a purely biological view, having no diversity leads to increased risk. Adam Barth wrote: > Hi Lisa, > > On Mon, Apr 6, 2009 at 9:35 AM, Lisa Dusseault > <lisa.dusseault@messagingarchitects.com> wrote: > >> 1. Doesn't the threat model of mime sniffing need to assume that some >> servers are malicious? the last paragraph of section 1 implies that without >> server cooperation, which implies trusting the server, the sniffing >> procedure can lead to security problems. >> > > In most cases, when the server is malicious, the server can simply > specify whatever type it likes in the Content-Type header and doesn't > need to leverage the browser's content sniffing algorithm. That said, > there is a corner case where it's important to think about a malicious > server: when someone (say a proxy or a firewall) is making a decision > based on the media type of HTTP responses. For example, a firewall > might wish to block all images (for whatever reason) and then might be > sad when an HTTP response is sniffing as an image. > > There isn't really a way to tweak the content sniffing algorithm to > mitigate these issues. Instead, we win here by having every user > agent that performs sniffing use the same algorithm. That way, > vendors of proxies and firewalls can take sniffing into account (if > they choose) when deciding which responses to block or transform. > > >> 2. "Extensions must not be used for determining resource types for >> resources fetched over HTTP." why is this a needed requirement? And should >> there be an exception for IETF Standards Track extensions that offer more >> information on resource types? >> > > This requirement is not strictly necessary, but using the extension to > sniff is problematic from a security point of view because the > extension can often be chosen by an attacker. For example, by > default, PHP let's the attacker choose an arbitrary extension. In > particular, suppose that example.com uses a PHP script to retrieve > user avatars from its database: > > http://example.com/avatar.php?UID=3843 > > By default, this server will also respond with the same content (which > might be controlled by the attacker) when the user's browser requests > this URL: > > http://example.com/avatar.php/foo.html?UID=3843 > > If we take the extension into account, we're more likely to be tricked > into sniffing "incorrectly." > > Can you give an example of something you think ought to be an > exception to this requirement? > > >> 3. Having a fixed table of types with patterns to look for, doesn't fully >> address why we will always have content sniffing: new content types are >> created that servers don't recognize, but a client could be updated to >> recognize. Should the table simply be a starter set and clients can extend >> at will? Or is there reason (and a reasonable way) to create an IANA >> registry for new patterns/types? >> > > Which types browsers sniff for has been fairly stable for a reasonable > period of time. I haven't studied historical sniffing algorithms in > detail, but I believe image/png was the most recent type added to > widely used algorithms. In my view, content sniffing is most useful > for interoperating with existing Web content. It might be worth > having a registry for new types, but I'd expect we'd only add a new > type on the order of every 5-10 years. > > >> 4. Are there any best-practice guidelines for working with users? E.g. >> allowing a user to choose "text/html" for unmarked content might be a >> security hazard. We don't want specific user interface requirements, but >> this document seems like a good place to extend security considerations to >> getting input from users, if there are such guidelines. >> > > As far as I know, none of the major implementations of content > sniffing provide user overrides. This is in contrast to charset > detection, where most major implementations let the user override. (I > believe this is because charsets are a huge mess in Asia.) I think it > makes sense to discuss this in the draft. I'll add it to the next > version. > > Adam > > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Monday, 6 April 2009 21:42:55 UTC