Re: Questions about draft-abarth-mime-sniff-00

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
> <> 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 uses a PHP script to retrieve
> user avatars from its database:
> 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:
> 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 -

Received on Monday, 6 April 2009 21:42:55 UTC