User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092802 SeaMonkey/2.0a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092802 SeaMonkey/2.0a1pre XML file using XSLT transformation doesn't work any more. Reproducible: Always Steps to Reproduce: 1.Open an xml file 2. 3. Actual Results: text view of the file ... Expected Results: HTML view

When the xslt is in the same directory transformation works. such as such as :<?xml-stylesheet href="s2000m_descript.xsl" type="text/xsl"?> so the example i join is working ... if you declare an xslt in an other directory the problem began . such as :<?xml-stylesheet href="../styles/s2000m_descript.xsl" type="text/xsl"?>

any messages in the error console? (tools|error console)

yes : security error Security Error: Content at file:///C:/193386/atservices/S2000M-xml/data_modules/DMC-S2000MA00000000A010AA_000.xml may not load data from file:///C:/193386/atservices/S2000M-xml/styles/s2000m_descript.xsl.

yeah, I think this is intentional

If you're developing locally then you can lower your protection against rogue file: urls by changing the pref "security.fileuri.origin_policy" to 3 for traditional handling. If this is something you're distributing on CD intended to be read using file: URIs then you need to put the XSLT in the same directory. Currently a subdirectory will also work. This change in handling file: uris was due to bug 230606. The effect on XSLT is perhaps an unwanted side-effect and we should special-case the SameOrigin check there.

The thing is that linking to some random HTML file as an XSLT can allow effectively reading that file, as I recall. ccing XSLT folks to confirm.

I don't think XSLT deserves special attention here really. If we're restricting access in the local file-system for fear of inappropriate data being stolen, then those restrictions should apply to XSLT too IMHO.

I learn, a long time ago, that a good rule to website developper was to put all files non readable for an user on a directory upper the webserver root directory. These new security rule, is to me, against the state of the art rules saying a common css/xlst/scripts or what ever for a website. Or we have to develop on flat manner, all the filse in the same directory. This will become quickly unmangeable... To be able to manage security problems, perhaps do we need some new standard way of coding or encoding ...

Firefox has no way to know you're using file: to develop a web server vs. someone abusing file: to steal someone else's data. The overwhelming number of Mozilla users are not developing websites and the default security settings need to be tuned for them. You can: a) run a server on localhost for development (apache is free and easy; bonus: your development environment will act like a web server whereas in many little ways file uris do not). b) change the security pref locally to get the original behavior. You are the intended audience for that pref, otherwise we would have simply changed the behavior.

The change security preference seems not documented and not reachable via tools menu. The pref security.fileuri.origin_policy does'nt existe with a default value in the file security-prefs.js. I add pref("security.fileuri.origin_policy",3); at the end an effectively the things come back as usual. Thanks for your time.

Do we have a developer-extension? If so we should make it add UI for this pref. I think it's fine that the default install doesn't have such UI as normal users should not be messing around with it.

This pref is not appropriate for the general user UI, it's a developer pref. It's available through the about:config interface. It's not in security-prefs.js (which is for the crypto library), the default is in the basic all.js. You shouldn't be adding a default value to those files, you should set a user pref value through about:config

ok, so it's the intention of firefox developers. why this bug isn't marked closed nor resolved? i am afraid that people will go on reporting this 'bug'. is there a way to tell the user, that it is intentional?

> why this bug isn't marked closed nor resolved? Because the current setup for file:// is not yet finalized.

Not saying we should actually fix this by setting blocking flag to +, but we need to get an answer to this question by the time we ship. +'ing and setting P3.

Closing this one as we have multiple other bugs on if the new file-policy is sound (see the blocking list for bug 230606). Whatever we deem the same-origin policy should look like, it should apply to XSLT.

I publish on a unix server and no xslt transformation is done even if the files xslt and xml are in the same directory. Is it again volonteer ? Shall I understand that xml transformation using xslt is avoid or not recommended ?

