Re: ACTION-308 (part 2) Updates to 'The Self-Describing Web'

John Kemp wrote:
>
> On Jan 5, 2010, at 9:33 PM, Eric J. Bowman wrote:
> 
> > Is ACTION-308 saying that the common implementation of XSLT on the
> > Web is wrong, and that all the major browsers are broken?
> 
> ACTION-308 basically says only that we should revise [SDW] and
> [AuthMeta] to acknowledge the fact that content sniffing occurs and
> that if you have to sniff you should do so in a secure and accepted
> manner.
> 

I understand that.  The background I can find on the issue is limited
to discussion of the text/plain type as an example.  I was wondering if
the ramifications of this finding on text/xml were considered.  I agree
with Sam:

http://lists.w3.org/Archives/Public/public-html/2008Jul/0041.html

Except my examples that have broken over time used text/xml, because I
expected that only IE would sniff for an xml-stylesheet PI to execute.
I see that as sniffing, unless the media type is application/xml.

> 
> I believe that the IETF content sniffing draft [BarthSniff] says that
> both sniffed text/html and sniffed text/xml are scriptable and thus
> there should be no privilege escalation between text/xml and
> text/html (they would be considered the same from a security
> perspective).
>

How confident are we that this is correct?  The only reference I can
find to the scriptability of text/xml is RFC 3023:

"
If an XML document -- that is, the unprocessed, source XML document --
is readable by casual users, text/xml is preferable to application/xml.
MIME user agents (and web user agents) that do not have explicit
support for text/xml will treat it as text/plain, for example, by
displaying the XML MIME entity as plain text. Application/xml is
preferable when the XML MIME entity is unreadable by casual users.
"

I'm just a guy who had gotten used to using text/xml for files I
intended to be opened in an editor, or displayed raw.  Without xml-
stylesheet PIs, IE displays text/xml as a collapsible tree.  Other
browsers used to just treat all elements as unknown in-line, while
others displayed it as plain text.  Aside from one aberrant browser, no
user-agent would ever have reason to start executing scripts.  Or so I
thought, anyway.

I had gotten used to using application/{*+}xml when I actually did want
user-agents to process the content, instead of displaying it somehow
(with the default being plain text).  Until recently, the Web had worked
this way for a long time, which reinforced my interpretation of RFC 3023
as saying that text/xml isn't scriptable, if you need to execute scripts
for the user, go with application/xml.

Now, browsers all execute XML PIs served as text/xml, when my intent
with my server was that they be displayed instead of executed (like
plain text, or in my case opened in an XML editing environment).  Have I
been running my server wrong, by not considering text/xml and text/html
the same from a security perspective?  I'd been given no reason to
think I was wrong by browsers (except the one I always assume to be
wrong on issues of standardization), until recently.

>
> I'd also note that the authoritative type and sniffed
> type seem to agree in the case you mention - the transformation is
> executed by the browser after it has received the content if I
> understand your case correctly?
> 

It depends on user-agent.  Some browsers compile XSLT, so in the case
of a first request, the transformation is executed after the content is
received.  Subsequent requests for the same .xsl are cache hits, so the
text/xml representation pipes through the compiled transformation as
soon as the browser encounters the XML PI.

I see what you're saying, though.  My thinking was that the sniffed
type was text/html due to the <html> root element in the .xsl file, not
the authoritative text/xml from the Content-Type header.  What I do not
expect to see when I dereference a text/xml URL with a browser, is an
HTML page where tables, forms, links and Javascript work.

HTML doesn't list text/xml as an allowed media type.  The text/xml
media type says nothing about processing tables, forms, links or
javascript DOM bindings.  Surely the browser has shifted from text/xml
to text/html.  I was seeing a privilege escalation because I'd never
read anything to lead me to believe text/xml was scriptable.

>
> > 
> > If this is so, does serving the .xml document as application/xml
> > suffer the same fate?  Consider:
> > 
> > http://www.w3.org/TR/MathML2/overview.xml
> > 
> > Not that they're using Javascript, but there's no reason it wouldn't
> > work if they did.  Is the TAG saying that HTML content must be
> > served with an HTML media type?
> 
> If HTML content is served over the Web (between an HTTP client and
> server, say) then are advantages described in [AuthMeta] and [SDW] to
> using authoritative metadata to correctly label the content sent
> "over the wire" between the server and the client. Once the client
> has that content however, it may certainly perform additional work on
> it, such as transforming it from one content type to another. The TAG
> findings do not, I believe, govern such transformations, executed
> only after content has been acquired and recognized.
> 

