228698 - Style sheet not processed if file is local and style sheet is remote

Status: RESOLVED INVALID

(Core :: XSLT, defect)

Description

[Hugo Haas]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

In an XML document with an xml-stylesheet PI, the document is processed and
styled in the following cases:
- the XML document is local (i.e. with a file:// URL) and the XSLT style sheet
is local.
- the XML document is remote (i.e. with an http:// URL).

If the document is local and the style sheet is remote, then the document is
styled by only showing text nodes.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Axel Hecht]

This is one of the many incarnations of the "same site policy", which we apply to
XSLT stylesheets.
It's verboten for security reasons.

Comment 2

[Richard Brodie]

*** Bug 252322 has been marked as a duplicate of this bug. ***

Comment 3

[Martin von Gagern]

Why should a remote XSLT be more harmful than a remote JavaScript? Loading an
external JavaScript from a local HTML page works perfectly well. I think there
should be some kind of unified handling for different kinds of external
resources, including XSLT stylesheets. I just created bug #299682 to address
this issue.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The difference is that xslt files can (almost) be just general XML files which
means that they can contain security sensitive information. We don't allow
cross-site loading of html documents for the same reason.

In theory JS files can contain security sensitive information too, but we can't
change the JS-file policy without breaking lots and lots of sites. So hopefully
most sites should protected against js files being loaded (by not putting
security sensitive information in js files, or by checking referrer). 

Comment 5

[Martin von Gagern]

Let me see if I get this straight. Someone might have put sensitive information
in an xslt, and restricted access to some trusted hosts. So if there were no
restrictions, someone else from an untrusted network could reference this xslt
in some malicious page, and thus gain some sensitive information from the xslt.
Is this the scenario you have in mind? How does this apply to a local xml? In
this case some malicious attacker would additionally have to trick some user
into saving and opening some specially crafted xml.

Maybe I missed something, but I believe this scenario to be rather far fetched:
1. sensitive information in xslt unlikely, this is not the purpose of xslt
2. attacker would have to guess url of sensitive xslt and some part of contents
3. sensitive information not password protected is administrators fault
4. user should never save and open any documents from an unknown source

On the other hand, it would be great if you could edit some xml locally and view
it the way it would be displayed on the web, without downloading the xslt,
cluttering your directories, rewriting the processing instructions, and all this
mess.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Again, note that any XML file is basically a valid XSLT stylesheet. See
http://www.w3.org/TR/xslt#result-element-stylesheet

The attack senario is:
1. Someone creates an XML file containing sensitive information.
2. This XML file is placed on a corporate network inside a firewall.
3. Someone inside that firewall browses to an evil site.
4. The evil site reads the XML file by referensing it as an XSLT stylesheet.
5. The contents of the XML file is sent back to the evil site.

2 can be replaced with putting the file on a password protected internet site.
Once you have logged into a site you won't be prompted for password again so
password protection does not help.

So with this you can bypass password protection or firewalls by just getting a
user to go to your site. And by allowing files to be read from file:// any site
could read files right off your harddrive as long as you can guess the location.
And remember, you can try as many times as you wish.


We are working on a solution for this, but it is not as easy as you make it out
to be.

Comment 7

[bugzilla]

(In reply to comment #6)
> Again, note that any XML file is basically a valid XSLT stylesheet. See
> http://www.w3.org/TR/xslt#result-element-stylesheet

The recommendation states: "A literal result element that is the document element of a stylesheet must have an xsl:version attribute, which indicates the version of XSLT that the stylesheet requires."

i.e. XML files without with an xsl:version attribute on the document element (and the associated xmlns declaration) are NOT valid XSLT stylesheets.

> The attack senario is:
> 1. Someone creates an XML file containing sensitive information.

Without an xsl:version attrib, the sensitive XML file would not be a valid XSLT stylesheet, see above.

> 2. This XML file is placed on a corporate network inside a firewall.
> 3. Someone inside that firewall browses to an evil site.
> 4. The evil site reads the XML file by referensing it as an XSLT stylesheet.
> 5. The contents of the XML file is sent back to the evil site.

Assuming that the sensitive XML file is indeed a valid stylesheet, surely what happens is that the browser retrieves the evil page and the "sensitive stylesheet", fires up the XSLT processor, tries to apply the stylesheet to the evil page and displays the result to the user (i.e. the "victim" behind the firewall). As far as I can see, neither the sensitive stylesheet, nor the output of the xslt processor get sent to the evil site.

Thus, unless I've missed something, the attack described won't work.

I suggest the bug be reopened.