> I publish on a unix server and no xslt transformation is done even if the files > xslt and xml are in the same directory. Then you're not seeing this bug. Please file your issue as a separate bug and make sure to include a link to your page. Feel free to cc me on this new bug.

Addtional info about this bug: I get this error: XML Parsing Error: Location: file:///D:/docs/my/stuff/site/mySite/contents/more/content/more/xml/file.xml Line Number 2, Column 1:<?xml-stylesheet type="text/xsl" href="../../../../styles/style.xsl"?> ^ The browser cannot find/parse the stile sheet, when it is located in another subfolder of the root folder or in any other case when the XSLT file is not located in the same folder as the XML file. This bug occurs when the files are stored locally. This workes in IE and Firefox 2

> I add pref("security.fileuri.origin_policy",3); at the end an effectively the > things come back as usual. I set the pref to false and it now works. But how should I make my offline xml only site if other less knowledgeable people should view it? At least why doesn't Firefox show an advice what the problem might be? It looks as if there is a browser or xslt bug!

No, sounds like everything is working as designed. The error console reports the security load error, I would presume...

I would be tempted to see the same behaviour as applied to certificates here, where the user can flag an exception. If there were a way to sign these files or limit the functionality without removing it completely.

When working with local files, both text/xml by Page Info, the XSL transformation fails to occur. The XML file leads with: <?xml version = "1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="../Site.xsl.xml"?> The XSL file leads with: <?xml version="1.0" encoding="utf-8"?> <!--========================================================================--> <!-- XSL html template for Site output files (10) --> <!--========================================================================--> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" XSL transformations from the web seem to operate correctly. Comment #19 (Formerly on bug 406530 )

"Andre-John Mas 2008-05-23 19:23:24 PDT I would be tempted to see the same behaviour as applied to certificates here, where the user can flag an exception. If there were a way to sign these files or limit the functionality without removing it completely." ----> That's a good suggestion!

Guys, this issue is not users vs. developers. For instance, in our company the users access documentation on the shared file system, the doc is organized in (sub)directories, takes form of XML and the XML uses xml-stylesheet processing instruction to reference common library of XSLT stylesheets. Furthermore, the stylesheets include other stylesheets to get common functionality (also in parent directory), and the resulting HTML links JS, CSS, whatever... in parent directory relative to the XML. To Comment #7: No, the exploit you suggest would not work. Yes, the browser loads a resource referenced by xml-stylesheet PI, but there is no way to access the data or otherwise exploit it (please, somebody provide a use case if I am wrong). The only way you could access the data is to use a stylesheet with the document() function inside, but that is IMHO another story. I think, the XSLT specific solution could look like this: doc/stylesheet/common.xsl doc/stylesheet/root.xsl doc/stylesheet/specific/specific.xsl doc/stylesheet/specific/specific.js doc/category1/cat.xml (cat.xml references root.xsl using PI. root.xsl includes specific.xsl, which includes common functionality from common.xsl) - cat.xml should be able to reference any local stylesheet using xml-stylesheet PI (for instance root.xsl). - specific.xsl should be able to include/import any local stylesheet (for instance common.xsl) - references in the transformation result (css, javascript) should obey the same-origin policy, but in the way, as if the reference has been made from stylesheet referenced from PI (in this case root.xsl) - XSLT document() function should obey the XSLT engine policy

The way I see it is that if your XSL, or Javascript, writes to disk, tries network or memory communication or tries accessing a Java library, for example, then it should be blocked and the user should have to give permission. Anything that is considered safe should be allowed. Basically we should be using a sandbox approach, like Java does for applets or webstart, in order to decide what can be run safely, and in what context, and what needs special user permissions.

Just to be sure, the case I posted in Comment #30, and the "solution" I proposed are specific for files on file system (file:// protocol).

In Bug 439238 I attached an interesting example: When opening a file in the main-directory which links to the file using the XSL-Stylesheet from inside a subdirectory the stylesheet actually *is* loaded (Firefox 3 RC 2) (I thought i was attaching the file before the bug was marked as a Duplicate).

