165606 - error loading XML file from URL with xmlDoc.load - document.load throws wrong security error code

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Rob Hughes]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826

Even with Mozilla 1.1 it is incredibly hard to get XML to parse from a URL to
HTML with Mozilla. Even with some tune-up code to account for bugs, I still
can't get it to work for a URL.

Reproducible: Always

Steps to Reproduce:
1. open the URL provided
2. click on the load XML from URL button
3. javascript: to view error

Actual Results:  
If you go to the URL, click on the "load XML from URL" and there's the following
error "Error: uncaught exception: [Exception... "Component returned failure
code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMXMLDocument.load]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
http://www.geek.com/test2/ibrains/js-xmltest2_2.htm :: loadXMLFromURL :: line
75"  data: no]"

Expected Results:  
Maybe I'm just a retard, but I've been trying to get Mozilla/Netscape to load
XML data from a URL for several hours now. The example I provided has code I
grabbed from a newsgroup that specifically tunes up the Netscape XML stuff for
dealing with loading XML from a file, which seems to work ok, but still, this
should be fixed so that it works properly. In IE 6.0 and 5.5 it works fine -
both buttons on the example page. 

Even if this is an example of "bad code form" it should work but note an error
due to the bad form, I'd say. For now, IE will support this functionality on my
site, and Mozilla/Nav will not. Argh.

Comment 1

[Rob Hughes]

This link to the Usenet archive on Google has an item with a lot of interesting
info on Mozilla DOM stuff compiled into one place:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=eadeadc2.0207231411.50e602a4%40posting.google.com&rnum=1&prev=/groups%3Fq%3DxmlDoc.load%2Bnetscape%2Berror%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Deadeadc2.0207231411.50e602a4%2540posting.google.com%26rnum%3D1

Just FYI if anyone's trying to get around similar stuff. Also, it may have been
unclear from my first post, but I'm trying to parse an XML file returned as the
result of a http call. It can work directly from a file or from input, but I
can't get Mozilla to load an URL result as XML.

Comment 2

[Boris Zbarsky [:bzbarsky]]

You're trying to load XML from a different domain, which I don't believe we
allow, for security reasons.

Comment 3

[Rob Hughes]

Hm. Not sure how that adds to security. I could put the same logic bomb into a
local URL or a file that could be there in a non-local domain.

I guess there's some assumption here that code from a different domain name may
be evil, but code from a local domain is trusted in some way? However, I don't
really see the difference personally. If I'm a naughty webmaster, I could pull
the same tricks either way...right? It seems more restrictive than secure to me
IMHO.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> I guess there's some assumption here that code from a different domain name may
> be evil, but code from a local domain is trusted in some way?

