Open Bug 583309 Opened 14 years ago Updated 2 years ago

No error reported for attempted non-HTTP cross-origin document() load

Categories

(Core :: XSLT, defect)

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

Tracking

()

People

(Reporter: michal.stybnar, Unassigned)

Details

(Whiteboard: Please read comment 14) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6

I'm really not sure if this problem is located in Transformiix or other part of the software, but it's 100% reproducible.

if I reference an XML document from a path like this: "../test.xml", the call to document() function simply fails without any visible notification (even the error console is silent here).


Reproducible: Always

Steps to Reproduce:
1. Create a simple XML like this:
<?xml version="1.0" encoding="utf-8" ?>
<?xml-stylesheet href="test.xsl" type="text/xml"?>
<?xml-stylesheet href="test.xsl" type="text/xsl"?><!-- for IE compatibility -->
<test href="..\test1.xml">
	<value>5</value>
	<value>1</value>
	<value>7</value>
	<value>2</value>
	<value>6</value>
	<value>4</value>
	<value>3</value>
	<value>2</value>
</test>
2. Create a stylesheet like this:
<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text" encoding="UTF-8"/>

<xsl:template match="/test">
	Description taken from: <xsl:value-of select="/test/@href"/><xsl:text>&#10;</xsl:text>
	Index	Value	Name<xsl:text>&#10;</xsl:text>
	<xsl:apply-templates select="value"/>
</xsl:template>

<xsl:template match="value">
	<xsl:variable name="value" select="text()"/>
	<xsl:text>&#9;</xsl:text>
	<xsl:value-of select="position()"/><xsl:text>       </xsl:text>
	<xsl:value-of select="text()"/><xsl:text>       </xsl:text>
	<xsl:value-of select="document(/test/@href)/test/desc[@value=$value]/@name"/>
	<xsl:text>&#10;</xsl:text>
</xsl:template>

</xsl:stylesheet>
3. Create the test1.xml and put it in the parent directory (as in /test/@href)
<?xml version="1.0" encoding="iso-8859-1" ?>
<test>
	<desc name="Value 1" value="1" yes="1">Desc 1</desc>
	<desc name="Value 2" value="2" yes="1">Desc 2</desc>
	<desc name="Value 3" value="3" yes="1" skip="1">Desc 3</desc>
	<desc name="Value 4" value="4" yes="1">Desc 4</desc>
	<desc name="Value 5" value="5">Desc 5</desc>
	<desc name="Value 6" value="6" yes="1">Desc 6</desc>
	<desc name="Value 7" value="7" yes="1">Desc 7</desc>
</test>
Actual Results:  

	Description taken from: ../test1.xml

	Index	Value	Name
	1       5       
	2       1       
	3       7       
	4       2       
	5       6       
	6       4       
	7       3       
	8       2       


Expected Results:  

	Description taken from: test1.xml

	Index	Value	Name
	1       5       Value 5
	2       1       Value 1
	3       7       Value 7
	4       2       Value 2
	5       6       Value 6
	6       4       Value 4
	7       3       Value 3
	8       2       Value 2


I leaved the changed path in the expected results to show you, that if the test1.xml file is in the current directory it works (same if in a child dir). I reproduced it only locally (file:///D:/...), not from the server, but it should work in both cases. On server it handles the "../" in path correctly (tested with an apache server on a remote machine).

It is not a security risk to load an XML from a parent directory locally on the system - the access rights setting should handle it correctly. So if anybody things about telling me, that this is because of security, than please leave this one to system admins. ;-)
> It is not a security risk to load an XML from a parent directory locally on the
> system

