W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

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

From: Adrien de Croy <adrien@qbik.com>
Date: Tue, 07 Apr 2009 09:45:13 +1200
Message-ID: <49DA77E9.5070204@qbik.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:02 GMT