Last Comment Bug 397894 - XML file using XSLT transformation affected by file: same-origin restrictions
: XML file using XSLT transformation affected by file: same-origin restrictions
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: Security: CAPS (show other bugs)
: unspecified
: x86 Windows XP
: P3 major with 14 votes (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
:
Mentors:
: 404240 421198 431259 435078 435449 439238 439721 443879 447808 463353 650844 668484 (view as bug list)
Depends on:
Blocks: 230606 404240
  Show dependency treegraph
 
Reported: 2007-09-28 06:31 PDT by Erick Fauquette
Modified: 2011-06-30 06:14 PDT (History)
36 users (show)
dsicore: blocking1.9+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
XML/XSL/CSS file (13.63 KB, application/unknown)
2007-09-28 06:37 PDT, Erick Fauquette
no flags Details

Description Erick Fauquette 2007-09-28 06:31:02 PDT
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
Comment 1 Erick Fauquette 2007-09-28 06:37:26 PDT
Created attachment 282685 [details]
XML/XSL/CSS file
Comment 2 Erick Fauquette 2007-09-28 06:52:47 PDT
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"?>
Comment 3 Christian :Biesinger (don't email me, ping me on IRC) 2007-09-28 06:54:59 PDT
any messages in the error console? (tools|error console)
Comment 4 Erick Fauquette 2007-09-28 07:08:25 PDT
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.
Comment 5 Christian :Biesinger (don't email me, ping me on IRC) 2007-09-28 10:44:34 PDT
yeah, I think this is intentional
Comment 6 Daniel Veditz [:dveditz] 2007-09-28 11:19:38 PDT
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.
Comment 7 Boris Zbarsky [:bz] 2007-09-28 11:40:15 PDT
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.
Comment 8 Jonas Sicking (:sicking) PTO Until July 5th 2007-09-28 14:45:50 PDT
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.
Comment 9 Erick Fauquette 2007-09-30 23:37:23 PDT
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 ...
Comment 10 Daniel Veditz [:dveditz] 2007-10-01 10:16:19 PDT
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.
Comment 11 Erick Fauquette 2007-10-02 00:06:05 PDT
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.




Comment 12 Jonas Sicking (:sicking) PTO Until July 5th 2007-10-02 00:22:16 PDT
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.
Comment 13 Daniel Veditz [:dveditz] 2007-10-03 02:32:16 PDT
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
Comment 14 Ivan G Shevchenko 2007-11-18 07:40:20 PST
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?
Comment 15 Boris Zbarsky [:bz] 2007-11-18 10:05:26 PST
> why this bug isn't marked closed nor resolved?

Because the current setup for file:// is not yet finalized.
Comment 16 Damon Sicore (:damons) 2007-11-20 10:30:14 PST
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.  
Comment 17 Jonas Sicking (:sicking) PTO Until July 5th 2007-11-20 11:13:09 PST
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.
Comment 18 Boris Zbarsky [:bz] 2007-11-20 11:36:49 PST
*** Bug 404240 has been marked as a duplicate of this bug. ***
Comment 19 Erick Fauquette 2007-11-30 06:49:35 PST
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  ?

Comment 20 Boris Zbarsky [:bz] 2007-11-30 09:22:40 PST
> 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.
Comment 21 Hristo 2008-04-07 23:53:10 PDT
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
Comment 22 Hristo 2008-04-08 00:51:27 PDT
> 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!

Comment 23 Boris Zbarsky [:bz] 2008-04-08 09:21:40 PDT
No, sounds like everything is working as designed.  The error console reports the security load error, I would presume...
Comment 24 Jesse Ruderman 2008-04-28 20:03:46 PDT
*** Bug 431259 has been marked as a duplicate of this bug. ***
Comment 25 Robert Longson 2008-05-22 01:28:51 PDT
*** Bug 435078 has been marked as a duplicate of this bug. ***
Comment 26 Sylvain Pasche 2008-05-23 14:24:34 PDT
*** Bug 435449 has been marked as a duplicate of this bug. ***
Comment 27 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.
Comment 28 Christopher V. Kimball 2008-05-27 04:04:46 PDT
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 )
Comment 29 Hristo 2008-06-02 01:16:26 PDT
"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!
Comment 30 Maros Ivanco 2008-06-02 09:29:41 PDT
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

Comment 31 Andre-John Mas 2008-06-02 09:46:10 PDT
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.

Comment 32 Maros Ivanco 2008-06-02 09:57:51 PDT
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).
Comment 33 Aiko 2008-06-14 11:51:37 PDT
*** Bug 439238 has been marked as a duplicate of this bug. ***
Comment 34 bugzilla 2008-06-14 12:05:14 PDT
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).
Comment 35 Boris Zbarsky [:bz] 2008-06-14 13:43:29 PDT
Yes.  You can link to things that are below you in the directory tree, but not to things that are above you.
Comment 36 Luke Mawbey 2008-06-15 18:32:53 PDT
*** Bug 421198 has been marked as a duplicate of this bug. ***
Comment 37 bugzilla 2008-06-16 07:10:03 PDT
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].
Comment 38 Boris Zbarsky [:bz] 2008-06-16 08:34:18 PDT
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.
Comment 39 Alan Varga 2008-06-16 10:53:58 PDT
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).
Comment 40 Nathan 2008-06-16 12:27:07 PDT
"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.
Comment 41 Boris Zbarsky [:bz] 2008-06-16 14:59:21 PDT
> 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.
Comment 42 Andre-John Mas 2008-06-16 16:08:41 PDT
>> 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.
Comment 43 timothy truckle 2008-07-02 00:07:22 PDT
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
Comment 44 Maros Ivanco 2008-07-02 01:18:19 PDT
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 ...
Comment 45 Alan Varga 2008-07-02 10:55:48 PDT
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.
Comment 46 Gordon Whitnall 2008-07-02 12:32:04 PDT
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!

 
Comment 47 Matthias Versen [:Matti] 2008-07-07 03:41:38 PDT
*** Bug 443879 has been marked as a duplicate of this bug. ***
Comment 48 Simon A. Eugster 2008-07-07 03:57:36 PDT
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. 
Comment 49 Boris Zbarsky [:bz] 2008-07-07 09:18:42 PDT
Uh...  This bug is ONLY about file://.  If you're not using file:// URIs, you're seeing something else.
Comment 50 Boris Zbarsky [:bz] 2008-07-07 16:19:11 PDT
*** Bug 443879 has been marked as a duplicate of this bug. ***
Comment 51 Robert Longson 2008-07-24 09:59:15 PDT
*** Bug 447808 has been marked as a duplicate of this bug. ***
Comment 52 Jesse Ruderman 2008-11-06 00:20:18 PST
*** Bug 439721 has been marked as a duplicate of this bug. ***
Comment 53 Jesse Ruderman 2008-11-06 00:20:31 PST
*** Bug 463353 has been marked as a duplicate of this bug. ***
Comment 54 timothy truckle 2008-11-06 00:47:14 PST
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
Comment 55 David Carlisle 2008-11-18 07:12:35 PST
(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
Comment 56 timothy truckle 2008-11-18 08:10:50 PST
>  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
Comment 57 Boris Zbarsky [:bz] 2008-11-18 08:19:13 PST
Timothy, doing that is precisely "requiring the end user to lower the security settings"
Comment 58 David Carlisle 2008-11-18 08:42:07 PST
(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.
Comment 59 Andre-John Mas 2008-11-18 10:13:40 PST
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.
Comment 60 Maros Ivanco 2008-11-19 03:23:08 PST
(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.
Comment 61 Peter Van der Beken [:peterv] - away till Aug 1st 2008-11-19 03:52:18 PST
(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.
Comment 62 Maros Ivanco 2008-11-19 05:02:57 PST
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.
Comment 63 Andre-John Mas 2008-11-19 08:05:12 PST
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.
Comment 64 Boris Zbarsky [:bz] 2008-11-19 08:33:35 PST
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.
Comment 65 Manfred Staudinger 2008-11-23 07:31:55 PST
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
Comment 66 Boris Zbarsky [:bz] 2008-11-23 08:16:30 PST
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.
Comment 67 Manfred Staudinger 2008-11-23 11:00:26 PST
>> 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?
Comment 68 Boris Zbarsky [:bz] 2008-11-23 13:05:16 PST
> 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.
Comment 69 Egor Abramovich 2010-01-04 10:18:39 PST
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.
Comment 70 Boris Zbarsky [:bz] 2010-07-30 11:35:57 PDT
*** Bug 583309 has been marked as a duplicate of this bug. ***
Comment 71 Robert Longson 2011-04-18 11:51:06 PDT
*** Bug 650844 has been marked as a duplicate of this bug. ***
Comment 72 Robert Longson 2011-06-30 06:14:31 PDT
*** Bug 668484 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.