Subject: [websec] #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml

From: "websec issue tracker" <[email-masked]>
Date: Sun, 23 Oct 2011 23:52:35 -0000

#21: sniffing of text/html shouldn't override polyglot label of
application/xhtml+xml

 (I have to double check that this is true):

 In general, "sniffing" is dangerous in "polyglot" cases where the same
 content CAN be served with different media types, where the meaning is the
 same or related.

 For example, there are types for packaged formats that use ZIP and thus
 have the ZIP magic number but aren't served as ZIP, text/plain is
 sometimes used to deliver examples of otherwise mal-formed XML, etc.

 It would seem better to discourage sniffing in cases where the content is
 valid for the type that it's actually labeled, and to treat that as a
 special case.

 (One still might want to sniff text/html when the type is labeled
 text/plain, for example, but not for other polyglot cases.)

-- 
------------------------+--------------------------------------------
 Reporter:  masinter@…  |      Owner:  draft-ietf-websec-mime-sniff@…
     Type:  defect      |     Status:  new
 Priority:  major       |  Milestone:
Component:  mime-sniff  |    Version:
 Severity:  -           |   Keywords:
------------------------+--------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/21>
websec <http://tools.ietf.org/websec/>

---

From: Philip Gladstone <[email-masked]>
Date: Mon, 24 Oct 2011 12:23:34 -0400

>   text/plain, for example, but not for other polyglot cases.)
This would be a disaster. For security reasons, a web server needs to 
know when a document will be "executed" rather than "displayed". 
Currently, using text/plain will display any document literally. Causing 
a document that looks like html to be executed will open lots of web 
sites to XSS.

Philip

---

From: Larry Masinter <[email-masked]>
Date: Mon, 24 Oct 2011 09:48:35 -0700

I don't understand, Philip. A central case of this document involves taking documents that look like text/html but are labeled as text/plain and "sniffing" them to be text/html after all.

It's claimed that this is necessary, part of most browsers today, regular practice, etc.

Are you opposed to specifying sniffing from text/plain to text/html? In any case? 

Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Gladstone
Sent: Monday, October 24, 2011 9:24 AM
To: [email-masked]
Subject: Re: [websec] #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml

>   text/plain, for example, but not for other polyglot cases.)
This would be a disaster. For security reasons, a web server needs to know when a document will be "executed" rather than "displayed". 
Currently, using text/plain will display any document literally. Causing a document that looks like html to be executed will open lots of web sites to XSS.

Philip
_______________________________________________
websec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/websec

---

From: Philip Gladstone <[email-masked]>
Date: Mon, 24 Oct 2011 13:15:25 -0400

> Are you opposed to specifying sniffing from text/plain to text/html? In any case?

If the web server explicitly says text/plain, then IMHO it should never 
be sniffed as text/html. Having dealt with security issues where a 
document was returned (without a mime type) and then interpreted as 
text/html, and then enabling a serious XSS, I am attuned to this issue. 
[In my case, this was with a web based ticketing system that allowed the 
submitter of a ticket to upload arbitrary files as supplementary 
information. It turned out that these files were then displayed without 
a content type, and *some* browsers chose to interpret any javascript 
that was embedded. Moving to an explicit text/plain type fixed that 
problem, and these files were displayed literally.]

In the case of sniffing image types when the web server gets it wrong, I 
don't have any experience with what security vulnerabilities that would 
introduce (if any).

Philip

---

From: Adam Barth <[email-masked]>
Date: Mon, 24 Oct 2011 10:18:49 -0700

> I don't understand, Philip. A central case of this document involves taking documents that look like text/html but are labeled as text/plain and "sniffing" them to be text/html after all.

Please read the document.  This does not occur.

> It's claimed that this is necessary, part of most browsers today, regular practice, etc.

That's not factual.

> Are you opposed to specifying sniffing from text/plain to text/html? In any case?

As far as I know, everyone is opposed to that.

Adam