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

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

Received on Monday, 6 April 2009 19:58:05 UTC