Last Comment Bug 445890 - XMLHttpRequest.responseXml not accessible from signed remote XUL code
: XMLHttpRequest.responseXml not accessible from signed remote XUL code
Status: VERIFIED FIXED
: regression, verified1.8.1.17
Product: Core
Classification: Components
Component: Security (show other bugs)
: 1.8 Branch
: All All
-- major (vote)
: ---
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
: David Keeler [:keeler] (use needinfo?)
Mentors:
Depends on: 326337 456705 457411
Blocks: 418996
  Show dependency treegraph
 
Reported: 2008-07-17 17:10 PDT by Franck Stauffer
Modified: 2008-10-08 10:03 PDT (History)
10 users (show)
dveditz: wanted1.8.1.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
This should do the trick (1.76 KB, patch)
2008-08-25 13:33 PDT, Boris Zbarsky [:bz] (still a bit busy)
bugs: review+
jst: superreview+
dveditz: approval1.8.1.17+
Details | Diff | Splinter Review

Description User image Franck Stauffer 2008-07-17 17:10:20 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16

We are developing a signed remote XUL CMS. Since firefox 2.0.0.15 we have serious problems with XmlHttpRequests,the following code used to work just fine

p = new XMLHttpRequest();
p.onload = null;
p.open("GET", requestUrl, false);
p.send(null);

if (p.responseXML)
{
     var preferencesDocumentId = parseInt(p.responseXML.getElementsByTagName('id').item(0).firstChild.data);
[...]

but now it seems p.responseXML has some rather very restrictive security access restrictions. The workaround is to do something like this:

p = new XMLHttpRequest();
p.onload = null;
p.open("GET", requestUrl, false);
p.send(null);
               
var xmlParser = new DOMParser();
var xmlResponse = xmlParser.parseFromString(p.responseText, 'text/xml');
[...]

Only Firefox 2.0.0.15 and 2.0.0.16 Mac/Win and probably linux exhibit that problem (even FF3 is fine).

Reproducible: Always

Steps to Reproduce:
(Online dummy testcase)

1. Install the signing certificate from here: 
http://www.lowcoders.fr/xul/getcert.php (Select the first and last chechbox)
2. Open the following URL: jar:http://www.lowcoders.fr/xul/getjar.php!/index.xul
Actual Results:  
JS Error console:
Error: uncaught exception: Permission denied to call method XMLDocument.getElementsByTagName

Expected Results:  
JS alert with the text "Hello"

Content of index.xul inside the signed jar:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>

<window
    id="findfile-window"
    title="Recherche de fichiers"
    orient="horizontal"
    xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">


<script type="text/javascript">
function testXmlHttpRequests(){
    var request = new XMLHttpRequest();
    request.open("GET", "http://www.lowcoders.fr/xul/test.xml", false);
    request.send(null);
    alert(request.responseXML.getElementsByTagName("test").item(0).firstChild.data);
}
</script>

<vbox flex="1">
	<hbox>
		<button label="Test" oncommand="testXmlHttpRequests()" />
		<spacer flex="1"/>
	</hbox>
	<spacer flex="1"/>
</vbox>

</window>

where http://www.lowcoders.fr/xul/test.xml

contains
<?xml version="1.0" encoding="utf-8"?>

<root>
 <test>Hello!</test>
</root>
Comment 1 User image Martijn Wargers [:mwargers] 2008-07-17 17:34:47 PDT
Boris, is this related to bug 434544 and/or bug 428995?
Comment 2 User image Franck Stauffer 2008-07-18 00:44:12 PDT
To be complete, the unsigned version of the script is directly accessible here:

http://www.lowcoders.fr/xul/index.xul

Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2008-07-21 11:05:29 PDT
Yeah.  The problem is that the signed script and the data gotten via XMLHttpRequest are different origins, since said data doesn't come from inside the signed jar.

On trunk, we set the calling document principal on the XMLHttpRequest response (see bug 326337), but that change never landed on branch, so we get this bug.
Comment 4 User image Daniel Veditz [:dveditz] 2008-08-04 11:44:02 PDT
So this would be fixed by a branch version of the patch in bug 326337?
Comment 5 User image Boris Zbarsky [:bz] (still a bit busy) 2008-08-04 12:37:43 PDT
I would think so, yes.
Comment 6 User image Peter Van der Beken [:peterv] 2008-08-05 01:32:17 PDT
If you want this fixed in the next three weeks you'll need to find a better owner.
Comment 7 User image Samuel Sidler (old account; do not CC) 2008-08-11 20:09:49 PDT
Johnny or Boris, can you take this on?
Comment 8 User image Samuel Sidler (old account; do not CC) 2008-08-25 11:23:41 PDT
Moving out to 1.8.1.18 since peterv is out of town.
Comment 9 User image Boris Zbarsky [:bz] (still a bit busy) 2008-08-25 13:33:29 PDT
Created attachment 335415 [details] [diff] [review]
This should do the trick
Comment 10 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2008-08-25 14:03:16 PDT
Comment on attachment 335415 [details] [diff] [review]
This should do the trick

It is different question if we need Bug 421228 on 1.8.
Comment 11 User image Boris Zbarsky [:bz] (still a bit busy) 2008-08-25 14:09:30 PDT
Gah.  Yes, we'd need that; good catch.  But there is no nullprincipal on 1.8...  I guess we could make it use about:blank?
Comment 12 User image Boris Zbarsky [:bz] (still a bit busy) 2008-08-26 13:32:52 PDT
Actually, I don't think we need it.  The data document content policy won't get bypassed on branch, and that's all that really matters here, I think.
Comment 13 User image Daniel Veditz [:dveditz] 2008-08-26 21:07:49 PDT
Comment on attachment 335415 [details] [diff] [review]
This should do the trick

Is it going to matter that in a redirect case the principal doesn't get updated? On branch they're guaranteed same-origin so they would at least be equivalent principals, but is this case handled OK for XS-XHR on trunk?

regardless, for 1.8 branch approved for 1.8.1.17, a=dveditz for release-drivers
Comment 14 User image Daniel Veditz [:dveditz] 2008-08-27 00:47:02 PDT
Fix checked into 1.8 branch.
Comment 15 User image Boris Zbarsky [:bz] (still a bit busy) 2008-08-27 05:20:10 PDT
We don't have XS-XHR on trunk yet, and when we do we'll likely still stamp the document with the loader principal so that the loader can actually get that data.

Thanks for checking this in!
Comment 16 User image Al Billings [:abillings] 2008-09-02 15:58:25 PDT
Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/2008082909 Firefox/2.0.0.17.
Comment 17 User image Boris Zbarsky [:bz] (still a bit busy) 2008-10-08 10:03:29 PDT
Removing the blocker flag for a release _after_ the one this was fixed in, since it's not really relevant anymore.

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