The default bug view has changed. See this FAQ.

Disable cross-site loading of XSLT stylesheets by default

RESOLVED FIXED in mozilla1.3alpha



15 years ago
3 years ago


(Reporter: Heikki Toivonen (remove -bugzilla when emailing directly), Assigned: peterv)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:mustfix])


(2 attachments)

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.
Isn't the problem that could try to load a stylesheet from and thereby discover some information that should be secret?
Whiteboard: [sg:mustfix]
Yes, that is also possible, but I think less likely to divulge important
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?
Peter, can you fix this for 1.3a? The freeze is next Tuesday.
i can try to come up with a patch

Comment 6

15 years ago
Created attachment 107848 [details] [diff] [review]


15 years ago
Attachment #107848 - Flags: superreview?(heikki)
Attachment #107848 - Flags: review?(bugmail)


15 years ago
Priority: -- → P1
Target Milestone: --- → mozilla1.3alpha
Comment on attachment 107848 [details] [diff] [review]

>     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
Attachment #107848 - Flags: review?(bugmail) → review+
Attachment #107848 - Flags: superreview?(heikki) → superreview+

Comment 8

15 years ago
Checked in.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 9

14 years ago
mass verifying
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.
Keywords: verifyme
Resolution: FIXED → ---
Back to resolved, pending verification.
Last Resolved: 15 years ago14 years ago
Resolution: --- → FIXED
Group: security

Comment 13

13 years ago
Created attachment 160130 [details]
A simple XML and XSL Java WAR file for deployment into a Java App Server to illustrate that this bug is incorrectly fixed


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
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

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

----- 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

----- Start of Request Headers -----
host = localhost:8080
user-agent = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
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   -----
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.