No.  What is being protected here is the user's ability to communicate with the
"different domain" without you reading the data.  If you could make requests to
the "different domain" that look like the user making a request and then read
the data, that would be disastrous (thing "different domain" == "user's bank's
web site").

So the idea here is not to prevent the browser from loading the content (you
could load it in an iframe) but to prevent _you_ (and untrusted and presumed
evil person) from getting at content that only the user should be able to get at.

See http://sec.greymagic.com/adv/gm001-ns/ and the IE equivalent at
http://www.xs4all.nl/~jkuperus/bug.htm for more information.

Comment 5

[Rob Hughes]

Those two links provided discuss a bug regarding reading the user's local hard
drive. It would seem to me that that problem could be fixed separately from
disabling the ability to load some HTML into a variable. However, I think your
statements have merit.

"If you could make requests to the 'different domain' that look like the user
making a request and then read the data, that would be disastrous"
I guess the problem is that Javascript will let you act as the user, but
something like Perl or a simple Unix "get" command would be seen as the server
making the request and not the client machine (IP address). I could see how this
is potentially harmful if you set up a bogus site, knew how to access an
insecure financial institution through a repetitive URL, and used such an URL
posing as users tricked into going to your bogus site to transfer funds from
their account to yours... for example, and then getting away with a check and
fleeing to some 3rd world country before being caught and imprisoned. There are
a lot of variables that have to jive here, but it is a potential security
problem, so I can agree with that in the interest of security.

Although making Mozilla Javascript more secure, the unfortunate side effect is
that disallowing that type of request stops Javascript from being able to
offload certain tasks to the user browser from the server (open, parse and
display XML from a 3rd party). A potential workaround is downloading the XML
separately to a file on the local server on a regular basis and then displaying
off of that local XML file with javascript. However, this doesn't work for our
situation as the XML file may potentially change every time a request is made. I
will most likely just use Perl or mod_Perl to take care of the requests and
parsing in lieu of the user.

Feel free to respond if any of my statements are in error. I'm just trying to
gain an understanding specifically why this is prohibited and make it clear to
others as a search for "nsIDOMXMLDocument.load" before I posted this on Bugzilla
turned up blank... hmmm... now when I search Bugzilla for nsIDOMXMLDocument or
nsIDOMXMLDocument.load (here:
http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser&format=guided), I
still get "Zarro Boogs found." even though I've used that term to describe this
boog. Is Bugzilla's search working properly? This bug has been open for 2 days...

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Although making Mozilla Javascript more secure, the unfortunate side effect is
> that disallowing that type of request stops Javascript from being able to
> offload certain tasks to the user browser from the server (open, parse and
> display XML from a 3rd party).

Agreed.

> Is Bugzilla's search working properly?

Sort of, yes...  That search field does not search UNCONFIRMED bugs.

confirming, since no matter what the end result is the problem is still
present... if nothing else, we should throw a security exception, not just
NS_ERROR_FAILURE.

Comment 7

[Rob Hughes]

If a decent security exception can be sent to the javascript console instead of
the generic message, that would definitely help people figure out what's going
on. If a better "error" message is shown, and this becomes searchable, that
satisfies me.

Comment 8

[Joris Huizer]

I'm seeing this in Mozilla on Linux;

I have a folder system like this:
main-folder
 vDesktopService - xml files created by the server
 vDesktopLogin - a html file loading the xml files from xml

It's obvious the xml is coming from the same server as the html, but I get the
error:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMXMLDocument.load]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
http://vdesktop.us/vdesktoplogin/webservice.js :: callService :: line 46"  data: no]

What's going wrong here? This cannot possible be a security problem as the xml
is coming from the same server

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Joris, I suspect in your case this happens because your script is at vdesktop.us
while the script tries to load a file from www.vdesktop.us. String comparing
these two hosts shows they are different, and the security manager will block
it. Try relative URLs (i.e. skip the host part), or make sure the host names
really are the same.

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

So the only issue we have is that we should have a more decriptive error message
for a security error? Since document.load() will be in DOM Level 3, I think we
could reuse the DOM access denied error messages. Let me know if you think
something else is needed.

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Proposed fix

No need to throw exception here, CAPS will do it for us. There are no C++
callers of this method in Mozilla either, so should be cool for everyone.

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

After the fix the user will now see this in JS console (we do this for
XMLHttpRequest.open as well):

Error: uncaught exception: Permission denied to call method XMLDocument.load

Comment 13

[Mitchell Stoltz (not reading bugmail)]

Comment on attachment 114724 [details] [diff] [review]
Proposed fix

r=mstoltz on this fix. Returning OK instead of FAILURE should make the more
descriptive error message propagate.

Comment 14

[Peter Van der Beken [:peterv]]

Comment on attachment 114724 [details] [diff] [review]
Proposed fix

Could you add a comment at the return or in the header or both to point out
that if JS code calls C++ code that calls this code then the C++ caller doesn't
get notified about the error.

Comment 15

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Sure, I'll add the comment.

Comment 16

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Fixed.

I added the following comment to the C++ code:

    // We need to return success here so that JS will get a proper exception
    // thrown later. Native calls should always result in CheckConnect() succeeding,
    // but in case JS calls C++ which calls this code the exception might be lost.