I use application/xhtml+xml (with xml-stylesheet PI to call XSLT) or
text/html (with Javascript to call XSLT) as media types, when I'm
ultimately providing an XHTML interface to the user.  Because the root
element of my XSLT output is <html>.  The [AuthMeta] note in particular
seems to govern such transformations:

"
Similarly, XInclude [XInclude] processing has the implied consent of
the user to transform data from one source to another and thus should
only result in errors when the transformation is unsuccessful. Note,
however, that this functionality imposes a social burden on XInclude
processors to be sure that the resulting composed document does not
violate the user's security constraints.
"

Which I read to mean that XSLT processing has the implied consent of
the user, unless it results in a privilege escalation.  The idea that
text/xml can be safely processed as text/html seems as wrong to me as
it does with the text/plain examples given, because I'd never expected
text/plain *or* text/xml to start running Javascript.

-Eric

>
> Regards,
> 
> - johnk
> 
> [AuthMeta] http://www.w3.org/2001/tag/doc/mime-respect.html
> [SDW] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
> [BarthSniff] http://tools.ietf.org/html/draft-abarth-mime-sniff-03
> 
> > 
> > -Eric
> > 
> > John Kemp wrote:
> >> 
> >> Hello,
> >> 
> >> As the second part of ACTION-308, I propose the following updates
> >> to 'The Self-Describing Web' finding [SelfDescWeb], to acknowledge
> >> the reality of content-type sniffing. I shall now mark ACTION-308
> >> to be 'pending review'.
> >> 
> >> Regards,
> >> 
> >> - johnk
> >> 
> >> [SelfDescWeb] -
> >> http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
> >> [ACTION-308] - http://www.w3.org/2001/tag/group/track/actions/308
> >> [F2FMinutesSep2009] -
> >> http://www.w3.org/2001/tag/2009/09/24-minutes#item03
> >> 
> >> (begin proposed changes)
> >> 
> >> 1.
> >> 
> >> Section 1: Introduction
> >> 
> >> After bullet point:
> >> 
> >> Each representation should include standard machine-readable
> >> indications, such as HTTP Content-type headers, XML encoding
> >> declarations, etc., of the standards and conventions used to encode
> >> it. 
> >> 
> >> Add:
> >> 
> >> ... and every effort should be made to ensure that the intentions
> >> of the content author and publisher regarding interpretation of the
> >> content are accurately conveyed in such indications.
> >> 
> >> 2.
> >> 
> >> Section 2: The Web's Standard Retrieval Algorithm
> >> 
> >> After paragraph:
> >> 
> >> Consider instead a different example, in which Bob clicks on a link
> >> to ftp://example.com/todaysnews. Although Bob's browser can easily
> >> open an FTP connection to retrieve a file, there is no way for the
> >> browser to reliably determine the nature of the information
> >> received. Even if the URI were ftp://example.com/todaysnews.html
> >> the browser would be guessing if it assumed that the file's
> >> contents were HTML, since no normative specification ensures that
> >> data from ftp URIs ending in .html is in any particular format. 
> >> 
> >> Add:
> >> 
> >> As noted above, and for other reasons (such as content
> >> aggregation), it may not be possible for a browser to reliably
> >> determine, via inspection of a Content-Type HTTP header or other
> >> external metadata alone, the intended interpretation of Web
> >> content. In such cases, a browser may inspect the content directly
> >> (commonly known as "sniffing"). The consequences of such an action
> >> are described in [AuthoritativeMetadata]. In particular, sniffing
> >> Web content should only be done using an accepted and secure
> >> algorithm, such as [BarthSniff].
> >> 
> >> 3.
> >> 
> >> References:
> >> 
> >> Add:
> >> 
> >> [BarthSniff] http://tools.ietf.org/html/draft-abarth-mime-sniff-03
> > 
>

Received on Friday, 8 January 2010 00:38:46 UTC