165532 - Disable cross-site loading of XSLT stylesheets by default

Status: RESOLVED FIXED

(Core :: XSLT, defect, P1)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

IE does not allow cross-site loading of XSLT stylesheets, apparently because of
security reasons. It seems like we should follow suit.

We have limited external stylesheet loading so that the external stylesheet can
only load external resources from the site where the stylesheet resides. Also
the original author must have trusted that stylesheet provider at least
initially. It is possible that the author did not realize that the XSLT could be
malicious (it is a stylesheet, what bad can it do?). Also if the stylesheet
provider is hacked the original author may not become aware of that.

It should be possible to override this by using trusted sites/domains (for
example it seems safe to download stylesheets from W3C), see bug 165531 for how
this could be implemented.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Isn't the problem that badguys.com could try to load a stylesheet from
yourintranet.com and thereby discover some information that should be secret?

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Yes, that is also possible, but I think less likely to divulge important
information.

Comment 3

[Mitchell Stoltz (not reading bugmail)]

We'd like to get this fixed by Mozilla 1.3 so that people don't start depending
on cross-site loading of stylesheets. Peter, can you do this?

Comment 4

[Mitchell Stoltz (not reading bugmail)]

Peter, can you fix this for 1.3a? The freeze is next Tuesday.

Comment 5

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

i can try to come up with a patch

Comment 6

[Peter Van der Beken [:peterv]]

Attachment: v1

Comment 7

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

Comment on attachment 107848 [details] [diff] [review]
v1

>+
>     rv = secMan->CheckLoadURI(mDocumentURL, url,
>                               nsIScriptSecurityManager::ALLOW_CHROME);
>-    if (NS_FAILED(rv))
>-      return NS_OK;
>-    rv = LoadXSLStyleSheet(url);
>-  } else if (aType.Equals(NS_LITERAL_STRING("text/css"))) {
>+    NS_ENSURE_SUCCESS(rv, rv);
>+
>+    rv = secMan->CheckSameOriginURI(mDocumentURL, url);
>+    NS_ENSURE_SUCCESS(rv, rv);

We should probably not return an error-code since that might stop the parsing,
which we IMHO shouldn't do. NS_ENSURE_SUCCESS(rv, NS_OK) would be ok with me
since the warning could be good to have for debugging.

With that, r=sicking

Comment 8

[Peter Van der Beken [:peterv]]

Checked in.

Comment 9

[Axel Hecht]

mass verifying

Comment 10

[Christopher Aillon (sabbatical, not receiving bugmail)]

Re-opening to clear the verified flag.  Pike, can you (or someone) actually
verify this?  I don't like to see rubber stamp verification for security bugs.

Comment 11

[Christopher Aillon (sabbatical, not receiving bugmail)]

Back to resolved, pending verification.

Comment 12

[Christopher Aillon (sabbatical, not receiving bugmail)]

Opening.

Comment 13

[Mark McNamee]

Attachment: A simple XML and XSL Java WAR file for deployment into a Java App Server to illustrate that this bug is incorrectly fixed

Hi,

IMHO this "bug" should be reopened and resolved properly, or at the very least,
allow hard-disk based XML files (that you have potentially saved from a web
server) to connect back to a web server in order to obtain their associated XSL
file. I am an avid fan of the Mozilla project and all that it stands for; but
am amazed to see a bug beginning with words such as "IE does not allow
cross-site loading of XSLT stylesheets, apparently because of security reasons.
It seems like we should follow suit."; IE does make a request to a remote XSL
file if the XML you are viewing is stored on your local file system! (I have
not tried true Cross-site loading)

IE actually has another (more serious) bug in the MSXML engine (the DDL which
processes XSLT within IE), whereby it ignores the user's language preferences,
and does not bother sending ANY "accept-language" header. See the examples I
have included for more info.

I have included a few sample snippets of XML, XSL and JSP to illustrate my
point, and allow replication of the problem I wish to outline.

Imagine the following scenario:

 -  An XML data file is generated as part of a batch process and emailed to a
customer. (Hundreds of thousands of these files are sent out at a time, and the
customer needs to store a copy, hence they are not generated "on the fly" by
the web server itself!)
 -  The XML contains pure data, so no internationalisation is required here
 -  The email recipient opens the XML file, which has a stylesheet processing
instruction in the header referencing an XSL file back on the server(s) which
sent the file. (This XSL file is actually a JSP, so it can be internationalised
and have some other useful logic in it)
 -  The email recipient's system web browser (the plan is to support IE and all
mozilla variants) opens the XML file, and requests the XSL from the web server.
The web server inspects the "accept-language" header from the browser and
internationalises the "display and formatting" content in the XSL, allowing the
browser to render the XML file as HTML, localised for the user's native
language
 
In order to get mozilla to recognise the XSL file correctly, you will need to
ensure the web server sets the content-type as "text/xml" or more preferably,
"text/xml; charset=UTF-8". If you deploy the WAR file I have attached into
Tomcat or JBoss, this should work out of the box.

May I recommend one possible solution until security domains are implemented
within Mozilla? A popup that asks the user "This XML file is attempting to
connect to {URL} to obtain a stylesheet to display this document, do you wish
to allow this?" (Yes/No). This would at least allow the user to make the choice
of what happens next, rather than the current behaviour which is to strip all
the tag information off and display unformatted text, which I personally think
is highly undesireable!

Other interesting things to try with IE:
Deploy the WAR and check http://localhost:8080/xsl/msxml/msxml4-example.html.
The Javascript call "window.navigator.browserLanguage" also appears to be
broken in Internet Explorer, as I have setup my browser in French, and regional
settings are still UK, and this field is still initialised to "en_US"!!

If any further information is required, please do not hesitate to ask me as I
would really like to get this issue resolved in my favourite browser!

Below is the request headers for 2 identical requests, one from IE and one from
Mozilla.

The following is the debug output from the XSL JSP file. It simply iterates
over the Request Headers and prints them out to the log

--------------------------------------------------------------------------------

Internet Explorer 6 calling http://localhost:8080/xsl/verysimple.xml, output
is the result of the request for http://localhost:8080/xsl/verysimple.xsl
--------------------------------------------------------------------------------

request.getLocale=en_GB
----- Start of Request Headers -----
accept = */*
accept-encoding = gzip, deflate
user-agent = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
host = localhost:8080
connection = Keep-Alive
----- End of Request Headers   -----


--------------------------------------------------------------------------------

Mozilla 1.7.3 opening http://localhost:8080/xsl/verysimple.xml, output
is the result of the request for http://localhost:8080/xsl/verysimple.xsl
--------------------------------------------------------------------------------

request.getLocale=fr
----- Start of Request Headers -----
host = localhost:8080
user-agent = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20040910
accept = text/xml,application/xml,application/xhtml+xml,*/*;q=0.1
accept-language = fr,en;q=0.5
accept-encoding = gzip,deflate
accept-charset = ISO-8859-1,utf-8;q=0.7,*;q=0.7
keep-alive = 300
connection = keep-alive
referer = http://localhost:8080/xsl/verysimple.xml
cache-control = max-age=0
----- End of Request Headers   -----

Comment 14

[Tracy Walker [:tracy]]

mass remove verifyme requests greater than 4 months old