It actually is.  More precisely, it's a privacy risk.  It allows one file owned by the user (but which came from some website) to read some other file owned by the user (that the website isn't supposed to have access to) and then phone the contents home.  Since both files are owned by the user, access rights are not relevant.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
(In reply to comment #1)
> > It is not a security risk to load an XML from a parent directory locally on the
> > system
> 
> It actually is.  More precisely, it's a privacy risk.  It allows one file owned
> by the user (but which came from some website) ...

It's not a website! All of the files are local only! e.g.:
   D:\project\features\test.xml
   D:\project\features\stylesheets\test.xsl
   D:\project\data\test1.xml

All the files are from the same project and are on the same "site" (in this case machine or even more strictly drive). In this case there's no reason why Firefox should handle security! It's up to the system administrator to setup correct access rights.

> *** This bug has been marked as a duplicate of bug 397894 ***

I disagree! This is definitely not a duplicate, as in that case the output was not displayed at all and there was a message in the error console, but not in my case!

I lost days before I realized, that my XSLT stylesheet is comletely OK, but the behaviour of Firefox is wrong (and even if it would be a security risk, it's a bug when I'm not informed about it). That example worked with IE6, Stylus Studios built in transformer and Saxon as well. Only Transformiix SILENTLY ignored that!

So this should be done:
1) if it is considered a security risk, !ALERT! the user (not just in the console or in my case never) that it may be a risk - like in IE, when a site not in trusted sites tries to run ActiveX.
2) allow override of this functionality (again like in IE), because when I develop stylesheets I do it always locally before I use them online (because my stylesheets are built into the application) and the directory structure is fixed because of versioning system (ClearCase) and production scripts. There's a similar structure to the one I showed on top of this comment. Each project has it's own drive on Windows, so it's not a security risk. As I told you, let it up to the user. You can notify us, but leave the decision on us. The only other possibility is to black-list Mozilla in our application.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Another error reproducible with the test case here. If you do not explicitly "select" where to apply next template at line 9 of the stylesheet, the result is this (including empty lines):
    Description taken from: test1.xml

    Index    Value    Name

    	2       5       Value 5

    	4       1       Value 1

    	6       7       Value 7

    	8       2       Value 2

    	10       6       Value 6

    	12       4       Value 4

    	14       3       Value 3

    	16       2       Value 2

Why does this happen - again only in Transformiix?
Firefox doesn't know if the file originally came from an untrusted source, like email or browser save-webpage-as. Thus we treat all local file content as potentially untrusted and don't allow it to access parent directories.

Would you really want a webpage that you had saved from the web to be able to use

document("../../../Program Files/User Name/Documents/....")

and read any HTML or XML file there and send it to any website on the web?

If there wasn't an error message in the console that is a problem though. I thought there would have been, is there really not?
> It's not a website!

_You_ know that, but Gecko doesn't.  See comment 4.

> It's up to the system administrator to setup correct access rights.

Please read comment 1 and comment 4 carefully.

> as in that case the output was not displayed at all and there was a message
> in the error console, but not in my case!

That bug as filed was about the link given in the <?xml-stylesheet?> PI, but as far as I can tell some of the duplicates cover exactly this situation.

Specifically, the document() call goes through nsSyncLoader::LoadDocument which creates an nsCrossSiteListenerProxy which makes calls to CheckMayLoad and passes false for the "report errors" argument (since a false return is not necessarily fatal yet at that point).  Then because the protocol is not http or https it fails the load with the (somewhat useless) NS_ERROR_FAILURE error code.  If the protocol were one of those, it would fail the load later (but probably still not report an error to the error console, if I recall how the cross site proxy works correctly).

I agree that there should be an error console message in this case and that the lack of such is a bug; resummarizing accordingly and confirming.

> allow override of this functionality

Please do read bug 397894.  That issue is discussed there.  In general, users do not have the knowledge necessary to make that sort of security decision; the ones who can are of course able to change the preference to use the loose file security policy (with the attendant security risks).

> The only other possibility is to black-list Mozilla in our application.

That's up to you, obviously.  But your application is relying on a security hole to work, so...

> Why does this happen - again only in Transformiix?

