Subject: Re: [websec] mimesniff feedback, part 2

From: Larry Masinter <[email-masked]>
Date: Sun, 8 Jan 2012 07:49:31 -0800

I've started on editing the sniffing document in earnest. 

Foolishly, I started going through it from the beginning.  Here's a take at the Abstract to make the scope clearer:

      <t>HTTP provides a way of labeling content with its
      Content-Type, an indication of the file format / language by
      which the content is to be interpreted.  Unfortunately, many web
      servers, as deployed, supply incorrect Content-Type header
      fields with their HTTP responses.  In order to be compatible
      with these servers, web clients would consider the content of
      HTTP responses as well as the Content-Type header fields when
      determining how the content was interpreted (the "effective
      media type").  Looking at content to determine its type (aka
      "sniffing") is also used when no Content-Type header is
      supplied.  Overly ambitious sniffing has resulted in a number of
      security issues in the past.  This document specifies methods
      and options for computing an effective media type, in a way that
      addresses both security and compatibility considerations.
      It also discusses the use of sniffing in contexts other than
      delivery of content via HTTP.
      </t>

I wanted to address the scope by making it clear that the scope of the document included sniffing outside of content delivered via HTTP.

*** Shouldn't sniffed content have a different origin than the content as labeled?  The only "privilege upgrade" that I've come across seem to be cross-origin ones. 

*** Is sniffing used by servers when clients use file-upload? Doe web servers do sniffing on content to decide what media type to label the content with? Or is sniffing really only scoped  to apply to web browsers?

    <section anchor="intro" title="Introduction">

      <t>HTTP provides a way of labeling content with its
      Content-Type, as an indication of the file format / language by
      which the content is to be interpreted.  Unfortunately, many web
      servers, as deployed, supply incorrect Content-Type header
      fields with their HTTP responses.  In order to be compatible
      with these servers, web clients would consider the content of
      HTTP responses as well as the Content-Type header fields when
      determining how the content was interpreted (the "effective
      media type").  Looking at content to determine its type (aka
      "sniffing") is also used when no Content-Type header is
      supplied.</t>

I tried to introduce "effective media type" as it was used before defined.

Where is the term "privilege escalation", as used in this document, defined?

http://en.wikipedia.org/wiki/Privilege_escalation

defines the term in general, and then at the end mentions a couple of examples under

===============begin Wikipedia quote ===========================
"Examples of horizontal privilege escalation"

This problem often occurs in web applications. Consider the following example:
User A has access to his/her bank account in an Internet Banking application.
User B has access to his/her bank account in the same Internet Banking application.
The vulnerability occurs when User A is able to access User B's bank account by performing some sort of malicious activity.
This malicious activity may be possible due to common web application weaknesses or vulnerabilities.
Potential web application vulnerabilities or situations that may lead to this condition include:
* Predictable session ID's in the user's HTTP cookie
* Session fixation
* Cross-site Scripting
* Easily guessable passwords
* Theft or hijacking of session cookies
* Keystroke logging
===============end Wikipedia quote ==========================

But there are no mentions there of sniffing is a source of privilege escalation.

 Surely since this is the main use case the specification is intended to mitigate, shouldn't it be described somewhere? 

The examples given in passing in the document seem to be XSS attacks (which would be mitigated merely by giving sniffed content a different unique origin, wouldn't it?) 

The  abstract implies there might be other attacks too...  are there? what are they?

Larry
--
http://larry.masinter.net

---

From: Adam Barth <[email-masked]>
Date: Sun, 8 Jan 2012 12:45:51 -0800

> *** Shouldn't sniffed content have a different origin than the content as labeled?  The only "privilege upgrade" that I've come across seem to be cross-origin ones.

Nope.  Browsers would not be able to implement that because it would
break too many web sites.

> *** Is sniffing used by servers when clients use file-upload? Doe web servers do sniffing on content to decide what media type to label the content with? Or is sniffing really only scoped  to apply…

That seems out of scope for this document.  This is a document for user agents.

> But there are no mentions there of sniffing is a source of privilege escalation.

Sure, but just because the wikipedia article for privilege escalation
doesn't call out sniffing an example doesn't mean that it isn't an
example.

>  Surely since this is the main use case the specification is intended to mitigate, shouldn't it be described somewhere?

It's just a general term of art.  If you like, we can add a reference
to Section 3.3 of RFC 6454.

> The examples given in passing in the document seem to be XSS attacks (which would be mitigated merely by giving sniffed content a different unique origin, wouldn't it?)

Not in all case, but that's not going to happen, so it's somewhat irrelevant.

> The  abstract implies there might be other attacks too...  are there? what are they?

There are other attacks, but XSS is the most important one.  I'd
rather the reader focused on XSS because that's easiest to understand.

Adam

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 09 Jan 2012 04:43:31 +0000

<hat="individual">

On 08/01/12 20:45, Adam Barth wrote:
> On Sun, Jan 8, 2012 at 7:49 AM, Larry Masinter<[email-masked]>  wrote:
Well, just to be clear, I would imagine that there might be "user 
agents" running as a server process and doing sniffing on uploaded 
content. (e.g. Imagine a user uploading a document and specifying the 
content-type incorrectly or not at all).
If any server would do some sniffing, it would be very likely that they 
will employ the same rule-set (algorithm?) and/or re-use the existing 
client libraries for sniffing.
And actually, personally I would even strongly recommend to use the same 
rules, as this would at least avoid inconsistent (and unexpected) results.

> doesn't call out sniffing an example doesn't mean that it isn't an
Well, for Wiki: it does not claim completeness, so we just correct/amend 
the Wiki article.

> rather the reader focused on XSS because that's easiest to understand.

Agree with Adam's recommendation on this. Currently XSS is the most 
prevalent risk for that.
So it seems ok to focus on that. The existing example cases should be 
sufficient to illustrate the problem and principle.

> Adam

Best regards, Tobias