Open Bug 245463 Opened 20 years ago Updated 2 years ago

Rich error report for stylesheets not loaded due to security

Categories

(Core :: XSLT, enhancement)

Product:
Core
Component:
XSLT
Platform:
x86
Windows XP
Type:
enhancement

Tracking

()

People

(Reporter: dontneedyouraccount, Assigned: peterv)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040526 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040526 Firefox/0.8.0+

Stylesheet at remote URL (http://www.gzegzolka.com/cvx.xsl) used by local XML
file is not loading. Relative local URLs works fine.
You can download "example.xml" at http://www.gzegzolka.com/example.xml (works
fine online) and test it on your local drive.

Reproducible: Always
Steps to Reproduce:
1. Save "http://www.gzegzolka.com/example.xml" locally
2. Open local copy of "example.xml" in Firefox

Actual Results:  
I see untransformed content.

Expected Results:  
Show transformed content.
That is the expected behaviour, we do not allow cross site XSLT (which is the
same as file <-> web) for security reasons.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
(In reply to comment #1)
> That is the expected behaviour, we do not allow cross site XSLT (which is the
> same as file <-> web) for security reasons.

I don't think it's good not to allow sth "for security reasons". You may add
option to allow cross site XSLT.

It's great way to update a lot of world-wide-spread files by replacing XSL file
on the web server. This time I prefer MSIE behaviour.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
a lot of unsecure things are usefull, and a lot of things in IE are unsecure.
Neither of these properties makes them less unsecure.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → INVALID
I'm still think it's bug.

Why? Because it doesn't work. I don't see any error message, I see untransformed
content without any information WHY it's untransformed.

And I still think there should be a way to allow cross site XSLT.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
I think prefs to allow for unsecure features are in general frowned upon. Why
should we include a feature that we recommend everyone to not turn on? Even if
it is usefull for your application, you would expose all your users to a
security risk.

I agree though it could be argued that we need some sort of errorreporting. At
least we should put a warning in the console.
Severity: major → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: keith → core.xslt
Summary: Stylesheet at remote URL used by local XML file is not loading → Rich error report for stylesheets not loaded due to security
I think best solution is Yes/No message box with `don't ask again` checkbox.
I don't want to see any more comments sounding like "security is an option".
period.
(In reply to comment #7)
> I don't want to see any more comments sounding like "security is an option".
> period.

So, don't turn your computer on. It's most secure, also for your eyes etc...

;-)
Could someone clarify something for me:  are the security rules with regard to
the loading of XSLT documents different from (or the same as) those that govern
the location of CSS documents?

If they are different (more strict), then why?

What are the dangerous actions that the XSLT could perform that the CSS could
 not?  The only thing that comes to mind would be an infinitely recursive XSLT
 document, but mozilla would be vulnerable to that even if it came from the 
same server as the xml document.

It seems to me that a common application for client-side XSLT would be where 
the xml documents are generated dynamically from an application server, and
where the xslt document is referenced from a static content server.  To my 
mind that makes this restriction seem a bit severe.
(In reply to comment #9)
> Could someone clarify something for me:  are the security rules with regard to
> the loading of XSLT documents different from (or the same as) those that
> govern the location of CSS documents?
> 
> If they are different (more strict), then why?

Yes they are more strict. IIRC we decided this because XSLT can create scripts.
With css it's relativly harmless to link to some random sites css file. However
if you link to some random persons XSLT stylesheet that person could modify the
stylesheet and then perform a cross-site script attack on your website.

So this is not so much to protect the user as to protect the web-author.

Though i'm not super convinced that this is needed. After all, we do support
linking to .js files on random servers. Though there it is much more obvious
that you should trust the site you're linking to.
> Though i'm not super convinced that this is needed. After all, we 
> do support linking to .js files on random servers. 

I'd like to see XSLT follow the same policy.  Mozilla's current policy
is killing my opportunity to use client-side XSLT for a real project.
Why can't you just place a copy of the stylesheet that you want to use on the
same server as your xml?

We don't want to lower security without a very good usecase. There are still
risks with allowing fetching data from other severs. Basically we'd allow an
xml-file that potentially contains sensitive data to be loaded from other
servers which could be located inside a firewall or password protected site.
The only thing that'd stop us from loading just any xml file is that the file
has to have an xsl:version attribute on the top level element to be a valid
stylesheet.
The app server that produces the xml serves only dynamic content.

The xslt is static content, and should reside on the static content
server.  (The app server's thread pool for handling http requests
should not be bothered with this task, in my opinion.)

The production installation happens to have a proxy that sits in front
of both, so mozilla would work fine there.

The killer is that setting up this special configuration on each developer
seat just to accomodate this weakly-justified security policy in one
browser is a hard one to sell.

They'll just end up using IE, and no doubt make us dependent upon its quirks.

I agree that we can jump through hoops to make this work.  I just think that
anything that encourages developers to use IE should give pause.  Mozilla
shouldn't bleed mindshare without a very good, specific reason.  (Which I
think we're still waiting on.)
Well, a very good reason is that allowing loading an XSLT from an arbitary
server means that we allow loading XML data from arbitary servers, which would
be a very big security problem. Such security issues has made headlines in the past.
The only difference here would be that the data has to have a certain attribute
set, but I'm far from convinced that that is enough.

Possibly we could leverage the security model that webservices use. I don't know
the details of it but basically a server is able to flag that it's allowed to
connect to it from anywhere and that it doesn't contain sensitive information.
(In reply to comment #14)
> Well, a very good reason is that allowing loading an XSLT from an arbitary
> server means that we allow loading XML data from arbitary servers, which would
> be a very big security problem. Such security issues has made headlines in the
past.

Exactly - loading cross domain XML files is a no-no.

> The only difference here would be that the data has to have a certain attribute
> set, but I'm far from convinced that that is enough.
> 
> Possibly we could leverage the security model that webservices use. I don't know
> the details of it but basically a server is able to flag that it's allowed to
> connect to it from anywhere and that it doesn't contain sensitive information.

The model is described in
http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/New_Security_Model.html

I guess we could consider the model for XSLT, but what we really need is to
standardize it for doing cross domain XML loading.

I still think XSLT stylesheets are most useful when they are loaded from one
server. I'm using many XML files on different machines and they all require the
same XSLT stylesheet... Sometimes this stylesheet changes, how to replace it
automatically on many different machines?
PS. ...this security model makes Mozilla XSLT useless for me.
Summary: Rich error report for stylesheets not loaded due to security → Rich error report for stylesheets not loaded due to "security ;-)"
Please stop spamming and doing useless changes.
Summary: Rich error report for stylesheets not loaded due to "security ;-)" → Rich error report for stylesheets not loaded due to security
Yeah, standardizing it for all XML seems like a good way to go. We could even
hook it up in the nsExpatDriver which'll make it really apply to all xml. Though
a more logical place would probably be the sinks, though unfortunatly that would
mean codeduplication.
>  Exactly - loading cross domain XML files is a no-no.

Is 'domain' here defined as in the standard DNS sense, or is there some
other meaning?

The reason that I ask is that I'm mostly interested in being able to fetch
my transform from a different machine in the same domain.  (Or even from
the same IP address but a different port!)
Domain is, iirc, defined as compleate DNS name. I.e. not just 'foo.com' but
'www.sub.foo.com'. And a different port is also considered a different domain,
i.e. 'www.foo.com' is different from 'www.foo.com:8081'
(In reply to comment #15)
> (In reply to comment #14)
> > Well, a very good reason is that allowing loading an XSLT from an arbitary
> > server means that we allow loading XML data from arbitary servers, which would
> > be a very big security problem. Such security issues has made headlines in the
> past.
> 
> Exactly - loading cross domain XML files is a no-no.

Why? I really can't figure it out. Firefox can load script files from evil.com quite happily, so why not load xsl files that can only really load more documents, or format things, or insert scripts (which we can already load anyway).

Also, if an XML file has a style-sheet and fail to find it, or is not authorized to get it, it should really display as if it had no style sheet, and pop down the yellow "this page try to.... ". A completely empty page and a notice in an error log that no one reads is not really helpful.

bug 394708, which I found first, seems to be a dup of this, really.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.