Sounds like a separate issue from the original bug here, which should be filed separately.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: XPath function document() incorrectly handles relative paths → No error reported for attempted non-HTTP cross-origin document() load
(In reply to comment #5)
> > It's not a website!
> 
> _You_ know that, but Gecko doesn't.  See comment 4.

http:// - website
file:// - local files

It's that simple. Please don't do something, which is more than enough. If firefox would be an OS, it would probably deny me to access my own files.

> > It's up to the system administrator to setup correct access rights.
> 
> Please read comment 1 and comment 4 carefully.

I did and still it's obvious that if it's local, than it's local. If I save a webpage, than nobody knows the names of my files. Or does someone? If yes it's not a security hole in the Firefox app., but in the OS! It's not up to you to solve local access rights issues! And I am a developer of user applications in more than one platform - this means I know something. ;-)

> I agree that there should be an error console message in this case and that the
> lack of such is a bug; resummarizing accordingly and confirming.

Even an entry in error console is not enough! It should tell you in a message box or a sort of "panel" like in IE, that current security policy is blocking some code on the webpage(in this case local XML/XSLT). And it should allow you to override it for thi case ONLY! It's not acceptable to lower security check for all cases.

> > allow override of this functionality
> 
> Please do read bug 397894.  That issue is discussed there.  In general, users
> do not have the knowledge necessary to make that sort of security decision; the
> ones who can are of course able to change the preference to use the loose file
> security policy (with the attendant security risks).

Again, let the decision up to the user. Even programmers like me do not use about:config and do not know the ill structure and user interface there!

> > Why does this happen - again only in Transformiix?
> 
> Sounds like a separate issue from the original bug here, which should be filed
> separately.

I agree here.

So at least I would expect Firefox to ALERT me (the user), that something is wrong. And I want to have a possibility to override it with a description which file would be read. Any user of Firefox can decide if he will allow it or not. Do not tell me, that all users are stupid.
> It's that simple.

It's not, because people save web pages.  Please do read the comments in this bug.

> If I save a webpage, than nobody knows the names of my files.

Sure they do.  Lots of apps store their files in standard locations.  That includes files that have various user-private data.

> It's not up to you to solve local access rights issues!

The point is that saved web pages Must Not have the same access rights as the user, period.  Nor, generally speaking, should a random HTML-based help system.  It's that simple, as you like to say.

> this means I know something.

Really, what it means is that you seem to have tunnel-vision regarding XML and XSLT use in terms of it being used only in the ways you use them...

> And it should allow you to override it

Again, most users would just click through something like this.  We see no reason to expose them to that sort of security risk for the rare case of an app that wants to use web technologies not on the web to do things that web technologies can't normally do.

> Again, let the decision up to the user.

Most users are not interested in making this decision, and don't have the information to make it in any way other than picking at random (or more likely picking the "yeah, allow whatever" button).  I suggest familiarizing yourself with the extensive research on user interaction with security dialogs...

> Do not tell me, that all users are stupid.

Of course not.  Most users are just fine mentally.  Which means they (correctly) don't care about computer system security and expect it to be handled for them by the system.  Just like most airline passengers don't worry about the flying of the aircraft and how most car drivers don't worry about their engined not exploding on them.  The problem is that computer professionals seem to think that everyone should spend all their time studying computer security issues so as to make informed decisions in situations like this; most people have better things to do with their time (and do said better things instead).
(In reply to comment #7)
> It's not, because people save web pages.  Please do read the comments in this
> bug.

I did it, but it seems you didn't.

> The point is that saved web pages Must Not have the same access rights as the
> user, period.  Nor, generally speaking, should a random HTML-based help system.
>  It's that simple, as you like to say.

Does Firefox prohibit access to downloaded exe files? These downloaded exe files have the same access to the same files as you mean ("Documents and Settings" and similar). If you really like to have a BIG security, do not allow to download files. But this will all lead to do you now what? That nobody will use Firefox, because it cannot do a simmple thing like downloading a file! It's that simple! Do you understand?

> Really, what it means is that you seem to have tunnel-vision regarding XML and
> XSLT use in terms of it being used only in the ways you use them...

Oh yes we can even not allow to use computers at all, because there are hackers and these create viruses. Because we are unable to protect the user, we can close the internet, computers and everything right?

> > And it should allow you to override it
> 
> Again, most users would just click through something like this.  We see no
> reason to expose them to that sort of security risk for the rare case of an app
> that wants to use web technologies not on the web to do things that web
> technologies can't normally do.

That's it! Leave it up to the user. If he will do it, it's HIS fault not yours! And "can't normally do"? What the hell does this mean? XSLT is a programming language like Javascript. Nothing more and nothing less. The usage should not be limited by a stupid transformer, which does not fulfil standards because of some "security". I'm starting to hate this community. Really.

> Most users are not interested in making this decision, and don't have the
> information to make it in any way other than picking at random (or more likely
> picking the "yeah, allow whatever" button).  I suggest familiarizing yourself
> with the extensive research on user interaction with security dialogs...

I disagree. Most users really wants to decide. That's why we have democracy and not communism. Just thing about it.

> Which means they (correctly) don't care about computer system security and expect it to be handled for them by the system.

Do you seriously believe it?

I liked Mozilla because:
 - it's open source
 - it tries to be secure
 - it's open for extensions

Now it seems, that the security seems to be exaggerated.
> Does Firefox prohibit access to downloaded exe files? 

No, but most users have at least some idea that those might be dangerous.  Most users have no idea that a downloaded web page can be dangerous.

> Because we are unable to protect the user, we can close the internet,
> computers and everything right?

Well, obviously one has to strike a balance.  That's what we try to do with our same-origin policy for files: prohibit the most egregious security issues while keeping most (emphasis on most) file:// content that assumes all files are in a single security origin working.  It's your bad luck that your content isn't in the set of things that can be made to work without breaking other, more common, things or without compromising security.

> If he will do it, it's HIS fault not yours!

Sorry, no.  That's not the case in any sane ethical system (nor in many legal ones).  If I give someone who has no experience with guns and has never seen one or heard of one a loaded gun and don't even mention that it might be dangerous, it's _my_ fault if he hurts himself or others.  If you think otherwise, then I think we have a fundamental philosophical disagreement about how people should relate to each other, and I'm glad we don't live in a world where most people are like you.

> What the hell does this mean?

XSLT on the web can't do document() cross-origin, unless the target site explicitly opts into it.  The file:// behavior you observe is just a consequence of not treating all files as coming from the same origin.

Now clearly there are various different ways of assigning files to origins; the particular one that was chosen was designed to mitigate the most serious security threats while not breaking too many use cases where people assumed all files are same-origin with each other.

> Most users really wants to decide.

Most people want to decide if 1) they care about the issue and 2) they have a basis for the decision.  #1 is a requirement; #2 is not absolutely necessary but helps a lot.

