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

On 6-Apr-09, at 12:57 PM, 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.

That makes more sense now.  It might be nice to specifically mention  
that the threat model assumes that the server can lie about Content- 
Type anyway, and in the security considerations warn that a server  
might trick clients into handling one content type as another if the  
client isn't careful.

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

I now think we mean something completely different by "extension".  I  
had assumed "protocol extension", i.e. a specification that extends  
HTTP, but now I see you mean "file name extension".

Thanks,
Lisa

--- Scanned by M+ Guardian Messaging Firewall ---
Messaging Architects sponsors The Spamhaus Project.

Received on Monday, 6 April 2009 20:07:57 UTC