Yes. You can link to things that are below you in the directory tree, but not to things that are above you.

Well, I'm sorry, but that sounds like ****... I'm an ubuntu-linux user, and if someone is interested in any data from my hard-drive it's probably *not* /etc/passwd but something like ~/.kde/share/apps/kwallet/kdewallet.kwl (my keyring) or ~/.gnupg/secring.gpg (my secret key). These are all subdirectories, not parent directories. So if *someone* get's me to download a malicious file, I'll probably store it where I store everything that I download, be it a download via HTTP, BitTorrent or a FileTransfer via Jabber. So please correct me if I'm wrong, but that way all my data could be retrieved easily (which I doubt cause show me how to extract databy using <?xsl-stylesheet?>). Therefore that whole thing is pointless (at least on unix-like systems). Can't Firefox just ask for it? A simple popup like "This page wants to load additional data from your hard-drive" and a List showing what's gonna be loaded [Allow] [Disallow].

They're subdirectories of your home directory, yes. Which means you shouldn't be putting any downloads in your home directory, ever. Have a separate directory for them. That's been the recommended practice for a while now, and when OSes provide a default download location it's often not the home directory. We would have made the child dir thing not work too, but that breaks all HTML manuals and the like, which was just too much of a problem. :( > Can't Firefox just ask for it? Users don't read security dialogs; they just select a random option. Statistically speaking, of course; a very small percentage do read. So asking actually decreases security, on average.

I've been reading the duplicate bugs (one if which I submitted myself) and it sounds like the programmers aren't going to budge on this issue. The only workaround for those of us who need it is provided in comment 22 on this bug (https://bugzilla.mozilla.org/show_bug.cgi?id=397894#c22). It would really be appreciated, though, if something about this were included in the Release Notes when FF3 goes live tomorrow (2008-06-17), if I have the date right).

"Users don't read security dialogs; they just select a random option. Statistically speaking, of course; a very small percentage do read. So asking actually decreases security, on average." Sorry, but that is a BS argument. It is the user's fault if they do not read the security dialog. Why do you want to punish everybody to prevent a few morons from potentially allowing a security hole? What would happen if Windows start blocking all .exe files because some of them could be dangerous? This is basically the same thing. One example where this truly is going to screw me and many I know over is that I am a modder for phpBB3 and we use xml files for the mod instructions. We are going to get hundreds or thousands of people asking why none of the .xml files work in the contrib or upgrades directory. Also, if you think about it, just having a global setting will open up many more problems then having a dialog box with the 1 time option. Many people will need to set it to always allow xsl files from different directories and then all of them will always have this "security hole" open. If you plan on blocking accessing xsl files from different directories at the _very_ least it should show a message saying why the file is blocked and how to unblock it.

> Sorry, but that is a BS argument. On the contrary, it's a fundamental fact that needs to be kept in mind when designing security-related UI. > It is the user's fault if they do not read the security dialog. No, it's the fault of the programmer for asking the user to make a decision that involves information and understanding that the user doesn't have, and most likely doesn't need to have. I urge you to do your research and read some of the studies done on this. > What would happen if Windows start blocking all .exe files because some of > them could be dangerous? Last I checked, OS X does something along those lines for executables downloaded from the Web, by default, until the user explicitly allows them to run (I don't recall the details, to be honest). What mostly happens is a lower incidence of malware. > This is basically the same thing. In 99% of cases when people say that, the two things are in fact different. In this case, for example. > and we use xml files for the mod instructions. So this is over file:// URIs? That sounds like pretty poor design given the security track record of file://, to be honest.

>> What would happen if Windows start blocking all .exe files because some of >> them could be dangerous? > >Last I checked, OS X does something along those lines for executables >downloaded from the Web, by default, until the user explicitly allows them to >run (I don't recall the details, to be honest). What mostly happens is a lower >incidence of malware. On the Mac the user is warned that the executable was downloaded from the internet, and is then asked whether they wish to continue launching the application, or cancel. The user is provided the option to launch the application. In the case of the issue marked in the ticket, the user is not provided any choice.

Id like to repost my comment on Bug 439721 here hoping it is a push in a new direction: In my view the main problem with this bug is, that FF seams to do some XSL translation (it strips all xml tags) and one could feel there was some error in the XSL file. So I'd say the bug is still open. For me the restrictive default was ok when a) users would see the XML file as if the XSL was not given at all and b) users would get an an info that XSL processing is disabled because of a security restriction (WITHOUT the option to allow it immediately). I belive that most FF users are smart enougth to find the security setting to toggle in this case. bye TT

Oh guys, please, this issue is really not about displaying pop-up with an option. It is about the same-origin policy making absolutely no sense in the context of XSLT. No, there is no exploit possible. But as I understand, turning the policy off would require to implement exception specific to XSLT case. And that is what would make security design less clean, and since the case is considered marginal, the developers do hesitate to implement it ...

For the number of readers of this bug, and for the number of duplicate/related bugs for XSLT handling, I'm disappointed that there are only 3 votes to have it fixed/addressed. Even if you're not able to try fixing the issue yourself, at least vote on it to make your voice heard.

Disallowing directory bridging is disastrous for us who distribute data for local viewing (because users may require it without access to a server). It flies in the face of the philosophy of separating data and style!

I never thought there would be the time again where I have the identic file in three different directories and have to update all of them when I want to change something because of /Firefox/ (Opera, Safari and IE don't deny loading a stylesheet in an external directory). Denying file://, as Maros suggested in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=397894#c32">Comment 32</a>, would make impossible to steal data, wouldn't it? At least relative pahts could be allowed.

Uh... This bug is ONLY about file://. If you're not using file:// URIs, you're seeing something else.

Hello, since the FF developers rather decided to ignore this bug you may vote for Bug 443459 which has a focus away from the "same origin policy". bye TT

(In reply to comment #35) > Yes. You can link to things that are below you in the directory tree, but not > to things that are above you. This restriction is absolutely fatal to distributing entire directory trees of manuals (for example) with shared stylesheets in a directory near the top of the tree so individual files need to link to ../../styles/foo.xsl The current firefox behaviour which appears to be to silently ignore the stylesheet without any indication that it is being ignored seems to be the worse possible outcome. the status says INVALID which seems bizarre. It may be that you decide not to fix, but the initial problem statement is correct. I was directed here after making a comment to bug 402983, is there any bug number tracing this issue that is not closed? When Microsoft added similar security restrictions to IE they at least allowed you to distribute files that worked in combination by putting the magic "mark of the web" comment in them. I'm not saying you should necessarily implement that but _some_ means short of requiring the end user to lower the security settings must be possible. http://msdn.microsoft.com/en-us/library/ms537628(VS.85).aspx

> but _some_ means short of requiring the end user to lower the security > settings must be possible. enter "about:config" in address bar and change option security.fileuri.strict_origin_policy to false. Maybe someone will create a plugin that allows to toggel this option depending on the URI viewed... bye TT

Timothy, doing that is precisely "requiring the end user to lower the security settings"

(In reply to comment #57) > Timothy, doing that is precisely "requiring the end user to lower the security > settings" Yes exactly. We distribute the manual with the product and have no control over whether it's installed on a web server or just read from the file system. It's worked on firefox, and mozilla before that for best part of a decade, and now suddenly with FF3 it stops working. While I can choose to change _my_ security settings if I wish, I can not (or at least I would not) require end users to lower their general security settings in order to read our software manual.

While the suggestion in comment #56 is certainly a solution, it bares all the issues that we see with Windows Vista. Basically it means you get overzealous security, so the only way to return to some sanity is to disable the security all together, which counter-productive. Maybe I should approach this question from another angle: if I have a directory structure where I don't know the absolute based, since it is in my file system, how is a child document meant to reference the base folder of my document tree. For example: /User/myuser/Yearly Report/index.xsl /User/myuser/Yearly Report/January/myfile.xsl If '/User/myuser/Yearly Report' is the document base, how is myfile.xsl meant to reference index.xsl, without using an absolute reference? If there is a cross-browser solution to this, that also works in Firefox 3 and does not break the security model, then this should work for me.

(In reply to comment #59) There are only few things to do: 1., modify the implementation of same-origin policy in a way, that it will not apply to XSL files. See comment #30 for motivation and example. 2., vote for this, and related bugs. I haven't been here for several months so the status: "resolved invalid" is pretty weird to me, especially because solving the bug would have NO impact on security. It suggests, probably, there is no will, XSL knowledge, or resources to do anything with it.

(In reply to comment #60) > (In reply to comment #59) There are only few things to do: > > 1., modify the implementation of same-origin policy in a way, that it will not > apply to XSL files. See comment #30 for motivation and example. See comment #8 and comment #17. > I haven't been here for several months so the status: "resolved invalid" is > pretty weird to me, especially because solving the bug would have NO impact on > security. At least some Mozilla developers that have commented here disagree, and I'll note I disagree too (I'm XSLT module owner). > It suggests, probably, there is no will, XSL knowledge, or resources > to do anything with it. I don't see how you could reach that conclusion given the previous comments. Unless you have significant new arguments I don't think there's a need to make further comments on this bug. Rehashing arguments over and over is not going to make us come back on a decision that was taken after considering those arguments (amongst others). Just because we don't also respond over and over to the same arguments doesn't mean we try to ignore the issue, it means we stand by our decision.

My sole intention was to point the others, that they should either do something, or at least vote. > > > I haven't been here for several months so the status: "resolved invalid" is > > pretty weird to me, especially because solving the bug would have NO impact on > > security. > > At least some Mozilla developers that have commented here disagree, and I'll > note I disagree too (I'm XSLT module owner). I respect that, even though I do not understand the disagreement. The whole thread lacks arguments against the bug, so I would be glad if you provide any. > > > It suggests, probably, there is no will, XSL knowledge, or resources > > to do anything with it. > > I don't see how you could reach that conclusion given the previous comments. > Unless you have significant new arguments I don't think there's a need to make > further comments on this bug. It is a hypothesis, and it is based on the lack of argument against this bug in the thread.

What bothers me, and probably a few people, is that the people involved in implementing this limitation, don't seem to be involved in trying to find a workable solution. One solution that could be done, and would suit me, is the requirement of a signature file either in the base directory of the ancestor, or in all folders of the document tree. The way I would see this working: If Firefox detects a signature file in the current folder, it will then attempt to follow the relative path and if there is a matching signature file in that folder, then the relative path action will be allowed, otherwise it will be denied. I suggest the above approach since it does not require modification of the xsl specification and should not provide any impact on any other systems. Of what form the signature file should take I am not sure, but it could be simply a case of something like a file called "signature.msig" with the header MSIG and then some random content.

That solution sounds like it would allow anyone who can guess the signature (say by installing the same application as the targeted user) to access files in any subtree of the rootmost thing with that signature, no? Seriously, though, Jonas is right. XSLT is not special. The signature thing might be workable, and if so it would need to be workable for all file:// loads. I suggest filing a separate bug about such a modification to the file:// same-origin policy.

Firefox 3.0.4 security.fileuri.strict_origin_policy;true I could not find any written specification for the same-origin policy on local files to answer the following basic questions: 1. Why does a certain xml sometimes load ../view_names.xsl and sometimes not? 2. Does the same-origin policy depend on filetype? Please note, I have carefully read through the following: Security.fileuri.strict origin policy (since 2008-03-20) http://kb.mozillazine.org/Security.fileuri.strict_origin_policy Security.fileuri.origin policy (up to 2008-03-20) http://kb.mozillazine.org/Security.fileuri.origin_policy Bug 230606 - Tighten the same-origin policy for local files (file: URLs, trusted, security) -- Comments #1 to #92 https://bugzilla.mozilla.org/show_bug.cgi?id=230606 Bug 397894 - XML file using XSLT transformation affected by file: same-origin restrictions -- Comments #1 to #64 https://bugzilla.mozilla.org/show_bug.cgi?id=397894 Bug 402983 - Security checks that should be symmetric are now asymmetric -- Comments #1 to #50 https://bugzilla.mozilla.org/show_bug.cgi?id=402983 Firefox3/Product Requirements Document / Security, Privacy https://wiki.mozilla.org/Firefox3/Product_Requirements_Document#Security.2C_Privacy

Hmm. Two of those bugs have dev-doc-needed, but it looks like the documentation hasn't happened. :( The answer to your question 2 is "no". The answer to question 1 is that file A can load same-origin file B if the origin of file A is a file that is either in the same directory as B or in the same directory as an ancestor directory of B. The origin of a file the user loads directly from the url bar is itself. The origin of a file loaded from another file (via link click, location set, subframe load, etc, etc, etc) is the origin of the file that originated the load if the load is same-origin and is the file being loaded otherwise. So if the user directly loads /tmp/foo/test.html, then that file's origin is itself. If that file loads a subframe from /tmp/foo.html, that subframe's origin is /tmp/foo.html. If it loads a subframe from /tmp/foo/bar.html or /tmp/foo/bar/baz.html, that subframe's origin is /tmp/foo/test.html. So the upshot is that if a user loads some file, then after that all files in that file's directory or subdirectories of it are treated as same-origin with that file. Files higher up in the directory tree are not.

>> 2. Does the same-origin policy depend on filetype? > The answer to your question 2 is "no". Local html loads css from ../css/ind_common_b.css . If not already done, I'll file a bug report. > The origin of a file the user loads directly from the url bar is itself. The > origin of a file loaded from another file (via link click, location set, > subframe load, etc, etc, etc) is the origin of the file that originated the > load if the load is same-origin and is the file being loaded otherwise. It's much clearer now, thanks. But if I right-click a link, the origin should be preserved ("open link in new tab" etc.) or you should warn the user if this is not possible and the origin is about to change ("bookmark this page"). As it stands now, the context menue has become worthless in this situation. These are just a few ideas and not a replacement for a design, if you know what I mean. Was or is there any discussion about the "origin of a file" concept, which I can read?

> Local html loads css from ../css/ind_common_b.css Stylesheet _loading_ is not subject to same-origin checks, ever (even on the web). Trying to read rules from that stylesheet via script will fail, of course (with the strict file policy; it would be allower with the old file policy). > But if I right-click a link, the origin should be preserved ("open link in new > tab" etc.) Indeed. If it's not, then there's a bug there even with web content (e.g. javascript: and data: URIs). Pretty sure it's already filed, but if not please do file. It's a front-end bug, not a core rendering engine bug. > Was or is there any discussion about the "origin of a file" concept, > which I can read? I think the bugs you reference in comment 65 have discussion about this... There might have been something in newsgroups too, but if so I don't have pointers to it offhand.

Every time I am copying my XML files to another machine I have to remember this weird FF3 option of allowing XML to use XSL from a different folder. Maybe someone can show me some scenario that will break my security when XML and XSL are in the different folders? Maybe some security problems can happen for "file://" references in HTML pages, but this is absolutely not related to XSL. This XSL file referenced with "file://" will go through XSL processor which will reject anything that is not valid XSL (including ssh scripts, or whatever). Means this restriction is totally useless for XSL technology. And a very painful one, since you would definitely prefer one XSL to be able to process (be referenced by) a lot of XML files in different directories. This restriction is kind of similar if you would restrict HTML page to use only images from the same folder as HTML file itself in <img src> tag.