So for example, most people use automatic transmissions (even though they're more expensive than manual ones) because they don't actually care what gear their car is in.  Most people don't change their browser's default settings.  Most people don't change their OS file type associations.  Heck, most people don't change their browser from whatever someone they trust installed for them...

Computer security in particular, most users have no basis for their decisions _and_ don't care about the subject matter.

I'm not going to give a full response to your attempt to drag politics into this, since that would take way too much time and space, except to point out that most people feel that there are _sometimes_ political decisions they care about and know something about and that for any given election most people in fact don't care to decide: turnout in the US is stably under 50% of eligible voters for everything except presidential elections.

> Do you seriously believe it?

Yes.  The thing is, there are multiple scientific studies showing this to be the case, as well as my personal observations of non-technical computer users (which is most of them).  I don't _like_ believing it, but the data is what it is.  Pretending otherwise is bad science leading to bad user interface design and bad outcomes.

> Now it seems, that the security seems to be exaggerated.

You are, of course, entitled to your personal opinions.
(In reply to comment #9)
> > Does Firefox prohibit access to downloaded exe files? 
> 
> No, but most users have at least some idea that those might be dangerous.  

I disagree. For example my mother don't even have any idea about what is a virus. But the true is, that she uses the computer for e-mails only. ;-)

> ... file:// content that assumes all files are in a single security origin ...

What if I make a junction (symlink in *nix environment) of "Documents ans Settings" into some directory on D: drive? In this case the same origin policy would not work either. ;-)

> If I give someone who has no experience with guns ... a loaded gun ... it's _my_ fault if he hurts someone.

Do you live in America? From your last comment - I think so (hmm... now I see - Massachusetts). In most of the countries in European Union it's not allowed to have a gun if you're not a soldier or a police man (with some exceptions) already for a very long time. I think in USA it's the other way round. ;-)

I mean, that the downloaded web page is not a gun. It may be a spyware, but that's a task for spyware protection programs.

> So for example, most people use automatic transmissions (even though they're
> more expensive than manual ones) because they don't actually care what gear
> their car is in.

That's possibly true in USA, but not in other states. In EU for example most of the cars sold use manual transmission. We can argue about why is it so. Is it because it's cheaper, or because people likes control about things? I seriously don't know. It's just about a possibility to have a choice (emphasis on choice). We are already tired of being controlled by someone here. Russians controlled us for more than 40 years, before them there was an Austrian-Hungarian monarchy and so on. And yes, it's all about politics, even if most of the people don't want to accept it (probably, because they are tired too).

> Most people don't change their browser's default settings.

But leave them a choice. Not something hidden in about:config! I was hidden even before me (IT developer)!

> I'm not going to give a full response to your attempt to drag politics ...

I'm sorry. Either way it does not make sense to talk about politics. I just wanted to compare it:
 - democracy - you have a choice
 - communism - you are controlled by someone, who thinks he's smarter than you
No offense...

> Pretending otherwise is bad science leading to bad user interface design
> and bad outcomes.

I agree in most of it, but let there be a chance (I hope it's correctly written in English ;-). Still I want to have a choice to fine tune it and allow the override just for a single file. It can be in the options:
 - don't allow cross-origin files at all
 - ask always
 - don't check at all (ATTENTION: This may be a security risk!)

???


> > Now it seems, that the security seems to be exaggerated.
> 
> You are, of course, entitled to your personal opinions.

Personal, yes! What is more personal, if your making decisions instead of me?
> In this case the same origin policy would not work either. ;-)

Not sure what you mean...

> Do you live in America?

If you care, replace "give a loaded gun" with "allow to get behind the steering wheel of a car".  The point being that if you give someone a dangerous tool, without them realizing it's dangerous, it's really your fault if they misuse it.
(In reply to comment #11)
> Not sure what you mean...

e.g.:

  my XML file is:  D:\test\test.xml
  my XSLT file is: D:\test\test.xsl
  I make a symlink (junction in WinXP) of "C:\Documents and Settings" to D:\test\bla

The result is, that the XML/XSLT would have a complete access to all my docs.
;-)

What I mean with it is: Firefox is not an OS and cannot guarantee any security of this kind. Leave it up to the apps which are responsible for security even if it's not done well. Firefox just cannot make it better in this case.

> If you care, replace "give a loaded gun" with "allow to get behind the steering
> wheel of a car".

I have a bicycle and go out to the streets with it. No one protects me from these steering wheels (except me of course). Does somebody in US? Again no offense. ;-)

P.S.: I don't tell you to delete this "security feature", even if I don't trust it really. I just want to have an override, if I know it's safe. Currently I was forced to allow all scripts to access whatever - because I don't really know what I enabled with that switch in about:config.
> The result is, that the XML/XSLT would have a complete access to all my docs.

That actually depends on whether the security check is done before or after symbolic link resolution.  But yes, it might.  Of course saving a website doesn't create such a symbolic link.

> I have a bicycle and go out to the streets with it.

Sure.  That's not the same thing at all, because any normal person with eyes knows about most of the dangers of riding a bycicle.  And we have huge public education campaigns about things like wearing helmets for the few dangers that are not self-evident.

> I just want to have an override, if I know it's safe.

The problem is that for almost all people the override is a footgun.

That said, if you think that the entire file same-origin policy should be redesigned around your use case (which is what you're asking for), do feel free to file a bug with exactly that as a summary.

> because I don't really know what I enabled with that switch in about:config.

You enabled every file:// URI to load data from any other file:// URI.
People, this bug is getting out of hand.

We are not going to change our security policy to allow any HTML file loaded from the file system read any local file. We have made the judgement call that a significant number of people that open local HTML files do not expect that to be as security sensitive as running an executable. I.e. we do not expect people to understand that that can load privacy sensitive information and send that to a server.

Other people might make other judgement calls. If you want to discuss this I'd encourage you to bring this up in the newsgroups, such as mozilla.dev.security. That will give more people an opportunity to weigh in on the issue.

I should also point out that at least IE has similar concerns as we do. They have used a different solution, but they seem to share the same concern that people don't generally think that locally saved HTML files have the same security issues as executables. IE will refuse to run any scripts at all in local pages, as to prevent those pages from sending sensitive data to the server. Instead the user is given a choice to allow the page to do potentially unsafe actions if the user trusts the page.

We're not a fan of IEs solution since scientific research has showed that a significan number of people tend to just click anything in such dialogs in order to get on with whatever it is they want to do, without taking the time to understand the security implications of this.

However, since we know that the security policy for local files affect developers, the exact way that you are affected, we have enabled a preference to change the policy. If you go to about:config and set the preference

security.fileuri.strict_origin_policy

to false, then your xslt should work fine. However be aware that this means that you should never open a locally saved HTML file from a source that you don't 100% trust with all your locally saved passwords, documents and other resources.
Whiteboard: Please read comment 14
(In reply to comment #13)
> That actually depends on whether the security check is done before or after
> symbolic link resolution.

As far as I know, junctions are resolved in the NTFS driver, which means "kernel" (if you can call it so). I don't know that much about NTFS symlinks.

> The problem is that for almost all people the override is a footgun.

I dont's know what "footgun" is, but still I think that's not the same thing at all (like you like to say).

(In reply to comment #14)
> I should also point out that at least IE has similar concerns as we do.

Sure, I was talking about that.

> IE will refuse to run any scripts at all in local pages ...
> Instead the user is given a choice to allow the page to do potentially
> unsafe actions if the user trusts the page.

And I also think it's not really done the safe way. When I say I trust it, I never know which file would be accessed afterwards. I wanted to have the same "panel" in Firefox with exactly the file name which will be accessed.

> We're not a fan of IEs solution since scientific research ...

Where was this scientific research done? ;-)
Just making fun... ;-)

> However, since we know that the security policy for local files affect
> developers, the exact way that you are affected, we have enabled a preference
> to change the policy. If you go to about:config and set the preference...

I disagree. The about:config was never meant for web page developers, but for Mozilla developers and fan(atic)s.

> However be aware that this means that you should never open a locally saved
> HTML file from a source that you don't 100% trust ...

I talked about it too. Do you remember? (e.g. Comment 12)


BUT OK, I RESIGN!

The subject of this bug currently reads:
  No error reported for attempted non-HTTP cross-origin document() load

That's enough for now. But as I said, error console is not enough!
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.